Ethersex_Wiki sensrjeb_etherwiki http://www.ethersex.de/index.php/Main_Page MediaWiki 1.30.0 first-letter Media Special Talk User User talk Ethersex Wiki Ethersex Wiki talk File File talk MediaWiki MediaWiki talk Template Template talk Help Help talk Category Category talk 10 2 2 2011-09-19T12:32:07Z Mgue 312 Imported https://wiki.archlinux.org/index.php/Template:I18n wikitext text/x-wiki <noinclude>{{Template}} {{DISPLAYTITLE:Template:i18n}} '''An 'i18n' box used to display inter-language links. See [[Help:i18n]].''' ====Usage==== This template should be added at the beginning of every article (ideally below category markers but above any other content). <pre>{{i18n|Template:i18n}}</pre> The argument should be modified to match the English title of the article (i.e. without any language tag). Inter-language links are sorted alphabetically via JavaScript; see the language table ([[Help:i18n#Languages]]) and [[Wikipedia:Help:Sorting]] for details. ====Example==== {{i18n|Template:i18n}}</noinclude><includeonly><div class="toc noprint" style="text-align: center; margin-bottom: 1em"> '''[[Help:i18n|i18n]]''' ---- {{Lang|{{{1}}}|Dansk}} [[{{{2|{{{1}}}}}}|English]]&nbsp;&ndash; <!-- English is special --> {{Lang|{{{1}}}|Español}} {{Lang|{{{1}}}|Français}} {{Lang|{{{1}}}|Indonesia}} {{Lang|{{{1}}}|Italiano}} {{Lang|{{{1}}}|Lietuviškai}} {{Lang|{{{1}}}|Magyar}} {{Lang|{{{1}}}|Nederlands}} {{Lang|{{{1}}}|Português}} {{Lang|{{{1}}}|Română}} {{Lang|{{{1}}}|Slovenský}} {{Lang|{{{1}}}|Suomi}} {{Lang|{{{1}}}|Svenska}} {{Lang|{{{1}}}|Türkçe}} {{Lang|{{{1}}}|Česky}} {{Lang|{{{1}}}|Ελληνικά}} {{Lang|{{{1}}}|Български}} {{Lang|{{{1}}}|Русский}} {{Lang|{{{1}}}|Српски}} {{Lang|{{{1}}}|Українська}} {{Lang|{{{1}}}|עברית}} {{Lang|{{{1}}}|ไทย}} {{Lang|{{{1}}}|日本語}} {{Lang|{{{1}}}|正體中文}} {{Lang|{{{1}}}|简体中文}} [[{{{1}}} (한국어)|한국어]] <!-- last entry is special (don't display trailing dash) --> </div></includeonly> b2668f0bdbcce6dc504fb790561a9df1b1c6af0e 30 2 2011-09-20T16:51:24Z Mgue 312 removed some languages, added german wikitext text/x-wiki <noinclude>{{Template}} {{DISPLAYTITLE:Template:i18n}} '''An 'i18n' box used to display inter-language links. See [[Help:i18n]].''' ====Usage==== This template should be added at the beginning of every article (ideally below category markers but above any other content). <pre>{{i18n|Template:i18n}}</pre> The argument should be modified to match the English title of the article (i.e. without any language tag). Inter-language links are sorted alphabetically via JavaScript; see the language table ([[Help:i18n#Languages]]) and [[Wikipedia:Help:Sorting]] for details. If you want to contribute some translations in a language not listed in the box, feel free to contact us! ====Example==== {{i18n|Template:i18n}}</noinclude><includeonly><div class="toc noprint" style="text-align: center; margin-bottom: 1em"> '''[[Help:i18n|Language]]''' ---- [[{{{2|{{{1}}}}}}|English]]&nbsp;&ndash; <!-- English is special --> {{Lang|{{{1}}}|Español}} {{Lang|{{{1}}}|Français}} {{Lang|{{{1}}}|Nederlands}} {{Lang|{{{1}}}|Deutsch}} [[{{{1}}} (Italiano)|Italiano]]<!-- last entry is special (don't display trailing dash) --> </div></includeonly> 84cd461bd9739b318cce8a2e7faa70b8264099f5 31 30 2011-09-20T16:52:07Z Mgue 312 wikitext text/x-wiki <noinclude>{{Template}} {{DISPLAYTITLE:Template:i18n}} '''An 'i18n' box used to display inter-language links. See [[Help:i18n]].''' ====Usage==== This template should be added at the beginning of every article (ideally below category markers but above any other content). <pre>{{i18n|Template:i18n}}</pre> The argument should be modified to match the English title of the article (i.e. without any language tag). Inter-language links are sorted alphabetically via JavaScript; see the language table ([[Help:i18n#Languages]]) and [[Wikipedia:Help:Sorting]] for details. If you want to contribute some translations in a language not listed in the box, feel free to contact us! ====Example==== {{i18n|Template:i18n}}</noinclude><includeonly><div class="toc noprint" style="text-align: center; margin-bottom: 1em"> '''[[Help:i18n|Language]]''' ---- [[{{{2|{{{1}}}}}}|English]]&nbsp;&ndash; <!-- English is special --> {{Lang|{{{1}}}|Deutsch}} {{Lang|{{{1}}}|Nederlands}} {{Lang|{{{1}}}|Français}} {{Lang|{{{1}}}|Español}} [[{{{1}}} (Italiano)|Italiano]]<!-- last entry is special (don't display trailing dash) --> </div></includeonly> bcbd3ebd4bf084aaceafcd7a3794980956a02eb2 10 3 3 2011-09-19T12:32:51Z Mgue 312 Imported https://wiki.archlinux.org/index.php/Template:Lang wikitext text/x-wiki <noinclude>{{Template}} '''A helper template for use with [[Template:i18n]].'''</noinclude><includeonly>[[{{{1}}} ({{{2}}})|{{{2}}}]]&nbsp;&ndash;</includeonly> 47e6aa2ec99c7326e82e790b8735056b26913a89 10 4 4 2011-09-19T12:38:26Z Mgue 312 Imported https://wiki.archlinux.org/index.php/Template:Template wikitext text/x-wiki <noinclude>{{Template}} '''A special template for use in ''all'' template pages.''' ====Usage==== This template should be added at the very beginning of all template pages between 'noinclude' tags: &lt;noinclude&gt;<nowiki>{{Template}}</nowiki>&lt;/noinclude&gt; A brief description of the template, usage instructions, and output example should also be added between the 'noinclude' tags (as in this template). The template wikitext must be written between 'includeonly' tags: &lt;includeonly&gt;...&lt;/includeonly&gt; ====Example==== {{Template}}</noinclude><includeonly>[[Category:Template]] <div class="toc">This page is a template. It contains no Arch Linux-related information, but should be used as part of other articles. For more information, read [[Help:Template]]. Please do not experiment with this template; you could ruin [[Special:Whatlinkshere/Template:{{PAGENAME}}|all pages using this template]]. If you want to edit this template, copy the text to [[Template:Sandbox]], edit and test it there, and copy it back when it works. Feel free to voice [[Template talk:{{PAGENAME}}|your opinion]] regarding this template.</div></includeonly> 1b8c18161189d994c64da2c2688f9e3045f1e29c 6 4 2011-09-19T15:00:08Z 93.218.20.25 0 changed description wikitext text/x-wiki <noinclude>{{Template}} '''A special template for use in ''all'' template pages.''' ====Usage==== This template should be added at the very beginning of all template pages between 'noinclude' tags: &lt;noinclude&gt;<nowiki>{{Template}}</nowiki>&lt;/noinclude&gt; A brief description of the template, usage instructions, and output example should also be added between the 'noinclude' tags (as in this template). The template wikitext must be written between 'includeonly' tags: &lt;includeonly&gt;...&lt;/includeonly&gt; ====Example==== {{Template}}</noinclude><includeonly>[[Category:Template]] <div class="toc">This page is a template. It contains no ethersex-related information, but should be used as part of other articles. For more information, read [[Help:Template]]. Please do not experiment with this template; you could ruin [[Special:Whatlinkshere/Template:{{PAGENAME}}|all pages using this template]]. If you want to edit this template, copy the text to [[Template:Sandbox]], edit and test it there, and copy it back when it works. Feel free to voice [[Template talk:{{PAGENAME}}|your opinion]] regarding this template.</div></includeonly> 1dbc1c7702ef493cd9964578f425ecbba061beec 0 5 5 2011-09-19T12:39:24Z Mgue 312 i18n wikitext text/x-wiki {{i18n|Main Page}} 8106ade80da3bd223e57337c83200f79a99cacad 28 5 2011-09-20T16:36:09Z Mgue 312 wikitext text/x-wiki {{i18n|Main Page}} == Welcome ethersex - the universial AVR firmware == {{Facts}} 56ff3eac79e011c0a016d5aff9079fe0f94ad7e9 10 6 7 2011-09-19T15:07:11Z 93.218.20.25 0 imported https://wiki.archlinux.org/index.php/Template:Box wikitext text/x-wiki <noinclude>{{Template}} '''A generic message box.''' See also: * [[:Template:Box BLUE]] * [[:Template:Box GREEN]] * [[:Template:Box RED]] * [[:Template:Box YELLOW]] ====Usage==== {{Codeline|1=<nowiki>{{Box||Content without heading}}</nowiki>}} {{Codeline|1=<nowiki>{{Box|Example:|Content with heading}}</nowiki>}} {{Codeline|1=<nowiki>{{Box|Example:|Content followed by border-color|#DF0000}}</nowiki>}} {{Codeline|1=<nowiki>{{Box|Example:|Content followed by border-color and background-color|#DF0000|#FFDFDF}}</nowiki>}} ====Example==== {{Box||Content without heading}} {{Box|Example:|Content with heading}} {{Box|Example:|Content followed by border-color|#DF0000}} {{Box|Example:|Content followed by border-color and background-color|#DF0000|#FFDFDF}}</noinclude><includeonly><div style="padding: 5px; margin: 0.50em 0; background-color: {{{4}}}; border: thin solid {{{3|#000}}}; overflow: hidden;"><strong> {{{1}}} </strong>{{{2}}}</div></includeonly> e17b78ceb9078f9288fb4cb9b12cded82582449a 10 7 8 2011-09-19T15:08:02Z 93.218.20.25 0 imported https://wiki.archlinux.org/index.php/Template:Box_BLUE wikitext text/x-wiki <noinclude>{{Template}} '''A generic BLUE message box.''' ====Usage==== {{Codeline|1=<nowiki>{{Box BLUE|Example:|Content}}</nowiki>}} ====Example==== {{Box BLUE|Example:|Content}}</noinclude><includeonly>{{Box|{{{1}}}|{{{2}}}|#BBBBDD|#DDDDFF}}</includeonly> a38c651df721cbddecab7251b0d977861761f98b 10 8 9 2011-09-19T15:08:53Z 93.218.20.25 0 imported https://wiki.archlinux.org/index.php/Template:Box_GREEN wikitext text/x-wiki <noinclude>{{Template}} '''A generic GREEN message box.''' ====Usage==== {{Codeline|1=<nowiki>{{Box GREEN|Example:|Content}}</nowiki>}} ====Example==== {{Box GREEN|Example:|Content}}</noinclude><includeonly>{{Box|{{{1}}}|{{{2}}}|#BBDDBB|#DDFFDD}}</includeonly> c3dbd71ff5aed064608681c4fd0842258625ad7b 10 9 10 2011-09-19T15:09:08Z 93.218.20.25 0 imported https://wiki.archlinux.org/index.php/Template:Box_RED wikitext text/x-wiki <noinclude>{{Template}} '''A generic RED message box.''' ====Usage==== {{Codeline|1=<nowiki>{{Box RED|Example:|Content}}</nowiki>}} ====Example==== {{Box RED|Example:|Content}}</noinclude><includeonly>{{Box|{{{1}}}|{{{2}}}|#DDBBBB|#FFDDDD}}</includeonly> bb152465c7b5555c1be41883106276852460da88 10 10 11 2011-09-19T15:09:25Z 93.218.20.25 0 imported https://wiki.archlinux.org/index.php/Template:Box_YELLOW wikitext text/x-wiki <noinclude>{{Template}} '''A generic YELLOW message box.''' ====Usage==== {{Codeline|1=<nowiki>{{Box YELLOW|Example:|Content}}</nowiki>}} ====Example==== {{Box YELLOW|Example:|Content}}</noinclude><includeonly>{{Box|{{{1}}}|{{{2}}}|#DDDD88|#FFFFAA}}</includeonly> ee2ff23c836e82e8786bf491d9c32993b7e303b0 10 11 12 2011-09-19T15:12:32Z 93.218.20.25 0 imported https://wiki.archlinux.org/index.php/Template:Codeline wikitext text/x-wiki <noinclude>{{Template}} '''A 'Codeline' element used to format lines of code.''' ====Usage==== {{Codeline|1=<nowiki>{{Codeline|pacman --sync --refresh --sysupgrade}}</nowiki>}} ====Example==== {{Codeline|pacman --sync --refresh --sysupgrade}}</noinclude><includeonly><span style="font-family: monospace; color: #005; white-space: nowrap">{{{1}}}</span></includeonly> fc727e7f5e944af85b4a678ac7c5bcee2d1e7aff 13 12 2011-09-19T15:13:57Z Mgue 312 changed code to ethersex example wikitext text/x-wiki <noinclude>{{Template}} '''A 'Codeline' element used to format lines of code.''' ====Usage==== {{Codeline|1=<nowiki>{{Codeline|make menuconfig}}</nowiki>}} ====Example==== {{Codeline|make menuconfig}}</noinclude><includeonly><span style="font-family: monospace; color: #005; white-space: nowrap">{{{1}}}</span></includeonly> c16e802c242507286afca6640369122bc613f492 10 12 14 2011-09-19T15:15:59Z Mgue 312 imported https://wiki.archlinux.org/index.php/Template:Tip wikitext text/x-wiki <noinclude>{{Template}} '''A 'Tip' box used to share helpful hints.''' ====Usage==== {{Codeline|1=<nowiki>{{Tip|This text should be considered.}}</nowiki>}} ====Example==== {{Tip|This text should be considered.}}</noinclude><includeonly>{{Box GREEN|Tip:|{{{1}}}}}</includeonly> 5d4249fff6bddb0ba3a861a264eb619ae1df7aa2 10 13 15 2011-09-19T15:16:45Z Mgue 312 imported https://wiki.archlinux.org/index.php/Template:Note wikitext text/x-wiki <noinclude>{{Template}} '''A 'Note' box used to emphasize important information.''' ====Usage==== {{Codeline|1=<nowiki>{{Note|This text should be noted.}}</nowiki>}} ====Example==== {{Note|This text should be noted.}}</noinclude><includeonly>{{Box BLUE|Note:|{{{1}}}}}</includeonly> eac0cde41eacd6f9c83dfb6b066260ce3cfd3dc5 10 14 16 2011-09-19T20:26:44Z Mgue 312 Created page with "|" wikitext text/x-wiki | 3eb416223e9e69e6bb8ee19793911ad1ad2027d8 10 15 17 2011-09-19T20:30:33Z Mgue 312 first try wikitext text/x-wiki <onlyinclude>{| class="wikitable float-right" style="width:330px; font-size:95%;margin-top:0px;" !colspan="2" style="background-color:#CEDAF2; text-align:center"| {{#if: {{{NAME|}}}|<big>{{{NAME}}}</big>|<big>{{PAGENAME}}</big>}} |- {{#if: {{{STATUS|}}}| {{!}} style="vertical-align:top;" {{!}}Status {{!}} {{{STATUS}}} }} |- {{#if: {{{MENUCONFIG|}}}| {{!}} style="vertical-align:top;" {{!}}menuconfig {{!}} {{{MENUCONFIG}}} }} |- {{#if: {{{PINNING|}}}| {{!}} style="vertical-align:top;" {{!}}Pinning {{!}} {{{PINNING}}} }} |- {{#if: {{{DEPENDS|}}}| {{!}} style="vertical-align:top;" {{!}}Depends on {{!}} {{{DEPENDS}}} }} |- {{#if: {{{REQUIRES|}}}| {{!}} style="vertical-align:top;" {{!}}Requires {{!}} {{{REQUIRES}}} }} |- {{#if: {{{CODE|}}}| {{!}} style="vertical-align:top;" {{!}}Code {{!}} {{{CODE}}} }} |- |}</onlyinclude> a5c8de20658bd64d026370b21647281161b658a5 18 17 2011-09-19T20:41:27Z Mgue 312 some sample code wikitext text/x-wiki <onlyinclude>{| class="wikitable float-right" style="width:330px; font-size:95%;margin-top:0px;" !colspan="2" style="background-color:#CEDAF2; text-align:center"| {{#if: {{{NAME|}}}|<big>{{{NAME}}}</big>|<big>{{PAGENAME}}</big>}} |- {{#if: {{{STATUS|}}}| {{!}} style="vertical-align:top;" {{!}}Status {{!}} {{{STATUS}}} |- {{#if: {{{MENUCONFIG|}}}| {{!}} style="vertical-align:top;" {{!}}menuconfig {{!}} {{{MENUCONFIG}}} }} |- {{#if: {{{PINNING|}}}| {{!}} style="vertical-align:top;" {{!}}Pinning {{!}} {{{PINNING}}} }} |- {{#if: {{{DEPENDS|}}}| {{!}} style="vertical-align:top;" {{!}}Depends on {{!}} {{{DEPENDS}}} }} |- {{#if: {{{REQUIRES|}}}| {{!}} style="vertical-align:top;" {{!}}Requires {{!}} {{{REQUIRES}}} }} |- {{#if: {{{CODE|}}}| {{!}} style="vertical-align:top;" {{!}}Code {{!}} {{{CODE}}} }} |- |}</onlyinclude> {{Module |NAME=Onewire |MENUCONFIG=I/O->Onewire support |STATUS=stable |PINNING=yes |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} 84b4754bec4d6f2bf3f69213b9d4cf529c1a9cf9 19 18 2011-09-19T21:46:32Z Mgue 312 wikitext text/x-wiki <onlyinclude>{| class="wikitable float-right" style="width:330px; font-size:95%;margin-top:0px;" !colspan="2" style="background-color:#CEDAF2; text-align:center"| {{#if: {{{NAME|}}}|<big>{{{NAME}}}</big>|<big>{{PAGENAME}}</big>}} |- {{#if: {{{STATUS|}}}| {{!}} style="vertical-align:top;" {{!}}Status {{!}} {{{STATUS}}} }} |- {{#if: {{{MENUCONFIG|}}}| {{!}} style="vertical-align:top;" {{!}}menuconfig {{!}} {{{MENUCONFIG}}} }} |- {{#if: {{{PINNING|}}}| {{!}} style="vertical-align:top;" {{!}}Pinning {{!}} {{{PINNING}}} }} |- {{#if: {{{DEPENDS|}}}| {{!}} style="vertical-align:top;" {{!}}Depends on {{!}} {{{DEPENDS}}} }} |- {{#if: {{{REQUIRES|}}}| {{!}} style="vertical-align:top;" {{!}}Requires {{!}} {{{REQUIRES}}} }} |- {{#if: {{{CODE|}}}| {{!}} style="vertical-align:top;" {{!}}Code {{!}} {{{CODE}}} }} |- |}</onlyinclude> {{Module |NAME=Onewire |MENUCONFIG=I/O->Onewire support |STATUS=stable |PINNING=yes |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} 43627172fb989d9ee951aa150b0c9cf0d243ca90 20 19 2011-09-19T21:58:14Z Mgue 312 corrected example wikitext text/x-wiki <onlyinclude>{| class="wikitable float-right" style="width:330px; font-size:95%;margin-top:0px;" !colspan="2" style="background-color:#CEDAF2; text-align:center"| {{#if: {{{NAME|}}}|<big>{{{NAME}}}</big>|<big>{{PAGENAME}}</big>}} |- {{#if: {{{STATUS|}}}| {{!}} style="vertical-align:top;" {{!}}Status {{!}} {{{STATUS}}} }} |- {{#if: {{{MENUCONFIG|}}}| {{!}} style="vertical-align:top;" {{!}}menuconfig {{!}} {{{MENUCONFIG}}} }} |- {{#if: {{{PINNING|}}}| {{!}} style="vertical-align:top;" {{!}}Pinning {{!}} {{{PINNING}}} }} |- {{#if: {{{DEPENDS|}}}| {{!}} style="vertical-align:top;" {{!}}Depends on {{!}} {{{DEPENDS}}} }} |- {{#if: {{{REQUIRES|}}}| {{!}} style="vertical-align:top;" {{!}}Requires {{!}} {{{REQUIRES}}} }} |- {{#if: {{{CODE|}}}| {{!}} style="vertical-align:top;" {{!}}Code {{!}} {{{CODE}}} }} |- |}</onlyinclude> {{Module |NAME=Onewire |MENUCONFIG=I/O->Onewire support |STATUS=stable |PINNING=yes |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} efa666326272adf0ac4936e1659771e0fae564ff 21 20 2011-09-20T13:05:36Z Mgue 312 style wikitext text/x-wiki <onlyinclude>{| style="float:right;margin:1em 0 1em 1em; border:1px #AAA solid;background: #f9f9f9;width:330px; font-size:95%;margin-top:0px;" !colspan="2" style="background-color:#CEDAF2; text-align:center"| {{#if: {{{NAME|}}}|<big>{{{NAME}}}</big>|<big>{{PAGENAME}}</big>}} |- {{#if: {{{STATUS|}}}| {{!}} style="vertical-align:top;" {{!}}Status {{!}} {{{STATUS}}} }} |- {{#if: {{{MENUCONFIG|}}}| {{!}} style="vertical-align:top;" {{!}}menuconfig {{!}} {{{MENUCONFIG}}} }} |- {{#if: {{{PINNING|}}}| {{!}} style="vertical-align:top;" {{!}}Pinning {{!}} {{{PINNING}}} }} |- {{#if: {{{DEPENDS|}}}| {{!}} style="vertical-align:top;" {{!}}Depends on {{!}} {{{DEPENDS}}} }} |- {{#if: {{{REQUIRES|}}}| {{!}} style="vertical-align:top;" {{!}}Requires {{!}} {{{REQUIRES}}} }} |- {{#if: {{{CODE|}}}| {{!}} style="vertical-align:top;" {{!}}Code {{!}} {{{CODE}}} }} |- |}</onlyinclude> {{Module |NAME=Onewire |MENUCONFIG=I/O->Onewire support |STATUS=stable |PINNING=yes |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} e74bbadf9ccf782f2ede4d831c874f5a44706ae6 26 21 2011-09-20T14:40:11Z Mgue 312 wikitext text/x-wiki <onlyinclude>{| style="float:right;margin:1em 0 1em 1em; border:1px #AAA solid;background: #f9f9f9;width:330px; font-size:95%;margin-top:0px;" !colspan="2" style="background-color:#CEDAF2; text-align:center"| {{#if: {{{NAME|}}}|<big>{{{NAME}}}</big>|<big>{{PAGENAME}}</big>}} |- {{#if: {{{STATUS|}}}| {{!}} style="vertical-align:top;" {{!}}Status {{!}} {{{STATUS}}} }} |- {{#if: {{{MENUCONFIG|}}}| {{!}} style="vertical-align:top;" {{!}}menuconfig {{!}} {{{MENUCONFIG}}} }} |- {{#if: {{{PINNING|}}}| {{!}} style="vertical-align:top;" {{!}}Pinning {{!}} {{{PINNING}}} }} |- {{#if: {{{DEPENDS|}}}| {{!}} style="vertical-align:top;" {{!}}Depends on {{!}} {{{DEPENDS}}} }} |- {{#if: {{{REQUIRES|}}}| {{!}} style="vertical-align:top;" {{!}}Requires {{!}} {{{REQUIRES}}} }} |- {{#if: {{{CODE|}}}| {{!}} style="vertical-align:top;" {{!}}Code {{!}} {{{CODE}}} }} |- |}</onlyinclude> {{Module |NAME=Onewire |MENUCONFIG=I/O->Onewire support |STATUS={{stable}} |PINNING=yes |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} f8d7488ec79904c3435c4ba516cddc2da89c3914 32 26 2011-09-20T17:13:31Z Mgue 312 Docu wikitext text/x-wiki <onlyinclude>{| style="float:right;margin:1em 0 1em 1em; border:1px #AAA solid;background: #f9f9f9;width:330px; font-size:95%;margin-top:0px;" !colspan="2" style="background-color:#CEDAF2; text-align:center"| {{#if: {{{NAME|}}}|<big>{{{NAME}}}</big>|<big>{{PAGENAME}}</big>}} |- {{#if: {{{STATUS|}}}| {{!}} style="vertical-align:top;" {{!}}Status {{!}} {{{STATUS}}} }} |- {{#if: {{{MENUCONFIG|}}}| {{!}} style="vertical-align:top;" {{!}}menuconfig {{!}} {{{MENUCONFIG}}} }} |- {{#if: {{{PINNING|}}}| {{!}} style="vertical-align:top;" {{!}}Pinning {{!}} {{{PINNING}}} }} |- {{#if: {{{DEPENDS|}}}| {{!}} style="vertical-align:top;" {{!}}Depends on {{!}} {{{DEPENDS}}} }} |- {{#if: {{{REQUIRES|}}}| {{!}} style="vertical-align:top;" {{!}}Requires {{!}} {{{REQUIRES}}} }} |- {{#if: {{{CODE|}}}| {{!}} style="vertical-align:top;" {{!}}Code {{!}} {{{CODE}}} }} |- |}</onlyinclude> == Arguments for STATUS == {| style="width:50%" |- | {{Codeline|<nowiki>{{stable}}</nowiki>}} {{stable}} {{Codeline|<nowiki>{{In_Development}}</nowiki>}} {{In Development}} {{Codeline|<nowiki>{{Unstable}}</nowiki>}} {{Unstable}} {{Codeline|<nowiki>{{Deprecated}}</nowiki>}} {{Deprecated}} |} == Example == <pre><nowiki> {{Module |NAME=Onewire |MENUCONFIG=I/O->Onewire support |STATUS={{stable}} |PINNING=yes |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }}</nowiki></pre> == Result == {{Module |NAME=Onewire |MENUCONFIG=I/O->Onewire support |STATUS={{stable}} |PINNING=yes |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} fa8d85b76f61d9f265477477faa490ba232eff72 42 32 2011-09-20T23:16:55Z Mgue 312 wikitext text/x-wiki <onlyinclude>{| style="float:right;margin:1em 0 1em 1em; border:1px #AAA solid;background: #f9f9f9;width:330px; font-size:95%;margin-top:0px;" !colspan="2" style="background-color:#CEDAF2; text-align:center"| {{#if: {{{NAME|}}}|<big>{{{NAME}}}</big>|<big>{{PAGENAME}}</big>}} |- {{#if: {{{STATUS|}}}| {{!}} style="vertical-align:top;" {{!}}Status {{!}} {{{STATUS}}} }} |- {{#if: {{{MENUCONFIG|}}}| {{!}} style="vertical-align:top;" {{!}}menuconfig {{!}} {{{MENUCONFIG}}} }} |- {{#if: {{{PINNING|}}}| {{!}} style="vertical-align:top;" {{!}}Pinning {{!}} {{{PINNING}}} }} |- {{#if: {{{DEPENDS|}}}| {{!}} style="vertical-align:top;" {{!}}Depends on {{!}} {{{DEPENDS}}} }} |- {{#if: {{{REQUIRES|}}}| {{!}} style="vertical-align:top;" {{!}}Requires {{!}} {{{REQUIRES}}} }} |- {{#if: {{{CODE|}}}| {{!}} style="vertical-align:top;" {{!}}Code {{!}} {{{CODE}}} }} |- |}</onlyinclude> == Arguments for STATUS == {| style="width:50%" |- | {{Codeline|<nowiki>{{stable}}</nowiki>}} {{stable}} {{Codeline|<nowiki>{{In_Development}}</nowiki>}} {{In Development}} {{Codeline|<nowiki>{{Unstable}}</nowiki>}} {{Unstable}} {{Codeline|<nowiki>{{Deprecated}}</nowiki>}} {{Deprecated}} |} == Templates for menuconfig == If you use one of the following templates, the module will automatically added to the proper category {{Codeline|<nowiki>{{I/O}}</nowiki>}} {{Codeline|<nowiki>{{Protocols}}</nowiki>}} {{Codeline|<nowiki>{{Applications}}</nowiki>}} == Example == <pre><nowiki> {{Module |NAME=Onewire |MENUCONFIG={{I/O}}->Onewire support |STATUS={{stable}} |PINNING=yes |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }}</nowiki></pre> == Result == {{Module |NAME=Onewire |MENUCONFIG={{I/O}}->Onewire support |STATUS={{stable}} |PINNING=yes |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} 94136190bd2f95f37e5ee7e6d67aeec3809aa592 43 42 2011-09-20T23:17:08Z Mgue 312 wikitext text/x-wiki <onlyinclude>{| style="float:right;margin:1em 0 1em 1em; border:1px #AAA solid;background: #f9f9f9;width:330px; font-size:95%;margin-top:0px;" !colspan="2" style="background-color:#CEDAF2; text-align:center"| {{#if: {{{NAME|}}}|<big>{{{NAME}}}</big>|<big>{{PAGENAME}}</big>}} |- {{#if: {{{STATUS|}}}| {{!}} style="vertical-align:top;" {{!}}Status {{!}} {{{STATUS}}} }} |- {{#if: {{{MENUCONFIG|}}}| {{!}} style="vertical-align:top;" {{!}}menuconfig {{!}} {{{MENUCONFIG}}} }} |- {{#if: {{{PINNING|}}}| {{!}} style="vertical-align:top;" {{!}}Pinning {{!}} {{{PINNING}}} }} |- {{#if: {{{DEPENDS|}}}| {{!}} style="vertical-align:top;" {{!}}Depends on {{!}} {{{DEPENDS}}} }} |- {{#if: {{{REQUIRES|}}}| {{!}} style="vertical-align:top;" {{!}}Requires {{!}} {{{REQUIRES}}} }} |- {{#if: {{{CODE|}}}| {{!}} style="vertical-align:top;" {{!}}Code {{!}} {{{CODE}}} }} |- |}</onlyinclude> == Arguments for STATUS == {| style="width:50%" |- | {{Codeline|<nowiki>{{stable}}</nowiki>}} {{stable}} {{Codeline|<nowiki>{{In_Development}}</nowiki>}} {{In Development}} {{Codeline|<nowiki>{{Unstable}}</nowiki>}} {{Unstable}} {{Codeline|<nowiki>{{Deprecated}}</nowiki>}} {{Deprecated}} |} == Templates for menuconfig == If you use one of the following templates, the module will automatically added to the proper category {{Codeline|<nowiki>{{I/O}}</nowiki>}} {{Codeline|<nowiki>{{Protocols}}</nowiki>}} {{Codeline|<nowiki>{{Applications}}</nowiki>}} == Example == <pre><nowiki> {{Module |NAME=Onewire |MENUCONFIG={{I/O}}->Onewire support |STATUS={{stable}} |PINNING=yes |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }}</nowiki></pre> == Result == {{Module |NAME=Onewire |MENUCONFIG={{I/O}}->Onewire support |STATUS={{stable}} |PINNING=yes |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} facef63c7e591ce9b4eaf76988be64f189a3a56f 48 43 2011-10-04T17:51:17Z Mgue 312 wikitext text/x-wiki <onlyinclude>{| style="float:right;margin:1em 0 1em 1em; border:1px #AAA solid;background: #f9f9f9;width:330px; font-size:95%;margin-top:0px;" !colspan="2" style="background-color:#CEDAF2; text-align:center"| {{#if: {{{NAME|}}}|<big>{{{NAME}}}</big>|<big>{{PAGENAME}}</big>}} |- {{#if: {{{STATUS|}}}| {{!}} style="vertical-align:top;" {{!}}Status {{!}} {{{STATUS}}} }} |- {{#if: {{{MENUCONFIG|}}}| {{!}} style="vertical-align:top;" {{!}}menuconfig {{!}} {{{MENUCONFIG}}} }} |- {{#if: {{{PINNING|}}}| {{!}} style="vertical-align:top;" {{!}}Pinning {{!}} {{{PINNING}}} }} |- {{#if: {{{DEPENDS|}}}| {{!}} style="vertical-align:top;" {{!}}Depends on {{!}} {{{DEPENDS}}} }} |- {{#if: {{{REQUIRES|}}}| {{!}} style="vertical-align:top;" {{!}}Requires {{!}} {{{REQUIRES}}} }} |- {{#if: {{{CODE|}}}| {{!}} style="vertical-align:top;" {{!}}Code {{!}} {{{CODE}}} }} |- |}</onlyinclude> == Templates for menuconfig == If you use one of the following templates, the module will automatically added to the proper category {{Codeline|<nowiki>{{I/O}}</nowiki>}} {{Codeline|<nowiki>{{Protocols}}</nowiki>}} {{Codeline|<nowiki>{{Applications}}</nowiki>}} == Templates for STATUS == {| style="width:50%" |- | {{Codeline|<nowiki>{{stable}}</nowiki>}} {{stable}} {{Codeline|<nowiki>{{In_Development}}</nowiki>}} {{In Development}} {{Codeline|<nowiki>{{Unstable}}</nowiki>}} {{Unstable}} {{Codeline|<nowiki>{{Deprecated}}</nowiki>}} {{Deprecated}} |} == Templates for ECMD == {| style="width:50%" |- | {{Codeline|<nowiki>{{has_ecmd}}</nowiki>}} {{has_ecmd}} {{Codeline|<nowiki>-</nowiki>}} |} == Example == <pre><nowiki> {{Module |NAME=Onewire |MENUCONFIG={{I/O}}->Onewire support |STATUS={{stable}} |PINNING=yes |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }}</nowiki></pre> == Result == {{Module |NAME=Onewire |MENUCONFIG={{I/O}}->Onewire support |STATUS={{stable}} |PINNING=yes |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} c24ab60bf2e7c2f5e6966135d8d6a151e70b5b5e 50 48 2011-10-04T17:53:24Z Mgue 312 wikitext text/x-wiki <onlyinclude>{| style="float:right;margin:1em 0 1em 1em; border:1px #AAA solid;background: #f9f9f9;width:330px; font-size:95%;margin-top:0px;" !colspan="2" style="background-color:#CEDAF2; text-align:center"| {{#if: {{{NAME|}}}|<big>{{{NAME}}}</big>|<big>{{PAGENAME}}</big>}} |- {{#if: {{{STATUS|}}}| {{!}} style="vertical-align:top;" {{!}}Status {{!}} {{{STATUS}}} }} |- {{#if: {{{MENUCONFIG|}}}| {{!}} style="vertical-align:top;" {{!}}menuconfig {{!}} {{{MENUCONFIG}}} }} |- {{#if: {{{PINNING|}}}| {{!}} style="vertical-align:top;" {{!}}Pinning {{!}} {{{PINNING}}} }} |- {{#if: {{{ECMD|}}}| {{!}} style="vertical-align:top;" {{!}}Ecmd {{!}} {{{ECMD}}} }} |- {{#if: {{{DEPENDS|}}}| {{!}} style="vertical-align:top;" {{!}}Depends on {{!}} {{{DEPENDS}}} }} |- {{#if: {{{REQUIRES|}}}| {{!}} style="vertical-align:top;" {{!}}Requires {{!}} {{{REQUIRES}}} }} |- {{#if: {{{CODE|}}}| {{!}} style="vertical-align:top;" {{!}}Code {{!}} {{{CODE}}} }} |- |}</onlyinclude> == Templates for menuconfig == If you use one of the following templates, the module will automatically added to the proper category {{Codeline|<nowiki>{{I/O}}</nowiki>}} {{Codeline|<nowiki>{{Protocols}}</nowiki>}} {{Codeline|<nowiki>{{Applications}}</nowiki>}} == Templates for STATUS == {| style="width:50%" |- | {{Codeline|<nowiki>{{stable}}</nowiki>}} {{stable}} {{Codeline|<nowiki>{{In_Development}}</nowiki>}} {{In Development}} {{Codeline|<nowiki>{{Unstable}}</nowiki>}} {{Unstable}} {{Codeline|<nowiki>{{Deprecated}}</nowiki>}} {{Deprecated}} |} == Templates for ECMD == {| style="width:50%" |- | {{Codeline|<nowiki>{{has_ecmd}}</nowiki>}} {{has_ecmd}} or leave blank == Example == <pre><nowiki> {{Module |NAME=Onewire |MENUCONFIG={{I/O}}->Onewire support |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }}</nowiki></pre> == Result == {{Module |NAME=Onewire |MENUCONFIG={{I/O}}->Onewire support |STATUS={{stable}} |PINNING=yes |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} 45f5703e7f797b0d23046e76288e6707b759f716 51 50 2011-10-04T17:53:48Z Mgue 312 wikitext text/x-wiki <onlyinclude>{| style="float:right;margin:1em 0 1em 1em; border:1px #AAA solid;background: #f9f9f9;width:330px; font-size:95%;margin-top:0px;" !colspan="2" style="background-color:#CEDAF2; text-align:center"| {{#if: {{{NAME|}}}|<big>{{{NAME}}}</big>|<big>{{PAGENAME}}</big>}} |- {{#if: {{{STATUS|}}}| {{!}} style="vertical-align:top;" {{!}}Status {{!}} {{{STATUS}}} }} |- {{#if: {{{MENUCONFIG|}}}| {{!}} style="vertical-align:top;" {{!}}menuconfig {{!}} {{{MENUCONFIG}}} }} |- {{#if: {{{PINNING|}}}| {{!}} style="vertical-align:top;" {{!}}Pinning {{!}} {{{PINNING}}} }} |- {{#if: {{{ECMD|}}}| {{!}} style="vertical-align:top;" {{!}}Ecmd {{!}} {{{ECMD}}} }} |- {{#if: {{{DEPENDS|}}}| {{!}} style="vertical-align:top;" {{!}}Depends on {{!}} {{{DEPENDS}}} }} |- {{#if: {{{REQUIRES|}}}| {{!}} style="vertical-align:top;" {{!}}Requires {{!}} {{{REQUIRES}}} }} |- {{#if: {{{CODE|}}}| {{!}} style="vertical-align:top;" {{!}}Code {{!}} {{{CODE}}} }} |- |}</onlyinclude> == Templates for menuconfig == If you use one of the following templates, the module will automatically added to the proper category {{Codeline|<nowiki>{{I/O}}</nowiki>}} {{Codeline|<nowiki>{{Protocols}}</nowiki>}} {{Codeline|<nowiki>{{Applications}}</nowiki>}} == Templates for STATUS == {| style="width:50%" |- | {{Codeline|<nowiki>{{stable}}</nowiki>}} {{stable}} {{Codeline|<nowiki>{{In_Development}}</nowiki>}} {{In Development}} {{Codeline|<nowiki>{{Unstable}}</nowiki>}} {{Unstable}} {{Codeline|<nowiki>{{Deprecated}}</nowiki>}} {{Deprecated}} |} == Templates for ECMD == {| style="width:50%" |- | {{Codeline|<nowiki>{{has_ecmd}}</nowiki>}} {{has_ecmd}} or leave blank == Example == <pre><nowiki> {{Module |NAME=Onewire |MENUCONFIG={{I/O}}->Onewire support |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }}</nowiki></pre> == Result == {{Module |NAME=Onewire |MENUCONFIG={{I/O}}->Onewire support |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} 41eacc88eb12118257e572a4bd950085722e0822 10 16 22 2011-09-20T14:27:48Z Mgue 312 first version wikitext text/x-wiki <div style="text-align:center;background-color: #00C406;color: #FFFFFF;">Stable</div> [[Category:Stable Module| ]] aeb9ab8fba0ddac42abdb5b60f4c6ee72f12340b 10 17 23 2011-09-20T14:37:35Z Mgue 312 Created page with "<div style="text-align:center;background-color: #09D8B9;color: #FFFFFF;">In Development</div> [[Category:Module in Development| ]]" wikitext text/x-wiki <div style="text-align:center;background-color: #09D8B9;color: #FFFFFF;">In Development</div> [[Category:Module in Development| ]] 728f9730aa39c7823a4b9d6ee7a698b739edd602 10 18 24 2011-09-20T14:38:24Z Mgue 312 Created page with "<div style="text-align:center;background-color: #C10003;color: #FFFFFF;">Unstable/Broken</div> [[Category:Broken Module| ]]" wikitext text/x-wiki <div style="text-align:center;background-color: #C10003;color: #FFFFFF;">Unstable/Broken</div> [[Category:Broken Module| ]] c6252b6915bdecb6cddc435741818fa8927c40be 10 19 25 2011-09-20T14:39:33Z Mgue 312 Created page with "<div style="text-align:center;background-color: #747474;color: #FFFFFF;">Deprecated</div> [[Category:Deprecated Module| ]]" wikitext text/x-wiki <div style="text-align:center;background-color: #747474;color: #FFFFFF;">Deprecated</div> [[Category:Deprecated Module| ]] 01477c419fdc76211c96421ca9a0fc11e1d1b573 10 20 27 2011-09-20T16:35:51Z Mgue 312 first version wikitext text/x-wiki <noinclude>{{i18n|Facts}}</noinclude> Ethersex is a firmware with network support for 8-bit AVR microcontrollers. Some of the features include * Support for atmega 8,16,32,64,128,644 and many more * Uses the common '''ENC28J60''' * TCP/IP IPv4/'''IPv6''' * OpenVPN * Software USB stack * RFM12 (433 MHz) * '''i²c''' Master (numerous chips supported)/Slave * onewire * http server * can be controlled remotely using the '''Ethersex Command Protocol (ECMD)''' * easily customizable and expandable to suit your needs 0fdb6adc2fc557d0f3a4c067268eaf431e7ba153 29 27 2011-09-20T16:45:36Z Mgue 312 wikitext text/x-wiki <noinclude>{{i18n|Facts}}</noinclude> {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | colspan=2 style="background-color: #FFFFFF; text-align: center; border-bottom:1px solid #aaaaaa;" | '''Features''' |- |Ethersex is a firmware with network support for 8-bit AVR microcontrollers. Some of the features include * Support for atmega 8,16,32,64,128,644 and many more * Uses the common '''ENC28J60''' * TCP/IP IPv4/'''IPv6''' * OpenVPN * Software USB stack * RFM12 (433 MHz) * '''i²c''' Master (numerous chips supported)/Slave * onewire * http server * can be controlled remotely using the '''Ethersex Command Protocol (ECMD)''' * easily customizable and expandable to suit your needs |} a5181850eebcb06b87cbcc94bd606a11c1eb0f8b 10 21 33 2011-09-20T23:12:41Z Mgue 312 Created page with "I/O [[Category:Hardware|]]" wikitext text/x-wiki I/O [[Category:Hardware|Hardware]] 5669928a5893b021aa4554a813f04399ab875c40 38 33 2011-09-20T23:14:36Z Mgue 312 moved [[Template:Hardware]] to [[Template:I/O]] wikitext text/x-wiki I/O [[Category:Hardware|Hardware]] 5669928a5893b021aa4554a813f04399ab875c40 44 38 2011-09-20T23:19:29Z Mgue 312 wikitext text/x-wiki [[:Category:Hardware|I/O]] [[Category:Hardware|Hardware]] 27ac69981cca171589c97621fb476c81c7cfc39d 10 22 34 2011-09-20T23:13:22Z Mgue 312 Created page with "Protocols [[Category:Protocol|]]" wikitext text/x-wiki Protocols [[Category:Protocol|Protocol]] 235605cd5ced2601af137efd2a3ed8fabf5d4a72 40 34 2011-09-20T23:14:59Z Mgue 312 moved [[Template:Protocol]] to [[Template:Protocols]] wikitext text/x-wiki Protocols [[Category:Protocol|Protocol]] 235605cd5ced2601af137efd2a3ed8fabf5d4a72 45 40 2011-09-20T23:19:52Z Mgue 312 wikitext text/x-wiki [[:Category:Protocols|Protocols]] [[Category:Protocol|Protocol]] 5cc6e629091d11802469e6bbb4f9bc2955a1cd3d 47 45 2011-09-20T23:20:39Z Mgue 312 wikitext text/x-wiki [[:Category:Protocol|Protocols]] [[Category:Protocol|Protocol]] a6467922a7fb6fc2da7bee2fdf336d62bbd11f42 10 23 35 2011-09-20T23:13:53Z Mgue 312 Created page with "Applications [[Category:Application|]]" wikitext text/x-wiki Applications [[Category:Application|Application]] 07251d557c7c10716bcb6ed18f4fcc632353b198 36 35 2011-09-20T23:14:12Z Mgue 312 moved [[Template:Application]] to [[Template:Applications]] wikitext text/x-wiki Applications [[Category:Application|Application]] 07251d557c7c10716bcb6ed18f4fcc632353b198 46 36 2011-09-20T23:20:28Z Mgue 312 wikitext text/x-wiki [[:Category:Application|Application]] [[Category:Application|Application]] 64507a1650baffb2d1e9f1063752df6c70145983 10 24 37 2011-09-20T23:14:12Z Mgue 312 moved [[Template:Application]] to [[Template:Applications]] wikitext text/x-wiki #REDIRECT [[Template:Applications]] 555d33e9086c949238f8dc18eccf655f430487e0 10 25 39 2011-09-20T23:14:36Z Mgue 312 moved [[Template:Hardware]] to [[Template:I/O]] wikitext text/x-wiki #REDIRECT [[Template:I/O]] 63649cedb0fe4f00a4e502acf69100441b6716a6 10 26 41 2011-09-20T23:14:59Z Mgue 312 moved [[Template:Protocol]] to [[Template:Protocols]] wikitext text/x-wiki #REDIRECT [[Template:Protocols]] f0929b25c8f75ddbb07d296e015c236d82ca656c 10 27 49 2011-10-04T17:51:56Z Mgue 312 Created page with "<div style="text-align:center;background-color: #00C406;color: #FFFFFF;">yes</div> [[Category:Module with ECMD| ]]" wikitext text/x-wiki <div style="text-align:center;background-color: #00C406;color: #FFFFFF;">yes</div> [[Category:Module with ECMD| ]] 248dfed724049df997ad8b8d8a21165396314402 10 23 52 46 2011-10-04T17:57:21Z Mgue 312 wikitext text/x-wiki [[:Category:Application|Applications]] [[Category:Application|Application]] 248ee01becf56be1a270f2cc6d1668bfed69581e 0 28 53 2011-10-04T18:30:24Z Mgue 312 first version wikitext text/x-wiki {{Module |NAME=DMX Storage |MENUCONFIG={{Applications}}->DMX Storage |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] (optional) |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/services/dmx-storage https://github.com/ethersex/ethersex/tree/master/services/dmx-storage] }} Dmx Storage provides a database-like storage layer for DMX information. It forms the core of the [[Ethersex Lighting Architecture]]. == Modules (input) == The following modules change/alter the DMX data *[[Artnet]] *[[DMX]] (not yet implemented) *[[DMX Effect]] == Modules (output) == The following modules display/use the dmx data *[[Artnet]] *[[DMX]] *[[Starburst]] *[[Stella]] == [[ECMD]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx channels | Get channels per universe |- | dmx get | Return channel value |- | dmx set | Set channel values |- | dmx universe | Get a whole universe |- | dmx universes | Get universes |- |} 8c727f3eb08c7e8ded91d55ee9ae5f611c4d17ea 54 53 2011-10-04T19:58:50Z Mgue 312 wikitext text/x-wiki {{i18n|DMX Storage}} {{Module |NAME=DMX Storage |MENUCONFIG={{Applications}}->DMX Storage |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] (optional) |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/services/dmx-storage https://github.com/ethersex/ethersex/tree/master/services/dmx-storage] }} Dmx Storage provides a database-like storage layer for DMX information. It forms the core of the [[Ethersex Lighting Architecture]]. == Modules (input) == The following modules change/alter the DMX data *[[Artnet]] *[[DMX]] (not yet implemented) *[[DMX Effect]] == Modules (output) == The following modules display/use the dmx data *[[Artnet]] *[[DMX]] *[[Starburst]] *[[Stella]] == [[ECMD]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx channels | Get channels per universe |- | dmx get | Return channel value |- | dmx set | Set channel values |- | dmx universe | Get a whole universe |- | dmx universes | Get universes |- |} 6a574beafb6b1c1ef5f04a0920b9545d74d67385 85 54 2011-10-11T15:27:45Z Mgue 312 e6la wikitext text/x-wiki {{i18n|DMX Storage}} {{Module |NAME=DMX Storage |MENUCONFIG={{Applications}}->DMX Storage |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] (optional) |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/services/dmx-storage https://github.com/ethersex/ethersex/tree/master/services/dmx-storage] }} Dmx Storage provides a database-like storage layer for DMX information. It forms the core of the [[Ethersex Lighting Architecture]]. == Modules (input) == The following modules change/alter the DMX data *[[Artnet]] *[[DMX]] (not yet implemented) *[[DMX Effect]] == Modules (output) == The following modules display/use the dmx data *[[Artnet]] *[[DMX]] *[[Starburst]] *[[Stella]] == [[ECMD]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx channels | Get channels per universe |- | dmx get | Return channel value |- | dmx set | Set channel values |- | dmx universe | Get a whole universe |- | dmx universes | Get universes |- |} {{e6la}} 9eb72aac8cfee64bb02d7826b42fbe4a6a1daf92 86 85 2011-10-11T15:28:01Z Mgue 312 wikitext text/x-wiki {{i18n|DMX Storage}} {{Module |NAME=DMX Storage |MENUCONFIG={{Applications}}->DMX Storage |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] (optional) |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/services/dmx-storage https://github.com/ethersex/ethersex/tree/master/services/dmx-storage] }} Dmx Storage provides a database-like storage layer for DMX information. It forms the core of the [[Ethersex Lighting Architecture]]. == Modules (input) == The following modules change/alter the DMX data *[[Artnet]] *[[DMX]] (not yet implemented) *[[DMX Effect]] == Modules (output) == The following modules display/use the dmx data *[[Artnet]] *[[DMX]] *[[Starburst]] *[[Stella]] == [[ECMD]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx channels | Get channels per universe |- | dmx get | Return channel value |- | dmx set | Set channel values |- | dmx universe | Get a whole universe |- | dmx universes | Get universes |- |} [[Category:e6la]] 7bc22a7a058ea2109f0bd2742dda76e6889aec6d 0 29 55 2011-10-05T16:46:46Z GooPie4o 265 initial version wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} 77e64607827ea7c2218c8e08a8a71ef96d15db5e 71 55 2011-10-05T17:06:37Z GooPie4o 265 wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} 28d9d1ddb202e1a550efd787e0f05e16f8865529 78 71 2011-10-05T19:39:37Z 91.39.122.161 0 wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR Receivers->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} d88ddb7748bce0de33b050258389a798922964f7 82 78 2011-10-06T10:40:28Z GooPie4o 265 translation of german article wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR Receivers->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP is a port of the [http://www.mikrocontroller.net/articles/IRMP infrared multi-protocol decoder] for [[Ethersex]]. == Connection == The reception of IR signals is performed by a receiver TSOP1736 type (or similar). This may be connected to any pin. The interrogation of the pins and the decoding of the IR protocol is done in an ISR, which occupies one 8-bit timer of the ATmegas. When sending the signal with the carrier frequency of the respective IR Protocol is [[PWM]] modulated. This is another 8-bit timer of the ATmegas (OC0/OC2) is demonstrated. On the [[Etherrape]] board takes a [[NE555]] this function, ie the option ''Use external modulator for the transmitter'' is activated. It saves a timer on the [[AVR]] is set at a carrier frequency. Example of a ATMega32 from: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Meaning: * IRMP_RX - pin the IR receiver is connected to * IRMP_USE_TIMER2 - use Timer2 for receiver, Timer0 for sender (undef = reversed) * IRMP_RX_LOW_ACTIVE - the IR receiver is low-active (undef = high-active) * IRMP_RX_LED_LOW_ACTIVE - the control LED of the receiver is switched to USS (undef = switched to GND) * IRMP_TX - pin the IR sender is connected to (=output of Timer0 or Timer2, see IRMP_USE_TIMER2)<br>'''Caution: 0A to 2A if MCU with A / B channel''' * IRMP_TX_LED_LOW_ACTIVE - the control LED of the sender is switched to USS (undef = switched to GND) == Configuration == Each supported IR protocol occupies memory of code. Therefore, one should select only the required protocols. A detailed overview of the protocols are the [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail article in the mikrocontroller forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ --- Debugging Flags │ │ [ ] IRMP Debug IRMP also decodes the RC5 protocol, so that the separately [[Ethersex]] contained [[RC5]] decoder is not needed any longer. == [[ECMD]] == IRMP implements a [[ECMD]] interface for reading received and decoded IR commands and send IR commands. See [[Ecmd_Reference|ECMD reference]]. == [[Control6|Control6]] == === Output received characters via [[SYSLOG|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> IRMP_READ checks for received IR code and stores it in the variables IRMP_PROTOCOL, IRMP_ADDRESS, and IRMP_COMMAND IRMP_FLAGS. Return values ​​greater than zero indicate the validity of the variables. If IRMP_FLAGS = 1 it is a repetition. === Control of [[Stella_Light)|Stella]]/Pins by IR commands === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> The script switches the Stella channel 0 to 255 or 0, the remote control is a Denon (Protocol 8). With ''include'' access to the Stella sources granted.<br> Instead of ''"stella_setValue (STELLA_SET_IMMEDIATELY, 0, 255);"'' ''"PIN_SET (LED)"'' and ''"PIN_CLEAR (LED)"'' can be used ([[Named_PIN|named pin]]). |Named PIN]]). === Send IR commands === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 * no tx support yet dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON * no tx support yet IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Command 5678 to device 1234 will be send with one repetition using the NEC protocol. 4c7ca1bfd8c5f8ab6874707d84e92b6439f84ae9 0 30 56 2011-10-05T16:48:20Z GooPie4o 265 initial version wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} 77e64607827ea7c2218c8e08a8a71ef96d15db5e 57 56 2011-10-05T16:52:21Z GooPie4o 265 wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP ist eine Portierung des [http://www.mikrocontroller.net/articles/IRMP Infrarot-Multiprotokoll-Decoders] nach [[Ethersex]]. == Anschluss == Der Empfang der IR-Signale erfolgt durch einen Empfänger vom Typ TSOP1736 (oder ähnlich). Dieser kann an einem beliebigen Pin angeschlossen werden. Die Abfrage des Pins und die Dekodierung des IR-Protokolls erfolgt in einer ISR, die einen 8-Bit-Timer des ATMEGAs belegt. Beim Senden wird das Signal mit der Trägerfrequenz des jeweiligen IR-Protokolls über [[PWM]] moduliert. Dazu wird ein weiterer 8-Bit Timer des ATMEGAs (OC0/OC2) belegt. Auf dem '''[[Etherape]]'''-Board übernimmt ein [[NE555]] diese Funktion, d.h. die Option ''Use external modulator for sender'' ist zu aktivieren. Man spart einen Timer des [[AVR]] und ist auf eine Trägerfrequenz festgelegt. Beispiel für einen ATMega32 aus: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Bedeutung: * IRMP_RX - Pin an dem der IR-Empfänger angeschlossen ist * IRMP_USE_TIMER2 - benutze Timer2 für den Empfang, Timer0 für das Senden (undef = umgekehrt) * IRMP_RX_LOW_ACTIVE - der IR-Empfänger ist Low-Akriv (undef = High-aktiv) * IRMP_RX_LED_LOW_ACTIVE - die Kontroll-LED des Empfängers ist gegen USS geschaltet (undef = gegen GND geschaltet) * IRMP_TX - Pin an dem der IR-Sender angschlossen ist (=Ausgang des Timer0 oder Timer2, vgl. IRMP_USE_TIMER2)<br>'''Achtung: 0A bzw 2A bei MCU mit A/B Kanal''' * IRMP_TX_LED_LOW_ACTIVE - die Kontroll-LED des Senders ist gegen USS geschaltet (undef = gegen GND geschaltet) == Konfiguration == Jedes unterstützte IR-Protokoll "verbrät" Speicher an Code. Deshalb sollte man nur die benötigten Protokolle auswählen. Eine detailierte Übersicht über die Protokolle gibt der [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail Artikel im Mikrocontroller Forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ --- Debugging Flags │ │ [ ] IRMP Debug IRMP dekodiert auch das RC5-Protokoll, so dass der separat in [[Ethersex]] enthaltene [[RC5]]-Dekoder nicht länger benötigt wird. == [[ECMD]] == IRMP implementiert eine [[ECMD]] Schnittestelle zum Auslesen empfangener und dekodierter IR-Kommandos und zum Senden von IR-Kommandos. Siehe [[Ecmd_Reference|ECMD Referenz]]. == [[Control6]] == === Ausgabe empfangener IR-Zeichen via [[SYSLOG|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> Mit IRMP_READ wird auf empfangenen IR-Code geprüft und dieser in die Variablen IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND und IRMP_FLAGS gespeichert. Rückgabewerte größer Null signalisieren die Gültigkeit der Variablen. Bei IRMP_FLAGS=1 handelt es sich um eine Wiederholung. === Steuern von [[Stella_Light|Stella]]/Pins durch IR-Zeichen === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> Das Script schaltet den Stella Channel 0 auf 255 oder auf 0, die Fernbedienung ist hier eine Denon (Protocol 8). Mit ''include'' wurde dem Script der Zugriff auf die Stellasourcen gestattet.<br> Statt ''"stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255);"'' kann auch ''"PIN_SET(LED)"'' und ''"PIN_CLEAR(LED)"'' verwendet werden ([[Named_PIN|Named PIN]]). === Senden von IR-Zeichen === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 * no tx support yet dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON * no tx support yet IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Kommando 5678 an Gerät 1234 wird mit einer Wiederholung im NEC-Protokoll gesendet. e2150e1ada763ac9ad498e03e7e85e4494c144a4 58 57 2011-10-05T16:55:55Z GooPie4o 265 /* Anschluss */ wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP ist eine Portierung des [http://www.mikrocontroller.net/articles/IRMP Infrarot-Multiprotokoll-Decoders] nach [[Ethersex]]. == Anschluss == Der Empfang der IR-Signale erfolgt durch einen Empfänger vom Typ TSOP1736 (oder ähnlich). Dieser kann an einem beliebigen Pin angeschlossen werden. Die Abfrage des Pins und die Dekodierung des IR-Protokolls erfolgt in einer ISR, die einen 8-Bit-Timer des ATMEGAs belegt. Beim Senden wird das Signal mit der Trägerfrequenz des jeweiligen IR-Protokolls über [[PWM_(Deutsch)]] moduliert. Dazu wird ein weiterer 8-Bit Timer des ATMEGAs (OC0/OC2) belegt. Auf dem '''[[Etherape_(Deutsch)]]'''-Board übernimmt ein [[NE555_(Deutsch)]] diese Funktion, d.h. die Option ''Use external modulator for sender'' ist zu aktivieren. Man spart einen Timer des [[AVR_(Deutsch)]] und ist auf eine Trägerfrequenz festgelegt. Beispiel für einen ATMega32 aus: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Bedeutung: * IRMP_RX - Pin an dem der IR-Empfänger angeschlossen ist * IRMP_USE_TIMER2 - benutze Timer2 für den Empfang, Timer0 für das Senden (undef = umgekehrt) * IRMP_RX_LOW_ACTIVE - der IR-Empfänger ist Low-Akriv (undef = High-aktiv) * IRMP_RX_LED_LOW_ACTIVE - die Kontroll-LED des Empfängers ist gegen USS geschaltet (undef = gegen GND geschaltet) * IRMP_TX - Pin an dem der IR-Sender angschlossen ist (=Ausgang des Timer0 oder Timer2, vgl. IRMP_USE_TIMER2)<br>'''Achtung: 0A bzw 2A bei MCU mit A/B Kanal''' * IRMP_TX_LED_LOW_ACTIVE - die Kontroll-LED des Senders ist gegen USS geschaltet (undef = gegen GND geschaltet) == Konfiguration == Jedes unterstützte IR-Protokoll "verbrät" Speicher an Code. Deshalb sollte man nur die benötigten Protokolle auswählen. Eine detailierte Übersicht über die Protokolle gibt der [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail Artikel im Mikrocontroller Forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ --- Debugging Flags │ │ [ ] IRMP Debug IRMP dekodiert auch das RC5-Protokoll, so dass der separat in [[Ethersex]] enthaltene [[RC5]]-Dekoder nicht länger benötigt wird. == [[ECMD]] == IRMP implementiert eine [[ECMD]] Schnittestelle zum Auslesen empfangener und dekodierter IR-Kommandos und zum Senden von IR-Kommandos. Siehe [[Ecmd_Reference|ECMD Referenz]]. == [[Control6]] == === Ausgabe empfangener IR-Zeichen via [[SYSLOG|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> Mit IRMP_READ wird auf empfangenen IR-Code geprüft und dieser in die Variablen IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND und IRMP_FLAGS gespeichert. Rückgabewerte größer Null signalisieren die Gültigkeit der Variablen. Bei IRMP_FLAGS=1 handelt es sich um eine Wiederholung. === Steuern von [[Stella_Light|Stella]]/Pins durch IR-Zeichen === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> Das Script schaltet den Stella Channel 0 auf 255 oder auf 0, die Fernbedienung ist hier eine Denon (Protocol 8). Mit ''include'' wurde dem Script der Zugriff auf die Stellasourcen gestattet.<br> Statt ''"stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255);"'' kann auch ''"PIN_SET(LED)"'' und ''"PIN_CLEAR(LED)"'' verwendet werden ([[Named_PIN|Named PIN]]). === Senden von IR-Zeichen === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 * no tx support yet dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON * no tx support yet IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Kommando 5678 an Gerät 1234 wird mit einer Wiederholung im NEC-Protokoll gesendet. 2e8eaa53adac00e6ebeef03028df0339a5a11706 59 58 2011-10-05T16:57:07Z GooPie4o 265 /* Anschluss */ wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP ist eine Portierung des [http://www.mikrocontroller.net/articles/IRMP Infrarot-Multiprotokoll-Decoders] nach [[Ethersex]]. == Anschluss == Der Empfang der IR-Signale erfolgt durch einen Empfänger vom Typ TSOP1736 (oder ähnlich). Dieser kann an einem beliebigen Pin angeschlossen werden. Die Abfrage des Pins und die Dekodierung des IR-Protokolls erfolgt in einer ISR, die einen 8-Bit-Timer des ATMEGAs belegt. Beim Senden wird das Signal mit der Trägerfrequenz des jeweiligen IR-Protokolls über [[PWM_(Deutsch)|PWM]] moduliert. Dazu wird ein weiterer 8-Bit Timer des ATMEGAs (OC0/OC2) belegt. Auf dem '''[[Etherape_(Deutsch)|Etherrape]]'''-Board übernimmt ein [[NE555_(Deutsch)|NE555]] diese Funktion, d.h. die Option ''Use external modulator for sender'' ist zu aktivieren. Man spart einen Timer des [[AVR_(Deutsch)|AVR]] und ist auf eine Trägerfrequenz festgelegt. Beispiel für einen ATMega32 aus: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Bedeutung: * IRMP_RX - Pin an dem der IR-Empfänger angeschlossen ist * IRMP_USE_TIMER2 - benutze Timer2 für den Empfang, Timer0 für das Senden (undef = umgekehrt) * IRMP_RX_LOW_ACTIVE - der IR-Empfänger ist Low-Akriv (undef = High-aktiv) * IRMP_RX_LED_LOW_ACTIVE - die Kontroll-LED des Empfängers ist gegen USS geschaltet (undef = gegen GND geschaltet) * IRMP_TX - Pin an dem der IR-Sender angschlossen ist (=Ausgang des Timer0 oder Timer2, vgl. IRMP_USE_TIMER2)<br>'''Achtung: 0A bzw 2A bei MCU mit A/B Kanal''' * IRMP_TX_LED_LOW_ACTIVE - die Kontroll-LED des Senders ist gegen USS geschaltet (undef = gegen GND geschaltet) == Konfiguration == Jedes unterstützte IR-Protokoll "verbrät" Speicher an Code. Deshalb sollte man nur die benötigten Protokolle auswählen. Eine detailierte Übersicht über die Protokolle gibt der [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail Artikel im Mikrocontroller Forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ --- Debugging Flags │ │ [ ] IRMP Debug IRMP dekodiert auch das RC5-Protokoll, so dass der separat in [[Ethersex]] enthaltene [[RC5]]-Dekoder nicht länger benötigt wird. == [[ECMD]] == IRMP implementiert eine [[ECMD]] Schnittestelle zum Auslesen empfangener und dekodierter IR-Kommandos und zum Senden von IR-Kommandos. Siehe [[Ecmd_Reference|ECMD Referenz]]. == [[Control6]] == === Ausgabe empfangener IR-Zeichen via [[SYSLOG|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> Mit IRMP_READ wird auf empfangenen IR-Code geprüft und dieser in die Variablen IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND und IRMP_FLAGS gespeichert. Rückgabewerte größer Null signalisieren die Gültigkeit der Variablen. Bei IRMP_FLAGS=1 handelt es sich um eine Wiederholung. === Steuern von [[Stella_Light|Stella]]/Pins durch IR-Zeichen === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> Das Script schaltet den Stella Channel 0 auf 255 oder auf 0, die Fernbedienung ist hier eine Denon (Protocol 8). Mit ''include'' wurde dem Script der Zugriff auf die Stellasourcen gestattet.<br> Statt ''"stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255);"'' kann auch ''"PIN_SET(LED)"'' und ''"PIN_CLEAR(LED)"'' verwendet werden ([[Named_PIN|Named PIN]]). === Senden von IR-Zeichen === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 * no tx support yet dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON * no tx support yet IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Kommando 5678 an Gerät 1234 wird mit einer Wiederholung im NEC-Protokoll gesendet. 9895d8c17ff550a7e8b09bc2699dc79603514509 62 59 2011-10-05T17:00:57Z GooPie4o 265 /* Konfiguration */ wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP ist eine Portierung des [http://www.mikrocontroller.net/articles/IRMP Infrarot-Multiprotokoll-Decoders] nach [[Ethersex]]. == Anschluss == Der Empfang der IR-Signale erfolgt durch einen Empfänger vom Typ TSOP1736 (oder ähnlich). Dieser kann an einem beliebigen Pin angeschlossen werden. Die Abfrage des Pins und die Dekodierung des IR-Protokolls erfolgt in einer ISR, die einen 8-Bit-Timer des ATMEGAs belegt. Beim Senden wird das Signal mit der Trägerfrequenz des jeweiligen IR-Protokolls über [[PWM_(Deutsch)|PWM]] moduliert. Dazu wird ein weiterer 8-Bit Timer des ATMEGAs (OC0/OC2) belegt. Auf dem '''[[Etherape_(Deutsch)|Etherrape]]'''-Board übernimmt ein [[NE555_(Deutsch)|NE555]] diese Funktion, d.h. die Option ''Use external modulator for sender'' ist zu aktivieren. Man spart einen Timer des [[AVR_(Deutsch)|AVR]] und ist auf eine Trägerfrequenz festgelegt. Beispiel für einen ATMega32 aus: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Bedeutung: * IRMP_RX - Pin an dem der IR-Empfänger angeschlossen ist * IRMP_USE_TIMER2 - benutze Timer2 für den Empfang, Timer0 für das Senden (undef = umgekehrt) * IRMP_RX_LOW_ACTIVE - der IR-Empfänger ist Low-Akriv (undef = High-aktiv) * IRMP_RX_LED_LOW_ACTIVE - die Kontroll-LED des Empfängers ist gegen USS geschaltet (undef = gegen GND geschaltet) * IRMP_TX - Pin an dem der IR-Sender angschlossen ist (=Ausgang des Timer0 oder Timer2, vgl. IRMP_USE_TIMER2)<br>'''Achtung: 0A bzw 2A bei MCU mit A/B Kanal''' * IRMP_TX_LED_LOW_ACTIVE - die Kontroll-LED des Senders ist gegen USS geschaltet (undef = gegen GND geschaltet) == Konfiguration == Jedes unterstützte IR-Protokoll "verbrät" Speicher an Code. Deshalb sollte man nur die benötigten Protokolle auswählen. Eine detailierte Übersicht über die Protokolle gibt der [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail Artikel im Mikrocontroller Forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ --- Debugging Flags │ │ [ ] IRMP Debug IRMP dekodiert auch das RC5-Protokoll, so dass der separat in [[Ethersex_(Deutsch)|Ethersex]] enthaltene [[RC5_(Deutsch)|RC5]]-Dekoder nicht länger benötigt wird. == [[ECMD]] == IRMP implementiert eine [[ECMD]] Schnittestelle zum Auslesen empfangener und dekodierter IR-Kommandos und zum Senden von IR-Kommandos. Siehe [[Ecmd_Reference|ECMD Referenz]]. == [[Control6]] == === Ausgabe empfangener IR-Zeichen via [[SYSLOG|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> Mit IRMP_READ wird auf empfangenen IR-Code geprüft und dieser in die Variablen IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND und IRMP_FLAGS gespeichert. Rückgabewerte größer Null signalisieren die Gültigkeit der Variablen. Bei IRMP_FLAGS=1 handelt es sich um eine Wiederholung. === Steuern von [[Stella_Light|Stella]]/Pins durch IR-Zeichen === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> Das Script schaltet den Stella Channel 0 auf 255 oder auf 0, die Fernbedienung ist hier eine Denon (Protocol 8). Mit ''include'' wurde dem Script der Zugriff auf die Stellasourcen gestattet.<br> Statt ''"stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255);"'' kann auch ''"PIN_SET(LED)"'' und ''"PIN_CLEAR(LED)"'' verwendet werden ([[Named_PIN|Named PIN]]). === Senden von IR-Zeichen === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 * no tx support yet dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON * no tx support yet IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Kommando 5678 an Gerät 1234 wird mit einer Wiederholung im NEC-Protokoll gesendet. 7a65e068fbe3a398597ef4653498e6a5090de735 63 62 2011-10-05T17:01:43Z GooPie4o 265 /* ECMD */ wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP ist eine Portierung des [http://www.mikrocontroller.net/articles/IRMP Infrarot-Multiprotokoll-Decoders] nach [[Ethersex]]. == Anschluss == Der Empfang der IR-Signale erfolgt durch einen Empfänger vom Typ TSOP1736 (oder ähnlich). Dieser kann an einem beliebigen Pin angeschlossen werden. Die Abfrage des Pins und die Dekodierung des IR-Protokolls erfolgt in einer ISR, die einen 8-Bit-Timer des ATMEGAs belegt. Beim Senden wird das Signal mit der Trägerfrequenz des jeweiligen IR-Protokolls über [[PWM_(Deutsch)|PWM]] moduliert. Dazu wird ein weiterer 8-Bit Timer des ATMEGAs (OC0/OC2) belegt. Auf dem '''[[Etherape_(Deutsch)|Etherrape]]'''-Board übernimmt ein [[NE555_(Deutsch)|NE555]] diese Funktion, d.h. die Option ''Use external modulator for sender'' ist zu aktivieren. Man spart einen Timer des [[AVR_(Deutsch)|AVR]] und ist auf eine Trägerfrequenz festgelegt. Beispiel für einen ATMega32 aus: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Bedeutung: * IRMP_RX - Pin an dem der IR-Empfänger angeschlossen ist * IRMP_USE_TIMER2 - benutze Timer2 für den Empfang, Timer0 für das Senden (undef = umgekehrt) * IRMP_RX_LOW_ACTIVE - der IR-Empfänger ist Low-Akriv (undef = High-aktiv) * IRMP_RX_LED_LOW_ACTIVE - die Kontroll-LED des Empfängers ist gegen USS geschaltet (undef = gegen GND geschaltet) * IRMP_TX - Pin an dem der IR-Sender angschlossen ist (=Ausgang des Timer0 oder Timer2, vgl. IRMP_USE_TIMER2)<br>'''Achtung: 0A bzw 2A bei MCU mit A/B Kanal''' * IRMP_TX_LED_LOW_ACTIVE - die Kontroll-LED des Senders ist gegen USS geschaltet (undef = gegen GND geschaltet) == Konfiguration == Jedes unterstützte IR-Protokoll "verbrät" Speicher an Code. Deshalb sollte man nur die benötigten Protokolle auswählen. Eine detailierte Übersicht über die Protokolle gibt der [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail Artikel im Mikrocontroller Forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ --- Debugging Flags │ │ [ ] IRMP Debug IRMP dekodiert auch das RC5-Protokoll, so dass der separat in [[Ethersex_(Deutsch)|Ethersex]] enthaltene [[RC5_(Deutsch)|RC5]]-Dekoder nicht länger benötigt wird. == [[ECMD_(Deutsch)|ECMD]] == IRMP implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle zum Auslesen empfangener und dekodierter IR-Kommandos und zum Senden von IR-Kommandos. Siehe [[Ecmd_Reference_(Deutsch)|ECMD Referenz]]. == [[Control6]] == === Ausgabe empfangener IR-Zeichen via [[SYSLOG|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> Mit IRMP_READ wird auf empfangenen IR-Code geprüft und dieser in die Variablen IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND und IRMP_FLAGS gespeichert. Rückgabewerte größer Null signalisieren die Gültigkeit der Variablen. Bei IRMP_FLAGS=1 handelt es sich um eine Wiederholung. === Steuern von [[Stella_Light|Stella]]/Pins durch IR-Zeichen === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> Das Script schaltet den Stella Channel 0 auf 255 oder auf 0, die Fernbedienung ist hier eine Denon (Protocol 8). Mit ''include'' wurde dem Script der Zugriff auf die Stellasourcen gestattet.<br> Statt ''"stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255);"'' kann auch ''"PIN_SET(LED)"'' und ''"PIN_CLEAR(LED)"'' verwendet werden ([[Named_PIN|Named PIN]]). === Senden von IR-Zeichen === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 * no tx support yet dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON * no tx support yet IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Kommando 5678 an Gerät 1234 wird mit einer Wiederholung im NEC-Protokoll gesendet. 56d258219b97644b9b522acf29c2d35d25be1bc9 64 63 2011-10-05T17:02:04Z GooPie4o 265 /* Ausgabe empfangener IR-Zeichen via Syslog */ wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP ist eine Portierung des [http://www.mikrocontroller.net/articles/IRMP Infrarot-Multiprotokoll-Decoders] nach [[Ethersex]]. == Anschluss == Der Empfang der IR-Signale erfolgt durch einen Empfänger vom Typ TSOP1736 (oder ähnlich). Dieser kann an einem beliebigen Pin angeschlossen werden. Die Abfrage des Pins und die Dekodierung des IR-Protokolls erfolgt in einer ISR, die einen 8-Bit-Timer des ATMEGAs belegt. Beim Senden wird das Signal mit der Trägerfrequenz des jeweiligen IR-Protokolls über [[PWM_(Deutsch)|PWM]] moduliert. Dazu wird ein weiterer 8-Bit Timer des ATMEGAs (OC0/OC2) belegt. Auf dem '''[[Etherape_(Deutsch)|Etherrape]]'''-Board übernimmt ein [[NE555_(Deutsch)|NE555]] diese Funktion, d.h. die Option ''Use external modulator for sender'' ist zu aktivieren. Man spart einen Timer des [[AVR_(Deutsch)|AVR]] und ist auf eine Trägerfrequenz festgelegt. Beispiel für einen ATMega32 aus: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Bedeutung: * IRMP_RX - Pin an dem der IR-Empfänger angeschlossen ist * IRMP_USE_TIMER2 - benutze Timer2 für den Empfang, Timer0 für das Senden (undef = umgekehrt) * IRMP_RX_LOW_ACTIVE - der IR-Empfänger ist Low-Akriv (undef = High-aktiv) * IRMP_RX_LED_LOW_ACTIVE - die Kontroll-LED des Empfängers ist gegen USS geschaltet (undef = gegen GND geschaltet) * IRMP_TX - Pin an dem der IR-Sender angschlossen ist (=Ausgang des Timer0 oder Timer2, vgl. IRMP_USE_TIMER2)<br>'''Achtung: 0A bzw 2A bei MCU mit A/B Kanal''' * IRMP_TX_LED_LOW_ACTIVE - die Kontroll-LED des Senders ist gegen USS geschaltet (undef = gegen GND geschaltet) == Konfiguration == Jedes unterstützte IR-Protokoll "verbrät" Speicher an Code. Deshalb sollte man nur die benötigten Protokolle auswählen. Eine detailierte Übersicht über die Protokolle gibt der [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail Artikel im Mikrocontroller Forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ --- Debugging Flags │ │ [ ] IRMP Debug IRMP dekodiert auch das RC5-Protokoll, so dass der separat in [[Ethersex_(Deutsch)|Ethersex]] enthaltene [[RC5_(Deutsch)|RC5]]-Dekoder nicht länger benötigt wird. == [[ECMD_(Deutsch)|ECMD]] == IRMP implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle zum Auslesen empfangener und dekodierter IR-Kommandos und zum Senden von IR-Kommandos. Siehe [[Ecmd_Reference_(Deutsch)|ECMD Referenz]]. == [[Control6]] == === Ausgabe empfangener IR-Zeichen via [[SYSLOG_(Deutsch)|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> Mit IRMP_READ wird auf empfangenen IR-Code geprüft und dieser in die Variablen IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND und IRMP_FLAGS gespeichert. Rückgabewerte größer Null signalisieren die Gültigkeit der Variablen. Bei IRMP_FLAGS=1 handelt es sich um eine Wiederholung. === Steuern von [[Stella_Light|Stella]]/Pins durch IR-Zeichen === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> Das Script schaltet den Stella Channel 0 auf 255 oder auf 0, die Fernbedienung ist hier eine Denon (Protocol 8). Mit ''include'' wurde dem Script der Zugriff auf die Stellasourcen gestattet.<br> Statt ''"stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255);"'' kann auch ''"PIN_SET(LED)"'' und ''"PIN_CLEAR(LED)"'' verwendet werden ([[Named_PIN|Named PIN]]). === Senden von IR-Zeichen === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 * no tx support yet dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON * no tx support yet IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Kommando 5678 an Gerät 1234 wird mit einer Wiederholung im NEC-Protokoll gesendet. 76f18f4f86b734fcc2163fb85ba01e91dc1714a2 65 64 2011-10-05T17:02:26Z GooPie4o 265 /* Steuern von Stella/Pins durch IR-Zeichen */ wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP ist eine Portierung des [http://www.mikrocontroller.net/articles/IRMP Infrarot-Multiprotokoll-Decoders] nach [[Ethersex]]. == Anschluss == Der Empfang der IR-Signale erfolgt durch einen Empfänger vom Typ TSOP1736 (oder ähnlich). Dieser kann an einem beliebigen Pin angeschlossen werden. Die Abfrage des Pins und die Dekodierung des IR-Protokolls erfolgt in einer ISR, die einen 8-Bit-Timer des ATMEGAs belegt. Beim Senden wird das Signal mit der Trägerfrequenz des jeweiligen IR-Protokolls über [[PWM_(Deutsch)|PWM]] moduliert. Dazu wird ein weiterer 8-Bit Timer des ATMEGAs (OC0/OC2) belegt. Auf dem '''[[Etherape_(Deutsch)|Etherrape]]'''-Board übernimmt ein [[NE555_(Deutsch)|NE555]] diese Funktion, d.h. die Option ''Use external modulator for sender'' ist zu aktivieren. Man spart einen Timer des [[AVR_(Deutsch)|AVR]] und ist auf eine Trägerfrequenz festgelegt. Beispiel für einen ATMega32 aus: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Bedeutung: * IRMP_RX - Pin an dem der IR-Empfänger angeschlossen ist * IRMP_USE_TIMER2 - benutze Timer2 für den Empfang, Timer0 für das Senden (undef = umgekehrt) * IRMP_RX_LOW_ACTIVE - der IR-Empfänger ist Low-Akriv (undef = High-aktiv) * IRMP_RX_LED_LOW_ACTIVE - die Kontroll-LED des Empfängers ist gegen USS geschaltet (undef = gegen GND geschaltet) * IRMP_TX - Pin an dem der IR-Sender angschlossen ist (=Ausgang des Timer0 oder Timer2, vgl. IRMP_USE_TIMER2)<br>'''Achtung: 0A bzw 2A bei MCU mit A/B Kanal''' * IRMP_TX_LED_LOW_ACTIVE - die Kontroll-LED des Senders ist gegen USS geschaltet (undef = gegen GND geschaltet) == Konfiguration == Jedes unterstützte IR-Protokoll "verbrät" Speicher an Code. Deshalb sollte man nur die benötigten Protokolle auswählen. Eine detailierte Übersicht über die Protokolle gibt der [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail Artikel im Mikrocontroller Forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ --- Debugging Flags │ │ [ ] IRMP Debug IRMP dekodiert auch das RC5-Protokoll, so dass der separat in [[Ethersex_(Deutsch)|Ethersex]] enthaltene [[RC5_(Deutsch)|RC5]]-Dekoder nicht länger benötigt wird. == [[ECMD_(Deutsch)|ECMD]] == IRMP implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle zum Auslesen empfangener und dekodierter IR-Kommandos und zum Senden von IR-Kommandos. Siehe [[Ecmd_Reference_(Deutsch)|ECMD Referenz]]. == [[Control6]] == === Ausgabe empfangener IR-Zeichen via [[SYSLOG_(Deutsch)|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> Mit IRMP_READ wird auf empfangenen IR-Code geprüft und dieser in die Variablen IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND und IRMP_FLAGS gespeichert. Rückgabewerte größer Null signalisieren die Gültigkeit der Variablen. Bei IRMP_FLAGS=1 handelt es sich um eine Wiederholung. === Steuern von [[Stella_Light_(Deutsch)|Stella]]/Pins durch IR-Zeichen === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> Das Script schaltet den Stella Channel 0 auf 255 oder auf 0, die Fernbedienung ist hier eine Denon (Protocol 8). Mit ''include'' wurde dem Script der Zugriff auf die Stellasourcen gestattet.<br> Statt ''"stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255);"'' kann auch ''"PIN_SET(LED)"'' und ''"PIN_CLEAR(LED)"'' verwendet werden ([[Named_PIN_(Deutsch)|Named PIN]]). === Senden von IR-Zeichen === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 * no tx support yet dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON * no tx support yet IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Kommando 5678 an Gerät 1234 wird mit einer Wiederholung im NEC-Protokoll gesendet. d995427528760d921f14f90ab9a5251f1d360a66 70 65 2011-10-05T17:06:26Z GooPie4o 265 wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP ist eine Portierung des [http://www.mikrocontroller.net/articles/IRMP Infrarot-Multiprotokoll-Decoders] nach [[Ethersex]]. == Anschluss == Der Empfang der IR-Signale erfolgt durch einen Empfänger vom Typ TSOP1736 (oder ähnlich). Dieser kann an einem beliebigen Pin angeschlossen werden. Die Abfrage des Pins und die Dekodierung des IR-Protokolls erfolgt in einer ISR, die einen 8-Bit-Timer des ATMEGAs belegt. Beim Senden wird das Signal mit der Trägerfrequenz des jeweiligen IR-Protokolls über [[PWM_(Deutsch)|PWM]] moduliert. Dazu wird ein weiterer 8-Bit Timer des ATMEGAs (OC0/OC2) belegt. Auf dem '''[[Etherape_(Deutsch)|Etherrape]]'''-Board übernimmt ein [[NE555_(Deutsch)|NE555]] diese Funktion, d.h. die Option ''Use external modulator for sender'' ist zu aktivieren. Man spart einen Timer des [[AVR_(Deutsch)|AVR]] und ist auf eine Trägerfrequenz festgelegt. Beispiel für einen ATMega32 aus: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Bedeutung: * IRMP_RX - Pin an dem der IR-Empfänger angeschlossen ist * IRMP_USE_TIMER2 - benutze Timer2 für den Empfang, Timer0 für das Senden (undef = umgekehrt) * IRMP_RX_LOW_ACTIVE - der IR-Empfänger ist Low-Akriv (undef = High-aktiv) * IRMP_RX_LED_LOW_ACTIVE - die Kontroll-LED des Empfängers ist gegen USS geschaltet (undef = gegen GND geschaltet) * IRMP_TX - Pin an dem der IR-Sender angschlossen ist (=Ausgang des Timer0 oder Timer2, vgl. IRMP_USE_TIMER2)<br>'''Achtung: 0A bzw 2A bei MCU mit A/B Kanal''' * IRMP_TX_LED_LOW_ACTIVE - die Kontroll-LED des Senders ist gegen USS geschaltet (undef = gegen GND geschaltet) == Konfiguration == Jedes unterstützte IR-Protokoll "verbrät" Speicher an Code. Deshalb sollte man nur die benötigten Protokolle auswählen. Eine detailierte Übersicht über die Protokolle gibt der [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail Artikel im Mikrocontroller Forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ --- Debugging Flags │ │ [ ] IRMP Debug IRMP dekodiert auch das RC5-Protokoll, so dass der separat in [[Ethersex_(Deutsch)|Ethersex]] enthaltene [[RC5_(Deutsch)|RC5]]-Dekoder nicht länger benötigt wird. == [[ECMD_(Deutsch)|ECMD]] == IRMP implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle zum Auslesen empfangener und dekodierter IR-Kommandos und zum Senden von IR-Kommandos. Siehe [[Ecmd_Reference_(Deutsch)|ECMD Referenz]]. == [[Control6]] == === Ausgabe empfangener IR-Zeichen via [[SYSLOG_(Deutsch)|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> Mit IRMP_READ wird auf empfangenen IR-Code geprüft und dieser in die Variablen IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND und IRMP_FLAGS gespeichert. Rückgabewerte größer Null signalisieren die Gültigkeit der Variablen. Bei IRMP_FLAGS=1 handelt es sich um eine Wiederholung. === Steuern von [[Stella_Light_(Deutsch)|Stella]]/Pins durch IR-Zeichen === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> Das Script schaltet den Stella Channel 0 auf 255 oder auf 0, die Fernbedienung ist hier eine Denon (Protocol 8). Mit ''include'' wurde dem Script der Zugriff auf die Stellasourcen gestattet.<br> Statt ''"stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255);"'' kann auch ''"PIN_SET(LED)"'' und ''"PIN_CLEAR(LED)"'' verwendet werden ([[Named_PIN_(Deutsch)|Named PIN]]). === Senden von IR-Zeichen === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 * no tx support yet dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON * no tx support yet IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Kommando 5678 an Gerät 1234 wird mit einer Wiederholung im NEC-Protokoll gesendet. 5c1e4f8607b884e9ee6c5d8b233b8feb2e3555c9 74 70 2011-10-05T19:33:18Z 2001:638:A00:F011:240:F4FF:FEB4:EA2D 0 /* Senden von IR-Zeichen */ wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP ist eine Portierung des [http://www.mikrocontroller.net/articles/IRMP Infrarot-Multiprotokoll-Decoders] nach [[Ethersex]]. == Anschluss == Der Empfang der IR-Signale erfolgt durch einen Empfänger vom Typ TSOP1736 (oder ähnlich). Dieser kann an einem beliebigen Pin angeschlossen werden. Die Abfrage des Pins und die Dekodierung des IR-Protokolls erfolgt in einer ISR, die einen 8-Bit-Timer des ATMEGAs belegt. Beim Senden wird das Signal mit der Trägerfrequenz des jeweiligen IR-Protokolls über [[PWM_(Deutsch)|PWM]] moduliert. Dazu wird ein weiterer 8-Bit Timer des ATMEGAs (OC0/OC2) belegt. Auf dem '''[[Etherape_(Deutsch)|Etherrape]]'''-Board übernimmt ein [[NE555_(Deutsch)|NE555]] diese Funktion, d.h. die Option ''Use external modulator for sender'' ist zu aktivieren. Man spart einen Timer des [[AVR_(Deutsch)|AVR]] und ist auf eine Trägerfrequenz festgelegt. Beispiel für einen ATMega32 aus: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Bedeutung: * IRMP_RX - Pin an dem der IR-Empfänger angeschlossen ist * IRMP_USE_TIMER2 - benutze Timer2 für den Empfang, Timer0 für das Senden (undef = umgekehrt) * IRMP_RX_LOW_ACTIVE - der IR-Empfänger ist Low-Akriv (undef = High-aktiv) * IRMP_RX_LED_LOW_ACTIVE - die Kontroll-LED des Empfängers ist gegen USS geschaltet (undef = gegen GND geschaltet) * IRMP_TX - Pin an dem der IR-Sender angschlossen ist (=Ausgang des Timer0 oder Timer2, vgl. IRMP_USE_TIMER2)<br>'''Achtung: 0A bzw 2A bei MCU mit A/B Kanal''' * IRMP_TX_LED_LOW_ACTIVE - die Kontroll-LED des Senders ist gegen USS geschaltet (undef = gegen GND geschaltet) == Konfiguration == Jedes unterstützte IR-Protokoll "verbrät" Speicher an Code. Deshalb sollte man nur die benötigten Protokolle auswählen. Eine detailierte Übersicht über die Protokolle gibt der [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail Artikel im Mikrocontroller Forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ --- Debugging Flags │ │ [ ] IRMP Debug IRMP dekodiert auch das RC5-Protokoll, so dass der separat in [[Ethersex_(Deutsch)|Ethersex]] enthaltene [[RC5_(Deutsch)|RC5]]-Dekoder nicht länger benötigt wird. == [[ECMD_(Deutsch)|ECMD]] == IRMP implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle zum Auslesen empfangener und dekodierter IR-Kommandos und zum Senden von IR-Kommandos. Siehe [[Ecmd_Reference_(Deutsch)|ECMD Referenz]]. == [[Control6]] == === Ausgabe empfangener IR-Zeichen via [[SYSLOG_(Deutsch)|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> Mit IRMP_READ wird auf empfangenen IR-Code geprüft und dieser in die Variablen IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND und IRMP_FLAGS gespeichert. Rückgabewerte größer Null signalisieren die Gültigkeit der Variablen. Bei IRMP_FLAGS=1 handelt es sich um eine Wiederholung. === Steuern von [[Stella_Light_(Deutsch)|Stella]]/Pins durch IR-Zeichen === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> Das Script schaltet den Stella Channel 0 auf 255 oder auf 0, die Fernbedienung ist hier eine Denon (Protocol 8). Mit ''include'' wurde dem Script der Zugriff auf die Stellasourcen gestattet.<br> Statt ''"stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255);"'' kann auch ''"PIN_SET(LED)"'' und ''"PIN_CLEAR(LED)"'' verwendet werden ([[Named_PIN_(Deutsch)|Named PIN]]). === Senden von IR-Zeichen === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 * no tx support yet dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON * no tx support yet IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Kommando 5678 an Gerät 1234 wird mit einer Wiederholung im NEC-Protokoll gesendet. 4843ab1b69a44752b1b7e52a7250d0a5c29209c1 75 74 2011-10-05T19:35:57Z 91.39.122.161 0 /* Control6 */ wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP ist eine Portierung des [http://www.mikrocontroller.net/articles/IRMP Infrarot-Multiprotokoll-Decoders] nach [[Ethersex]]. == Anschluss == Der Empfang der IR-Signale erfolgt durch einen Empfänger vom Typ TSOP1736 (oder ähnlich). Dieser kann an einem beliebigen Pin angeschlossen werden. Die Abfrage des Pins und die Dekodierung des IR-Protokolls erfolgt in einer ISR, die einen 8-Bit-Timer des ATMEGAs belegt. Beim Senden wird das Signal mit der Trägerfrequenz des jeweiligen IR-Protokolls über [[PWM_(Deutsch)|PWM]] moduliert. Dazu wird ein weiterer 8-Bit Timer des ATMEGAs (OC0/OC2) belegt. Auf dem '''[[Etherape_(Deutsch)|Etherrape]]'''-Board übernimmt ein [[NE555_(Deutsch)|NE555]] diese Funktion, d.h. die Option ''Use external modulator for sender'' ist zu aktivieren. Man spart einen Timer des [[AVR_(Deutsch)|AVR]] und ist auf eine Trägerfrequenz festgelegt. Beispiel für einen ATMega32 aus: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Bedeutung: * IRMP_RX - Pin an dem der IR-Empfänger angeschlossen ist * IRMP_USE_TIMER2 - benutze Timer2 für den Empfang, Timer0 für das Senden (undef = umgekehrt) * IRMP_RX_LOW_ACTIVE - der IR-Empfänger ist Low-Akriv (undef = High-aktiv) * IRMP_RX_LED_LOW_ACTIVE - die Kontroll-LED des Empfängers ist gegen USS geschaltet (undef = gegen GND geschaltet) * IRMP_TX - Pin an dem der IR-Sender angschlossen ist (=Ausgang des Timer0 oder Timer2, vgl. IRMP_USE_TIMER2)<br>'''Achtung: 0A bzw 2A bei MCU mit A/B Kanal''' * IRMP_TX_LED_LOW_ACTIVE - die Kontroll-LED des Senders ist gegen USS geschaltet (undef = gegen GND geschaltet) == Konfiguration == Jedes unterstützte IR-Protokoll "verbrät" Speicher an Code. Deshalb sollte man nur die benötigten Protokolle auswählen. Eine detailierte Übersicht über die Protokolle gibt der [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail Artikel im Mikrocontroller Forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ --- Debugging Flags │ │ [ ] IRMP Debug IRMP dekodiert auch das RC5-Protokoll, so dass der separat in [[Ethersex_(Deutsch)|Ethersex]] enthaltene [[RC5_(Deutsch)|RC5]]-Dekoder nicht länger benötigt wird. == [[ECMD_(Deutsch)|ECMD]] == IRMP implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle zum Auslesen empfangener und dekodierter IR-Kommandos und zum Senden von IR-Kommandos. Siehe [[Ecmd_Reference_(Deutsch)|ECMD Referenz]]. == [[Control6_(Deutsch)|Control6]] == === Ausgabe empfangener IR-Zeichen via [[SYSLOG_(Deutsch)|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> Mit IRMP_READ wird auf empfangenen IR-Code geprüft und dieser in die Variablen IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND und IRMP_FLAGS gespeichert. Rückgabewerte größer Null signalisieren die Gültigkeit der Variablen. Bei IRMP_FLAGS=1 handelt es sich um eine Wiederholung. === Steuern von [[Stella_Light_(Deutsch)|Stella]]/Pins durch IR-Zeichen === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> Das Script schaltet den Stella Channel 0 auf 255 oder auf 0, die Fernbedienung ist hier eine Denon (Protocol 8). Mit ''include'' wurde dem Script der Zugriff auf die Stellasourcen gestattet.<br> Statt ''"stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255);"'' kann auch ''"PIN_SET(LED)"'' und ''"PIN_CLEAR(LED)"'' verwendet werden ([[Named_PIN_(Deutsch)|Named PIN]]). === Senden von IR-Zeichen === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 * no tx support yet dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON * no tx support yet IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Kommando 5678 an Gerät 1234 wird mit einer Wiederholung im NEC-Protokoll gesendet. 515d645d582aa300470d9de8841339633ff0ba7b 76 75 2011-10-05T19:38:33Z 91.39.122.161 0 /* Senden von IR-Zeichen */ wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP ist eine Portierung des [http://www.mikrocontroller.net/articles/IRMP Infrarot-Multiprotokoll-Decoders] nach [[Ethersex]]. == Anschluss == Der Empfang der IR-Signale erfolgt durch einen Empfänger vom Typ TSOP1736 (oder ähnlich). Dieser kann an einem beliebigen Pin angeschlossen werden. Die Abfrage des Pins und die Dekodierung des IR-Protokolls erfolgt in einer ISR, die einen 8-Bit-Timer des ATMEGAs belegt. Beim Senden wird das Signal mit der Trägerfrequenz des jeweiligen IR-Protokolls über [[PWM_(Deutsch)|PWM]] moduliert. Dazu wird ein weiterer 8-Bit Timer des ATMEGAs (OC0/OC2) belegt. Auf dem '''[[Etherape_(Deutsch)|Etherrape]]'''-Board übernimmt ein [[NE555_(Deutsch)|NE555]] diese Funktion, d.h. die Option ''Use external modulator for sender'' ist zu aktivieren. Man spart einen Timer des [[AVR_(Deutsch)|AVR]] und ist auf eine Trägerfrequenz festgelegt. Beispiel für einen ATMega32 aus: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Bedeutung: * IRMP_RX - Pin an dem der IR-Empfänger angeschlossen ist * IRMP_USE_TIMER2 - benutze Timer2 für den Empfang, Timer0 für das Senden (undef = umgekehrt) * IRMP_RX_LOW_ACTIVE - der IR-Empfänger ist Low-Akriv (undef = High-aktiv) * IRMP_RX_LED_LOW_ACTIVE - die Kontroll-LED des Empfängers ist gegen USS geschaltet (undef = gegen GND geschaltet) * IRMP_TX - Pin an dem der IR-Sender angschlossen ist (=Ausgang des Timer0 oder Timer2, vgl. IRMP_USE_TIMER2)<br>'''Achtung: 0A bzw 2A bei MCU mit A/B Kanal''' * IRMP_TX_LED_LOW_ACTIVE - die Kontroll-LED des Senders ist gegen USS geschaltet (undef = gegen GND geschaltet) == Konfiguration == Jedes unterstützte IR-Protokoll "verbrät" Speicher an Code. Deshalb sollte man nur die benötigten Protokolle auswählen. Eine detailierte Übersicht über die Protokolle gibt der [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail Artikel im Mikrocontroller Forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ --- Debugging Flags │ │ [ ] IRMP Debug IRMP dekodiert auch das RC5-Protokoll, so dass der separat in [[Ethersex_(Deutsch)|Ethersex]] enthaltene [[RC5_(Deutsch)|RC5]]-Dekoder nicht länger benötigt wird. == [[ECMD_(Deutsch)|ECMD]] == IRMP implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle zum Auslesen empfangener und dekodierter IR-Kommandos und zum Senden von IR-Kommandos. Siehe [[Ecmd_Reference_(Deutsch)|ECMD Referenz]]. == [[Control6_(Deutsch)|Control6]] == === Ausgabe empfangener IR-Zeichen via [[SYSLOG_(Deutsch)|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> Mit IRMP_READ wird auf empfangenen IR-Code geprüft und dieser in die Variablen IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND und IRMP_FLAGS gespeichert. Rückgabewerte größer Null signalisieren die Gültigkeit der Variablen. Bei IRMP_FLAGS=1 handelt es sich um eine Wiederholung. === Steuern von [[Stella_Light_(Deutsch)|Stella]]/Pins durch IR-Zeichen === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> Das Script schaltet den Stella Channel 0 auf 255 oder auf 0, die Fernbedienung ist hier eine Denon (Protocol 8). Mit ''include'' wurde dem Script der Zugriff auf die Stellasourcen gestattet.<br> Statt ''"stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255);"'' kann auch ''"PIN_SET(LED)"'' und ''"PIN_CLEAR(LED)"'' verwendet werden ([[Named_PIN_(Deutsch)|Named PIN]]). === Senden von IR-Zeichen === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 * no tx support yet dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON * no tx support yet IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Kommando 5678 an Gerät 1234 wird mit einer Wiederholung im NEC-Protokoll gesendet. 0fa4df1b047c27489ae271ed0c526654bca5a78e 77 76 2011-10-05T19:39:25Z 91.39.122.161 0 wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR Receivers->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP ist eine Portierung des [http://www.mikrocontroller.net/articles/IRMP Infrarot-Multiprotokoll-Decoders] nach [[Ethersex]]. == Anschluss == Der Empfang der IR-Signale erfolgt durch einen Empfänger vom Typ TSOP1736 (oder ähnlich). Dieser kann an einem beliebigen Pin angeschlossen werden. Die Abfrage des Pins und die Dekodierung des IR-Protokolls erfolgt in einer ISR, die einen 8-Bit-Timer des ATMEGAs belegt. Beim Senden wird das Signal mit der Trägerfrequenz des jeweiligen IR-Protokolls über [[PWM_(Deutsch)|PWM]] moduliert. Dazu wird ein weiterer 8-Bit Timer des ATMEGAs (OC0/OC2) belegt. Auf dem '''[[Etherape_(Deutsch)|Etherrape]]'''-Board übernimmt ein [[NE555_(Deutsch)|NE555]] diese Funktion, d.h. die Option ''Use external modulator for sender'' ist zu aktivieren. Man spart einen Timer des [[AVR_(Deutsch)|AVR]] und ist auf eine Trägerfrequenz festgelegt. Beispiel für einen ATMega32 aus: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Bedeutung: * IRMP_RX - Pin an dem der IR-Empfänger angeschlossen ist * IRMP_USE_TIMER2 - benutze Timer2 für den Empfang, Timer0 für das Senden (undef = umgekehrt) * IRMP_RX_LOW_ACTIVE - der IR-Empfänger ist Low-Akriv (undef = High-aktiv) * IRMP_RX_LED_LOW_ACTIVE - die Kontroll-LED des Empfängers ist gegen USS geschaltet (undef = gegen GND geschaltet) * IRMP_TX - Pin an dem der IR-Sender angschlossen ist (=Ausgang des Timer0 oder Timer2, vgl. IRMP_USE_TIMER2)<br>'''Achtung: 0A bzw 2A bei MCU mit A/B Kanal''' * IRMP_TX_LED_LOW_ACTIVE - die Kontroll-LED des Senders ist gegen USS geschaltet (undef = gegen GND geschaltet) == Konfiguration == Jedes unterstützte IR-Protokoll "verbrät" Speicher an Code. Deshalb sollte man nur die benötigten Protokolle auswählen. Eine detailierte Übersicht über die Protokolle gibt der [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail Artikel im Mikrocontroller Forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ --- Debugging Flags │ │ [ ] IRMP Debug IRMP dekodiert auch das RC5-Protokoll, so dass der separat in [[Ethersex_(Deutsch)|Ethersex]] enthaltene [[RC5_(Deutsch)|RC5]]-Dekoder nicht länger benötigt wird. == [[ECMD_(Deutsch)|ECMD]] == IRMP implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle zum Auslesen empfangener und dekodierter IR-Kommandos und zum Senden von IR-Kommandos. Siehe [[Ecmd_Reference_(Deutsch)|ECMD Referenz]]. == [[Control6_(Deutsch)|Control6]] == === Ausgabe empfangener IR-Zeichen via [[SYSLOG_(Deutsch)|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> Mit IRMP_READ wird auf empfangenen IR-Code geprüft und dieser in die Variablen IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND und IRMP_FLAGS gespeichert. Rückgabewerte größer Null signalisieren die Gültigkeit der Variablen. Bei IRMP_FLAGS=1 handelt es sich um eine Wiederholung. === Steuern von [[Stella_Light_(Deutsch)|Stella]]/Pins durch IR-Zeichen === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> Das Script schaltet den Stella Channel 0 auf 255 oder auf 0, die Fernbedienung ist hier eine Denon (Protocol 8). Mit ''include'' wurde dem Script der Zugriff auf die Stellasourcen gestattet.<br> Statt ''"stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255);"'' kann auch ''"PIN_SET(LED)"'' und ''"PIN_CLEAR(LED)"'' verwendet werden ([[Named_PIN_(Deutsch)|Named PIN]]). === Senden von IR-Zeichen === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 * no tx support yet dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON * no tx support yet IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Kommando 5678 an Gerät 1234 wird mit einer Wiederholung im NEC-Protokoll gesendet. 0940ea6754d584d30fdf79c3f8bbf1e4543de18c 81 77 2011-10-06T10:24:42Z GooPie4o 265 /* Anschluss */ wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR Receivers->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP ist eine Portierung des [http://www.mikrocontroller.net/articles/IRMP Infrarot-Multiprotokoll-Decoders] nach [[Ethersex]]. == Anschluss == Der Empfang der IR-Signale erfolgt durch einen Empfänger vom Typ TSOP1736 (oder ähnlich). Dieser kann an einem beliebigen Pin angeschlossen werden. Die Abfrage des Pins und die Dekodierung des IR-Protokolls erfolgt in einer ISR, die einen 8-Bit-Timer des ATMEGAs belegt. Beim Senden wird das Signal mit der Trägerfrequenz des jeweiligen IR-Protokolls über [[PWM_(Deutsch)|PWM]] moduliert. Dazu wird ein weiterer 8-Bit Timer des ATMEGAs (OC0/OC2) belegt. Auf dem '''[[Etherape_(Deutsch)|Etherrape]]'''-Board übernimmt ein [[NE555_(Deutsch)|NE555]] diese Funktion, d.h. die Option ''Use external modulator for sender'' ist zu aktivieren. Man spart einen Timer des [[AVR_(Deutsch)|AVR]] und ist auf eine Trägerfrequenz festgelegt. Beispiel für einen ATMega32 aus: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Bedeutung: * IRMP_RX - Pin an dem der IR-Empfänger angeschlossen ist * IRMP_USE_TIMER2 - benutze Timer2 für den Empfang, Timer0 für das Senden (undef = umgekehrt) * IRMP_RX_LOW_ACTIVE - der IR-Empfänger ist Low-Aktiv (undef = High-aktiv) * IRMP_RX_LED_LOW_ACTIVE - die Kontroll-LED des Empfängers ist gegen USS geschaltet (undef = gegen GND geschaltet) * IRMP_TX - Pin an dem der IR-Sender angschlossen ist (=Ausgang des Timer0 oder Timer2, vgl. IRMP_USE_TIMER2)<br>'''Achtung: 0A bzw 2A bei MCU mit A/B Kanal''' * IRMP_TX_LED_LOW_ACTIVE - die Kontroll-LED des Senders ist gegen USS geschaltet (undef = gegen GND geschaltet) == Konfiguration == Jedes unterstützte IR-Protokoll "verbrät" Speicher an Code. Deshalb sollte man nur die benötigten Protokolle auswählen. Eine detailierte Übersicht über die Protokolle gibt der [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail Artikel im Mikrocontroller Forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ --- Debugging Flags │ │ [ ] IRMP Debug IRMP dekodiert auch das RC5-Protokoll, so dass der separat in [[Ethersex_(Deutsch)|Ethersex]] enthaltene [[RC5_(Deutsch)|RC5]]-Dekoder nicht länger benötigt wird. == [[ECMD_(Deutsch)|ECMD]] == IRMP implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle zum Auslesen empfangener und dekodierter IR-Kommandos und zum Senden von IR-Kommandos. Siehe [[Ecmd_Reference_(Deutsch)|ECMD Referenz]]. == [[Control6_(Deutsch)|Control6]] == === Ausgabe empfangener IR-Zeichen via [[SYSLOG_(Deutsch)|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> Mit IRMP_READ wird auf empfangenen IR-Code geprüft und dieser in die Variablen IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND und IRMP_FLAGS gespeichert. Rückgabewerte größer Null signalisieren die Gültigkeit der Variablen. Bei IRMP_FLAGS=1 handelt es sich um eine Wiederholung. === Steuern von [[Stella_Light_(Deutsch)|Stella]]/Pins durch IR-Zeichen === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> Das Script schaltet den Stella Channel 0 auf 255 oder auf 0, die Fernbedienung ist hier eine Denon (Protocol 8). Mit ''include'' wurde dem Script der Zugriff auf die Stellasourcen gestattet.<br> Statt ''"stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255);"'' kann auch ''"PIN_SET(LED)"'' und ''"PIN_CLEAR(LED)"'' verwendet werden ([[Named_PIN_(Deutsch)|Named PIN]]). === Senden von IR-Zeichen === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 * no tx support yet dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON * no tx support yet IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Kommando 5678 an Gerät 1234 wird mit einer Wiederholung im NEC-Protokoll gesendet. 5449d0b945d1cc8ef6f9956bd16127569fd850b8 0 31 60 2011-10-05T16:58:45Z GooPie4o 265 initial version wikitext text/x-wiki {{i18n|RC5}} {{Module |NAME=RC5 |MENUCONFIG={{I/O}}->IR->RC5 |STATUS={{deprecated}} |PINNING=yes |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/rc5 https://github.com/ethersex/ethersex/tree/master/hardware/ir/rc5] }} 14761523a4ccc8cbc6ca986032d143bc9044a2bf 73 60 2011-10-05T17:07:06Z GooPie4o 265 wikitext text/x-wiki {{i18n|RC5}} {{Module |NAME=RC5 |MENUCONFIG={{I/O}}->IR->RC5 |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |PINNING=yes |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/rc5 https://github.com/ethersex/ethersex/tree/master/hardware/ir/rc5] }} 6b38d88cf23b0de032ad86d12f20a87468301f2d 80 73 2011-10-05T19:40:28Z 91.39.122.161 0 wikitext text/x-wiki {{i18n|RC5}} {{Module |NAME=RC5 |STATUS={{deprecated}} |MENUCONFIG={{I/O}}->IR Receivers->RC5 |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |PINNING=yes |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/rc5 https://github.com/ethersex/ethersex/tree/master/hardware/ir/rc5] }} 01e212534a93950ee79a149fc60af2d1332225a3 83 80 2011-10-06T10:49:14Z GooPie4o 265 wikitext text/x-wiki {{i18n|RC5}} {{Module |NAME=RC5 |STATUS={{deprecated}} |MENUCONFIG={{I/O}}->IR Receivers->RC5 |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |PINNING=yes |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/rc5 https://github.com/ethersex/ethersex/tree/master/hardware/ir/rc5] }} RC5 ist ein von Philips entwickelter Code für Infrarot-Fernbedienungen. Ein [[Ethersex_(Deutsch)|Ethersex]]-System kann RC5-Signale sowohl empfangen und dekodieren als auch senden. Das Modul wird nicht länger gepflegt. Bitte [[IRMP_(Deutsch)|IRMP]] stattdessen verwenden. e5bbc83b9f0c529bc0085bc06cd7ef3b7838afee 0 32 61 2011-10-05T16:59:47Z GooPie4o 265 initial version wikitext text/x-wiki {{i18n|RC5}} {{Module |NAME=RC5 |MENUCONFIG={{I/O}}->IR->RC5 |STATUS={{deprecated}} |PINNING=yes |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/rc5 https://github.com/ethersex/ethersex/tree/master/hardware/ir/rc5] }} 14761523a4ccc8cbc6ca986032d143bc9044a2bf 72 61 2011-10-05T17:06:55Z GooPie4o 265 wikitext text/x-wiki {{i18n|RC5}} {{Module |NAME=RC5 |MENUCONFIG={{I/O}}->IR->RC5 |STATUS={{deprecated}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/rc5 https://github.com/ethersex/ethersex/tree/master/hardware/ir/rc5] }} 4b3df88e839190605ffee1b7b16adad212984748 79 72 2011-10-05T19:39:50Z 91.39.122.161 0 wikitext text/x-wiki {{i18n|RC5}} {{Module |NAME=RC5 |MENUCONFIG={{I/O}}->IR Receivers->RC5 |STATUS={{deprecated}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/rc5 https://github.com/ethersex/ethersex/tree/master/hardware/ir/rc5] }} 33242022258535a26ab082e2454e8373bde211e4 84 79 2011-10-06T10:52:09Z GooPie4o 265 wikitext text/x-wiki {{i18n|RC5}} {{Module |NAME=RC5 |MENUCONFIG={{I/O}}->IR Receivers->RC5 |STATUS={{deprecated}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/rc5 https://github.com/ethersex/ethersex/tree/master/hardware/ir/rc5] }} RC5 is a code for infrared remote controlsdeveloped by Philips. A [[Ethersex]] system can receive and decode RC5 signals and transmit RC5 signals. The module is not maintained anymore. Please use [[IRMP]] instead. c321fa07289032f694f6b12fa8acbf31311058ca 10 15 66 51 2011-10-05T17:02:42Z Mgue 312 wikitext text/x-wiki <onlyinclude>{| style="float:right;margin:1em 0 1em 1em; border:1px #AAA solid;background: #f9f9f9;width:330px; font-size:95%;margin-top:0px;" !colspan="2" style="background-color:#CEDAF2; text-align:center"| {{#if: {{{NAME|}}}|<big>{{{NAME}}}</big>|<big>{{PAGENAME}}</big>}} |- {{#if: {{{STATUS|}}}| {{!}} style="vertical-align:top;" {{!}}Status {{!}} {{{STATUS}}} }} |- {{#if: {{{MENUCONFIG|}}}| {{!}} style="vertical-align:top;" {{!}}menuconfig {{!}} {{{MENUCONFIG}}} }} |- {{#if: {{{PINNING|}}}| {{!}} style="vertical-align:top;" {{!}}Pinning {{!}} {{{PINNING}}} }} |- {{#if: {{{ECMD|}}}| {{!}} style="vertical-align:top;" {{!}}Ecmd {{!}} {{{ECMD}}} }} |- {{#if: {{{CONTROL6|}}}| {{!}} style="vertical-align:top;" {{!}}Control6 {{!}} {{{CONTROL6}}} }} |- {{#if: {{{DEPENDS|}}}| {{!}} style="vertical-align:top;" {{!}}Depends on {{!}} {{{DEPENDS}}} }} |- {{#if: {{{REQUIRES|}}}| {{!}} style="vertical-align:top;" {{!}}Requires {{!}} {{{REQUIRES}}} }} |- {{#if: {{{CODE|}}}| {{!}} style="vertical-align:top;" {{!}}Code {{!}} {{{CODE}}} }} |- |}</onlyinclude> == Templates for menuconfig == If you use one of the following templates, the module will automatically added to the proper category {{Codeline|<nowiki>{{I/O}}</nowiki>}} {{Codeline|<nowiki>{{Protocols}}</nowiki>}} {{Codeline|<nowiki>{{Applications}}</nowiki>}} == Templates for STATUS == {| style="width:50%" |- | {{Codeline|<nowiki>{{stable}}</nowiki>}} {{stable}} {{Codeline|<nowiki>{{In_Development}}</nowiki>}} {{In Development}} {{Codeline|<nowiki>{{Unstable}}</nowiki>}} {{Unstable}} {{Codeline|<nowiki>{{Deprecated}}</nowiki>}} {{Deprecated}} |} == Templates for ECMD == {| style="width:50%" |- | {{Codeline|<nowiki>{{has_ecmd}}</nowiki>}} {{has_ecmd}} |} or leave blank == Example == <pre><nowiki> {{Module |NAME=Onewire |MENUCONFIG={{I/O}}->Onewire support |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }}</nowiki></pre> == Result == {{Module |NAME=Onewire |MENUCONFIG={{I/O}}->Onewire support |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} 3db8bf6b5018f9ad9ed9fdaaf330a06c41258b2a 69 66 2011-10-05T17:04:45Z Mgue 312 wikitext text/x-wiki <onlyinclude>{| style="float:right;margin:1em 0 1em 1em; border:1px #AAA solid;background: #f9f9f9;width:330px; font-size:95%;margin-top:0px;" !colspan="2" style="background-color:#CEDAF2; text-align:center"| {{#if: {{{NAME|}}}|<big>{{{NAME}}}</big>|<big>{{PAGENAME}}</big>}} |- {{#if: {{{STATUS|}}}| {{!}} style="vertical-align:top;" {{!}}Status {{!}} {{{STATUS}}} }} |- {{#if: {{{MENUCONFIG|}}}| {{!}} style="vertical-align:top;" {{!}}menuconfig {{!}} {{{MENUCONFIG}}} }} |- {{#if: {{{PINNING|}}}| {{!}} style="vertical-align:top;" {{!}}Pinning {{!}} {{{PINNING}}} }} |- {{#if: {{{ECMD|}}}| {{!}} style="vertical-align:top;" {{!}}Ecmd {{!}} {{{ECMD}}} }} |- {{#if: {{{CONTROL6|}}}| {{!}} style="vertical-align:top;" {{!}}Control6 {{!}} {{{CONTROL6}}} }} |- {{#if: {{{DEPENDS|}}}| {{!}} style="vertical-align:top;" {{!}}Depends on {{!}} {{{DEPENDS}}} }} |- {{#if: {{{REQUIRES|}}}| {{!}} style="vertical-align:top;" {{!}}Requires {{!}} {{{REQUIRES}}} }} |- {{#if: {{{CODE|}}}| {{!}} style="vertical-align:top;" {{!}}Code {{!}} {{{CODE}}} }} |- |}</onlyinclude> == Templates for menuconfig == If you use one of the following templates, the module will automatically added to the proper category {{Codeline|<nowiki>{{I/O}}</nowiki>}} {{Codeline|<nowiki>{{Protocols}}</nowiki>}} {{Codeline|<nowiki>{{Applications}}</nowiki>}} == Templates for STATUS == {| style="width:50%" |- | {{Codeline|<nowiki>{{stable}}</nowiki>}} {{stable}} {{Codeline|<nowiki>{{In_Development}}</nowiki>}} {{In Development}} {{Codeline|<nowiki>{{Unstable}}</nowiki>}} {{Unstable}} {{Codeline|<nowiki>{{Deprecated}}</nowiki>}} {{Deprecated}} |} == Templates for ECMD == {| style="width:50%" |- | {{Codeline|<nowiki>{{has_ecmd}}</nowiki>}} |} or leave blank == Templates for CONTROL6 == {| style="width:50%" |- | {{Codeline|<nowiki>{{has_control6}}</nowiki>}} |} or leave blank == Example == <pre><nowiki> {{Module |NAME=Onewire |MENUCONFIG={{I/O}}->Onewire support |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }}</nowiki></pre> == Result == {{Module |NAME=Onewire |MENUCONFIG={{I/O}}->Onewire support |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} 795c1103f889d7544ab2d7bbc3363214e2bdd3be 10 27 67 49 2011-10-05T17:03:22Z Mgue 312 wikitext text/x-wiki yes [[Category:Module with ECMD| ]] afdd4896085a36e7f2c28d9a3e5821ef8d93d471 10 33 68 2011-10-05T17:03:45Z Mgue 312 Created page with "yes [[Category:Module with Control6| ]]" wikitext text/x-wiki yes [[Category:Module with Control6| ]] d0964d14c043ce1a69581a140d94d4930f8c5020 0 34 87 2011-10-11T15:34:05Z Mgue 312 Created page with "{{i18n|Artnet}} {{Module |NAME=Artnet |MENUCONFIG={{Protocols}}->Art-Net Node |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] (optional) [[DMX Storage]] |REQU…" wikitext text/x-wiki {{i18n|Artnet}} {{Module |NAME=Artnet |MENUCONFIG={{Protocols}}->Art-Net Node |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] (optional) [[DMX Storage]] |REQUIRES= - |CODE=[https://github.com/mguentner/ethersex/tree/master/protocols/artnet https://github.com/mguentner/ethersex/tree/master/protocols/artnet] }} The Artnet module currently supports receiving aswell as broadcasting universes. Configuration packages are not yet implemented (like setting the IP address of your device using Artnet). The module is part of the [[Ethersex Lighting Architecture]] and stores/requests the DMX data using [[DMX Storage]]. == Known Issues == Some programs like [http://qlc.svn.sourceforge.net/ QLC] start the universe count with 1 instead of 0. Make sure that you adjust the universes according to that. [[Category:e6la]] de5183cec6a144f593f3d0eebed230d8ea10c127 90 87 2011-10-19T20:40:35Z Mgue 312 NET_MAX_FRAME_LENGTH added wikitext text/x-wiki {{i18n|Artnet}} {{Module |NAME=Artnet |MENUCONFIG={{Protocols}}->Art-Net Node |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] (optional) [[DMX Storage]] |REQUIRES= NET_MAX_FRAME_LENGTH >= 572 |CODE=[https://github.com/mguentner/ethersex/tree/master/protocols/artnet https://github.com/mguentner/ethersex/tree/master/protocols/artnet] }} The Artnet module currently supports receiving aswell as broadcasting universes. Configuration packages are not yet implemented (like setting the IP address of your device using Artnet). The module is part of the [[Ethersex Lighting Architecture]] and stores/requests the DMX data using [[DMX Storage]]. == Configuration == Make sure that NET_MAX_FRAME_LENGTH is >= 572 or artnet will be unable to process any packages. == Known Issues == Some programs like [http://qlc.svn.sourceforge.net/ QLC] start the universe count with 1 instead of 0. Make sure that you adjust the universes according to that. [[Category:e6la]] f21a4363f1db489244d90270b25d9c731697ad55 0 35 88 2011-10-19T16:55:13Z Mgue 312 Created page with " == Step 1: Contacting the authors == <source> cd ethersex git shortlog -e -s > gitcommits egrep -I -h -r -o "([a-zA-Z0-9_\.\-\+])+\@(([a-zA-Z0-9\-])+\.)+([a-zA-Z0-9]{2,4})" * |…" wikitext text/x-wiki == Step 1: Contacting the authors == <source> cd ethersex git shortlog -e -s > gitcommits egrep -I -h -r -o "([a-zA-Z0-9_\.\-\+])+\@(([a-zA-Z0-9\-])+\.)+([a-zA-Z0-9]{2,4})" * | sort -u rm gitcommits </source> 545b69b291cf1e99de66227d5c2492a010781b89 89 88 2011-10-19T16:55:30Z Mgue 312 wikitext text/x-wiki == Step 1: Contacting the authors == <source lang="bash"> cd ethersex git shortlog -e -s > gitcommits egrep -I -h -r -o "([a-zA-Z0-9_\.\-\+])+\@(([a-zA-Z0-9\-])+\.)+([a-zA-Z0-9]{2,4})" * | sort -u rm gitcommits </source> 7e5de32d93b76d619b0480ca8676386a06ea6dbc 10 20 91 29 2011-10-24T18:22:58Z Mgue 312 + Hardware wikitext text/x-wiki <noinclude>{{i18n|Facts}}</noinclude> {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | colspan=2 style="background-color: #FFFFFF; text-align: center; border-bottom:1px solid #aaaaaa;" | '''Overview''' |- |Ethersex is a firmware with network support for 8-bit AVR microcontrollers. {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- !style="width:50%" | Features !style="width:50%" | Supported Boards |- | * Support for atmega 8,16,32,64,128,644 and many more * Uses the common '''ENC28J60''' * TCP/IP IPv4/'''IPv6''' * OpenVPN * Software USB stack * RFM12 (433 MHz) * '''i²c''' Master (numerous chips supported)/Slave * onewire * http server * can be controlled remotely using the '''Ethersex Command Protocol (ECMD)''' * easily customizable and expandable to suit your needs * [[Features|any many more]] | * NetIO (Pollin) * Etherrape (lochraster.org) * AVR Module (Ulrich Radig) * Jackalope (lochraster.org * Probot (Conrad) * Fimser (OV Lennestadt) * JeeLink v2 (JeeLabs) * Funk-AVR-Evaluationsboard (Pollin) * TODO: Custom Board * [[Supported Boards |any many more]] |} 9bc9c381b1870e9f16c4137c6ac4ab467a8f88f2 95 91 2011-10-24T19:33:58Z Mgue 312 wikitext text/x-wiki <noinclude>{{i18n|Facts}}</noinclude> {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | colspan=2 style="background-color: #FFFFFF; text-align: center; border-bottom:1px solid #aaaaaa;" | '''Overview''' |- |Ethersex is a firmware with network support for 8-bit AVR microcontrollers. {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- !style="width:50%" | Features !style="width:50%" | Supported Boards |- | * Support for atmega 8,16,32,64,128,644 and many more * Uses the common '''ENC28J60''' * TCP/IP IPv4/'''IPv6''' * OpenVPN * Software USB stack * RFM12 (433 MHz) * '''i²c''' Master (numerous chips supported)/Slave * onewire * http server * can be controlled remotely using the '''Ethersex Command Protocol (ECMD)''' * easily customizable and expandable to suit your needs * [[Features|any many more]] | * NetIO (Pollin) * Etherrape (lochraster.org) * AVR Module (Ulrich Radig) * Jackalope (lochraster.org * Probot (Conrad) * Fimser (OV Lennestadt) * JeeLink v2 (JeeLabs) * Funk-AVR-Evaluationsboard (Pollin) * TODO: Custom Board * [[Supported Boards |any many more]] |} |} 5c6888e5885754d1c167e0513ee1b17d5c532b19 0 36 92 2011-10-24T19:13:51Z Mgue 312 Created page with "= How to Contribute = We are a truly open source [[community]] and therefore appreciate any effort to make ethersex even more awesome. You can help in various ways like writing …" wikitext text/x-wiki = How to Contribute = We are a truly open source [[community]] and therefore appreciate any effort to make ethersex even more awesome. You can help in various ways like writing code, supporting other users (e.g. on [[Community|IRC]]) or expanding this wiki with your knowledge. == Writing Code == All your code needs to be [http://www.gnu.org/copyleft/gpl.html ''GPLv3 or later''] if you plan to publish your code. TODO == Coding Style == TODO == Patches == For version control we use [http://git-scm.com/ Git]. Our repository is hosted [https://github.com/ethersex/ethersex on github]. If you haven't work with git so far, you should familiarize yourself with it by reading [http://help.github.com/ the beginners guide on github]. === Fork us! === [http://help.github.com/fork-a-repo/ The help page on github] pretty much explains how that works. To make your life easier you should create a branch for '''each''' new feature you will be implementing. '''NEVER''' touch the ''master'' branch - or you probably will not be able to merge upstream changes into your fork without conflicts. === Pull requests === Pull requests are the easiest way to get your code integrated into the ethersex code base. Developers don't need to send patches around on mailing lists and can respond faster to questions/concerns maintainers may have about the code. Please read [http://help.github.com/send-pull-requests/ this page] in case you don't know who to use pull requests on github. 65c77ac0ca4851220e93518d0e3026169ff21f40 10 37 93 2011-10-24T19:28:02Z Mgue 312 Created page with "{|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | colspan=2 style="background-colo…" wikitext text/x-wiki {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | colspan=2 style="background-color: #FFFFFF; text-align: center; border-bottom:1px solid #aaaaaa;" | '''Getting started''' |- | * [[Quick Start Guide]] * [[Community]] * [[Contributing]] |} 2d1f8647301b5f4391c0db5b4d3ee0bb2bc73439 0 5 94 28 2011-10-24T19:32:05Z Mgue 312 wikitext text/x-wiki {{i18n|Main Page}} == Welcome ethersex - the universial AVR firmware == {{Facts}} {{Getting Started}} f36f4abf73327914383ab087fef37dc1051f5357 100 94 2011-10-24T20:06:22Z Mgue 312 wikitext text/x-wiki {{i18n|Main Page}} == Welcome ethersex - the universial AVR firmware == {{Facts}} {|style="width:100%" |style="width:50%"|{{Getting Started}} |style="width:50%"|{{Documentation}} |- |} 2e2e8187c39db2da677f2619a5a4e9d67fbc92f7 0 38 96 2011-10-24T19:52:43Z Mgue 312 Created page with "= Mailing lists = [http://list.zerties.org/cgi-bin/mailman/listinfo/ethersex-devel ethersex-devel] [https://list.zerties.org/cgi-bin/mailman/listinfo/ethersex-commit ethersex-com…" wikitext text/x-wiki = Mailing lists = [http://list.zerties.org/cgi-bin/mailman/listinfo/ethersex-devel ethersex-devel] [https://list.zerties.org/cgi-bin/mailman/listinfo/ethersex-commit ethersex-commit] = IRC = You can find us on [irc://freenode.net/#ethersex #ethersex] (freenode.net) If you have any questions...just ask! If no one answers right away - don't take it personally. We might just be away from keyboard. Just stick around for some time. ec469582511249865fdc4d92664465ecb7bf65f8 97 96 2011-10-24T19:52:48Z Mgue 312 wikitext text/x-wiki = Mailing lists = [http://list.zerties.org/cgi-bin/mailman/listinfo/ethersex-devel ethersex-devel] [https://list.zerties.org/cgi-bin/mailman/listinfo/ethersex-commit ethersex-commit] = IRC = You can find us on [irc://freenode.net/#ethersex #ethersex] (freenode.net) If you have any questions...just ask! If no one answers right away - don't take it personally. We might just be away from keyboard. Just stick around for some time. 3a90e348fa4d84b5b27a99aae5cf8069a4208d78 98 97 2011-10-24T19:52:58Z Mgue 312 wikitext text/x-wiki = Mailing lists = *[http://list.zerties.org/cgi-bin/mailman/listinfo/ethersex-devel ethersex-devel] *[https://list.zerties.org/cgi-bin/mailman/listinfo/ethersex-commit ethersex-commit] = IRC = You can find us on [irc://freenode.net/#ethersex #ethersex] (freenode.net) If you have any questions...just ask! If no one answers right away - don't take it personally. We might just be away from keyboard. Just stick around for some time. 3748cbc4453a8b49578b6d1f86c27a1ede2d8d21 10 39 99 2011-10-24T20:04:59Z Mgue 312 Created page with "{|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | colspan=2 style="background-colo…" wikitext text/x-wiki {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | colspan=2 style="background-color: #FFFFFF; text-align: center; border-bottom:1px solid #aaaaaa;" | '''Documentation''' |- | [[Wiki Guidelines]] ---- * [[:Category:Hardware|Hardware Drivers]] * [[:Category:Protocol|Protocol Support]] * [[:Category:Application|Services and Applications]] |} 788cfb44407cd18866ce1625aa02964a9250726c 101 99 2011-10-24T20:08:20Z Mgue 312 wikitext text/x-wiki {{i18n|Documentation}} {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | colspan=2 style="background-color: #FFFFFF; text-align: center; border-bottom:1px solid #aaaaaa;" | '''Documentation''' |- | [[Wiki Guidelines]] ---- * [[:Category:Hardware|Hardware Drivers]] * [[:Category:Protocol|Protocol Support]] * [[:Category:Application|Services and Applications]] |} 564437ff7622da2f6642104ef5e2fe51a93dbe35 10 39 102 101 2011-10-24T20:08:58Z Mgue 312 wikitext text/x-wiki <noinclude>{{i18n|Documentation}}</noinclude> {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | colspan=2 style="background-color: #FFFFFF; text-align: center; border-bottom:1px solid #aaaaaa;" | '''Documentation''' |- | [[Wiki Guidelines]] ---- * [[:Category:Hardware|Hardware Drivers]] * [[:Category:Protocol|Protocol Support]] * [[:Category:Application|Services and Applications]] |} 7fdb1f6c9f67976b1d6781cb251df6ec1968996e 104 102 2011-10-24T20:09:38Z Mgue 312 wikitext text/x-wiki <noinclude>{{i18n|Template:Documentation}}</noinclude> {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | colspan=2 style="background-color: #FFFFFF; text-align: center; border-bottom:1px solid #aaaaaa;" | '''Documentation''' |- | [[Wiki Guidelines]] ---- * [[:Category:Hardware|Hardware Drivers]] * [[:Category:Protocol|Protocol Support]] * [[:Category:Application|Services and Applications]] |} 81ce45bc1c8155b16de2df9f3f01f1b0cff3bd1b 10 20 103 95 2011-10-24T20:09:24Z Mgue 312 wikitext text/x-wiki <noinclude>{{i18n|Template:Facts}}</noinclude> {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | colspan=2 style="background-color: #FFFFFF; text-align: center; border-bottom:1px solid #aaaaaa;" | '''Overview''' |- |Ethersex is a firmware with network support for 8-bit AVR microcontrollers. {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- !style="width:50%" | Features !style="width:50%" | Supported Boards |- | * Support for atmega 8,16,32,64,128,644 and many more * Uses the common '''ENC28J60''' * TCP/IP IPv4/'''IPv6''' * OpenVPN * Software USB stack * RFM12 (433 MHz) * '''i²c''' Master (numerous chips supported)/Slave * onewire * http server * can be controlled remotely using the '''Ethersex Command Protocol (ECMD)''' * easily customizable and expandable to suit your needs * [[Features|any many more]] | * NetIO (Pollin) * Etherrape (lochraster.org) * AVR Module (Ulrich Radig) * Jackalope (lochraster.org * Probot (Conrad) * Fimser (OV Lennestadt) * JeeLink v2 (JeeLabs) * Funk-AVR-Evaluationsboard (Pollin) * TODO: Custom Board * [[Supported Boards |any many more]] |} |} 3f4c579961555802fc10e51fdfe94d6b6a0c2617 10 37 105 93 2011-10-24T20:09:57Z Mgue 312 wikitext text/x-wiki <noinclude>{{i18n|Template:Getting Started}}</noinclude> {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | colspan=2 style="background-color: #FFFFFF; text-align: center; border-bottom:1px solid #aaaaaa;" | '''Getting started''' |- | * [[Quick Start Guide]] * [[Community]] * [[Contributing]] |} 96bd7500afdd41b9acbd46cd55c8f84f1e9953a3 0 38 106 98 2011-10-24T20:10:18Z Mgue 312 wikitext text/x-wiki {{i18n|Community}} = Mailing lists = *[http://list.zerties.org/cgi-bin/mailman/listinfo/ethersex-devel ethersex-devel] *[https://list.zerties.org/cgi-bin/mailman/listinfo/ethersex-commit ethersex-commit] = IRC = You can find us on [irc://freenode.net/#ethersex #ethersex] (freenode.net) If you have any questions...just ask! If no one answers right away - don't take it personally. We might just be away from keyboard. Just stick around for some time. be0aacec4e8ed7d7654216f68bc9733b16465fdf 0 36 107 92 2011-10-24T20:10:42Z Mgue 312 wikitext text/x-wiki {{i18n|Contributing}} = How to Contribute = We are a truly open source [[community]] and therefore appreciate any effort to make ethersex even more awesome. You can help in various ways like writing code, supporting other users (e.g. on [[Community|IRC]]) or expanding this wiki with your knowledge. == Writing Code == All your code needs to be [http://www.gnu.org/copyleft/gpl.html ''GPLv3 or later''] if you plan to publish your code. TODO == Coding Style == TODO == Patches == For version control we use [http://git-scm.com/ Git]. Our repository is hosted [https://github.com/ethersex/ethersex on github]. If you haven't work with git so far, you should familiarize yourself with it by reading [http://help.github.com/ the beginners guide on github]. === Fork us! === [http://help.github.com/fork-a-repo/ The help page on github] pretty much explains how that works. To make your life easier you should create a branch for '''each''' new feature you will be implementing. '''NEVER''' touch the ''master'' branch - or you probably will not be able to merge upstream changes into your fork without conflicts. === Pull requests === Pull requests are the easiest way to get your code integrated into the ethersex code base. Developers don't need to send patches around on mailing lists and can respond faster to questions/concerns maintainers may have about the code. Please read [http://help.github.com/send-pull-requests/ this page] in case you don't know who to use pull requests on github. 571a740db5f12d5ac7659e6a6c132c2147797707 0 40 108 2011-10-24T20:19:38Z Mgue 312 Created page with "{{i18n|Wiki Guidelines}} == Languages == This is an international wiki. Please include this on every page you create: {{Codeline|<nowiki>{{i18n|TITLE}}</nowiki>}} replace TITL…" wikitext text/x-wiki {{i18n|Wiki Guidelines}} == Languages == This is an international wiki. Please include this on every page you create: {{Codeline|<nowiki>{{i18n|TITLE}}</nowiki>}} replace TITLE with the title of the page you are editing. This will insert a language bar like the one you can see above. If you want to translate a page, simply click on the language and start editing. Make sure that you include the language template as well. == Modules == If you want to document a module, please make use of the [[Template:Module | Module Template]]. A well documented module should look similar to [[IRMP | this ]]. 5fc180272abd8e1c9a8932a1688866faad8a8743 138 108 2011-10-30T17:04:56Z Mgue 312 wikitext text/x-wiki {{i18n|Wiki Guidelines}} == Languages == This is an international wiki. Please include this on every page you create: {{Codeline|<nowiki>{{i18n|TITLE}}</nowiki>}} replace TITLE with the title of the page you are editing. This will insert a language bar like the one you can see above. If you want to translate a page, simply click on the language and start editing. Make sure that you include the language template as well. == Modules == If you want to document a module, please make use of the [[Template:Module | Module Template]]. A well documented module should look similar to [[IRMP | this ]]. For the title, please use the name of the module in menuconfig or how it is called in the code (e.g. the folder name). Please do not chose a title that doesn't match with either one of these. == More rules == * Refrain from putting all information related to a module into one single page. Create subpages for examples and specific setups. 2399bdd1c6d72c34db2dcb23d731ba8a8ac23233 0 35 109 89 2011-10-25T05:50:21Z GooPie4o 265 Protected "[[Licensing]]" ([edit=sysop] (indefinite) [move=sysop] (indefinite)) wikitext text/x-wiki == Step 1: Contacting the authors == <source lang="bash"> cd ethersex git shortlog -e -s > gitcommits egrep -I -h -r -o "([a-zA-Z0-9_\.\-\+])+\@(([a-zA-Z0-9\-])+\.)+([a-zA-Z0-9]{2,4})" * | sort -u rm gitcommits </source> 7e5de32d93b76d619b0480ca8676386a06ea6dbc 110 109 2011-10-25T06:21:42Z GooPie4o 265 /* Step 1: Contacting the authors */ wikitext text/x-wiki == Step 1: Contacting the authors == <source lang="bash"> cd ethersex git shortlog -e -s > gitcommits egrep -I -h -r -o "([a-zA-Z0-9_\.\-\+])+\@(([a-zA-Z0-9\-])+\.)+([a-zA-Z0-9]{2,4})" * | sort -u rm gitcommits </source> ==== Email template ===== http://techbase.kde.org/Projects/KDE_Relicensing#KDE_GPL_v2.0_Relicensing_effort 2eb8b93de1eff40c1313358d4abd83b138dd887a 111 110 2011-10-25T06:21:58Z GooPie4o 265 /* Email template = */ wikitext text/x-wiki == Step 1: Contacting the authors == <source lang="bash"> cd ethersex git shortlog -e -s > gitcommits egrep -I -h -r -o "([a-zA-Z0-9_\.\-\+])+\@(([a-zA-Z0-9\-])+\.)+([a-zA-Z0-9]{2,4})" * | sort -u rm gitcommits </source> ===== Email template ===== http://techbase.kde.org/Projects/KDE_Relicensing#KDE_GPL_v2.0_Relicensing_effort 8a5bc3878593c7a9014380fa80eaa8f42006a032 112 111 2011-10-25T10:11:39Z GooPie4o 265 /* Email template */ wikitext text/x-wiki == Step 1: Contacting the authors == <source lang="bash"> cd ethersex git shortlog -e -s > gitcommits egrep -I -h -r -o "([a-zA-Z0-9_\.\-\+])+\@(([a-zA-Z0-9\-])+\.)+([a-zA-Z0-9]{2,4})" * | sort -u rm gitcommits </source> http://www.fsf.org/news/quick-guide-gplv3-announcement http://techbase.kde.org/Projects/KDE_Relicensing#KDE_GPL_v2.0_Relicensing_effort d94e7b517c9591bd3ae5ea2ab3cac7023c47a56f 113 112 2011-10-25T10:11:54Z GooPie4o 265 /* Step 1: Contacting the authors */ wikitext text/x-wiki == Step 1: Contacting the authors == <source lang="bash"> cd ethersex git shortlog -e -s > gitcommits egrep -I -h -r -o "([a-zA-Z0-9_\.\-\+])+\@(([a-zA-Z0-9\-])+\.)+([a-zA-Z0-9]{2,4})" * | sort -u rm gitcommits </source> http://www.fsf.org/news/quick-guide-gplv3-announcement http://techbase.kde.org/Projects/KDE_Relicensing#KDE_GPL_v2.0_Relicensing_effort d83579281bb9e2b3a72f5886da266005797a64dc 114 113 2011-10-25T10:34:45Z GooPie4o 265 /* Step 1: Contacting the authors */ wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or as BSD. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or BSD. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2 or BSD, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with relicensing your contributions done under "BSD" to "GPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # you the following script <source lang="bash"> cd ethersex git shortlog -e -s > gitcommits egrep -I -h -r -o "([a-zA-Z0-9_\.\-\+])+\@(([a-zA-Z0-9\-])+\.)+([a-zA-Z0-9]{2,4})" * | sort -u rm gitcommits </source> # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! BSD -> GPLv3 || Ethersex decides |- |Kunze, Erik || YES || YES || YES || YES || YES || NO |- |} == Current TODO List == == Relicensing progress == 784cb0330bce8bf6451acf7ec5b33ef9d1d106e4 115 114 2011-10-25T10:36:36Z GooPie4o 265 /* What's next? */ wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or as BSD. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or BSD. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2 or BSD, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with relicensing your contributions done under "BSD" to "GPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # run the following script <source lang="bash"> cd ethersex git shortlog -e -s > gitcommits egrep -I -h -r -o "([a-zA-Z0-9_\.\-\+])+\@(([a-zA-Z0-9\-])+\.)+([a-zA-Z0-9]{2,4})" * | sort -u rm gitcommits </source> # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! BSD -> GPLv3 || Ethersex decides |- |Kunze, Erik || YES || YES || YES || YES || YES || NO |- |} == Current TODO List == == Relicensing progress == 736ba5d72d069cec4acd5dfd5be9ffb0b3e9f72d 116 115 2011-10-25T15:22:25Z Mgue 312 + Güntner,Maximilian wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or as BSD. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or BSD. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2 or BSD, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with relicensing your contributions done under "BSD" to "GPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # run the following script <source lang="bash"> cd ethersex git shortlog -e -s > gitcommits egrep -I -h -r -o "([a-zA-Z0-9_\.\-\+])+\@(([a-zA-Z0-9\-])+\.)+([a-zA-Z0-9]{2,4})" * | sort -u rm gitcommits </source> # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! BSD -> GPLv3 || Ethersex decides |- |Kunze, Erik || YES || YES || YES || YES || YES || NO |- |Güntner, Maximilian || YES || YES || YES || YES || YES || NO |- |} == Current TODO List == == Relicensing progress == d155f70e6578ab55d1e1842cfc83ab9653f6de61 117 116 2011-10-25T22:41:01Z Mgue 312 sort list wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or as BSD. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or BSD. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2 or BSD, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with relicensing your contributions done under "BSD" to "GPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # run the following script <source lang="bash"> cd ethersex git shortlog -e -s > gitcommits egrep -I -h -r -o "([a-zA-Z0-9_\.\-\+])+\@(([a-zA-Z0-9\-])+\.)+([a-zA-Z0-9]{2,4})" * | sort -u rm gitcommits </source> # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! BSD -> GPLv3 || Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || YES || NO |- |} == Current TODO List == == Relicensing progress == 575e17ea4b34eaaff61e7d73c14960b10ee41b21 118 117 2011-10-26T05:55:29Z GooPie4o 265 /* What's next? */ wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or as BSD. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or BSD. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2 or BSD, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with relicensing your contributions done under "BSD" to "GPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! BSD -> GPLv3 || Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || YES || NO |- |} == Current TODO List == == Relicensing progress == ba49fd013de12a96bac5aae5972bfbbaae95fd97 119 118 2011-10-28T07:57:33Z GooPie4o 265 /* Current TODO List */ wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or as BSD. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or BSD. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2 or BSD, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with relicensing your contributions done under "BSD" to "GPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! BSD -> GPLv3 || Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || YES || NO |- |} == Current TODO List == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/Crypto-arm-lib == Relicensing progress == cfbb3c31e608cb8a009249d323c18c2d588c73d2 120 119 2011-10-29T12:45:14Z GooPie4o 265 /* Current TODO List */ wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or as BSD. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or BSD. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2 or BSD, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with relicensing your contributions done under "BSD" to "GPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! BSD -> GPLv3 || Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || YES || NO |- |} == Current TODO List == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/Crypto-arm-lib ** done 3402fc6f983d801908d6cf94f78f8dfc13c40be4 == Relicensing progress == a2f3b1bc3bdc6433d59d01730eb063e04998d251 121 120 2011-10-29T12:45:58Z GooPie4o 265 /* Current TODO List */ wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or as BSD. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or BSD. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2 or BSD, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with relicensing your contributions done under "BSD" to "GPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! BSD -> GPLv3 || Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || YES || NO |- |} == Current TODO List == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/Crypto-arm-lib ** done 3402fc6f983d801908d6cf94f78f8dfc13c40be4 * clarify if files under BSD license need to be relicensed == Relicensing progress == fd217a4c1b400200033fca0579b2b0bbdcf8ad41 122 121 2011-10-29T12:46:37Z GooPie4o 265 wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or as BSD. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or BSD. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2 or BSD, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with relicensing your contributions done under "BSD" to "GPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! BSD -> GPLv3 || Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || YES || NO |- |} == Current TODO List == * clarify if files under BSD license need to be relicensed == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/Crypto-arm-lib ** done 3402fc6f983d801908d6cf94f78f8dfc13c40be4 ae6b29b5b1006cca5913f477ee70f73999193f46 123 122 2011-10-29T12:47:19Z GooPie4o 265 /* Relicensing progress */ wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or as BSD. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or BSD. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2 or BSD, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with relicensing your contributions done under "BSD" to "GPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! BSD -> GPLv3 || Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || YES || NO |- |} == Current TODO List == * clarify if files under BSD license need to be relicensed == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/Crypto-arm-lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 05030484cd7abf8d6e4ae20f852b99796dc02971 124 123 2011-10-29T12:50:47Z GooPie4o 265 /* Relicensing progress */ wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or as BSD. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or BSD. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2 or BSD, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with relicensing your contributions done under "BSD" to "GPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! BSD -> GPLv3 || Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || YES || NO |- |} == Current TODO List == * clarify if files under BSD license need to be relicensed == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 c16f71892db8cb83401cc94585cce078960336e0 125 124 2011-10-29T14:30:02Z GooPie4o 265 wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or as BSD. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or BSD. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2 or BSD, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with relicensing your contributions done under "BSD" to "GPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! BSD -> GPLv3 || Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || YES || NO |- |} == Current TODO List == * send an email to authors of source files with incompatible license == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD f1e04a454fce41e16d1d06f55c1482e76100c557 126 125 2011-10-29T14:55:07Z Mgue 312 uIP wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or as BSD. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or BSD. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2 or BSD, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with relicensing your contributions done under "BSD" to "GPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! BSD -> GPLv3 || Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || YES || NO |- |} == Current TODO List == * send an email to authors of source files with incompatible license == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD * Adam Dunkels' uIP Stack is licensed under the BSD http://en.wikipedia.org/wiki/UIP_(micro_IP) https://github.com/ethersex/ethersex/blob/master/protocols/uip/uip.c#L25 323c87d651cf2c351eab2d15dd83742dd0ae6226 127 126 2011-10-29T14:58:19Z GooPie4o 265 /* Relicensing progress */ wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or as BSD. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or BSD. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2 or BSD, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with relicensing your contributions done under "BSD" to "GPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! BSD -> GPLv3 || Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || YES || NO |- |} == Current TODO List == * send an email to authors of source files with incompatible license == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD * Adam Dunkels' uIP Stack is licensed under the BSD http://en.wikipedia.org/wiki/UIP_(micro_IP) https://github.com/ethersex/ethersex/blob/master/protocols/uip/uip.c#L25 * MIT/X is compatible with GPLv3 ** http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing f71ef3dfcc7dd4134f1480a2246ec52eb022dcec 128 127 2011-10-29T16:00:02Z GooPie4o 265 /* How can I help? */ wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or as BSD. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or BSD. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2 or BSD, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! BSD -> GPLv3 || Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || YES || NO |- |} == Current TODO List == * send an email to authors of source files with incompatible license == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD * Adam Dunkels' uIP Stack is licensed under the BSD http://en.wikipedia.org/wiki/UIP_(micro_IP) https://github.com/ethersex/ethersex/blob/master/protocols/uip/uip.c#L25 * MIT/X is compatible with GPLv3 ** http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing 3500d77cf48e9124c4799db4e9c476ccdd7bbc06 129 128 2011-10-29T16:01:10Z GooPie4o 265 /* Why does it matter? */ wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or any other incompatible licesne. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or any other incompatible license. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2 or BSD, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! BSD -> GPLv3 || Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || YES || NO |- |} == Current TODO List == * send an email to authors of source files with incompatible license == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD * Adam Dunkels' uIP Stack is licensed under the BSD http://en.wikipedia.org/wiki/UIP_(micro_IP) https://github.com/ethersex/ethersex/blob/master/protocols/uip/uip.c#L25 * MIT/X is compatible with GPLv3 ** http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing 1abdde7de7afdabe359cff7d009d94cd9b04048b 130 129 2011-10-30T16:22:40Z GooPie4o 265 /* Current TODO List */ wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or any other incompatible licesne. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or any other incompatible license. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2 or BSD, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! BSD -> GPLv3 || Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || YES || NO |- |} == Current TODO List == * {| border="1" ! File !! License !! Status |- | contrib/webscripts/sty.c || unknown || |- | control6/control6.h || unknown || |- | core/gui/font.c || unknown || |- | core/host/avr/interrupt.h || unknown || |- | core/host/avr/io.h || unknown || |- | core/host/avr/pgmspace.h || unknown || |- | core/host/avr/wdt.h || unknown || |- | core/host/host.h || unknown || |- | core/host/util/crc16.h || unknown || |- | core/setbaud.h || unknown || |- | embed/Sty.c || unknown || |- | hardware/ir/irmp/irmp_lib.c || unknown || |- | hardware/lcd/s1d15g10/bunnies.h || unknown || |- | hardware/lcd/ST7626/4x6.h || unknown || |- | hardware/lcd/ST7626/ST7626.h || unknown || |- | hardware/sram/sram.h || unknown || |- | hardware/storage/sd_reader/byteordering.c || GPLv2 || |- | hardware/storage/sd_reader/byteordering.h || GPLv2 || |- | hardware/storage/sd_reader/fat.c || GPLv2 || |- | hardware/storage/sd_reader/fat_config.h || GPLv2 || |- | hardware/storage/sd_reader/fat.h || GPLv2 || |- | hardware/storage/sd_reader/partition.c || GPLv2 || |- | hardware/storage/sd_reader/partition_config.h || GPLv2 || |- | hardware/storage/sd_reader/partition.h || GPLv2 || |- | hardware/storage/sd_reader/sd_raw.c || GPLv2 || |- | hardware/storage/sd_reader/sd_raw_config.h || GPLv2 || |- | hardware/storage/sd_reader/sd_raw.h || GPLv2 || |- | hardware/storage/sd_reader/sd-reader_config.h || GPLv2 || |- | protocols/bootp/bootphdr.h || unknown || |- | protocols/uip/uip-conf.h || unknown || |- | protocols/usb/usbconfig.h || GPLv2 || |- | protocols/ustream/vs1053.h || unknown || |- | services/glcdmenu/menu-interpreter/menudata-progmem.c || unknown || |- | services/glcdmenu/menu-interpreter/menu-interpreter-config.h || unknown || |- | services/lome6/embed/Stl.c || unknown || |- |} * send an email to authors of source files with incompatible license == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD * Adam Dunkels' uIP Stack is licensed under the BSD http://en.wikipedia.org/wiki/UIP_(micro_IP) https://github.com/ethersex/ethersex/blob/master/protocols/uip/uip.c#L25 * MIT/X is compatible with GPLv3 ** http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing 4214a2af8d8a6d331db1fb6ebfd53131ad44b978 131 130 2011-10-30T16:24:07Z GooPie4o 265 /* Current TODO List */ wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or any other incompatible licesne. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or any other incompatible license. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2 or BSD, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! BSD -> GPLv3 || Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || YES || NO |- |} == Current TODO List == * collect files with incompatible license {| border="1" ! File !! License !! Status |- | contrib/webscripts/sty.c || unknown || |- | control6/control6.h || unknown || |- | core/gui/font.c || unknown || |- | core/host/avr/interrupt.h || unknown || |- | core/host/avr/io.h || unknown || |- | core/host/avr/pgmspace.h || unknown || |- | core/host/avr/wdt.h || unknown || |- | core/host/host.h || unknown || |- | core/host/util/crc16.h || unknown || |- | core/setbaud.h || unknown || |- | embed/Sty.c || unknown || |- | hardware/ir/irmp/irmp_lib.c || unknown || |- | hardware/lcd/s1d15g10/bunnies.h || unknown || |- | hardware/lcd/ST7626/4x6.h || unknown || |- | hardware/lcd/ST7626/ST7626.h || unknown || |- | hardware/sram/sram.h || unknown || |- | hardware/storage/sd_reader/byteordering.c || GPLv2 || |- | hardware/storage/sd_reader/byteordering.h || GPLv2 || |- | hardware/storage/sd_reader/fat.c || GPLv2 || |- | hardware/storage/sd_reader/fat_config.h || GPLv2 || |- | hardware/storage/sd_reader/fat.h || GPLv2 || |- | hardware/storage/sd_reader/partition.c || GPLv2 || |- | hardware/storage/sd_reader/partition_config.h || GPLv2 || |- | hardware/storage/sd_reader/partition.h || GPLv2 || |- | hardware/storage/sd_reader/sd_raw.c || GPLv2 || |- | hardware/storage/sd_reader/sd_raw_config.h || GPLv2 || |- | hardware/storage/sd_reader/sd_raw.h || GPLv2 || |- | hardware/storage/sd_reader/sd-reader_config.h || GPLv2 || |- | protocols/bootp/bootphdr.h || unknown || |- | protocols/uip/uip-conf.h || unknown || |- | protocols/usb/usbconfig.h || GPLv2 || |- | protocols/ustream/vs1053.h || unknown || |- | services/glcdmenu/menu-interpreter/menudata-progmem.c || unknown || |- | services/glcdmenu/menu-interpreter/menu-interpreter-config.h || unknown || |- | services/lome6/embed/Stl.c || unknown || |- |} * send an email to authors of source files with incompatible license == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD * Adam Dunkels' uIP Stack is licensed under the BSD http://en.wikipedia.org/wiki/UIP_(micro_IP) https://github.com/ethersex/ethersex/blob/master/protocols/uip/uip.c#L25 * MIT/X is compatible with GPLv3 ** http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing ec6ee73b54ad9e37db2f85a613c52c7e58e74b26 132 131 2011-10-30T16:26:06Z GooPie4o 265 /* Current TODO List */ wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or any other incompatible licesne. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or any other incompatible license. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2 or BSD, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! BSD -> GPLv3 || Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || YES || NO |- |} == Current TODO List == * collect files with incompatible license {| border="1" ! File !! License !! Status |- | contrib/webscripts/sty.c || unknown || |- | control6/control6.h || unknown || |- | core/gui/font.c || unknown || |- | core/host/avr/interrupt.h || unknown || |- | core/host/avr/io.h || unknown || |- | core/host/avr/pgmspace.h || unknown || |- | core/host/avr/wdt.h || unknown || |- | core/host/host.h || unknown || |- | core/host/util/crc16.h || unknown || |- | core/setbaud.h || unknown || |- | embed/Sty.c || unknown || |- | hardware/ir/irmp/irmp_lib.c || GPLv2+ || OK |- | hardware/lcd/s1d15g10/bunnies.h || unknown || |- | hardware/lcd/ST7626/4x6.h || unknown || |- | hardware/lcd/ST7626/ST7626.h || unknown || |- | hardware/sram/sram.h || unknown || |- | hardware/storage/sd_reader/byteordering.c || GPLv2 || |- | hardware/storage/sd_reader/byteordering.h || GPLv2 || |- | hardware/storage/sd_reader/fat.c || GPLv2 || |- | hardware/storage/sd_reader/fat_config.h || GPLv2 || |- | hardware/storage/sd_reader/fat.h || GPLv2 || |- | hardware/storage/sd_reader/partition.c || GPLv2 || |- | hardware/storage/sd_reader/partition_config.h || GPLv2 || |- | hardware/storage/sd_reader/partition.h || GPLv2 || |- | hardware/storage/sd_reader/sd_raw.c || GPLv2 || |- | hardware/storage/sd_reader/sd_raw_config.h || GPLv2 || |- | hardware/storage/sd_reader/sd_raw.h || GPLv2 || |- | hardware/storage/sd_reader/sd-reader_config.h || GPLv2 || |- | protocols/bootp/bootphdr.h || unknown || |- | protocols/uip/uip-conf.h || unknown || |- | protocols/usb/usbconfig.h || GPLv2 || |- | protocols/ustream/vs1053.h || unknown || |- | services/glcdmenu/menu-interpreter/menudata-progmem.c || unknown || |- | services/glcdmenu/menu-interpreter/menu-interpreter-config.h || unknown || |- | services/lome6/embed/Stl.c || unknown || |- |} * send an email to authors of source files with incompatible license == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD * Adam Dunkels' uIP Stack is licensed under the BSD http://en.wikipedia.org/wiki/UIP_(micro_IP) https://github.com/ethersex/ethersex/blob/master/protocols/uip/uip.c#L25 * MIT/X is compatible with GPLv3 ** http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing b9a1b3762b8ef5d8e9afd27e9cd2a0d4d925103e 133 132 2011-10-30T16:31:40Z GooPie4o 265 /* Current TODO List */ wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or any other incompatible licesne. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or any other incompatible license. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2 or BSD, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! BSD -> GPLv3 || Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || YES || NO |- |} == Current TODO List == * collect files with incompatible license {| border="1" ! File !! License !! Status |- | contrib/webscripts/sty.c || unknown || |- | core/gui/font.c || unknown || |- | core/host/avr/interrupt.h || unknown || |- | core/host/avr/io.h || unknown || |- | core/host/avr/pgmspace.h || unknown || |- | core/host/avr/wdt.h || unknown || |- | core/host/host.h || unknown || |- | core/host/util/crc16.h || unknown || |- | core/setbaud.h || unknown || |- | embed/Sty.c || unknown || |- | hardware/ir/irmp/irmp_lib.c || GPLv2+ || OK |- | hardware/lcd/s1d15g10/bunnies.h || unknown || |- | hardware/lcd/ST7626/4x6.h || unknown || |- | hardware/lcd/ST7626/ST7626.h || unknown || |- | hardware/sram/sram.h || unknown || |- | hardware/storage/sd_reader/byteordering.c || GPLv2 || |- | hardware/storage/sd_reader/byteordering.h || GPLv2 || |- | hardware/storage/sd_reader/fat.c || GPLv2 || |- | hardware/storage/sd_reader/fat_config.h || GPLv2 || |- | hardware/storage/sd_reader/fat.h || GPLv2 || |- | hardware/storage/sd_reader/partition.c || GPLv2 || |- | hardware/storage/sd_reader/partition_config.h || GPLv2 || |- | hardware/storage/sd_reader/partition.h || GPLv2 || |- | hardware/storage/sd_reader/sd_raw.c || GPLv2 || |- | hardware/storage/sd_reader/sd_raw_config.h || GPLv2 || |- | hardware/storage/sd_reader/sd_raw.h || GPLv2 || |- | hardware/storage/sd_reader/sd-reader_config.h || GPLv2 || |- | protocols/bootp/bootphdr.h || unknown || |- | protocols/uip/uip-conf.h || unknown || |- | protocols/usb/usbconfig.h || GPLv2 || |- | protocols/ustream/vs1053.h || unknown || |- | services/glcdmenu/menu-interpreter/menudata-progmem.c || unknown || |- | services/glcdmenu/menu-interpreter/menu-interpreter-config.h || unknown || |- | services/lome6/embed/Stl.c || unknown || |- |} * send an email to authors of source files with incompatible license == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD * Adam Dunkels' uIP Stack is licensed under the BSD http://en.wikipedia.org/wiki/UIP_(micro_IP) https://github.com/ethersex/ethersex/blob/master/protocols/uip/uip.c#L25 * MIT/X is compatible with GPLv3 ** http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing df61c7e65305c1e4fa605e73bc7b6f45e20c0d98 134 133 2011-10-30T16:37:50Z GooPie4o 265 /* Current TODO List */ wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or any other incompatible licesne. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or any other incompatible license. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2 or BSD, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! BSD -> GPLv3 || Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || YES || NO |- |} == Current TODO List == * collect files with incompatible license {| border="1" ! File !! License !! Status |- | contrib/webscripts/sty.c || unknown || |- | core/gui/font.c || unknown || |- | core/host/avr/interrupt.h || unknown || |- | core/host/avr/io.h || unknown || |- | core/host/avr/pgmspace.h || unknown || |- | core/host/avr/wdt.h || unknown || |- | core/host/host.h || unknown || |- | core/host/util/crc16.h || unknown || |- | core/setbaud.h || unknown || |- | embed/Sty.c || unknown || |- | hardware/ir/irmp/irmp_lib.c || GPLv2+ || OK |- | hardware/lcd/s1d15g10/bunnies.h || unknown || |- | hardware/lcd/ST7626/4x6.h || unknown || |- | hardware/lcd/ST7626/ST7626.h || unknown || |- | hardware/sram/sram.h || unknown || |- | hardware/storage/sd_reader/byteordering.c || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/byteordering.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/fat.c || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/fat_config.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/fat.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/partition.c || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/partition_config.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/partition.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd_raw.c || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd_raw_config.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd_raw.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd-reader_config.h || GPLv2/LGPLv2.1 || |- | protocols/bootp/bootphdr.h || unknown || |- | protocols/uip/uip-conf.h || unknown || |- | protocols/usb/usbconfig.h || GPLv2 || |- | protocols/ustream/vs1053.h || unknown || |- | services/glcdmenu/menu-interpreter/menudata-progmem.c || unknown || |- | services/glcdmenu/menu-interpreter/menu-interpreter-config.h || unknown || |- | services/lome6/embed/Stl.c || unknown || |- |} * send an email to authors of source files with incompatible license == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD * Adam Dunkels' uIP Stack is licensed under the BSD http://en.wikipedia.org/wiki/UIP_(micro_IP) https://github.com/ethersex/ethersex/blob/master/protocols/uip/uip.c#L25 * MIT/X is compatible with GPLv3 ** http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing 0fe026617c3763f3a0c91c4c0cc1be203cd75637 135 134 2011-10-30T16:40:17Z GooPie4o 265 /* Current TODO List */ wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or any other incompatible licesne. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or any other incompatible license. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2 or BSD, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! BSD -> GPLv3 || Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || YES || NO |- |} == Current TODO List == * collect files with incompatible license {| border="1" ! File !! License !! Status |- | core/gui/font.c || unknown || |- | core/host/avr/interrupt.h || unknown || |- | core/host/avr/io.h || unknown || |- | core/host/avr/pgmspace.h || unknown || |- | core/host/avr/wdt.h || unknown || |- | core/host/host.h || unknown || |- | core/host/util/crc16.h || unknown || |- | core/setbaud.h || unknown || |- | embed/Sty.c || unknown || |- | hardware/ir/irmp/irmp_lib.c || GPLv2+ || OK |- | hardware/lcd/s1d15g10/bunnies.h || unknown || |- | hardware/lcd/ST7626/4x6.h || unknown || |- | hardware/lcd/ST7626/ST7626.h || unknown || |- | hardware/sram/sram.h || unknown || |- | hardware/storage/sd_reader/byteordering.c || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/byteordering.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/fat.c || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/fat_config.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/fat.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/partition.c || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/partition_config.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/partition.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd_raw.c || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd_raw_config.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd_raw.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd-reader_config.h || GPLv2/LGPLv2.1 || |- | protocols/bootp/bootphdr.h || unknown || |- | protocols/uip/uip-conf.h || unknown || |- | protocols/usb/usbconfig.h || GPLv2 || |- | protocols/ustream/vs1053.h || unknown || |- | services/glcdmenu/menu-interpreter/menudata-progmem.c || unknown || |- | services/glcdmenu/menu-interpreter/menu-interpreter-config.h || unknown || |- |} * send an email to authors of source files with incompatible license == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD * Adam Dunkels' uIP Stack is licensed under the BSD http://en.wikipedia.org/wiki/UIP_(micro_IP) https://github.com/ethersex/ethersex/blob/master/protocols/uip/uip.c#L25 * MIT/X is compatible with GPLv3 ** http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing b226e01f885858702d314bbc47f45e8f15009089 136 135 2011-10-30T16:42:59Z GooPie4o 265 /* Current TODO List */ wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or any other incompatible licesne. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or any other incompatible license. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2 or BSD, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! BSD -> GPLv3 || Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || YES || NO |- |} == Current TODO List == * collect files with incompatible license {| border="1" ! File !! License !! Status |- | core/gui/font.c || unknown || |- | core/host/avr/interrupt.h || unknown || |- | core/host/avr/io.h || unknown || |- | core/host/avr/pgmspace.h || unknown || |- | core/host/avr/wdt.h || unknown || |- | core/host/host.h || unknown || |- | core/host/util/crc16.h || unknown || |- | core/setbaud.h || unknown || |- | hardware/ir/irmp/irmp_lib.c || GPLv2+ || OK |- | hardware/lcd/s1d15g10/bunnies.h || unknown || |- | hardware/lcd/ST7626/4x6.h || unknown || |- | hardware/lcd/ST7626/ST7626.h || unknown || |- | hardware/sram/sram.h || unknown || |- | hardware/storage/sd_reader/byteordering.c || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/byteordering.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/fat.c || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/fat_config.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/fat.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/partition.c || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/partition_config.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/partition.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd_raw.c || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd_raw_config.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd_raw.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd-reader_config.h || GPLv2/LGPLv2.1 || |- | protocols/bootp/bootphdr.h || unknown || |- | protocols/uip/uip-conf.h || unknown || |- | protocols/usb/usbconfig.h || GPLv2 || |- | protocols/ustream/vs1053.h || unknown || |- | services/glcdmenu/menu-interpreter/menudata-progmem.c || unknown || |- | services/glcdmenu/menu-interpreter/menu-interpreter-config.h || unknown || |- |} * send an email to authors of source files with incompatible license == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD * Adam Dunkels' uIP Stack is licensed under the BSD http://en.wikipedia.org/wiki/UIP_(micro_IP) https://github.com/ethersex/ethersex/blob/master/protocols/uip/uip.c#L25 * MIT/X is compatible with GPLv3 ** http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing bdbdeb9088cd99fc943bb35136211724aabe83d5 137 136 2011-10-30T16:43:41Z GooPie4o 265 /* Current TODO List */ wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or any other incompatible licesne. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or any other incompatible license. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2 or BSD, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! BSD -> GPLv3 || Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || YES || NO |- |} == Current TODO List == * collect files with incompatible license {| border="1" ! File !! License !! Status |- | core/gui/font.c || unknown || |- | core/host/avr/interrupt.h || unknown || |- | core/host/avr/io.h || unknown || |- | core/host/avr/pgmspace.h || unknown || |- | core/host/avr/wdt.h || unknown || |- | core/host/host.h || unknown || |- | core/host/util/crc16.h || unknown || |- | core/setbaud.h || unknown || |- | hardware/ir/irmp/irmp_lib.c || GPLv2+ || OK |- | hardware/lcd/s1d15g10/bunnies.h || unknown || |- | hardware/lcd/ST7626/4x6.h || unknown || |- | hardware/lcd/ST7626/ST7626.h || unknown || |- | hardware/sram/sram.h || unknown || |- | hardware/storage/sd_reader/byteordering.c || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/byteordering.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/fat.c || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/fat_config.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/fat.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/partition.c || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/partition_config.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/partition.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd_raw.c || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd_raw_config.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd_raw.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd-reader_config.h || GPLv2/LGPLv2.1 || |- | protocols/bootp/bootphdr.h || unknown || |- | protocols/uip/uip-conf.h || unknown || |- | protocols/usb/usbconfig.h || GPLv2 || |- | protocols/ustream/vs1053.h || unknown || |- | services/glcdmenu/menu-interpreter/menudata-progmem.c || unknown || |- | services/glcdmenu/menu-interpreter/menu-interpreter-config.h || unknown || |- |} * send an email to authors of source files with incompatible license * rebase SD Reader library from http://www.roland-riegel.de/sd-reader/ == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD * Adam Dunkels' uIP Stack is licensed under the BSD http://en.wikipedia.org/wiki/UIP_(micro_IP) https://github.com/ethersex/ethersex/blob/master/protocols/uip/uip.c#L25 * MIT/X is compatible with GPLv3 ** http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing f9fe3fafca05ae8080a2557ecccf78f8d38927cd 139 137 2011-10-30T19:49:57Z Mgue 312 contrib/license-lister file wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or any other incompatible licesne. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or any other incompatible license. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2 or BSD, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! BSD -> GPLv3 || Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || YES || NO |- |} == Current TODO List == * collect files with incompatible license. {| border="1" ! File !! License !! Status |- | core/gui/font.c || unknown || |- | core/host/avr/interrupt.h || unknown || |- | core/host/avr/io.h || unknown || |- | core/host/avr/pgmspace.h || unknown || |- | core/host/avr/wdt.h || unknown || |- | core/host/host.h || unknown || |- | core/host/util/crc16.h || unknown || |- | core/setbaud.h || unknown || |- | hardware/ir/irmp/irmp_lib.c || GPLv2+ || OK |- | hardware/lcd/s1d15g10/bunnies.h || unknown || |- | hardware/lcd/ST7626/4x6.h || unknown || |- | hardware/lcd/ST7626/ST7626.h || unknown || |- | hardware/sram/sram.h || unknown || |- | hardware/storage/sd_reader/byteordering.c || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/byteordering.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/fat.c || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/fat_config.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/fat.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/partition.c || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/partition_config.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/partition.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd_raw.c || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd_raw_config.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd_raw.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd-reader_config.h || GPLv2/LGPLv2.1 || |- | protocols/bootp/bootphdr.h || unknown || |- | protocols/uip/uip-conf.h || unknown || |- | protocols/usb/usbconfig.h || GPLv2 || |- | protocols/ustream/vs1053.h || unknown || |- | services/glcdmenu/menu-interpreter/menudata-progmem.c || unknown || |- | services/glcdmenu/menu-interpreter/menu-interpreter-config.h || unknown || |- |} to find out all the authors of a certain file, run ''contrib/license-lister file'' . e.g. ''contrib/license-lister protocols/bootp/bootphdr.h'' * send an email to authors of source files with incompatible license * rebase SD Reader library from http://www.roland-riegel.de/sd-reader/ == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD * Adam Dunkels' uIP Stack is licensed under the BSD http://en.wikipedia.org/wiki/UIP_(micro_IP) https://github.com/ethersex/ethersex/blob/master/protocols/uip/uip.c#L25 * MIT/X is compatible with GPLv3 ** http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing 9ebe5c58b1b6bd4303017469fec6a9ea87a09b2c 140 139 2011-10-31T08:42:38Z GooPie4o 265 /* Current Reply List */ wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or any other incompatible licesne. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or any other incompatible license. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2 or BSD, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! BSD -> GPLv3 || Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || YES || NO |- |Riegel, Roland || N/A || N/A || N/A || N/A || N/A || N/A |- |} == Current TODO List == * collect files with incompatible license. {| border="1" ! File !! License !! Status |- | core/gui/font.c || unknown || |- | core/host/avr/interrupt.h || unknown || |- | core/host/avr/io.h || unknown || |- | core/host/avr/pgmspace.h || unknown || |- | core/host/avr/wdt.h || unknown || |- | core/host/host.h || unknown || |- | core/host/util/crc16.h || unknown || |- | core/setbaud.h || unknown || |- | hardware/ir/irmp/irmp_lib.c || GPLv2+ || OK |- | hardware/lcd/s1d15g10/bunnies.h || unknown || |- | hardware/lcd/ST7626/4x6.h || unknown || |- | hardware/lcd/ST7626/ST7626.h || unknown || |- | hardware/sram/sram.h || unknown || |- | hardware/storage/sd_reader/byteordering.c || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/byteordering.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/fat.c || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/fat_config.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/fat.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/partition.c || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/partition_config.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/partition.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd_raw.c || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd_raw_config.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd_raw.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd-reader_config.h || GPLv2/LGPLv2.1 || |- | protocols/bootp/bootphdr.h || unknown || |- | protocols/uip/uip-conf.h || unknown || |- | protocols/usb/usbconfig.h || GPLv2 || |- | protocols/ustream/vs1053.h || unknown || |- | services/glcdmenu/menu-interpreter/menudata-progmem.c || unknown || |- | services/glcdmenu/menu-interpreter/menu-interpreter-config.h || unknown || |- |} to find out all the authors of a certain file, run ''contrib/license-lister file'' . e.g. ''contrib/license-lister protocols/bootp/bootphdr.h'' * send an email to authors of source files with incompatible license * rebase SD Reader library from http://www.roland-riegel.de/sd-reader/ == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD * Adam Dunkels' uIP Stack is licensed under the BSD http://en.wikipedia.org/wiki/UIP_(micro_IP) https://github.com/ethersex/ethersex/blob/master/protocols/uip/uip.c#L25 * MIT/X is compatible with GPLv3 ** http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing 016d797c851047e83c1b4951866b2ec009953bfb 141 140 2011-10-31T08:44:10Z GooPie4o 265 wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or any other incompatible licesne. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or any other incompatible license. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2 or BSD, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! BSD -> GPLv3 || Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || YES || NO |- |Riegel, Roland || N/A || N/A || N/A || N/A || N/A || N/A |- |} == Current TODO List == * collect files with incompatible license. {| border="1" ! File !! License !! Status |- | core/gui/font.c || unknown || |- | core/host/avr/interrupt.h || unknown || |- | core/host/avr/io.h || unknown || |- | core/host/avr/pgmspace.h || unknown || |- | core/host/avr/wdt.h || unknown || |- | core/host/host.h || unknown || |- | core/host/util/crc16.h || unknown || |- | core/setbaud.h || unknown || |- | hardware/ir/irmp/irmp_lib.c || GPLv2+ || OK |- | hardware/lcd/s1d15g10/bunnies.h || unknown || |- | hardware/lcd/ST7626/4x6.h || unknown || |- | hardware/lcd/ST7626/ST7626.h || unknown || |- | hardware/sram/sram.h || unknown || |- | hardware/storage/sd_reader/byteordering.c || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/byteordering.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/fat.c || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/fat_config.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/fat.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/partition.c || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/partition_config.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/partition.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd_raw.c || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd_raw_config.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd_raw.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd-reader_config.h || GPLv2/LGPLv2.1 || |- | protocols/bootp/bootphdr.h || unknown || |- | protocols/uip/uip-conf.h || unknown || |- | protocols/usb/usbconfig.h || GPLv2 || |- | protocols/ustream/vs1053.h || unknown || |- | services/glcdmenu/menu-interpreter/menudata-progmem.c || unknown || |- | services/glcdmenu/menu-interpreter/menu-interpreter-config.h || unknown || |- |} to find out all the authors of a certain file, run ''contrib/license-lister file'' . e.g. ''contrib/license-lister protocols/bootp/bootphdr.h'' * send an email to authors of source files with incompatible license == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD * Adam Dunkels' uIP Stack is licensed under the BSD http://en.wikipedia.org/wiki/UIP_(micro_IP) https://github.com/ethersex/ethersex/blob/master/protocols/uip/uip.c#L25 * MIT/X is compatible with GPLv3 ** http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing * reintegrate SD Reader library from http://www.roland-riegel.de/sd-reader/ ** done 214bc3c6e16e1f7c5389905265fd64a8c7eb4f20 142 141 2011-10-31T08:52:05Z GooPie4o 265 /* How can I help? */ wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or any other incompatible licesne. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or any other incompatible license. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! BSD -> GPLv3 || Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || YES || NO |- |Riegel, Roland || N/A || N/A || N/A || N/A || N/A || N/A |- |} == Current TODO List == * collect files with incompatible license. {| border="1" ! File !! License !! Status |- | core/gui/font.c || unknown || |- | core/host/avr/interrupt.h || unknown || |- | core/host/avr/io.h || unknown || |- | core/host/avr/pgmspace.h || unknown || |- | core/host/avr/wdt.h || unknown || |- | core/host/host.h || unknown || |- | core/host/util/crc16.h || unknown || |- | core/setbaud.h || unknown || |- | hardware/ir/irmp/irmp_lib.c || GPLv2+ || OK |- | hardware/lcd/s1d15g10/bunnies.h || unknown || |- | hardware/lcd/ST7626/4x6.h || unknown || |- | hardware/lcd/ST7626/ST7626.h || unknown || |- | hardware/sram/sram.h || unknown || |- | hardware/storage/sd_reader/byteordering.c || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/byteordering.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/fat.c || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/fat_config.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/fat.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/partition.c || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/partition_config.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/partition.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd_raw.c || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd_raw_config.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd_raw.h || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd-reader_config.h || GPLv2/LGPLv2.1 || |- | protocols/bootp/bootphdr.h || unknown || |- | protocols/uip/uip-conf.h || unknown || |- | protocols/usb/usbconfig.h || GPLv2 || |- | protocols/ustream/vs1053.h || unknown || |- | services/glcdmenu/menu-interpreter/menudata-progmem.c || unknown || |- | services/glcdmenu/menu-interpreter/menu-interpreter-config.h || unknown || |- |} to find out all the authors of a certain file, run ''contrib/license-lister file'' . e.g. ''contrib/license-lister protocols/bootp/bootphdr.h'' * send an email to authors of source files with incompatible license == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD * Adam Dunkels' uIP Stack is licensed under the BSD http://en.wikipedia.org/wiki/UIP_(micro_IP) https://github.com/ethersex/ethersex/blob/master/protocols/uip/uip.c#L25 * MIT/X is compatible with GPLv3 ** http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing * reintegrate SD Reader library from http://www.roland-riegel.de/sd-reader/ ** done 66c046a0f9b964ee766ce8258392c253694d0280 143 142 2011-10-31T08:59:48Z GooPie4o 265 /* Current TODO List */ wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or any other incompatible licesne. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or any other incompatible license. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! BSD -> GPLv3 || Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || YES || NO |- |Riegel, Roland || N/A || N/A || N/A || N/A || N/A || N/A |- |} == Current TODO List == * collect files with incompatible license. {| border="1" ! File !! License !! Status |- | core/gui/font.c || unknown || |- | core/host/avr/interrupt.h || unknown || |- | core/host/avr/io.h || unknown || |- | core/host/avr/pgmspace.h || unknown || |- | core/host/avr/wdt.h || unknown || |- | core/host/host.h || unknown || |- | core/host/util/crc16.h || unknown || |- | core/setbaud.h || unknown || |- | hardware/ir/irmp/irmp_lib.c || GPLv2+ || OK |- | hardware/lcd/s1d15g10/bunnies.h || unknown || |- | hardware/lcd/ST7626/4x6.h || unknown || |- | hardware/lcd/ST7626/ST7626.h || unknown || |- | hardware/sram/sram.h || unknown || |- | hardware/storage/sd_reader/byteordering.* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/fat* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/partition* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd_raw* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd-reader_config.h || GPLv2/LGPLv2.1 || |- | protocols/bootp/bootphdr.h || unknown || |- | protocols/uip/uip-conf.h || unknown || |- | protocols/usb/usbconfig.h || GPLv2 || |- | protocols/ustream/vs1053.h || unknown || |- | services/glcdmenu/menu-interpreter/menudata-progmem.c || unknown || |- | services/glcdmenu/menu-interpreter/menu-interpreter-config.h || unknown || |- |} to find out all the authors of a certain file, run ''contrib/license-lister file'' . e.g. ''contrib/license-lister protocols/bootp/bootphdr.h'' * send an email to authors of source files with incompatible license == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD * Adam Dunkels' uIP Stack is licensed under the BSD http://en.wikipedia.org/wiki/UIP_(micro_IP) https://github.com/ethersex/ethersex/blob/master/protocols/uip/uip.c#L25 * MIT/X is compatible with GPLv3 ** http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing * reintegrate SD Reader library from http://www.roland-riegel.de/sd-reader/ ** done 863a8d26ace0ae663ce4c0a6b7c62ee9f7a04442 144 143 2011-10-31T10:19:49Z GooPie4o 265 /* Current Reply List */ wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or any other incompatible licesne. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or any other incompatible license. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || NO |- |Riegel, Roland || N/A || N/A || N/A || N/A || N/A |- |} == Current TODO List == * collect files with incompatible license. {| border="1" ! File !! License !! Status |- | core/gui/font.c || unknown || |- | core/host/avr/interrupt.h || unknown || |- | core/host/avr/io.h || unknown || |- | core/host/avr/pgmspace.h || unknown || |- | core/host/avr/wdt.h || unknown || |- | core/host/host.h || unknown || |- | core/host/util/crc16.h || unknown || |- | core/setbaud.h || unknown || |- | hardware/ir/irmp/irmp_lib.c || GPLv2+ || OK |- | hardware/lcd/s1d15g10/bunnies.h || unknown || |- | hardware/lcd/ST7626/4x6.h || unknown || |- | hardware/lcd/ST7626/ST7626.h || unknown || |- | hardware/sram/sram.h || unknown || |- | hardware/storage/sd_reader/byteordering.* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/fat* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/partition* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd_raw* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd-reader_config.h || GPLv2/LGPLv2.1 || |- | protocols/bootp/bootphdr.h || unknown || |- | protocols/uip/uip-conf.h || unknown || |- | protocols/usb/usbconfig.h || GPLv2 || |- | protocols/ustream/vs1053.h || unknown || |- | services/glcdmenu/menu-interpreter/menudata-progmem.c || unknown || |- | services/glcdmenu/menu-interpreter/menu-interpreter-config.h || unknown || |- |} to find out all the authors of a certain file, run ''contrib/license-lister file'' . e.g. ''contrib/license-lister protocols/bootp/bootphdr.h'' * send an email to authors of source files with incompatible license == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD * Adam Dunkels' uIP Stack is licensed under the BSD http://en.wikipedia.org/wiki/UIP_(micro_IP) https://github.com/ethersex/ethersex/blob/master/protocols/uip/uip.c#L25 * MIT/X is compatible with GPLv3 ** http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing * reintegrate SD Reader library from http://www.roland-riegel.de/sd-reader/ ** done 7519df81d1fd46a54603665528821462396f33a4 145 144 2011-10-31T10:32:54Z GooPie4o 265 /* Current TODO List */ wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or any other incompatible licesne. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or any other incompatible license. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || NO |- |Riegel, Roland || N/A || N/A || N/A || N/A || N/A |- |} == Current TODO List == * collect files with incompatible license. {| border="1" ! File !! License !! Status |- | core/gui/font.c || 3-clause BSD || OK |- | core/host/avr/interrupt.h || unknown || |- | core/host/avr/io.h || unknown || |- | core/host/avr/pgmspace.h || unknown || |- | core/host/avr/wdt.h || unknown || |- | core/host/host.h || unknown || |- | core/host/util/crc16.h || unknown || |- | core/setbaud.h || unknown || |- | hardware/ir/irmp/irmp_lib.c || GPLv2+ || OK |- | hardware/lcd/s1d15g10/bunnies.h || unknown || |- | hardware/lcd/ST7626/4x6.h || unknown || |- | hardware/lcd/ST7626/ST7626.h || unknown || |- | hardware/sram/sram.h || unknown || |- | hardware/storage/sd_reader/byteordering.* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/fat* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/partition* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd_raw* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd-reader_config.h || GPLv2/LGPLv2.1 || |- | protocols/bootp/bootphdr.h || unknown || |- | protocols/uip/uip-conf.h || unknown || |- | protocols/usb/usbconfig.h || GPLv2 || |- | protocols/ustream/vs1053.h || unknown || |- | services/glcdmenu/menu-interpreter/menudata-progmem.c || unknown || |- | services/glcdmenu/menu-interpreter/menu-interpreter-config.h || unknown || |- |} to find out all the authors of a certain file, run ''contrib/license-lister file'' . e.g. ''contrib/license-lister protocols/bootp/bootphdr.h'' * send an email to authors of source files with incompatible license == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD * Adam Dunkels' uIP Stack is licensed under the BSD http://en.wikipedia.org/wiki/UIP_(micro_IP) https://github.com/ethersex/ethersex/blob/master/protocols/uip/uip.c#L25 * MIT/X is compatible with GPLv3 ** http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing * reintegrate SD Reader library from http://www.roland-riegel.de/sd-reader/ ** done e5eb3ddd6fe133475f3b2050a75f5ee0a933b0ae 146 145 2011-10-31T10:42:30Z GooPie4o 265 /* Current TODO List */ wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or any other incompatible licesne. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or any other incompatible license. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || NO |- |Riegel, Roland || N/A || N/A || N/A || N/A || N/A |- |} == Current TODO List == * collect files with incompatible license. {| border="1" ! File !! License !! Status |- | core/gui/font.c || 3-clause BSD || OK |- | core/host/avr/interrupt.h || unknown || |- | core/host/host.h || unknown || |- | core/host/util/crc16.h || unknown || |- | core/setbaud.h || unknown || |- | hardware/ir/irmp/irmp_lib.c || GPLv2+ || OK |- | hardware/lcd/s1d15g10/bunnies.h || unknown || |- | hardware/lcd/ST7626/4x6.h || unknown || |- | hardware/lcd/ST7626/ST7626.h || unknown || |- | hardware/sram/sram.h || unknown || |- | hardware/storage/sd_reader/byteordering.* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/fat* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/partition* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd_raw* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd-reader_config.h || GPLv2/LGPLv2.1 || |- | protocols/bootp/bootphdr.h || unknown || |- | protocols/uip/uip-conf.h || unknown || |- | protocols/usb/usbconfig.h || GPLv2 || |- | protocols/ustream/vs1053.h || unknown || |- | services/glcdmenu/menu-interpreter/menudata-progmem.c || unknown || |- | services/glcdmenu/menu-interpreter/menu-interpreter-config.h || unknown || |- |} to find out all the authors of a certain file, run ''contrib/license-lister file'' . e.g. ''contrib/license-lister protocols/bootp/bootphdr.h'' * send an email to authors of source files with incompatible license == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD * Adam Dunkels' uIP Stack is licensed under the BSD http://en.wikipedia.org/wiki/UIP_(micro_IP) https://github.com/ethersex/ethersex/blob/master/protocols/uip/uip.c#L25 * MIT/X is compatible with GPLv3 ** http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing * reintegrate SD Reader library from http://www.roland-riegel.de/sd-reader/ ** done d000b101ad583487d4f7392f79c459f8f4c16c9a 147 146 2011-10-31T10:57:19Z GooPie4o 265 /* Current TODO List */ wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or any other incompatible licesne. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or any other incompatible license. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || NO |- |Riegel, Roland || N/A || N/A || N/A || N/A || N/A |- |} == Current TODO List == * collect files with incompatible license. {| border="1" ! File !! License !! Status |- | core/gui/font.c || 3-clause BSD || OK |- | core/host/host.h || unknown || |- | core/host/util/crc16.h || unknown || |- | core/setbaud.h || unknown || |- | hardware/ir/irmp/irmp_lib.c || GPLv2+ || OK |- | hardware/lcd/s1d15g10/bunnies.h || unknown || |- | hardware/lcd/ST7626/4x6.h || unknown || |- | hardware/lcd/ST7626/ST7626.h || unknown || |- | hardware/sram/sram.h || unknown || |- | hardware/storage/sd_reader/byteordering.* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/fat* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/partition* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd_raw* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd-reader_config.h || GPLv2/LGPLv2.1 || |- | protocols/bootp/bootphdr.h || unknown || |- | protocols/uip/uip-conf.h || unknown || |- | protocols/usb/usbconfig.h || GPLv2 || |- | protocols/ustream/vs1053.h || unknown || |- | services/glcdmenu/menu-interpreter/menudata-progmem.c || unknown || |- | services/glcdmenu/menu-interpreter/menu-interpreter-config.h || unknown || |- |} to find out all the authors of a certain file, run ''contrib/license-lister file'' . e.g. ''contrib/license-lister protocols/bootp/bootphdr.h'' * send an email to authors of source files with incompatible license == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD * Adam Dunkels' uIP Stack is licensed under the BSD http://en.wikipedia.org/wiki/UIP_(micro_IP) https://github.com/ethersex/ethersex/blob/master/protocols/uip/uip.c#L25 * MIT/X is compatible with GPLv3 ** http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing * reintegrate SD Reader library from http://www.roland-riegel.de/sd-reader/ ** done d34eb29c6a3e8e073a2773c78c91ec2c9ba65c24 148 147 2011-10-31T12:06:46Z GooPie4o 265 /* Relicensing progress */ wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or any other incompatible licesne. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or any other incompatible license. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || NO |- |Riegel, Roland || N/A || N/A || N/A || N/A || N/A |- |} == Current TODO List == * collect files with incompatible license. {| border="1" ! File !! License !! Status |- | core/gui/font.c || 3-clause BSD || OK |- | core/host/host.h || unknown || |- | core/host/util/crc16.h || unknown || |- | core/setbaud.h || unknown || |- | hardware/ir/irmp/irmp_lib.c || GPLv2+ || OK |- | hardware/lcd/s1d15g10/bunnies.h || unknown || |- | hardware/lcd/ST7626/4x6.h || unknown || |- | hardware/lcd/ST7626/ST7626.h || unknown || |- | hardware/sram/sram.h || unknown || |- | hardware/storage/sd_reader/byteordering.* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/fat* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/partition* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd_raw* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd-reader_config.h || GPLv2/LGPLv2.1 || |- | protocols/bootp/bootphdr.h || unknown || |- | protocols/uip/uip-conf.h || unknown || |- | protocols/usb/usbconfig.h || GPLv2 || |- | protocols/ustream/vs1053.h || unknown || |- | services/glcdmenu/menu-interpreter/menudata-progmem.c || unknown || |- | services/glcdmenu/menu-interpreter/menu-interpreter-config.h || unknown || |- |} to find out all the authors of a certain file, run ''contrib/license-lister file'' . e.g. ''contrib/license-lister protocols/bootp/bootphdr.h'' * send an email to authors of source files with incompatible license == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD * Adam Dunkels' uIP Stack is licensed under the BSD http://en.wikipedia.org/wiki/UIP_(micro_IP) https://github.com/ethersex/ethersex/blob/master/protocols/uip/uip.c#L25 * MIT/X is compatible with GPLv3 ** http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing * reintegrate SD Reader library from http://www.roland-riegel.de/sd-reader/ ** done https://github.com/ethersex/ethersex/commit/0ba2a832b2f0e16e78cb26202b5e4fe4e266614b 36a66534c2b576576e174dceedf77903b70393cf 10 41 149 2011-10-31T17:51:59Z Mgue 312 first version wikitext text/x-wiki <noinclude>{{i18n|Template:NewWiki}}</noinclude> {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#FFAF4D; border:4px #aaa solid; font-size:95%; color:black; width:auto%;" |- |'''Welcome to the new Wiki of the ethersex project.''' This wiki is far from being complete, so please help us by contributing your knowledge! In search of the old wiki? [http://old.ethersex.de Go to old.ethersex.de] |- |} 73ff85e55d0e282594eba24cf0f1a4da9ff71360 151 149 2011-10-31T18:05:20Z Mgue 312 wikitext text/x-wiki <noinclude>{{i18n|Template:NewWiki}}</noinclude> {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#FFAF4D; border:4px #aaa solid; font-size:95%; color:black; width:auto%; padding: 15px; font-size: 15px" |- |'''Welcome to the new Wiki of the ethersex project.''' This wiki is far from being complete, so please help us by contributing your knowledge! In search of the old wiki? [http://old.ethersex.de Go to old.ethersex.de] |- |} 8cd41c253c72c76800acc440d4f39ac694e8a055 0 5 150 100 2011-10-31T17:52:23Z Mgue 312 wikitext text/x-wiki {{i18n|Main Page}} {{NewWiki}} == Welcome ethersex - the universial AVR firmware == {{Facts}} {|style="width:100%" |style="width:50%"|{{Getting Started}} |style="width:50%"|{{Documentation}} |- |} dcdfcfaa82985a6d4a299ceecf3b64ce1b96984c 0 5 152 150 2011-10-31T19:57:15Z Chris 276 /* Welcome ethersex - the universial AVR firmware */ wikitext text/x-wiki {{i18n|Main Page}} {{NewWiki}} == Welcome ethersex - the universal AVR firmware == {{Facts}} {|style="width:100%" |style="width:50%"|{{Getting Started}} |style="width:50%"|{{Documentation}} |- |} ef7bff24630f3fb18aaed1bb4632267c81ab9c5e 153 152 2011-10-31T20:09:42Z Mgue 312 wikitext text/x-wiki {{i18n|Main Page}} {{NewWiki}} == Welcome to ethersex.de - the universal AVR firmware == {{Facts}} {|style="width:100%" |style="width:50%"|{{Getting Started}} |style="width:50%"|{{Documentation}} |- |} 0e05e31a34b111f2f6bd3749ae463515189c8f0a 0 42 154 2011-11-04T00:01:41Z Arazer 125 Created page with "=== Download the Source from GITHUB === You can download Ethersex from github via git protocol git clone git://github.com/ethersex/ethersex.git or via http git clone http:/…" wikitext text/x-wiki === Download the Source from GITHUB === You can download Ethersex from github via git protocol git clone git://github.com/ethersex/ethersex.git or via http git clone http://github.com/ethersex/ethersex.git Updating a local version of ethersex is possible with: git pull origin 9d1a125a9af6f8ee828b371c768bf028c36168ac 155 154 2011-11-04T00:08:57Z Arazer 125 /* Download the Source from GITHUB */ wikitext text/x-wiki === Download the Source from GITHUB === You can download Ethersex from github via git protocol git clone git://github.com/ethersex/ethersex.git or via http git clone http://github.com/ethersex/ethersex.git Updating a local version of ethersex is possible with: git pull origin === Requirements === AVR GCC-Compiler (Version 4.1 or higher) AVR LIBC (Version 1.6.8, for 128er ATMegas 1.7) GNU-Tools (Bash, Make, m4, awk) AVR-Programmer (e.g. avrdude) Linux Debian / Ubuntu apt-get install gcc-avr avr-libc binutils-avr m4 gawk libncurses5-dev make dialog git-core avrdude Mac OSX Using MacPorts (www.macports.org) Apple Bash and sed doesn't work, you need to install Bash V4.0 and GNU sed. port install git avrdude avr-binutils avr-gcc avr-libc bash sed d0676146d707279d9ad03b6b5005235115ad69a1 156 155 2011-11-04T00:09:47Z Arazer 125 /* Requirements */ wikitext text/x-wiki === Download the Source from GITHUB === You can download Ethersex from github via git protocol git clone git://github.com/ethersex/ethersex.git or via http git clone http://github.com/ethersex/ethersex.git Updating a local version of ethersex is possible with: git pull origin === Requirements === * AVR GCC-Compiler (Version 4.1 or higher) * AVR LIBC (Version 1.6.8, for 128er ATMegas 1.7) * GNU-Tools (Bash, Make, m4, awk) * AVR-Programmer (e.g. avrdude) == Linux Debian / Ubuntu == apt-get install gcc-avr avr-libc binutils-avr m4 gawk libncurses5-dev make dialog git-core avrdude == Mac OSX == Using MacPorts (www.macports.org) Apple Bash and sed doesn't work, you need to install Bash V4.0 and GNU sed. port install git avrdude avr-binutils avr-gcc avr-libc bash sed 6ceef7e1aa37d87cab30da63eb54fa7d3c56f31a 158 156 2011-11-04T07:19:53Z Mgue 312 added language template wikitext text/x-wiki {{i18n|Quick Start Guide}} === Download the Source from GITHUB === You can download Ethersex from github via git protocol git clone git://github.com/ethersex/ethersex.git or via http git clone http://github.com/ethersex/ethersex.git Updating a local version of ethersex is possible with: git pull origin === Requirements === * AVR GCC-Compiler (Version 4.1 or higher) * AVR LIBC (Version 1.6.8, for 128er ATMegas 1.7) * GNU-Tools (Bash, Make, m4, awk) * AVR-Programmer (e.g. avrdude) == Linux Debian / Ubuntu == apt-get install gcc-avr avr-libc binutils-avr m4 gawk libncurses5-dev make dialog git-core avrdude == Mac OSX == Using MacPorts (www.macports.org) Apple Bash and sed doesn't work, you need to install Bash V4.0 and GNU sed. port install git avrdude avr-binutils avr-gcc avr-libc bash sed 8ce90ee1bae5df45608808cfc49aa63a6677c883 186 158 2011-11-09T15:18:16Z Morais 209 /* Mac OSX */ wikitext text/x-wiki {{i18n|Quick Start Guide}} === Download the Source from GITHUB === You can download Ethersex from github via git protocol git clone git://github.com/ethersex/ethersex.git or via http git clone http://github.com/ethersex/ethersex.git Updating a local version of ethersex is possible with: git pull origin === Requirements === * AVR GCC-Compiler (Version 4.1 or higher) * AVR LIBC (Version 1.6.8, for 128er ATMegas 1.7) * GNU-Tools (Bash, Make, m4, awk) * AVR-Programmer (e.g. avrdude) == Linux Debian / Ubuntu == apt-get install gcc-avr avr-libc binutils-avr m4 gawk libncurses5-dev make dialog git-core avrdude == Mac OSX == Using MacPorts (www.macports.org) Apple Bash and sed doesn't work, you need to install Bash V4.0 and GNU sed. port install git avrdude avr-binutils avr-gcc avr-libc bash sed If the MacPort versions of avr-gcc or avrdude are too old. Here is a instuction how to build the toolchain manually: [http://www.heise.de/ct/projekte/machmit/ctbot/wiki/AVRToolchain] 8e2f1e00929c31b8e17541219c7a0afdf6893529 188 186 2011-11-11T13:40:17Z Arazer 125 /* Mac OSX */ wikitext text/x-wiki {{i18n|Quick Start Guide}} === Download the Source from GITHUB === You can download Ethersex from github via git protocol git clone git://github.com/ethersex/ethersex.git or via http git clone http://github.com/ethersex/ethersex.git Updating a local version of ethersex is possible with: git pull origin === Requirements === * AVR GCC-Compiler (Version 4.1 or higher) * AVR LIBC (Version 1.6.8, for 128er ATMegas 1.7) * GNU-Tools (Bash, Make, m4, awk) * AVR-Programmer (e.g. avrdude) == Linux Debian / Ubuntu == apt-get install gcc-avr avr-libc binutils-avr m4 gawk libncurses5-dev make dialog git-core avrdude == Mac OSX == Using MacPorts (www.macports.org) Apple Bash and sed doesn't work, you need to install Bash V4.0 and GNU sed. First, sync the Port Repository to ensure that you´ll build the latest versions of the requirements. port selfupgrade port install git avrdude avr-binutils avr-gcc avr-libc bash sed You can also use the CrossPack, but MacPorts is more straightforward and updated. [http://www.obdev.at/products/crosspack/index-de.html] 44cbf88f816cc84423059e9c4ae56a03af3c8314 189 188 2011-11-11T13:52:29Z Arazer 125 /* Mac OSX */ wikitext text/x-wiki {{i18n|Quick Start Guide}} === Download the Source from GITHUB === You can download Ethersex from github via git protocol git clone git://github.com/ethersex/ethersex.git or via http git clone http://github.com/ethersex/ethersex.git Updating a local version of ethersex is possible with: git pull origin === Requirements === * AVR GCC-Compiler (Version 4.1 or higher) * AVR LIBC (Version 1.6.8, for 128er ATMegas 1.7) * GNU-Tools (Bash, Make, m4, awk) * AVR-Programmer (e.g. avrdude) == Linux Debian / Ubuntu == apt-get install gcc-avr avr-libc binutils-avr m4 gawk libncurses5-dev make dialog git-core avrdude == Mac OSX == Using MacPorts (www.macports.org) Apple Bash and sed doesn't work, you need to install Bash V4.0 and GNU sed. First, sync the Port Repository to ensure that you´ll build the latest versions of the requirements. port selfupgrade port install git-core avrdude avr-binutils avr-gcc avr-libc bash sed You can also use the CrossPack, but MacPorts is more straightforward and updated. [http://www.obdev.at/products/crosspack/index-de.html] 3947a4834e587e0c54a2b01c6c087c93a6b4d73d 10 20 157 103 2011-11-04T00:17:42Z Arazer 125 wikitext text/x-wiki <noinclude>{{i18n|Template:Facts}}</noinclude> {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | colspan=2 style="background-color: #FFFFFF; text-align: center; border-bottom:1px solid #aaaaaa;" | '''Overview''' |- |Ethersex is a community driven firmware with network support for 8-bit AVR microcontrollers. {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- !style="width:50%" | Features !style="width:50%" | Supported Boards |- | * Support for atmega 8,16,32,64,128,644 and many more * Uses the common '''ENC28J60''' * easily customizable and expandable to suit your needs Protocols: * TCP/IP IPv4/'''IPv6''' * OpenVPN * Software USB stack * RFM12 (433 MHz) * '''i²c''' Master (numerous chips supported)/Slave * onewire * http server * can be controlled remotely using the '''Ethersex Command Protocol (ECMD)''' * [[Features|and many more]] | * NetIO (Pollin) * Etherrape (lochraster.org) * AVR Module (Ulrich Radig) * Jackalope (lochraster.org * Probot (Conrad) * Fimser (OV Lennestadt) * JeeLink v2 (JeeLabs) * Funk-AVR-Evaluationsboard (Pollin) * TODO: Custom Board * [[Supported Boards |any many more]] |} |} 83d3d449aa7e8882e21997ae38fc28d58f1b014a 206 157 2011-11-22T21:26:11Z Weef 314 added RFM12B and frequ 868 MHz wikitext text/x-wiki <noinclude>{{i18n|Template:Facts}}</noinclude> {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | colspan=2 style="background-color: #FFFFFF; text-align: center; border-bottom:1px solid #aaaaaa;" | '''Overview''' |- |Ethersex is a community driven firmware with network support for 8-bit AVR microcontrollers. {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- !style="width:50%" | Features !style="width:50%" | Supported Boards |- | * Support for atmega 8,16,32,64,128,644 and many more * Uses the common '''ENC28J60''' * easily customizable and expandable to suit your needs Protocols: * TCP/IP IPv4/'''IPv6''' * OpenVPN * software USB stack * RFM12 / RFM12B (433 MHz / 868 MHz) * '''i²c''' Master (numerous chips supported)/Slave * onewire * http server * can be controlled remotely using the '''Ethersex Command Protocol (ECMD)''' * [[Features|and many more]] | * NetIO (Pollin) * Etherrape (lochraster.org) * AVR Module (Ulrich Radig) * Jackalope (lochraster.org * Probot (Conrad) * Fimser (OV Lennestadt) * JeeLink v2 (JeeLabs) * Funk-AVR-Evaluationsboard (Pollin) * TODO: Custom Board * [[Supported Boards |any many more]] |} |} 4591e918b3bc80bbdc57cc00850019b82753e5fe 0 35 159 148 2011-11-04T11:25:40Z Mgue 312 /* Current TODO List */ wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or any other incompatible licesne. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or any other incompatible license. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || NO |- |Riegel, Roland || N/A || N/A || N/A || N/A || N/A |- |} == Current TODO List == * collect files with incompatible license. {| border="1" ! File !! License !! Status |- | core/gui/font.c || 3-clause BSD || OK |- | core/host/host.h || unknown || |- | core/host/util/crc16.h || unknown || |- | core/setbaud.h || unknown || |- | hardware/ir/irmp/irmp_lib.c || GPLv2+ || OK |- | hardware/lcd/s1d15g10/bunnies.h || unknown || |- | hardware/lcd/ST7626/4x6.h || unknown || |- | hardware/lcd/ST7626/ST7626.h || unknown || |- | hardware/sram/sram.h || unknown || |- | hardware/storage/sd_reader/byteordering.* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/fat* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/partition* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd_raw* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd-reader_config.h || GPLv2/LGPLv2.1 || |- | protocols/bootp/bootphdr.h || unknown || |- | protocols/uip/uip-conf.h || unknown || |- | protocols/usb/usbconfig.h || GPLv2 || |- | protocols/ustream/vs1053.h || unknown || |- | services/glcdmenu/menu-interpreter/menudata-progmem.c || unknown || contacted 4.11.11 |- | services/glcdmenu/menu-interpreter/menu-interpreter-config.h || unknown || contacted 4.11.11 |- |} to find out all the authors of a certain file, run ''contrib/license-lister file'' . e.g. ''contrib/license-lister protocols/bootp/bootphdr.h'' * send an email to authors of source files with incompatible license == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD * Adam Dunkels' uIP Stack is licensed under the BSD http://en.wikipedia.org/wiki/UIP_(micro_IP) https://github.com/ethersex/ethersex/blob/master/protocols/uip/uip.c#L25 * MIT/X is compatible with GPLv3 ** http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing * reintegrate SD Reader library from http://www.roland-riegel.de/sd-reader/ ** done https://github.com/ethersex/ethersex/commit/0ba2a832b2f0e16e78cb26202b5e4fe4e266614b 0d211d724787e2ff3cc0218990a5f60c3860b9ae 160 159 2011-11-04T11:31:44Z Mgue 312 /* Current TODO List */ wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or any other incompatible licesne. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or any other incompatible license. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || NO |- |Riegel, Roland || N/A || N/A || N/A || N/A || N/A |- |} == Current TODO List == * collect files with incompatible license. {| border="1" ! File !! License !! Status |- | core/gui/font.c || 3-clause BSD || OK |- | core/host/host.h || unknown || |- | core/host/util/crc16.h || unknown || |- | core/setbaud.h || unknown || |- | hardware/ir/irmp/irmp_lib.c || GPLv2+ || OK |- | hardware/lcd/s1d15g10/bunnies.h || unknown || |- | hardware/lcd/ST7626/4x6.h || unknown || |- | hardware/lcd/ST7626/ST7626.h || unknown || |- | hardware/sram/sram.h || unknown || |- | hardware/storage/sd_reader/byteordering.* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/fat* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/partition* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd_raw* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd-reader_config.h || GPLv2/LGPLv2.1 || |- | protocols/bootp/bootphdr.h || unknown || |- | protocols/uip/uip-conf.h || unknown || |- | protocols/usb/usbconfig.h || GPLv2 || critical, see [http://www.obdev.at/products/vusb/license-de.html link] |- | protocols/ustream/vs1053.h || unknown || |- | services/glcdmenu/menu-interpreter/menudata-progmem.c || unknown || contacted 4.11.11 |- | services/glcdmenu/menu-interpreter/menu-interpreter-config.h || unknown || contacted 4.11.11 |- |} to find out all the authors of a certain file, run ''contrib/license-lister file'' . e.g. ''contrib/license-lister protocols/bootp/bootphdr.h'' * send an email to authors of source files with incompatible license == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD * Adam Dunkels' uIP Stack is licensed under the BSD http://en.wikipedia.org/wiki/UIP_(micro_IP) https://github.com/ethersex/ethersex/blob/master/protocols/uip/uip.c#L25 * MIT/X is compatible with GPLv3 ** http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing * reintegrate SD Reader library from http://www.roland-riegel.de/sd-reader/ ** done https://github.com/ethersex/ethersex/commit/0ba2a832b2f0e16e78cb26202b5e4fe4e266614b 94be2791d0d7e4986fdeffbe1823827601bfa9f4 161 160 2011-11-04T11:50:57Z Mgue 312 /* Current TODO List */ wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or any other incompatible licesne. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or any other incompatible license. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || NO |- |Riegel, Roland || N/A || N/A || N/A || N/A || N/A |- |} == Current TODO List == * collect files with incompatible license. {| border="1" ! File !! License !! Status |- | core/gui/font.c || 3-clause BSD || OK |- | core/host/host.h || unknown || |- | core/host/util/crc16.h || unknown || |- | core/setbaud.h || unknown || |- | hardware/ir/irmp/irmp_lib.c || GPLv2+ || OK |- | hardware/lcd/s1d15g10/bunnies.h || unknown || |- | hardware/lcd/ST7626/4x6.h || unknown || |- | hardware/lcd/ST7626/ST7626.h || unknown || |- | hardware/sram/sram.h || unknown || |- | hardware/storage/sd_reader/byteordering.* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/fat* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/partition* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd_raw* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd-reader_config.h || GPLv2/LGPLv2.1 || |- | protocols/bootp/bootphdr.h || unknown || |- | protocols/uip/uip-conf.h || unknown || |- | protocols/usb/usbconfig.h || GPLv2 || critical, see [http://www.obdev.at/products/vusb/license-de.html link] |- | protocols/ustream/vs1053.h || unknown || contacted 4.11.11 |- | protocols/ustream/vs1053.h || unknown || contacted 4.11.11 |- | services/glcdmenu/menu-interpreter/menudata-progmem.c || unknown || contacted 4.11.11 |- | services/glcdmenu/menu-interpreter/menu-interpreter-config.h || unknown || contacted 4.11.11 |- |} to find out all the authors of a certain file, run ''contrib/license-lister file'' . e.g. ''contrib/license-lister protocols/bootp/bootphdr.h'' * send an email to authors of source files with incompatible license == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD * Adam Dunkels' uIP Stack is licensed under the BSD http://en.wikipedia.org/wiki/UIP_(micro_IP) https://github.com/ethersex/ethersex/blob/master/protocols/uip/uip.c#L25 * MIT/X is compatible with GPLv3 ** http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing * reintegrate SD Reader library from http://www.roland-riegel.de/sd-reader/ ** done https://github.com/ethersex/ethersex/commit/0ba2a832b2f0e16e78cb26202b5e4fe4e266614b f0cd3bb2b884a56fd7d857c83c334a750c22bd3d 162 161 2011-11-04T11:51:11Z Mgue 312 /* Current TODO List */ wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or any other incompatible licesne. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or any other incompatible license. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || NO |- |Riegel, Roland || N/A || N/A || N/A || N/A || N/A |- |} == Current TODO List == * collect files with incompatible license. {| border="1" ! File !! License !! Status |- | core/gui/font.c || 3-clause BSD || OK |- | core/host/host.h || unknown || |- | core/host/util/crc16.h || unknown || |- | core/setbaud.h || unknown || |- | hardware/ir/irmp/irmp_lib.c || GPLv2+ || OK |- | hardware/lcd/s1d15g10/bunnies.h || unknown || |- | hardware/lcd/ST7626/4x6.h || unknown || |- | hardware/lcd/ST7626/ST7626.h || unknown || |- | hardware/sram/sram.h || unknown || |- | hardware/storage/sd_reader/byteordering.* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/fat* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/partition* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd_raw* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd-reader_config.h || GPLv2/LGPLv2.1 || |- | protocols/bootp/bootphdr.h || unknown || |- | protocols/uip/uip-conf.h || unknown || |- | protocols/usb/usbconfig.h || GPLv2 || critical, see [http://www.obdev.at/products/vusb/license-de.html link] |- | protocols/ustream/vs1053.c || unknown || contacted 4.11.11 |- | protocols/ustream/vs1053.h || unknown || contacted 4.11.11 |- | services/glcdmenu/menu-interpreter/menudata-progmem.c || unknown || contacted 4.11.11 |- | services/glcdmenu/menu-interpreter/menu-interpreter-config.h || unknown || contacted 4.11.11 |- |} to find out all the authors of a certain file, run ''contrib/license-lister file'' . e.g. ''contrib/license-lister protocols/bootp/bootphdr.h'' * send an email to authors of source files with incompatible license == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD * Adam Dunkels' uIP Stack is licensed under the BSD http://en.wikipedia.org/wiki/UIP_(micro_IP) https://github.com/ethersex/ethersex/blob/master/protocols/uip/uip.c#L25 * MIT/X is compatible with GPLv3 ** http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing * reintegrate SD Reader library from http://www.roland-riegel.de/sd-reader/ ** done https://github.com/ethersex/ethersex/commit/0ba2a832b2f0e16e78cb26202b5e4fe4e266614b 6923ae5a8c928d473f5b59d999153d76bef41471 171 162 2011-11-07T17:05:21Z Mgue 312 /* Current TODO List */ wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or any other incompatible licesne. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or any other incompatible license. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || NO |- |Riegel, Roland || N/A || N/A || N/A || N/A || N/A |- |} == Current TODO List == * collect files with incompatible license. {| border="1" ! File !! License !! Status |- | core/gui/font.c || 3-clause BSD || OK |- | core/host/host.h || unknown || |- | core/host/util/crc16.h || unknown || |- | core/setbaud.h || unknown || |- | hardware/ir/irmp/irmp_lib.c || GPLv2+ || OK |- | hardware/lcd/s1d15g10/bunnies.h || unknown || |- | hardware/lcd/ST7626/4x6.h || unknown || |- | hardware/lcd/ST7626/ST7626.h || unknown || |- | hardware/sram/sram.h || unknown || |- | hardware/storage/sd_reader/byteordering.* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/fat* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/partition* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd_raw* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd-reader_config.h || GPLv2/LGPLv2.1 || |- | protocols/bootp/bootphdr.h || unknown || |- | protocols/uip/uip-conf.h || unknown || |- | protocols/usb/usbconfig.h || GPLv2 || critical, see [http://www.obdev.at/products/vusb/license-de.html link] |- | protocols/ustream/vs1053.c || unknown || contacted 4.11.11, replied - agreed on MIT |- | protocols/ustream/vs1053.h || unknown || contacted 4.11.11, replied - agreed on MIT |- | services/glcdmenu/menu-interpreter/menudata-progmem.c || unknown || contacted 4.11.11 |- | services/glcdmenu/menu-interpreter/menu-interpreter-config.h || unknown || contacted 4.11.11 |- |} to find out all the authors of a certain file, run ''contrib/license-lister file'' . e.g. ''contrib/license-lister protocols/bootp/bootphdr.h'' * send an email to authors of source files with incompatible license == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD * Adam Dunkels' uIP Stack is licensed under the BSD http://en.wikipedia.org/wiki/UIP_(micro_IP) https://github.com/ethersex/ethersex/blob/master/protocols/uip/uip.c#L25 * MIT/X is compatible with GPLv3 ** http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing * reintegrate SD Reader library from http://www.roland-riegel.de/sd-reader/ ** done https://github.com/ethersex/ethersex/commit/0ba2a832b2f0e16e78cb26202b5e4fe4e266614b 05a2ef3ff099f4d702ebbfa8516d78ce5bf92638 216 171 2011-11-26T20:30:45Z Mgue 312 /* Current TODO List */ wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or any other incompatible licesne. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or any other incompatible license. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || NO |- |Riegel, Roland || N/A || N/A || N/A || N/A || N/A |- |} == Current TODO List == * collect files with incompatible license. {| border="1" ! File !! License !! Status |- | core/gui/font.c || 3-clause BSD || OK |- | core/host/host.h || unknown || |- | core/host/util/crc16.h || unknown || |- | core/setbaud.h || unknown || |- | hardware/ir/irmp/irmp_lib.c || GPLv2+ || OK |- | hardware/lcd/s1d15g10/bunnies.h || unknown || |- | hardware/lcd/ST7626/4x6.h || unknown || |- | hardware/lcd/ST7626/ST7626.h || unknown || |- | hardware/sram/sram.h || unknown || |- | hardware/storage/sd_reader/byteordering.* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/fat* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/partition* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd_raw* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd-reader_config.h || GPLv2/LGPLv2.1 || |- | protocols/bootp/bootphdr.h || unknown || |- | protocols/uip/uip-conf.h || unknown || |- | protocols/usb/usbconfig.h || GPLv2 || critical, see [http://www.obdev.at/products/vusb/license-de.html link] |- | protocols/ustream/vs1053.c || unknown || contacted 4.11.11, replied - agreed on MIT |- | protocols/ustream/vs1053.h || unknown || contacted 4.11.11, replied - agreed on MIT |- | services/glcdmenu/menu-interpreter/menudata-progmem.c || unknown || contacted 4.11.11, generated code - no need to license |- | services/glcdmenu/menu-interpreter/menu-interpreter-config.h || unknown || contacted 4.11.11, generated code - no need to license |- |} to find out all the authors of a certain file, run ''contrib/license-lister file'' . e.g. ''contrib/license-lister protocols/bootp/bootphdr.h'' * send an email to authors of source files with incompatible license == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD * Adam Dunkels' uIP Stack is licensed under the BSD http://en.wikipedia.org/wiki/UIP_(micro_IP) https://github.com/ethersex/ethersex/blob/master/protocols/uip/uip.c#L25 * MIT/X is compatible with GPLv3 ** http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing * reintegrate SD Reader library from http://www.roland-riegel.de/sd-reader/ ** done https://github.com/ethersex/ethersex/commit/0ba2a832b2f0e16e78cb26202b5e4fe4e266614b 4e74854a6d7547fc26be7aed87165becaaf614d1 217 216 2011-11-27T15:22:22Z GooPie4o 265 /* Current Reply List */ wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or any other incompatible licesne. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or any other incompatible license. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || NO |- |Riegel, Roland || NO || NO || NO || NO || NO |- |} == Current TODO List == * collect files with incompatible license. {| border="1" ! File !! License !! Status |- | core/gui/font.c || 3-clause BSD || OK |- | core/host/host.h || unknown || |- | core/host/util/crc16.h || unknown || |- | core/setbaud.h || unknown || |- | hardware/ir/irmp/irmp_lib.c || GPLv2+ || OK |- | hardware/lcd/s1d15g10/bunnies.h || unknown || |- | hardware/lcd/ST7626/4x6.h || unknown || |- | hardware/lcd/ST7626/ST7626.h || unknown || |- | hardware/sram/sram.h || unknown || |- | hardware/storage/sd_reader/byteordering.* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/fat* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/partition* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd_raw* || GPLv2/LGPLv2.1 || |- | hardware/storage/sd_reader/sd-reader_config.h || GPLv2/LGPLv2.1 || |- | protocols/bootp/bootphdr.h || unknown || |- | protocols/uip/uip-conf.h || unknown || |- | protocols/usb/usbconfig.h || GPLv2 || critical, see [http://www.obdev.at/products/vusb/license-de.html link] |- | protocols/ustream/vs1053.c || unknown || contacted 4.11.11, replied - agreed on MIT |- | protocols/ustream/vs1053.h || unknown || contacted 4.11.11, replied - agreed on MIT |- | services/glcdmenu/menu-interpreter/menudata-progmem.c || unknown || contacted 4.11.11, generated code - no need to license |- | services/glcdmenu/menu-interpreter/menu-interpreter-config.h || unknown || contacted 4.11.11, generated code - no need to license |- |} to find out all the authors of a certain file, run ''contrib/license-lister file'' . e.g. ''contrib/license-lister protocols/bootp/bootphdr.h'' * send an email to authors of source files with incompatible license == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD * Adam Dunkels' uIP Stack is licensed under the BSD http://en.wikipedia.org/wiki/UIP_(micro_IP) https://github.com/ethersex/ethersex/blob/master/protocols/uip/uip.c#L25 * MIT/X is compatible with GPLv3 ** http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing * reintegrate SD Reader library from http://www.roland-riegel.de/sd-reader/ ** done https://github.com/ethersex/ethersex/commit/0ba2a832b2f0e16e78cb26202b5e4fe4e266614b 21c5defadbcdbbb4aa03bc0601e4f8d81b39c9eb 0 43 163 2011-11-04T19:54:48Z LadySM 0 Importing text file wikitext text/x-wiki <div class="errorbox"> This page is automatically generated from the files in the Ethersex source code repository. Do not edit this page but send [[patches]] for those files! </div> __NOTOC__ == Analog/Digital Conversion ([[ADC]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | adc get [CHANNEL] | Get the ADC value in hex of CHANNEL or if no channel set of all channels. |- | hr20 temp | Read HR20 temperature sensor. |- |} == DNS Resolver == {| border='1' | ''Command syntax'' | ''Short description'' |- | dns server [IPADDR] | Display/Set the IP address of the DNS server to use to IPADDR. |- | nslookup HOSTNAME | Do DNS lookup for HOSTNAME (call twice). |- |} == Digital/Analog Conversion ([[DAC]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ltc1257_delay `[VALUE] | Set (if VALUE given) or get (no VALUE) delay for LTC1257 output bit changes in µs' |- | ltc1257_set `[VALUE0] [VALUE1] ... | Set output to value (value: 0-4095)' |- | tlc5620 `[CHANNEL] [VALUE] | Set Output to value (Value: 0-0xff)' |- |} == Fnordlicht == {| border='1' | ''Command syntax'' | ''Short description'' |- | fnordlicht "ADDRESS RED | GREEN,BLUE",fnordlicht command to set RGB color |- | fnordlicht_init | fnordlicht init |- |} == HD44780 [[LCD]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | hr20 hourbar START STOP | Update hourbar to show ticks between START and STOP (range 0..23) |- | hr20 toggle SEG | Toggle segment SEG (a number, not a symbolic name!) |- | lcd backlight STATE | switch back light STATE to ON or OFF |- | lcd char N D1 D2 D3 D4 D5 D6 D7 D8 | Define use-definable char N with data D1..D8 (provide DATA in hex) |- | lcd clear [LINE] | Clear line LINE (0..3) or the whole display (if parameter is omitted) |- | lcd goto LINE COL | Move cursor to LINE and column COL (origin is 0/0) |- | lcd reinit CURSOR BLINK | Reinitialize the display, set whether to show the cursor (CURSOR, 0 or 1) and whether the cursor shall BLINK |- | lcd shift DIR | Shift the display to DIR (either ''left'' or ''right'') |- | lcd write TEXT | Write TEXT to the current cursor location |- |} == Infrared Send/Receive ([[IR-TRX]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ir receive | receive an IR command |- | ir send DEVICE COMMAND | send COMMAND to DEVICE |- |} == Infrared Send/Receive ([[IRMP]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | irmp receive | receive an IR command |- | irmp send PROTOCOL DEVICE COMMAND REPEAT | send COMMAND with REPEAT flag to DEVICE using PROTOCOL |- |} == NTP Client == {| border='1' | ''Command syntax'' | ''Short description'' |- | ntp query | Query the NTP server to get an NTP update. |- | ntp server [IPADDR] | Display/Set the IP address of the NTP server to use to IPADDR. |- | ntp status | Display NTP server status |- |} == Network configuration == {| border='1' | ''Command syntax'' | ''Short description'' |- | enc dump | Dump the internal state of the enc to serial |- | gw [IP] | Display/Set the address of the default router. |- | ip [IP] | Display/Set the IP address. |- | mac [xx:xx:xx:xx:xx:xx] | Display/Set the MAC address. |- | netmask [IP] | Display/Set the network mask. |- |} == Port I/O == {| border='1' | ''Command syntax'' | ''Short description'' |- | io get ddr PORTNUM | Display the current value of the DDR PORTNUM. |- | io get mask PORTNUM | Display the mask of the port PORTNUM. |- | io get pin PORTNUM | Display the current value of the PIN-register of the port PORTNUM. |- | io get port NUM | Display the current value of the PORT NUM. |- | io set ddr PORTNUM HEXVALUE [MASK] | Set the DDR of port PORTNUM to VALUE (possibly using the provided MASK). |- | io set port NUM HEXVALUE [MASK] | Set the PORT NUM to VALUE (possibly using the provided MASK). |- |} == Reading and Writing EEPROM Space on Device == {| border='1' | ''Command syntax'' | ''Short description'' |- | eer eer <ADDR> <LENGTH> | Read n bytes from address after the config in eeprom. |- | eew eew <ADDR> <HEXBYTES> | Write Hexbytes at address after the config in epprom. |- | fuse | Display current fuse settings |- | hostname | Display hostname. |- |} == Resetting the controller == {| border='1' | ''Command syntax'' | ''Short description'' |- | bootloader | Call the bootloader. |- | reset | Reset the Ethersex. |- | wdreset | Go into endless loop to trigger a watchdog timeout. |- |} == [[ADS]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | ads get | Get the ADC value in hex. |- | ads mean [COUNT] | Get the mean of power of 2 COUNT ADC values in hex. |- |} == [[Am_Puls_der_Zeit|Clock]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | date | Display the current date. |- | lastdcf | Display when last valid DCF Signal was received. |- | time [UNIXTIME] | Display/Set the current time in seconds since January 1st 1970. |- | uptime | Display ethersex uptime in unix format. |- | whm | Display ethersex uptime. |- |} == [[Application_Sample]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sample | Manually call application sample commands |- | sample_init | Manually call application sample init method |- | sample_periodic | Manually call application sample periodic method |- |} == [[Blinkenlights_MCUF|MCUF]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | mcuf modul N | Select module N |- | mcuf modul list | List all modules |- | mcuf showclock | Show digital clock |- | mcuf showstring MESSAGE | Show scrolling MESSAGE on the display |- |} == [[CRON-Dienst]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | cron_add MIN HOUR DAY MONTH DOW ECMD | Add ECMD to cron to be executed at given time |- | cron_list | Show all cron entries |- | cron_make_persistent | Mark a Job as persistent |- | cron_rm POSITION | Remove one cron entry |- | cron_save | Saves all persistent jobs |- |} == [[DALI]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dali cmd [TARGET] [COMMAND] [!][?] | "send the given command (decimal) to targets (all, g00 to g15, s00 to s63), auto repeat with !, read reply with ?" |- | dali dim [TARGET] [LEVEL] | "dim targets (all, g00 to g15, s00 to s63) to given level (0-254)" |- | dali raw [BYTE1] [BYTE2] | "send a raw frame (two bytes, given in hex) over the DALI bus" |- | dali scmd [SPECIAL COMMAND] [DATA] [!][?] | "send special command (256-287) with data, auto repeat with !, read reply with ?" |- |} == [[DMX_Effect]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx rainbow | switch rainbow on (1) or off (0) |- | dmx random | switch random on (1) or off (0) |- |} == [[DMX_Storage]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx channels | Get channels per universe |- | dmx get | Return channel value |- | dmx set | Set channel values |- | dmx universe | Get a whole universe |- | dmx universes | Get universes |- |} == [[Dallas_1-wire_Bus]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | 1w convert [DEVICE] | Trigger temperature conversion of either DEVICE or all connected devices |- | 1w ds2450 convert [DEVICE] | `start conversion (with optional input mask and read out control)' |- | 1w ds2450 get [DEVICE] | `get conversion result (one or all channels)' |- | 1w ds2450 oc [DEVICE] | `get/set output control (per channel)' |- | 1w ds2450 oe [DEVICE] | `get/set output enable (per channel)' |- | 1w ds2450 por [DEVICE] | `get/set power on reset (per channel)' |- | 1w ds2450 power [DEVICE] | `get/set power supply of device (global)' |- | 1w ds2450 range [DEVICE] | `get/set input voltage range (per channel)' |- | 1w ds2450 res [DEVICE] | `get/set bit resolution of AD convert (per channel)' |- | 1w get DEVICE | Return temperature value of onewire DEVICE (provide 64-bit ID as 16-hex-digits) |- | 1w list | Return a list of the connected onewire devices |- |} == [[DataFlash]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | df status | Display internal status. |- | fs format | Format the filesystem. |- | fs inspect inode INODE | Inspect INODE (and associated page). |- | fs inspect node NODE | Inspect NODE and dump to serial. |- | fs list | List the directory. |- | fs mkfile NAME | Create a new file NAME. |- | fs remove NAME | Delete the file NAME. |- | fs truncate NAME LEN | Truncate the file NAME to LEN bytes. |- |} == [[Dc3840_camera|DC3840 mobil camera support]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dc3840 capture | Take a picture. Access 'dc3840' via VFS afterwards. See [[DC3840 Camera]] for details. |- | dc3840 light | Light level of camera |- | dc3840 send A B C D E | Send provided command bytes to the camera. |- | dc3840 sync | Re-sync to the camera |- | dc3840 zoom | Enable zoom of camera |- |} == [[ECMDScript]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | call FILENAME | Start script named FILENAME |- | cat FILENAME | cat file content (with debug only) |- | dec VAR | Decrement variable VAR (a number) |- | echo <any> | Print out all arguments of echo |- | exit | Exit currently running script |- | get VAR | Get value of variable VAR |- | goto N | Goto line N in currently running script |- | if ( CMD/VAR == CONST ) then CMD2 | If condition matches execute CMD2 |- | inc VAR | Increment variable VAR (a number) |- | rem <any> | Remark for anything |- | set VAR VALUE | Set variable VAR to VALUE |- | wait I | Wait I milliseconds |- |} == [[FS20]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fht send HOUSECODE ADDR CMD [CMD2] | Send FHT command. See [[FS20]] for details. |- | fs20 receive | Receive FS20/FHT sequence and display it. |- | fs20 send HOUSECODE ADDR CMD [CMD2] | Send FS20 command. See [[FS20]] for details. |- | fs20 ws300 | Receive FS20 sequence from WS300 weather station and decode it. |- |} == [[Frequency Counter]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fc %duty [CHANNEL] | "returns last on duty cycle in percent, channel is always 0 (for now)" |- | fc duty [CHANNEL] | "returns last on duty cycle (0-255), channel is always 0 (for now)" |- | fc freq [CHANNEL] | "returns last frequency in Hz, channel is always 0 (for now)" |- | fc ticks [CHANNEL] | "returns last frequency in CPU ticks, channel is always 0 (for now)" |- |} == [[GLCD_Menu]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | glcdmenu key VALUE | Send a keypress to the menu |- | glcdmenu update | Update the menu |- |} == [[GPS]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | nmea get | Get latitude and longitude data |- | nmea satellites | Get satellites |- |} == [[H-Bridge]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | hbridge [action] [enable_l] [enable_r] | Set H-Bridge command |- | hbridge pwm int | Set H-Bridge enable line valueeg. speed |- |} == [[I2C]] (TWI) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ds1631 convert ADDR VALUE | Initiate temperature conversions (0: stop, 1: convert) |- | ds1631 temp ADDR | Read last converted temperature |- | i2c detect | list detected I2C Chips |- | i2c rbb ADDR | read byte from I2C chip |- | i2c rbd CHIPADDR REGADDR | read byte from register address at I2C chip |- | i2c rwd CHIPADDR REGADDR | read word from register address at I2C chip |- | i2c wbb ADDR HEXVALUE | write byte to I2C chip |- | i2c wbd CHIPADDR REGADDR HEXVALUE | write byte to register address on I2C chip |- | i2c wwd CHIPADDR REGADDR HEXVALUE | write word to register address on I2C chip |- | lm75 ADDR | Get temperature |- | max7311 getDDRw ADDR | Get Direction-Register DDR |- | max7311 getINw ADDR | Get Input-Register IN |- | max7311 getOUTw ADDR | Get Output-Register OUT |- | max7311 pulse ADDR BIT TIME | Toggle Output-BIT for TIME (in ms) |- | max7311 set ADDR BIT VALUE | Set Output-BIT to VALUE (bool) |- | max7311 setDDRw ADDR VALUE | Set Direction-Register DDR (VALUE as hex) |- | max7311 setOUTw ADDR VALUE | Set Output-Register OUT (VALUE as hex) |- | pca9531 ADDR PERIODPWM1 DUTYPWM1 PERIODPWM2 DUTYPWM2 LED0..3 LED4..7 | set PWM1 and PWM2 and LED states |- | pca9685m ADDR | OUTDRV, IVRT, PRESCALE |- | pca9685s ADDR | LED, ON, OFF |- | pcf8574x read ADDR CHIP | Get bits |- | pcf8574x set ADDR CHIP HEXVALUE | Set bits |- | tsl2550 lux | Show light level by reading adc registers and computing level |- | tsl2550 mode VALUE | Set the TSL2550s operating mode (0: standard range, 1: extended range) |- | tsl2550 power VALUE | Set the TSL2550s power state (0: down, 1:up) |- |} == [[Jabber]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | jabber_host [HOSTNAME] | JABBER hostname |- | jabber_pass [PASSWORD] | JABBER password |- | jabber_resrc [RESOURCE] | JABBER resource |- | jabber_user [USERNAME] | JABBER username |- |} == [[KTY]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | kty autocalibrate CHANNEL | Calibrate to 1000 Ohm precision Resistor. |- | kty cal get | Return the calibration difference to 2k2 Resistor. |- | kty get [CHANNEL] | Get the temperature in xxx.x °C of CHANNEL or if no channel set of all channels. |- |} == [[MotorCurtain]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | curtain VALUE | Set value of curtain. 0=closed..7=open. If you use fewer sensors, use the corrent value instead of 7. |- | curtainlast | Return last known position |- | curtainmax | Return maximum position |- | curtainoff | Switch motor off |- |} == [[Named_PIN]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | pin get NAME | Read and display the status of pin NAME. |- | pin list | List all known named-pins. |- | pin set NAME STATUS | Set the status of pin NAME to STATUS. |- | pin toggle NAME | Toggle the status of pin NAME. |- |} == [[PWM]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dtmf CHARS | send CHARS as DTMF |- | freq set FREQUENCY DELAY | Set frequency for DELAY ms |- | pwm fade [channel +-diff startvalue] | Set fading at channel with startvalue and change each stepp to diff (must be signed 3 digit) |- | pwm set [channel value] | Set channel to value |- |} == [[RFM12]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | rfm12 reinit | Re-initialize RFM12 module. |- | rfm12 setbandwidth BW | Set RX bandwidth to BW. |- | rfm12 setbaud BAUD | Set baudrate to BAUD. |- | rfm12 setdrssi DRSSI | Set the drssi to DRSSI. |- | rfm12 setgain GAIN | Set preamplifier gain to GAIN. |- | rfm12 setmod MOD | Set modulation to MOD. |- | rfm12 status | Display internal status. |- |} == [[RFM12_ASK]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | rfm12 1527 | housecodeCommand delay cnt |- | rfm12 2272 | housecodeCommand delay cnt |- | rfm12 ask sense | Trigger (Tevion) ASK sensing. Enable ext. filter pin before! |- | rfm12 external filter [1] | Enable ext. filter pin if argument is present (disable otherwise) |- | rfm12 intertechno | family group device command |- | rfm12 tevion | housecode command delay cnt |- |} == [[SD-Karte]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sd dir | List contents of current SD directory. |- | sd mkdir PATH | Create directory hierarchy PATH. |- |} == [[SHT]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sht humid | Return humidity of SHT sensor |- | sht raw | Return raw hex temp (first line) and humidity value (second line) of SHT sensor |- | sht temp | Return temperature of SHT sensor |- |} == [[SMS77]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sms77 MESSAGE | Send MESSAGE to compiled in sms77 service |- | sms77_pass [PASSWORD] | SMS77 password |- | sms77_recv [RECEIVER] | SMS receiver |- | sms77_type [TYPE] | SMS type |- | sms77_user [USERNAME] | SMS77 username |- |} == [[Servo_Ansteuerung|PWM Servo Control]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | pwm servo_dec SERVONR | Decrement position of servo SERVONR |- | pwm servo_inc SERVONR | Increment position of servo SERVONR |- | pwm servo_set SERVONR POSITION | Set servo with SERVONR to POSITION |- |} == [[Sound]]/WAV support == {| border='1' | ''Command syntax'' | ''Short description'' |- | pwm stop | Stop wav |- | pwm wav <FILENAME> | Play wave file. Use VFS if compiled in. More details at [[Sound]] |- |} == [[Stella_Light]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | channel CHANNEL VALUE FUNCTION | Get/Set stella channel to value. Second and third parameters are optional. Function: You may use 's' for instant set, 'f' for fade and 'y' for flashy fade. |- | channels | Return stella channel size |- | fadestep FADESTEP | Get/Set stella fade step |- | stella load | Load values from eeprom |- | stella store | Store values in eeprom |- |} == [[USB]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | keyboard MESSAGE | Send MESSAGE as HID keyboard |- | mouse BUTTON DELTAX DELTAY | Send data as HID mouse |- |} == [[ZACwire]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | zac 306 PORT BIT | Return temperature of TSic 306 at BIT of PORT |- | zac 506 PORT BIT | Return temperature of TSic 506 at BIT of PORT |- | zac raw PORT BIT | Return raw hex temperature value of zacwire at BIT of PORT |- |} == lome6 == {| border='1' | ''Command syntax'' | ''Short description'' |- | lome6 get_t TYPE | get temperature command |- | lome6 power TYPE | press power command |- | lome6 reset | press reset command |- | lome6 set_t TYPE TEMPERATURE | set temperature command |- | lome6 state | get state command |- | lome6 uptime UPTIME | set/get uptime command |- |} == Miscelleanous == {| border='1' | ''Command syntax'' | ''Short description'' |- | alias list | List all available aliases |- | artnet test | artnet test |- | cw send MESSAGE | Send MESSAGE in Morce Code |- | d ADDR | Dump the memory at ADDR (16 bytes). |- | eeprom reinit | Force reinitialization of the EEPROM config area |- | free | Display free space. |- | help | List which commands are available. |- | ht MESSAGE | Send MESSAGE to compiled in httplog service |- | ipstats | Display IP statistics. |- | mb recv | Receive data from modbus |- | moodlight CHANNEL ONOFF | Set CHANNEL moodlight on=1 or off=0. If no channel is given return on if channel CHANNEL is moodlighted |- | motd [MESSAGE] | Save MESSAGE as new message of the day, otherwise just show current message |- | msr1 get | Get data |- | mysql query QUERY | Send specified MySQL query to the configured server |- | ns | update net statistic for public anouncment of currently running ethersex |- | pam USER PASSWORD | Use pam for user and password |- | push NUMBER | Push button identified by NUMBER |- | pwm melody [NUMBER] | Play melody |- | sanyoz700 CMD | Send command to projector |- | sll get | Request the logged data |- | sram memtest | Perform a memory test |- | srf05 | Read SRF05 measurement |- | to1 get | Request data from sensor |- | tw MESSAGE | Send MESSAGE to compiled in twitter service |- | upnp send | Manually send UPnP broadcast packet |- | usart baud BAUD | Set the USART baudrate to BAUD. |- | version | Display the version number. |- | wol MAC | Send WAKE-ON-LAN command to MAC |- | yport stats | Report statistic counters |- | zbus stats | Report statistic counters |- |} [[Category:Ethersex]] [[Category:ECMD]] 84b86cfcb9b1efad93c47e931a89a3476583c38b 170 163 2011-11-06T20:42:21Z LadySM 0 Importing text file wikitext text/x-wiki <div class="errorbox"> This page is automatically generated from the files in the Ethersex source code repository. Do not edit this page but send [[patches]] for those files! </div> __NOTOC__ == Analog/Digital Conversion ([[ADC]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | adc get [CHANNEL] | Get the ADC value in hex of CHANNEL or if no channel set of all channels. |- | hr20 temp | Read HR20 temperature sensor. |- |} == DNS Resolver == {| border='1' | ''Command syntax'' | ''Short description'' |- | dns server [IPADDR] | Display/Set the IP address of the DNS server to use to IPADDR. |- | nslookup HOSTNAME | Do DNS lookup for HOSTNAME (call twice). |- |} == Digital/Analog Conversion ([[DAC]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ltc1257_delay `[VALUE] | Set (if VALUE given) or get (no VALUE) delay for LTC1257 output bit changes in µs' |- | ltc1257_set `[VALUE0] [VALUE1] ... | Set output to value (value: 0-4095)' |- | tlc5620 `[CHANNEL] [VALUE] | Set Output to value (Value: 0-0xff)' |- |} == Fnordlicht == {| border='1' | ''Command syntax'' | ''Short description'' |- | fnordlicht "ADDRESS RED | GREEN,BLUE",fnordlicht command to set RGB color |- | fnordlicht_init | fnordlicht init |- |} == HD44780 [[LCD]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | hr20 hourbar START STOP | Update hourbar to show ticks between START and STOP (range 0..23) |- | hr20 toggle SEG | Toggle segment SEG (a number, not a symbolic name!) |- | lcd backlight STATE | switch back light STATE to ON or OFF |- | lcd char N D1 D2 D3 D4 D5 D6 D7 D8 | Define use-definable char N with data D1..D8 (provide DATA in hex) |- | lcd clear [LINE] | Clear line LINE (0..3) or the whole display (if parameter is omitted) |- | lcd goto LINE COL | Move cursor to LINE and column COL (origin is 0/0) |- | lcd reinit CURSOR BLINK | Reinitialize the display, set whether to show the cursor (CURSOR, 0 or 1) and whether the cursor shall BLINK |- | lcd shift DIR | Shift the display to DIR (either ''left'' or ''right'') |- | lcd write TEXT | Write TEXT to the current cursor location |- |} == Infrared Send/Receive ([[IR-TRX]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ir receive | receive an IR command |- | ir send DEVICE COMMAND | send COMMAND to DEVICE |- |} == Infrared Send/Receive ([[IRMP]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | irmp receive | receive an IR command |- | irmp send PROTOCOL DEVICE COMMAND REPEAT | send COMMAND with REPEAT flag to DEVICE using PROTOCOL |- |} == NTP Client == {| border='1' | ''Command syntax'' | ''Short description'' |- | ntp query | Query the NTP server to get an NTP update. |- | ntp server [IPADDR] | Display/Set the IP address of the NTP server to use to IPADDR. |- | ntp status | Display NTP server status |- |} == Network configuration == {| border='1' | ''Command syntax'' | ''Short description'' |- | enc dump | Dump the internal state of the enc to serial |- | gw [IP] | Display/Set the address of the default router. |- | ip [IP] | Display/Set the IP address. |- | mac [xx:xx:xx:xx:xx:xx] | Display/Set the MAC address. |- | netmask [IP] | Display/Set the network mask. |- |} == Port I/O == {| border='1' | ''Command syntax'' | ''Short description'' |- | io get ddr PORTNUM | Display the current value of the DDR PORTNUM. |- | io get mask PORTNUM | Display the mask of the port PORTNUM. |- | io get pin PORTNUM | Display the current value of the PIN-register of the port PORTNUM. |- | io get port NUM | Display the current value of the PORT NUM. |- | io set ddr PORTNUM HEXVALUE [MASK] | Set the DDR of port PORTNUM to VALUE (possibly using the provided MASK). |- | io set port NUM HEXVALUE [MASK] | Set the PORT NUM to VALUE (possibly using the provided MASK). |- |} == Reading and Writing EEPROM Space on Device == {| border='1' | ''Command syntax'' | ''Short description'' |- | eer eer <ADDR> <LENGTH> | Read n bytes from address after the config in eeprom. |- | eew eew <ADDR> <HEXBYTES> | Write Hexbytes at address after the config in epprom. |- | fuse | Display current fuse settings |- | hostname | Display hostname. |- |} == Resetting the controller == {| border='1' | ''Command syntax'' | ''Short description'' |- | bootloader | Call the bootloader. |- | reset | Reset the Ethersex. |- | wdreset | Go into endless loop to trigger a watchdog timeout. |- |} == [[ADS]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | ads get | Get the ADC value in hex. |- | ads mean [COUNT] | Get the mean of power of 2 COUNT ADC values in hex. |- |} == [[Am_Puls_der_Zeit|Clock]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | date | Display the current date. |- | lastdcf | Display when last valid DCF Signal was received. |- | time [UNIXTIME] | Display/Set the current time in seconds since January 1st 1970. |- | uptime | Display ethersex uptime in unix format. |- | whm | Display ethersex uptime. |- |} == [[Application_Sample]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sample | Manually call application sample commands |- | sample_init | Manually call application sample init method |- | sample_periodic | Manually call application sample periodic method |- |} == [[Blinkenlights_MCUF|MCUF]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | mcuf modul N | Select module N |- | mcuf modul list | List all modules |- | mcuf showclock | Show digital clock |- | mcuf showstring MESSAGE | Show scrolling MESSAGE on the display |- |} == [[CRON-Dienst]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | cron_add MIN HOUR DAY MONTH DOW ECMD | Add ECMD to cron to be executed at given time |- | cron_list | Show all cron entries |- | cron_make_persistent | Mark a Job as persistent |- | cron_rm POSITION | Remove one cron entry |- | cron_save | Saves all persistent jobs |- |} == [[DALI]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dali cmd [TARGET] [COMMAND] [!][?] | "send the given command (decimal) to targets (all, g00 to g15, s00 to s63), auto repeat with !, read reply with ?" |- | dali dim [TARGET] [LEVEL] | "dim targets (all, g00 to g15, s00 to s63) to given level (0-254)" |- | dali raw [BYTE1] [BYTE2] | "send a raw frame (two bytes, given in hex) over the DALI bus" |- | dali scmd [SPECIAL COMMAND] [DATA] [!][?] | "send special command (256-287) with data, auto repeat with !, read reply with ?" |- |} == [[DMX_Effect]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx rainbow | switch rainbow on (1) or off (0) |- | dmx random | switch random on (1) or off (0) |- |} == [[DMX_Storage]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx channels | Get channels per universe |- | dmx get | Return channel value |- | dmx set | Set channel values |- | dmx universe | Get a whole universe |- | dmx universes | Get universes |- |} == [[Dallas_1-wire_Bus]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | 1w convert [DEVICE] | Trigger temperature conversion of either DEVICE or all connected devices |- | 1w ds2450 convert [DEVICE] | `start conversion (with optional input mask and read out control)' |- | 1w ds2450 get [DEVICE] | `get conversion result (one or all channels)' |- | 1w ds2450 oc [DEVICE] | `get/set output control (per channel)' |- | 1w ds2450 oe [DEVICE] | `get/set output enable (per channel)' |- | 1w ds2450 por [DEVICE] | `get/set power on reset (per channel)' |- | 1w ds2450 power [DEVICE] | `get/set power supply of device (global)' |- | 1w ds2450 range [DEVICE] | `get/set input voltage range (per channel)' |- | 1w ds2450 res [DEVICE] | `get/set bit resolution of AD convert (per channel)' |- | 1w get DEVICE | Return temperature value of onewire DEVICE (provide 64-bit ID as 16-hex-digits) |- | 1w list | Return a list of the connected onewire devices |- |} == [[DataFlash]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | df status | Display internal status. |- | fs format | Format the filesystem. |- | fs inspect inode INODE | Inspect INODE (and associated page). |- | fs inspect node NODE | Inspect NODE and dump to serial. |- | fs list | List the directory. |- | fs mkfile NAME | Create a new file NAME. |- | fs remove NAME | Delete the file NAME. |- | fs truncate NAME LEN | Truncate the file NAME to LEN bytes. |- |} == [[Dc3840_camera|DC3840 mobil camera support]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dc3840 capture | Take a picture. Access 'dc3840' via VFS afterwards. See [[DC3840 Camera]] for details. |- | dc3840 light | Light level of camera |- | dc3840 send A B C D E | Send provided command bytes to the camera. |- | dc3840 sync | Re-sync to the camera |- | dc3840 zoom | Enable zoom of camera |- |} == [[ECMDScript]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | call FILENAME | Start script named FILENAME |- | cat FILENAME | cat file content (with debug only) |- | dec VAR | Decrement variable VAR (a number) |- | echo <any> | Print out all arguments of echo |- | exit | Exit currently running script |- | get VAR | Get value of variable VAR |- | goto N | Goto line N in currently running script |- | if ( CMD/VAR == CONST ) then CMD2 | If condition matches execute CMD2 |- | inc VAR | Increment variable VAR (a number) |- | rem <any> | Remark for anything |- | set VAR VALUE | Set variable VAR to VALUE |- | wait I | Wait I milliseconds |- |} == [[FS20]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fht send HOUSECODE ADDR CMD [CMD2] | Send FHT command. See [[FS20]] for details. |- | fs20 receive | Receive FS20/FHT sequence and display it. |- | fs20 send HOUSECODE ADDR CMD [CMD2] | Send FS20 command. See [[FS20]] for details. |- | fs20 ws300 | Receive FS20 sequence from WS300 weather station and decode it. |- |} == [[Frequency Counter]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fc %duty [CHANNEL] | "returns last on duty cycle in percent for given channel" |- | fc duty [CHANNEL] | "returns last on duty cycle (0-255) for given channel" |- | fc freq [CHANNEL] | "returns last frequency in Hz for given channel" |- | fc off [CHANNEL] | "switch off frequency counting on given channel" |- | fc on [CHANNEL] | "switch on frequency counting on given channel" |- | fc ticks [CHANNEL] | "returns last frequency in CPU ticks for given channel" |- |} == [[GLCD_Menu]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | glcdmenu key VALUE | Send a keypress to the menu |- | glcdmenu update | Update the menu |- |} == [[GPS]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | nmea get | Get latitude and longitude data |- | nmea satellites | Get satellites |- |} == [[H-Bridge]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | hbridge [action] [enable_l] [enable_r] | Set H-Bridge command |- | hbridge pwm int | Set H-Bridge enable line valueeg. speed |- |} == [[I2C]] (TWI) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ds1631 convert ADDR VALUE | Initiate temperature conversions (0: stop, 1: convert) |- | ds1631 temp ADDR | Read last converted temperature |- | i2c detect | list detected I2C Chips |- | i2c rbb ADDR | read byte from I2C chip |- | i2c rbd CHIPADDR REGADDR | read byte from register address at I2C chip |- | i2c rwd CHIPADDR REGADDR | read word from register address at I2C chip |- | i2c wbb ADDR HEXVALUE | write byte to I2C chip |- | i2c wbd CHIPADDR REGADDR HEXVALUE | write byte to register address on I2C chip |- | i2c wwd CHIPADDR REGADDR HEXVALUE | write word to register address on I2C chip |- | lm75 ADDR | Get temperature |- | max7311 getDDRw ADDR | Get Direction-Register DDR |- | max7311 getINw ADDR | Get Input-Register IN |- | max7311 getOUTw ADDR | Get Output-Register OUT |- | max7311 pulse ADDR BIT TIME | Toggle Output-BIT for TIME (in ms) |- | max7311 set ADDR BIT VALUE | Set Output-BIT to VALUE (bool) |- | max7311 setDDRw ADDR VALUE | Set Direction-Register DDR (VALUE as hex) |- | max7311 setOUTw ADDR VALUE | Set Output-Register OUT (VALUE as hex) |- | pca9531 ADDR PERIODPWM1 DUTYPWM1 PERIODPWM2 DUTYPWM2 LED0..3 LED4..7 | set PWM1 and PWM2 and LED states |- | pca9685m ADDR | OUTDRV, IVRT, PRESCALE |- | pca9685s ADDR | LED, ON, OFF |- | pcf8574x read ADDR CHIP | Get bits |- | pcf8574x set ADDR CHIP HEXVALUE | Set bits |- | tsl2550 lux | Show light level by reading adc registers and computing level |- | tsl2550 mode VALUE | Set the TSL2550s operating mode (0: standard range, 1: extended range) |- | tsl2550 power VALUE | Set the TSL2550s power state (0: down, 1:up) |- |} == [[Jabber]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | jabber_host [HOSTNAME] | JABBER hostname |- | jabber_pass [PASSWORD] | JABBER password |- | jabber_resrc [RESOURCE] | JABBER resource |- | jabber_user [USERNAME] | JABBER username |- |} == [[KTY]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | kty autocalibrate CHANNEL | Calibrate to 1000 Ohm precision Resistor. |- | kty cal get | Return the calibration difference to 2k2 Resistor. |- | kty get [CHANNEL] | Get the temperature in xxx.x °C of CHANNEL or if no channel set of all channels. |- |} == [[MotorCurtain]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | curtain VALUE | Set value of curtain. 0=closed..7=open. If you use fewer sensors, use the corrent value instead of 7. |- | curtainlast | Return last known position |- | curtainmax | Return maximum position |- | curtainoff | Switch motor off |- |} == [[Named_PIN]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | pin get NAME | Read and display the status of pin NAME. |- | pin list | List all known named-pins. |- | pin set NAME STATUS | Set the status of pin NAME to STATUS. |- | pin toggle NAME | Toggle the status of pin NAME. |- |} == [[PWM]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dtmf CHARS | send CHARS as DTMF |- | freq set FREQUENCY DELAY | Set frequency for DELAY ms |- | pwm fade [channel +-diff startvalue] | Set fading at channel with startvalue and change each stepp to diff (must be signed 3 digit) |- | pwm set [channel value] | Set channel to value |- |} == [[RFM12]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | rfm12 reinit | Re-initialize RFM12 module. |- | rfm12 setbandwidth BW | Set RX bandwidth to BW. |- | rfm12 setbaud BAUD | Set baudrate to BAUD. |- | rfm12 setdrssi DRSSI | Set the drssi to DRSSI. |- | rfm12 setgain GAIN | Set preamplifier gain to GAIN. |- | rfm12 setmod MOD | Set modulation to MOD. |- | rfm12 status | Display internal status. |- |} == [[RFM12_ASK]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | rfm12 1527 | housecodeCommand delay cnt |- | rfm12 2272 | housecodeCommand delay cnt |- | rfm12 ask sense | Trigger (Tevion) ASK sensing. Enable ext. filter pin before! |- | rfm12 external filter [1] | Enable ext. filter pin if argument is present (disable otherwise) |- | rfm12 intertechno | family group device command |- | rfm12 tevion | housecode command delay cnt |- |} == [[SD-Karte]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sd dir | List contents of current SD directory. |- | sd mkdir PATH | Create directory hierarchy PATH. |- |} == [[SHT]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sht humid | Return humidity of SHT sensor |- | sht raw | Return raw hex temp (first line) and humidity value (second line) of SHT sensor |- | sht temp | Return temperature of SHT sensor |- |} == [[SMS77]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sms77 MESSAGE | Send MESSAGE to compiled in sms77 service |- | sms77_pass [PASSWORD] | SMS77 password |- | sms77_recv [RECEIVER] | SMS receiver |- | sms77_type [TYPE] | SMS type |- | sms77_user [USERNAME] | SMS77 username |- |} == [[Servo_Ansteuerung|PWM Servo Control]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | pwm servo_dec SERVONR | Decrement position of servo SERVONR |- | pwm servo_inc SERVONR | Increment position of servo SERVONR |- | pwm servo_set SERVONR POSITION | Set servo with SERVONR to POSITION |- |} == [[Sound]]/WAV support == {| border='1' | ''Command syntax'' | ''Short description'' |- | pwm stop | Stop wav |- | pwm wav <FILENAME> | Play wave file. Use VFS if compiled in. More details at [[Sound]] |- |} == [[Stella_Light]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | channel CHANNEL VALUE FUNCTION | Get/Set stella channel to value. Second and third parameters are optional. Function: You may use 's' for instant set, 'f' for fade and 'y' for flashy fade. |- | channels | Return stella channel size |- | fadestep FADESTEP | Get/Set stella fade step |- | stella load | Load values from eeprom |- | stella store | Store values in eeprom |- |} == [[USB]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | keyboard MESSAGE | Send MESSAGE as HID keyboard |- | mouse BUTTON DELTAX DELTAY | Send data as HID mouse |- |} == [[ZACwire]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | zac 306 PORT BIT | Return temperature of TSic 306 at BIT of PORT |- | zac 506 PORT BIT | Return temperature of TSic 506 at BIT of PORT |- | zac raw PORT BIT | Return raw hex temperature value of zacwire at BIT of PORT |- |} == lome6 == {| border='1' | ''Command syntax'' | ''Short description'' |- | lome6 get_t TYPE | get temperature command |- | lome6 power TYPE | press power command |- | lome6 reset | press reset command |- | lome6 set_t TYPE TEMPERATURE | set temperature command |- | lome6 state | get state command |- | lome6 uptime UPTIME | set/get uptime command |- |} == Miscelleanous == {| border='1' | ''Command syntax'' | ''Short description'' |- | alias list | List all available aliases |- | artnet test | artnet test |- | cw send MESSAGE | Send MESSAGE in Morce Code |- | d ADDR | Dump the memory at ADDR (16 bytes). |- | eeprom reinit | Force reinitialization of the EEPROM config area |- | free | Display free space. |- | help | List which commands are available. |- | ht MESSAGE | Send MESSAGE to compiled in httplog service |- | ipstats | Display IP statistics. |- | mb recv | Receive data from modbus |- | moodlight CHANNEL ONOFF | Set CHANNEL moodlight on=1 or off=0. If no channel is given return on if channel CHANNEL is moodlighted |- | motd [MESSAGE] | Save MESSAGE as new message of the day, otherwise just show current message |- | msr1 get | Get data |- | mysql query QUERY | Send specified MySQL query to the configured server |- | ns | update net statistic for public anouncment of currently running ethersex |- | pam USER PASSWORD | Use pam for user and password |- | push NUMBER | Push button identified by NUMBER |- | pwm melody [NUMBER] | Play melody |- | sanyoz700 CMD | Send command to projector |- | sll get | Request the logged data |- | sram memtest | Perform a memory test |- | srf05 | Read SRF05 measurement |- | to1 get | Request data from sensor |- | tw MESSAGE | Send MESSAGE to compiled in twitter service |- | upnp send | Manually send UPnP broadcast packet |- | usart baud BAUD | Set the USART baudrate to BAUD. |- | version | Display the version number. |- | wol MAC | Send WAKE-ON-LAN command to MAC |- | yport stats | Report statistic counters |- | zbus stats | Report statistic counters |- |} [[Category:Ethersex]] [[Category:ECMD]] a9e84c2ec9932c7f76a790677c5a6a4b67bcf298 10 39 164 104 2011-11-05T09:41:21Z Mgue 312 + ECMD Reference wikitext text/x-wiki <noinclude>{{i18n|Template:Documentation}}</noinclude> {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | colspan=2 style="background-color: #FFFFFF; text-align: center; border-bottom:1px solid #aaaaaa;" | '''Documentation''' |- | [[Wiki Guidelines]] ---- * [[:Category:Hardware|Hardware Drivers]] * [[:Category:Protocol|Protocol Support]] * [[:Category:Application|Services and Applications]] * [[ECMD Reference]] |} fb4c345e23fd6de5618d3d75459697b6de684d6c 6 44 165 2011-11-05T15:47:57Z Mgue 312 '''Source:''' http://tango-project.org/ cc-by-sa-2.5 wikitext text/x-wiki '''Source:''' http://tango-project.org/ cc-by-sa-2.5 3f4c4673cf2dd48ea91bb0b43b2a8fb0dfa9bd6c 10 41 166 151 2011-11-05T15:51:46Z Mgue 312 wikitext text/x-wiki <noinclude>{{i18n|Template:NewWiki}}</noinclude> {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#FFAF4D; border:4px #aaa solid; font-size:95%; color:black; width:auto%; padding: 15px; font-size: 15px" |- |[[Image:Applications-development.svg]] |'''Welcome to the new Wiki of the ethersex project.''' This wiki is far from being complete, so please help us by contributing your knowledge! In search of the old wiki? [http://old.ethersex.de Go to old.ethersex.de] |- |} 57fcb982cfdc96e88b59178b68e4969bc65d4103 0 45 167 2011-11-06T19:57:48Z Gvegidy 132 Created page with "{{i18n|Frequency Counter}} {{Module |NAME=Frequency Counter |MENUCONFIG={{Applications}}->Frequency Counter |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] (…" wikitext text/x-wiki {{i18n|Frequency Counter}} {{Module |NAME=Frequency Counter |MENUCONFIG={{Applications}}->Frequency Counter |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] (optional) |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/services/freqcount https://github.com/ethersex/ethersex/tree/master/services/freqcount] }} Measures the frequency and duty cycle of a signal == Anschluss == * muss immer an das ICP1-Pin angeschlossen werden * im Pinning muss der Pin zusätzlich noch definiert werden: <code>pin(FREQCOUNT_PIN, PB0, INPUT)</code> * es ist geplant noch ein Multiplexing mit einem zusätzlichen 74HC251 oder dem Ananlog-Multiplexer (unter Verlust des ADCs) einzubauen == Frequenz == * CPU-Ticks von Rising-Edge zu Rising-Edge werden gemessen * Minimal das kleinere von 1 Hz und CPU-Frequenz / 16777216, in der Praxis 2 Hz * Maximal ca. 50 CPU-Takte, also ca. 400KHz bei 20 MHz * Ist die Frequenz höher, wird dies nicht sicher erkannt, es werden einfach falsche Werte gemessen * Steigt die Interrupt-Last der CPU (z.B. durch Netzwerkverkverkehr oder UART), sinkt die maximal sicher messbare Frequenz * Die Frequenz wird intern als Anzahl der Ticks (32 Bit unsigned int) gespeichert == Duty-Cycle == * Kann auch den Duty-Cycle eines PWM-Signals messen * Duty-Cycle ist (Zeit von Rising Edge zu Falling Edge) / Gesamtdauer des letzten Zyklus von Rising zu Rising * Frequenz und Duty-Cycle werden nacheinander gemessen * Sollte sich die Frequenz signifikant ändern, ist die Duty-Cycle Messung falsch * Der Duty Cycle wird intern als 8 Bit Wert gespeichert == Durchschnittsbildung == * Durch Interrupt-Verzögerungen etc. kann es zu Fehlmessungen kommen * Bei höheren Frequenzen sinkt die maximal mögliche Auflösung * Um das zu kompensieren wird immer der Durchschnitt von n Messungen verwendet, n ist im Konfigurationsmenü einstellbar * Zusätzlich wird immer der höchste und der niedrigste Wert einer dieser Durchschnittsreihen verworfen (es werden n+2 Samples genommen) == ECMD-Befehle == {| border=1 cellspacing=0 padding=4 class=wikitable ! width="25%" | Kommando ! Funktion |- |fc freq ''Channel''|| Gibt die Frequenz in Hz zurück (Achtung: 32 Bit). |- |- |fc ticks ''Channel''|| Gibt die Frequenz in CPU Ticks zurück (Achtung: 32 Bit). |- |- |fc duty ''Channel''|| Gibt den Duty Cycle als 8 Bit Wert zurück (0-255 dezimal). |- |- |fc %duty ''Channel''|| Gibt den Duty Cycle in Prozent zurück. |- |- Hinweis: Channel ist momentan immer 0 94d21702bc2d6d42d75e522be6a37906d4eb4561 168 167 2011-11-06T20:15:13Z Gvegidy 132 some translation wikitext text/x-wiki {{i18n|Frequency Counter}} {{Module |NAME=Frequency Counter |MENUCONFIG={{Applications}}->Frequency Counter |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] (optional) |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/services/freqcount https://github.com/ethersex/ethersex/tree/master/services/freqcount] }} Measures the frequency and duty cycle of a signal == Pinning == * the signal must always be fed to the ICP1-pin. Look up in the datasheet which physical pin this is on the used controller. * you need to define the pinning in ''pinning/hardware/<your board>.m4'': pin(FREQCOUNT_PIN, PB0, INPUT) * if you want to measure the frequency of multiple signals, you can multiplex them with one or two 74HC251 * define the pinning for the control lines you need like this: pin(FREQCOUNT_CHANNEL_MULTIPLEX_BIT1, PB1, OUTPUT) pin(FREQCOUNT_CHANNEL_MULTIPLEX_BIT2, PB2, OUTPUT) pin(FREQCOUNT_CHANNEL_MULTIPLEX_BIT2, PB3, OUTPUT) pin(FREQCOUNT_CHANNEL_MULTIPLEX_CS_A, PB4, OUTPUT) pin(FREQCOUNT_CHANNEL_MULTIPLEX_CS_B, PB5, OUTPUT) == Frequency == * CPU ticks from rising edge to rising edge are measured * minimum frequency is the smaller value of 1 Hz and CPU frequency divided by 16777216, in practice 2 Hz * if the frequency is below the minimum, the output is 0 * maximum frequency is about 50 cpu ticks, about 400 KHz at 20 MHz CPU * if the frequency is above the maximum you get bogus results * when the irq load of the cpu increases (e.g. by network traffic or UART), the maximum frequency decreases == Duty Cycle == * you can also measure the duty cycle of a PWM signal * duty cycle is (time from rising edge to falling edge) / time of whole cycle from rising to rising * frequency and duty cycle are measured one after another * when the frequency changes significantly the measured duty cycle will be wrong * duty cycle is stored as 8 bit value == Durchschnittsbildung == * Durch Interrupt-Verzögerungen etc. kann es zu Fehlmessungen kommen * Bei höheren Frequenzen sinkt die maximal mögliche Auflösung * Um das zu kompensieren wird immer der Durchschnitt von n Messungen verwendet, n ist im Konfigurationsmenü einstellbar * Zusätzlich wird immer der höchste und der niedrigste Wert einer dieser Durchschnittsreihen verworfen (es werden n+2 Samples genommen) == ECMD-Befehle == {| border=1 cellspacing=0 padding=4 class=wikitable ! width="25%" | Kommando ! Funktion |- |fc freq ''Channel''|| Gibt die Frequenz in Hz zurück (Achtung: 32 Bit). |- |- |fc ticks ''Channel''|| Gibt die Frequenz in CPU Ticks zurück (Achtung: 32 Bit). |- |- |fc duty ''Channel''|| Gibt den Duty Cycle als 8 Bit Wert zurück (0-255 dezimal). |- |- |fc %duty ''Channel''|| Gibt den Duty Cycle in Prozent zurück. |- |- Hinweis: Channel ist momentan immer 0 e6afc911626b75cbb574047bcf880eb30eb3bba5 169 168 2011-11-06T20:36:30Z Gvegidy 132 more translation wikitext text/x-wiki {{i18n|Frequency Counter}} {{Module |NAME=Frequency Counter |MENUCONFIG={{Applications}}->Frequency Counter |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] (optional) |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/services/freqcount https://github.com/ethersex/ethersex/tree/master/services/freqcount] }} Measures the frequency and duty cycle of a signal == Pinning == * the signal must always be fed to the ICP1-pin. Look up in the datasheet which physical pin this is on the used controller. * you need to define the pinning in ''pinning/hardware/<your board>.m4'': pin(FREQCOUNT_PIN, PB0, INPUT) * if you want to measure the frequency of multiple signals, you can multiplex them with one or two 74HC251, up to 16 channels are supported * define the pinning for the control lines you need like this: pin(FREQCOUNT_CHANNEL_MULTIPLEX_BIT1, PB1, OUTPUT) pin(FREQCOUNT_CHANNEL_MULTIPLEX_BIT2, PB2, OUTPUT) pin(FREQCOUNT_CHANNEL_MULTIPLEX_BIT2, PB3, OUTPUT) pin(FREQCOUNT_CHANNEL_MULTIPLEX_CS_A, PB4, OUTPUT) pin(FREQCOUNT_CHANNEL_MULTIPLEX_CS_B, PB5, OUTPUT) == Frequency == * CPU ticks from rising edge to rising edge are measured * minimum frequency is the smaller value of 1 Hz and CPU frequency divided by 16777216, in practice 2 Hz * if the frequency is below the minimum, the output is 0 * maximum frequency is about 50 cpu ticks, about 400 KHz at 20 MHz CPU * if the frequency is above the maximum you get bogus results * when the irq load of the cpu increases (e.g. by network traffic or UART), the maximum frequency decreases == Duty Cycle == * you can also measure the duty cycle of a PWM signal * duty cycle is (time from rising edge to falling edge) / time of whole cycle from rising to rising * frequency and duty cycle are measured one after another * when the frequency changes significantly the measured duty cycle will be wrong * duty cycle is stored as 8 bit value == Basic Averaging == * you will sometimes get a wrong result due to interrupt latencies etc. * the module always averages the result of ''n'' measurements. You can define ''n'' in the menuconfig. * additionally the highest and lowest value of a averaging-block will be cut off, so ''n''+2 samples are taken * use a power of 2 for ''n'' to reduce code size and improve execution speed == Moving Average == * additionally to the basic averaging you can enable the moving average * the moving average uses the output from basic averaging as input * you can define the number of samples in the menuconfig * use a power of 2 for the number of samples to reduce code size and improve execution speed == ECMD Commands == {| border=1 cellspacing=0 padding=4 class=wikitable ! width="25%" | Command ! Function |- |fc freq ''Channel''|| Returns the frequency in Hz (Attention: 32 Bit). |- |- |fc ticks ''Channel''|| Returns the frequency in CPU ticks (Attention: 32 Bit). |- |- |fc duty ''Channel''|| Returns the duty cycle (0-255 decimal). |- |- |fc %duty ''Channel''|| Returns the duty cycle in percent. |- |- |fc on ''Channel''|| Switches on frequency counting on the given channel. |- |- |fc off ''Channel''|| Switches off frequency counting on the given channel. |- |- ''Channel'' is the number of the multiplexing channel (0-15), 0 if you do not use channel multiplexing. ffef70984194cd4f15fe000ae09b4ce9f3537e48 0 46 172 2011-11-08T10:21:41Z Loddel 64 Created page with "Die Dachs MSR1 ist ein Klein-Blockheizkraftwerk (BHKW) der Firma [http://www.senertec.de SenerTec], die sowohl Wärme, als auch Strom erzeugt, und vor allem eine serielle Schnitt…" wikitext text/x-wiki Die Dachs MSR1 ist ein Klein-Blockheizkraftwerk (BHKW) der Firma [http://www.senertec.de SenerTec], die sowohl Wärme, als auch Strom erzeugt, und vor allem eine serielle Schnittstelle zur Verfügung stellt *Händereib*. Über diese kann man einiges an Betriebs- und Wartungsdaten auslesen. Eine genauere Beschreibung des Protokolls gibts [[Dachs_MSR1_Service_Protokoll|hier]]. │ │ Load a Default Configuration ---> │ │ ... │ │ IO Support ---> | | ... │ │ [*] Senertec Dachs MSR1 Support │ │ (0) MSR1 usart select == Anschluss == [[Bild:Dachs_msr1_anschluss.png‎|thumb]] Obwohl sowohl das Ethersex, als auch die MSR1 einen Slave (Weiblich) RS232 Anschluss hat braucht man ein 1:1 Kabel. Außerdem muss das RTS Signal des MSR1 auf eine logische Null gelegt werden, da sich die MSR1 sonst nicht für irgendwelche Befehle interessiert. Dazu verwendet man am besten den zweiten Kanal des verbauten MAX232, legt den Eingang auf GND und greift die +10V am Ausgang ab. Ansonsten ist der RS232 Anschluss ein 9600 8N1. == Alternative Kabelbelegung == Im [http://www.bhkw-forum.de BHKW-Forum] gibt es noch eine alternative Kabelbelegung. Zu beachten ist nur, das man die Leitungen nicht kreuzen darf. (getestet mit dem AVR-Net-IO) [[Media:Kabelbelegung_Dachs_MRS1.pdf]] Die dort beschriebene Belegung ist also für PC->Dachs gedacht. Diese Variante funktioniert mit einem ethersex nur dann, wenn an der RS232 Buchse auch der RTS Kanal durch den MAX232 geschleift wird. (Und die Ethersexfirmware um RTS Handshaking erweitert wurde *huestel*) == Auslesen == Der MSR1 kann man zwei verschiedene Datensätze entlocken, den "0xe8"-Datensatz und den "0xc0"-Datensatz. Beide enthalten teilweise redundante Daten, wobei jedoch letzterer weitaus mehr Informationen bietet. Den 0xe8 Datensatz bekommt man mit dem ecmd `msr1 get' bzw. `msr1 get 0'. Das erste Byte gibt an, wieviele Anfragen seit dem letzten erfolgreichen Versuch fehlgeschlagen sind. Den 0xc0-Datensatz bekommt man über `msr1 get 1'. == Einbindung in den [[HTTPD]] == [[Bild:Msr1_screenshot.png|600px]] │ │ Load a Default Configuration ---> │ │ ... │ │ General Setup ---> │ │ ... │ │ [*] VFS (Virtual File System) ---> │ │ [*] VFS File Inling │ │ [*] Inline MSR1 Unter '''$ethersexip/msr.ht''' kann nun der aktuelle Status des Dachs ausgelesen werden. = Programm Beispiele = == Abfrage in Perl == === e8 === '''Ein Beispiel wie die Werte e8 abgefragt und aufbereitet werden.''' <source lang="perl"> #!/usr/bin/perl -w # Abfrage der Dachs e8-Werte per esex # # kleines Beispielscript, das die e8 Wert abholt ud anschliesend aufbereitet # in Variabeln schreibt. # Das Script kann als Vorlage für eigene Entwicklungen benutzt werden. # # Autor: Lothar Schweikle-Droll # Lizenz: GPL use strict; use Net::Telnet (); my $debug=1; my $esex; my $esexip="192.168.255.90"; my $esexport="2701"; my $e8hex; my @e8hex; my $BETRIEBSSTUNDEN; my $WARTUNG; my $RL; my $VL; my $ABGAS; my $EINSCH_TEMP_SOL; my $BETRIEBSZUSTAND; my $BETRIEBSZUSTAND_SOL; my $GEN_LEISTUNG_SOL; my @SERVICE_CODE_MODUL; #Modul 0 = Leitregler my %BETRIEBSZUSTAND = ( 10=>'Störabschaltung', 11=>'Abschaltung MV1', 11=>'Abschaltung MV2', 13=>'Drehzahl<200 n. 25 sek.', 14=>'Drehzahl>200 n. 25 sek.', 15=>'Abschaltung>1 Minute', 16=>'Abschaltung>4 Minuten', 20=>'Startvorbereitung', 21=>'Starteinleitung', 22=>'Start', 23=>'1,5 sek. nach Start', 24=>'Startende', 30=>'450<Drehz<800', 32=>'Zuschaltung Generator', 33=>'Leistungsregelung runter', 34=>'Leistungsregelung hoch', 35=>'Betrieb'); my $non; &e8_esex; &wertezuweisung; ### Ab hier kann eigener Code stehen if ( $debug == 1){ &debug; } ##### Subrotinen sub e8_esex { #Dachs e8 abfrge per Telnet über den ethersex $esex = Net::Telnet->new || die "kann Ethersex nicht finden"; $esex->open(Host => $esexip, Port => $esexport, Timeout => 1); $esex->print("msr1 get 0"); ($non, $e8hex) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); #den String in ein Array wandeln @e8hex = $e8hex =~ /(..)/g; } sub wertezuweisung { $BETRIEBSSTUNDEN=hex($e8hex[1].$e8hex[2]); $WARTUNG=hex($e8hex[3]); #RL auf negative Temp prüfen if (hex($e8hex[4]) >128 ) { $RL=hex($e8hex[4])-255; }else{ $RL=hex($e8hex[4]); } #VL auf negative Temp prüfen if (hex($e8hex[5]) >128 ) { $VL=hex($e8hex[5])-255; }else{ $VL=hex($e8hex[5]); } $ABGAS=hex($e8hex[6])+15; $EINSCH_TEMP_SOL=hex($e8hex[7]); $BETRIEBSZUSTAND=$BETRIEBSZUSTAND{hex($e8hex[8])}; $GEN_LEISTUNG_SOL= sprintf("%.3f" , hex($e8hex[9])/34); #Sollwert Der Generatorleistung gerundet auf 3 Stellen nach dem Komma my $i=0; while ($i <=5 ) { $SERVICE_CODE_MODUL[$i]=hex($e8hex[$i+10]); $i++ } $BETRIEBSZUSTAND_SOL=hex($e8hex[16]); } sub debug { print "\n*********** DEBUG Start *************\n\n"; print "e8-Hexwert:","@e8hex","\n\n"; print "Betriebstundenb:\t",$BETRIEBSSTUNDEN,"\n"; print "Wartung:\t\t",$WARTUNG,"\n"; print "VL:\t\t\t",$VL,"\n"; print "RL:\t\t\t",$RL,"\n"; print "Abgas:\t\t\t",$ABGAS,"\n"; print "EINSCH_TEMP_SOL:\t",$EINSCH_TEMP_SOL,"\n"; print "Betriebszustand:\t",$BETRIEBSZUSTAND,"\n"; print "Generator Leitsung Sol:\t",$GEN_LEISTUNG_SOL,"\n"; print "BETRIEBSZUSTAND_SOL:\t",$BETRIEBSZUSTAND_SOL,"\n"; my $i=0; while ($i <=5 ) { #$SERVICE_CODE_MODUL[$i]=hex($e8sex[$i+10]); print "SERVICE_CODE_MODUL[".$i."]\t".$SERVICE_CODE_MODUL[$i],"\n"; $i++ } print "\n"; print "*********** DEBUG Ende **************\n\n"; } </source> === c0 === '''Ein Beispiel für die c0 Werte''' <source lang="perl"> #!/usr/bin/perl -w # Abfrage der Dachs c0-Werte per esex # # kleines Beispielscript, das die c0 Wert abholt ud anschliesend aufbereitet # in Variabeln schreibt. # Das Script kann als Vorlage für eigene Entwicklungen benutzt werden. # # Autor: Lothar Schweikle-Droll # Lizenz: GPL use strict; use Net::Telnet (); my $debug=1; my $esex; my $esexip="192.168.255.90"; my $esexport="2701"; my $c0hex1; my $c0hex2; my $c0hex3; my $c0hex4; my $c0hex; my @c0hex; my $WARTUNG; my $RL; my $VL; my $SRL; my $SVL; my $BETRIEBSSTUNDEN; my $ABGAS; my $AUSENTEMP; my $F1TEMP; my $F2TEMP; my $GENERTEMP; my $MOTORTEMP; my $SERVICECODE; my $BETRIEBSART; my $BHKW_FREIGABE; my $BRENNER_FREIGABE; my $DREHZAHL; my $ERZEUGTE_E_ENERGIE; my $ERZEUGT_WAERME; my $GEN_LEISTUNG; my $STARTS; my $non; &e8_esex; &wertezuweisung; ### Ab hier kann eigener Code stehen if ( $debug == 1){ &debug; } ##### Subrotinen sub e8_esex { #Dachs C0 abfrge per Telnet über den ethersex $esex = Net::Telnet->new || die "kann Ethersex nicht finden"; $esex->open(Host => $esexip, Port => $esexport, Timeout => 1); # $c0hex1=$esex->cmd('msr1 get 1'); $esex->print("msr1 get 1"); ($non, $c0hex1) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $c0hex2) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $c0hex3) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $c0hex4) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); $c0hex = ($c0hex1).($c0hex2).($c0hex3).($c0hex4); #die vier Einzelwerte zu einem gesamt String zusammensetzen @c0hex = $c0hex =~ /(..)/g; #Den String in eine Array schreiben (nur die HEX-Werte ohne Leerstellen } sub wertezuweisung { $BETRIEBSSTUNDEN=hex($c0hex[19].$c0hex[20]); $WARTUNG=$c0hex[3]; #RL auf negative Temp prüfen if (hex($c0hex[22]) >128 ) { $RL=hex($c0hex[22])-255; }else{ $RL=hex($c0hex[22]); } $SRL=hex($c0hex[21]); #VL auf negative Temp prüfen if (hex($c0hex[24]) >128 ) { $VL=hex($c0hex[24])-255; }else{ $VL=hex($c0hex[24]); } $SVL=hex($c0hex[23]); #Ausentemp auf negative Temp prüfen if (hex($c0hex[25]) >128 ) { $AUSENTEMP=hex($c0hex[25])-255; }else{ $AUSENTEMP=hex($c0hex[25]); } #F1 und F2 auf negative Temp prüfen if (hex($c0hex[26]) >128 ) { $F1TEMP=hex($c0hex[26])-255; }else{ $F1TEMP=hex($c0hex[26]); } if (hex($c0hex[27]) >128 ) { $F2TEMP=hex($c0hex[27])-255; }else{ $F2TEMP=hex($c0hex[27]); } $GENERTEMP=hex($c0hex[28]); $SERVICECODE=hex($c0hex[30]); $BETRIEBSART=$c0hex[31]; $BHKW_FREIGABE=hex($c0hex[32]); $BRENNER_FREIGABE=hex($c0hex[33]); $MOTORTEMP=hex($c0hex[34]); $ABGAS=hex($c0hex[35])+15; $DREHZAHL=hex($c0hex[36].$c0hex[37]); $ERZEUGTE_E_ENERGIE=hex($c0hex[38].$c0hex[39].$c0hex[40].$c0hex[41]); $ERZEUGT_WAERME=hex($c0hex[42].$c0hex[43].$c0hex[44].$c0hex[45]); $GEN_LEISTUNG=sprintf("%.3f" , hex($c0hex[46])/34); #Sollwert Der Generatorleistung gerundet auf 3 Stellen nach dem Komma $STARTS=hex($c0hex[47].$c0hex[48]); } sub debug { print "\n*********** DEBUG Start *************\n\n"; print "c0-Hexwert:","@c0hex","\n\n"; print "Betriebstunden:\t\t",$BETRIEBSSTUNDEN,"\n"; print "Wartung:\t\t",$WARTUNG,"\n"; print "VL:\t\t\t",$VL,"\n"; print "RL:\t\t\t",$RL,"\n"; print "F1:\t\t\t",$F1TEMP,"\n"; print "F2:\t\t\t",$F2TEMP,"\n"; print "VL Soll:\t\t",$SVL,"\n"; print "RL Soll:\t\t",$SRL,"\n"; print "Ausen:\t\t\t",$AUSENTEMP,"\n"; print "Generator Temp:\t\t",$GENERTEMP,"\n"; print "Servicecode:\t\t",$SERVICECODE,"\n"; print "Betreibsart:\t\t",$BETRIEBSART,"\n"; print "BHKW Freigabe:\t\t",$BHKW_FREIGABE,"\n"; print "Brenner Freigabe:\t",$BRENNER_FREIGABE,"\n"; print "Motor Temp:\t\t",$MOTORTEMP,"\n"; print "Abgas:\t\t\t",$ABGAS,"\n"; print "Drehzahl:\t\t",$DREHZAHL,"\n"; print "erzeugte E-Energie:\t",$ERZEUGTE_E_ENERGIE,"\n"; print "erzeugte Wärme:\t\t",$ERZEUGT_WAERME,"\n"; print "Generator ist:\t\t",$GEN_LEISTUNG,"\n"; print "Startvorgang:\t\t",$STARTS,"\n"; print "\n"; print "*********** DEBUG Ende **************\n\n"; } </source> === 48 === '''Ein Beispiel für die 48 Werte''' <source lang="perl"> #!/usr/bin/perl -w # Abfrage der Dachs 48-Werte per esex # # kleines Beispielscript, das die 48 Wert abholt ud anschliesend aufbereitet # in Variabeln schreibt. # Das Script kann als Vorlage für eigene Entwicklungen benutzt werden. # # Autor: Lothar Schweikle-Droll # Lizenz: GPL use strict; use Net::Telnet (); my $debug=1; my $esex; my $esexip="192.168.255.90"; my $esexport="2701"; my $x48hex1; my $x48hex2; my $x48hex3; my $x48hex4; my $x48hex; my @x48hex; my $WARTUNG; my $BETRIEBSSTUNDEN; my $MAXABGAS; my $VL; my $STOERUNGEN; my $F1TEMP; my $F2TEMP; my $MAXGENERTEMP; my $MAXMOTORTEMP; my $STARTS; my $MITTELGENLEISTUNG; my $FLUESSIGKEITSCHALTER; my $LETZTEWARTUNG; my $NAECHSTEWARTUNGOEL; my $NAECHSTEWARTUNGGAS; my @FEHLERCODE; #000-127 my @FEHLERAUTO; #1=Autoentstörung my @FEHLERCODELANG; my @FEHLERMIN; my @FEHLERSTUNDEN; my @FEHLERTAG; my @FEHLERMON; my @FEHLERJAHR; my @FEHLERDATUM; my $non; my %Servicecode = ( 0=>'Allgemeine Hilfe', 1=>'Abgasfühler U/K', 2=>'Kuehlw.Motor U/K', 3=>'Kuehlw.Gener. U/K', 4=>'04', 5=>'Vorlauftemp. U/K', 6=>'Ruecklauftemp U/K', 7=>'Fuehler 1 U/K', 8=>'Fuehler 2 U/K', 9=>'Aussentemp. U/K', 10=>'Fluessigkeit. U/K', 11=>'11', 11=>'12', 13=>'13', 14=>'14', 15=>'15', 16=>'16', 17=>'17', 18=>'18', 19=>'19', 20=>'Abgas Motor zu hoch', 21=>'21', 22=>'Kuehlw. Motor > 95 C', 23=>'Abgastemp. zu hoch', 24=>'Kuehlw. Generator > 77 C', 25=>'25', 26=>'2h Vorlauft < Soll', 27=>'27', 28=>'28', 29=>'UP:Rueckleistung', 30=>'30', 31=>'HKA-Anl. < 100 U/min', 32=>'32', 33=>'HKA-Lauf < 2300 U/m', 34=>'34', 35=>'35', 36=>'36', 37=>'37', 38=>'38', 39=>'Generatorzuschalt', 40=>'Generatorabschalt', 41=>'Generator fehlt', 42=>'kein Text', 43=>'kein Text', 44=>'1h Si-Kette offen', 45=>'kein Text', 46=>'kein Text', 47=>'kein Text', 48=>'UP/LP:Int. b. Start', 49=>'UP: Intern', 50=>'UP/LP: Intern', 51=>'UP:Startfreigabe', 52=>'UP:Datentransfer', 53=>'UP:keine Daten', 54=>'kein Text', 55=>'kein Text', 56=>'UP:Messk Drehzahl', 56=>'kein Text', 57=>'kein Text', 58=>'kein Text', 59=>'UP:Spannung b.St.', 60=>'UP: Spannung', 61=>'kein Text', 62=>'Leistung zu hoch', 63=>'Leistung zu klein', 64=>'Leistung im Stand', 65=>'kein Text', 66=>'ENS-3 Abschaltung', 67=>'UP:Frequenz b.St', 68=>'UP:Frequenz', 69=>'UP:Phasen', 70=>'kein Text', 71=>'Oeldruckschalter', 72=>'Oeldruckmangel', 73=>'MV/Hubmag.undicht', 74=>'MV/Hubmag.undicht', 75=>'kein Text', 76=>'Programmdurchlauf', 77=>'kein Text', 78=>'kein Text', 79=>'4 Starts < 2300 U/m', 80=>'kein Text', 81=>'kein Text', 82=>'kein Text', 83=>'kein Text', 84=>'UP:Drehfeld', 85=>'Fluessigkeitssch', 86=>'UP: Zuendaussetzer', 87=>'Drehz. > 3300 U/min', 88=>'4 Starts 400-800U/m', 89=>'4Starts < 400 U/min', 90=>'kein Text', 91=>'UP:Drehz > 3500 U/m', 92=>'UP:verriegelt', 93=>'UP/RP-Prog.falsch', 94=>'kein Text', 95=>'No ClkRAM Kommuni', 96=>'No Ack-w I2C-Bus', 97=>'No Ack-r I2C-Bus', 98=>'Clk_RAM write nOK', 99=>'UP:Flags'); &x48_esex; &wertezuweisung; ### Ab hier kann eigener Code stehen if ( $debug == 1){ &debug; } ##### Subrotinen sub x48_esex { #Dachs 48 abfrge per Telnet über den ethersex $esex = Net::Telnet->new || die "kann Ethersex nicht finden"; $esex->open(Host => $esexip, Port => $esexport, Timeout => 1); # $x48hex1=$esex->cmd('msr1 get 1'); $esex->print("msr1 get 2"); ($non, $x48hex1) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $x48hex2) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $x48hex3) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $x48hex4) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); $x48hex = ($x48hex1).($x48hex2).($x48hex3).($x48hex4); #die vier Einzelwerte zu einem gesamt String zusammensetzen @x48hex = $x48hex =~ /(..)/g; #Den String in eine Array schreiben (nur die HEX-Werte ohne Leerstellen } sub wertezuweisung { $BETRIEBSSTUNDEN=hex($x48hex[1].$x48hex[2]); $STARTS=hex($x48hex[3].$x48hex[4]); $MAXABGAS=hex($x48hex[5])+15; $MAXGENERTEMP=hex($x48hex[7]); $MAXMOTORTEMP=hex($x48hex[6]); #MAXVL auf negative Temp prüfen if (hex($x48hex[8]) >128 ) { $VL=hex($x48hex[8])-255; }else{ $VL=hex($x48hex[8]); } #Max F1 und F2 auf negative Temp prüfen if (hex($x48hex[9]) >128 ) { $F1TEMP=hex($x48hex[9])-255; }else{ $F1TEMP=hex($x48hex[9]); } if (hex($x48hex[10]) >128 ) { $F2TEMP=hex($x48hex[10])-255; }else{ $F2TEMP=hex($x48hex[10]); } $MITTELGENLEISTUNG=(7.5 / 255 * hex($x48hex[11])); $STOERUNGEN=hex($x48hex[12]); $FLUESSIGKEITSCHALTER=hex($x48hex[55]); $LETZTEWARTUNG=hex($x48hex[59].$x48hex[60]); $NAECHSTEWARTUNGOEL=hex($x48hex[59].$x48hex[60])+2700; $NAECHSTEWARTUNGGAS=hex($x48hex[59].$x48hex[60])+3500; #Fehler Code zuweisen for ($non=1;$non<=7;$non++) { $FEHLERCODE[$non]=hex($x48hex[7+(6*$non)]); $FEHLERAUTO[$non]="0"; if ( $FEHLERCODE[$non] > 127 ) { $FEHLERCODE[$non]=$FEHLERCODE[$non]-128; $FEHLERAUTO[$non]="1"; } $FEHLERCODELANG[$non]=$Servicecode{$FEHLERCODE[$non]}; $FEHLERSTUNDEN[$non]=hex($x48hex[9+(6*$non)]); if ( $FEHLERSTUNDEN[$non]=~ /^[0-9]$/ ) { $FEHLERSTUNDEN[$non]='0'.$FEHLERSTUNDEN[$non]; } $FEHLERMIN[$non]=hex($x48hex[8+(6*$non)]); if ( $FEHLERMIN[$non]=~ /^[0-9]$/ ) { $FEHLERMIN[$non]='0'.$FEHLERMIN[$non]; } $FEHLERTAG[$non]=hex($x48hex[10+(6*$non)]); if ( $FEHLERTAG[$non]=~ /^[0-9]$/ ) { $FEHLERTAG[$non]='0'.$FEHLERTAG[$non]; } $FEHLERMON[$non]=hex($x48hex[11+(6*$non)]); if ( $FEHLERMON[$non]=~ /^[0-9]$/ ) { $FEHLERMON[$non]='0'.$FEHLERMON[$non]; } $FEHLERJAHR[$non]=hex($x48hex[12+(6*$non)]); if ( $FEHLERJAHR[$non]=~ /^[0-9]$/ ) { $FEHLERJAHR[$non]='0'.$FEHLERJAHR[$non]; } $FEHLERDATUM[$non]=$FEHLERSTUNDEN[$non].":".$FEHLERMIN[$non]." ".$FEHLERTAG[$non].".".$FEHLERMON[$non].".".$FEHLERJAHR[$non]; #Deutsch ohne Sekunden $FEHLERDATUM[$non]=$FEHLERJAHR[$non]."-".$FEHLERMON[$non]."-".$FEHLERTAG[$non]." ".$FEHLERSTUNDEN[$non].":".$FEHLERMIN[$non].":30"; #International mit gemittelte Sekunden #print "HEXzahl: ".(7 + (6 * $non))."\n"; } } sub debug { print "\n*********** DEBUG Start *************\n\n"; print "48-Hexwert:","@x48hex","\n\n"; print "Betriebstunden:\t\t",$BETRIEBSSTUNDEN,"\n"; print "Letzte Wartung:\t\t",$LETZTEWARTUNG,"\n"; print "Wartung bei Öl (alle 2700h):\t",$NAECHSTEWARTUNGOEL,"\n"; print "Wartung bei Gas (alle 3500h):\t",$NAECHSTEWARTUNGGAS,"\n"; print "Starts:\t\t\t",$STARTS,"\n"; print "MAX Abgas:\t\t",$MAXABGAS,"\n"; print "MAX Gen Temp:\t\t",$MAXGENERTEMP,"\n"; print "MAX Mot Temp:\t\t",$MAXMOTORTEMP,"\n"; print "Max VL:\t\t\t",$VL,"\n"; print "Max F1:\t\t\t",$F1TEMP,"\n"; print "Max F2:\t\t\t",$F2TEMP,"\n"; print "Mittlere Gen Leistung:\t",$MITTELGENLEISTUNG,"\n"; print "Anzahl Störungen:\t",$STOERUNGEN,"\n"; print "Fluessigkeitsschalter:\t",$FLUESSIGKEITSCHALTER,"\n\n"; print "Fehlerpeicher\n"; print "=============\n"; for ($non=1;$non<=7;$non++) { print "Fehler: ".$non."\n"; print "Fehlercode: ".$FEHLERCODE[$non]."\n"; print "Autoentstörung: ".$FEHLERAUTO[$non]."\n"; print "Zeit: ".$FEHLERSTUNDEN[$non].":".$FEHLERMIN[$non]." ".$FEHLERTAG[$non].".".$FEHLERMON[$non].".".$FEHLERJAHR[$non]."\n"; print "Datum: ".$FEHLERDATUM[$non]."\n"; print "Langtext: ".$FEHLERCODELANG[$non]."\n\n"; } print "\n"; print "*********** DEBUG Ende **************\n\n"; } </source> === 50 === '''Ein Beispiel für die 50 Werte''' <source lang="perl"> #!/usr/bin/perl -w # Abfrage der Dachs 50-Werte per esex # # kleines Beispielscript, das die 50 Wert abholt ud anschliesend aufbereitet # in Variabeln schreibt. # Das Script kann als Vorlage für eigene Entwicklungen benutzt werden. # # Autor: Lothar Schweikle-Droll # Lizenz: GPL use strict; use constant PI => 4 * atan2(1, 1); #Wegen cosph Berechnung use Net::Telnet (); my $debug=1; my $esex; my $esexip="192.168.255.90"; my $esexport="2701"; my $x50hex1; my $x50hex2; my $x50hex3; my $x50hex4; my $x50hex; my @x50hex; my $RL; my $VL; my $MOTORTEMP; my $ABGAS; my $AUSENTEMP; my $F1TEMP; my $F2TEMP; my $GENERTEMP; my $DREHZAHL; my $BIVAL_UMSCHALT_TMP; my $BIVAL_UMSCHALT_ZEIT; my $SERVICE; my $UMWALZPUMPESTATUS1; my $UMWALZPUMPESTATUS2; my $U1; my $U2; my $U3; my $I1; my $I2; my $I3; my $COSPHI; my $UE_PLATINE; my $non; &e8_esex; &wertezuweisung; ### Ab hier kann eigener Code stehen if ( $debug == 1){ &debug; } ##### Subrotinen sub e8_esex { #Dachs C0 abfrge per Telnet über den ethersex $esex = Net::Telnet->new || die "kann Ethersex nicht finden"; $esex->open(Host => $esexip, Port => $esexport, Timeout => 1); # $x50hex1=$esex->cmd('msr1 get 1'); $esex->print("msr1 get 3"); ($non, $x50hex1) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $x50hex2) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $x50hex3) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $x50hex4) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); $x50hex = ($x50hex1).($x50hex2).($x50hex3).($x50hex4); #die vier Einzelwerte zu einem gesamt String zusammensetzen @x50hex = $x50hex =~ /(..)/g; #Den String in eine Array schreiben (nur die HEX-Werte ohne Leerstellen } sub wertezuweisung { #VL auf negative Temp prüfen if (hex($x50hex[1]) >128 ) { $VL=hex($x50hex[1])-255; }else{ $VL=hex($x50hex[1]); } #RL auf negative Temp prüfen if (hex($x50hex[2]) >128 ) { $RL=hex($x50hex[2])-255; }else{ $RL=hex($x50hex[2]); } $MOTORTEMP=hex($x50hex[3]); $ABGAS=hex($x50hex[4])+15; #Ausentemp auf negative Temp prüfen if (hex($x50hex[5]) >128 ) { $AUSENTEMP=hex($x50hex[5])-255; }else{ $AUSENTEMP=hex($x50hex[5]); } #F1 und F2 auf negative Temp prüfen if (hex($x50hex[6]) >128 ) { $F1TEMP=hex($x50hex[6])-255; }else{ $F1TEMP=hex($x50hex[6]); } if (hex($x50hex[7]) >128 ) { $F2TEMP=hex($x50hex[7])-255; }else{ $F2TEMP=hex($x50hex[7]); } $GENERTEMP=hex($x50hex[8]); $ABGAS=hex($x50hex[4])+15; $DREHZAHL=hex($x50hex[10].$x50hex[11]); $BIVAL_UMSCHALT_TMP=hex($x50hex[13]); $BIVAL_UMSCHALT_ZEIT=hex($x50hex[14].$x50hex[15]); #Wert in Minuten $SERVICE=hex($x50hex[16]); $UMWALZPUMPESTATUS1=hex($x50hex[21]); $UMWALZPUMPESTATUS2=hex($x50hex[21]); $U1=105.6 + (100.0 / 461) * (hex($x50hex[31].$x50hex[32])); #105.6V + (100.0 /0x1cd) * Wert $U2=314.4 - (100.0 / 461) * (hex($x50hex[33].$x50hex[34])); #314.4V - (100.0 /0x1cd) * Wert $U3=105.6 + (100.0 / 461) * (hex($x50hex[35].$x50hex[36])); #105.6V + (100.0 /0x1cd) * Wert $I1=hex($x50hex[37].$x50hex[38]) * (10.0 / 461) - (10.0 * 205) / 461 ; #Wert * (10.0A /0x1cd) - (10.0*0xcd)/0x1cd $I2=hex($x50hex[39].$x50hex[40]) * (10.0 / 461) - (10.0 * 205) / 461; #Wert * (10.0A /0x1cd) - (10.0*0xcd)/0x1cd $I3=10.0 / 461 * (757 - (hex($x50hex[41].$x50hex[42]))); #10.0A/0x1cd * (0x02f5 - Wert) #$x50hex[43]='C9'; $COSPHI=abs( cos(((hex($x50hex[43]))-128)*PI/180) ); if (hex($x50hex[45]) >= 253 ) { $UE_PLATINE='ok'; }else{ $UE_PLATINE='error'; } } sub debug { print "\n*********** DEBUG Start *************\n\n"; print "50-Hexwert:","@x50hex","\n\n"; print "VL:\t\t\t",$VL,"\n"; print "RL:\t\t\t",$RL,"\n"; print "Motor Temp:\t\t",$MOTORTEMP,"\n"; print "Abgas:\t\t\t",$ABGAS,"\n"; print "F1:\t\t\t",$F1TEMP,"\n"; print "F2:\t\t\t",$F2TEMP,"\n"; print "Generator Temp:\t\t",$GENERTEMP,"\n"; print "Drehzahl:\t\t",$DREHZAHL,"\n"; print "BIVAL_UMSCHALT_TMP:\t",$BIVAL_UMSCHALT_TMP,"\n"; print "BIVAL_UMSCHALT_ZEIT:\t",$BIVAL_UMSCHALT_ZEIT,"\n"; print "U1:\t\t\t",$U1," ",hex($x50hex[31].$x50hex[32]),"\n"; print "U2:\t\t\t",$U2," ",hex($x50hex[33].$x50hex[34]),"\n"; print "U3:\t\t\t",$U3," ",hex($x50hex[35].$x50hex[36]),"\n"; print "I1:\t\t\t",$I1," ",hex($x50hex[37].$x50hex[38]),"\n"; print "I2:\t\t\t",$I2," ",hex($x50hex[39].$x50hex[40]),"\n"; print "I3:\t\t\t",$I3," ",hex($x50hex[41].$x50hex[42]),"\n"; print "COSPHI:\t\t\t",$COSPHI," ",hex($x50hex[43]),"\n"; print "UE_PLATINE:\t\t",$UE_PLATINE," ",hex($x50hex[45]),"\n"; print "UMWALZPUMPESTATUS1:\t",$UMWALZPUMPESTATUS1,"\n"; print "UMWALZPUMPESTATUS2:\t",$UMWALZPUMPESTATUS2,"\n"; print "\n"; print "*********** DEBUG Ende **************\n\n"; } </source> [[Kategorie:Ethersex]] [[Kategorie:Home-Visualisierung]] [[Category:MSR1]] baf7dcf89c318c87083f5049308570c7c17ab69f 174 172 2011-11-08T10:22:55Z Loddel 64 /* Anschluss */ wikitext text/x-wiki Die Dachs MSR1 ist ein Klein-Blockheizkraftwerk (BHKW) der Firma [http://www.senertec.de SenerTec], die sowohl Wärme, als auch Strom erzeugt, und vor allem eine serielle Schnittstelle zur Verfügung stellt *Händereib*. Über diese kann man einiges an Betriebs- und Wartungsdaten auslesen. Eine genauere Beschreibung des Protokolls gibts [[Dachs_MSR1_Service_Protokoll|hier]]. │ │ Load a Default Configuration ---> │ │ ... │ │ IO Support ---> | | ... │ │ [*] Senertec Dachs MSR1 Support │ │ (0) MSR1 usart select == Anschluss == [[File:Dachs_msr1_anschluss.png]] Obwohl sowohl das Ethersex, als auch die MSR1 einen Slave (Weiblich) RS232 Anschluss hat braucht man ein 1:1 Kabel. Außerdem muss das RTS Signal des MSR1 auf eine logische Null gelegt werden, da sich die MSR1 sonst nicht für irgendwelche Befehle interessiert. Dazu verwendet man am besten den zweiten Kanal des verbauten MAX232, legt den Eingang auf GND und greift die +10V am Ausgang ab. Ansonsten ist der RS232 Anschluss ein 9600 8N1. == Alternative Kabelbelegung == Im [http://www.bhkw-forum.de BHKW-Forum] gibt es noch eine alternative Kabelbelegung. Zu beachten ist nur, das man die Leitungen nicht kreuzen darf. (getestet mit dem AVR-Net-IO) [[Media:Kabelbelegung_Dachs_MRS1.pdf]] Die dort beschriebene Belegung ist also für PC->Dachs gedacht. Diese Variante funktioniert mit einem ethersex nur dann, wenn an der RS232 Buchse auch der RTS Kanal durch den MAX232 geschleift wird. (Und die Ethersexfirmware um RTS Handshaking erweitert wurde *huestel*) == Auslesen == Der MSR1 kann man zwei verschiedene Datensätze entlocken, den "0xe8"-Datensatz und den "0xc0"-Datensatz. Beide enthalten teilweise redundante Daten, wobei jedoch letzterer weitaus mehr Informationen bietet. Den 0xe8 Datensatz bekommt man mit dem ecmd `msr1 get' bzw. `msr1 get 0'. Das erste Byte gibt an, wieviele Anfragen seit dem letzten erfolgreichen Versuch fehlgeschlagen sind. Den 0xc0-Datensatz bekommt man über `msr1 get 1'. == Einbindung in den [[HTTPD]] == [[Bild:Msr1_screenshot.png|600px]] │ │ Load a Default Configuration ---> │ │ ... │ │ General Setup ---> │ │ ... │ │ [*] VFS (Virtual File System) ---> │ │ [*] VFS File Inling │ │ [*] Inline MSR1 Unter '''$ethersexip/msr.ht''' kann nun der aktuelle Status des Dachs ausgelesen werden. = Programm Beispiele = == Abfrage in Perl == === e8 === '''Ein Beispiel wie die Werte e8 abgefragt und aufbereitet werden.''' <source lang="perl"> #!/usr/bin/perl -w # Abfrage der Dachs e8-Werte per esex # # kleines Beispielscript, das die e8 Wert abholt ud anschliesend aufbereitet # in Variabeln schreibt. # Das Script kann als Vorlage für eigene Entwicklungen benutzt werden. # # Autor: Lothar Schweikle-Droll # Lizenz: GPL use strict; use Net::Telnet (); my $debug=1; my $esex; my $esexip="192.168.255.90"; my $esexport="2701"; my $e8hex; my @e8hex; my $BETRIEBSSTUNDEN; my $WARTUNG; my $RL; my $VL; my $ABGAS; my $EINSCH_TEMP_SOL; my $BETRIEBSZUSTAND; my $BETRIEBSZUSTAND_SOL; my $GEN_LEISTUNG_SOL; my @SERVICE_CODE_MODUL; #Modul 0 = Leitregler my %BETRIEBSZUSTAND = ( 10=>'Störabschaltung', 11=>'Abschaltung MV1', 11=>'Abschaltung MV2', 13=>'Drehzahl<200 n. 25 sek.', 14=>'Drehzahl>200 n. 25 sek.', 15=>'Abschaltung>1 Minute', 16=>'Abschaltung>4 Minuten', 20=>'Startvorbereitung', 21=>'Starteinleitung', 22=>'Start', 23=>'1,5 sek. nach Start', 24=>'Startende', 30=>'450<Drehz<800', 32=>'Zuschaltung Generator', 33=>'Leistungsregelung runter', 34=>'Leistungsregelung hoch', 35=>'Betrieb'); my $non; &e8_esex; &wertezuweisung; ### Ab hier kann eigener Code stehen if ( $debug == 1){ &debug; } ##### Subrotinen sub e8_esex { #Dachs e8 abfrge per Telnet über den ethersex $esex = Net::Telnet->new || die "kann Ethersex nicht finden"; $esex->open(Host => $esexip, Port => $esexport, Timeout => 1); $esex->print("msr1 get 0"); ($non, $e8hex) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); #den String in ein Array wandeln @e8hex = $e8hex =~ /(..)/g; } sub wertezuweisung { $BETRIEBSSTUNDEN=hex($e8hex[1].$e8hex[2]); $WARTUNG=hex($e8hex[3]); #RL auf negative Temp prüfen if (hex($e8hex[4]) >128 ) { $RL=hex($e8hex[4])-255; }else{ $RL=hex($e8hex[4]); } #VL auf negative Temp prüfen if (hex($e8hex[5]) >128 ) { $VL=hex($e8hex[5])-255; }else{ $VL=hex($e8hex[5]); } $ABGAS=hex($e8hex[6])+15; $EINSCH_TEMP_SOL=hex($e8hex[7]); $BETRIEBSZUSTAND=$BETRIEBSZUSTAND{hex($e8hex[8])}; $GEN_LEISTUNG_SOL= sprintf("%.3f" , hex($e8hex[9])/34); #Sollwert Der Generatorleistung gerundet auf 3 Stellen nach dem Komma my $i=0; while ($i <=5 ) { $SERVICE_CODE_MODUL[$i]=hex($e8hex[$i+10]); $i++ } $BETRIEBSZUSTAND_SOL=hex($e8hex[16]); } sub debug { print "\n*********** DEBUG Start *************\n\n"; print "e8-Hexwert:","@e8hex","\n\n"; print "Betriebstundenb:\t",$BETRIEBSSTUNDEN,"\n"; print "Wartung:\t\t",$WARTUNG,"\n"; print "VL:\t\t\t",$VL,"\n"; print "RL:\t\t\t",$RL,"\n"; print "Abgas:\t\t\t",$ABGAS,"\n"; print "EINSCH_TEMP_SOL:\t",$EINSCH_TEMP_SOL,"\n"; print "Betriebszustand:\t",$BETRIEBSZUSTAND,"\n"; print "Generator Leitsung Sol:\t",$GEN_LEISTUNG_SOL,"\n"; print "BETRIEBSZUSTAND_SOL:\t",$BETRIEBSZUSTAND_SOL,"\n"; my $i=0; while ($i <=5 ) { #$SERVICE_CODE_MODUL[$i]=hex($e8sex[$i+10]); print "SERVICE_CODE_MODUL[".$i."]\t".$SERVICE_CODE_MODUL[$i],"\n"; $i++ } print "\n"; print "*********** DEBUG Ende **************\n\n"; } </source> === c0 === '''Ein Beispiel für die c0 Werte''' <source lang="perl"> #!/usr/bin/perl -w # Abfrage der Dachs c0-Werte per esex # # kleines Beispielscript, das die c0 Wert abholt ud anschliesend aufbereitet # in Variabeln schreibt. # Das Script kann als Vorlage für eigene Entwicklungen benutzt werden. # # Autor: Lothar Schweikle-Droll # Lizenz: GPL use strict; use Net::Telnet (); my $debug=1; my $esex; my $esexip="192.168.255.90"; my $esexport="2701"; my $c0hex1; my $c0hex2; my $c0hex3; my $c0hex4; my $c0hex; my @c0hex; my $WARTUNG; my $RL; my $VL; my $SRL; my $SVL; my $BETRIEBSSTUNDEN; my $ABGAS; my $AUSENTEMP; my $F1TEMP; my $F2TEMP; my $GENERTEMP; my $MOTORTEMP; my $SERVICECODE; my $BETRIEBSART; my $BHKW_FREIGABE; my $BRENNER_FREIGABE; my $DREHZAHL; my $ERZEUGTE_E_ENERGIE; my $ERZEUGT_WAERME; my $GEN_LEISTUNG; my $STARTS; my $non; &e8_esex; &wertezuweisung; ### Ab hier kann eigener Code stehen if ( $debug == 1){ &debug; } ##### Subrotinen sub e8_esex { #Dachs C0 abfrge per Telnet über den ethersex $esex = Net::Telnet->new || die "kann Ethersex nicht finden"; $esex->open(Host => $esexip, Port => $esexport, Timeout => 1); # $c0hex1=$esex->cmd('msr1 get 1'); $esex->print("msr1 get 1"); ($non, $c0hex1) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $c0hex2) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $c0hex3) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $c0hex4) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); $c0hex = ($c0hex1).($c0hex2).($c0hex3).($c0hex4); #die vier Einzelwerte zu einem gesamt String zusammensetzen @c0hex = $c0hex =~ /(..)/g; #Den String in eine Array schreiben (nur die HEX-Werte ohne Leerstellen } sub wertezuweisung { $BETRIEBSSTUNDEN=hex($c0hex[19].$c0hex[20]); $WARTUNG=$c0hex[3]; #RL auf negative Temp prüfen if (hex($c0hex[22]) >128 ) { $RL=hex($c0hex[22])-255; }else{ $RL=hex($c0hex[22]); } $SRL=hex($c0hex[21]); #VL auf negative Temp prüfen if (hex($c0hex[24]) >128 ) { $VL=hex($c0hex[24])-255; }else{ $VL=hex($c0hex[24]); } $SVL=hex($c0hex[23]); #Ausentemp auf negative Temp prüfen if (hex($c0hex[25]) >128 ) { $AUSENTEMP=hex($c0hex[25])-255; }else{ $AUSENTEMP=hex($c0hex[25]); } #F1 und F2 auf negative Temp prüfen if (hex($c0hex[26]) >128 ) { $F1TEMP=hex($c0hex[26])-255; }else{ $F1TEMP=hex($c0hex[26]); } if (hex($c0hex[27]) >128 ) { $F2TEMP=hex($c0hex[27])-255; }else{ $F2TEMP=hex($c0hex[27]); } $GENERTEMP=hex($c0hex[28]); $SERVICECODE=hex($c0hex[30]); $BETRIEBSART=$c0hex[31]; $BHKW_FREIGABE=hex($c0hex[32]); $BRENNER_FREIGABE=hex($c0hex[33]); $MOTORTEMP=hex($c0hex[34]); $ABGAS=hex($c0hex[35])+15; $DREHZAHL=hex($c0hex[36].$c0hex[37]); $ERZEUGTE_E_ENERGIE=hex($c0hex[38].$c0hex[39].$c0hex[40].$c0hex[41]); $ERZEUGT_WAERME=hex($c0hex[42].$c0hex[43].$c0hex[44].$c0hex[45]); $GEN_LEISTUNG=sprintf("%.3f" , hex($c0hex[46])/34); #Sollwert Der Generatorleistung gerundet auf 3 Stellen nach dem Komma $STARTS=hex($c0hex[47].$c0hex[48]); } sub debug { print "\n*********** DEBUG Start *************\n\n"; print "c0-Hexwert:","@c0hex","\n\n"; print "Betriebstunden:\t\t",$BETRIEBSSTUNDEN,"\n"; print "Wartung:\t\t",$WARTUNG,"\n"; print "VL:\t\t\t",$VL,"\n"; print "RL:\t\t\t",$RL,"\n"; print "F1:\t\t\t",$F1TEMP,"\n"; print "F2:\t\t\t",$F2TEMP,"\n"; print "VL Soll:\t\t",$SVL,"\n"; print "RL Soll:\t\t",$SRL,"\n"; print "Ausen:\t\t\t",$AUSENTEMP,"\n"; print "Generator Temp:\t\t",$GENERTEMP,"\n"; print "Servicecode:\t\t",$SERVICECODE,"\n"; print "Betreibsart:\t\t",$BETRIEBSART,"\n"; print "BHKW Freigabe:\t\t",$BHKW_FREIGABE,"\n"; print "Brenner Freigabe:\t",$BRENNER_FREIGABE,"\n"; print "Motor Temp:\t\t",$MOTORTEMP,"\n"; print "Abgas:\t\t\t",$ABGAS,"\n"; print "Drehzahl:\t\t",$DREHZAHL,"\n"; print "erzeugte E-Energie:\t",$ERZEUGTE_E_ENERGIE,"\n"; print "erzeugte Wärme:\t\t",$ERZEUGT_WAERME,"\n"; print "Generator ist:\t\t",$GEN_LEISTUNG,"\n"; print "Startvorgang:\t\t",$STARTS,"\n"; print "\n"; print "*********** DEBUG Ende **************\n\n"; } </source> === 48 === '''Ein Beispiel für die 48 Werte''' <source lang="perl"> #!/usr/bin/perl -w # Abfrage der Dachs 48-Werte per esex # # kleines Beispielscript, das die 48 Wert abholt ud anschliesend aufbereitet # in Variabeln schreibt. # Das Script kann als Vorlage für eigene Entwicklungen benutzt werden. # # Autor: Lothar Schweikle-Droll # Lizenz: GPL use strict; use Net::Telnet (); my $debug=1; my $esex; my $esexip="192.168.255.90"; my $esexport="2701"; my $x48hex1; my $x48hex2; my $x48hex3; my $x48hex4; my $x48hex; my @x48hex; my $WARTUNG; my $BETRIEBSSTUNDEN; my $MAXABGAS; my $VL; my $STOERUNGEN; my $F1TEMP; my $F2TEMP; my $MAXGENERTEMP; my $MAXMOTORTEMP; my $STARTS; my $MITTELGENLEISTUNG; my $FLUESSIGKEITSCHALTER; my $LETZTEWARTUNG; my $NAECHSTEWARTUNGOEL; my $NAECHSTEWARTUNGGAS; my @FEHLERCODE; #000-127 my @FEHLERAUTO; #1=Autoentstörung my @FEHLERCODELANG; my @FEHLERMIN; my @FEHLERSTUNDEN; my @FEHLERTAG; my @FEHLERMON; my @FEHLERJAHR; my @FEHLERDATUM; my $non; my %Servicecode = ( 0=>'Allgemeine Hilfe', 1=>'Abgasfühler U/K', 2=>'Kuehlw.Motor U/K', 3=>'Kuehlw.Gener. U/K', 4=>'04', 5=>'Vorlauftemp. U/K', 6=>'Ruecklauftemp U/K', 7=>'Fuehler 1 U/K', 8=>'Fuehler 2 U/K', 9=>'Aussentemp. U/K', 10=>'Fluessigkeit. U/K', 11=>'11', 11=>'12', 13=>'13', 14=>'14', 15=>'15', 16=>'16', 17=>'17', 18=>'18', 19=>'19', 20=>'Abgas Motor zu hoch', 21=>'21', 22=>'Kuehlw. Motor > 95 C', 23=>'Abgastemp. zu hoch', 24=>'Kuehlw. Generator > 77 C', 25=>'25', 26=>'2h Vorlauft < Soll', 27=>'27', 28=>'28', 29=>'UP:Rueckleistung', 30=>'30', 31=>'HKA-Anl. < 100 U/min', 32=>'32', 33=>'HKA-Lauf < 2300 U/m', 34=>'34', 35=>'35', 36=>'36', 37=>'37', 38=>'38', 39=>'Generatorzuschalt', 40=>'Generatorabschalt', 41=>'Generator fehlt', 42=>'kein Text', 43=>'kein Text', 44=>'1h Si-Kette offen', 45=>'kein Text', 46=>'kein Text', 47=>'kein Text', 48=>'UP/LP:Int. b. Start', 49=>'UP: Intern', 50=>'UP/LP: Intern', 51=>'UP:Startfreigabe', 52=>'UP:Datentransfer', 53=>'UP:keine Daten', 54=>'kein Text', 55=>'kein Text', 56=>'UP:Messk Drehzahl', 56=>'kein Text', 57=>'kein Text', 58=>'kein Text', 59=>'UP:Spannung b.St.', 60=>'UP: Spannung', 61=>'kein Text', 62=>'Leistung zu hoch', 63=>'Leistung zu klein', 64=>'Leistung im Stand', 65=>'kein Text', 66=>'ENS-3 Abschaltung', 67=>'UP:Frequenz b.St', 68=>'UP:Frequenz', 69=>'UP:Phasen', 70=>'kein Text', 71=>'Oeldruckschalter', 72=>'Oeldruckmangel', 73=>'MV/Hubmag.undicht', 74=>'MV/Hubmag.undicht', 75=>'kein Text', 76=>'Programmdurchlauf', 77=>'kein Text', 78=>'kein Text', 79=>'4 Starts < 2300 U/m', 80=>'kein Text', 81=>'kein Text', 82=>'kein Text', 83=>'kein Text', 84=>'UP:Drehfeld', 85=>'Fluessigkeitssch', 86=>'UP: Zuendaussetzer', 87=>'Drehz. > 3300 U/min', 88=>'4 Starts 400-800U/m', 89=>'4Starts < 400 U/min', 90=>'kein Text', 91=>'UP:Drehz > 3500 U/m', 92=>'UP:verriegelt', 93=>'UP/RP-Prog.falsch', 94=>'kein Text', 95=>'No ClkRAM Kommuni', 96=>'No Ack-w I2C-Bus', 97=>'No Ack-r I2C-Bus', 98=>'Clk_RAM write nOK', 99=>'UP:Flags'); &x48_esex; &wertezuweisung; ### Ab hier kann eigener Code stehen if ( $debug == 1){ &debug; } ##### Subrotinen sub x48_esex { #Dachs 48 abfrge per Telnet über den ethersex $esex = Net::Telnet->new || die "kann Ethersex nicht finden"; $esex->open(Host => $esexip, Port => $esexport, Timeout => 1); # $x48hex1=$esex->cmd('msr1 get 1'); $esex->print("msr1 get 2"); ($non, $x48hex1) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $x48hex2) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $x48hex3) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $x48hex4) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); $x48hex = ($x48hex1).($x48hex2).($x48hex3).($x48hex4); #die vier Einzelwerte zu einem gesamt String zusammensetzen @x48hex = $x48hex =~ /(..)/g; #Den String in eine Array schreiben (nur die HEX-Werte ohne Leerstellen } sub wertezuweisung { $BETRIEBSSTUNDEN=hex($x48hex[1].$x48hex[2]); $STARTS=hex($x48hex[3].$x48hex[4]); $MAXABGAS=hex($x48hex[5])+15; $MAXGENERTEMP=hex($x48hex[7]); $MAXMOTORTEMP=hex($x48hex[6]); #MAXVL auf negative Temp prüfen if (hex($x48hex[8]) >128 ) { $VL=hex($x48hex[8])-255; }else{ $VL=hex($x48hex[8]); } #Max F1 und F2 auf negative Temp prüfen if (hex($x48hex[9]) >128 ) { $F1TEMP=hex($x48hex[9])-255; }else{ $F1TEMP=hex($x48hex[9]); } if (hex($x48hex[10]) >128 ) { $F2TEMP=hex($x48hex[10])-255; }else{ $F2TEMP=hex($x48hex[10]); } $MITTELGENLEISTUNG=(7.5 / 255 * hex($x48hex[11])); $STOERUNGEN=hex($x48hex[12]); $FLUESSIGKEITSCHALTER=hex($x48hex[55]); $LETZTEWARTUNG=hex($x48hex[59].$x48hex[60]); $NAECHSTEWARTUNGOEL=hex($x48hex[59].$x48hex[60])+2700; $NAECHSTEWARTUNGGAS=hex($x48hex[59].$x48hex[60])+3500; #Fehler Code zuweisen for ($non=1;$non<=7;$non++) { $FEHLERCODE[$non]=hex($x48hex[7+(6*$non)]); $FEHLERAUTO[$non]="0"; if ( $FEHLERCODE[$non] > 127 ) { $FEHLERCODE[$non]=$FEHLERCODE[$non]-128; $FEHLERAUTO[$non]="1"; } $FEHLERCODELANG[$non]=$Servicecode{$FEHLERCODE[$non]}; $FEHLERSTUNDEN[$non]=hex($x48hex[9+(6*$non)]); if ( $FEHLERSTUNDEN[$non]=~ /^[0-9]$/ ) { $FEHLERSTUNDEN[$non]='0'.$FEHLERSTUNDEN[$non]; } $FEHLERMIN[$non]=hex($x48hex[8+(6*$non)]); if ( $FEHLERMIN[$non]=~ /^[0-9]$/ ) { $FEHLERMIN[$non]='0'.$FEHLERMIN[$non]; } $FEHLERTAG[$non]=hex($x48hex[10+(6*$non)]); if ( $FEHLERTAG[$non]=~ /^[0-9]$/ ) { $FEHLERTAG[$non]='0'.$FEHLERTAG[$non]; } $FEHLERMON[$non]=hex($x48hex[11+(6*$non)]); if ( $FEHLERMON[$non]=~ /^[0-9]$/ ) { $FEHLERMON[$non]='0'.$FEHLERMON[$non]; } $FEHLERJAHR[$non]=hex($x48hex[12+(6*$non)]); if ( $FEHLERJAHR[$non]=~ /^[0-9]$/ ) { $FEHLERJAHR[$non]='0'.$FEHLERJAHR[$non]; } $FEHLERDATUM[$non]=$FEHLERSTUNDEN[$non].":".$FEHLERMIN[$non]." ".$FEHLERTAG[$non].".".$FEHLERMON[$non].".".$FEHLERJAHR[$non]; #Deutsch ohne Sekunden $FEHLERDATUM[$non]=$FEHLERJAHR[$non]."-".$FEHLERMON[$non]."-".$FEHLERTAG[$non]." ".$FEHLERSTUNDEN[$non].":".$FEHLERMIN[$non].":30"; #International mit gemittelte Sekunden #print "HEXzahl: ".(7 + (6 * $non))."\n"; } } sub debug { print "\n*********** DEBUG Start *************\n\n"; print "48-Hexwert:","@x48hex","\n\n"; print "Betriebstunden:\t\t",$BETRIEBSSTUNDEN,"\n"; print "Letzte Wartung:\t\t",$LETZTEWARTUNG,"\n"; print "Wartung bei Öl (alle 2700h):\t",$NAECHSTEWARTUNGOEL,"\n"; print "Wartung bei Gas (alle 3500h):\t",$NAECHSTEWARTUNGGAS,"\n"; print "Starts:\t\t\t",$STARTS,"\n"; print "MAX Abgas:\t\t",$MAXABGAS,"\n"; print "MAX Gen Temp:\t\t",$MAXGENERTEMP,"\n"; print "MAX Mot Temp:\t\t",$MAXMOTORTEMP,"\n"; print "Max VL:\t\t\t",$VL,"\n"; print "Max F1:\t\t\t",$F1TEMP,"\n"; print "Max F2:\t\t\t",$F2TEMP,"\n"; print "Mittlere Gen Leistung:\t",$MITTELGENLEISTUNG,"\n"; print "Anzahl Störungen:\t",$STOERUNGEN,"\n"; print "Fluessigkeitsschalter:\t",$FLUESSIGKEITSCHALTER,"\n\n"; print "Fehlerpeicher\n"; print "=============\n"; for ($non=1;$non<=7;$non++) { print "Fehler: ".$non."\n"; print "Fehlercode: ".$FEHLERCODE[$non]."\n"; print "Autoentstörung: ".$FEHLERAUTO[$non]."\n"; print "Zeit: ".$FEHLERSTUNDEN[$non].":".$FEHLERMIN[$non]." ".$FEHLERTAG[$non].".".$FEHLERMON[$non].".".$FEHLERJAHR[$non]."\n"; print "Datum: ".$FEHLERDATUM[$non]."\n"; print "Langtext: ".$FEHLERCODELANG[$non]."\n\n"; } print "\n"; print "*********** DEBUG Ende **************\n\n"; } </source> === 50 === '''Ein Beispiel für die 50 Werte''' <source lang="perl"> #!/usr/bin/perl -w # Abfrage der Dachs 50-Werte per esex # # kleines Beispielscript, das die 50 Wert abholt ud anschliesend aufbereitet # in Variabeln schreibt. # Das Script kann als Vorlage für eigene Entwicklungen benutzt werden. # # Autor: Lothar Schweikle-Droll # Lizenz: GPL use strict; use constant PI => 4 * atan2(1, 1); #Wegen cosph Berechnung use Net::Telnet (); my $debug=1; my $esex; my $esexip="192.168.255.90"; my $esexport="2701"; my $x50hex1; my $x50hex2; my $x50hex3; my $x50hex4; my $x50hex; my @x50hex; my $RL; my $VL; my $MOTORTEMP; my $ABGAS; my $AUSENTEMP; my $F1TEMP; my $F2TEMP; my $GENERTEMP; my $DREHZAHL; my $BIVAL_UMSCHALT_TMP; my $BIVAL_UMSCHALT_ZEIT; my $SERVICE; my $UMWALZPUMPESTATUS1; my $UMWALZPUMPESTATUS2; my $U1; my $U2; my $U3; my $I1; my $I2; my $I3; my $COSPHI; my $UE_PLATINE; my $non; &e8_esex; &wertezuweisung; ### Ab hier kann eigener Code stehen if ( $debug == 1){ &debug; } ##### Subrotinen sub e8_esex { #Dachs C0 abfrge per Telnet über den ethersex $esex = Net::Telnet->new || die "kann Ethersex nicht finden"; $esex->open(Host => $esexip, Port => $esexport, Timeout => 1); # $x50hex1=$esex->cmd('msr1 get 1'); $esex->print("msr1 get 3"); ($non, $x50hex1) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $x50hex2) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $x50hex3) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $x50hex4) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); $x50hex = ($x50hex1).($x50hex2).($x50hex3).($x50hex4); #die vier Einzelwerte zu einem gesamt String zusammensetzen @x50hex = $x50hex =~ /(..)/g; #Den String in eine Array schreiben (nur die HEX-Werte ohne Leerstellen } sub wertezuweisung { #VL auf negative Temp prüfen if (hex($x50hex[1]) >128 ) { $VL=hex($x50hex[1])-255; }else{ $VL=hex($x50hex[1]); } #RL auf negative Temp prüfen if (hex($x50hex[2]) >128 ) { $RL=hex($x50hex[2])-255; }else{ $RL=hex($x50hex[2]); } $MOTORTEMP=hex($x50hex[3]); $ABGAS=hex($x50hex[4])+15; #Ausentemp auf negative Temp prüfen if (hex($x50hex[5]) >128 ) { $AUSENTEMP=hex($x50hex[5])-255; }else{ $AUSENTEMP=hex($x50hex[5]); } #F1 und F2 auf negative Temp prüfen if (hex($x50hex[6]) >128 ) { $F1TEMP=hex($x50hex[6])-255; }else{ $F1TEMP=hex($x50hex[6]); } if (hex($x50hex[7]) >128 ) { $F2TEMP=hex($x50hex[7])-255; }else{ $F2TEMP=hex($x50hex[7]); } $GENERTEMP=hex($x50hex[8]); $ABGAS=hex($x50hex[4])+15; $DREHZAHL=hex($x50hex[10].$x50hex[11]); $BIVAL_UMSCHALT_TMP=hex($x50hex[13]); $BIVAL_UMSCHALT_ZEIT=hex($x50hex[14].$x50hex[15]); #Wert in Minuten $SERVICE=hex($x50hex[16]); $UMWALZPUMPESTATUS1=hex($x50hex[21]); $UMWALZPUMPESTATUS2=hex($x50hex[21]); $U1=105.6 + (100.0 / 461) * (hex($x50hex[31].$x50hex[32])); #105.6V + (100.0 /0x1cd) * Wert $U2=314.4 - (100.0 / 461) * (hex($x50hex[33].$x50hex[34])); #314.4V - (100.0 /0x1cd) * Wert $U3=105.6 + (100.0 / 461) * (hex($x50hex[35].$x50hex[36])); #105.6V + (100.0 /0x1cd) * Wert $I1=hex($x50hex[37].$x50hex[38]) * (10.0 / 461) - (10.0 * 205) / 461 ; #Wert * (10.0A /0x1cd) - (10.0*0xcd)/0x1cd $I2=hex($x50hex[39].$x50hex[40]) * (10.0 / 461) - (10.0 * 205) / 461; #Wert * (10.0A /0x1cd) - (10.0*0xcd)/0x1cd $I3=10.0 / 461 * (757 - (hex($x50hex[41].$x50hex[42]))); #10.0A/0x1cd * (0x02f5 - Wert) #$x50hex[43]='C9'; $COSPHI=abs( cos(((hex($x50hex[43]))-128)*PI/180) ); if (hex($x50hex[45]) >= 253 ) { $UE_PLATINE='ok'; }else{ $UE_PLATINE='error'; } } sub debug { print "\n*********** DEBUG Start *************\n\n"; print "50-Hexwert:","@x50hex","\n\n"; print "VL:\t\t\t",$VL,"\n"; print "RL:\t\t\t",$RL,"\n"; print "Motor Temp:\t\t",$MOTORTEMP,"\n"; print "Abgas:\t\t\t",$ABGAS,"\n"; print "F1:\t\t\t",$F1TEMP,"\n"; print "F2:\t\t\t",$F2TEMP,"\n"; print "Generator Temp:\t\t",$GENERTEMP,"\n"; print "Drehzahl:\t\t",$DREHZAHL,"\n"; print "BIVAL_UMSCHALT_TMP:\t",$BIVAL_UMSCHALT_TMP,"\n"; print "BIVAL_UMSCHALT_ZEIT:\t",$BIVAL_UMSCHALT_ZEIT,"\n"; print "U1:\t\t\t",$U1," ",hex($x50hex[31].$x50hex[32]),"\n"; print "U2:\t\t\t",$U2," ",hex($x50hex[33].$x50hex[34]),"\n"; print "U3:\t\t\t",$U3," ",hex($x50hex[35].$x50hex[36]),"\n"; print "I1:\t\t\t",$I1," ",hex($x50hex[37].$x50hex[38]),"\n"; print "I2:\t\t\t",$I2," ",hex($x50hex[39].$x50hex[40]),"\n"; print "I3:\t\t\t",$I3," ",hex($x50hex[41].$x50hex[42]),"\n"; print "COSPHI:\t\t\t",$COSPHI," ",hex($x50hex[43]),"\n"; print "UE_PLATINE:\t\t",$UE_PLATINE," ",hex($x50hex[45]),"\n"; print "UMWALZPUMPESTATUS1:\t",$UMWALZPUMPESTATUS1,"\n"; print "UMWALZPUMPESTATUS2:\t",$UMWALZPUMPESTATUS2,"\n"; print "\n"; print "*********** DEBUG Ende **************\n\n"; } </source> [[Kategorie:Ethersex]] [[Kategorie:Home-Visualisierung]] [[Category:MSR1]] b0c750fe3737b5761fcaa25ca7a09ca7c5fd748e 175 174 2011-11-08T10:23:28Z Loddel 64 /* Anschluss */ wikitext text/x-wiki Die Dachs MSR1 ist ein Klein-Blockheizkraftwerk (BHKW) der Firma [http://www.senertec.de SenerTec], die sowohl Wärme, als auch Strom erzeugt, und vor allem eine serielle Schnittstelle zur Verfügung stellt *Händereib*. Über diese kann man einiges an Betriebs- und Wartungsdaten auslesen. Eine genauere Beschreibung des Protokolls gibts [[Dachs_MSR1_Service_Protokoll|hier]]. │ │ Load a Default Configuration ---> │ │ ... │ │ IO Support ---> | | ... │ │ [*] Senertec Dachs MSR1 Support │ │ (0) MSR1 usart select == Anschluss == [[File:Dachs_msr1_anschluss.png|thumb]] Obwohl sowohl das Ethersex, als auch die MSR1 einen Slave (Weiblich) RS232 Anschluss hat braucht man ein 1:1 Kabel. Außerdem muss das RTS Signal des MSR1 auf eine logische Null gelegt werden, da sich die MSR1 sonst nicht für irgendwelche Befehle interessiert. Dazu verwendet man am besten den zweiten Kanal des verbauten MAX232, legt den Eingang auf GND und greift die +10V am Ausgang ab. Ansonsten ist der RS232 Anschluss ein 9600 8N1. == Alternative Kabelbelegung == Im [http://www.bhkw-forum.de BHKW-Forum] gibt es noch eine alternative Kabelbelegung. Zu beachten ist nur, das man die Leitungen nicht kreuzen darf. (getestet mit dem AVR-Net-IO) [[Media:Kabelbelegung_Dachs_MRS1.pdf]] Die dort beschriebene Belegung ist also für PC->Dachs gedacht. Diese Variante funktioniert mit einem ethersex nur dann, wenn an der RS232 Buchse auch der RTS Kanal durch den MAX232 geschleift wird. (Und die Ethersexfirmware um RTS Handshaking erweitert wurde *huestel*) == Auslesen == Der MSR1 kann man zwei verschiedene Datensätze entlocken, den "0xe8"-Datensatz und den "0xc0"-Datensatz. Beide enthalten teilweise redundante Daten, wobei jedoch letzterer weitaus mehr Informationen bietet. Den 0xe8 Datensatz bekommt man mit dem ecmd `msr1 get' bzw. `msr1 get 0'. Das erste Byte gibt an, wieviele Anfragen seit dem letzten erfolgreichen Versuch fehlgeschlagen sind. Den 0xc0-Datensatz bekommt man über `msr1 get 1'. == Einbindung in den [[HTTPD]] == [[Bild:Msr1_screenshot.png|600px]] │ │ Load a Default Configuration ---> │ │ ... │ │ General Setup ---> │ │ ... │ │ [*] VFS (Virtual File System) ---> │ │ [*] VFS File Inling │ │ [*] Inline MSR1 Unter '''$ethersexip/msr.ht''' kann nun der aktuelle Status des Dachs ausgelesen werden. = Programm Beispiele = == Abfrage in Perl == === e8 === '''Ein Beispiel wie die Werte e8 abgefragt und aufbereitet werden.''' <source lang="perl"> #!/usr/bin/perl -w # Abfrage der Dachs e8-Werte per esex # # kleines Beispielscript, das die e8 Wert abholt ud anschliesend aufbereitet # in Variabeln schreibt. # Das Script kann als Vorlage für eigene Entwicklungen benutzt werden. # # Autor: Lothar Schweikle-Droll # Lizenz: GPL use strict; use Net::Telnet (); my $debug=1; my $esex; my $esexip="192.168.255.90"; my $esexport="2701"; my $e8hex; my @e8hex; my $BETRIEBSSTUNDEN; my $WARTUNG; my $RL; my $VL; my $ABGAS; my $EINSCH_TEMP_SOL; my $BETRIEBSZUSTAND; my $BETRIEBSZUSTAND_SOL; my $GEN_LEISTUNG_SOL; my @SERVICE_CODE_MODUL; #Modul 0 = Leitregler my %BETRIEBSZUSTAND = ( 10=>'Störabschaltung', 11=>'Abschaltung MV1', 11=>'Abschaltung MV2', 13=>'Drehzahl<200 n. 25 sek.', 14=>'Drehzahl>200 n. 25 sek.', 15=>'Abschaltung>1 Minute', 16=>'Abschaltung>4 Minuten', 20=>'Startvorbereitung', 21=>'Starteinleitung', 22=>'Start', 23=>'1,5 sek. nach Start', 24=>'Startende', 30=>'450<Drehz<800', 32=>'Zuschaltung Generator', 33=>'Leistungsregelung runter', 34=>'Leistungsregelung hoch', 35=>'Betrieb'); my $non; &e8_esex; &wertezuweisung; ### Ab hier kann eigener Code stehen if ( $debug == 1){ &debug; } ##### Subrotinen sub e8_esex { #Dachs e8 abfrge per Telnet über den ethersex $esex = Net::Telnet->new || die "kann Ethersex nicht finden"; $esex->open(Host => $esexip, Port => $esexport, Timeout => 1); $esex->print("msr1 get 0"); ($non, $e8hex) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); #den String in ein Array wandeln @e8hex = $e8hex =~ /(..)/g; } sub wertezuweisung { $BETRIEBSSTUNDEN=hex($e8hex[1].$e8hex[2]); $WARTUNG=hex($e8hex[3]); #RL auf negative Temp prüfen if (hex($e8hex[4]) >128 ) { $RL=hex($e8hex[4])-255; }else{ $RL=hex($e8hex[4]); } #VL auf negative Temp prüfen if (hex($e8hex[5]) >128 ) { $VL=hex($e8hex[5])-255; }else{ $VL=hex($e8hex[5]); } $ABGAS=hex($e8hex[6])+15; $EINSCH_TEMP_SOL=hex($e8hex[7]); $BETRIEBSZUSTAND=$BETRIEBSZUSTAND{hex($e8hex[8])}; $GEN_LEISTUNG_SOL= sprintf("%.3f" , hex($e8hex[9])/34); #Sollwert Der Generatorleistung gerundet auf 3 Stellen nach dem Komma my $i=0; while ($i <=5 ) { $SERVICE_CODE_MODUL[$i]=hex($e8hex[$i+10]); $i++ } $BETRIEBSZUSTAND_SOL=hex($e8hex[16]); } sub debug { print "\n*********** DEBUG Start *************\n\n"; print "e8-Hexwert:","@e8hex","\n\n"; print "Betriebstundenb:\t",$BETRIEBSSTUNDEN,"\n"; print "Wartung:\t\t",$WARTUNG,"\n"; print "VL:\t\t\t",$VL,"\n"; print "RL:\t\t\t",$RL,"\n"; print "Abgas:\t\t\t",$ABGAS,"\n"; print "EINSCH_TEMP_SOL:\t",$EINSCH_TEMP_SOL,"\n"; print "Betriebszustand:\t",$BETRIEBSZUSTAND,"\n"; print "Generator Leitsung Sol:\t",$GEN_LEISTUNG_SOL,"\n"; print "BETRIEBSZUSTAND_SOL:\t",$BETRIEBSZUSTAND_SOL,"\n"; my $i=0; while ($i <=5 ) { #$SERVICE_CODE_MODUL[$i]=hex($e8sex[$i+10]); print "SERVICE_CODE_MODUL[".$i."]\t".$SERVICE_CODE_MODUL[$i],"\n"; $i++ } print "\n"; print "*********** DEBUG Ende **************\n\n"; } </source> === c0 === '''Ein Beispiel für die c0 Werte''' <source lang="perl"> #!/usr/bin/perl -w # Abfrage der Dachs c0-Werte per esex # # kleines Beispielscript, das die c0 Wert abholt ud anschliesend aufbereitet # in Variabeln schreibt. # Das Script kann als Vorlage für eigene Entwicklungen benutzt werden. # # Autor: Lothar Schweikle-Droll # Lizenz: GPL use strict; use Net::Telnet (); my $debug=1; my $esex; my $esexip="192.168.255.90"; my $esexport="2701"; my $c0hex1; my $c0hex2; my $c0hex3; my $c0hex4; my $c0hex; my @c0hex; my $WARTUNG; my $RL; my $VL; my $SRL; my $SVL; my $BETRIEBSSTUNDEN; my $ABGAS; my $AUSENTEMP; my $F1TEMP; my $F2TEMP; my $GENERTEMP; my $MOTORTEMP; my $SERVICECODE; my $BETRIEBSART; my $BHKW_FREIGABE; my $BRENNER_FREIGABE; my $DREHZAHL; my $ERZEUGTE_E_ENERGIE; my $ERZEUGT_WAERME; my $GEN_LEISTUNG; my $STARTS; my $non; &e8_esex; &wertezuweisung; ### Ab hier kann eigener Code stehen if ( $debug == 1){ &debug; } ##### Subrotinen sub e8_esex { #Dachs C0 abfrge per Telnet über den ethersex $esex = Net::Telnet->new || die "kann Ethersex nicht finden"; $esex->open(Host => $esexip, Port => $esexport, Timeout => 1); # $c0hex1=$esex->cmd('msr1 get 1'); $esex->print("msr1 get 1"); ($non, $c0hex1) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $c0hex2) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $c0hex3) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $c0hex4) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); $c0hex = ($c0hex1).($c0hex2).($c0hex3).($c0hex4); #die vier Einzelwerte zu einem gesamt String zusammensetzen @c0hex = $c0hex =~ /(..)/g; #Den String in eine Array schreiben (nur die HEX-Werte ohne Leerstellen } sub wertezuweisung { $BETRIEBSSTUNDEN=hex($c0hex[19].$c0hex[20]); $WARTUNG=$c0hex[3]; #RL auf negative Temp prüfen if (hex($c0hex[22]) >128 ) { $RL=hex($c0hex[22])-255; }else{ $RL=hex($c0hex[22]); } $SRL=hex($c0hex[21]); #VL auf negative Temp prüfen if (hex($c0hex[24]) >128 ) { $VL=hex($c0hex[24])-255; }else{ $VL=hex($c0hex[24]); } $SVL=hex($c0hex[23]); #Ausentemp auf negative Temp prüfen if (hex($c0hex[25]) >128 ) { $AUSENTEMP=hex($c0hex[25])-255; }else{ $AUSENTEMP=hex($c0hex[25]); } #F1 und F2 auf negative Temp prüfen if (hex($c0hex[26]) >128 ) { $F1TEMP=hex($c0hex[26])-255; }else{ $F1TEMP=hex($c0hex[26]); } if (hex($c0hex[27]) >128 ) { $F2TEMP=hex($c0hex[27])-255; }else{ $F2TEMP=hex($c0hex[27]); } $GENERTEMP=hex($c0hex[28]); $SERVICECODE=hex($c0hex[30]); $BETRIEBSART=$c0hex[31]; $BHKW_FREIGABE=hex($c0hex[32]); $BRENNER_FREIGABE=hex($c0hex[33]); $MOTORTEMP=hex($c0hex[34]); $ABGAS=hex($c0hex[35])+15; $DREHZAHL=hex($c0hex[36].$c0hex[37]); $ERZEUGTE_E_ENERGIE=hex($c0hex[38].$c0hex[39].$c0hex[40].$c0hex[41]); $ERZEUGT_WAERME=hex($c0hex[42].$c0hex[43].$c0hex[44].$c0hex[45]); $GEN_LEISTUNG=sprintf("%.3f" , hex($c0hex[46])/34); #Sollwert Der Generatorleistung gerundet auf 3 Stellen nach dem Komma $STARTS=hex($c0hex[47].$c0hex[48]); } sub debug { print "\n*********** DEBUG Start *************\n\n"; print "c0-Hexwert:","@c0hex","\n\n"; print "Betriebstunden:\t\t",$BETRIEBSSTUNDEN,"\n"; print "Wartung:\t\t",$WARTUNG,"\n"; print "VL:\t\t\t",$VL,"\n"; print "RL:\t\t\t",$RL,"\n"; print "F1:\t\t\t",$F1TEMP,"\n"; print "F2:\t\t\t",$F2TEMP,"\n"; print "VL Soll:\t\t",$SVL,"\n"; print "RL Soll:\t\t",$SRL,"\n"; print "Ausen:\t\t\t",$AUSENTEMP,"\n"; print "Generator Temp:\t\t",$GENERTEMP,"\n"; print "Servicecode:\t\t",$SERVICECODE,"\n"; print "Betreibsart:\t\t",$BETRIEBSART,"\n"; print "BHKW Freigabe:\t\t",$BHKW_FREIGABE,"\n"; print "Brenner Freigabe:\t",$BRENNER_FREIGABE,"\n"; print "Motor Temp:\t\t",$MOTORTEMP,"\n"; print "Abgas:\t\t\t",$ABGAS,"\n"; print "Drehzahl:\t\t",$DREHZAHL,"\n"; print "erzeugte E-Energie:\t",$ERZEUGTE_E_ENERGIE,"\n"; print "erzeugte Wärme:\t\t",$ERZEUGT_WAERME,"\n"; print "Generator ist:\t\t",$GEN_LEISTUNG,"\n"; print "Startvorgang:\t\t",$STARTS,"\n"; print "\n"; print "*********** DEBUG Ende **************\n\n"; } </source> === 48 === '''Ein Beispiel für die 48 Werte''' <source lang="perl"> #!/usr/bin/perl -w # Abfrage der Dachs 48-Werte per esex # # kleines Beispielscript, das die 48 Wert abholt ud anschliesend aufbereitet # in Variabeln schreibt. # Das Script kann als Vorlage für eigene Entwicklungen benutzt werden. # # Autor: Lothar Schweikle-Droll # Lizenz: GPL use strict; use Net::Telnet (); my $debug=1; my $esex; my $esexip="192.168.255.90"; my $esexport="2701"; my $x48hex1; my $x48hex2; my $x48hex3; my $x48hex4; my $x48hex; my @x48hex; my $WARTUNG; my $BETRIEBSSTUNDEN; my $MAXABGAS; my $VL; my $STOERUNGEN; my $F1TEMP; my $F2TEMP; my $MAXGENERTEMP; my $MAXMOTORTEMP; my $STARTS; my $MITTELGENLEISTUNG; my $FLUESSIGKEITSCHALTER; my $LETZTEWARTUNG; my $NAECHSTEWARTUNGOEL; my $NAECHSTEWARTUNGGAS; my @FEHLERCODE; #000-127 my @FEHLERAUTO; #1=Autoentstörung my @FEHLERCODELANG; my @FEHLERMIN; my @FEHLERSTUNDEN; my @FEHLERTAG; my @FEHLERMON; my @FEHLERJAHR; my @FEHLERDATUM; my $non; my %Servicecode = ( 0=>'Allgemeine Hilfe', 1=>'Abgasfühler U/K', 2=>'Kuehlw.Motor U/K', 3=>'Kuehlw.Gener. U/K', 4=>'04', 5=>'Vorlauftemp. U/K', 6=>'Ruecklauftemp U/K', 7=>'Fuehler 1 U/K', 8=>'Fuehler 2 U/K', 9=>'Aussentemp. U/K', 10=>'Fluessigkeit. U/K', 11=>'11', 11=>'12', 13=>'13', 14=>'14', 15=>'15', 16=>'16', 17=>'17', 18=>'18', 19=>'19', 20=>'Abgas Motor zu hoch', 21=>'21', 22=>'Kuehlw. Motor > 95 C', 23=>'Abgastemp. zu hoch', 24=>'Kuehlw. Generator > 77 C', 25=>'25', 26=>'2h Vorlauft < Soll', 27=>'27', 28=>'28', 29=>'UP:Rueckleistung', 30=>'30', 31=>'HKA-Anl. < 100 U/min', 32=>'32', 33=>'HKA-Lauf < 2300 U/m', 34=>'34', 35=>'35', 36=>'36', 37=>'37', 38=>'38', 39=>'Generatorzuschalt', 40=>'Generatorabschalt', 41=>'Generator fehlt', 42=>'kein Text', 43=>'kein Text', 44=>'1h Si-Kette offen', 45=>'kein Text', 46=>'kein Text', 47=>'kein Text', 48=>'UP/LP:Int. b. Start', 49=>'UP: Intern', 50=>'UP/LP: Intern', 51=>'UP:Startfreigabe', 52=>'UP:Datentransfer', 53=>'UP:keine Daten', 54=>'kein Text', 55=>'kein Text', 56=>'UP:Messk Drehzahl', 56=>'kein Text', 57=>'kein Text', 58=>'kein Text', 59=>'UP:Spannung b.St.', 60=>'UP: Spannung', 61=>'kein Text', 62=>'Leistung zu hoch', 63=>'Leistung zu klein', 64=>'Leistung im Stand', 65=>'kein Text', 66=>'ENS-3 Abschaltung', 67=>'UP:Frequenz b.St', 68=>'UP:Frequenz', 69=>'UP:Phasen', 70=>'kein Text', 71=>'Oeldruckschalter', 72=>'Oeldruckmangel', 73=>'MV/Hubmag.undicht', 74=>'MV/Hubmag.undicht', 75=>'kein Text', 76=>'Programmdurchlauf', 77=>'kein Text', 78=>'kein Text', 79=>'4 Starts < 2300 U/m', 80=>'kein Text', 81=>'kein Text', 82=>'kein Text', 83=>'kein Text', 84=>'UP:Drehfeld', 85=>'Fluessigkeitssch', 86=>'UP: Zuendaussetzer', 87=>'Drehz. > 3300 U/min', 88=>'4 Starts 400-800U/m', 89=>'4Starts < 400 U/min', 90=>'kein Text', 91=>'UP:Drehz > 3500 U/m', 92=>'UP:verriegelt', 93=>'UP/RP-Prog.falsch', 94=>'kein Text', 95=>'No ClkRAM Kommuni', 96=>'No Ack-w I2C-Bus', 97=>'No Ack-r I2C-Bus', 98=>'Clk_RAM write nOK', 99=>'UP:Flags'); &x48_esex; &wertezuweisung; ### Ab hier kann eigener Code stehen if ( $debug == 1){ &debug; } ##### Subrotinen sub x48_esex { #Dachs 48 abfrge per Telnet über den ethersex $esex = Net::Telnet->new || die "kann Ethersex nicht finden"; $esex->open(Host => $esexip, Port => $esexport, Timeout => 1); # $x48hex1=$esex->cmd('msr1 get 1'); $esex->print("msr1 get 2"); ($non, $x48hex1) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $x48hex2) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $x48hex3) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $x48hex4) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); $x48hex = ($x48hex1).($x48hex2).($x48hex3).($x48hex4); #die vier Einzelwerte zu einem gesamt String zusammensetzen @x48hex = $x48hex =~ /(..)/g; #Den String in eine Array schreiben (nur die HEX-Werte ohne Leerstellen } sub wertezuweisung { $BETRIEBSSTUNDEN=hex($x48hex[1].$x48hex[2]); $STARTS=hex($x48hex[3].$x48hex[4]); $MAXABGAS=hex($x48hex[5])+15; $MAXGENERTEMP=hex($x48hex[7]); $MAXMOTORTEMP=hex($x48hex[6]); #MAXVL auf negative Temp prüfen if (hex($x48hex[8]) >128 ) { $VL=hex($x48hex[8])-255; }else{ $VL=hex($x48hex[8]); } #Max F1 und F2 auf negative Temp prüfen if (hex($x48hex[9]) >128 ) { $F1TEMP=hex($x48hex[9])-255; }else{ $F1TEMP=hex($x48hex[9]); } if (hex($x48hex[10]) >128 ) { $F2TEMP=hex($x48hex[10])-255; }else{ $F2TEMP=hex($x48hex[10]); } $MITTELGENLEISTUNG=(7.5 / 255 * hex($x48hex[11])); $STOERUNGEN=hex($x48hex[12]); $FLUESSIGKEITSCHALTER=hex($x48hex[55]); $LETZTEWARTUNG=hex($x48hex[59].$x48hex[60]); $NAECHSTEWARTUNGOEL=hex($x48hex[59].$x48hex[60])+2700; $NAECHSTEWARTUNGGAS=hex($x48hex[59].$x48hex[60])+3500; #Fehler Code zuweisen for ($non=1;$non<=7;$non++) { $FEHLERCODE[$non]=hex($x48hex[7+(6*$non)]); $FEHLERAUTO[$non]="0"; if ( $FEHLERCODE[$non] > 127 ) { $FEHLERCODE[$non]=$FEHLERCODE[$non]-128; $FEHLERAUTO[$non]="1"; } $FEHLERCODELANG[$non]=$Servicecode{$FEHLERCODE[$non]}; $FEHLERSTUNDEN[$non]=hex($x48hex[9+(6*$non)]); if ( $FEHLERSTUNDEN[$non]=~ /^[0-9]$/ ) { $FEHLERSTUNDEN[$non]='0'.$FEHLERSTUNDEN[$non]; } $FEHLERMIN[$non]=hex($x48hex[8+(6*$non)]); if ( $FEHLERMIN[$non]=~ /^[0-9]$/ ) { $FEHLERMIN[$non]='0'.$FEHLERMIN[$non]; } $FEHLERTAG[$non]=hex($x48hex[10+(6*$non)]); if ( $FEHLERTAG[$non]=~ /^[0-9]$/ ) { $FEHLERTAG[$non]='0'.$FEHLERTAG[$non]; } $FEHLERMON[$non]=hex($x48hex[11+(6*$non)]); if ( $FEHLERMON[$non]=~ /^[0-9]$/ ) { $FEHLERMON[$non]='0'.$FEHLERMON[$non]; } $FEHLERJAHR[$non]=hex($x48hex[12+(6*$non)]); if ( $FEHLERJAHR[$non]=~ /^[0-9]$/ ) { $FEHLERJAHR[$non]='0'.$FEHLERJAHR[$non]; } $FEHLERDATUM[$non]=$FEHLERSTUNDEN[$non].":".$FEHLERMIN[$non]." ".$FEHLERTAG[$non].".".$FEHLERMON[$non].".".$FEHLERJAHR[$non]; #Deutsch ohne Sekunden $FEHLERDATUM[$non]=$FEHLERJAHR[$non]."-".$FEHLERMON[$non]."-".$FEHLERTAG[$non]." ".$FEHLERSTUNDEN[$non].":".$FEHLERMIN[$non].":30"; #International mit gemittelte Sekunden #print "HEXzahl: ".(7 + (6 * $non))."\n"; } } sub debug { print "\n*********** DEBUG Start *************\n\n"; print "48-Hexwert:","@x48hex","\n\n"; print "Betriebstunden:\t\t",$BETRIEBSSTUNDEN,"\n"; print "Letzte Wartung:\t\t",$LETZTEWARTUNG,"\n"; print "Wartung bei Öl (alle 2700h):\t",$NAECHSTEWARTUNGOEL,"\n"; print "Wartung bei Gas (alle 3500h):\t",$NAECHSTEWARTUNGGAS,"\n"; print "Starts:\t\t\t",$STARTS,"\n"; print "MAX Abgas:\t\t",$MAXABGAS,"\n"; print "MAX Gen Temp:\t\t",$MAXGENERTEMP,"\n"; print "MAX Mot Temp:\t\t",$MAXMOTORTEMP,"\n"; print "Max VL:\t\t\t",$VL,"\n"; print "Max F1:\t\t\t",$F1TEMP,"\n"; print "Max F2:\t\t\t",$F2TEMP,"\n"; print "Mittlere Gen Leistung:\t",$MITTELGENLEISTUNG,"\n"; print "Anzahl Störungen:\t",$STOERUNGEN,"\n"; print "Fluessigkeitsschalter:\t",$FLUESSIGKEITSCHALTER,"\n\n"; print "Fehlerpeicher\n"; print "=============\n"; for ($non=1;$non<=7;$non++) { print "Fehler: ".$non."\n"; print "Fehlercode: ".$FEHLERCODE[$non]."\n"; print "Autoentstörung: ".$FEHLERAUTO[$non]."\n"; print "Zeit: ".$FEHLERSTUNDEN[$non].":".$FEHLERMIN[$non]." ".$FEHLERTAG[$non].".".$FEHLERMON[$non].".".$FEHLERJAHR[$non]."\n"; print "Datum: ".$FEHLERDATUM[$non]."\n"; print "Langtext: ".$FEHLERCODELANG[$non]."\n\n"; } print "\n"; print "*********** DEBUG Ende **************\n\n"; } </source> === 50 === '''Ein Beispiel für die 50 Werte''' <source lang="perl"> #!/usr/bin/perl -w # Abfrage der Dachs 50-Werte per esex # # kleines Beispielscript, das die 50 Wert abholt ud anschliesend aufbereitet # in Variabeln schreibt. # Das Script kann als Vorlage für eigene Entwicklungen benutzt werden. # # Autor: Lothar Schweikle-Droll # Lizenz: GPL use strict; use constant PI => 4 * atan2(1, 1); #Wegen cosph Berechnung use Net::Telnet (); my $debug=1; my $esex; my $esexip="192.168.255.90"; my $esexport="2701"; my $x50hex1; my $x50hex2; my $x50hex3; my $x50hex4; my $x50hex; my @x50hex; my $RL; my $VL; my $MOTORTEMP; my $ABGAS; my $AUSENTEMP; my $F1TEMP; my $F2TEMP; my $GENERTEMP; my $DREHZAHL; my $BIVAL_UMSCHALT_TMP; my $BIVAL_UMSCHALT_ZEIT; my $SERVICE; my $UMWALZPUMPESTATUS1; my $UMWALZPUMPESTATUS2; my $U1; my $U2; my $U3; my $I1; my $I2; my $I3; my $COSPHI; my $UE_PLATINE; my $non; &e8_esex; &wertezuweisung; ### Ab hier kann eigener Code stehen if ( $debug == 1){ &debug; } ##### Subrotinen sub e8_esex { #Dachs C0 abfrge per Telnet über den ethersex $esex = Net::Telnet->new || die "kann Ethersex nicht finden"; $esex->open(Host => $esexip, Port => $esexport, Timeout => 1); # $x50hex1=$esex->cmd('msr1 get 1'); $esex->print("msr1 get 3"); ($non, $x50hex1) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $x50hex2) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $x50hex3) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $x50hex4) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); $x50hex = ($x50hex1).($x50hex2).($x50hex3).($x50hex4); #die vier Einzelwerte zu einem gesamt String zusammensetzen @x50hex = $x50hex =~ /(..)/g; #Den String in eine Array schreiben (nur die HEX-Werte ohne Leerstellen } sub wertezuweisung { #VL auf negative Temp prüfen if (hex($x50hex[1]) >128 ) { $VL=hex($x50hex[1])-255; }else{ $VL=hex($x50hex[1]); } #RL auf negative Temp prüfen if (hex($x50hex[2]) >128 ) { $RL=hex($x50hex[2])-255; }else{ $RL=hex($x50hex[2]); } $MOTORTEMP=hex($x50hex[3]); $ABGAS=hex($x50hex[4])+15; #Ausentemp auf negative Temp prüfen if (hex($x50hex[5]) >128 ) { $AUSENTEMP=hex($x50hex[5])-255; }else{ $AUSENTEMP=hex($x50hex[5]); } #F1 und F2 auf negative Temp prüfen if (hex($x50hex[6]) >128 ) { $F1TEMP=hex($x50hex[6])-255; }else{ $F1TEMP=hex($x50hex[6]); } if (hex($x50hex[7]) >128 ) { $F2TEMP=hex($x50hex[7])-255; }else{ $F2TEMP=hex($x50hex[7]); } $GENERTEMP=hex($x50hex[8]); $ABGAS=hex($x50hex[4])+15; $DREHZAHL=hex($x50hex[10].$x50hex[11]); $BIVAL_UMSCHALT_TMP=hex($x50hex[13]); $BIVAL_UMSCHALT_ZEIT=hex($x50hex[14].$x50hex[15]); #Wert in Minuten $SERVICE=hex($x50hex[16]); $UMWALZPUMPESTATUS1=hex($x50hex[21]); $UMWALZPUMPESTATUS2=hex($x50hex[21]); $U1=105.6 + (100.0 / 461) * (hex($x50hex[31].$x50hex[32])); #105.6V + (100.0 /0x1cd) * Wert $U2=314.4 - (100.0 / 461) * (hex($x50hex[33].$x50hex[34])); #314.4V - (100.0 /0x1cd) * Wert $U3=105.6 + (100.0 / 461) * (hex($x50hex[35].$x50hex[36])); #105.6V + (100.0 /0x1cd) * Wert $I1=hex($x50hex[37].$x50hex[38]) * (10.0 / 461) - (10.0 * 205) / 461 ; #Wert * (10.0A /0x1cd) - (10.0*0xcd)/0x1cd $I2=hex($x50hex[39].$x50hex[40]) * (10.0 / 461) - (10.0 * 205) / 461; #Wert * (10.0A /0x1cd) - (10.0*0xcd)/0x1cd $I3=10.0 / 461 * (757 - (hex($x50hex[41].$x50hex[42]))); #10.0A/0x1cd * (0x02f5 - Wert) #$x50hex[43]='C9'; $COSPHI=abs( cos(((hex($x50hex[43]))-128)*PI/180) ); if (hex($x50hex[45]) >= 253 ) { $UE_PLATINE='ok'; }else{ $UE_PLATINE='error'; } } sub debug { print "\n*********** DEBUG Start *************\n\n"; print "50-Hexwert:","@x50hex","\n\n"; print "VL:\t\t\t",$VL,"\n"; print "RL:\t\t\t",$RL,"\n"; print "Motor Temp:\t\t",$MOTORTEMP,"\n"; print "Abgas:\t\t\t",$ABGAS,"\n"; print "F1:\t\t\t",$F1TEMP,"\n"; print "F2:\t\t\t",$F2TEMP,"\n"; print "Generator Temp:\t\t",$GENERTEMP,"\n"; print "Drehzahl:\t\t",$DREHZAHL,"\n"; print "BIVAL_UMSCHALT_TMP:\t",$BIVAL_UMSCHALT_TMP,"\n"; print "BIVAL_UMSCHALT_ZEIT:\t",$BIVAL_UMSCHALT_ZEIT,"\n"; print "U1:\t\t\t",$U1," ",hex($x50hex[31].$x50hex[32]),"\n"; print "U2:\t\t\t",$U2," ",hex($x50hex[33].$x50hex[34]),"\n"; print "U3:\t\t\t",$U3," ",hex($x50hex[35].$x50hex[36]),"\n"; print "I1:\t\t\t",$I1," ",hex($x50hex[37].$x50hex[38]),"\n"; print "I2:\t\t\t",$I2," ",hex($x50hex[39].$x50hex[40]),"\n"; print "I3:\t\t\t",$I3," ",hex($x50hex[41].$x50hex[42]),"\n"; print "COSPHI:\t\t\t",$COSPHI," ",hex($x50hex[43]),"\n"; print "UE_PLATINE:\t\t",$UE_PLATINE," ",hex($x50hex[45]),"\n"; print "UMWALZPUMPESTATUS1:\t",$UMWALZPUMPESTATUS1,"\n"; print "UMWALZPUMPESTATUS2:\t",$UMWALZPUMPESTATUS2,"\n"; print "\n"; print "*********** DEBUG Ende **************\n\n"; } </source> [[Kategorie:Ethersex]] [[Kategorie:Home-Visualisierung]] [[Category:MSR1]] 2c300bdbe0a06c2e5a10fa2d0cf60ad8454cfcfc 178 175 2011-11-08T10:26:28Z Loddel 64 /* Einbindung in den HTTPD */ wikitext text/x-wiki Die Dachs MSR1 ist ein Klein-Blockheizkraftwerk (BHKW) der Firma [http://www.senertec.de SenerTec], die sowohl Wärme, als auch Strom erzeugt, und vor allem eine serielle Schnittstelle zur Verfügung stellt *Händereib*. Über diese kann man einiges an Betriebs- und Wartungsdaten auslesen. Eine genauere Beschreibung des Protokolls gibts [[Dachs_MSR1_Service_Protokoll|hier]]. │ │ Load a Default Configuration ---> │ │ ... │ │ IO Support ---> | | ... │ │ [*] Senertec Dachs MSR1 Support │ │ (0) MSR1 usart select == Anschluss == [[File:Dachs_msr1_anschluss.png|thumb]] Obwohl sowohl das Ethersex, als auch die MSR1 einen Slave (Weiblich) RS232 Anschluss hat braucht man ein 1:1 Kabel. Außerdem muss das RTS Signal des MSR1 auf eine logische Null gelegt werden, da sich die MSR1 sonst nicht für irgendwelche Befehle interessiert. Dazu verwendet man am besten den zweiten Kanal des verbauten MAX232, legt den Eingang auf GND und greift die +10V am Ausgang ab. Ansonsten ist der RS232 Anschluss ein 9600 8N1. == Alternative Kabelbelegung == Im [http://www.bhkw-forum.de BHKW-Forum] gibt es noch eine alternative Kabelbelegung. Zu beachten ist nur, das man die Leitungen nicht kreuzen darf. (getestet mit dem AVR-Net-IO) [[Media:Kabelbelegung_Dachs_MRS1.pdf]] Die dort beschriebene Belegung ist also für PC->Dachs gedacht. Diese Variante funktioniert mit einem ethersex nur dann, wenn an der RS232 Buchse auch der RTS Kanal durch den MAX232 geschleift wird. (Und die Ethersexfirmware um RTS Handshaking erweitert wurde *huestel*) == Auslesen == Der MSR1 kann man zwei verschiedene Datensätze entlocken, den "0xe8"-Datensatz und den "0xc0"-Datensatz. Beide enthalten teilweise redundante Daten, wobei jedoch letzterer weitaus mehr Informationen bietet. Den 0xe8 Datensatz bekommt man mit dem ecmd `msr1 get' bzw. `msr1 get 0'. Das erste Byte gibt an, wieviele Anfragen seit dem letzten erfolgreichen Versuch fehlgeschlagen sind. Den 0xc0-Datensatz bekommt man über `msr1 get 1'. == Einbindung in den [[HTTPD]] == [[File:800px-Msr1_screenshot.png|600px]] │ │ Load a Default Configuration ---> │ │ ... │ │ General Setup ---> │ │ ... │ │ [*] VFS (Virtual File System) ---> │ │ [*] VFS File Inling │ │ [*] Inline MSR1 Unter '''$ethersexip/msr.ht''' kann nun der aktuelle Status des Dachs ausgelesen werden. = Programm Beispiele = == Abfrage in Perl == === e8 === '''Ein Beispiel wie die Werte e8 abgefragt und aufbereitet werden.''' <source lang="perl"> #!/usr/bin/perl -w # Abfrage der Dachs e8-Werte per esex # # kleines Beispielscript, das die e8 Wert abholt ud anschliesend aufbereitet # in Variabeln schreibt. # Das Script kann als Vorlage für eigene Entwicklungen benutzt werden. # # Autor: Lothar Schweikle-Droll # Lizenz: GPL use strict; use Net::Telnet (); my $debug=1; my $esex; my $esexip="192.168.255.90"; my $esexport="2701"; my $e8hex; my @e8hex; my $BETRIEBSSTUNDEN; my $WARTUNG; my $RL; my $VL; my $ABGAS; my $EINSCH_TEMP_SOL; my $BETRIEBSZUSTAND; my $BETRIEBSZUSTAND_SOL; my $GEN_LEISTUNG_SOL; my @SERVICE_CODE_MODUL; #Modul 0 = Leitregler my %BETRIEBSZUSTAND = ( 10=>'Störabschaltung', 11=>'Abschaltung MV1', 11=>'Abschaltung MV2', 13=>'Drehzahl<200 n. 25 sek.', 14=>'Drehzahl>200 n. 25 sek.', 15=>'Abschaltung>1 Minute', 16=>'Abschaltung>4 Minuten', 20=>'Startvorbereitung', 21=>'Starteinleitung', 22=>'Start', 23=>'1,5 sek. nach Start', 24=>'Startende', 30=>'450<Drehz<800', 32=>'Zuschaltung Generator', 33=>'Leistungsregelung runter', 34=>'Leistungsregelung hoch', 35=>'Betrieb'); my $non; &e8_esex; &wertezuweisung; ### Ab hier kann eigener Code stehen if ( $debug == 1){ &debug; } ##### Subrotinen sub e8_esex { #Dachs e8 abfrge per Telnet über den ethersex $esex = Net::Telnet->new || die "kann Ethersex nicht finden"; $esex->open(Host => $esexip, Port => $esexport, Timeout => 1); $esex->print("msr1 get 0"); ($non, $e8hex) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); #den String in ein Array wandeln @e8hex = $e8hex =~ /(..)/g; } sub wertezuweisung { $BETRIEBSSTUNDEN=hex($e8hex[1].$e8hex[2]); $WARTUNG=hex($e8hex[3]); #RL auf negative Temp prüfen if (hex($e8hex[4]) >128 ) { $RL=hex($e8hex[4])-255; }else{ $RL=hex($e8hex[4]); } #VL auf negative Temp prüfen if (hex($e8hex[5]) >128 ) { $VL=hex($e8hex[5])-255; }else{ $VL=hex($e8hex[5]); } $ABGAS=hex($e8hex[6])+15; $EINSCH_TEMP_SOL=hex($e8hex[7]); $BETRIEBSZUSTAND=$BETRIEBSZUSTAND{hex($e8hex[8])}; $GEN_LEISTUNG_SOL= sprintf("%.3f" , hex($e8hex[9])/34); #Sollwert Der Generatorleistung gerundet auf 3 Stellen nach dem Komma my $i=0; while ($i <=5 ) { $SERVICE_CODE_MODUL[$i]=hex($e8hex[$i+10]); $i++ } $BETRIEBSZUSTAND_SOL=hex($e8hex[16]); } sub debug { print "\n*********** DEBUG Start *************\n\n"; print "e8-Hexwert:","@e8hex","\n\n"; print "Betriebstundenb:\t",$BETRIEBSSTUNDEN,"\n"; print "Wartung:\t\t",$WARTUNG,"\n"; print "VL:\t\t\t",$VL,"\n"; print "RL:\t\t\t",$RL,"\n"; print "Abgas:\t\t\t",$ABGAS,"\n"; print "EINSCH_TEMP_SOL:\t",$EINSCH_TEMP_SOL,"\n"; print "Betriebszustand:\t",$BETRIEBSZUSTAND,"\n"; print "Generator Leitsung Sol:\t",$GEN_LEISTUNG_SOL,"\n"; print "BETRIEBSZUSTAND_SOL:\t",$BETRIEBSZUSTAND_SOL,"\n"; my $i=0; while ($i <=5 ) { #$SERVICE_CODE_MODUL[$i]=hex($e8sex[$i+10]); print "SERVICE_CODE_MODUL[".$i."]\t".$SERVICE_CODE_MODUL[$i],"\n"; $i++ } print "\n"; print "*********** DEBUG Ende **************\n\n"; } </source> === c0 === '''Ein Beispiel für die c0 Werte''' <source lang="perl"> #!/usr/bin/perl -w # Abfrage der Dachs c0-Werte per esex # # kleines Beispielscript, das die c0 Wert abholt ud anschliesend aufbereitet # in Variabeln schreibt. # Das Script kann als Vorlage für eigene Entwicklungen benutzt werden. # # Autor: Lothar Schweikle-Droll # Lizenz: GPL use strict; use Net::Telnet (); my $debug=1; my $esex; my $esexip="192.168.255.90"; my $esexport="2701"; my $c0hex1; my $c0hex2; my $c0hex3; my $c0hex4; my $c0hex; my @c0hex; my $WARTUNG; my $RL; my $VL; my $SRL; my $SVL; my $BETRIEBSSTUNDEN; my $ABGAS; my $AUSENTEMP; my $F1TEMP; my $F2TEMP; my $GENERTEMP; my $MOTORTEMP; my $SERVICECODE; my $BETRIEBSART; my $BHKW_FREIGABE; my $BRENNER_FREIGABE; my $DREHZAHL; my $ERZEUGTE_E_ENERGIE; my $ERZEUGT_WAERME; my $GEN_LEISTUNG; my $STARTS; my $non; &e8_esex; &wertezuweisung; ### Ab hier kann eigener Code stehen if ( $debug == 1){ &debug; } ##### Subrotinen sub e8_esex { #Dachs C0 abfrge per Telnet über den ethersex $esex = Net::Telnet->new || die "kann Ethersex nicht finden"; $esex->open(Host => $esexip, Port => $esexport, Timeout => 1); # $c0hex1=$esex->cmd('msr1 get 1'); $esex->print("msr1 get 1"); ($non, $c0hex1) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $c0hex2) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $c0hex3) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $c0hex4) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); $c0hex = ($c0hex1).($c0hex2).($c0hex3).($c0hex4); #die vier Einzelwerte zu einem gesamt String zusammensetzen @c0hex = $c0hex =~ /(..)/g; #Den String in eine Array schreiben (nur die HEX-Werte ohne Leerstellen } sub wertezuweisung { $BETRIEBSSTUNDEN=hex($c0hex[19].$c0hex[20]); $WARTUNG=$c0hex[3]; #RL auf negative Temp prüfen if (hex($c0hex[22]) >128 ) { $RL=hex($c0hex[22])-255; }else{ $RL=hex($c0hex[22]); } $SRL=hex($c0hex[21]); #VL auf negative Temp prüfen if (hex($c0hex[24]) >128 ) { $VL=hex($c0hex[24])-255; }else{ $VL=hex($c0hex[24]); } $SVL=hex($c0hex[23]); #Ausentemp auf negative Temp prüfen if (hex($c0hex[25]) >128 ) { $AUSENTEMP=hex($c0hex[25])-255; }else{ $AUSENTEMP=hex($c0hex[25]); } #F1 und F2 auf negative Temp prüfen if (hex($c0hex[26]) >128 ) { $F1TEMP=hex($c0hex[26])-255; }else{ $F1TEMP=hex($c0hex[26]); } if (hex($c0hex[27]) >128 ) { $F2TEMP=hex($c0hex[27])-255; }else{ $F2TEMP=hex($c0hex[27]); } $GENERTEMP=hex($c0hex[28]); $SERVICECODE=hex($c0hex[30]); $BETRIEBSART=$c0hex[31]; $BHKW_FREIGABE=hex($c0hex[32]); $BRENNER_FREIGABE=hex($c0hex[33]); $MOTORTEMP=hex($c0hex[34]); $ABGAS=hex($c0hex[35])+15; $DREHZAHL=hex($c0hex[36].$c0hex[37]); $ERZEUGTE_E_ENERGIE=hex($c0hex[38].$c0hex[39].$c0hex[40].$c0hex[41]); $ERZEUGT_WAERME=hex($c0hex[42].$c0hex[43].$c0hex[44].$c0hex[45]); $GEN_LEISTUNG=sprintf("%.3f" , hex($c0hex[46])/34); #Sollwert Der Generatorleistung gerundet auf 3 Stellen nach dem Komma $STARTS=hex($c0hex[47].$c0hex[48]); } sub debug { print "\n*********** DEBUG Start *************\n\n"; print "c0-Hexwert:","@c0hex","\n\n"; print "Betriebstunden:\t\t",$BETRIEBSSTUNDEN,"\n"; print "Wartung:\t\t",$WARTUNG,"\n"; print "VL:\t\t\t",$VL,"\n"; print "RL:\t\t\t",$RL,"\n"; print "F1:\t\t\t",$F1TEMP,"\n"; print "F2:\t\t\t",$F2TEMP,"\n"; print "VL Soll:\t\t",$SVL,"\n"; print "RL Soll:\t\t",$SRL,"\n"; print "Ausen:\t\t\t",$AUSENTEMP,"\n"; print "Generator Temp:\t\t",$GENERTEMP,"\n"; print "Servicecode:\t\t",$SERVICECODE,"\n"; print "Betreibsart:\t\t",$BETRIEBSART,"\n"; print "BHKW Freigabe:\t\t",$BHKW_FREIGABE,"\n"; print "Brenner Freigabe:\t",$BRENNER_FREIGABE,"\n"; print "Motor Temp:\t\t",$MOTORTEMP,"\n"; print "Abgas:\t\t\t",$ABGAS,"\n"; print "Drehzahl:\t\t",$DREHZAHL,"\n"; print "erzeugte E-Energie:\t",$ERZEUGTE_E_ENERGIE,"\n"; print "erzeugte Wärme:\t\t",$ERZEUGT_WAERME,"\n"; print "Generator ist:\t\t",$GEN_LEISTUNG,"\n"; print "Startvorgang:\t\t",$STARTS,"\n"; print "\n"; print "*********** DEBUG Ende **************\n\n"; } </source> === 48 === '''Ein Beispiel für die 48 Werte''' <source lang="perl"> #!/usr/bin/perl -w # Abfrage der Dachs 48-Werte per esex # # kleines Beispielscript, das die 48 Wert abholt ud anschliesend aufbereitet # in Variabeln schreibt. # Das Script kann als Vorlage für eigene Entwicklungen benutzt werden. # # Autor: Lothar Schweikle-Droll # Lizenz: GPL use strict; use Net::Telnet (); my $debug=1; my $esex; my $esexip="192.168.255.90"; my $esexport="2701"; my $x48hex1; my $x48hex2; my $x48hex3; my $x48hex4; my $x48hex; my @x48hex; my $WARTUNG; my $BETRIEBSSTUNDEN; my $MAXABGAS; my $VL; my $STOERUNGEN; my $F1TEMP; my $F2TEMP; my $MAXGENERTEMP; my $MAXMOTORTEMP; my $STARTS; my $MITTELGENLEISTUNG; my $FLUESSIGKEITSCHALTER; my $LETZTEWARTUNG; my $NAECHSTEWARTUNGOEL; my $NAECHSTEWARTUNGGAS; my @FEHLERCODE; #000-127 my @FEHLERAUTO; #1=Autoentstörung my @FEHLERCODELANG; my @FEHLERMIN; my @FEHLERSTUNDEN; my @FEHLERTAG; my @FEHLERMON; my @FEHLERJAHR; my @FEHLERDATUM; my $non; my %Servicecode = ( 0=>'Allgemeine Hilfe', 1=>'Abgasfühler U/K', 2=>'Kuehlw.Motor U/K', 3=>'Kuehlw.Gener. U/K', 4=>'04', 5=>'Vorlauftemp. U/K', 6=>'Ruecklauftemp U/K', 7=>'Fuehler 1 U/K', 8=>'Fuehler 2 U/K', 9=>'Aussentemp. U/K', 10=>'Fluessigkeit. U/K', 11=>'11', 11=>'12', 13=>'13', 14=>'14', 15=>'15', 16=>'16', 17=>'17', 18=>'18', 19=>'19', 20=>'Abgas Motor zu hoch', 21=>'21', 22=>'Kuehlw. Motor > 95 C', 23=>'Abgastemp. zu hoch', 24=>'Kuehlw. Generator > 77 C', 25=>'25', 26=>'2h Vorlauft < Soll', 27=>'27', 28=>'28', 29=>'UP:Rueckleistung', 30=>'30', 31=>'HKA-Anl. < 100 U/min', 32=>'32', 33=>'HKA-Lauf < 2300 U/m', 34=>'34', 35=>'35', 36=>'36', 37=>'37', 38=>'38', 39=>'Generatorzuschalt', 40=>'Generatorabschalt', 41=>'Generator fehlt', 42=>'kein Text', 43=>'kein Text', 44=>'1h Si-Kette offen', 45=>'kein Text', 46=>'kein Text', 47=>'kein Text', 48=>'UP/LP:Int. b. Start', 49=>'UP: Intern', 50=>'UP/LP: Intern', 51=>'UP:Startfreigabe', 52=>'UP:Datentransfer', 53=>'UP:keine Daten', 54=>'kein Text', 55=>'kein Text', 56=>'UP:Messk Drehzahl', 56=>'kein Text', 57=>'kein Text', 58=>'kein Text', 59=>'UP:Spannung b.St.', 60=>'UP: Spannung', 61=>'kein Text', 62=>'Leistung zu hoch', 63=>'Leistung zu klein', 64=>'Leistung im Stand', 65=>'kein Text', 66=>'ENS-3 Abschaltung', 67=>'UP:Frequenz b.St', 68=>'UP:Frequenz', 69=>'UP:Phasen', 70=>'kein Text', 71=>'Oeldruckschalter', 72=>'Oeldruckmangel', 73=>'MV/Hubmag.undicht', 74=>'MV/Hubmag.undicht', 75=>'kein Text', 76=>'Programmdurchlauf', 77=>'kein Text', 78=>'kein Text', 79=>'4 Starts < 2300 U/m', 80=>'kein Text', 81=>'kein Text', 82=>'kein Text', 83=>'kein Text', 84=>'UP:Drehfeld', 85=>'Fluessigkeitssch', 86=>'UP: Zuendaussetzer', 87=>'Drehz. > 3300 U/min', 88=>'4 Starts 400-800U/m', 89=>'4Starts < 400 U/min', 90=>'kein Text', 91=>'UP:Drehz > 3500 U/m', 92=>'UP:verriegelt', 93=>'UP/RP-Prog.falsch', 94=>'kein Text', 95=>'No ClkRAM Kommuni', 96=>'No Ack-w I2C-Bus', 97=>'No Ack-r I2C-Bus', 98=>'Clk_RAM write nOK', 99=>'UP:Flags'); &x48_esex; &wertezuweisung; ### Ab hier kann eigener Code stehen if ( $debug == 1){ &debug; } ##### Subrotinen sub x48_esex { #Dachs 48 abfrge per Telnet über den ethersex $esex = Net::Telnet->new || die "kann Ethersex nicht finden"; $esex->open(Host => $esexip, Port => $esexport, Timeout => 1); # $x48hex1=$esex->cmd('msr1 get 1'); $esex->print("msr1 get 2"); ($non, $x48hex1) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $x48hex2) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $x48hex3) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $x48hex4) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); $x48hex = ($x48hex1).($x48hex2).($x48hex3).($x48hex4); #die vier Einzelwerte zu einem gesamt String zusammensetzen @x48hex = $x48hex =~ /(..)/g; #Den String in eine Array schreiben (nur die HEX-Werte ohne Leerstellen } sub wertezuweisung { $BETRIEBSSTUNDEN=hex($x48hex[1].$x48hex[2]); $STARTS=hex($x48hex[3].$x48hex[4]); $MAXABGAS=hex($x48hex[5])+15; $MAXGENERTEMP=hex($x48hex[7]); $MAXMOTORTEMP=hex($x48hex[6]); #MAXVL auf negative Temp prüfen if (hex($x48hex[8]) >128 ) { $VL=hex($x48hex[8])-255; }else{ $VL=hex($x48hex[8]); } #Max F1 und F2 auf negative Temp prüfen if (hex($x48hex[9]) >128 ) { $F1TEMP=hex($x48hex[9])-255; }else{ $F1TEMP=hex($x48hex[9]); } if (hex($x48hex[10]) >128 ) { $F2TEMP=hex($x48hex[10])-255; }else{ $F2TEMP=hex($x48hex[10]); } $MITTELGENLEISTUNG=(7.5 / 255 * hex($x48hex[11])); $STOERUNGEN=hex($x48hex[12]); $FLUESSIGKEITSCHALTER=hex($x48hex[55]); $LETZTEWARTUNG=hex($x48hex[59].$x48hex[60]); $NAECHSTEWARTUNGOEL=hex($x48hex[59].$x48hex[60])+2700; $NAECHSTEWARTUNGGAS=hex($x48hex[59].$x48hex[60])+3500; #Fehler Code zuweisen for ($non=1;$non<=7;$non++) { $FEHLERCODE[$non]=hex($x48hex[7+(6*$non)]); $FEHLERAUTO[$non]="0"; if ( $FEHLERCODE[$non] > 127 ) { $FEHLERCODE[$non]=$FEHLERCODE[$non]-128; $FEHLERAUTO[$non]="1"; } $FEHLERCODELANG[$non]=$Servicecode{$FEHLERCODE[$non]}; $FEHLERSTUNDEN[$non]=hex($x48hex[9+(6*$non)]); if ( $FEHLERSTUNDEN[$non]=~ /^[0-9]$/ ) { $FEHLERSTUNDEN[$non]='0'.$FEHLERSTUNDEN[$non]; } $FEHLERMIN[$non]=hex($x48hex[8+(6*$non)]); if ( $FEHLERMIN[$non]=~ /^[0-9]$/ ) { $FEHLERMIN[$non]='0'.$FEHLERMIN[$non]; } $FEHLERTAG[$non]=hex($x48hex[10+(6*$non)]); if ( $FEHLERTAG[$non]=~ /^[0-9]$/ ) { $FEHLERTAG[$non]='0'.$FEHLERTAG[$non]; } $FEHLERMON[$non]=hex($x48hex[11+(6*$non)]); if ( $FEHLERMON[$non]=~ /^[0-9]$/ ) { $FEHLERMON[$non]='0'.$FEHLERMON[$non]; } $FEHLERJAHR[$non]=hex($x48hex[12+(6*$non)]); if ( $FEHLERJAHR[$non]=~ /^[0-9]$/ ) { $FEHLERJAHR[$non]='0'.$FEHLERJAHR[$non]; } $FEHLERDATUM[$non]=$FEHLERSTUNDEN[$non].":".$FEHLERMIN[$non]." ".$FEHLERTAG[$non].".".$FEHLERMON[$non].".".$FEHLERJAHR[$non]; #Deutsch ohne Sekunden $FEHLERDATUM[$non]=$FEHLERJAHR[$non]."-".$FEHLERMON[$non]."-".$FEHLERTAG[$non]." ".$FEHLERSTUNDEN[$non].":".$FEHLERMIN[$non].":30"; #International mit gemittelte Sekunden #print "HEXzahl: ".(7 + (6 * $non))."\n"; } } sub debug { print "\n*********** DEBUG Start *************\n\n"; print "48-Hexwert:","@x48hex","\n\n"; print "Betriebstunden:\t\t",$BETRIEBSSTUNDEN,"\n"; print "Letzte Wartung:\t\t",$LETZTEWARTUNG,"\n"; print "Wartung bei Öl (alle 2700h):\t",$NAECHSTEWARTUNGOEL,"\n"; print "Wartung bei Gas (alle 3500h):\t",$NAECHSTEWARTUNGGAS,"\n"; print "Starts:\t\t\t",$STARTS,"\n"; print "MAX Abgas:\t\t",$MAXABGAS,"\n"; print "MAX Gen Temp:\t\t",$MAXGENERTEMP,"\n"; print "MAX Mot Temp:\t\t",$MAXMOTORTEMP,"\n"; print "Max VL:\t\t\t",$VL,"\n"; print "Max F1:\t\t\t",$F1TEMP,"\n"; print "Max F2:\t\t\t",$F2TEMP,"\n"; print "Mittlere Gen Leistung:\t",$MITTELGENLEISTUNG,"\n"; print "Anzahl Störungen:\t",$STOERUNGEN,"\n"; print "Fluessigkeitsschalter:\t",$FLUESSIGKEITSCHALTER,"\n\n"; print "Fehlerpeicher\n"; print "=============\n"; for ($non=1;$non<=7;$non++) { print "Fehler: ".$non."\n"; print "Fehlercode: ".$FEHLERCODE[$non]."\n"; print "Autoentstörung: ".$FEHLERAUTO[$non]."\n"; print "Zeit: ".$FEHLERSTUNDEN[$non].":".$FEHLERMIN[$non]." ".$FEHLERTAG[$non].".".$FEHLERMON[$non].".".$FEHLERJAHR[$non]."\n"; print "Datum: ".$FEHLERDATUM[$non]."\n"; print "Langtext: ".$FEHLERCODELANG[$non]."\n\n"; } print "\n"; print "*********** DEBUG Ende **************\n\n"; } </source> === 50 === '''Ein Beispiel für die 50 Werte''' <source lang="perl"> #!/usr/bin/perl -w # Abfrage der Dachs 50-Werte per esex # # kleines Beispielscript, das die 50 Wert abholt ud anschliesend aufbereitet # in Variabeln schreibt. # Das Script kann als Vorlage für eigene Entwicklungen benutzt werden. # # Autor: Lothar Schweikle-Droll # Lizenz: GPL use strict; use constant PI => 4 * atan2(1, 1); #Wegen cosph Berechnung use Net::Telnet (); my $debug=1; my $esex; my $esexip="192.168.255.90"; my $esexport="2701"; my $x50hex1; my $x50hex2; my $x50hex3; my $x50hex4; my $x50hex; my @x50hex; my $RL; my $VL; my $MOTORTEMP; my $ABGAS; my $AUSENTEMP; my $F1TEMP; my $F2TEMP; my $GENERTEMP; my $DREHZAHL; my $BIVAL_UMSCHALT_TMP; my $BIVAL_UMSCHALT_ZEIT; my $SERVICE; my $UMWALZPUMPESTATUS1; my $UMWALZPUMPESTATUS2; my $U1; my $U2; my $U3; my $I1; my $I2; my $I3; my $COSPHI; my $UE_PLATINE; my $non; &e8_esex; &wertezuweisung; ### Ab hier kann eigener Code stehen if ( $debug == 1){ &debug; } ##### Subrotinen sub e8_esex { #Dachs C0 abfrge per Telnet über den ethersex $esex = Net::Telnet->new || die "kann Ethersex nicht finden"; $esex->open(Host => $esexip, Port => $esexport, Timeout => 1); # $x50hex1=$esex->cmd('msr1 get 1'); $esex->print("msr1 get 3"); ($non, $x50hex1) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $x50hex2) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $x50hex3) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $x50hex4) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); $x50hex = ($x50hex1).($x50hex2).($x50hex3).($x50hex4); #die vier Einzelwerte zu einem gesamt String zusammensetzen @x50hex = $x50hex =~ /(..)/g; #Den String in eine Array schreiben (nur die HEX-Werte ohne Leerstellen } sub wertezuweisung { #VL auf negative Temp prüfen if (hex($x50hex[1]) >128 ) { $VL=hex($x50hex[1])-255; }else{ $VL=hex($x50hex[1]); } #RL auf negative Temp prüfen if (hex($x50hex[2]) >128 ) { $RL=hex($x50hex[2])-255; }else{ $RL=hex($x50hex[2]); } $MOTORTEMP=hex($x50hex[3]); $ABGAS=hex($x50hex[4])+15; #Ausentemp auf negative Temp prüfen if (hex($x50hex[5]) >128 ) { $AUSENTEMP=hex($x50hex[5])-255; }else{ $AUSENTEMP=hex($x50hex[5]); } #F1 und F2 auf negative Temp prüfen if (hex($x50hex[6]) >128 ) { $F1TEMP=hex($x50hex[6])-255; }else{ $F1TEMP=hex($x50hex[6]); } if (hex($x50hex[7]) >128 ) { $F2TEMP=hex($x50hex[7])-255; }else{ $F2TEMP=hex($x50hex[7]); } $GENERTEMP=hex($x50hex[8]); $ABGAS=hex($x50hex[4])+15; $DREHZAHL=hex($x50hex[10].$x50hex[11]); $BIVAL_UMSCHALT_TMP=hex($x50hex[13]); $BIVAL_UMSCHALT_ZEIT=hex($x50hex[14].$x50hex[15]); #Wert in Minuten $SERVICE=hex($x50hex[16]); $UMWALZPUMPESTATUS1=hex($x50hex[21]); $UMWALZPUMPESTATUS2=hex($x50hex[21]); $U1=105.6 + (100.0 / 461) * (hex($x50hex[31].$x50hex[32])); #105.6V + (100.0 /0x1cd) * Wert $U2=314.4 - (100.0 / 461) * (hex($x50hex[33].$x50hex[34])); #314.4V - (100.0 /0x1cd) * Wert $U3=105.6 + (100.0 / 461) * (hex($x50hex[35].$x50hex[36])); #105.6V + (100.0 /0x1cd) * Wert $I1=hex($x50hex[37].$x50hex[38]) * (10.0 / 461) - (10.0 * 205) / 461 ; #Wert * (10.0A /0x1cd) - (10.0*0xcd)/0x1cd $I2=hex($x50hex[39].$x50hex[40]) * (10.0 / 461) - (10.0 * 205) / 461; #Wert * (10.0A /0x1cd) - (10.0*0xcd)/0x1cd $I3=10.0 / 461 * (757 - (hex($x50hex[41].$x50hex[42]))); #10.0A/0x1cd * (0x02f5 - Wert) #$x50hex[43]='C9'; $COSPHI=abs( cos(((hex($x50hex[43]))-128)*PI/180) ); if (hex($x50hex[45]) >= 253 ) { $UE_PLATINE='ok'; }else{ $UE_PLATINE='error'; } } sub debug { print "\n*********** DEBUG Start *************\n\n"; print "50-Hexwert:","@x50hex","\n\n"; print "VL:\t\t\t",$VL,"\n"; print "RL:\t\t\t",$RL,"\n"; print "Motor Temp:\t\t",$MOTORTEMP,"\n"; print "Abgas:\t\t\t",$ABGAS,"\n"; print "F1:\t\t\t",$F1TEMP,"\n"; print "F2:\t\t\t",$F2TEMP,"\n"; print "Generator Temp:\t\t",$GENERTEMP,"\n"; print "Drehzahl:\t\t",$DREHZAHL,"\n"; print "BIVAL_UMSCHALT_TMP:\t",$BIVAL_UMSCHALT_TMP,"\n"; print "BIVAL_UMSCHALT_ZEIT:\t",$BIVAL_UMSCHALT_ZEIT,"\n"; print "U1:\t\t\t",$U1," ",hex($x50hex[31].$x50hex[32]),"\n"; print "U2:\t\t\t",$U2," ",hex($x50hex[33].$x50hex[34]),"\n"; print "U3:\t\t\t",$U3," ",hex($x50hex[35].$x50hex[36]),"\n"; print "I1:\t\t\t",$I1," ",hex($x50hex[37].$x50hex[38]),"\n"; print "I2:\t\t\t",$I2," ",hex($x50hex[39].$x50hex[40]),"\n"; print "I3:\t\t\t",$I3," ",hex($x50hex[41].$x50hex[42]),"\n"; print "COSPHI:\t\t\t",$COSPHI," ",hex($x50hex[43]),"\n"; print "UE_PLATINE:\t\t",$UE_PLATINE," ",hex($x50hex[45]),"\n"; print "UMWALZPUMPESTATUS1:\t",$UMWALZPUMPESTATUS1,"\n"; print "UMWALZPUMPESTATUS2:\t",$UMWALZPUMPESTATUS2,"\n"; print "\n"; print "*********** DEBUG Ende **************\n\n"; } </source> [[Kategorie:Ethersex]] [[Kategorie:Home-Visualisierung]] [[Category:MSR1]] 1365492b2e71951a32cab4c5a0d348e7263d5db2 179 178 2011-11-08T10:32:14Z Loddel 64 Replaced content with "'''nur in deutsch'''" wikitext text/x-wiki '''nur in deutsch''' b989f625a848b61ade79a623f935fe51b7c89c1b 181 179 2011-11-08T10:33:36Z Loddel 64 wikitext text/x-wiki [http://ethersex.de/index.php/Dachs_MSR1_%28Deutsch%29| nur in deutsch] a405428ea2c911c0fa88fa15a4860fb8b501623a 182 181 2011-11-08T10:34:06Z Loddel 64 wikitext text/x-wiki [http://www.ethersex.de/index.php/Dachs_MSR1_%28Deutsch%29| nur in deutsch] 84b184befaf0676b33fff7d84cd0ff0338f418b6 183 182 2011-11-09T09:18:03Z Mgue 312 wikitext text/x-wiki {{i18n|Dachs MSR1}} b97b212c7a37d871d05292f5bca11f3a439c1f3f 6 47 173 2011-11-08T10:22:01Z Loddel 64 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 48 176 2011-11-08T10:24:26Z Loddel 64 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 49 177 2011-11-08T10:25:34Z Loddel 64 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 50 180 2011-11-08T10:32:18Z Loddel 64 Created page with "Die Dachs MSR1 ist ein Klein-Blockheizkraftwerk (BHKW) der Firma [http://www.senertec.de SenerTec], die sowohl Wärme, als auch Strom erzeugt, und vor allem eine serielle Schnitt…" wikitext text/x-wiki Die Dachs MSR1 ist ein Klein-Blockheizkraftwerk (BHKW) der Firma [http://www.senertec.de SenerTec], die sowohl Wärme, als auch Strom erzeugt, und vor allem eine serielle Schnittstelle zur Verfügung stellt *Händereib*. Über diese kann man einiges an Betriebs- und Wartungsdaten auslesen. Eine genauere Beschreibung des Protokolls gibts [[Dachs_MSR1_Service_Protokoll|hier]]. │ │ Load a Default Configuration ---> │ │ ... │ │ IO Support ---> | | ... │ │ [*] Senertec Dachs MSR1 Support │ │ (0) MSR1 usart select == Anschluss == [[File:Dachs_msr1_anschluss.png|thumb]] Obwohl sowohl das Ethersex, als auch die MSR1 einen Slave (Weiblich) RS232 Anschluss hat braucht man ein 1:1 Kabel. Außerdem muss das RTS Signal des MSR1 auf eine logische Null gelegt werden, da sich die MSR1 sonst nicht für irgendwelche Befehle interessiert. Dazu verwendet man am besten den zweiten Kanal des verbauten MAX232, legt den Eingang auf GND und greift die +10V am Ausgang ab. Ansonsten ist der RS232 Anschluss ein 9600 8N1. == Alternative Kabelbelegung == Im [http://www.bhkw-forum.de BHKW-Forum] gibt es noch eine alternative Kabelbelegung. Zu beachten ist nur, das man die Leitungen nicht kreuzen darf. (getestet mit dem AVR-Net-IO) [[Media:Kabelbelegung_Dachs_MRS1.pdf]] Die dort beschriebene Belegung ist also für PC->Dachs gedacht. Diese Variante funktioniert mit einem ethersex nur dann, wenn an der RS232 Buchse auch der RTS Kanal durch den MAX232 geschleift wird. (Und die Ethersexfirmware um RTS Handshaking erweitert wurde *huestel*) == Auslesen == Der MSR1 kann man zwei verschiedene Datensätze entlocken, den "0xe8"-Datensatz und den "0xc0"-Datensatz. Beide enthalten teilweise redundante Daten, wobei jedoch letzterer weitaus mehr Informationen bietet. Den 0xe8 Datensatz bekommt man mit dem ecmd `msr1 get' bzw. `msr1 get 0'. Das erste Byte gibt an, wieviele Anfragen seit dem letzten erfolgreichen Versuch fehlgeschlagen sind. Den 0xc0-Datensatz bekommt man über `msr1 get 1'. == Einbindung in den [[HTTPD]] == [[File:800px-Msr1_screenshot.png|600px]] │ │ Load a Default Configuration ---> │ │ ... │ │ General Setup ---> │ │ ... │ │ [*] VFS (Virtual File System) ---> │ │ [*] VFS File Inling │ │ [*] Inline MSR1 Unter '''$ethersexip/msr.ht''' kann nun der aktuelle Status des Dachs ausgelesen werden. = Programm Beispiele = == Abfrage in Perl == === e8 === '''Ein Beispiel wie die Werte e8 abgefragt und aufbereitet werden.''' <source lang="perl"> #!/usr/bin/perl -w # Abfrage der Dachs e8-Werte per esex # # kleines Beispielscript, das die e8 Wert abholt ud anschliesend aufbereitet # in Variabeln schreibt. # Das Script kann als Vorlage für eigene Entwicklungen benutzt werden. # # Autor: Lothar Schweikle-Droll # Lizenz: GPL use strict; use Net::Telnet (); my $debug=1; my $esex; my $esexip="192.168.255.90"; my $esexport="2701"; my $e8hex; my @e8hex; my $BETRIEBSSTUNDEN; my $WARTUNG; my $RL; my $VL; my $ABGAS; my $EINSCH_TEMP_SOL; my $BETRIEBSZUSTAND; my $BETRIEBSZUSTAND_SOL; my $GEN_LEISTUNG_SOL; my @SERVICE_CODE_MODUL; #Modul 0 = Leitregler my %BETRIEBSZUSTAND = ( 10=>'Störabschaltung', 11=>'Abschaltung MV1', 11=>'Abschaltung MV2', 13=>'Drehzahl<200 n. 25 sek.', 14=>'Drehzahl>200 n. 25 sek.', 15=>'Abschaltung>1 Minute', 16=>'Abschaltung>4 Minuten', 20=>'Startvorbereitung', 21=>'Starteinleitung', 22=>'Start', 23=>'1,5 sek. nach Start', 24=>'Startende', 30=>'450<Drehz<800', 32=>'Zuschaltung Generator', 33=>'Leistungsregelung runter', 34=>'Leistungsregelung hoch', 35=>'Betrieb'); my $non; &e8_esex; &wertezuweisung; ### Ab hier kann eigener Code stehen if ( $debug == 1){ &debug; } ##### Subrotinen sub e8_esex { #Dachs e8 abfrge per Telnet über den ethersex $esex = Net::Telnet->new || die "kann Ethersex nicht finden"; $esex->open(Host => $esexip, Port => $esexport, Timeout => 1); $esex->print("msr1 get 0"); ($non, $e8hex) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); #den String in ein Array wandeln @e8hex = $e8hex =~ /(..)/g; } sub wertezuweisung { $BETRIEBSSTUNDEN=hex($e8hex[1].$e8hex[2]); $WARTUNG=hex($e8hex[3]); #RL auf negative Temp prüfen if (hex($e8hex[4]) >128 ) { $RL=hex($e8hex[4])-255; }else{ $RL=hex($e8hex[4]); } #VL auf negative Temp prüfen if (hex($e8hex[5]) >128 ) { $VL=hex($e8hex[5])-255; }else{ $VL=hex($e8hex[5]); } $ABGAS=hex($e8hex[6])+15; $EINSCH_TEMP_SOL=hex($e8hex[7]); $BETRIEBSZUSTAND=$BETRIEBSZUSTAND{hex($e8hex[8])}; $GEN_LEISTUNG_SOL= sprintf("%.3f" , hex($e8hex[9])/34); #Sollwert Der Generatorleistung gerundet auf 3 Stellen nach dem Komma my $i=0; while ($i <=5 ) { $SERVICE_CODE_MODUL[$i]=hex($e8hex[$i+10]); $i++ } $BETRIEBSZUSTAND_SOL=hex($e8hex[16]); } sub debug { print "\n*********** DEBUG Start *************\n\n"; print "e8-Hexwert:","@e8hex","\n\n"; print "Betriebstundenb:\t",$BETRIEBSSTUNDEN,"\n"; print "Wartung:\t\t",$WARTUNG,"\n"; print "VL:\t\t\t",$VL,"\n"; print "RL:\t\t\t",$RL,"\n"; print "Abgas:\t\t\t",$ABGAS,"\n"; print "EINSCH_TEMP_SOL:\t",$EINSCH_TEMP_SOL,"\n"; print "Betriebszustand:\t",$BETRIEBSZUSTAND,"\n"; print "Generator Leitsung Sol:\t",$GEN_LEISTUNG_SOL,"\n"; print "BETRIEBSZUSTAND_SOL:\t",$BETRIEBSZUSTAND_SOL,"\n"; my $i=0; while ($i <=5 ) { #$SERVICE_CODE_MODUL[$i]=hex($e8sex[$i+10]); print "SERVICE_CODE_MODUL[".$i."]\t".$SERVICE_CODE_MODUL[$i],"\n"; $i++ } print "\n"; print "*********** DEBUG Ende **************\n\n"; } </source> === c0 === '''Ein Beispiel für die c0 Werte''' <source lang="perl"> #!/usr/bin/perl -w # Abfrage der Dachs c0-Werte per esex # # kleines Beispielscript, das die c0 Wert abholt ud anschliesend aufbereitet # in Variabeln schreibt. # Das Script kann als Vorlage für eigene Entwicklungen benutzt werden. # # Autor: Lothar Schweikle-Droll # Lizenz: GPL use strict; use Net::Telnet (); my $debug=1; my $esex; my $esexip="192.168.255.90"; my $esexport="2701"; my $c0hex1; my $c0hex2; my $c0hex3; my $c0hex4; my $c0hex; my @c0hex; my $WARTUNG; my $RL; my $VL; my $SRL; my $SVL; my $BETRIEBSSTUNDEN; my $ABGAS; my $AUSENTEMP; my $F1TEMP; my $F2TEMP; my $GENERTEMP; my $MOTORTEMP; my $SERVICECODE; my $BETRIEBSART; my $BHKW_FREIGABE; my $BRENNER_FREIGABE; my $DREHZAHL; my $ERZEUGTE_E_ENERGIE; my $ERZEUGT_WAERME; my $GEN_LEISTUNG; my $STARTS; my $non; &e8_esex; &wertezuweisung; ### Ab hier kann eigener Code stehen if ( $debug == 1){ &debug; } ##### Subrotinen sub e8_esex { #Dachs C0 abfrge per Telnet über den ethersex $esex = Net::Telnet->new || die "kann Ethersex nicht finden"; $esex->open(Host => $esexip, Port => $esexport, Timeout => 1); # $c0hex1=$esex->cmd('msr1 get 1'); $esex->print("msr1 get 1"); ($non, $c0hex1) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $c0hex2) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $c0hex3) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $c0hex4) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); $c0hex = ($c0hex1).($c0hex2).($c0hex3).($c0hex4); #die vier Einzelwerte zu einem gesamt String zusammensetzen @c0hex = $c0hex =~ /(..)/g; #Den String in eine Array schreiben (nur die HEX-Werte ohne Leerstellen } sub wertezuweisung { $BETRIEBSSTUNDEN=hex($c0hex[19].$c0hex[20]); $WARTUNG=$c0hex[3]; #RL auf negative Temp prüfen if (hex($c0hex[22]) >128 ) { $RL=hex($c0hex[22])-255; }else{ $RL=hex($c0hex[22]); } $SRL=hex($c0hex[21]); #VL auf negative Temp prüfen if (hex($c0hex[24]) >128 ) { $VL=hex($c0hex[24])-255; }else{ $VL=hex($c0hex[24]); } $SVL=hex($c0hex[23]); #Ausentemp auf negative Temp prüfen if (hex($c0hex[25]) >128 ) { $AUSENTEMP=hex($c0hex[25])-255; }else{ $AUSENTEMP=hex($c0hex[25]); } #F1 und F2 auf negative Temp prüfen if (hex($c0hex[26]) >128 ) { $F1TEMP=hex($c0hex[26])-255; }else{ $F1TEMP=hex($c0hex[26]); } if (hex($c0hex[27]) >128 ) { $F2TEMP=hex($c0hex[27])-255; }else{ $F2TEMP=hex($c0hex[27]); } $GENERTEMP=hex($c0hex[28]); $SERVICECODE=hex($c0hex[30]); $BETRIEBSART=$c0hex[31]; $BHKW_FREIGABE=hex($c0hex[32]); $BRENNER_FREIGABE=hex($c0hex[33]); $MOTORTEMP=hex($c0hex[34]); $ABGAS=hex($c0hex[35])+15; $DREHZAHL=hex($c0hex[36].$c0hex[37]); $ERZEUGTE_E_ENERGIE=hex($c0hex[38].$c0hex[39].$c0hex[40].$c0hex[41]); $ERZEUGT_WAERME=hex($c0hex[42].$c0hex[43].$c0hex[44].$c0hex[45]); $GEN_LEISTUNG=sprintf("%.3f" , hex($c0hex[46])/34); #Sollwert Der Generatorleistung gerundet auf 3 Stellen nach dem Komma $STARTS=hex($c0hex[47].$c0hex[48]); } sub debug { print "\n*********** DEBUG Start *************\n\n"; print "c0-Hexwert:","@c0hex","\n\n"; print "Betriebstunden:\t\t",$BETRIEBSSTUNDEN,"\n"; print "Wartung:\t\t",$WARTUNG,"\n"; print "VL:\t\t\t",$VL,"\n"; print "RL:\t\t\t",$RL,"\n"; print "F1:\t\t\t",$F1TEMP,"\n"; print "F2:\t\t\t",$F2TEMP,"\n"; print "VL Soll:\t\t",$SVL,"\n"; print "RL Soll:\t\t",$SRL,"\n"; print "Ausen:\t\t\t",$AUSENTEMP,"\n"; print "Generator Temp:\t\t",$GENERTEMP,"\n"; print "Servicecode:\t\t",$SERVICECODE,"\n"; print "Betreibsart:\t\t",$BETRIEBSART,"\n"; print "BHKW Freigabe:\t\t",$BHKW_FREIGABE,"\n"; print "Brenner Freigabe:\t",$BRENNER_FREIGABE,"\n"; print "Motor Temp:\t\t",$MOTORTEMP,"\n"; print "Abgas:\t\t\t",$ABGAS,"\n"; print "Drehzahl:\t\t",$DREHZAHL,"\n"; print "erzeugte E-Energie:\t",$ERZEUGTE_E_ENERGIE,"\n"; print "erzeugte Wärme:\t\t",$ERZEUGT_WAERME,"\n"; print "Generator ist:\t\t",$GEN_LEISTUNG,"\n"; print "Startvorgang:\t\t",$STARTS,"\n"; print "\n"; print "*********** DEBUG Ende **************\n\n"; } </source> === 48 === '''Ein Beispiel für die 48 Werte''' <source lang="perl"> #!/usr/bin/perl -w # Abfrage der Dachs 48-Werte per esex # # kleines Beispielscript, das die 48 Wert abholt ud anschliesend aufbereitet # in Variabeln schreibt. # Das Script kann als Vorlage für eigene Entwicklungen benutzt werden. # # Autor: Lothar Schweikle-Droll # Lizenz: GPL use strict; use Net::Telnet (); my $debug=1; my $esex; my $esexip="192.168.255.90"; my $esexport="2701"; my $x48hex1; my $x48hex2; my $x48hex3; my $x48hex4; my $x48hex; my @x48hex; my $WARTUNG; my $BETRIEBSSTUNDEN; my $MAXABGAS; my $VL; my $STOERUNGEN; my $F1TEMP; my $F2TEMP; my $MAXGENERTEMP; my $MAXMOTORTEMP; my $STARTS; my $MITTELGENLEISTUNG; my $FLUESSIGKEITSCHALTER; my $LETZTEWARTUNG; my $NAECHSTEWARTUNGOEL; my $NAECHSTEWARTUNGGAS; my @FEHLERCODE; #000-127 my @FEHLERAUTO; #1=Autoentstörung my @FEHLERCODELANG; my @FEHLERMIN; my @FEHLERSTUNDEN; my @FEHLERTAG; my @FEHLERMON; my @FEHLERJAHR; my @FEHLERDATUM; my $non; my %Servicecode = ( 0=>'Allgemeine Hilfe', 1=>'Abgasfühler U/K', 2=>'Kuehlw.Motor U/K', 3=>'Kuehlw.Gener. U/K', 4=>'04', 5=>'Vorlauftemp. U/K', 6=>'Ruecklauftemp U/K', 7=>'Fuehler 1 U/K', 8=>'Fuehler 2 U/K', 9=>'Aussentemp. U/K', 10=>'Fluessigkeit. U/K', 11=>'11', 11=>'12', 13=>'13', 14=>'14', 15=>'15', 16=>'16', 17=>'17', 18=>'18', 19=>'19', 20=>'Abgas Motor zu hoch', 21=>'21', 22=>'Kuehlw. Motor > 95 C', 23=>'Abgastemp. zu hoch', 24=>'Kuehlw. Generator > 77 C', 25=>'25', 26=>'2h Vorlauft < Soll', 27=>'27', 28=>'28', 29=>'UP:Rueckleistung', 30=>'30', 31=>'HKA-Anl. < 100 U/min', 32=>'32', 33=>'HKA-Lauf < 2300 U/m', 34=>'34', 35=>'35', 36=>'36', 37=>'37', 38=>'38', 39=>'Generatorzuschalt', 40=>'Generatorabschalt', 41=>'Generator fehlt', 42=>'kein Text', 43=>'kein Text', 44=>'1h Si-Kette offen', 45=>'kein Text', 46=>'kein Text', 47=>'kein Text', 48=>'UP/LP:Int. b. Start', 49=>'UP: Intern', 50=>'UP/LP: Intern', 51=>'UP:Startfreigabe', 52=>'UP:Datentransfer', 53=>'UP:keine Daten', 54=>'kein Text', 55=>'kein Text', 56=>'UP:Messk Drehzahl', 56=>'kein Text', 57=>'kein Text', 58=>'kein Text', 59=>'UP:Spannung b.St.', 60=>'UP: Spannung', 61=>'kein Text', 62=>'Leistung zu hoch', 63=>'Leistung zu klein', 64=>'Leistung im Stand', 65=>'kein Text', 66=>'ENS-3 Abschaltung', 67=>'UP:Frequenz b.St', 68=>'UP:Frequenz', 69=>'UP:Phasen', 70=>'kein Text', 71=>'Oeldruckschalter', 72=>'Oeldruckmangel', 73=>'MV/Hubmag.undicht', 74=>'MV/Hubmag.undicht', 75=>'kein Text', 76=>'Programmdurchlauf', 77=>'kein Text', 78=>'kein Text', 79=>'4 Starts < 2300 U/m', 80=>'kein Text', 81=>'kein Text', 82=>'kein Text', 83=>'kein Text', 84=>'UP:Drehfeld', 85=>'Fluessigkeitssch', 86=>'UP: Zuendaussetzer', 87=>'Drehz. > 3300 U/min', 88=>'4 Starts 400-800U/m', 89=>'4Starts < 400 U/min', 90=>'kein Text', 91=>'UP:Drehz > 3500 U/m', 92=>'UP:verriegelt', 93=>'UP/RP-Prog.falsch', 94=>'kein Text', 95=>'No ClkRAM Kommuni', 96=>'No Ack-w I2C-Bus', 97=>'No Ack-r I2C-Bus', 98=>'Clk_RAM write nOK', 99=>'UP:Flags'); &x48_esex; &wertezuweisung; ### Ab hier kann eigener Code stehen if ( $debug == 1){ &debug; } ##### Subrotinen sub x48_esex { #Dachs 48 abfrge per Telnet über den ethersex $esex = Net::Telnet->new || die "kann Ethersex nicht finden"; $esex->open(Host => $esexip, Port => $esexport, Timeout => 1); # $x48hex1=$esex->cmd('msr1 get 1'); $esex->print("msr1 get 2"); ($non, $x48hex1) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $x48hex2) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $x48hex3) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $x48hex4) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); $x48hex = ($x48hex1).($x48hex2).($x48hex3).($x48hex4); #die vier Einzelwerte zu einem gesamt String zusammensetzen @x48hex = $x48hex =~ /(..)/g; #Den String in eine Array schreiben (nur die HEX-Werte ohne Leerstellen } sub wertezuweisung { $BETRIEBSSTUNDEN=hex($x48hex[1].$x48hex[2]); $STARTS=hex($x48hex[3].$x48hex[4]); $MAXABGAS=hex($x48hex[5])+15; $MAXGENERTEMP=hex($x48hex[7]); $MAXMOTORTEMP=hex($x48hex[6]); #MAXVL auf negative Temp prüfen if (hex($x48hex[8]) >128 ) { $VL=hex($x48hex[8])-255; }else{ $VL=hex($x48hex[8]); } #Max F1 und F2 auf negative Temp prüfen if (hex($x48hex[9]) >128 ) { $F1TEMP=hex($x48hex[9])-255; }else{ $F1TEMP=hex($x48hex[9]); } if (hex($x48hex[10]) >128 ) { $F2TEMP=hex($x48hex[10])-255; }else{ $F2TEMP=hex($x48hex[10]); } $MITTELGENLEISTUNG=(7.5 / 255 * hex($x48hex[11])); $STOERUNGEN=hex($x48hex[12]); $FLUESSIGKEITSCHALTER=hex($x48hex[55]); $LETZTEWARTUNG=hex($x48hex[59].$x48hex[60]); $NAECHSTEWARTUNGOEL=hex($x48hex[59].$x48hex[60])+2700; $NAECHSTEWARTUNGGAS=hex($x48hex[59].$x48hex[60])+3500; #Fehler Code zuweisen for ($non=1;$non<=7;$non++) { $FEHLERCODE[$non]=hex($x48hex[7+(6*$non)]); $FEHLERAUTO[$non]="0"; if ( $FEHLERCODE[$non] > 127 ) { $FEHLERCODE[$non]=$FEHLERCODE[$non]-128; $FEHLERAUTO[$non]="1"; } $FEHLERCODELANG[$non]=$Servicecode{$FEHLERCODE[$non]}; $FEHLERSTUNDEN[$non]=hex($x48hex[9+(6*$non)]); if ( $FEHLERSTUNDEN[$non]=~ /^[0-9]$/ ) { $FEHLERSTUNDEN[$non]='0'.$FEHLERSTUNDEN[$non]; } $FEHLERMIN[$non]=hex($x48hex[8+(6*$non)]); if ( $FEHLERMIN[$non]=~ /^[0-9]$/ ) { $FEHLERMIN[$non]='0'.$FEHLERMIN[$non]; } $FEHLERTAG[$non]=hex($x48hex[10+(6*$non)]); if ( $FEHLERTAG[$non]=~ /^[0-9]$/ ) { $FEHLERTAG[$non]='0'.$FEHLERTAG[$non]; } $FEHLERMON[$non]=hex($x48hex[11+(6*$non)]); if ( $FEHLERMON[$non]=~ /^[0-9]$/ ) { $FEHLERMON[$non]='0'.$FEHLERMON[$non]; } $FEHLERJAHR[$non]=hex($x48hex[12+(6*$non)]); if ( $FEHLERJAHR[$non]=~ /^[0-9]$/ ) { $FEHLERJAHR[$non]='0'.$FEHLERJAHR[$non]; } $FEHLERDATUM[$non]=$FEHLERSTUNDEN[$non].":".$FEHLERMIN[$non]." ".$FEHLERTAG[$non].".".$FEHLERMON[$non].".".$FEHLERJAHR[$non]; #Deutsch ohne Sekunden $FEHLERDATUM[$non]=$FEHLERJAHR[$non]."-".$FEHLERMON[$non]."-".$FEHLERTAG[$non]." ".$FEHLERSTUNDEN[$non].":".$FEHLERMIN[$non].":30"; #International mit gemittelte Sekunden #print "HEXzahl: ".(7 + (6 * $non))."\n"; } } sub debug { print "\n*********** DEBUG Start *************\n\n"; print "48-Hexwert:","@x48hex","\n\n"; print "Betriebstunden:\t\t",$BETRIEBSSTUNDEN,"\n"; print "Letzte Wartung:\t\t",$LETZTEWARTUNG,"\n"; print "Wartung bei Öl (alle 2700h):\t",$NAECHSTEWARTUNGOEL,"\n"; print "Wartung bei Gas (alle 3500h):\t",$NAECHSTEWARTUNGGAS,"\n"; print "Starts:\t\t\t",$STARTS,"\n"; print "MAX Abgas:\t\t",$MAXABGAS,"\n"; print "MAX Gen Temp:\t\t",$MAXGENERTEMP,"\n"; print "MAX Mot Temp:\t\t",$MAXMOTORTEMP,"\n"; print "Max VL:\t\t\t",$VL,"\n"; print "Max F1:\t\t\t",$F1TEMP,"\n"; print "Max F2:\t\t\t",$F2TEMP,"\n"; print "Mittlere Gen Leistung:\t",$MITTELGENLEISTUNG,"\n"; print "Anzahl Störungen:\t",$STOERUNGEN,"\n"; print "Fluessigkeitsschalter:\t",$FLUESSIGKEITSCHALTER,"\n\n"; print "Fehlerpeicher\n"; print "=============\n"; for ($non=1;$non<=7;$non++) { print "Fehler: ".$non."\n"; print "Fehlercode: ".$FEHLERCODE[$non]."\n"; print "Autoentstörung: ".$FEHLERAUTO[$non]."\n"; print "Zeit: ".$FEHLERSTUNDEN[$non].":".$FEHLERMIN[$non]." ".$FEHLERTAG[$non].".".$FEHLERMON[$non].".".$FEHLERJAHR[$non]."\n"; print "Datum: ".$FEHLERDATUM[$non]."\n"; print "Langtext: ".$FEHLERCODELANG[$non]."\n\n"; } print "\n"; print "*********** DEBUG Ende **************\n\n"; } </source> === 50 === '''Ein Beispiel für die 50 Werte''' <source lang="perl"> #!/usr/bin/perl -w # Abfrage der Dachs 50-Werte per esex # # kleines Beispielscript, das die 50 Wert abholt ud anschliesend aufbereitet # in Variabeln schreibt. # Das Script kann als Vorlage für eigene Entwicklungen benutzt werden. # # Autor: Lothar Schweikle-Droll # Lizenz: GPL use strict; use constant PI => 4 * atan2(1, 1); #Wegen cosph Berechnung use Net::Telnet (); my $debug=1; my $esex; my $esexip="192.168.255.90"; my $esexport="2701"; my $x50hex1; my $x50hex2; my $x50hex3; my $x50hex4; my $x50hex; my @x50hex; my $RL; my $VL; my $MOTORTEMP; my $ABGAS; my $AUSENTEMP; my $F1TEMP; my $F2TEMP; my $GENERTEMP; my $DREHZAHL; my $BIVAL_UMSCHALT_TMP; my $BIVAL_UMSCHALT_ZEIT; my $SERVICE; my $UMWALZPUMPESTATUS1; my $UMWALZPUMPESTATUS2; my $U1; my $U2; my $U3; my $I1; my $I2; my $I3; my $COSPHI; my $UE_PLATINE; my $non; &e8_esex; &wertezuweisung; ### Ab hier kann eigener Code stehen if ( $debug == 1){ &debug; } ##### Subrotinen sub e8_esex { #Dachs C0 abfrge per Telnet über den ethersex $esex = Net::Telnet->new || die "kann Ethersex nicht finden"; $esex->open(Host => $esexip, Port => $esexport, Timeout => 1); # $x50hex1=$esex->cmd('msr1 get 1'); $esex->print("msr1 get 3"); ($non, $x50hex1) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $x50hex2) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $x50hex3) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $x50hex4) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); $x50hex = ($x50hex1).($x50hex2).($x50hex3).($x50hex4); #die vier Einzelwerte zu einem gesamt String zusammensetzen @x50hex = $x50hex =~ /(..)/g; #Den String in eine Array schreiben (nur die HEX-Werte ohne Leerstellen } sub wertezuweisung { #VL auf negative Temp prüfen if (hex($x50hex[1]) >128 ) { $VL=hex($x50hex[1])-255; }else{ $VL=hex($x50hex[1]); } #RL auf negative Temp prüfen if (hex($x50hex[2]) >128 ) { $RL=hex($x50hex[2])-255; }else{ $RL=hex($x50hex[2]); } $MOTORTEMP=hex($x50hex[3]); $ABGAS=hex($x50hex[4])+15; #Ausentemp auf negative Temp prüfen if (hex($x50hex[5]) >128 ) { $AUSENTEMP=hex($x50hex[5])-255; }else{ $AUSENTEMP=hex($x50hex[5]); } #F1 und F2 auf negative Temp prüfen if (hex($x50hex[6]) >128 ) { $F1TEMP=hex($x50hex[6])-255; }else{ $F1TEMP=hex($x50hex[6]); } if (hex($x50hex[7]) >128 ) { $F2TEMP=hex($x50hex[7])-255; }else{ $F2TEMP=hex($x50hex[7]); } $GENERTEMP=hex($x50hex[8]); $ABGAS=hex($x50hex[4])+15; $DREHZAHL=hex($x50hex[10].$x50hex[11]); $BIVAL_UMSCHALT_TMP=hex($x50hex[13]); $BIVAL_UMSCHALT_ZEIT=hex($x50hex[14].$x50hex[15]); #Wert in Minuten $SERVICE=hex($x50hex[16]); $UMWALZPUMPESTATUS1=hex($x50hex[21]); $UMWALZPUMPESTATUS2=hex($x50hex[21]); $U1=105.6 + (100.0 / 461) * (hex($x50hex[31].$x50hex[32])); #105.6V + (100.0 /0x1cd) * Wert $U2=314.4 - (100.0 / 461) * (hex($x50hex[33].$x50hex[34])); #314.4V - (100.0 /0x1cd) * Wert $U3=105.6 + (100.0 / 461) * (hex($x50hex[35].$x50hex[36])); #105.6V + (100.0 /0x1cd) * Wert $I1=hex($x50hex[37].$x50hex[38]) * (10.0 / 461) - (10.0 * 205) / 461 ; #Wert * (10.0A /0x1cd) - (10.0*0xcd)/0x1cd $I2=hex($x50hex[39].$x50hex[40]) * (10.0 / 461) - (10.0 * 205) / 461; #Wert * (10.0A /0x1cd) - (10.0*0xcd)/0x1cd $I3=10.0 / 461 * (757 - (hex($x50hex[41].$x50hex[42]))); #10.0A/0x1cd * (0x02f5 - Wert) #$x50hex[43]='C9'; $COSPHI=abs( cos(((hex($x50hex[43]))-128)*PI/180) ); if (hex($x50hex[45]) >= 253 ) { $UE_PLATINE='ok'; }else{ $UE_PLATINE='error'; } } sub debug { print "\n*********** DEBUG Start *************\n\n"; print "50-Hexwert:","@x50hex","\n\n"; print "VL:\t\t\t",$VL,"\n"; print "RL:\t\t\t",$RL,"\n"; print "Motor Temp:\t\t",$MOTORTEMP,"\n"; print "Abgas:\t\t\t",$ABGAS,"\n"; print "F1:\t\t\t",$F1TEMP,"\n"; print "F2:\t\t\t",$F2TEMP,"\n"; print "Generator Temp:\t\t",$GENERTEMP,"\n"; print "Drehzahl:\t\t",$DREHZAHL,"\n"; print "BIVAL_UMSCHALT_TMP:\t",$BIVAL_UMSCHALT_TMP,"\n"; print "BIVAL_UMSCHALT_ZEIT:\t",$BIVAL_UMSCHALT_ZEIT,"\n"; print "U1:\t\t\t",$U1," ",hex($x50hex[31].$x50hex[32]),"\n"; print "U2:\t\t\t",$U2," ",hex($x50hex[33].$x50hex[34]),"\n"; print "U3:\t\t\t",$U3," ",hex($x50hex[35].$x50hex[36]),"\n"; print "I1:\t\t\t",$I1," ",hex($x50hex[37].$x50hex[38]),"\n"; print "I2:\t\t\t",$I2," ",hex($x50hex[39].$x50hex[40]),"\n"; print "I3:\t\t\t",$I3," ",hex($x50hex[41].$x50hex[42]),"\n"; print "COSPHI:\t\t\t",$COSPHI," ",hex($x50hex[43]),"\n"; print "UE_PLATINE:\t\t",$UE_PLATINE," ",hex($x50hex[45]),"\n"; print "UMWALZPUMPESTATUS1:\t",$UMWALZPUMPESTATUS1,"\n"; print "UMWALZPUMPESTATUS2:\t",$UMWALZPUMPESTATUS2,"\n"; print "\n"; print "*********** DEBUG Ende **************\n\n"; } </source> [[Kategorie:Ethersex]] [[Kategorie:Home-Visualisierung]] [[Category:MSR1]] 1365492b2e71951a32cab4c5a0d348e7263d5db2 184 180 2011-11-09T09:27:53Z Mgue 312 http://ethersex.de/index.php/Wiki_Guidelines wikitext text/x-wiki {{i18n|Dachs MSR1}} {{Module |NAME=Dachs MSR1 |MENUCONFIG={{Protocols}}->Senertec Dachs MSR1 Support |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6= - |DEPENDS=[[ECMD]] |REQUIRES=freie USART |CODE=[https://github.com/ethersex/ethersex/tree/master/protocols/msr1 https://github.com/ethersex/ethersex/tree/master/protocols/msr1] }} Die Dachs MSR1 ist ein Klein-Blockheizkraftwerk (BHKW) der Firma [http://www.senertec.de SenerTec], die sowohl Wärme, als auch Strom erzeugt, und vor allem eine serielle Schnittstelle zur Verfügung stellt *Händereib*. Über diese kann man einiges an Betriebs- und Wartungsdaten auslesen. Eine genauere Beschreibung des Protokolls gibts [[Dachs_MSR1_Service_Protokoll|hier]]. == Anschluss == [[File:Dachs_msr1_anschluss.png|thumb]] Obwohl sowohl das Ethersex, als auch die MSR1 einen Slave (Weiblich) RS232 Anschluss hat braucht man ein 1:1 Kabel. Außerdem muss das RTS Signal des MSR1 auf eine logische Null gelegt werden, da sich die MSR1 sonst nicht für irgendwelche Befehle interessiert. Dazu verwendet man am besten den zweiten Kanal des verbauten MAX232, legt den Eingang auf GND und greift die +10V am Ausgang ab. Ansonsten ist der RS232 Anschluss ein 9600 8N1. == Alternative Kabelbelegung == Im [http://www.bhkw-forum.de BHKW-Forum] gibt es noch eine alternative Kabelbelegung. Zu beachten ist nur, das man die Leitungen nicht kreuzen darf. (getestet mit dem AVR-Net-IO) [[Media:Kabelbelegung_Dachs_MRS1.pdf]] Die dort beschriebene Belegung ist also für PC->Dachs gedacht. Diese Variante funktioniert mit einem ethersex nur dann, wenn an der RS232 Buchse auch der RTS Kanal durch den MAX232 geschleift wird. (Und die Ethersexfirmware um RTS Handshaking erweitert wurde *huestel*) == Auslesen == Der MSR1 kann man zwei verschiedene Datensätze entlocken, den "0xe8"-Datensatz und den "0xc0"-Datensatz. Beide enthalten teilweise redundante Daten, wobei jedoch letzterer weitaus mehr Informationen bietet. Den 0xe8 Datensatz bekommt man mit dem ecmd `msr1 get' bzw. `msr1 get 0'. Das erste Byte gibt an, wieviele Anfragen seit dem letzten erfolgreichen Versuch fehlgeschlagen sind. Den 0xc0-Datensatz bekommt man über `msr1 get 1'. == Einbindung in den [[HTTPD]] == [[File:800px-Msr1_screenshot.png|600px]] │ │ Load a Default Configuration ---> │ │ ... │ │ General Setup ---> │ │ ... │ │ [*] VFS (Virtual File System) ---> │ │ [*] VFS File Inling │ │ [*] Inline MSR1 Unter '''$ethersexip/msr.ht''' kann nun der aktuelle Status des Dachs ausgelesen werden. = Programm Beispiele = == Abfrage in Perl == === e8 === '''Ein Beispiel wie die Werte e8 abgefragt und aufbereitet werden.''' <source lang="perl"> #!/usr/bin/perl -w # Abfrage der Dachs e8-Werte per esex # # kleines Beispielscript, das die e8 Wert abholt ud anschliesend aufbereitet # in Variabeln schreibt. # Das Script kann als Vorlage für eigene Entwicklungen benutzt werden. # # Autor: Lothar Schweikle-Droll # Lizenz: GPL use strict; use Net::Telnet (); my $debug=1; my $esex; my $esexip="192.168.255.90"; my $esexport="2701"; my $e8hex; my @e8hex; my $BETRIEBSSTUNDEN; my $WARTUNG; my $RL; my $VL; my $ABGAS; my $EINSCH_TEMP_SOL; my $BETRIEBSZUSTAND; my $BETRIEBSZUSTAND_SOL; my $GEN_LEISTUNG_SOL; my @SERVICE_CODE_MODUL; #Modul 0 = Leitregler my %BETRIEBSZUSTAND = ( 10=>'Störabschaltung', 11=>'Abschaltung MV1', 11=>'Abschaltung MV2', 13=>'Drehzahl<200 n. 25 sek.', 14=>'Drehzahl>200 n. 25 sek.', 15=>'Abschaltung>1 Minute', 16=>'Abschaltung>4 Minuten', 20=>'Startvorbereitung', 21=>'Starteinleitung', 22=>'Start', 23=>'1,5 sek. nach Start', 24=>'Startende', 30=>'450<Drehz<800', 32=>'Zuschaltung Generator', 33=>'Leistungsregelung runter', 34=>'Leistungsregelung hoch', 35=>'Betrieb'); my $non; &e8_esex; &wertezuweisung; ### Ab hier kann eigener Code stehen if ( $debug == 1){ &debug; } ##### Subrotinen sub e8_esex { #Dachs e8 abfrge per Telnet über den ethersex $esex = Net::Telnet->new || die "kann Ethersex nicht finden"; $esex->open(Host => $esexip, Port => $esexport, Timeout => 1); $esex->print("msr1 get 0"); ($non, $e8hex) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); #den String in ein Array wandeln @e8hex = $e8hex =~ /(..)/g; } sub wertezuweisung { $BETRIEBSSTUNDEN=hex($e8hex[1].$e8hex[2]); $WARTUNG=hex($e8hex[3]); #RL auf negative Temp prüfen if (hex($e8hex[4]) >128 ) { $RL=hex($e8hex[4])-255; }else{ $RL=hex($e8hex[4]); } #VL auf negative Temp prüfen if (hex($e8hex[5]) >128 ) { $VL=hex($e8hex[5])-255; }else{ $VL=hex($e8hex[5]); } $ABGAS=hex($e8hex[6])+15; $EINSCH_TEMP_SOL=hex($e8hex[7]); $BETRIEBSZUSTAND=$BETRIEBSZUSTAND{hex($e8hex[8])}; $GEN_LEISTUNG_SOL= sprintf("%.3f" , hex($e8hex[9])/34); #Sollwert Der Generatorleistung gerundet auf 3 Stellen nach dem Komma my $i=0; while ($i <=5 ) { $SERVICE_CODE_MODUL[$i]=hex($e8hex[$i+10]); $i++ } $BETRIEBSZUSTAND_SOL=hex($e8hex[16]); } sub debug { print "\n*********** DEBUG Start *************\n\n"; print "e8-Hexwert:","@e8hex","\n\n"; print "Betriebstundenb:\t",$BETRIEBSSTUNDEN,"\n"; print "Wartung:\t\t",$WARTUNG,"\n"; print "VL:\t\t\t",$VL,"\n"; print "RL:\t\t\t",$RL,"\n"; print "Abgas:\t\t\t",$ABGAS,"\n"; print "EINSCH_TEMP_SOL:\t",$EINSCH_TEMP_SOL,"\n"; print "Betriebszustand:\t",$BETRIEBSZUSTAND,"\n"; print "Generator Leitsung Sol:\t",$GEN_LEISTUNG_SOL,"\n"; print "BETRIEBSZUSTAND_SOL:\t",$BETRIEBSZUSTAND_SOL,"\n"; my $i=0; while ($i <=5 ) { #$SERVICE_CODE_MODUL[$i]=hex($e8sex[$i+10]); print "SERVICE_CODE_MODUL[".$i."]\t".$SERVICE_CODE_MODUL[$i],"\n"; $i++ } print "\n"; print "*********** DEBUG Ende **************\n\n"; } </source> === c0 === '''Ein Beispiel für die c0 Werte''' <source lang="perl"> #!/usr/bin/perl -w # Abfrage der Dachs c0-Werte per esex # # kleines Beispielscript, das die c0 Wert abholt ud anschliesend aufbereitet # in Variabeln schreibt. # Das Script kann als Vorlage für eigene Entwicklungen benutzt werden. # # Autor: Lothar Schweikle-Droll # Lizenz: GPL use strict; use Net::Telnet (); my $debug=1; my $esex; my $esexip="192.168.255.90"; my $esexport="2701"; my $c0hex1; my $c0hex2; my $c0hex3; my $c0hex4; my $c0hex; my @c0hex; my $WARTUNG; my $RL; my $VL; my $SRL; my $SVL; my $BETRIEBSSTUNDEN; my $ABGAS; my $AUSENTEMP; my $F1TEMP; my $F2TEMP; my $GENERTEMP; my $MOTORTEMP; my $SERVICECODE; my $BETRIEBSART; my $BHKW_FREIGABE; my $BRENNER_FREIGABE; my $DREHZAHL; my $ERZEUGTE_E_ENERGIE; my $ERZEUGT_WAERME; my $GEN_LEISTUNG; my $STARTS; my $non; &e8_esex; &wertezuweisung; ### Ab hier kann eigener Code stehen if ( $debug == 1){ &debug; } ##### Subrotinen sub e8_esex { #Dachs C0 abfrge per Telnet über den ethersex $esex = Net::Telnet->new || die "kann Ethersex nicht finden"; $esex->open(Host => $esexip, Port => $esexport, Timeout => 1); # $c0hex1=$esex->cmd('msr1 get 1'); $esex->print("msr1 get 1"); ($non, $c0hex1) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $c0hex2) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $c0hex3) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $c0hex4) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); $c0hex = ($c0hex1).($c0hex2).($c0hex3).($c0hex4); #die vier Einzelwerte zu einem gesamt String zusammensetzen @c0hex = $c0hex =~ /(..)/g; #Den String in eine Array schreiben (nur die HEX-Werte ohne Leerstellen } sub wertezuweisung { $BETRIEBSSTUNDEN=hex($c0hex[19].$c0hex[20]); $WARTUNG=$c0hex[3]; #RL auf negative Temp prüfen if (hex($c0hex[22]) >128 ) { $RL=hex($c0hex[22])-255; }else{ $RL=hex($c0hex[22]); } $SRL=hex($c0hex[21]); #VL auf negative Temp prüfen if (hex($c0hex[24]) >128 ) { $VL=hex($c0hex[24])-255; }else{ $VL=hex($c0hex[24]); } $SVL=hex($c0hex[23]); #Ausentemp auf negative Temp prüfen if (hex($c0hex[25]) >128 ) { $AUSENTEMP=hex($c0hex[25])-255; }else{ $AUSENTEMP=hex($c0hex[25]); } #F1 und F2 auf negative Temp prüfen if (hex($c0hex[26]) >128 ) { $F1TEMP=hex($c0hex[26])-255; }else{ $F1TEMP=hex($c0hex[26]); } if (hex($c0hex[27]) >128 ) { $F2TEMP=hex($c0hex[27])-255; }else{ $F2TEMP=hex($c0hex[27]); } $GENERTEMP=hex($c0hex[28]); $SERVICECODE=hex($c0hex[30]); $BETRIEBSART=$c0hex[31]; $BHKW_FREIGABE=hex($c0hex[32]); $BRENNER_FREIGABE=hex($c0hex[33]); $MOTORTEMP=hex($c0hex[34]); $ABGAS=hex($c0hex[35])+15; $DREHZAHL=hex($c0hex[36].$c0hex[37]); $ERZEUGTE_E_ENERGIE=hex($c0hex[38].$c0hex[39].$c0hex[40].$c0hex[41]); $ERZEUGT_WAERME=hex($c0hex[42].$c0hex[43].$c0hex[44].$c0hex[45]); $GEN_LEISTUNG=sprintf("%.3f" , hex($c0hex[46])/34); #Sollwert Der Generatorleistung gerundet auf 3 Stellen nach dem Komma $STARTS=hex($c0hex[47].$c0hex[48]); } sub debug { print "\n*********** DEBUG Start *************\n\n"; print "c0-Hexwert:","@c0hex","\n\n"; print "Betriebstunden:\t\t",$BETRIEBSSTUNDEN,"\n"; print "Wartung:\t\t",$WARTUNG,"\n"; print "VL:\t\t\t",$VL,"\n"; print "RL:\t\t\t",$RL,"\n"; print "F1:\t\t\t",$F1TEMP,"\n"; print "F2:\t\t\t",$F2TEMP,"\n"; print "VL Soll:\t\t",$SVL,"\n"; print "RL Soll:\t\t",$SRL,"\n"; print "Ausen:\t\t\t",$AUSENTEMP,"\n"; print "Generator Temp:\t\t",$GENERTEMP,"\n"; print "Servicecode:\t\t",$SERVICECODE,"\n"; print "Betreibsart:\t\t",$BETRIEBSART,"\n"; print "BHKW Freigabe:\t\t",$BHKW_FREIGABE,"\n"; print "Brenner Freigabe:\t",$BRENNER_FREIGABE,"\n"; print "Motor Temp:\t\t",$MOTORTEMP,"\n"; print "Abgas:\t\t\t",$ABGAS,"\n"; print "Drehzahl:\t\t",$DREHZAHL,"\n"; print "erzeugte E-Energie:\t",$ERZEUGTE_E_ENERGIE,"\n"; print "erzeugte Wärme:\t\t",$ERZEUGT_WAERME,"\n"; print "Generator ist:\t\t",$GEN_LEISTUNG,"\n"; print "Startvorgang:\t\t",$STARTS,"\n"; print "\n"; print "*********** DEBUG Ende **************\n\n"; } </source> === 48 === '''Ein Beispiel für die 48 Werte''' <source lang="perl"> #!/usr/bin/perl -w # Abfrage der Dachs 48-Werte per esex # # kleines Beispielscript, das die 48 Wert abholt ud anschliesend aufbereitet # in Variabeln schreibt. # Das Script kann als Vorlage für eigene Entwicklungen benutzt werden. # # Autor: Lothar Schweikle-Droll # Lizenz: GPL use strict; use Net::Telnet (); my $debug=1; my $esex; my $esexip="192.168.255.90"; my $esexport="2701"; my $x48hex1; my $x48hex2; my $x48hex3; my $x48hex4; my $x48hex; my @x48hex; my $WARTUNG; my $BETRIEBSSTUNDEN; my $MAXABGAS; my $VL; my $STOERUNGEN; my $F1TEMP; my $F2TEMP; my $MAXGENERTEMP; my $MAXMOTORTEMP; my $STARTS; my $MITTELGENLEISTUNG; my $FLUESSIGKEITSCHALTER; my $LETZTEWARTUNG; my $NAECHSTEWARTUNGOEL; my $NAECHSTEWARTUNGGAS; my @FEHLERCODE; #000-127 my @FEHLERAUTO; #1=Autoentstörung my @FEHLERCODELANG; my @FEHLERMIN; my @FEHLERSTUNDEN; my @FEHLERTAG; my @FEHLERMON; my @FEHLERJAHR; my @FEHLERDATUM; my $non; my %Servicecode = ( 0=>'Allgemeine Hilfe', 1=>'Abgasfühler U/K', 2=>'Kuehlw.Motor U/K', 3=>'Kuehlw.Gener. U/K', 4=>'04', 5=>'Vorlauftemp. U/K', 6=>'Ruecklauftemp U/K', 7=>'Fuehler 1 U/K', 8=>'Fuehler 2 U/K', 9=>'Aussentemp. U/K', 10=>'Fluessigkeit. U/K', 11=>'11', 11=>'12', 13=>'13', 14=>'14', 15=>'15', 16=>'16', 17=>'17', 18=>'18', 19=>'19', 20=>'Abgas Motor zu hoch', 21=>'21', 22=>'Kuehlw. Motor > 95 C', 23=>'Abgastemp. zu hoch', 24=>'Kuehlw. Generator > 77 C', 25=>'25', 26=>'2h Vorlauft < Soll', 27=>'27', 28=>'28', 29=>'UP:Rueckleistung', 30=>'30', 31=>'HKA-Anl. < 100 U/min', 32=>'32', 33=>'HKA-Lauf < 2300 U/m', 34=>'34', 35=>'35', 36=>'36', 37=>'37', 38=>'38', 39=>'Generatorzuschalt', 40=>'Generatorabschalt', 41=>'Generator fehlt', 42=>'kein Text', 43=>'kein Text', 44=>'1h Si-Kette offen', 45=>'kein Text', 46=>'kein Text', 47=>'kein Text', 48=>'UP/LP:Int. b. Start', 49=>'UP: Intern', 50=>'UP/LP: Intern', 51=>'UP:Startfreigabe', 52=>'UP:Datentransfer', 53=>'UP:keine Daten', 54=>'kein Text', 55=>'kein Text', 56=>'UP:Messk Drehzahl', 56=>'kein Text', 57=>'kein Text', 58=>'kein Text', 59=>'UP:Spannung b.St.', 60=>'UP: Spannung', 61=>'kein Text', 62=>'Leistung zu hoch', 63=>'Leistung zu klein', 64=>'Leistung im Stand', 65=>'kein Text', 66=>'ENS-3 Abschaltung', 67=>'UP:Frequenz b.St', 68=>'UP:Frequenz', 69=>'UP:Phasen', 70=>'kein Text', 71=>'Oeldruckschalter', 72=>'Oeldruckmangel', 73=>'MV/Hubmag.undicht', 74=>'MV/Hubmag.undicht', 75=>'kein Text', 76=>'Programmdurchlauf', 77=>'kein Text', 78=>'kein Text', 79=>'4 Starts < 2300 U/m', 80=>'kein Text', 81=>'kein Text', 82=>'kein Text', 83=>'kein Text', 84=>'UP:Drehfeld', 85=>'Fluessigkeitssch', 86=>'UP: Zuendaussetzer', 87=>'Drehz. > 3300 U/min', 88=>'4 Starts 400-800U/m', 89=>'4Starts < 400 U/min', 90=>'kein Text', 91=>'UP:Drehz > 3500 U/m', 92=>'UP:verriegelt', 93=>'UP/RP-Prog.falsch', 94=>'kein Text', 95=>'No ClkRAM Kommuni', 96=>'No Ack-w I2C-Bus', 97=>'No Ack-r I2C-Bus', 98=>'Clk_RAM write nOK', 99=>'UP:Flags'); &x48_esex; &wertezuweisung; ### Ab hier kann eigener Code stehen if ( $debug == 1){ &debug; } ##### Subrotinen sub x48_esex { #Dachs 48 abfrge per Telnet über den ethersex $esex = Net::Telnet->new || die "kann Ethersex nicht finden"; $esex->open(Host => $esexip, Port => $esexport, Timeout => 1); # $x48hex1=$esex->cmd('msr1 get 1'); $esex->print("msr1 get 2"); ($non, $x48hex1) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $x48hex2) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $x48hex3) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $x48hex4) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); $x48hex = ($x48hex1).($x48hex2).($x48hex3).($x48hex4); #die vier Einzelwerte zu einem gesamt String zusammensetzen @x48hex = $x48hex =~ /(..)/g; #Den String in eine Array schreiben (nur die HEX-Werte ohne Leerstellen } sub wertezuweisung { $BETRIEBSSTUNDEN=hex($x48hex[1].$x48hex[2]); $STARTS=hex($x48hex[3].$x48hex[4]); $MAXABGAS=hex($x48hex[5])+15; $MAXGENERTEMP=hex($x48hex[7]); $MAXMOTORTEMP=hex($x48hex[6]); #MAXVL auf negative Temp prüfen if (hex($x48hex[8]) >128 ) { $VL=hex($x48hex[8])-255; }else{ $VL=hex($x48hex[8]); } #Max F1 und F2 auf negative Temp prüfen if (hex($x48hex[9]) >128 ) { $F1TEMP=hex($x48hex[9])-255; }else{ $F1TEMP=hex($x48hex[9]); } if (hex($x48hex[10]) >128 ) { $F2TEMP=hex($x48hex[10])-255; }else{ $F2TEMP=hex($x48hex[10]); } $MITTELGENLEISTUNG=(7.5 / 255 * hex($x48hex[11])); $STOERUNGEN=hex($x48hex[12]); $FLUESSIGKEITSCHALTER=hex($x48hex[55]); $LETZTEWARTUNG=hex($x48hex[59].$x48hex[60]); $NAECHSTEWARTUNGOEL=hex($x48hex[59].$x48hex[60])+2700; $NAECHSTEWARTUNGGAS=hex($x48hex[59].$x48hex[60])+3500; #Fehler Code zuweisen for ($non=1;$non<=7;$non++) { $FEHLERCODE[$non]=hex($x48hex[7+(6*$non)]); $FEHLERAUTO[$non]="0"; if ( $FEHLERCODE[$non] > 127 ) { $FEHLERCODE[$non]=$FEHLERCODE[$non]-128; $FEHLERAUTO[$non]="1"; } $FEHLERCODELANG[$non]=$Servicecode{$FEHLERCODE[$non]}; $FEHLERSTUNDEN[$non]=hex($x48hex[9+(6*$non)]); if ( $FEHLERSTUNDEN[$non]=~ /^[0-9]$/ ) { $FEHLERSTUNDEN[$non]='0'.$FEHLERSTUNDEN[$non]; } $FEHLERMIN[$non]=hex($x48hex[8+(6*$non)]); if ( $FEHLERMIN[$non]=~ /^[0-9]$/ ) { $FEHLERMIN[$non]='0'.$FEHLERMIN[$non]; } $FEHLERTAG[$non]=hex($x48hex[10+(6*$non)]); if ( $FEHLERTAG[$non]=~ /^[0-9]$/ ) { $FEHLERTAG[$non]='0'.$FEHLERTAG[$non]; } $FEHLERMON[$non]=hex($x48hex[11+(6*$non)]); if ( $FEHLERMON[$non]=~ /^[0-9]$/ ) { $FEHLERMON[$non]='0'.$FEHLERMON[$non]; } $FEHLERJAHR[$non]=hex($x48hex[12+(6*$non)]); if ( $FEHLERJAHR[$non]=~ /^[0-9]$/ ) { $FEHLERJAHR[$non]='0'.$FEHLERJAHR[$non]; } $FEHLERDATUM[$non]=$FEHLERSTUNDEN[$non].":".$FEHLERMIN[$non]." ".$FEHLERTAG[$non].".".$FEHLERMON[$non].".".$FEHLERJAHR[$non]; #Deutsch ohne Sekunden $FEHLERDATUM[$non]=$FEHLERJAHR[$non]."-".$FEHLERMON[$non]."-".$FEHLERTAG[$non]." ".$FEHLERSTUNDEN[$non].":".$FEHLERMIN[$non].":30"; #International mit gemittelte Sekunden #print "HEXzahl: ".(7 + (6 * $non))."\n"; } } sub debug { print "\n*********** DEBUG Start *************\n\n"; print "48-Hexwert:","@x48hex","\n\n"; print "Betriebstunden:\t\t",$BETRIEBSSTUNDEN,"\n"; print "Letzte Wartung:\t\t",$LETZTEWARTUNG,"\n"; print "Wartung bei Öl (alle 2700h):\t",$NAECHSTEWARTUNGOEL,"\n"; print "Wartung bei Gas (alle 3500h):\t",$NAECHSTEWARTUNGGAS,"\n"; print "Starts:\t\t\t",$STARTS,"\n"; print "MAX Abgas:\t\t",$MAXABGAS,"\n"; print "MAX Gen Temp:\t\t",$MAXGENERTEMP,"\n"; print "MAX Mot Temp:\t\t",$MAXMOTORTEMP,"\n"; print "Max VL:\t\t\t",$VL,"\n"; print "Max F1:\t\t\t",$F1TEMP,"\n"; print "Max F2:\t\t\t",$F2TEMP,"\n"; print "Mittlere Gen Leistung:\t",$MITTELGENLEISTUNG,"\n"; print "Anzahl Störungen:\t",$STOERUNGEN,"\n"; print "Fluessigkeitsschalter:\t",$FLUESSIGKEITSCHALTER,"\n\n"; print "Fehlerpeicher\n"; print "=============\n"; for ($non=1;$non<=7;$non++) { print "Fehler: ".$non."\n"; print "Fehlercode: ".$FEHLERCODE[$non]."\n"; print "Autoentstörung: ".$FEHLERAUTO[$non]."\n"; print "Zeit: ".$FEHLERSTUNDEN[$non].":".$FEHLERMIN[$non]." ".$FEHLERTAG[$non].".".$FEHLERMON[$non].".".$FEHLERJAHR[$non]."\n"; print "Datum: ".$FEHLERDATUM[$non]."\n"; print "Langtext: ".$FEHLERCODELANG[$non]."\n\n"; } print "\n"; print "*********** DEBUG Ende **************\n\n"; } </source> === 50 === '''Ein Beispiel für die 50 Werte''' <source lang="perl"> #!/usr/bin/perl -w # Abfrage der Dachs 50-Werte per esex # # kleines Beispielscript, das die 50 Wert abholt ud anschliesend aufbereitet # in Variabeln schreibt. # Das Script kann als Vorlage für eigene Entwicklungen benutzt werden. # # Autor: Lothar Schweikle-Droll # Lizenz: GPL use strict; use constant PI => 4 * atan2(1, 1); #Wegen cosph Berechnung use Net::Telnet (); my $debug=1; my $esex; my $esexip="192.168.255.90"; my $esexport="2701"; my $x50hex1; my $x50hex2; my $x50hex3; my $x50hex4; my $x50hex; my @x50hex; my $RL; my $VL; my $MOTORTEMP; my $ABGAS; my $AUSENTEMP; my $F1TEMP; my $F2TEMP; my $GENERTEMP; my $DREHZAHL; my $BIVAL_UMSCHALT_TMP; my $BIVAL_UMSCHALT_ZEIT; my $SERVICE; my $UMWALZPUMPESTATUS1; my $UMWALZPUMPESTATUS2; my $U1; my $U2; my $U3; my $I1; my $I2; my $I3; my $COSPHI; my $UE_PLATINE; my $non; &e8_esex; &wertezuweisung; ### Ab hier kann eigener Code stehen if ( $debug == 1){ &debug; } ##### Subrotinen sub e8_esex { #Dachs C0 abfrge per Telnet über den ethersex $esex = Net::Telnet->new || die "kann Ethersex nicht finden"; $esex->open(Host => $esexip, Port => $esexport, Timeout => 1); # $x50hex1=$esex->cmd('msr1 get 1'); $esex->print("msr1 get 3"); ($non, $x50hex1) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $x50hex2) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $x50hex3) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $x50hex4) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); $x50hex = ($x50hex1).($x50hex2).($x50hex3).($x50hex4); #die vier Einzelwerte zu einem gesamt String zusammensetzen @x50hex = $x50hex =~ /(..)/g; #Den String in eine Array schreiben (nur die HEX-Werte ohne Leerstellen } sub wertezuweisung { #VL auf negative Temp prüfen if (hex($x50hex[1]) >128 ) { $VL=hex($x50hex[1])-255; }else{ $VL=hex($x50hex[1]); } #RL auf negative Temp prüfen if (hex($x50hex[2]) >128 ) { $RL=hex($x50hex[2])-255; }else{ $RL=hex($x50hex[2]); } $MOTORTEMP=hex($x50hex[3]); $ABGAS=hex($x50hex[4])+15; #Ausentemp auf negative Temp prüfen if (hex($x50hex[5]) >128 ) { $AUSENTEMP=hex($x50hex[5])-255; }else{ $AUSENTEMP=hex($x50hex[5]); } #F1 und F2 auf negative Temp prüfen if (hex($x50hex[6]) >128 ) { $F1TEMP=hex($x50hex[6])-255; }else{ $F1TEMP=hex($x50hex[6]); } if (hex($x50hex[7]) >128 ) { $F2TEMP=hex($x50hex[7])-255; }else{ $F2TEMP=hex($x50hex[7]); } $GENERTEMP=hex($x50hex[8]); $ABGAS=hex($x50hex[4])+15; $DREHZAHL=hex($x50hex[10].$x50hex[11]); $BIVAL_UMSCHALT_TMP=hex($x50hex[13]); $BIVAL_UMSCHALT_ZEIT=hex($x50hex[14].$x50hex[15]); #Wert in Minuten $SERVICE=hex($x50hex[16]); $UMWALZPUMPESTATUS1=hex($x50hex[21]); $UMWALZPUMPESTATUS2=hex($x50hex[21]); $U1=105.6 + (100.0 / 461) * (hex($x50hex[31].$x50hex[32])); #105.6V + (100.0 /0x1cd) * Wert $U2=314.4 - (100.0 / 461) * (hex($x50hex[33].$x50hex[34])); #314.4V - (100.0 /0x1cd) * Wert $U3=105.6 + (100.0 / 461) * (hex($x50hex[35].$x50hex[36])); #105.6V + (100.0 /0x1cd) * Wert $I1=hex($x50hex[37].$x50hex[38]) * (10.0 / 461) - (10.0 * 205) / 461 ; #Wert * (10.0A /0x1cd) - (10.0*0xcd)/0x1cd $I2=hex($x50hex[39].$x50hex[40]) * (10.0 / 461) - (10.0 * 205) / 461; #Wert * (10.0A /0x1cd) - (10.0*0xcd)/0x1cd $I3=10.0 / 461 * (757 - (hex($x50hex[41].$x50hex[42]))); #10.0A/0x1cd * (0x02f5 - Wert) #$x50hex[43]='C9'; $COSPHI=abs( cos(((hex($x50hex[43]))-128)*PI/180) ); if (hex($x50hex[45]) >= 253 ) { $UE_PLATINE='ok'; }else{ $UE_PLATINE='error'; } } sub debug { print "\n*********** DEBUG Start *************\n\n"; print "50-Hexwert:","@x50hex","\n\n"; print "VL:\t\t\t",$VL,"\n"; print "RL:\t\t\t",$RL,"\n"; print "Motor Temp:\t\t",$MOTORTEMP,"\n"; print "Abgas:\t\t\t",$ABGAS,"\n"; print "F1:\t\t\t",$F1TEMP,"\n"; print "F2:\t\t\t",$F2TEMP,"\n"; print "Generator Temp:\t\t",$GENERTEMP,"\n"; print "Drehzahl:\t\t",$DREHZAHL,"\n"; print "BIVAL_UMSCHALT_TMP:\t",$BIVAL_UMSCHALT_TMP,"\n"; print "BIVAL_UMSCHALT_ZEIT:\t",$BIVAL_UMSCHALT_ZEIT,"\n"; print "U1:\t\t\t",$U1," ",hex($x50hex[31].$x50hex[32]),"\n"; print "U2:\t\t\t",$U2," ",hex($x50hex[33].$x50hex[34]),"\n"; print "U3:\t\t\t",$U3," ",hex($x50hex[35].$x50hex[36]),"\n"; print "I1:\t\t\t",$I1," ",hex($x50hex[37].$x50hex[38]),"\n"; print "I2:\t\t\t",$I2," ",hex($x50hex[39].$x50hex[40]),"\n"; print "I3:\t\t\t",$I3," ",hex($x50hex[41].$x50hex[42]),"\n"; print "COSPHI:\t\t\t",$COSPHI," ",hex($x50hex[43]),"\n"; print "UE_PLATINE:\t\t",$UE_PLATINE," ",hex($x50hex[45]),"\n"; print "UMWALZPUMPESTATUS1:\t",$UMWALZPUMPESTATUS1,"\n"; print "UMWALZPUMPESTATUS2:\t",$UMWALZPUMPESTATUS2,"\n"; print "\n"; print "*********** DEBUG Ende **************\n\n"; } </source> [[Category:Ethersex]] [[Category:Home-Visualisierung]] [[Category:MSR1]] d6612c1b1d0e8d4e36bf130df1d9e6ea509ccc5b 10 52 190 2011-11-11T21:10:43Z Schronk 341 Created page with "<noinclude>{{i18n|Template:NewWiki}}</noinclude> {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#FFAF4D; border:4px #aaa solid; font-size:95%; color:black; …" wikitext text/x-wiki <noinclude>{{i18n|Template:NewWiki}}</noinclude> {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#FFAF4D; border:4px #aaa solid; font-size:95%; color:black; width:auto%; padding: 15px; font-size: 15px" |- |[[Image:Applications-development.svg]] |'''Willkommen im neuen Wiki des Ethersex-Projekts.''' Dieses Wiki ist noch lange nicht fertig. Bitte hilf uns, indem du dein Wissen hier einbringst. Auf der Suche nach dem alten Wiki? [http://old.ethersex.de Go to old.ethersex.de] |- |} e82c6f61a28faccb26ae6f0a61f4f4fdec7e30ff 10 53 191 2011-11-11T21:14:19Z Schronk 341 Created page with "<noinclude>{{i18n|Template:Getting Started}}</noinclude> {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color…" wikitext text/x-wiki <noinclude>{{i18n|Template:Getting Started}}</noinclude> {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | colspan=2 style="background-color: #FFFFFF; text-align: center; border-bottom:1px solid #aaaaaa;" | '''Einstieg''' |- | * [[Quick Start Guide|Erste Schritte]] * [[Community]] * [[Contributing|Mitmachen]] |} 15f63fb466ba6fd1b52ca570e4e46d9e13dd7024 192 191 2011-11-11T21:26:49Z Schronk 341 Links für Weiterleitung auf die deutschen Seiten korrigiert wikitext text/x-wiki <noinclude>{{i18n|Template:Getting Started}}</noinclude> {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | colspan=2 style="background-color: #FFFFFF; text-align: center; border-bottom:1px solid #aaaaaa;" | '''Einstieg''' |- | * [[Quick Start Guide (Deutsch)|Erste Schritte]] * [[Community (Deutsch)|Community]] * [[Contributing (Deutsch)|Mitmachen]] |} b09bf222d7ff08d64924f2faf8f0de8f0962c0e3 0 54 193 2011-11-11T21:55:07Z Schronk 341 Created page with "{{i18n|Wiki Guidelines}} == Sprachen == Das ist ein internationales Wiki. Bitte füge die folgende Codezeile in jede Seite ein, die du erstellst. {{Codeline|<nowiki>{{i18n|TIT…" wikitext text/x-wiki {{i18n|Wiki Guidelines}} == Sprachen == Das ist ein internationales Wiki. Bitte füge die folgende Codezeile in jede Seite ein, die du erstellst. {{Codeline|<nowiki>{{i18n|TITLE}}</nowiki>}} Ersetze TITLE durch den Titel der Seite, die du bearbeitest. Das fügt die Sprachauswahlzeile ein, die du oben siehst. Wenn du eine Seite übersetzen möchtest, klicke einfach auf die gewünschte Sprache und starte mit der Bearbeitung. Stell bitte sicher, dass du auch hier das Sprachen-Template einfügst. == Module == Wenn du ein Modul dokumentieren möchtest, nutze bitte das [[Template:Module (Deutsch)|Modul-Template]]. [[IRMP (Deutsch)|Hier]] ein Beispiel für ein gut dokumentiertes Modul. Bitte nutze als Titel den Name des Moduls im menuconfig oder die Bezeichnung wie im Quellcode (z.B. Ordnername). Wähle bitte keinen Titel der nicht mit einem der beiden übereinstimmt. == Weitere Regeln == * Vermeide es bitte, alle Informationen, die mit einem Modul im Zusammenhang stehen, auf eine Seite zu packen. Erzeuge Unterseiten für Beispiele und spezielle Einstellungen. 0020b85eecd946ec78bfb95871fa37310047c8ec 10 55 194 2011-11-11T22:02:15Z Schronk 341 Created page with "<noinclude>{{i18n|Template:Documentation}}</noinclude> {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:b…" wikitext text/x-wiki <noinclude>{{i18n|Template:Documentation}}</noinclude> {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | colspan=2 style="background-color: #FFFFFF; text-align: center; border-bottom:1px solid #aaaaaa;" | '''Dokumentation''' |- | [[Wiki Guidelines (Deutsch)|Wiki Richtlinien]] ---- * [[:Category:Hardware (Deutsch)|Hardware Treiber]] * [[:Category:Protocol (Deutsch)|Protokoll Support]] * [[:Category:Application (Deutsch)|Dienste und Applikationen]] * [[ECMD Reference|ECMD Befehlssatz]] |} 61f201919c6dd22dc3fee0148b876457ce825eee 10 56 195 2011-11-11T22:26:39Z Schronk 341 Created page with "<noinclude>{{i18n|Template:Facts}}</noinclude> {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; wid…" wikitext text/x-wiki <noinclude>{{i18n|Template:Facts}}</noinclude> {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | colspan=2 style="background-color: #FFFFFF; text-align: center; border-bottom:1px solid #aaaaaa;" | '''Überblick''' |- |Ethersex eine Firmware mit Netzwerkunterstützung für 8-bit AVR Mikrokontroller, die durch eine Community entwickelt wird. {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- !style="width:50%" | Features !style="width:50%" | Unterstützte Boards |- | * unterstützt Atmega 8,16,32,64,128,644 und viele mehr * nutzt den Ethernet-Controller '''ENC28J60''' * leicht anzupassen und zu erweitern um deine Anforderungen zu erfüllen Protokolle: * TCP/IP IPv4/'''IPv6''' * OpenVPN * Software USB stack * RFM12 (433 MHz) * '''i²c''' Master (Untersützung zahlreicher Chips) / Slave * onewire * http server * kann mit dem '''Ethersex Command Protocol (ECMD)''' ferngesteuert werden * [[Features (Deutsch)|und viele mehr]] | * NetIO (Pollin) * Etherrape (lochraster.org) * AVR Module (Ulrich Radig) * Jackalope (lochraster.org) * Probot (Conrad) * Fimser (OV Lennestadt) * JeeLink v2 (JeeLabs) * Funk-AVR-Evaluationsboard (Pollin) * TODO: Custom Board * [[Supported Boards (Deutsch)|und viele mehr]] |} |} d5d66429955ac0555b767985bf9d98501e49cfe7 205 195 2011-11-22T21:24:34Z Weef 314 added RFM12B and frequ 868 MHz wikitext text/x-wiki <noinclude>{{i18n|Template:Facts}}</noinclude> {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | colspan=2 style="background-color: #FFFFFF; text-align: center; border-bottom:1px solid #aaaaaa;" | '''Überblick''' |- |Ethersex eine Firmware mit Netzwerkunterstützung für 8-bit AVR Mikrokontroller, die durch eine Community entwickelt wird. {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- !style="width:50%" | Features !style="width:50%" | Unterstützte Boards |- | * unterstützt Atmega 8,16,32,64,128,644 und viele mehr * nutzt den Ethernet-Controller '''ENC28J60''' * leicht anzupassen und zu erweitern um deine Anforderungen zu erfüllen Protokolle: * TCP/IP IPv4/'''IPv6''' * OpenVPN * Software USB stack * RFM12 / RFM12B (433 MHz / 868 MHz) * '''i²c''' Master (Untersützung zahlreicher Chips) / Slave * onewire * http server * kann mit dem '''Ethersex Command Protocol (ECMD)''' ferngesteuert werden * [[Features (Deutsch)|und viele mehr]] | * NetIO (Pollin) * Etherrape (lochraster.org) * AVR Module (Ulrich Radig) * Jackalope (lochraster.org) * Probot (Conrad) * Fimser (OV Lennestadt) * JeeLink v2 (JeeLabs) * Funk-AVR-Evaluationsboard (Pollin) * TODO: Custom Board * [[Supported Boards (Deutsch)|und viele mehr]] |} |} 19afa2480cbd4b9dbebfa628451b639a77f045d8 0 57 196 2011-11-11T22:28:58Z Schronk 341 Created page with "{{i18n|Main Page}} {{NewWiki (Deutsch)}} == Willkommen bei ethersex.de - der universalen AVR Firmware == {{Facts (Deutsch)}} {|style="width:100%" |style="width:50%"|{{Getting St…" wikitext text/x-wiki {{i18n|Main Page}} {{NewWiki (Deutsch)}} == Willkommen bei ethersex.de - der universalen AVR Firmware == {{Facts (Deutsch)}} {|style="width:100%" |style="width:50%"|{{Getting Started (Deutsch)}} |style="width:50%"|{{Documentation (Deutsch)}} |- |} 1c3a81ad2fb9bacd3b1d0a82f6117c238294a6b3 0 58 197 2011-11-11T22:49:31Z Schronk 341 Created page with "{{i18n|Quick Start Guide}} === Lade den Quellcode von GITHUB herunter === Du kannst Ethersex von github über das Git-Protokoll herunterladen git clone git://github.com/ethers…" wikitext text/x-wiki {{i18n|Quick Start Guide}} === Lade den Quellcode von GITHUB herunter === Du kannst Ethersex von github über das Git-Protokoll herunterladen git clone git://github.com/ethersex/ethersex.git oder über http git clone http://github.com/ethersex/ethersex.git Das Hochladen einer neuen Version von Ethersex ist möglich mit: git pull origin === Vorraussetzungen === * AVR GCC-Compiler (Version 4.1 oder höher) * AVR LIBC (Version 1.6.8, für 128er ATMegas 1.7) * GNU-Tools (Bash, Make, m4, awk) * AVR-Programmer (z.B. avrdude) == Linux Debian / Ubuntu == apt-get install gcc-avr avr-libc binutils-avr m4 gawk libncurses5-dev make dialog git-core avrdude == Mac OSX == TODO (Übersetzung) Using [http://www.macports.org MacPorts] Apple Bash and sed doesn't work, you need to install Bash V4.0 and GNU sed. First, sync the Port Repository to ensure that you´ll build the latest versions of the requirements. port selfupgrade port install git-core avrdude avr-binutils avr-gcc avr-libc bash sed Du kannst auch [http://www.obdev.at/products/crosspack/index-de.html CrossPack] nutzen, aber MacPorts ist unkomplizierter und wird geupdated. ed43e0ced3f8cf6fcd9e87b3f9ed30fd42391203 0 59 198 2011-11-11T23:04:28Z Schronk 341 Created page with "{{i18n|Community}} = Email-Verteiler = *[http://list.zerties.org/cgi-bin/mailman/listinfo/ethersex-devel ethersex-devel] *[https://list.zerties.org/cgi-bin/mailman/listinfo/ether…" wikitext text/x-wiki {{i18n|Community}} = Email-Verteiler = *[http://list.zerties.org/cgi-bin/mailman/listinfo/ethersex-devel ethersex-devel] *[https://list.zerties.org/cgi-bin/mailman/listinfo/ethersex-commit ethersex-commit] = IRC = Du findest uns auf [irc://freenode.net/#ethersex #ethersex] (freenode.net) Wenn du irgend eine Frage hast ... frag einfach! Falls nicht sofort jemand antwortet, nimm es nicht persönlich. Es könnte sein, dass gerade niemand von uns vor dem Computer sitzt. Schau einfach später nochmal vorbei. b0382fd562a8b4a6edfdbfa1683c2affec6054ff 0 40 199 138 2011-11-11T23:15:58Z Schronk 341 /* Languages */ wikitext text/x-wiki {{i18n|Wiki Guidelines}} == Languages == This is an international wiki. Please include this on every page you create: {{Codeline|<nowiki>{{i18n|TITLE}}</nowiki>}} Replace TITLE with the title of the page you are editing. This will insert a language bar like the one you can see above. If you want to translate a page, simply click on the language and start editing. Make sure that you include the language template as well. == Modules == If you want to document a module, please make use of the [[Template:Module | Module Template]]. A well documented module should look similar to [[IRMP | this ]]. For the title, please use the name of the module in menuconfig or how it is called in the code (e.g. the folder name). Please do not chose a title that doesn't match with either one of these. == More rules == * Refrain from putting all information related to a module into one single page. Create subpages for examples and specific setups. db5616c3dc98ce8a68acd358e1dc5ee7d7694328 0 35 218 217 2011-11-27T15:26:21Z GooPie4o 265 /* Current TODO List */ wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or any other incompatible licesne. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or any other incompatible license. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || NO |- |Riegel, Roland || NO || NO || NO || NO || NO |- |} == Current TODO List == * collect files with incompatible license. {| border="1" ! File !! License !! Status |- | core/gui/font.c || 3-clause BSD || OK |- | core/host/host.h || unknown || |- | core/host/util/crc16.h || unknown || |- | core/setbaud.h || unknown || |- | hardware/ir/irmp/irmp_lib.c || GPLv2+ || OK |- | hardware/lcd/s1d15g10/bunnies.h || unknown || |- | hardware/lcd/ST7626/4x6.h || unknown || |- | hardware/lcd/ST7626/ST7626.h || unknown || |- | hardware/sram/sram.h || unknown || |- | hardware/storage/sd_reader/byteordering.* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/fat* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/partition* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/sd_raw* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/sd-reader_config.h || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | protocols/bootp/bootphdr.h || unknown || |- | protocols/uip/uip-conf.h || unknown || |- | protocols/usb/usbconfig.h || GPLv2 || critical, see [http://www.obdev.at/products/vusb/license-de.html link] |- | protocols/ustream/vs1053.c || unknown || contacted 4.11.11, replied - agreed on MIT |- | protocols/ustream/vs1053.h || unknown || contacted 4.11.11, replied - agreed on MIT |- | services/glcdmenu/menu-interpreter/menudata-progmem.c || unknown || contacted 4.11.11, generated code - no need to license |- | services/glcdmenu/menu-interpreter/menu-interpreter-config.h || unknown || contacted 4.11.11, generated code - no need to license |- |} to find out all the authors of a certain file, run ''contrib/license-lister file'' . e.g. ''contrib/license-lister protocols/bootp/bootphdr.h'' * send an email to authors of source files with incompatible license == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD * Adam Dunkels' uIP Stack is licensed under the BSD http://en.wikipedia.org/wiki/UIP_(micro_IP) https://github.com/ethersex/ethersex/blob/master/protocols/uip/uip.c#L25 * MIT/X is compatible with GPLv3 ** http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing * reintegrate SD Reader library from http://www.roland-riegel.de/sd-reader/ ** done https://github.com/ethersex/ethersex/commit/0ba2a832b2f0e16e78cb26202b5e4fe4e266614b 2055828bacba500e62a32ba34bad9365a1efe4bb 1 81 227 2011-12-01T07:11:54Z GooPie4o 265 Created page with "Leider ist in der Formatierung der Seite etwas schief gegangen. Bitte korrigieren." wikitext text/x-wiki Leider ist in der Formatierung der Seite etwas schief gegangen. Bitte korrigieren. afc05ab8977ef1fa683443fc052275947185a384 0 43 236 170 2011-12-02T12:42:08Z LadySM 0 Importing text file wikitext text/x-wiki <div class="errorbox"> This page is automatically generated from the files in the Ethersex source code repository. Do not edit this page but send [[patches]] for those files! </div> __NOTOC__ == Analog/Digital Conversion ([[ADC]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | adc get [CHANNEL] | Get the ADC value in hex of CHANNEL or if no channel set of all channels. |- | hr20 temp | Read HR20 temperature sensor. |- |} == DNS Resolver == {| border='1' | ''Command syntax'' | ''Short description'' |- | dns server [IPADDR] | Display/Set the IP address of the DNS server to use to IPADDR. |- | nslookup HOSTNAME | Do DNS lookup for HOSTNAME (call twice). |- |} == Digital/Analog Conversion ([[DAC]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ltc1257_delay `[VALUE] | Set (if VALUE given) or get (no VALUE) delay for LTC1257 output bit changes in µs' |- | ltc1257_set `[VALUE0] [VALUE1] ... | Set output to value (value: 0-4095)' |- | tlc5620 `[CHANNEL] [VALUE] | Set Output to value (Value: 0-0xff)' |- |} == Fnordlicht == {| border='1' | ''Command syntax'' | ''Short description'' |- | fnordlicht "ADDRESS RED | GREEN,BLUE",fnordlicht command to set RGB color |- | fnordlicht_init | fnordlicht init |- |} == HD44780 [[LCD]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | hr20 hourbar START STOP | Update hourbar to show ticks between START and STOP (range 0..23) |- | hr20 toggle SEG | Toggle segment SEG (a number, not a symbolic name!) |- | lcd backlight STATE | switch back light STATE to ON or OFF |- | lcd char N D1 D2 D3 D4 D5 D6 D7 D8 | Define use-definable char N with data D1..D8 (provide DATA in hex) |- | lcd clear [LINE] | Clear line LINE (0..3) or the whole display (if parameter is omitted) |- | lcd goto LINE COL | Move cursor to LINE and column COL (origin is 0/0) |- | lcd reinit CURSOR BLINK | Reinitialize the display, set whether to show the cursor (CURSOR, 0 or 1) and whether the cursor shall BLINK |- | lcd shift DIR | Shift the display to DIR (either ''left'' or ''right'') |- | lcd write TEXT | Write TEXT to the current cursor location |- |} == Infrared Send/Receive ([[IR-TRX]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ir receive | receive an IR command |- | ir send DEVICE COMMAND | send COMMAND to DEVICE |- |} == Infrared Send/Receive ([[IRMP]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | irmp receive | receive an IR command |- | irmp send PROTOCOL DEVICE COMMAND REPEAT | send COMMAND with REPEAT flag to DEVICE using PROTOCOL |- |} == NTP Client == {| border='1' | ''Command syntax'' | ''Short description'' |- | ntp query | Query the NTP server to get an NTP update. |- | ntp server [IPADDR] | Display/Set the IP address of the NTP server to use to IPADDR. |- | ntp status | Display NTP server status |- |} == Network configuration == {| border='1' | ''Command syntax'' | ''Short description'' |- | enc dump | Dump the internal state of the enc to serial |- | gw [IP] | Display/Set the address of the default router. |- | ip [IP] | Display/Set the IP address. |- | mac [xx:xx:xx:xx:xx:xx] | Display/Set the MAC address. |- | netmask [IP] | Display/Set the network mask. |- |} == Port I/O == {| border='1' | ''Command syntax'' | ''Short description'' |- | io get ddr PORTNUM | Display the current value of the DDR PORTNUM. |- | io get mask PORTNUM | Display the mask of the port PORTNUM. |- | io get pin PORTNUM | Display the current value of the PIN-register of the port PORTNUM. |- | io get port NUM | Display the current value of the PORT NUM. |- | io set ddr PORTNUM HEXVALUE [MASK] | Set the DDR of port PORTNUM to VALUE (possibly using the provided MASK). |- | io set port NUM HEXVALUE [MASK] | Set the PORT NUM to VALUE (possibly using the provided MASK). |- |} == Reading and Writing EEPROM Space on Device == {| border='1' | ''Command syntax'' | ''Short description'' |- | eer eer <ADDR> <LENGTH> | Read n bytes from address after the config in eeprom. |- | eew eew <ADDR> <HEXBYTES> | Write Hexbytes at address after the config in epprom. |- | fuse | Display current fuse settings |- | hostname | Display hostname. |- |} == Resetting the controller == {| border='1' | ''Command syntax'' | ''Short description'' |- | bootloader | Call the bootloader. |- | reset | Reset the Ethersex. |- | wdreset | Go into endless loop to trigger a watchdog timeout. |- |} == [[ADS]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | ads get | Get the ADC value in hex. |- | ads mean [COUNT] | Get the mean of power of 2 COUNT ADC values in hex. |- |} == [[Am_Puls_der_Zeit|Clock]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | date | Display the current date. |- | lastdcf | Display when last valid DCF Signal was received. |- | time [UNIXTIME] | Display/Set the current time in seconds since January 1st 1970. |- | uptime | Display ethersex uptime in unix format. |- | whm | Display ethersex uptime. |- |} == [[Application_Sample]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sample | Manually call application sample commands |- | sample_init | Manually call application sample init method |- | sample_periodic | Manually call application sample periodic method |- |} == [[Blinkenlights_MCUF|MCUF]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | mcuf modul N | Select module N |- | mcuf modul list | List all modules |- | mcuf showclock | Show digital clock |- | mcuf showstring MESSAGE | Show scrolling MESSAGE on the display |- |} == [[CRON-Dienst]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | cron_add MIN HOUR DAY MONTH DOW ECMD | Add ECMD to cron to be executed at given time |- | cron_list | Show all cron entries |- | cron_make_persistent | Mark a Job as persistent |- | cron_rm POSITION | Remove one cron entry |- | cron_save | Saves all persistent jobs |- |} == [[DALI]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dali cmd [TARGET] [COMMAND] [!][?] | "send the given command (decimal) to targets (all, g00 to g15, s00 to s63), auto repeat with !, read reply with ?" |- | dali dim [TARGET] [LEVEL] | "dim targets (all, g00 to g15, s00 to s63) to given level (0-254)" |- | dali raw [BYTE1] [BYTE2] | "send a raw frame (two bytes, given in hex) over the DALI bus" |- | dali scmd [SPECIAL COMMAND] [DATA] [!][?] | "send special command (256-287) with data, auto repeat with !, read reply with ?" |- |} == [[DMX_Effect]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx rainbow | switch rainbow on (1) or off (0) |- | dmx random | switch random on (1) or off (0) |- |} == [[DMX_FXSlot]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx fxslot devices | set the device settings |- | dmx fxslot effect | set the effect settings |- |} == [[DMX_Storage]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx channels | Get channels per universe |- | dmx get | Return channel value |- | dmx set | Set channel values |- | dmx universe | Get a whole universe |- | dmx universes | Get universes |- |} == [[Dallas_1-wire_Bus]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | 1w convert [DEVICE] | Trigger temperature conversion of either DEVICE or all connected devices |- | 1w ds2450 convert [DEVICE] | `start conversion (with optional input mask and read out control)' |- | 1w ds2450 get [DEVICE] | `get conversion result (one or all channels)' |- | 1w ds2450 oc [DEVICE] | `get/set output control (per channel)' |- | 1w ds2450 oe [DEVICE] | `get/set output enable (per channel)' |- | 1w ds2450 por [DEVICE] | `get/set power on reset (per channel)' |- | 1w ds2450 power [DEVICE] | `get/set power supply of device (global)' |- | 1w ds2450 range [DEVICE] | `get/set input voltage range (per channel)' |- | 1w ds2450 res [DEVICE] | `get/set bit resolution of AD convert (per channel)' |- | 1w get DEVICE | Return temperature value of onewire DEVICE (provide 64-bit ID as 16-hex-digits) |- | 1w list | Return a list of the connected onewire devices |- |} == [[DataFlash]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | df status | Display internal status. |- | fs format | Format the filesystem. |- | fs inspect inode INODE | Inspect INODE (and associated page). |- | fs inspect node NODE | Inspect NODE and dump to serial. |- | fs list | List the directory. |- | fs mkfile NAME | Create a new file NAME. |- | fs remove NAME | Delete the file NAME. |- | fs truncate NAME LEN | Truncate the file NAME to LEN bytes. |- |} == [[Dc3840_camera|DC3840 mobil camera support]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dc3840 capture | Take a picture. Access 'dc3840' via VFS afterwards. See [[DC3840 Camera]] for details. |- | dc3840 light | Light level of camera |- | dc3840 send A B C D E | Send provided command bytes to the camera. |- | dc3840 sync | Re-sync to the camera |- | dc3840 zoom | Enable zoom of camera |- |} == [[ECMDScript]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | call FILENAME | Start script named FILENAME |- | cat FILENAME | cat file content (with debug only) |- | dec VAR | Decrement variable VAR (a number) |- | echo <any> | Print out all arguments of echo |- | exit | Exit currently running script |- | get VAR | Get value of variable VAR |- | goto N | Goto line N in currently running script |- | if ( CMD/VAR == CONST ) then CMD2 | If condition matches execute CMD2 |- | inc VAR | Increment variable VAR (a number) |- | rem <any> | Remark for anything |- | set VAR VALUE | Set variable VAR to VALUE |- | wait I | Wait I milliseconds |- |} == [[FS20]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fht send HOUSECODE ADDR CMD [CMD2] | Send FHT command. See [[FS20]] for details. |- | fs20 receive | Receive FS20/FHT sequence and display it. |- | fs20 send HOUSECODE ADDR CMD [CMD2] | Send FS20 command. See [[FS20]] for details. |- | fs20 ws300 | Receive FS20 sequence from WS300 weather station and decode it. |- |} == [[Frequency Counter]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fc %duty [CHANNEL] | "returns last on duty cycle in percent for given channel" |- | fc duty [CHANNEL] | "returns last on duty cycle (0-255) for given channel" |- | fc freq [CHANNEL] | "returns last frequency in Hz for given channel" |- | fc off [CHANNEL] | "switch off frequency counting on given channel" |- | fc on [CHANNEL] | "switch on frequency counting on given channel" |- | fc ticks [CHANNEL] | "returns last frequency in CPU ticks for given channel" |- |} == [[GLCD_Menu]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | glcdmenu key VALUE | Send a keypress to the menu |- | glcdmenu update | Update the menu |- |} == [[GPS]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | nmea get | Get latitude and longitude data |- | nmea satellites | Get satellites |- |} == [[H-Bridge]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | hbridge [action] [enable_l] [enable_r] | Set H-Bridge command |- | hbridge pwm int | Set H-Bridge enable line valueeg. speed |- |} == [[I2C]] (TWI) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ds1631 convert ADDR VALUE | Initiate temperature conversions (0: stop, 1: convert) |- | ds1631 temp ADDR | Read last converted temperature |- | i2c detect | list detected I2C Chips |- | i2c rbb ADDR | read byte from I2C chip |- | i2c rbd CHIPADDR REGADDR | read byte from register address at I2C chip |- | i2c rwd CHIPADDR REGADDR | read word from register address at I2C chip |- | i2c wbb ADDR HEXVALUE | write byte to I2C chip |- | i2c wbd CHIPADDR REGADDR HEXVALUE | write byte to register address on I2C chip |- | i2c wwd CHIPADDR REGADDR HEXVALUE | write word to register address on I2C chip |- | lm75 ADDR | Get temperature |- | max7311 getDDRw ADDR | Get Direction-Register DDR |- | max7311 getINw ADDR | Get Input-Register IN |- | max7311 getOUTw ADDR | Get Output-Register OUT |- | max7311 pulse ADDR BIT TIME | Toggle Output-BIT for TIME (in ms) |- | max7311 set ADDR BIT VALUE | Set Output-BIT to VALUE (bool) |- | max7311 setDDRw ADDR VALUE | Set Direction-Register DDR (VALUE as hex) |- | max7311 setOUTw ADDR VALUE | Set Output-Register OUT (VALUE as hex) |- | pca9531 ADDR PERIODPWM1 DUTYPWM1 PERIODPWM2 DUTYPWM2 LED0..3 LED4..7 | set PWM1 and PWM2 and LED states |- | pca9685m ADDR | OUTDRV, IVRT, PRESCALE |- | pca9685s ADDR | LED, ON, OFF |- | pcf8574x read ADDR CHIP | Get bits |- | pcf8574x set ADDR CHIP HEXVALUE | Set bits |- | tsl2550 lux | Show light level by reading adc registers and computing level |- | tsl2550 mode VALUE | Set the TSL2550s operating mode (0: standard range, 1: extended range) |- | tsl2550 power VALUE | Set the TSL2550s power state (0: down, 1:up) |- |} == [[Jabber]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | jabber_host [HOSTNAME] | JABBER hostname |- | jabber_pass [PASSWORD] | JABBER password |- | jabber_resrc [RESOURCE] | JABBER resource |- | jabber_user [USERNAME] | JABBER username |- |} == [[KTY]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | kty autocalibrate CHANNEL | Calibrate to 1000 Ohm precision Resistor. |- | kty cal get | Return the calibration difference to 2k2 Resistor. |- | kty get [CHANNEL] | Get the temperature in xxx.x °C of CHANNEL or if no channel set of all channels. |- |} == [[MotorCurtain]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | curtain VALUE | Set value of curtain. 0=closed..7=open. If you use fewer sensors, use the corrent value instead of 7. |- | curtainlast | Return last known position |- | curtainmax | Return maximum position |- | curtainoff | Switch motor off |- |} == [[Named_PIN]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | pin get NAME | Read and display the status of pin NAME. |- | pin list | List all known named-pins. |- | pin set NAME STATUS | Set the status of pin NAME to STATUS. |- | pin toggle NAME | Toggle the status of pin NAME. |- |} == [[PWM]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dtmf CHARS | send CHARS as DTMF |- | freq set FREQUENCY DELAY | Set frequency for DELAY ms |- | pwm fade [channel +-diff startvalue] | Set fading at channel with startvalue and change each stepp to diff (must be signed 3 digit) |- | pwm set [channel value] | Set channel to value |- |} == [[RFM12]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | rfm12 reinit | Re-initialize RFM12 module. |- | rfm12 setbandwidth BW | Set RX bandwidth to BW. |- | rfm12 setbaud BAUD | Set baudrate to BAUD. |- | rfm12 setdrssi DRSSI | Set the drssi to DRSSI. |- | rfm12 setgain GAIN | Set preamplifier gain to GAIN. |- | rfm12 setmod MOD | Set modulation to MOD. |- | rfm12 status | Display internal status. |- |} == [[RFM12_ASK]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | rfm12 1527 | housecodeCommand delay cnt |- | rfm12 2272 | housecodeCommand delay cnt |- | rfm12 ask sense | Trigger (Tevion) ASK sensing. Enable ext. filter pin before! |- | rfm12 external filter [1] | Enable ext. filter pin if argument is present (disable otherwise) |- | rfm12 intertechno | family group device command |- | rfm12 tevion | housecode command delay cnt |- |} == [[SD-Karte]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sd dir | List contents of current SD directory. |- | sd mkdir PATH | Create directory hierarchy PATH. |- |} == [[SHT]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sht humid | Return humidity of SHT sensor |- | sht raw | Return raw hex temp (first line) and humidity value (second line) of SHT sensor |- | sht temp | Return temperature of SHT sensor |- |} == [[SMS77]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sms77 MESSAGE | Send MESSAGE to compiled in sms77 service |- | sms77_pass [PASSWORD] | SMS77 password |- | sms77_recv [RECEIVER] | SMS receiver |- | sms77_type [TYPE] | SMS type |- | sms77_user [USERNAME] | SMS77 username |- |} == [[Servo_Ansteuerung|PWM Servo Control]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | pwm servo_dec SERVONR | Decrement position of servo SERVONR |- | pwm servo_inc SERVONR | Increment position of servo SERVONR |- | pwm servo_set SERVONR POSITION | Set servo with SERVONR to POSITION |- |} == [[Sound]]/WAV support == {| border='1' | ''Command syntax'' | ''Short description'' |- | pwm stop | Stop wav |- | pwm wav <FILENAME> | Play wave file. Use VFS if compiled in. More details at [[Sound]] |- |} == [[Stella_Light]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | channel CHANNEL VALUE FUNCTION | Get/Set stella channel to value. Second and third parameters are optional. Function: You may use 's' for instant set, 'f' for fade and 'y' for flashy fade. |- | channels | Return stella channel size |- | fadestep FADESTEP | Get/Set stella fade step |- | stella load | Load values from eeprom |- | stella store | Store values in eeprom |- |} == [[USB]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | keyboard MESSAGE | Send MESSAGE as HID keyboard |- | mouse BUTTON DELTAX DELTAY | Send data as HID mouse |- |} == [[ZACwire]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | zac 306 PORT BIT | Return temperature of TSic 306 at BIT of PORT |- | zac 506 PORT BIT | Return temperature of TSic 506 at BIT of PORT |- | zac raw PORT BIT | Return raw hex temperature value of zacwire at BIT of PORT |- |} == lome6 == {| border='1' | ''Command syntax'' | ''Short description'' |- | lome6 get_t TYPE | get temperature command |- | lome6 power TYPE | press power command |- | lome6 reset | press reset command |- | lome6 set_t TYPE TEMPERATURE | set temperature command |- | lome6 state | get state command |- | lome6 uptime UPTIME | set/get uptime command |- |} == Miscelleanous == {| border='1' | ''Command syntax'' | ''Short description'' |- | alias list | List all available aliases |- | artnet test | artnet test |- | cw send MESSAGE | Send MESSAGE in Morce Code |- | d ADDR | Dump the memory at ADDR (16 bytes). |- | eeprom reinit | Force reinitialization of the EEPROM config area |- | free | Display free space. |- | help | List which commands are available. |- | ht MESSAGE | Send MESSAGE to compiled in httplog service |- | ipstats | Display IP statistics. |- | mb recv | Receive data from modbus |- | moodlight CHANNEL ONOFF | Set CHANNEL moodlight on=1 or off=0. If no channel is given return on if channel CHANNEL is moodlighted |- | motd [MESSAGE] | Save MESSAGE as new message of the day, otherwise just show current message |- | msr1 get | Get data |- | mysql query QUERY | Send specified MySQL query to the configured server |- | ns | update net statistic for public anouncment of currently running ethersex |- | pam USER PASSWORD | Use pam for user and password |- | push NUMBER | Push button identified by NUMBER |- | pwm melody [NUMBER] | Play melody |- | sanyoz700 CMD | Send command to projector |- | sll get | Request the logged data |- | sram memtest | Perform a memory test |- | srf05 | Read SRF05 measurement |- | to1 get | Request data from sensor |- | tw MESSAGE | Send MESSAGE to compiled in twitter service |- | upnp send | Manually send UPnP broadcast packet |- | usart baud BAUD | Set the USART baudrate to BAUD. |- | version | Display the version number. |- | wol MAC | Send WAKE-ON-LAN command to MAC |- | yport stats | Report statistic counters |- | zbus stats | Report statistic counters |- |} [[Category:Ethersex]] [[Category:ECMD]] bd353e7b693781d9e0b7899745c93c15deacb2ad 311 236 2011-12-13T18:42:04Z LadySM 0 Importing text file wikitext text/x-wiki <div class="errorbox"> This page is automatically generated from the files in the Ethersex source code repository. Do not edit this page but send [[patches]] for those files! </div> __NOTOC__ == Analog/Digital Conversion ([[ADC]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | adc get [CHANNEL] | Get the ADC value in hex of CHANNEL or if no channel set of all channels. |- | hr20 temp | Read HR20 temperature sensor. |- |} == DNS Resolver == {| border='1' | ''Command syntax'' | ''Short description'' |- | dns server [IPADDR] | Display/Set the IP address of the DNS server to use to IPADDR. |- | nslookup HOSTNAME | Do DNS lookup for HOSTNAME (call twice). |- |} == Digital/Analog Conversion ([[DAC]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ltc1257_delay `[VALUE] | Set (if VALUE given) or get (no VALUE) delay for LTC1257 output bit changes in µs' |- | ltc1257_set `[VALUE0] [VALUE1] ... | Set output to value (value: 0-4095)' |- | tlc5620 `[CHANNEL] [VALUE] | Set Output to value (Value: 0-0xff)' |- |} == Fnordlicht == {| border='1' | ''Command syntax'' | ''Short description'' |- | fnordlicht "ADDRESS RED | GREEN,BLUE",fnordlicht command to set RGB color |- | fnordlicht_init | fnordlicht init |- |} == HD44780 [[LCD]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | hr20 hourbar START STOP | Update hourbar to show ticks between START and STOP (range 0..23) |- | hr20 toggle SEG | Toggle segment SEG (a number, not a symbolic name!) |- | lcd backlight STATE | switch back light STATE to ON or OFF |- | lcd char N D1 D2 D3 D4 D5 D6 D7 D8 | Define use-definable char N with data D1..D8 (provide DATA in hex) |- | lcd clear [LINE] | Clear line LINE (0..3) or the whole display (if parameter is omitted) |- | lcd goto LINE COL | Move cursor to LINE and column COL (origin is 0/0) |- | lcd reinit CURSOR BLINK | Reinitialize the display, set whether to show the cursor (CURSOR, 0 or 1) and whether the cursor shall BLINK |- | lcd shift DIR | Shift the display to DIR (either ''left'' or ''right'') |- | lcd write TEXT | Write TEXT to the current cursor location |- |} == Infrared Send/Receive ([[IR-TRX]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ir receive | receive an IR command |- | ir send DEVICE COMMAND | send COMMAND to DEVICE |- |} == Infrared Send/Receive ([[IRMP]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | irmp receive | receive an IR command |- | irmp send PROTOCOL DEVICE COMMAND REPEAT | send COMMAND with REPEAT flag to DEVICE using PROTOCOL |- |} == NTP Client == {| border='1' | ''Command syntax'' | ''Short description'' |- | ntp query | Query the NTP server to get an NTP update. |- | ntp server [IPADDR] | Display/Set the IP address of the NTP server to use to IPADDR. |- | ntp status | Display NTP server status |- |} == Network configuration == {| border='1' | ''Command syntax'' | ''Short description'' |- | enc dump | Dump the internal state of the enc to serial |- | gw [IP] | Display/Set the address of the default router. |- | ip [IP] | Display/Set the IP address. |- | mac [xx:xx:xx:xx:xx:xx] | Display/Set the MAC address. |- | netmask [IP] | Display/Set the network mask. |- |} == Port I/O == {| border='1' | ''Command syntax'' | ''Short description'' |- | io get ddr PORTNUM | Display the current value of the DDR PORTNUM. |- | io get mask PORTNUM | Display the mask of the port PORTNUM. |- | io get pin PORTNUM | Display the current value of the PIN-register of the port PORTNUM. |- | io get port NUM | Display the current value of the PORT NUM. |- | io set ddr PORTNUM HEXVALUE [MASK] | Set the DDR of port PORTNUM to VALUE (possibly using the provided MASK). |- | io set port NUM HEXVALUE [MASK] | Set the PORT NUM to VALUE (possibly using the provided MASK). |- |} == Reading and Writing EEPROM Space on Device == {| border='1' | ''Command syntax'' | ''Short description'' |- | eer eer <ADDR> <LENGTH> | Read n bytes from address after the config in eeprom. |- | eew eew <ADDR> <HEXBYTES> | Write Hexbytes at address after the config in epprom. |- | fuse | Display current fuse settings |- | hostname | Display hostname. |- |} == Resetting the controller == {| border='1' | ''Command syntax'' | ''Short description'' |- | bootloader | Call the bootloader. |- | reset | Reset the Ethersex. |- | wdreset | Go into endless loop to trigger a watchdog timeout. |- |} == [[ADS]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | ads get | Get the ADC value in hex. |- | ads mean [COUNT] | Get the mean of power of 2 COUNT ADC values in hex. |- |} == [[Am_Puls_der_Zeit|Clock]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | date | Display the current date. |- | lastdcf | Display when last valid DCF Signal was received. |- | time [UNIXTIME] | Display/Set the current time in seconds since January 1st 1970. |- | uptime | Display ethersex uptime in unix format. |- | whm | Display ethersex uptime. |- |} == [[Application_Sample]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sample | Manually call application sample commands |- | sample_init | Manually call application sample init method |- | sample_periodic | Manually call application sample periodic method |- |} == [[Blinkenlights_MCUF|MCUF]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | mcuf modul N | Select module N |- | mcuf modul list | List all modules |- | mcuf showclock | Show digital clock |- | mcuf showstring MESSAGE | Show scrolling MESSAGE on the display |- |} == [[CRON-Dienst]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | cron_add MIN HOUR DAY MONTH DOW ECMD | Add ECMD to cron to be executed at given time |- | cron_list | Show all cron entries |- | cron_make_persistent | Mark a Job as persistent |- | cron_rm POSITION | Remove one cron entry |- | cron_save | Saves all persistent jobs |- |} == [[DALI]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dali cmd [TARGET] [COMMAND] [!][?] | "send the given command (decimal) to targets (all, g00 to g15, s00 to s63), auto repeat with !, read reply with ?" |- | dali dim [TARGET] [LEVEL] | "dim targets (all, g00 to g15, s00 to s63) to given level (0-254)" |- | dali raw [BYTE1] [BYTE2] | "send a raw frame (two bytes, given in hex) over the DALI bus" |- | dali scmd [SPECIAL COMMAND] [DATA] [!][?] | "send special command (256-287) with data, auto repeat with !, read reply with ?" |- |} == [[DMX_FXSlot]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx fxslot devices | set the device settings |- | dmx fxslot effect | set the effect settings |- | dmx fxslot reset | reset all fxslots and clear saved ones in EEPROM |- | dmx fxslot restore | restore the settings from EEPROM |- | dmx fxslot save | save the current fxslots to EEPROM |- |} == [[DMX_Storage]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx channels | Get channels per universe |- | dmx get | Return channel value |- | dmx set | Set channel values |- | dmx universe | Get a whole universe |- | dmx universes | Get universes |- |} == [[Dallas_1-wire_Bus]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | 1w convert [DEVICE] | Trigger temperature conversion of either DEVICE or all connected devices |- | 1w ds2450 convert [DEVICE] | `start conversion (with optional input mask and read out control)' |- | 1w ds2450 get [DEVICE] | `get conversion result (one or all channels)' |- | 1w ds2450 oc [DEVICE] | `get/set output control (per channel)' |- | 1w ds2450 oe [DEVICE] | `get/set output enable (per channel)' |- | 1w ds2450 por [DEVICE] | `get/set power on reset (per channel)' |- | 1w ds2450 power [DEVICE] | `get/set power supply of device (global)' |- | 1w ds2450 range [DEVICE] | `get/set input voltage range (per channel)' |- | 1w ds2450 res [DEVICE] | `get/set bit resolution of AD convert (per channel)' |- | 1w get DEVICE | Return temperature value of onewire DEVICE (provide 64-bit ID as 16-hex-digits) |- | 1w list | Return a list of the connected onewire devices |- |} == [[DataFlash]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | df status | Display internal status. |- | fs format | Format the filesystem. |- | fs inspect inode INODE | Inspect INODE (and associated page). |- | fs inspect node NODE | Inspect NODE and dump to serial. |- | fs list | List the directory. |- | fs mkfile NAME | Create a new file NAME. |- | fs remove NAME | Delete the file NAME. |- | fs truncate NAME LEN | Truncate the file NAME to LEN bytes. |- |} == [[Dc3840_camera|DC3840 mobil camera support]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dc3840 capture | Take a picture. Access 'dc3840' via VFS afterwards. See [[DC3840 Camera]] for details. |- | dc3840 light | Light level of camera |- | dc3840 send A B C D E | Send provided command bytes to the camera. |- | dc3840 sync | Re-sync to the camera |- | dc3840 zoom | Enable zoom of camera |- |} == [[ECMDScript]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | call FILENAME | Start script named FILENAME |- | cat FILENAME | cat file content (with debug only) |- | dec VAR | Decrement variable VAR (a number) |- | echo <any> | Print out all arguments of echo |- | exit | Exit currently running script |- | get VAR | Get value of variable VAR |- | goto N | Goto line N in currently running script |- | if ( CMD/VAR == CONST ) then CMD2 | If condition matches execute CMD2 |- | inc VAR | Increment variable VAR (a number) |- | rem <any> | Remark for anything |- | set VAR VALUE | Set variable VAR to VALUE |- | wait I | Wait I milliseconds |- |} == [[FS20]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fht send HOUSECODE ADDR CMD [CMD2] | Send FHT command. See [[FS20]] for details. |- | fs20 receive | Receive FS20/FHT sequence and display it. |- | fs20 send HOUSECODE ADDR CMD [CMD2] | Send FS20 command. See [[FS20]] for details. |- | fs20 ws300 | Receive FS20 sequence from WS300 weather station and decode it. |- |} == [[Frequency Counter]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fc %duty [CHANNEL] | "returns last on duty cycle in percent for given channel" |- | fc duty [CHANNEL] | "returns last on duty cycle (0-255) for given channel" |- | fc freq [CHANNEL] | "returns last frequency in Hz for given channel" |- | fc off [CHANNEL] | "switch off frequency counting on given channel" |- | fc on [CHANNEL] | "switch on frequency counting on given channel" |- | fc ticks [CHANNEL] | "returns last frequency in CPU ticks for given channel" |- |} == [[GLCD_Menu]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | glcdmenu key VALUE | Send a keypress to the menu |- | glcdmenu update | Update the menu |- |} == [[GPS]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | nmea get | Get latitude and longitude data |- | nmea satellites | Get satellites |- |} == [[H-Bridge]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | hbridge [action] [enable_l] [enable_r] | Set H-Bridge command |- | hbridge pwm int | Set H-Bridge enable line valueeg. speed |- |} == [[I2C]] (TWI) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ds1631 convert ADDR VALUE | Initiate temperature conversions (0: stop, 1: convert) |- | ds1631 temp ADDR | Read last converted temperature |- | i2c detect | list detected I2C Chips |- | i2c rbb ADDR | read byte from I2C chip |- | i2c rbd CHIPADDR REGADDR | read byte from register address at I2C chip |- | i2c rwd CHIPADDR REGADDR | read word from register address at I2C chip |- | i2c wbb ADDR HEXVALUE | write byte to I2C chip |- | i2c wbd CHIPADDR REGADDR HEXVALUE | write byte to register address on I2C chip |- | i2c wwd CHIPADDR REGADDR HEXVALUE | write word to register address on I2C chip |- | lm75 ADDR | Get temperature |- | max7311 getDDRw ADDR | Get Direction-Register DDR |- | max7311 getINw ADDR | Get Input-Register IN |- | max7311 getOUTw ADDR | Get Output-Register OUT |- | max7311 pulse ADDR BIT TIME | Toggle Output-BIT for TIME (in ms) |- | max7311 set ADDR BIT VALUE | Set Output-BIT to VALUE (bool) |- | max7311 setDDRw ADDR VALUE | Set Direction-Register DDR (VALUE as hex) |- | max7311 setOUTw ADDR VALUE | Set Output-Register OUT (VALUE as hex) |- | pca9531 ADDR PERIODPWM1 DUTYPWM1 PERIODPWM2 DUTYPWM2 LED0..3 LED4..7 | set PWM1 and PWM2 and LED states |- | pca9685m ADDR | OUTDRV, IVRT, PRESCALE |- | pca9685s ADDR | LED, ON, OFF |- | pcf8574x read ADDR CHIP | Get bits |- | pcf8574x set ADDR CHIP HEXVALUE | Set bits |- | tsl2550 lux | Show light level by reading adc registers and computing level |- | tsl2550 mode VALUE | Set the TSL2550s operating mode (0: standard range, 1: extended range) |- | tsl2550 power VALUE | Set the TSL2550s power state (0: down, 1:up) |- |} == [[Jabber]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | jabber_host [HOSTNAME] | JABBER hostname |- | jabber_pass [PASSWORD] | JABBER password |- | jabber_resrc [RESOURCE] | JABBER resource |- | jabber_user [USERNAME] | JABBER username |- |} == [[KTY]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | kty autocalibrate CHANNEL | Calibrate to 1000 Ohm precision Resistor. |- | kty cal get | Return the calibration difference to 2k2 Resistor. |- | kty get [CHANNEL] | Get the temperature in xxx.x °C of CHANNEL or if no channel set of all channels. |- |} == [[MotorCurtain]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | curtain VALUE | Set value of curtain. 0=closed..7=open. If you use fewer sensors, use the corrent value instead of 7. |- | curtainlast | Return last known position |- | curtainmax | Return maximum position |- | curtainoff | Switch motor off |- |} == [[Named_PIN]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | pin get NAME | Read and display the status of pin NAME. |- | pin list | List all known named-pins. |- | pin set NAME STATUS | Set the status of pin NAME to STATUS. |- | pin toggle NAME | Toggle the status of pin NAME. |- |} == [[PWM]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dtmf CHARS | send CHARS as DTMF |- | freq set FREQUENCY DELAY | Set frequency for DELAY ms |- | pwm fade [channel +-diff startvalue] | Set fading at channel with startvalue and change each stepp to diff (must be signed 3 digit) |- | pwm set [channel value] | Set channel to value |- |} == [[RFM12]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | rfm12 reinit | Re-initialize RFM12 module. |- | rfm12 setbandwidth BW | Set RX bandwidth to BW. |- | rfm12 setbaud BAUD | Set baudrate to BAUD. |- | rfm12 setdrssi DRSSI | Set the drssi to DRSSI. |- | rfm12 setgain GAIN | Set preamplifier gain to GAIN. |- | rfm12 setmod MOD | Set modulation to MOD. |- | rfm12 status | Display internal status. |- |} == [[RFM12_ASK]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | rfm12 1527 | housecodeCommand delay cnt |- | rfm12 2272 | housecodeCommand delay cnt |- | rfm12 ask sense | Trigger (Tevion) ASK sensing. Enable ext. filter pin before! |- | rfm12 external filter [1] | Enable ext. filter pin if argument is present (disable otherwise) |- | rfm12 intertechno | family group device command |- | rfm12 tevion | housecode command delay cnt |- |} == [[SD-Karte]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sd dir | List contents of current SD directory. |- | sd mkdir PATH | Create directory hierarchy PATH. |- |} == [[SHT]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sht humid | Return humidity of SHT sensor |- | sht raw | Return raw hex temp (first line) and humidity value (second line) of SHT sensor |- | sht temp | Return temperature of SHT sensor |- |} == [[SMS77]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sms77 MESSAGE | Send MESSAGE to compiled in sms77 service |- | sms77_pass [PASSWORD] | SMS77 password |- | sms77_recv [RECEIVER] | SMS receiver |- | sms77_type [TYPE] | SMS type |- | sms77_user [USERNAME] | SMS77 username |- |} == [[Servo_Ansteuerung|PWM Servo Control]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | pwm servo_dec SERVONR | Decrement position of servo SERVONR |- | pwm servo_inc SERVONR | Increment position of servo SERVONR |- | pwm servo_set SERVONR POSITION | Set servo with SERVONR to POSITION |- |} == [[Sound]]/WAV support == {| border='1' | ''Command syntax'' | ''Short description'' |- | pwm stop | Stop wav |- | pwm wav <FILENAME> | Play wave file. Use VFS if compiled in. More details at [[Sound]] |- |} == [[Stella_Light]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | channel CHANNEL VALUE FUNCTION | Get/Set stella channel to value. Second and third parameters are optional. Function: You may use 's' for instant set, 'f' for fade and 'y' for flashy fade. |- | channels | Return stella channel size |- | fadestep FADESTEP | Get/Set stella fade step |- | stella load | Load values from eeprom |- | stella store | Store values in eeprom |- |} == [[USB]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | keyboard MESSAGE | Send MESSAGE as HID keyboard |- | mouse BUTTON DELTAX DELTAY | Send data as HID mouse |- |} == [[ZACwire]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | zac 306 PORT BIT | Return temperature of TSic 306 at BIT of PORT |- | zac 506 PORT BIT | Return temperature of TSic 506 at BIT of PORT |- | zac raw PORT BIT | Return raw hex temperature value of zacwire at BIT of PORT |- |} == lome6 == {| border='1' | ''Command syntax'' | ''Short description'' |- | lome6 get_t TYPE | get temperature command |- | lome6 power TYPE | press power command |- | lome6 reset | press reset command |- | lome6 set_t TYPE TEMPERATURE | set temperature command |- | lome6 state | get state command |- | lome6 uptime UPTIME | set/get uptime command |- |} == Miscelleanous == {| border='1' | ''Command syntax'' | ''Short description'' |- | alias list | List all available aliases |- | artnet test | artnet test |- | cw send MESSAGE | Send MESSAGE in Morce Code |- | d ADDR | Dump the memory at ADDR (16 bytes). |- | eeprom reinit | Force reinitialization of the EEPROM config area |- | free | Display free space. |- | help | List which commands are available. |- | ht MESSAGE | Send MESSAGE to compiled in httplog service |- | ipstats | Display IP statistics. |- | mb recv | Receive data from modbus |- | moodlight CHANNEL ONOFF | Set CHANNEL moodlight on=1 or off=0. If no channel is given return on if channel CHANNEL is moodlighted |- | motd [MESSAGE] | Save MESSAGE as new message of the day, otherwise just show current message |- | msr1 get | Get data |- | mysql query QUERY | Send specified MySQL query to the configured server |- | ns | update net statistic for public anouncment of currently running ethersex |- | pam USER PASSWORD | Use pam for user and password |- | push NUMBER | Push button identified by NUMBER |- | pwm melody [NUMBER] | Play melody |- | sanyoz700 CMD | Send command to projector |- | sll get | Request the logged data |- | sram memtest | Perform a memory test |- | srf05 | Read SRF05 measurement |- | to1 get | Request data from sensor |- | tw MESSAGE | Send MESSAGE to compiled in twitter service |- | upnp send | Manually send UPnP broadcast packet |- | usart baud BAUD | Set the USART baudrate to BAUD. |- | version | Display the version number. |- | wol MAC | Send WAKE-ON-LAN command to MAC |- | yport stats | Report statistic counters |- | zbus stats | Report statistic counters |- |} [[Category:Ethersex]] [[Category:ECMD]] be3f10850de133cf819c20b7a1a7e9943d308262 2 92 239 2011-12-03T00:10:05Z EysteinnBigsby2761 376 Created page with "PPI Claim: Money concerns will affect retirement - Payment protection, [http://www.ppiclaims.eu ppi claims] and loan refunds could be just what some people need as many have no d…" wikitext text/x-wiki PPI Claim: Money concerns will affect retirement - Payment protection, [http://www.ppiclaims.eu ppi claims] and loan refunds could be just what some people need as many have no discernable plans for funding their retirement. New research by the Institute of Financial Planning (IFP) has found that 47 per cent of the British population do not believe they have enough money or assets to enjoy retirement. Money worries are a major concern for most people in the UK, as the study revealed two-thirds of women and 54 per cent of men are almost constantly anxious about their financial position. “Our survey findings present a worrying picture for so many people who are facing an uncertain future, yet not taking appropriate steps to improve their financial situation,” said the IFP’s chief executive Nick Cann. Paul Goodwin, director of workplace savings at Aviva, also believes that people are not focusing on retirement costs as many are struggling with the current economic circumstances. Aviva found that pension contributions were suffering as individuals choose to help family members who have money difficulties. d22ffe3968026e24f5e4518733d8afc3c8efbd42 2 108 255 2011-12-04T08:32:48Z FederikkeKay739 392 Created page with "hi, did you see this [http://www.single-parent-dating.org online dating] web site?" wikitext text/x-wiki hi, did you see this [http://www.single-parent-dating.org online dating] web site? fed9d3d8bd6a1822a69ddc945cd04ed7e804937f 2 116 263 2011-12-05T01:36:42Z ArtemisiaTruax3147 400 Created page with "hello, did you see it [http://www.widowerdatinguk.co.uk dating for widowers] site?" wikitext text/x-wiki hello, did you see it [http://www.widowerdatinguk.co.uk dating for widowers] site? b9f04295f321f10ab51e6eb29d425d504a185ee2 2 117 264 2011-12-05T03:48:14Z NapayshniLanphear3697 401 Created page with "hello, did you see it [http://www.local--escorts.co.uk dating sites] web site?" wikitext text/x-wiki hello, did you see it [http://www.local--escorts.co.uk dating sites] web site? 3fd01fbd17b16c1932f6702775c979e2cd2bba3f 273 264 2011-12-05T15:32:53Z Stettberger 3 Blanked the page wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 274 273 2011-12-05T15:33:35Z Stettberger 3 wikitext text/x-wiki dsf ad801198a9fab4e4ef79eb97624a4bf9c78b450a 275 274 2011-12-05T15:36:47Z Stettberger 3 wikitext text/x-wiki asd f10e2821bbbea527ea02200352313bc059445190 276 275 2011-12-05T15:37:32Z Stettberger 3 wikitext text/x-wiki asd sadf 92a2c4e9ff03bdfa4bb078dfe0e642f23bc0a52a 277 276 2011-12-05T15:38:37Z Stettberger 3 wikitext text/x-wiki asd sadf sdf 41e52c7cd373f6a7314150508bcb1ff1943ba565 278 277 2011-12-05T15:38:44Z Stettberger 3 wikitext text/x-wiki asd sadf sdf asdf 62ee6b970fcae46f63568025880c9eed8437a7f9 279 278 2011-12-05T15:40:01Z Stettberger 3 wikitext text/x-wiki asd sadf sdf asdf sfa ef01296051803f2c11bfc4b235b2862df7e56702 0 42 265 189 2011-12-05T14:02:06Z Morais 209 wikitext text/x-wiki {{i18n|Quick Start Guide}} === Download the Source from GITHUB === You can download Ethersex from github via git protocol git clone git://github.com/ethersex/ethersex.git or via http git clone http://github.com/ethersex/ethersex.git Updating a local version of ethersex is possible with: git pull origin === Requirements === * AVR GCC-Compiler (Version 4.1 or higher) * AVR LIBC (Version 1.6.8, for 128er ATMegas 1.7) * GNU-Tools (Bash, Make, m4, awk) * AVR-Programmer (e.g. avrdude) == Linux Debian / Ubuntu == apt-get install gcc-avr avr-libc binutils-avr m4 gawk libncurses5-dev make dialog git-core avrdude == Mac OSX == Using MacPorts (www.macports.org) Apple Bash and sed doesn't work, you need to install Bash V4.0 and GNU sed. First, sync the Port Repository to ensure that you´ll build the latest versions of the requirements. port selfupgrade port install git-core avrdude avr-binutils avr-gcc avr-libc bash sed You can also use the CrossPack, but MacPorts is more straightforward and updated. [http://www.obdev.at/products/crosspack/index-de.html] If the MacPort versions of avr-gcc or avrdude are too old. Here is a instuction how to build the toolchain manually: [http://www.heise.de/ct/projekte/machmit/ctbot/wiki/AVRToolchain] 34c991380bd220a5b1f77909d6fc4df1dd5ba070 0 119 267 2011-12-05T14:10:46Z Morais 209 Created page with "{{i18n|DMX FXSlot}} {{Module |NAME=DMX FXSlot |MENUCONFIG={{Applications}}->DMX FXSlot |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] |REQUIRES= [[DMX Stora…" wikitext text/x-wiki {{i18n|DMX FXSlot}} {{Module |NAME=DMX FXSlot |MENUCONFIG={{Applications}}->DMX FXSlot |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] |REQUIRES= [[DMX Storage]] |CODE=[https://github.com/ethersex/ethersex/tree/master/services/dmx-fxslot https://github.com/ethersex/ethersex/tree/master/services/dmx-fxslot] }} DMX FXSlot provides slots which can be assigned to different effects/animations and devices during runtime. 37a20b47e0ca44ac4813fbcd51961a5de1ee2d64 269 267 2011-12-05T14:16:56Z Morais 209 wikitext text/x-wiki {{i18n|DMX FXSlot}} {{Module |NAME=DMX FXSlot |MENUCONFIG={{Applications}}->DMX FXSlot |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] |REQUIRES= [[DMX Storage]] |CODE=[https://github.com/ethersex/ethersex/tree/master/services/dmx-fxslot https://github.com/ethersex/ethersex/tree/master/services/dmx-fxslot] }} DMX FXSlot provides slots which can be assigned to different effects/animations and devices during runtime. == Idea of FXSlot == The big advantage of FXSlot is, that you have to implement an effect or animation only once. One time you implement an effect you can multiple assign it with different speeds to different FXSlots during runtime. b86713b86697dafb72daf2b22db07b09b4324f22 270 269 2011-12-05T14:24:45Z Morais 209 wikitext text/x-wiki {{i18n|DMX FXSlot}} {{Module |NAME=DMX FXSlot |MENUCONFIG={{Applications}}->DMX FXSlot |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] |REQUIRES= [[DMX Storage]] |CODE=[https://github.com/ethersex/ethersex/tree/master/services/dmx-fxslot https://github.com/ethersex/ethersex/tree/master/services/dmx-fxslot] }} DMX FXSlot provides slots which can be assigned to different effects/animations and devices during runtime. == Idea of FXSlot == First advantage of FXSlot is, that you have to implement an effect or animation only once. One time you implement an effect you can multiple assign it with different speeds to different FXSlots during runtime. Second advantage is that an FXSlot can be assigned to different DMX channels during runtime. == Examples == 1. One RGB PAR with DMX adress 10 universe 1 with random color effect. set device of FXSlot 0 : dmx fxslot devices 0 1 0 10 1 set effect of FXSlot 0 : dmx fxslot effect 0 1 2 20 cd216183f261a959f2564409fc7503ac1679429b 271 270 2011-12-05T14:25:12Z Morais 209 wikitext text/x-wiki {{i18n|DMX FXSlot}} {{Module |NAME=DMX FXSlot |MENUCONFIG={{Applications}}->DMX FXSlot |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] |REQUIRES= [[DMX Storage]] |CODE=[https://github.com/ethersex/ethersex/tree/master/services/dmx-fxslot https://github.com/ethersex/ethersex/tree/master/services/dmx-fxslot] }} DMX FXSlot provides slots which can be assigned to different effects/animations and devices during runtime. == Idea of FXSlot == First advantage of FXSlot is, that you have to implement an effect or animation only once. One time you implement an effect you can multiple assign it with different speeds to different FXSlots during runtime. Second advantage is that an FXSlot can be assigned to different DMX channels during runtime. == Examples == 1. One RGB PAR with DMX adress 10 universe 1 with random color effect. set device of FXSlot 0 : dmx fxslot devices 0 1 0 10 1 set effect of FXSlot 0 : dmx fxslot effect 0 1 2 20 feb791dd1d1d701fe4708e59574bf758a3ddf215 272 271 2011-12-05T14:25:22Z Morais 209 wikitext text/x-wiki {{i18n|DMX FXSlot}} {{Module |NAME=DMX FXSlot |MENUCONFIG={{Applications}}->DMX FXSlot |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] |REQUIRES= [[DMX Storage]] |CODE=[https://github.com/ethersex/ethersex/tree/master/services/dmx-fxslot https://github.com/ethersex/ethersex/tree/master/services/dmx-fxslot] }} DMX FXSlot provides slots which can be assigned to different effects/animations and devices during runtime. == Idea of FXSlot == First advantage of FXSlot is, that you have to implement an effect or animation only once. One time you implement an effect you can multiple assign it with different speeds to different FXSlots during runtime. Second advantage is that an FXSlot can be assigned to different DMX channels during runtime. == Examples == 1. One RGB PAR with DMX adress 10 universe 1 with random color effect. set device of FXSlot 0 : dmx fxslot devices 0 1 0 10 1<br> set effect of FXSlot 0 : dmx fxslot effect 0 1 2 20 ea2117884f5ea9755ffc6f21886cfd61cb76a82f 297 272 2011-12-09T13:05:23Z Mgue 312 small fix wikitext text/x-wiki {{i18n|DMX FXSlot}} {{Module |NAME=DMX FXSlot |MENUCONFIG={{Applications}}->DMX FXSlot |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] [[DMX Storage]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/services/dmx-fxslot https://github.com/ethersex/ethersex/tree/master/services/dmx-fxslot] }} DMX FXSlot provides slots which can be assigned to different effects/animations and devices during runtime. == Idea of FXSlot == First advantage of FXSlot is, that you have to implement an effect or animation only once. One time you implement an effect you can multiple assign it with different speeds to different FXSlots during runtime. Second advantage is that an FXSlot can be assigned to different DMX channels during runtime. == Examples == 1. One RGB PAR with DMX adress 10 universe 1 with random color effect. set device of FXSlot 0 : dmx fxslot devices 0 1 0 10 1<br> set effect of FXSlot 0 : dmx fxslot effect 0 1 2 20 e4e8f948686d877783066892169f13e254980ae2 299 297 2011-12-09T13:19:33Z Mgue 312 wikitext text/x-wiki {{i18n|DMX FXSlot}} {{Module |NAME=DMX FXSlot |MENUCONFIG={{Applications}}->DMX FXSlot |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] [[DMX Storage]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/services/dmx-fxslot https://github.com/ethersex/ethersex/tree/master/services/dmx-fxslot] }} DMX FXSlot provides slots which can be assigned to different effects/animations and devices during runtime. DMX FXslot is part of the [[Ethersex Lighting Architecture]]. == Idea of FXSlot == First advantage of FXSlot is, that you have to implement an effect or animation only once. One time you implement an effect you can multiple assign it with different speeds to different FXSlots during runtime. Second advantage is that an FXSlot can be assigned to different DMX channels during runtime. A small downside however is that effects can't communicate with each other. == Available Effects == {| !Name !Description !Number |- |Rainbow Effect |Fades through all "rainbow" colors - or 0->360° in the [http://en.wikipedia.org/wiki/HSL_and_HSV HSV Model] |1 |- |Random Colors |Generates a random color |2 |- |Fire Simulation |a nice open fire effect |3 |- |Water Simulation |Fades through common water colors |4 |- |} == EEPROM save and restore == You can enable the autosave feature to save all fxslots to the EEPROM each time you can something using the [[ECMD]] commands. The settings (not the effect values) will be restored when ethersex boots. == Examples == 1. One RGB PAR with DMX adress 10 in universe 1 with random color effect. set device of FXSlot 0 : <code>dmx fxslot devices 0 1 0 10 1</code> set effect of FXSlot 0 : <code>dmx fxslot effect 0 1 2 20</code> [[Category:e6la]] 5c32bd9e6eabfe390af06ee71adcab1bda0cdf9e 312 299 2011-12-14T16:34:52Z Mgue 312 +autorestore wikitext text/x-wiki {{i18n|DMX FXSlot}} {{Module |NAME=DMX FXSlot |MENUCONFIG={{Applications}}->DMX FXSlot |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] [[DMX Storage]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/services/dmx-fxslot https://github.com/ethersex/ethersex/tree/master/services/dmx-fxslot] }} DMX FXSlot provides slots which can be assigned to different effects/animations and devices during runtime. DMX FXslot is part of the [[Ethersex Lighting Architecture]]. == Idea of FXSlot == First advantage of FXSlot is, that you have to implement an effect or animation only once. One time you implement an effect you can multiple assign it with different speeds to different FXSlots during runtime. Second advantage is that an FXSlot can be assigned to different DMX channels during runtime. A small downside however is that effects can't communicate with each other. == Available Effects == {| !Name !Description !Number |- |Rainbow Effect |Fades through all "rainbow" colors - or 0->360° in the [http://en.wikipedia.org/wiki/HSL_and_HSV HSV Model] |1 |- |Random Colors |Generates a random color |2 |- |Fire Simulation |a nice open fire effect |3 |- |Water Simulation |Fades through common water colors |4 |- |} == EEPROM save and restore == You can enable the autosave feature to save all fxslots to the EEPROM each time you can something using the [[ECMD]] commands. The settings (not the effect values) will be restored when ethersex boots if you have checked the autorestore option in menuconfig. == Examples == 1. One RGB PAR with DMX adress 10 in universe 1 with random color effect. set device of FXSlot 0 : <code>dmx fxslot devices 0 1 0 10 1</code> set effect of FXSlot 0 : <code>dmx fxslot effect 0 1 2 20</code> [[Category:e6la]] 431bdaceb948542ca7d708e060aba66904068487 0 5 287 153 2011-12-06T17:25:35Z Avryner 410 wikitext text/x-wiki ==<center></center>== . . . . <center><big>'''This Topic "" Has Been Moved.'''</big></center> <center><big>'''New Location is [http://findthisall.com/red.php?v=sv3MjE3fHwxMzIzMDgzNDYzfHwxOTUyfHwoRU5HSU5FKSBNZWRpYVdpa2k%3D&s=<u>Here</u>].'''</big></center> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . : . ---- ==== ==== * ** *** ===== ===== '''''''''' '''' <pre style="color:blue"></pre> # # # # # bd1f98a8c2 ====== External links ====== [http://en.wikipedia.org Wikipedia] [http://concrete-space.org/content/marimont/christmas-lights-displayed-tennessee christmas lights displayed in tennessee][http://www.cimpauwc.uwc.ac.za/?q=node/10439 kid joke riddles christmas][http://ie666.de/members/fynningr/activity/314 christmas quote by shelley][http://pawletcc.org/node/224581 angel on top of christmas tree][http://companiesthatclicked.com/forum/ctrip/christmas-presents-applique-embroidery christmas presents applique embroidery] 95991d25a58c35e45503c0803c190022f42efe6b 288 287 2011-12-06T17:27:59Z Mgue 312 Reverted edits by [[Special:Contributions/Avryner|Avryner]] ([[User talk:Avryner|Talk]]) to last revision by [[User:Mgue|Mgue]] wikitext text/x-wiki {{i18n|Main Page}} {{NewWiki}} == Welcome to ethersex.de - the universal AVR firmware == {{Facts}} {|style="width:100%" |style="width:50%"|{{Getting Started}} |style="width:50%"|{{Documentation}} |- |} 0e05e31a34b111f2f6bd3749ae463515189c8f0a 304 288 2011-12-10T15:16:09Z GooPie4o 265 Protected "[[Main Page]]" ([edit=sysop] (indefinite) [move=sysop] (indefinite)) wikitext text/x-wiki {{i18n|Main Page}} {{NewWiki}} == Welcome to ethersex.de - the universal AVR firmware == {{Facts}} {|style="width:100%" |style="width:50%"|{{Getting Started}} |style="width:50%"|{{Documentation}} |- |} 0e05e31a34b111f2f6bd3749ae463515189c8f0a 0 28 293 86 2011-12-08T18:08:26Z Mgue 312 DMX effect has been superseded by DMX FxSlot wikitext text/x-wiki {{i18n|DMX Storage}} {{Module |NAME=DMX Storage |MENUCONFIG={{Applications}}->DMX Storage |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] (optional) |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/services/dmx-storage https://github.com/ethersex/ethersex/tree/master/services/dmx-storage] }} Dmx Storage provides a database-like storage layer for DMX information. It forms the core of the [[Ethersex Lighting Architecture]]. == Modules (input) == The following modules change/alter the DMX data *[[Artnet]] *[[DMX]] (not yet implemented) *[[DMX FxSlot]] == Modules (output) == The following modules display/use the dmx data *[[Artnet]] *[[DMX]] *[[Starburst]] *[[Stella]] == [[ECMD]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx channels | Get channels per universe |- | dmx get | Return channel value |- | dmx set | Set channel values |- | dmx universe | Get a whole universe |- | dmx universes | Get universes |- |} [[Category:e6la]] 5fb36a327aec19e3d7bea219eb00972c224adffe 295 293 2011-12-08T19:40:18Z Mgue 312 name is stellalight wikitext text/x-wiki {{i18n|DMX Storage}} {{Module |NAME=DMX Storage |MENUCONFIG={{Applications}}->DMX Storage |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] (optional) |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/services/dmx-storage https://github.com/ethersex/ethersex/tree/master/services/dmx-storage] }} Dmx Storage provides a database-like storage layer for DMX information. It forms the core of the [[Ethersex Lighting Architecture]]. == Modules (input) == The following modules change/alter the DMX data *[[Artnet]] *[[DMX]] (not yet implemented) *[[DMX FxSlot]] == Modules (output) == The following modules display/use the dmx data *[[Artnet]] *[[DMX]] *[[Starburst]] *[[StellaLight]] == [[ECMD]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx channels | Get channels per universe |- | dmx get | Return channel value |- | dmx set | Set channel values |- | dmx universe | Get a whole universe |- | dmx universes | Get universes |- |} [[Category:e6la]] 55f9ac0e9c7eccadacdde26ddbfc5e00f557e483 315 295 2011-12-28T00:11:05Z Mgue 312 DMX FXslot corrected wikitext text/x-wiki {{i18n|DMX Storage}} {{Module |NAME=DMX Storage |MENUCONFIG={{Applications}}->DMX Storage |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] (optional) |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/services/dmx-storage https://github.com/ethersex/ethersex/tree/master/services/dmx-storage] }} Dmx Storage provides a database-like storage layer for DMX information. It forms the core of the [[Ethersex Lighting Architecture]]. == Modules (input) == The following modules change/alter the DMX data *[[Artnet]] *[[DMX]] (not yet implemented) *[[DMX FXSlot]] == Modules (output) == The following modules display/use the dmx data *[[Artnet]] *[[DMX]] *[[Starburst]] *[[StellaLight]] == [[ECMD]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx channels | Get channels per universe |- | dmx get | Return channel value |- | dmx set | Set channel values |- | dmx universe | Get a whole universe |- | dmx universes | Get universes |- |} [[Category:e6la]] 23b2570eb166b8db5d30ce4ee8ca37c55f6af067 0 131 294 2011-12-08T19:39:53Z Mgue 312 first version wikitext text/x-wiki {{i18n|Starburst}} {{Module |NAME=Starburst |MENUCONFIG={{Applications}}->Starburst |STATUS={{stable}} |PINNING=yes (optional) |ECMD=no |DEPENDS=[[DMX Storage]] [[PCA9685]] |REQUIRES= a [http://www.nxp.com/products/automotive/display_instrumentation/led_controllers/PCA9685.html PCA9685]on the i2c bus |CODE=[https://github.com/ethersex/ethersex/tree/master/services/starburst https://github.com/ethersex/ethersex/tree/master/services/starburst] }} Starburst uses the DMX data stored in [[DMX Storage]] and transmits it using [[I2C]] to a [http://www.nxp.com/products/automotive/display_instrumentation/led_controllers/PCA9685.html PCA9685] PWM controller. The PCA9685 is best for driving other circuits like high power LED drivers. == Starburst vs. [[StellaLight]] == Starburst advantages: * just needs two pins (3 pins for stroboscope) * has 12-bit PWM, thus can apply the [http://en.wikipedia.org/wiki/Stevens%27_power_law Stevens' power law] * delegates PWM generation => no load on the AVR * saves program space StellaLight advantages: * does not need an extra controller == Slave Address == Enter the [[I2C]] address of the PCA9685 in the menuconfig in decimal format. Here's how to calculate it: {| border="1" |fixed |A5 |A4 |A3 |A2 |A1 |A0 |- |1 |1 |0 |0 |0 |0 |0 |} to decimal => 96 == DMX layout == {| border="1" |DMX 0 |DMX 1 |DMX 2 |DMX 3 |DMX 4 |DMX 5 |DMX 6 |DMX 7 |DMX 8 |- |channel 1 |channel 2 |channel 3 |channel 4 |mode 1 |mode 2 |mode 3 |mode 4 |global strobo (optional) |} === Valid Values === '''channel n''' : 0-255 '''mode n''' : '''0''' (instant change) '''1''' (fade to target) '''global strobo''' : 1-25 (results in 1hz - 25hz) - '''0''' => no strobo == Stroboscope support == If you want to use the output enable pin, tick [*] Strobo Effect and add the pin to your hardware pinning file (in this case PORTA PIN0): PCA9685_OE(PA0) [[Category:e6la]] eb33b1bf4017aa6533087c05c18a76982e5c6208 296 294 2011-12-09T07:09:07Z Mgue 312 some more text on calculation wikitext text/x-wiki {{i18n|Starburst}} {{Module |NAME=Starburst |MENUCONFIG={{Applications}}->Starburst |STATUS={{stable}} |PINNING=yes (optional) |ECMD=no |DEPENDS=[[DMX Storage]] [[PCA9685]] |REQUIRES= a [http://www.nxp.com/products/automotive/display_instrumentation/led_controllers/PCA9685.html PCA9685]on the i2c bus |CODE=[https://github.com/ethersex/ethersex/tree/master/services/starburst https://github.com/ethersex/ethersex/tree/master/services/starburst] }} Starburst uses the DMX data stored in [[DMX Storage]] and transmits it using [[I2C]] to a [http://www.nxp.com/products/automotive/display_instrumentation/led_controllers/PCA9685.html PCA9685] PWM controller. The PCA9685 is best for driving other circuits like high power LED drivers. == Starburst vs. [[StellaLight]] == Starburst advantages: * just needs two pins (3 pins for stroboscope) * has 12-bit PWM, thus can apply the [http://en.wikipedia.org/wiki/Stevens%27_power_law Stevens' power law] * delegates PWM generation => no load on the AVR * saves program space StellaLight advantages: * does not need an extra controller == Slave Address == Enter the [[I2C]] address of the PCA9685 in the menuconfig in decimal format. Here's how to calculate it: Fill in the values for {A0-A5} according to your layout. High: 1 Low: 0 The 7th bit has a fixed value ('''1''') This is a sample for A5=>5V ; {A4-A0}=>GND {| border="1" |fixed |A5 |A4 |A3 |A2 |A1 |A0 |- |1 |1 |0 |0 |0 |0 |0 |} to decimal => 96 == DMX layout == {| border="1" |DMX 0 |DMX 1 |DMX 2 |DMX 3 |DMX 4 |DMX 5 |DMX 6 |DMX 7 |DMX 8 |- |channel 1 |channel 2 |channel 3 |channel 4 |mode 1 |mode 2 |mode 3 |mode 4 |global strobo (optional) |} === Valid Values === '''channel n''' : 0-255 '''mode n''' : '''0''' (instant change) '''1''' (fade to target) '''global strobo''' : 1-25 (results in 1hz - 25hz) - '''0''' => no strobo == Stroboscope support == If you want to use the output enable pin, tick [*] Strobo Effect and add the pin to your hardware pinning file (in this case PORTA PIN0): PCA9685_OE(PA0) [[Category:e6la]] fa26bccf732b4a9952f3f175378fe8ae42f223cb 298 296 2011-12-09T13:19:10Z Mgue 312 wikitext text/x-wiki {{i18n|Starburst}} {{Module |NAME=Starburst |MENUCONFIG={{Applications}}->Starburst |STATUS={{stable}} |PINNING=yes (optional) |ECMD=no |DEPENDS=[[DMX Storage]] [[PCA9685]] |REQUIRES= a [http://www.nxp.com/products/automotive/display_instrumentation/led_controllers/PCA9685.html PCA9685]on the i2c bus |CODE=[https://github.com/ethersex/ethersex/tree/master/services/starburst https://github.com/ethersex/ethersex/tree/master/services/starburst] }} Starburst uses the DMX data stored in [[DMX Storage]] and transmits it using [[I2C]] to a [http://www.nxp.com/products/automotive/display_instrumentation/led_controllers/PCA9685.html PCA9685] PWM controller. The PCA9685 is best for driving other circuits like high power LED drivers. Starburst is part of the [[Ethersex Lighting Architecture]]. == Starburst vs. [[StellaLight]] == Starburst advantages: * just needs two pins (3 pins for stroboscope) * has 12-bit PWM, thus can apply the [http://en.wikipedia.org/wiki/Stevens%27_power_law Stevens' power law] * delegates PWM generation => no load on the AVR * saves program space StellaLight advantages: * does not need an extra controller == Slave Address == Enter the [[I2C]] address of the PCA9685 in the menuconfig in decimal format. Here's how to calculate it: Fill in the values for {A0-A5} according to your layout. High: 1 Low: 0 The 7th bit has a fixed value ('''1''') This is a sample for A5=>5V ; {A4-A0}=>GND {| border="1" |fixed |A5 |A4 |A3 |A2 |A1 |A0 |- |1 |1 |0 |0 |0 |0 |0 |} to decimal => 96 == DMX layout == {| border="1" |DMX 0 |DMX 1 |DMX 2 |DMX 3 |DMX 4 |DMX 5 |DMX 6 |DMX 7 |DMX 8 |- |channel 1 |channel 2 |channel 3 |channel 4 |mode 1 |mode 2 |mode 3 |mode 4 |global strobo (optional) |} === Valid Values === '''channel n''' : 0-255 '''mode n''' : '''0''' (instant change) '''1''' (fade to target) '''global strobo''' : 1-25 (results in 1hz - 25hz) - '''0''' => no strobo == Stroboscope support == If you want to use the output enable pin, tick [*] Strobo Effect and add the pin to your hardware pinning file (in this case PORTA PIN0): PCA9685_OE(PA0) [[Category:e6la]] 3cc7f6a551ef5cfc2e087201c5dd2a336366659e 308 298 2011-12-11T16:41:27Z Mgue 312 wikitext text/x-wiki {{i18n|Starburst}} {{Module |NAME=Starburst |MENUCONFIG={{Applications}}->Starburst |STATUS={{stable}} |PINNING=yes (optional) |ECMD=no |DEPENDS=[[DMX Storage]] [[PCA9685]] |REQUIRES= a [http://www.nxp.com/products/automotive/display_instrumentation/led_controllers/PCA9685.html PCA9685]on the i2c bus |CODE=[https://github.com/ethersex/ethersex/tree/master/services/starburst https://github.com/ethersex/ethersex/tree/master/services/starburst] }} [[File:Pca9685pw-pcb.JPG|right|thumb|400px| A PCA9685PW (TSSOP-28 Package) soldered onto a breakout board]] Starburst uses the DMX data stored in [[DMX Storage]] and transmits it using [[I2C]] to a [http://www.nxp.com/products/automotive/display_instrumentation/led_controllers/PCA9685.html PCA9685] PWM controller. The PCA9685 is best for driving other circuits like high power LED drivers. Starburst is part of the [[Ethersex Lighting Architecture]]. == Starburst vs. [[StellaLight]] == Starburst advantages: * just needs two pins (3 pins for stroboscope) * has 12-bit PWM, thus can apply the [http://en.wikipedia.org/wiki/Stevens%27_power_law Stevens' power law] * delegates PWM generation => no load on the AVR * saves program space StellaLight advantages: * does not need an extra controller == Slave Address == Enter the [[I2C]] address of the PCA9685 in the menuconfig in decimal format. Here's how to calculate it: Fill in the values for {A0-A5} according to your layout. High: 1 Low: 0 The 7th bit has a fixed value ('''1''') This is a sample for A5=>5V ; {A4-A0}=>GND {| border="1" |fixed |A5 |A4 |A3 |A2 |A1 |A0 |- |1 |1 |0 |0 |0 |0 |0 |} to decimal => 96 == DMX layout == {| border="1" |DMX 0 |DMX 1 |DMX 2 |DMX 3 |DMX 4 |DMX 5 |DMX 6 |DMX 7 |DMX 8 |- |channel 1 |channel 2 |channel 3 |channel 4 |mode 1 |mode 2 |mode 3 |mode 4 |global strobo (optional) |} === Valid Values === '''channel n''' : 0-255 '''mode n''' : '''0''' (instant change) '''1''' (fade to target) '''global strobo''' : 1-25 (results in 1hz - 25hz) - '''0''' => no strobo == Stroboscope support == If you want to use the output enable pin, tick [*] Strobo Effect and add the pin to your hardware pinning file (in this case PORTA PIN0): PCA9685_OE(PA0) [[Category:e6la]] 24ff6726938274b67c9787c1e14273ff573c751e 14 132 300 2011-12-09T13:21:50Z Mgue 312 Created page with "This category lists all articles about modules listed under "Applications" in the menuconfig." wikitext text/x-wiki This category lists all articles about modules listed under "Applications" in the menuconfig. e323d11f2a6392926e21a45ed8a09e41ecf96b5a 14 133 301 2011-12-09T13:22:18Z Mgue 312 Created page with "This category lists all articles about modules listed under "Protocols" in the menuconfig." wikitext text/x-wiki This category lists all articles about modules listed under "Protocols" in the menuconfig. dca9f3922f762202ff9db70064751c7cbd480c13 14 134 302 2011-12-09T13:22:37Z Mgue 312 Created page with "This category lists all articles about modules listed under "I/O" in the menuconfig." wikitext text/x-wiki This category lists all articles about modules listed under "I/O" in the menuconfig. 677ff37f21f0b89d80da3777739cacff4e2aee33 6 136 305 2011-12-11T16:35:12Z Mgue 312 source is [[File:Applications-development.svg]] wikitext text/x-wiki source is [[File:Applications-development.svg]] dc5d3629adf3b18d06e40bdd3a9f2c7dced5b5c8 10 41 306 166 2011-12-11T16:35:42Z Mgue 312 wikitext text/x-wiki <noinclude>{{i18n|Template:NewWiki}}</noinclude> {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#FFAF4D; border:4px #aaa solid; font-size:95%; color:black; width:auto%; padding: 15px; font-size: 15px" |- |[[Image:Applications-development.png]] |'''Welcome to the new Wiki of the ethersex project.''' This wiki is far from being complete, so please help us by contributing your knowledge! In search of the old wiki? [http://old.ethersex.de Go to old.ethersex.de] |- |} cc244b368fec199a129429db56e216eca53bec6f 6 137 307 2011-12-11T16:38:08Z Mgue 312 PCA9685PW (TSSOP-28 Package) soldered onto a breakout board wikitext text/x-wiki PCA9685PW (TSSOP-28 Package) soldered onto a breakout board f4bab4928ac12c2e9d2b40f6c6d3c7d7d02c4aad 0 29 309 82 2011-12-12T14:34:10Z GooPie4o 265 /* ECMD */ wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR Receivers->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP is a port of the [http://www.mikrocontroller.net/articles/IRMP infrared multi-protocol decoder] for [[Ethersex]]. == Connection == The reception of IR signals is performed by a receiver TSOP1736 type (or similar). This may be connected to any pin. The interrogation of the pins and the decoding of the IR protocol is done in an ISR, which occupies one 8-bit timer of the ATmegas. When sending the signal with the carrier frequency of the respective IR Protocol is [[PWM]] modulated. This is another 8-bit timer of the ATmegas (OC0/OC2) is demonstrated. On the [[Etherrape]] board takes a [[NE555]] this function, ie the option ''Use external modulator for the transmitter'' is activated. It saves a timer on the [[AVR]] is set at a carrier frequency. Example of a ATMega32 from: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Meaning: * IRMP_RX - pin the IR receiver is connected to * IRMP_USE_TIMER2 - use Timer2 for receiver, Timer0 for sender (undef = reversed) * IRMP_RX_LOW_ACTIVE - the IR receiver is low-active (undef = high-active) * IRMP_RX_LED_LOW_ACTIVE - the control LED of the receiver is switched to USS (undef = switched to GND) * IRMP_TX - pin the IR sender is connected to (=output of Timer0 or Timer2, see IRMP_USE_TIMER2)<br>'''Caution: 0A to 2A if MCU with A / B channel''' * IRMP_TX_LED_LOW_ACTIVE - the control LED of the sender is switched to USS (undef = switched to GND) == Configuration == Each supported IR protocol occupies memory of code. Therefore, one should select only the required protocols. A detailed overview of the protocols are the [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail article in the mikrocontroller forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ --- Debugging Flags │ │ [ ] IRMP Debug IRMP also decodes the RC5 protocol, so that the separately [[Ethersex]] contained [[RC5]] decoder is not needed any longer. == [[ECMD]] == IRMP implements a [[ECMD]] interface for reading received and decoded IR commands and send IR commands. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == === Output received characters via [[SYSLOG|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> IRMP_READ checks for received IR code and stores it in the variables IRMP_PROTOCOL, IRMP_ADDRESS, and IRMP_COMMAND IRMP_FLAGS. Return values ​​greater than zero indicate the validity of the variables. If IRMP_FLAGS = 1 it is a repetition. === Control of [[Stella_Light)|Stella]]/Pins by IR commands === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> The script switches the Stella channel 0 to 255 or 0, the remote control is a Denon (Protocol 8). With ''include'' access to the Stella sources granted.<br> Instead of ''"stella_setValue (STELLA_SET_IMMEDIATELY, 0, 255);"'' ''"PIN_SET (LED)"'' and ''"PIN_CLEAR (LED)"'' can be used ([[Named_PIN|named pin]]). |Named PIN]]). === Send IR commands === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 * no tx support yet dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON * no tx support yet IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Command 5678 to device 1234 will be send with one repetition using the NEC protocol. aff6b00d9bc9deeb747774cfae4e5f460a2e38fe 0 30 310 81 2011-12-12T14:36:00Z GooPie4o 265 /* ECMD */ wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR Receivers->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP ist eine Portierung des [http://www.mikrocontroller.net/articles/IRMP Infrarot-Multiprotokoll-Decoders] nach [[Ethersex]]. == Anschluss == Der Empfang der IR-Signale erfolgt durch einen Empfänger vom Typ TSOP1736 (oder ähnlich). Dieser kann an einem beliebigen Pin angeschlossen werden. Die Abfrage des Pins und die Dekodierung des IR-Protokolls erfolgt in einer ISR, die einen 8-Bit-Timer des ATMEGAs belegt. Beim Senden wird das Signal mit der Trägerfrequenz des jeweiligen IR-Protokolls über [[PWM_(Deutsch)|PWM]] moduliert. Dazu wird ein weiterer 8-Bit Timer des ATMEGAs (OC0/OC2) belegt. Auf dem '''[[Etherape_(Deutsch)|Etherrape]]'''-Board übernimmt ein [[NE555_(Deutsch)|NE555]] diese Funktion, d.h. die Option ''Use external modulator for sender'' ist zu aktivieren. Man spart einen Timer des [[AVR_(Deutsch)|AVR]] und ist auf eine Trägerfrequenz festgelegt. Beispiel für einen ATMega32 aus: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Bedeutung: * IRMP_RX - Pin an dem der IR-Empfänger angeschlossen ist * IRMP_USE_TIMER2 - benutze Timer2 für den Empfang, Timer0 für das Senden (undef = umgekehrt) * IRMP_RX_LOW_ACTIVE - der IR-Empfänger ist Low-Aktiv (undef = High-aktiv) * IRMP_RX_LED_LOW_ACTIVE - die Kontroll-LED des Empfängers ist gegen USS geschaltet (undef = gegen GND geschaltet) * IRMP_TX - Pin an dem der IR-Sender angschlossen ist (=Ausgang des Timer0 oder Timer2, vgl. IRMP_USE_TIMER2)<br>'''Achtung: 0A bzw 2A bei MCU mit A/B Kanal''' * IRMP_TX_LED_LOW_ACTIVE - die Kontroll-LED des Senders ist gegen USS geschaltet (undef = gegen GND geschaltet) == Konfiguration == Jedes unterstützte IR-Protokoll "verbrät" Speicher an Code. Deshalb sollte man nur die benötigten Protokolle auswählen. Eine detailierte Übersicht über die Protokolle gibt der [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail Artikel im Mikrocontroller Forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ --- Debugging Flags │ │ [ ] IRMP Debug IRMP dekodiert auch das RC5-Protokoll, so dass der separat in [[Ethersex_(Deutsch)|Ethersex]] enthaltene [[RC5_(Deutsch)|RC5]]-Dekoder nicht länger benötigt wird. == [[ECMD_(Deutsch)|ECMD]] == IRMP implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle zum Auslesen empfangener und dekodierter IR-Kommandos und zum Senden von IR-Kommandos. Siehe [[ECMD_Reference|ECMD Referenz]]. == [[Control6_(Deutsch)|Control6]] == === Ausgabe empfangener IR-Zeichen via [[SYSLOG_(Deutsch)|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> Mit IRMP_READ wird auf empfangenen IR-Code geprüft und dieser in die Variablen IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND und IRMP_FLAGS gespeichert. Rückgabewerte größer Null signalisieren die Gültigkeit der Variablen. Bei IRMP_FLAGS=1 handelt es sich um eine Wiederholung. === Steuern von [[Stella_Light_(Deutsch)|Stella]]/Pins durch IR-Zeichen === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> Das Script schaltet den Stella Channel 0 auf 255 oder auf 0, die Fernbedienung ist hier eine Denon (Protocol 8). Mit ''include'' wurde dem Script der Zugriff auf die Stellasourcen gestattet.<br> Statt ''"stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255);"'' kann auch ''"PIN_SET(LED)"'' und ''"PIN_CLEAR(LED)"'' verwendet werden ([[Named_PIN_(Deutsch)|Named PIN]]). === Senden von IR-Zeichen === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 * no tx support yet dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON * no tx support yet IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Kommando 5678 an Gerät 1234 wird mit einer Wiederholung im NEC-Protokoll gesendet. 266509a1c102b41b2502d0fe1d9c150f6831f512 0 57 313 196 2011-12-17T14:34:18Z GooPie4o 265 Protected "[[Main Page (Deutsch)]]" ([edit=sysop] (indefinite) [move=sysop] (indefinite)) wikitext text/x-wiki {{i18n|Main Page}} {{NewWiki (Deutsch)}} == Willkommen bei ethersex.de - der universalen AVR Firmware == {{Facts (Deutsch)}} {|style="width:100%" |style="width:50%"|{{Getting Started (Deutsch)}} |style="width:50%"|{{Documentation (Deutsch)}} |- |} 1c3a81ad2fb9bacd3b1d0a82f6117c238294a6b3 10 52 314 190 2011-12-20T16:47:03Z Mgue 312 changed icon wikitext text/x-wiki <noinclude>{{i18n|Template:NewWiki}}</noinclude> {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#FFAF4D; border:4px #aaa solid; font-size:95%; color:black; width:auto%; padding: 15px; font-size: 15px" |- |[[Image:Applications-development.png]] |'''Willkommen im neuen Wiki des Ethersex-Projekts.''' Dieses Wiki ist noch lange nicht fertig. Bitte hilf uns, indem du dein Wissen hier einbringst. Auf der Suche nach dem alten Wiki? [http://old.ethersex.de Go to old.ethersex.de] |- |} 3655c2dbc273b45e7ca9055567cbed549d0ac178 0 138 316 2011-12-28T00:23:13Z Mgue 312 first version wikitext text/x-wiki {{i18n|StellaLight}} {{Module |NAME=StellaLight |MENUCONFIG={{Applications}}->StellaLight: Multichannel pwm |STATUS={{stable}} |PINNING=yes |ECMD=yes |DEPENDS=[[DMX Storage]] (optional) |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/services/stella https://github.com/ethersex/ethersex/tree/master/services/stella] }} StellaLight produces PWM signals on up to 16 independent pins for driving LEDs or servo motors. == Internals == Stella uses an 8-bit Timer of your choice for producing the PWM signals. Since the overflow interrupts need to be very consistent, StellaLight will not work flawlessy when other modules are active that disable the interrupts for a short amount of time. This is a list of module where you can expect some problems with: [[Onewire]], [[RFM12]] (please add more if you find some). Moreover StellaLight does not support [http://en.wikipedia.org/wiki/Gamma_correction Gamma Correction] since that would require at least 10-12 bit PWM. == Configuration == In Menuconfig you can select the prescaler. '''The higher the frequency, the more often the StellaLight PWM functions will be executed, leading to an higher overall load of the device. So if you run into problems, try decreasing the frequency.''' {| border="1" ! Option ! Prescaler |- | Very slow | 1024 |- | Slow | 256 |- | Normal | 128 |- | Fast | 64 |- |} You can calculate the resulting frequency by using this formula: F_CPU: The clockspeed of your AVR (like 8Mhz, 16Mhz etc.) ''F_STELLA=F_CPU/Prescaler/512'' So given a setting of "Normal" on a 16Mhz device will result in '''244Hz''' which is pretty good for most setups. So more than enough for the human eye (10 times more) If you have enabled [[DMX Storage]] in Menuconfig, you also can set the universe and start channel of StellaLight, so you can control StellaLight via [[Artnet]] or [[DMX FXSlot]]. == Pinning == STELLA_PORT1_RANGE(PXI,PXJ) sets the range of StellaLight controlled pins on PORTX STELLA_PORT2_RANGE(PX2I,PX2J) sets the range of StellaLight controlled pins on PORTX2 STELLA_USE_TIMER(2) programs Timer2 for StellaLight Two examples: '''1. 3 LEDs (e.g. RGB) on PORTA, Pins: 0,1,2''' <source> ifdef(`conf_STELLA', `dnl STELLA_PORT1_RANGE(PA0,PA2) STELLA_USE_TIMER(2) ')dnl </source> '''2. 15 LEDs (e.g. 5x RGB) on PORTA, Pins: 0,1,2,3,4,5,6,7 on PORTD, Pins: 0,1,2,3,4,5,6''' <source> ifdef(`conf_STELLA', `dnl STELLA_PORT1_RANGE(PA0,PA7) STELLA_PORT1_RANGE(PD0,PD6) STELLA_USE_TIMER(2) ')dnl </source> == Alternative == Have a look at [[Starburst]] for an improved and more resource-conserving solution. dd208f0be165e721106ba6e966753a66a35ae3fd 317 316 2011-12-28T00:29:08Z Mgue 312 table wikitext text/x-wiki {{i18n|StellaLight}} {{Module |NAME=StellaLight |MENUCONFIG={{Applications}}->StellaLight: Multichannel pwm |STATUS={{stable}} |PINNING=yes |ECMD=yes |DEPENDS=[[DMX Storage]] (optional) |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/services/stella https://github.com/ethersex/ethersex/tree/master/services/stella] }} StellaLight produces PWM signals on up to 16 independent pins for driving LEDs or servo motors. == Internals == Stella uses an 8-bit Timer of your choice for producing the PWM signals. Since the overflow interrupts need to be very consistent, StellaLight will not work flawlessy when other modules are active that disable the interrupts for a short amount of time. This is a list of module where you can expect some problems with: [[Onewire]], [[RFM12]] (please add more if you find some). Moreover StellaLight does not support [http://en.wikipedia.org/wiki/Gamma_correction Gamma Correction] since that would require at least 10-12 bit PWM. == Configuration == In Menuconfig you can select the prescaler. '''The higher the frequency, the more often the StellaLight PWM functions will be executed, leading to an higher overall load of the device. So if you run into problems, try decreasing the frequency.''' {| border="1" ! Option ! Prescaler |- | Very slow | 1024 |- | Slow | 256 |- | Normal | 128 |- | Fast | 64 |- |} You can calculate the resulting frequency by using this formula: F_CPU: The clockspeed of your AVR (like 8Mhz, 16Mhz etc.) ''F_STELLA=F_CPU/Prescaler/512'' So given a setting of "Normal" on a 16Mhz device will result in '''244Hz''' which is pretty good for most setups. So more than enough for the human eye (10 times more) If you have enabled [[DMX Storage]] in Menuconfig, you also can set the universe and start channel of StellaLight, so you can control StellaLight via [[Artnet]] or [[DMX FXSlot]]. == Pinning == {| border="1" |- | STELLA_PORT1_RANGE(PX'''I''',PX'''J''') | sets the range ('''I''' to '''J''') of StellaLight controlled pins on PORTX |- | STELLA_PORT2_RANGE(PX2'''I''',PX2'''J''') | sets the range ('''I''' to '''J''') of StellaLight controlled pins on PORTX2 |- | STELLA_USE_TIMER('''I''') | programs Timer'''I''' for StellaLight |- |} Two examples: '''1. 3 LEDs (e.g. RGB) on PORTA, Pins: 0,1,2''' <source> ifdef(`conf_STELLA', `dnl STELLA_PORT1_RANGE(PA0,PA2) STELLA_USE_TIMER(2) ')dnl </source> '''2. 15 LEDs (e.g. 5x RGB) on PORTA, Pins: 0,1,2,3,4,5,6,7 on PORTD, Pins: 0,1,2,3,4,5,6''' <source> ifdef(`conf_STELLA', `dnl STELLA_PORT1_RANGE(PA0,PA7) STELLA_PORT1_RANGE(PD0,PD6) STELLA_USE_TIMER(2) ')dnl </source> == Alternative == Have a look at [[Starburst]] for an improved and more resource-conserving solution. 1eba4b9071f41fffa9b43d0d4263813e03ff81b6 321 317 2011-12-29T20:59:50Z Mgue 312 more categories wikitext text/x-wiki {{i18n|StellaLight}} {{Module |NAME=StellaLight |MENUCONFIG={{Applications}}->StellaLight: Multichannel pwm |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |DEPENDS=[[DMX Storage]] (optional) |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/services/stella https://github.com/ethersex/ethersex/tree/master/services/stella] }} StellaLight produces PWM signals on up to 16 independent pins for driving LEDs or servo motors. == Internals == Stella uses an 8-bit Timer of your choice for producing the PWM signals. Since the overflow interrupts need to be very consistent, StellaLight will not work flawlessy when other modules are active that disable the interrupts for a short amount of time. This is a list of module where you can expect some problems with: [[Onewire]], [[RFM12]] (please add more if you find some). Moreover StellaLight does not support [http://en.wikipedia.org/wiki/Gamma_correction Gamma Correction] since that would require at least 10-12 bit PWM. == Configuration == In Menuconfig you can select the prescaler. '''The higher the frequency, the more often the StellaLight PWM functions will be executed, leading to an higher overall load of the device. So if you run into problems, try decreasing the frequency.''' {| border="1" ! Option ! Prescaler |- | Very slow | 1024 |- | Slow | 256 |- | Normal | 128 |- | Fast | 64 |- |} You can calculate the resulting frequency by using this formula: F_CPU: The clockspeed of your AVR (like 8Mhz, 16Mhz etc.) ''F_STELLA=F_CPU/Prescaler/512'' So given a setting of "Normal" on a 16Mhz device will result in '''244Hz''' which is pretty good for most setups. So more than enough for the human eye (10 times more) If you have enabled [[DMX Storage]] in Menuconfig, you also can set the universe and start channel of StellaLight, so you can control StellaLight via [[Artnet]] or [[DMX FXSlot]]. == Pinning == {| border="1" |- | STELLA_PORT1_RANGE(PX'''I''',PX'''J''') | sets the range ('''I''' to '''J''') of StellaLight controlled pins on PORTX |- | STELLA_PORT2_RANGE(PX2'''I''',PX2'''J''') | sets the range ('''I''' to '''J''') of StellaLight controlled pins on PORTX2 |- | STELLA_USE_TIMER('''I''') | programs Timer'''I''' for StellaLight |- |} Two examples: '''1. 3 LEDs (e.g. RGB) on PORTA, Pins: 0,1,2''' <source> ifdef(`conf_STELLA', `dnl STELLA_PORT1_RANGE(PA0,PA2) STELLA_USE_TIMER(2) ')dnl </source> '''2. 15 LEDs (e.g. 5x RGB) on PORTA, Pins: 0,1,2,3,4,5,6,7 on PORTD, Pins: 0,1,2,3,4,5,6''' <source> ifdef(`conf_STELLA', `dnl STELLA_PORT1_RANGE(PA0,PA7) STELLA_PORT1_RANGE(PD0,PD6) STELLA_USE_TIMER(2) ')dnl </source> == Alternative == Have a look at [[Starburst]] for an improved and more resource-conserving solution. [[Category:e6la]] dc75893f142a9ba594fe470b3b5272689c3ad083 0 36 318 107 2011-12-29T12:02:47Z GooPie4o 265 /* Coding Style */ wikitext text/x-wiki {{i18n|Contributing}} = How to Contribute = We are a truly open source [[community]] and therefore appreciate any effort to make ethersex even more awesome. You can help in various ways like writing code, supporting other users (e.g. on [[Community|IRC]]) or expanding this wiki with your knowledge. == Writing Code == All your code needs to be [http://www.gnu.org/copyleft/gpl.html ''GPLv3 or later''] if you plan to publish your code. TODO == Coding Style == To keep the source code readable some formatting rules should be adhered to. There is further evidence found in [[own_module]]. The supplied script ''scripts/indent.sh'' may be used to format the source code before committing it to the repository. Please keep in mind that pull requests might be rejected if source violates formatting rules. * GPLv3 license header if none exists * Maximum line length is 78 chars. * No text editor specific formatting rules. * Use spaces instead of tabs, two spaces per indent level. * Braces on single line, no additional indent. * No spaces between the name of the procedure being called and the `('. * Put the `*' character at the left of comments. * Break long lines after operators. * Macros are defined just below the includes Function prototypes are defined as <source> void func(void); </source> and implemented as <source> void func(void) { /* content */ } </source> == Patches == For version control we use [http://git-scm.com/ Git]. Our repository is hosted [https://github.com/ethersex/ethersex on github]. If you haven't work with git so far, you should familiarize yourself with it by reading [http://help.github.com/ the beginners guide on github]. === Fork us! === [http://help.github.com/fork-a-repo/ The help page on github] pretty much explains how that works. To make your life easier you should create a branch for '''each''' new feature you will be implementing. '''NEVER''' touch the ''master'' branch - or you probably will not be able to merge upstream changes into your fork without conflicts. === Pull requests === Pull requests are the easiest way to get your code integrated into the ethersex code base. Developers don't need to send patches around on mailing lists and can respond faster to questions/concerns maintainers may have about the code. Please read [http://help.github.com/send-pull-requests/ this page] in case you don't know who to use pull requests on github. d8190c39f38a8c36ec6e2ee04c9d422fe71bc07c 319 318 2011-12-29T12:31:06Z GooPie4o 265 /* Coding Style */ wikitext text/x-wiki {{i18n|Contributing}} = How to Contribute = We are a truly open source [[community]] and therefore appreciate any effort to make ethersex even more awesome. You can help in various ways like writing code, supporting other users (e.g. on [[Community|IRC]]) or expanding this wiki with your knowledge. == Writing Code == All your code needs to be [http://www.gnu.org/copyleft/gpl.html ''GPLv3 or later''] if you plan to publish your code. TODO == Coding Style == To keep the source code readable some formatting rules should be adhered to. There is further evidence found in [[own_module]]. The supplied script ''scripts/indent.sh'' may be used to format the source code before committing it to the repository. Please keep in mind that pull requests might be rejected if source violates formatting rules. * GPLv3 license header if none exists * Maximum line length is 78 chars. * No text editor specific formatting rules. * Use spaces instead of tabs, two spaces per indent level. * Braces on single line, no additional indent. * No spaces between the name of the procedure being called and the `('. * Put the `*' character at the left of comments. * Break long lines after operators. * Macros are defined just below the includes Function prototypes are defined as. <source> void func(void); </source> and implemented as <source> void func(void) { /* content */ } </source> == Patches == For version control we use [http://git-scm.com/ Git]. Our repository is hosted [https://github.com/ethersex/ethersex on github]. If you haven't work with git so far, you should familiarize yourself with it by reading [http://help.github.com/ the beginners guide on github]. === Fork us! === [http://help.github.com/fork-a-repo/ The help page on github] pretty much explains how that works. To make your life easier you should create a branch for '''each''' new feature you will be implementing. '''NEVER''' touch the ''master'' branch - or you probably will not be able to merge upstream changes into your fork without conflicts. === Pull requests === Pull requests are the easiest way to get your code integrated into the ethersex code base. Developers don't need to send patches around on mailing lists and can respond faster to questions/concerns maintainers may have about the code. Please read [http://help.github.com/send-pull-requests/ this page] in case you don't know who to use pull requests on github. 0b508a951b4b57654331dac4239e32330b604abe 0 139 320 2011-12-29T20:59:06Z GooPie4o 265 Created page with "{{i18n|Quick Start Guide}}" wikitext text/x-wiki {{i18n|Quick Start Guide}} d774c5e348122582b112566254620c8cb7bc589f 0 139 322 320 2011-12-29T21:00:43Z GooPie4o 265 wikitext text/x-wiki {{i18n|own_module}} 296317ac8ce784088fb749328b6d924afe47f48c 14 140 323 2011-12-29T21:00:47Z Mgue 312 Created page with "These modules can be considered as stable." wikitext text/x-wiki These modules can be considered as stable. 72cf045fbe47d8478e92adadbcf4adc07d6f8915 0 36 324 319 2011-12-29T21:01:57Z GooPie4o 265 /* Coding Style */ wikitext text/x-wiki {{i18n|Contributing}} = How to Contribute = We are a truly open source [[community]] and therefore appreciate any effort to make ethersex even more awesome. You can help in various ways like writing code, supporting other users (e.g. on [[Community|IRC]]) or expanding this wiki with your knowledge. == Writing Code == All your code needs to be [http://www.gnu.org/copyleft/gpl.html ''GPLv3 or later''] if you plan to publish your code. TODO == Coding Style == To keep the source code readable some formatting rules should be adhered to. There is further evidence found in [[own_module|''adding your own module'']]. The supplied script ''scripts/indent.sh'' may be used to format the source code before committing it to the repository. Please keep in mind that pull requests might be rejected if source violates formatting rules. * GPLv3 license header if none exists * Maximum line length is 78 chars. * No text editor specific formatting rules. * Use spaces instead of tabs, two spaces per indent level. * Braces on single line, no additional indent. * No spaces between the name of the procedure being called and the `('. * Put the `*' character at the left of comments. * Break long lines after operators. * Macros are defined just below the includes Function prototypes are defined as. <source> void func(void); </source> and implemented as <source> void func(void) { /* content */ } </source> == Patches == For version control we use [http://git-scm.com/ Git]. Our repository is hosted [https://github.com/ethersex/ethersex on github]. If you haven't work with git so far, you should familiarize yourself with it by reading [http://help.github.com/ the beginners guide on github]. === Fork us! === [http://help.github.com/fork-a-repo/ The help page on github] pretty much explains how that works. To make your life easier you should create a branch for '''each''' new feature you will be implementing. '''NEVER''' touch the ''master'' branch - or you probably will not be able to merge upstream changes into your fork without conflicts. === Pull requests === Pull requests are the easiest way to get your code integrated into the ethersex code base. Developers don't need to send patches around on mailing lists and can respond faster to questions/concerns maintainers may have about the code. Please read [http://help.github.com/send-pull-requests/ this page] in case you don't know who to use pull requests on github. 825dbb9ea49a42cad7074948371224f4ce297129 330 324 2012-01-05T20:58:17Z Sascha 423 who / how typo wikitext text/x-wiki {{i18n|Contributing}} = How to Contribute = We are a truly open source [[community]] and therefore appreciate any effort to make ethersex even more awesome. You can help in various ways like writing code, supporting other users (e.g. on [[Community|IRC]]) or expanding this wiki with your knowledge. == Writing Code == All your code needs to be [http://www.gnu.org/copyleft/gpl.html ''GPLv3 or later''] if you plan to publish your code. TODO == Coding Style == To keep the source code readable some formatting rules should be adhered to. There is further evidence found in [[own_module|''adding your own module'']]. The supplied script ''scripts/indent.sh'' may be used to format the source code before committing it to the repository. Please keep in mind that pull requests might be rejected if source violates formatting rules. * GPLv3 license header if none exists * Maximum line length is 78 chars. * No text editor specific formatting rules. * Use spaces instead of tabs, two spaces per indent level. * Braces on single line, no additional indent. * No spaces between the name of the procedure being called and the `('. * Put the `*' character at the left of comments. * Break long lines after operators. * Macros are defined just below the includes Function prototypes are defined as. <source> void func(void); </source> and implemented as <source> void func(void) { /* content */ } </source> == Patches == For version control we use [http://git-scm.com/ Git]. Our repository is hosted [https://github.com/ethersex/ethersex on github]. If you haven't work with git so far, you should familiarize yourself with it by reading [http://help.github.com/ the beginners guide on github]. === Fork us! === [http://help.github.com/fork-a-repo/ The help page on github] pretty much explains how that works. To make your life easier you should create a branch for '''each''' new feature you will be implementing. '''NEVER''' touch the ''master'' branch - or you probably will not be able to merge upstream changes into your fork without conflicts. === Pull requests === Pull requests are the easiest way to get your code integrated into the ethersex code base. Developers don't need to send patches around on mailing lists and can respond faster to questions/concerns maintainers may have about the code. Please read [http://help.github.com/send-pull-requests/ this page] in case you don't know how to use pull requests on github. dc2207b4f86c9cbaecc8896a8bc1493a462ed1bd 338 330 2012-01-09T19:41:52Z Mgue 312 markup wikitext text/x-wiki {{i18n|Contributing}} = How to Contribute = We are a truly open source [[community]] and therefore appreciate any effort to make ethersex even more awesome. You can help in various ways like writing code, supporting other users (e.g. on [[Community|IRC]]) or expanding this wiki with your knowledge. == Writing Code == All your code needs to be [http://www.gnu.org/copyleft/gpl.html ''GPLv3 or later''] if you plan to publish your code. TODO == Coding Style == To keep the source code readable some formatting rules should be adhered to. There is further evidence found in [[own_module|''adding your own module'']]. The supplied script ''scripts/indent.sh'' may be used to format the source code before committing it to the repository. Please keep in mind that pull requests might be rejected if source violates formatting rules. * GPLv3 license header if none exists * Maximum line length is 78 chars. * No text editor specific formatting rules. * Use spaces instead of tabs, two spaces per indent level. * Braces on single line, no additional indent. * No spaces between the name of the procedure being called and the `('. * Put the `*' character at the left of comments. * Break long lines after operators. * Macros are defined just below the includes Function prototypes are defined as. <source lang="c"> void func(void); </source> and implemented as <source lang="c"> void func(void) { /* content */ } </source> == Patches == For version control we use [http://git-scm.com/ Git]. Our repository is hosted [https://github.com/ethersex/ethersex on github]. If you haven't work with git so far, you should familiarize yourself with it by reading [http://help.github.com/ the beginners guide on github]. === Fork us! === [http://help.github.com/fork-a-repo/ The help page on github] pretty much explains how that works. To make your life easier you should create a branch for '''each''' new feature you will be implementing. '''NEVER''' touch the ''master'' branch - or you probably will not be able to merge upstream changes into your fork without conflicts. === Pull requests === Pull requests are the easiest way to get your code integrated into the ethersex code base. Developers don't need to send patches around on mailing lists and can respond faster to questions/concerns maintainers may have about the code. Please read [http://help.github.com/send-pull-requests/ this page] in case you don't know how to use pull requests on github. 4347726e6d558f1a23cc68028f65a049b1933707 0 138 325 321 2011-12-29T21:03:36Z Mgue 312 explanation wikitext text/x-wiki {{i18n|StellaLight}} {{Module |NAME=StellaLight |MENUCONFIG={{Applications}}->StellaLight: Multichannel pwm |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |DEPENDS=[[DMX Storage]] (optional) |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/services/stella https://github.com/ethersex/ethersex/tree/master/services/stella] }} StellaLight produces PWM signals on up to 16 independent pins for driving LEDs or servo motors. == Internals == Stella uses an 8-bit Timer of your choice for producing the PWM signals. Since the overflow interrupts need to be very consistent, StellaLight will not work flawlessy when other modules are active that disable the interrupts for a short amount of time. This is a list of module where you can expect some problems with: [[Onewire]], [[RFM12]] (please add more if you find some). Moreover StellaLight does not support [http://en.wikipedia.org/wiki/Gamma_correction Gamma Correction] since that would require at least 10-12 bit PWM. == Configuration == In Menuconfig you can select the prescaler. '''The higher the frequency, the more often the StellaLight PWM functions will be executed, leading to an higher overall load of the device. So if you run into problems, try decreasing the frequency, ergo increase the prescaler.''' {| border="1" ! Option ! Prescaler |- | Very slow | 1024 |- | Slow | 256 |- | Normal | 128 |- | Fast | 64 |- |} You can calculate the resulting frequency by using this formula: F_CPU: The clockspeed of your AVR (like 8Mhz, 16Mhz etc.) ''F_STELLA=F_CPU/Prescaler/512'' So given a setting of "Normal" on a 16Mhz device will result in '''244Hz''' which is pretty good for most setups. So more than enough for the human eye (10 times more) If you have enabled [[DMX Storage]] in Menuconfig, you also can set the universe and start channel of StellaLight, so you can control StellaLight via [[Artnet]] or [[DMX FXSlot]]. == Pinning == {| border="1" |- | STELLA_PORT1_RANGE(PX'''I''',PX'''J''') | sets the range ('''I''' to '''J''') of StellaLight controlled pins on PORTX |- | STELLA_PORT2_RANGE(PX2'''I''',PX2'''J''') | sets the range ('''I''' to '''J''') of StellaLight controlled pins on PORTX2 |- | STELLA_USE_TIMER('''I''') | programs Timer'''I''' for StellaLight |- |} Two examples: '''1. 3 LEDs (e.g. RGB) on PORTA, Pins: 0,1,2''' <source> ifdef(`conf_STELLA', `dnl STELLA_PORT1_RANGE(PA0,PA2) STELLA_USE_TIMER(2) ')dnl </source> '''2. 15 LEDs (e.g. 5x RGB) on PORTA, Pins: 0,1,2,3,4,5,6,7 on PORTD, Pins: 0,1,2,3,4,5,6''' <source> ifdef(`conf_STELLA', `dnl STELLA_PORT1_RANGE(PA0,PA7) STELLA_PORT1_RANGE(PD0,PD6) STELLA_USE_TIMER(2) ')dnl </source> == Alternative == Have a look at [[Starburst]] for an improved and more resource-conserving solution. [[Category:e6la]] 1a9891704887c6b19f68971e0a9a9d5bda0feadb 333 325 2012-01-06T11:44:35Z Mgue 312 source tag fixed wikitext text/x-wiki {{i18n|StellaLight}} {{Module |NAME=StellaLight |MENUCONFIG={{Applications}}->StellaLight: Multichannel pwm |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |DEPENDS=[[DMX Storage]] (optional) |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/services/stella https://github.com/ethersex/ethersex/tree/master/services/stella] }} StellaLight produces PWM signals on up to 16 independent pins for driving LEDs or servo motors. == Internals == Stella uses an 8-bit Timer of your choice for producing the PWM signals. Since the overflow interrupts need to be very consistent, StellaLight will not work flawlessy when other modules are active that disable the interrupts for a short amount of time. This is a list of module where you can expect some problems with: [[Onewire]], [[RFM12]] (please add more if you find some). Moreover StellaLight does not support [http://en.wikipedia.org/wiki/Gamma_correction Gamma Correction] since that would require at least 10-12 bit PWM. == Configuration == In Menuconfig you can select the prescaler. '''The higher the frequency, the more often the StellaLight PWM functions will be executed, leading to an higher overall load of the device. So if you run into problems, try decreasing the frequency, ergo increase the prescaler.''' {| border="1" ! Option ! Prescaler |- | Very slow | 1024 |- | Slow | 256 |- | Normal | 128 |- | Fast | 64 |- |} You can calculate the resulting frequency by using this formula: F_CPU: The clockspeed of your AVR (like 8Mhz, 16Mhz etc.) ''F_STELLA=F_CPU/Prescaler/512'' So given a setting of "Normal" on a 16Mhz device will result in '''244Hz''' which is pretty good for most setups. So more than enough for the human eye (10 times more) If you have enabled [[DMX Storage]] in Menuconfig, you also can set the universe and start channel of StellaLight, so you can control StellaLight via [[Artnet]] or [[DMX FXSlot]]. == Pinning == {| border="1" |- | STELLA_PORT1_RANGE(PX'''I''',PX'''J''') | sets the range ('''I''' to '''J''') of StellaLight controlled pins on PORTX |- | STELLA_PORT2_RANGE(PX2'''I''',PX2'''J''') | sets the range ('''I''' to '''J''') of StellaLight controlled pins on PORTX2 |- | STELLA_USE_TIMER('''I''') | programs Timer'''I''' for StellaLight |- |} Two examples: '''1. 3 LEDs (e.g. RGB) on PORTA, Pins: 0,1,2''' <source lang="c"> ifdef(`conf_STELLA', `dnl STELLA_PORT1_RANGE(PA0,PA2) STELLA_USE_TIMER(2) ')dnl </source> '''2. 15 LEDs (e.g. 5x RGB) on PORTA, Pins: 0,1,2,3,4,5,6,7 on PORTD, Pins: 0,1,2,3,4,5,6''' <source lang="c" > ifdef(`conf_STELLA', `dnl STELLA_PORT1_RANGE(PA0,PA7) STELLA_PORT1_RANGE(PD0,PD6) STELLA_USE_TIMER(2) ')dnl </source> == Alternative == Have a look at [[Starburst]] for an improved and more resource-conserving solution. [[Category:e6la]] d681f155be55c84619df65a6e141de6f75b272bc 0 141 326 2011-12-29T21:08:36Z GooPie4o 265 Created page with "Hier findest du die wichtigsten Informationen, um dein eigenes Modul entwickeln zu können. Beachte bitte auch den projektweit gültigen [[Coding_style|coding style]] und weitere…" wikitext text/x-wiki Hier findest du die wichtigsten Informationen, um dein eigenes Modul entwickeln zu können. Beachte bitte auch den projektweit gültigen [[Coding_style|coding style]] und weitere Infos wie unter [[Pins in Ethersex definieren]]. == Lizenz == Damit dein Modul mit ethersex veröffentlicht werden kann, musst du deinen Code unter eine GPLv3-kompatible Lizenz stellen. Füge dazu am besten folgenen Lizenzkopf in jede deiner Quellcode Dateien (*.h,*.c) ein: /* * * Copyright (c) 2012 by DEIN_NAME <DAVOR@DANACH.net> * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * as published by the Free Software Foundation; either version 3 * of the License, or (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. * * For more information on the GPL, please go to: * http://www.gnu.org/copyleft/gpl.html */ * Vergiss nicht, DEIN_NAME durch deinen Namen zu ersetzen. == Richtiges Verzeichnis == Du kannst dein Modul in eines der Verzeichnisse „hardware“, „services“ oder „protocols“ einsortieren. Wenn dein Modul mehrere dieser Kategorien erfüllt, muss das Modul eventuell in kleinere Untermodule aufgeteilt werden. Genaue Beschreibungen findest du im jeweiligen Verzeichnis in der Datei "content.txt". Wenn du dir nicht sicher bist, wo dein Modul genau einsortiert werden sollte, frag in der Mailingliste nach. Die 3 Kategorien grob umrissen: * Hardware: Module, die es ermöglichen externe Hardware anzusteuern. * Services: Module, die Anwendungen/Daemons/Services realisieren. * Protocols: Module, die Protokolle implementieren. == Dateien in Make-Prozess aufnehmen == Du hast in einem beliebigen Unterverzeichnis eine Datei hinzugefügt und möchtest natürlich, dass das Make-System diese jetzt auch mit berücksichtigt. Dazu musst du ein Makefile erstellen, welches beispielsweise wie folgt aussehen kann: <pre> TOPDIR ?= ../.. include $(TOPDIR)/.config $(DC3840_SUPPORT)_SRC += hardware/camera/dc3840.c ############################################################################## # generic fluff include $(TOPDIR)/scripts/rules.mk </pre> Anstelle der Variable, die auf _SRC endet, kannst du eine der folgenden Alternativen wählen: # Die Datei soll immer mit eingelinkt werden.<pre>SRC += Pfad/deinedatei.c</pre> # Die Datei soll in Abhängigkeit von einer Konfigurationsoption aus Menuconfig mit eingebunden werden.<pre>${DEINGENIALESMODUL_SUPPORT}_SRC += Pfad/deinedatei.c</pre> # Die Datei soll in Abhängigkeit von einer Konfigurationsoption mit eingebunden werden, wenn der ECMD-Parser aktiviert ist.<pre>${DEINGENIALESMODUL_SUPPORT}_ECMD_SRC += Pfad/deinedatei.c</pre> Abhängig von der Ordnertiefe des von dir angelegten Ordners musst du selbstverständlich die Zahl der ''../'' betreffend ''TOPDIR'' anpassen. Weiterhin musst du dein Makefile dem eigentlichen Makefile in $(TOPDIR) bekannt machen, indem du es folgendermaßen hinzufügst: SUBDIRS += hardware/camera == Menuconfig == Um dein Modul zur grafischen Konfiguration hinzuzufügen (make menuconfig), brauchst du im Ordner deines Moduls eine Datei namens config.in, beispielsweise mit folgendem Inhalt: dep_bool_menu 'Genius module' DEINGENIALESMODUL_SUPPORT $TCP_SUPPORT Dieser Eintrag bedeutet, dass du dein Modul nur dann aktivieren kannst, wenn TCP_SUPPORT aktiviert ist. Weiters wird hier noch ein Untermenü angelegt. Um dein Modul ohne Abhängigkeiten und ohne zusätzlichem Menü aktivieren zu können solltest du folgende Methode wählen: bool 'Genius module' DEINGENIALESMODUL_SUPPORT Dieses musst du, analog zum Makefile, in $(TOPDIR)/config.in hinzufügen: source hardware/camera/config.in == Funktion beim Boot und Periodisch aufrufen lassen == # Du hast ein neues Modul entwickelt, dieses Enthält eine Initialisierungsfunktion, die beim Start der Ethersex-Firmware aufgerufen werden muss. # Dein Modul enthält eine Funktion, die nach Möglichkeit ständig wieder aufgerufen wird (bzw. möglichst oft, soviel Rechenzeit wie die anderen Applikationen die ebenfalls ihre Dienste verrichten sollen, übrig lassen) Hierzu gibt es die ''Ethersex Meta''-Bereiche, die du evtl. bereits am Ende der einen oder anderen C-Datei entdeckt hast. Diese haben grundsätzlich den folgenden Aufbau: <pre> /* -- Ethersex META -- mainloop(stella_process) init(stella_init) */ </pre> Diese Zeilen, am Dateiende eingefügt, sorgen dafür, dass die Funktion ''stella_init'' einmal beim Start der von dir modifizierten Ethersex-Firmware aufgerufen wird und die Funktion ''stella_process' möglichst oft. Du kannst in den Meta-Bereich auch mehrere ''init''-Direktiven aufnehmen, etc. Weitere Direktiven sind: * '''initearly''' - funktioniert wie ''init''. Die Funktionen werden nur vor ''init'' aufgerufen. Dies ist bei Abhängigkeiten praktisch, in der Regel solltest du jedoch ''init'' verwenden. * '''net_init''' - zum Initialisieren von Netzwerkanwendungen. Die Funktionen werden nach den ''init''-Funktionen ausgeführt. * '''startup''' - diese Funktionen werden vor Aufruf der Mainloop gestartet. Der Sendmail-Service sendet hier beispielsweise die Startnachricht. * '''timer''' - Periodisch (alle 20ms) wie bei mainloop. Beispiel: timer(50, function()) ruft function() alle 50*20ms auf, also 1x pro Sekunde. * '''header''' - nicht dokumentiert Bei den aufzurufenden Funktionen muss bei init(<fkt>) die Funktion ohne Klammern und bei timer(<int>, <fkt>()) mit Klammern geschrieben werden. == Debug-Ausgaben == Für eingebettete Systeme zu programmieren kann manchmal ziemlich nervenaufreibend sein. In der Regel hat man nicht die nötige Hardware (JTAG) um step-by-step Debugging durchführen zu können. Der ethersex Core bietet dir einige Debug-Ausgabefunktionen an um zumindest über syslog oder die serielle Schnittstelle den Programmablauf mitverfolgen zu können. Folgende Debugfunktionen kannst du nutzen, nachdem du core/debug.h inkludiert hast: * void debug_printf(s, args...); // Syntax wie bei printf aus der standard C library * char* debug_binary(uint8_t); // Gibt eine 8 Byte lange Zeichenfolge von 0/1 zurück, die den integer repräsentiert Folgende Debug Funktionen kannst du nutzen, nachdem du protocols/syslog/syslog.h inkludiert hast: * void syslog_sendf(s, args...); // Syntax wie bei printf aus der standard C library [[Category:Ethersex]] [[Category:StepByStep]] 181b5b8be7cb29d4759f8a03ad551420df28ae1f 336 326 2012-01-07T13:17:50Z Mgue 312 i18n wikitext text/x-wiki {{i18n|Own module}} Hier findest du die wichtigsten Informationen, um dein eigenes Modul entwickeln zu können. Beachte bitte auch den projektweit gültigen [[Coding_style|coding style]] und weitere Infos wie unter [[Pins in Ethersex definieren]]. == Lizenz == Damit dein Modul mit ethersex veröffentlicht werden kann, musst du deinen Code unter eine GPLv3-kompatible Lizenz stellen. Füge dazu am besten folgenen Lizenzkopf in jede deiner Quellcode Dateien (*.h,*.c) ein: /* * * Copyright (c) 2012 by DEIN_NAME <DAVOR@DANACH.net> * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * as published by the Free Software Foundation; either version 3 * of the License, or (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. * * For more information on the GPL, please go to: * http://www.gnu.org/copyleft/gpl.html */ * Vergiss nicht, DEIN_NAME durch deinen Namen zu ersetzen. == Richtiges Verzeichnis == Du kannst dein Modul in eines der Verzeichnisse „hardware“, „services“ oder „protocols“ einsortieren. Wenn dein Modul mehrere dieser Kategorien erfüllt, muss das Modul eventuell in kleinere Untermodule aufgeteilt werden. Genaue Beschreibungen findest du im jeweiligen Verzeichnis in der Datei "content.txt". Wenn du dir nicht sicher bist, wo dein Modul genau einsortiert werden sollte, frag in der Mailingliste nach. Die 3 Kategorien grob umrissen: * Hardware: Module, die es ermöglichen externe Hardware anzusteuern. * Services: Module, die Anwendungen/Daemons/Services realisieren. * Protocols: Module, die Protokolle implementieren. == Dateien in Make-Prozess aufnehmen == Du hast in einem beliebigen Unterverzeichnis eine Datei hinzugefügt und möchtest natürlich, dass das Make-System diese jetzt auch mit berücksichtigt. Dazu musst du ein Makefile erstellen, welches beispielsweise wie folgt aussehen kann: <pre> TOPDIR ?= ../.. include $(TOPDIR)/.config $(DC3840_SUPPORT)_SRC += hardware/camera/dc3840.c ############################################################################## # generic fluff include $(TOPDIR)/scripts/rules.mk </pre> Anstelle der Variable, die auf _SRC endet, kannst du eine der folgenden Alternativen wählen: # Die Datei soll immer mit eingelinkt werden.<pre>SRC += Pfad/deinedatei.c</pre> # Die Datei soll in Abhängigkeit von einer Konfigurationsoption aus Menuconfig mit eingebunden werden.<pre>${DEINGENIALESMODUL_SUPPORT}_SRC += Pfad/deinedatei.c</pre> # Die Datei soll in Abhängigkeit von einer Konfigurationsoption mit eingebunden werden, wenn der ECMD-Parser aktiviert ist.<pre>${DEINGENIALESMODUL_SUPPORT}_ECMD_SRC += Pfad/deinedatei.c</pre> Abhängig von der Ordnertiefe des von dir angelegten Ordners musst du selbstverständlich die Zahl der ''../'' betreffend ''TOPDIR'' anpassen. Weiterhin musst du dein Makefile dem eigentlichen Makefile in $(TOPDIR) bekannt machen, indem du es folgendermaßen hinzufügst: SUBDIRS += hardware/camera == Menuconfig == Um dein Modul zur grafischen Konfiguration hinzuzufügen (make menuconfig), brauchst du im Ordner deines Moduls eine Datei namens config.in, beispielsweise mit folgendem Inhalt: dep_bool_menu 'Genius module' DEINGENIALESMODUL_SUPPORT $TCP_SUPPORT Dieser Eintrag bedeutet, dass du dein Modul nur dann aktivieren kannst, wenn TCP_SUPPORT aktiviert ist. Weiters wird hier noch ein Untermenü angelegt. Um dein Modul ohne Abhängigkeiten und ohne zusätzlichem Menü aktivieren zu können solltest du folgende Methode wählen: bool 'Genius module' DEINGENIALESMODUL_SUPPORT Dieses musst du, analog zum Makefile, in $(TOPDIR)/config.in hinzufügen: source hardware/camera/config.in == Funktion beim Boot und Periodisch aufrufen lassen == # Du hast ein neues Modul entwickelt, dieses Enthält eine Initialisierungsfunktion, die beim Start der Ethersex-Firmware aufgerufen werden muss. # Dein Modul enthält eine Funktion, die nach Möglichkeit ständig wieder aufgerufen wird (bzw. möglichst oft, soviel Rechenzeit wie die anderen Applikationen die ebenfalls ihre Dienste verrichten sollen, übrig lassen) Hierzu gibt es die ''Ethersex Meta''-Bereiche, die du evtl. bereits am Ende der einen oder anderen C-Datei entdeckt hast. Diese haben grundsätzlich den folgenden Aufbau: <pre> /* -- Ethersex META -- mainloop(stella_process) init(stella_init) */ </pre> Diese Zeilen, am Dateiende eingefügt, sorgen dafür, dass die Funktion ''stella_init'' einmal beim Start der von dir modifizierten Ethersex-Firmware aufgerufen wird und die Funktion ''stella_process' möglichst oft. Du kannst in den Meta-Bereich auch mehrere ''init''-Direktiven aufnehmen, etc. Weitere Direktiven sind: * '''initearly''' - funktioniert wie ''init''. Die Funktionen werden nur vor ''init'' aufgerufen. Dies ist bei Abhängigkeiten praktisch, in der Regel solltest du jedoch ''init'' verwenden. * '''net_init''' - zum Initialisieren von Netzwerkanwendungen. Die Funktionen werden nach den ''init''-Funktionen ausgeführt. * '''startup''' - diese Funktionen werden vor Aufruf der Mainloop gestartet. Der Sendmail-Service sendet hier beispielsweise die Startnachricht. * '''timer''' - Periodisch (alle 20ms) wie bei mainloop. Beispiel: timer(50, function()) ruft function() alle 50*20ms auf, also 1x pro Sekunde. * '''header''' - nicht dokumentiert Bei den aufzurufenden Funktionen muss bei init(<fkt>) die Funktion ohne Klammern und bei timer(<int>, <fkt>()) mit Klammern geschrieben werden. == Debug-Ausgaben == Für eingebettete Systeme zu programmieren kann manchmal ziemlich nervenaufreibend sein. In der Regel hat man nicht die nötige Hardware (JTAG) um step-by-step Debugging durchführen zu können. Der ethersex Core bietet dir einige Debug-Ausgabefunktionen an um zumindest über syslog oder die serielle Schnittstelle den Programmablauf mitverfolgen zu können. Folgende Debugfunktionen kannst du nutzen, nachdem du core/debug.h inkludiert hast: * void debug_printf(s, args...); // Syntax wie bei printf aus der standard C library * char* debug_binary(uint8_t); // Gibt eine 8 Byte lange Zeichenfolge von 0/1 zurück, die den integer repräsentiert Folgende Debug Funktionen kannst du nutzen, nachdem du protocols/syslog/syslog.h inkludiert hast: * void syslog_sendf(s, args...); // Syntax wie bei printf aus der standard C library [[Category:Ethersex]] [[Category:StepByStep]] 327ae221907b18104cd71967a9ccf9141af9312a 0 30 327 310 2012-01-03T00:11:36Z Sauttefk 326 quelltext passagen korrigiert wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR Receivers->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP ist eine Portierung des [http://www.mikrocontroller.net/articles/IRMP Infrarot-Multiprotokoll-Decoders] nach [[Ethersex]]. == Anschluss == Der Empfang der IR-Signale erfolgt durch einen Empfänger vom Typ TSOP1736 (oder ähnlich). Dieser kann an einem beliebigen Pin angeschlossen werden. Die Abfrage des Pins und die Dekodierung des IR-Protokolls erfolgt in einer ISR, die einen 8-Bit-Timer des ATMEGAs belegt. Beim Senden wird das Signal mit der Trägerfrequenz des jeweiligen IR-Protokolls über [[PWM_(Deutsch)|PWM]] moduliert. Dazu wird ein weiterer 8-Bit Timer des ATMEGAs (OC0/OC2) belegt. Auf dem '''[[Etherape_(Deutsch)|Etherrape]]'''-Board übernimmt ein [[NE555_(Deutsch)|NE555]] diese Funktion, d.h. die Option ''Use external modulator for sender'' ist zu aktivieren. Man spart einen Timer des [[AVR_(Deutsch)|AVR]] und ist auf eine Trägerfrequenz festgelegt. Beispiel für einen ATMega32 aus: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Bedeutung: * IRMP_RX - Pin an dem der IR-Empfänger angeschlossen ist * IRMP_USE_TIMER2 - benutze Timer2 für den Empfang, Timer0 für das Senden (undef = umgekehrt) * IRMP_RX_LOW_ACTIVE - der IR-Empfänger ist Low-Aktiv (undef = High-aktiv) * IRMP_RX_LED_LOW_ACTIVE - die Kontroll-LED des Empfängers ist gegen USS geschaltet (undef = gegen GND geschaltet) * IRMP_TX - Pin an dem der IR-Sender angschlossen ist (=Ausgang des Timer0 oder Timer2, vgl. IRMP_USE_TIMER2)<br>'''Achtung: 0A bzw 2A bei MCU mit A/B Kanal''' * IRMP_TX_LED_LOW_ACTIVE - die Kontroll-LED des Senders ist gegen USS geschaltet (undef = gegen GND geschaltet) == Konfiguration == Jedes unterstützte IR-Protokoll "verbrät" Speicher an Code. Deshalb sollte man nur die benötigten Protokolle auswählen. Eine detailierte Übersicht über die Protokolle gibt der [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail Artikel im Mikrocontroller Forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ --- Debugging Flags │ │ [ ] IRMP Debug IRMP dekodiert auch das RC5-Protokoll, so dass der separat in [[Ethersex_(Deutsch)|Ethersex]] enthaltene [[RC5_(Deutsch)|RC5]]-Dekoder nicht länger benötigt wird. == [[ECMD_(Deutsch)|ECMD]] == IRMP implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle zum Auslesen empfangener und dekodierter IR-Kommandos und zum Senden von IR-Kommandos. Siehe [[ECMD_Reference|ECMD Referenz]]. == [[Control6_(Deutsch)|Control6]] == === Ausgabe empfangener IR-Zeichen via [[SYSLOG_(Deutsch)|Syslog]] === CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END Mit IRMP_READ wird auf empfangenen IR-Code geprüft und dieser in die Variablen IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND und IRMP_FLAGS gespeichert. Rückgabewerte größer Null signalisieren die Gültigkeit der Variablen. Bei IRMP_FLAGS=1 handelt es sich um eine Wiederholung. === Steuern von [[Stella_Light_(Deutsch)|Stella]]/Pins durch IR-Zeichen === C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END Das Script schaltet den Stella Channel 0 auf 255 oder auf 0, die Fernbedienung ist hier eine Denon (Protocol 8). Mit ''include'' wurde dem Script der Zugriff auf die Stellasourcen gestattet.<br> Statt ''"stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255);"'' kann auch ''"PIN_SET(LED)"'' und ''"PIN_CLEAR(LED)"'' verwendet werden ([[Named_PIN_(Deutsch)|Named PIN]]). === Senden von IR-Zeichen === dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 * no tx support yet dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON * no tx support yet IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; Kommando 5678 an Gerät 1234 wird mit einer Wiederholung im NEC-Protokoll gesendet. 47411e307cf3695741767a5923d3e98963f439fb 335 327 2012-01-06T11:45:53Z Mgue 312 Reverted edits by [[Special:Contributions/Sauttefk|Sauttefk]] ([[User talk:Sauttefk|Talk]]) to last revision by [[User:GooPie4o|GooPie4o]] wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR Receivers->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP ist eine Portierung des [http://www.mikrocontroller.net/articles/IRMP Infrarot-Multiprotokoll-Decoders] nach [[Ethersex]]. == Anschluss == Der Empfang der IR-Signale erfolgt durch einen Empfänger vom Typ TSOP1736 (oder ähnlich). Dieser kann an einem beliebigen Pin angeschlossen werden. Die Abfrage des Pins und die Dekodierung des IR-Protokolls erfolgt in einer ISR, die einen 8-Bit-Timer des ATMEGAs belegt. Beim Senden wird das Signal mit der Trägerfrequenz des jeweiligen IR-Protokolls über [[PWM_(Deutsch)|PWM]] moduliert. Dazu wird ein weiterer 8-Bit Timer des ATMEGAs (OC0/OC2) belegt. Auf dem '''[[Etherape_(Deutsch)|Etherrape]]'''-Board übernimmt ein [[NE555_(Deutsch)|NE555]] diese Funktion, d.h. die Option ''Use external modulator for sender'' ist zu aktivieren. Man spart einen Timer des [[AVR_(Deutsch)|AVR]] und ist auf eine Trägerfrequenz festgelegt. Beispiel für einen ATMega32 aus: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Bedeutung: * IRMP_RX - Pin an dem der IR-Empfänger angeschlossen ist * IRMP_USE_TIMER2 - benutze Timer2 für den Empfang, Timer0 für das Senden (undef = umgekehrt) * IRMP_RX_LOW_ACTIVE - der IR-Empfänger ist Low-Aktiv (undef = High-aktiv) * IRMP_RX_LED_LOW_ACTIVE - die Kontroll-LED des Empfängers ist gegen USS geschaltet (undef = gegen GND geschaltet) * IRMP_TX - Pin an dem der IR-Sender angschlossen ist (=Ausgang des Timer0 oder Timer2, vgl. IRMP_USE_TIMER2)<br>'''Achtung: 0A bzw 2A bei MCU mit A/B Kanal''' * IRMP_TX_LED_LOW_ACTIVE - die Kontroll-LED des Senders ist gegen USS geschaltet (undef = gegen GND geschaltet) == Konfiguration == Jedes unterstützte IR-Protokoll "verbrät" Speicher an Code. Deshalb sollte man nur die benötigten Protokolle auswählen. Eine detailierte Übersicht über die Protokolle gibt der [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail Artikel im Mikrocontroller Forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ --- Debugging Flags │ │ [ ] IRMP Debug IRMP dekodiert auch das RC5-Protokoll, so dass der separat in [[Ethersex_(Deutsch)|Ethersex]] enthaltene [[RC5_(Deutsch)|RC5]]-Dekoder nicht länger benötigt wird. == [[ECMD_(Deutsch)|ECMD]] == IRMP implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle zum Auslesen empfangener und dekodierter IR-Kommandos und zum Senden von IR-Kommandos. Siehe [[ECMD_Reference|ECMD Referenz]]. == [[Control6_(Deutsch)|Control6]] == === Ausgabe empfangener IR-Zeichen via [[SYSLOG_(Deutsch)|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> Mit IRMP_READ wird auf empfangenen IR-Code geprüft und dieser in die Variablen IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND und IRMP_FLAGS gespeichert. Rückgabewerte größer Null signalisieren die Gültigkeit der Variablen. Bei IRMP_FLAGS=1 handelt es sich um eine Wiederholung. === Steuern von [[Stella_Light_(Deutsch)|Stella]]/Pins durch IR-Zeichen === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> Das Script schaltet den Stella Channel 0 auf 255 oder auf 0, die Fernbedienung ist hier eine Denon (Protocol 8). Mit ''include'' wurde dem Script der Zugriff auf die Stellasourcen gestattet.<br> Statt ''"stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255);"'' kann auch ''"PIN_SET(LED)"'' und ''"PIN_CLEAR(LED)"'' verwendet werden ([[Named_PIN_(Deutsch)|Named PIN]]). === Senden von IR-Zeichen === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 * no tx support yet dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON * no tx support yet IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Kommando 5678 an Gerät 1234 wird mit einer Wiederholung im NEC-Protokoll gesendet. 266509a1c102b41b2502d0fe1d9c150f6831f512 0 29 328 309 2012-01-03T00:15:50Z Sauttefk 326 quelltextpassagen korrigiert wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR Receivers->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP is a port of the [http://www.mikrocontroller.net/articles/IRMP infrared multi-protocol decoder] for [[Ethersex]]. == Connection == The reception of IR signals is performed by a receiver TSOP1736 type (or similar). This may be connected to any pin. The interrogation of the pins and the decoding of the IR protocol is done in an ISR, which occupies one 8-bit timer of the ATmegas. When sending the signal with the carrier frequency of the respective IR Protocol is [[PWM]] modulated. This is another 8-bit timer of the ATmegas (OC0/OC2) is demonstrated. On the [[Etherrape]] board takes a [[NE555]] this function, ie the option ''Use external modulator for the transmitter'' is activated. It saves a timer on the [[AVR]] is set at a carrier frequency. Example of a ATMega32 from: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Meaning: * IRMP_RX - pin the IR receiver is connected to * IRMP_USE_TIMER2 - use Timer2 for receiver, Timer0 for sender (undef = reversed) * IRMP_RX_LOW_ACTIVE - the IR receiver is low-active (undef = high-active) * IRMP_RX_LED_LOW_ACTIVE - the control LED of the receiver is switched to USS (undef = switched to GND) * IRMP_TX - pin the IR sender is connected to (=output of Timer0 or Timer2, see IRMP_USE_TIMER2)<br>'''Caution: 0A to 2A if MCU with A / B channel''' * IRMP_TX_LED_LOW_ACTIVE - the control LED of the sender is switched to USS (undef = switched to GND) == Configuration == Each supported IR protocol occupies memory of code. Therefore, one should select only the required protocols. A detailed overview of the protocols are the [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail article in the mikrocontroller forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ --- Debugging Flags │ │ [ ] IRMP Debug IRMP also decodes the RC5 protocol, so that the separately [[Ethersex]] contained [[RC5]] decoder is not needed any longer. == [[ECMD]] == IRMP implements a [[ECMD]] interface for reading received and decoded IR commands and send IR commands. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == === Output received characters via [[SYSLOG|Syslog]] === CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END IRMP_READ checks for received IR code and stores it in the variables IRMP_PROTOCOL, IRMP_ADDRESS, and IRMP_COMMAND IRMP_FLAGS. Return values ​​greater than zero indicate the validity of the variables. If IRMP_FLAGS = 1 it is a repetition. === Control of [[Stella_Light)|Stella]]/Pins by IR commands === C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END The script switches the Stella channel 0 to 255 or 0, the remote control is a Denon (Protocol 8). With ''include'' access to the Stella sources granted.<br> Instead of ''"stella_setValue (STELLA_SET_IMMEDIATELY, 0, 255);"'' ''"PIN_SET (LED)"'' and ''"PIN_CLEAR (LED)"'' can be used ([[Named_PIN|named pin]]). |Named PIN]]). === Send IR commands === dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 * no tx support yet dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON * no tx support yet IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; Command 5678 to device 1234 will be send with one repetition using the NEC protocol. c9b9fb5df6da495d3013e22665933e95b205c9b9 334 328 2012-01-06T11:45:35Z Mgue 312 Reverted edits by [[Special:Contributions/Sauttefk|Sauttefk]] ([[User talk:Sauttefk|Talk]]) to last revision by [[User:GooPie4o|GooPie4o]] wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR Receivers->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP is a port of the [http://www.mikrocontroller.net/articles/IRMP infrared multi-protocol decoder] for [[Ethersex]]. == Connection == The reception of IR signals is performed by a receiver TSOP1736 type (or similar). This may be connected to any pin. The interrogation of the pins and the decoding of the IR protocol is done in an ISR, which occupies one 8-bit timer of the ATmegas. When sending the signal with the carrier frequency of the respective IR Protocol is [[PWM]] modulated. This is another 8-bit timer of the ATmegas (OC0/OC2) is demonstrated. On the [[Etherrape]] board takes a [[NE555]] this function, ie the option ''Use external modulator for the transmitter'' is activated. It saves a timer on the [[AVR]] is set at a carrier frequency. Example of a ATMega32 from: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Meaning: * IRMP_RX - pin the IR receiver is connected to * IRMP_USE_TIMER2 - use Timer2 for receiver, Timer0 for sender (undef = reversed) * IRMP_RX_LOW_ACTIVE - the IR receiver is low-active (undef = high-active) * IRMP_RX_LED_LOW_ACTIVE - the control LED of the receiver is switched to USS (undef = switched to GND) * IRMP_TX - pin the IR sender is connected to (=output of Timer0 or Timer2, see IRMP_USE_TIMER2)<br>'''Caution: 0A to 2A if MCU with A / B channel''' * IRMP_TX_LED_LOW_ACTIVE - the control LED of the sender is switched to USS (undef = switched to GND) == Configuration == Each supported IR protocol occupies memory of code. Therefore, one should select only the required protocols. A detailed overview of the protocols are the [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail article in the mikrocontroller forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ --- Debugging Flags │ │ [ ] IRMP Debug IRMP also decodes the RC5 protocol, so that the separately [[Ethersex]] contained [[RC5]] decoder is not needed any longer. == [[ECMD]] == IRMP implements a [[ECMD]] interface for reading received and decoded IR commands and send IR commands. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == === Output received characters via [[SYSLOG|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> IRMP_READ checks for received IR code and stores it in the variables IRMP_PROTOCOL, IRMP_ADDRESS, and IRMP_COMMAND IRMP_FLAGS. Return values ​​greater than zero indicate the validity of the variables. If IRMP_FLAGS = 1 it is a repetition. === Control of [[Stella_Light)|Stella]]/Pins by IR commands === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> The script switches the Stella channel 0 to 255 or 0, the remote control is a Denon (Protocol 8). With ''include'' access to the Stella sources granted.<br> Instead of ''"stella_setValue (STELLA_SET_IMMEDIATELY, 0, 255);"'' ''"PIN_SET (LED)"'' and ''"PIN_CLEAR (LED)"'' can be used ([[Named_PIN|named pin]]). |Named PIN]]). === Send IR commands === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 * no tx support yet dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON * no tx support yet IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Command 5678 to device 1234 will be send with one repetition using the NEC protocol. aff6b00d9bc9deeb747774cfae4e5f460a2e38fe 2 142 329 2012-01-05T20:53:47Z Sascha 423 created page with some content wikitext text/x-wiki Sascha Ludwig, bastelt bei eventphone, im ccc und an diversen anderen Projekten cd8f6ac8a3ec6a7015a50f066ac985fd42f7ae63 0 143 331 2012-01-05T22:23:11Z Sascha 423 created a rough first draft of the dali protocol informations wikitext text/x-wiki {{i18n|DALI}} {{Module |NAME=DALI |MENUCONFIG={{Protocols}}->DALI light control |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] (optional) |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/protocols/dali https://github.com/ethersex/ethersex/tree/master/protocols/dali] }} DALI light control provides the software layer to control DALI enabled digital ballast and transformers. DALI is an abbreviation for Digital Addressable Lighting Interface == DALI bus physical layer == * one master (Ethersex) and up to 64 lights (targets) on one bus * 2 wire, no complex topology restrictions, no termination * targets may only answer on master's request * bus is isolated, but not SELV -> should be galvanic isolated on master's side * 1200 baud, manchester-encoding * 22.5VDC to 9.5VDC (16VDC nominally) is high level * 6.5VDC to -6.5VDV (0VDC nominally) is low level * bus is powered and held to high level by master * targets (slaves) short the bus to transmit a low value * master has to limit the current to 250mA == [[ECMD]] commands == {| border=1 | '''Command Syntax''' | '''Short description''' |- | dali raw <byte1> <byte2> | Sends a raw frame with 2 hex bytes. If you know what you are doing... |- | dali dim <target> <level> | Dims the specified target to the specified dim-level (0-254) |- | dali cmd <target> <command> ''[!]'' ''[?]'' | Sends a command (decimal) to the target. For a list of commands see the NXP application note or the DALI standard. To automatically repeat the command add a ''!'' to the end of the command (necessary with some commands). A ''?'' at the end means that command waits for an answer from the target. This answer is being returned as a decimal value. Not all commands will send an answer. |- | dali scmd <command> <data> ''[!]'' ''[?]'' | Sends a special command to all connected targets (decimal 256-287). For a list of commands see the NXP application note or the DALI standard. A ''?'' at the end means that command waits for an answer from the target. This answer is being returned as a decimal value. Not all commands will send an answer. |} Values for the <target> parameter: {| border=1 | '''Targetcode''' | '''Description''' |- |all || All / Broadcast |- |- |s''nn''|| short address 0-63 (decimal) |- |- |g''nn''|| group address 0-16 (decimal) |} == Examples == {| border=1 |'''Example''' |'''ECMD''' |- | Dim all targets to 100% | <code>dali dim all 254</code> |- | Target 12 off | <code>dali dim s12 0</code> |- | Targets in group 3 to 50% | <code>dali dim g3 127</code> |- | Set dim-speed on all targets to approx. 5.6 seconds (t=1/2*SQRT(2^x), x=1-15)|| <code>dali scmd 257 7 dali cmd all 46 !</code> |- | Get actual dim value from target 4 | <code>dali cmd s4 160 ?</code> Reply: <code>180</code> |- | Is a target with short address 8 existing? | <code>dali cmd s8 145 ?</code> Reply: <code>255</code> (means true) |- | Malfunction at target 8? || <code>dali cmd s8 146 ?</code> Reply: <code>READ TIMEOUT</code> (No answer means no malfunction) |- | Program the single connected target the short address 3 | <code>dali scmd 257 3 dali cmd all 128 !</code> |} == External sources == *[http://de.wikipedia.org/wiki/Digital_Addressable_Lighting_Interface DALI bei Wikipedia] *[http://www.freescale.com/files/microcontrollers/doc/ref_manual/DRM004.pdf Freescale DRM004 Application Note] good example for the hardware parts needed *[http://www.standardics.nxp.com/support/documents/microcontrollers/zip/an10760.zip NXP AN10760] good commandlist and explanation of the data transfer *[http://www.archenergy.com/lrp/products/dali.htm NEMA Standard 243 bei Archenergy] If you are lucky, you can find the official DALI standard document IEC 60929 on google. fbc6cca9fcaf070ee3fab9ce5569b23ca6e0c652 332 331 2012-01-05T22:25:55Z Sascha 423 externam sources update wikitext text/x-wiki {{i18n|DALI}} {{Module |NAME=DALI |MENUCONFIG={{Protocols}}->DALI light control |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] (optional) |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/protocols/dali https://github.com/ethersex/ethersex/tree/master/protocols/dali] }} DALI light control provides the software layer to control DALI enabled digital ballast and transformers. DALI is an abbreviation for Digital Addressable Lighting Interface == DALI bus physical layer == * one master (Ethersex) and up to 64 lights (targets) on one bus * 2 wire, no complex topology restrictions, no termination * targets may only answer on master's request * bus is isolated, but not SELV -> should be galvanic isolated on master's side * 1200 baud, manchester-encoding * 22.5VDC to 9.5VDC (16VDC nominally) is high level * 6.5VDC to -6.5VDV (0VDC nominally) is low level * bus is powered and held to high level by master * targets (slaves) short the bus to transmit a low value * master has to limit the current to 250mA == [[ECMD]] commands == {| border=1 | '''Command Syntax''' | '''Short description''' |- | dali raw <byte1> <byte2> | Sends a raw frame with 2 hex bytes. If you know what you are doing... |- | dali dim <target> <level> | Dims the specified target to the specified dim-level (0-254) |- | dali cmd <target> <command> ''[!]'' ''[?]'' | Sends a command (decimal) to the target. For a list of commands see the NXP application note or the DALI standard. To automatically repeat the command add a ''!'' to the end of the command (necessary with some commands). A ''?'' at the end means that command waits for an answer from the target. This answer is being returned as a decimal value. Not all commands will send an answer. |- | dali scmd <command> <data> ''[!]'' ''[?]'' | Sends a special command to all connected targets (decimal 256-287). For a list of commands see the NXP application note or the DALI standard. A ''?'' at the end means that command waits for an answer from the target. This answer is being returned as a decimal value. Not all commands will send an answer. |} Values for the <target> parameter: {| border=1 | '''Targetcode''' | '''Description''' |- |all || All / Broadcast |- |- |s''nn''|| short address 0-63 (decimal) |- |- |g''nn''|| group address 0-16 (decimal) |} == Examples == {| border=1 |'''Example''' |'''ECMD''' |- | Dim all targets to 100% | <code>dali dim all 254</code> |- | Target 12 off | <code>dali dim s12 0</code> |- | Targets in group 3 to 50% | <code>dali dim g3 127</code> |- | Set dim-speed on all targets to approx. 5.6 seconds (t=1/2*SQRT(2^x), x=1-15)|| <code>dali scmd 257 7 dali cmd all 46 !</code> |- | Get actual dim value from target 4 | <code>dali cmd s4 160 ?</code> Reply: <code>180</code> |- | Is a target with short address 8 existing? | <code>dali cmd s8 145 ?</code> Reply: <code>255</code> (means true) |- | Malfunction at target 8? || <code>dali cmd s8 146 ?</code> Reply: <code>READ TIMEOUT</code> (No answer means no malfunction) |- | Program the single connected target the short address 3 | <code>dali scmd 257 3 dali cmd all 128 !</code> |} == External sources == *[http://de.wikipedia.org/wiki/Digital_Addressable_Lighting_Interface DALI at Wikipedia] german article (more complete) *[http://www.freescale.com/files/microcontrollers/doc/ref_manual/DRM004.pdf Freescale DRM004 Application Note] good example for the hardware parts needed *[http://www.standardics.nxp.com/support/documents/microcontrollers/zip/an10760.zip NXP AN10760] good commandlist and explanation of the data transfer *[http://www.archenergy.com/lrp/products/dali.htm NEMA Standard 243 bei Archenergy] If you are lucky, you can find the official DALI standard document IEC 60929 on google. 93bf54120879179a03fc6787199528f01edc9bd4 10 55 337 194 2012-01-07T14:21:45Z Mgue 312 removed localized categories until Template:Module has i18n support wikitext text/x-wiki <noinclude>{{i18n|Template:Documentation}}</noinclude> {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | colspan=2 style="background-color: #FFFFFF; text-align: center; border-bottom:1px solid #aaaaaa;" | '''Dokumentation''' |- | [[Wiki Guidelines (Deutsch)|Wiki Richtlinien]] ---- * [[:Category:Hardware|Hardware Treiber]] * [[:Category:Protocol|Protokoll Support]] * [[:Category:Application|Dienste und Applikationen]] * [[ECMD Reference|ECMD Befehlssatz]] |} cb96fc270dc340a8cdc283407ab8bca02b67c62a 6 144 339 2012-01-10T11:33:29Z Hugo790 425 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 145 340 2012-01-10T11:49:01Z Hugo790 425 Created page with "==Porterweiterungen== Wenn am AVR schon viele Erweiterungen angeschlossen sind und die freien Ports langsam zur Neige gehen, kann man mit Schieberegistern arbeiten. Zwei dieser …" wikitext text/x-wiki ==Porterweiterungen== Wenn am AVR schon viele Erweiterungen angeschlossen sind und die freien Ports langsam zur Neige gehen, kann man mit Schieberegistern arbeiten. Zwei dieser Bausteine sind bereits in der SW vorgesehen und können per menuconfig freigeschaltet werden. === 74HC165 als Eingangserweiterung === Der 74HC165 ist ein 8-bit Parallel-in/Seriell-out Schieberegister. Das kann man z.B. dazu benutzen um mehrere Schalteingänge seriell abzufragen. So könnte man z.B. 8 Taster mit nur 3 Leitungen abfragen und spart in diesem Fall 5 Portleitungen. Diese Schaltung ist kaskadierbar, so daß weitere Eingänge abgefragt werden können ohne mehr Portleitungen zu benötigen. Schaltbild siehe bei [http://www.mikrocontroller.net/articles/Porterweiterung_mit_SPI#Eing.C3.A4nge www.mikrocontroller.net] { ''menuconfig todo'' } { ''pinning todo'' } === 74HC595 als Ausgangserweiterung === Der 74HC595 ist ein 8-bit Seriell-in/Parallel-out Schieberegister mit Latch. Das Latch braucht man, damit beim seriellen reinschieben der Bits diese nicht nacheinander an den Ausgängen erscheinen, sondern erst wenn das ganze Datenwort reingeschoben ist. Der 74HC595 ist sogar kaskadierbar, d.h. man kann theoretisch beliebig viele Ausgänge realisieren, ohne weitere Portleitungen zu benötigen. Weitere Informationen siehe bei [http://www.mikrocontroller.net/articles/Porterweiterung_mit_SPI#Ausg.C3.A4nge www.mikrocontroller.net] [[File:Hc595_example.png|thumb|Schaltbild 74HC595]] Zunächst muss bei "make menuconfig" unter "I/O" "HC595 output expansion" aktiviert werden. In der bei "Hardware/Periphery Class" ausgewählten .m4-Datei muss angegeben werden, wo der 74HC595 angeschlossen ist, z.B.: <pre> pin(HC595_DATA, PC0) pin(HC595_CLOCK, PC1) pin(HC595_STORE, PC2) </pre> Über emcd ist der 74HC595, zumindest bei einem Net IO-Board, als Port 4 ansprechbar. Z.B.: io set port 4 ff === 74HC164 als Ausgangserweiterung === Der 74HC164 ist ein 8-bit Seriell-in/Parallel-out Schieberegister. Das kann man z.B. dazu benutzen um ein handelsübliches LCD mit HD44780-Controller mit nur 3 Leitungen anzusteuern (bei direkter Ansteuerung würden 7 Portleitungen benötigt), so wird das bei U. Radig's Webserver gemacht.<br> In diesem Fall wird kein Latch benötigt, da das LCD erst beim Schalten seiner "E"-Leitung (enable) die Daten aus dem Schieberegister übernimmt. Schaltbild siehe bei [http://www.ulrichradig.de/home/index.php/software/avr-webserver-software AVR Webserver Software] { ''menuconfig todo'' } { ''pinning todo'' } ==D/A-Wandler mit LTC1257== Der LTC1257 ist ein 12bit Digital-Analog-Wandler mit seriellem Eingang und interner Referenzspannung. Zur Steuerung benötigt er lediglich 3 Portleitungen. Da er laut [http://cds.linear.com/docs/Datasheet/1257fb.pdf Datenblatt] mindestens 4,75 Volt Versorgungsspannung braucht, ist er nicht in Systemen mit 3,3 Volt einsetzbar. Die einfachste Form der Anbindung könnte so aussehen: [[Bild:LTC1257.png]] Das nötige Pinning ist für AVR-NET-IO bereits vorhanden, in der Zuordnung *PA0 = LOAD *PA1 = DATA *PA2 = CLK Mit <code>ltc1257_init</code> werden die Portleitungen passend initialisiert (lt. Datenblatt). Mit <code>ltc1257_delay</code> kann die interne Wartezeit in µs gesetzt werden, die zum Erkennen des Flankenwechsels durch den DAC beim Schreiben eines Bits gewartet wird (ist vor allem hilfreich, wenn der LTC1257 über Optopkoppler (z.B. CNY17) entkoppelt ist). Mit <code>ltc1257_set</code> werden die tatsächlichen Werte gesetzt, die der LTC1257 dann als Analogsignal ausgibt. Bei der Verwendung von mehreren LTC1257 im Daisy Chain muss die Reihenfolge der Werte für <code>ltc1257_set</code> in der <b>umgekehrten</b> Reihenfolge der DACs gesendet werden (d.h. das erste Argument ist für den letzten DAC). [[Category:Ethersex]] [[Category:Hardware]] 1dcab7909835cb71f699e7fd7fd5efd1b8eabed6 343 340 2012-01-11T17:07:03Z Mgue 312 i18n wikitext text/x-wiki {{i18n|Porterweiterungen}} ==Porterweiterungen== Wenn am AVR schon viele Erweiterungen angeschlossen sind und die freien Ports langsam zur Neige gehen, kann man mit Schieberegistern arbeiten. Zwei dieser Bausteine sind bereits in der SW vorgesehen und können per menuconfig freigeschaltet werden. === 74HC165 als Eingangserweiterung === Der 74HC165 ist ein 8-bit Parallel-in/Seriell-out Schieberegister. Das kann man z.B. dazu benutzen um mehrere Schalteingänge seriell abzufragen. So könnte man z.B. 8 Taster mit nur 3 Leitungen abfragen und spart in diesem Fall 5 Portleitungen. Diese Schaltung ist kaskadierbar, so daß weitere Eingänge abgefragt werden können ohne mehr Portleitungen zu benötigen. Schaltbild siehe bei [http://www.mikrocontroller.net/articles/Porterweiterung_mit_SPI#Eing.C3.A4nge www.mikrocontroller.net] { ''menuconfig todo'' } { ''pinning todo'' } === 74HC595 als Ausgangserweiterung === Der 74HC595 ist ein 8-bit Seriell-in/Parallel-out Schieberegister mit Latch. Das Latch braucht man, damit beim seriellen reinschieben der Bits diese nicht nacheinander an den Ausgängen erscheinen, sondern erst wenn das ganze Datenwort reingeschoben ist. Der 74HC595 ist sogar kaskadierbar, d.h. man kann theoretisch beliebig viele Ausgänge realisieren, ohne weitere Portleitungen zu benötigen. Weitere Informationen siehe bei [http://www.mikrocontroller.net/articles/Porterweiterung_mit_SPI#Ausg.C3.A4nge www.mikrocontroller.net] [[File:Hc595_example.png|thumb|Schaltbild 74HC595]] Zunächst muss bei "make menuconfig" unter "I/O" "HC595 output expansion" aktiviert werden. In der bei "Hardware/Periphery Class" ausgewählten .m4-Datei muss angegeben werden, wo der 74HC595 angeschlossen ist, z.B.: <pre> pin(HC595_DATA, PC0) pin(HC595_CLOCK, PC1) pin(HC595_STORE, PC2) </pre> Über emcd ist der 74HC595, zumindest bei einem Net IO-Board, als Port 4 ansprechbar. Z.B.: io set port 4 ff === 74HC164 als Ausgangserweiterung === Der 74HC164 ist ein 8-bit Seriell-in/Parallel-out Schieberegister. Das kann man z.B. dazu benutzen um ein handelsübliches LCD mit HD44780-Controller mit nur 3 Leitungen anzusteuern (bei direkter Ansteuerung würden 7 Portleitungen benötigt), so wird das bei U. Radig's Webserver gemacht.<br> In diesem Fall wird kein Latch benötigt, da das LCD erst beim Schalten seiner "E"-Leitung (enable) die Daten aus dem Schieberegister übernimmt. Schaltbild siehe bei [http://www.ulrichradig.de/home/index.php/software/avr-webserver-software AVR Webserver Software] { ''menuconfig todo'' } { ''pinning todo'' } ==D/A-Wandler mit LTC1257== Der LTC1257 ist ein 12bit Digital-Analog-Wandler mit seriellem Eingang und interner Referenzspannung. Zur Steuerung benötigt er lediglich 3 Portleitungen. Da er laut [http://cds.linear.com/docs/Datasheet/1257fb.pdf Datenblatt] mindestens 4,75 Volt Versorgungsspannung braucht, ist er nicht in Systemen mit 3,3 Volt einsetzbar. Die einfachste Form der Anbindung könnte so aussehen: [[Bild:LTC1257.png]] Das nötige Pinning ist für AVR-NET-IO bereits vorhanden, in der Zuordnung *PA0 = LOAD *PA1 = DATA *PA2 = CLK Mit <code>ltc1257_init</code> werden die Portleitungen passend initialisiert (lt. Datenblatt). Mit <code>ltc1257_delay</code> kann die interne Wartezeit in µs gesetzt werden, die zum Erkennen des Flankenwechsels durch den DAC beim Schreiben eines Bits gewartet wird (ist vor allem hilfreich, wenn der LTC1257 über Optopkoppler (z.B. CNY17) entkoppelt ist). Mit <code>ltc1257_set</code> werden die tatsächlichen Werte gesetzt, die der LTC1257 dann als Analogsignal ausgibt. Bei der Verwendung von mehreren LTC1257 im Daisy Chain muss die Reihenfolge der Werte für <code>ltc1257_set</code> in der <b>umgekehrten</b> Reihenfolge der DACs gesendet werden (d.h. das erste Argument ist für den letzten DAC). [[Category:Ethersex]] [[Category:Hardware]] 9e7392d7f42d65c538c077f75a659a7927d160d1 344 343 2012-01-11T17:07:32Z Mgue 312 moved [[Porterweiterungen]] to [[Porterweiterungen (Deutsch)]]:&#32;Don't mix german pages with english pages! wikitext text/x-wiki {{i18n|Porterweiterungen}} ==Porterweiterungen== Wenn am AVR schon viele Erweiterungen angeschlossen sind und die freien Ports langsam zur Neige gehen, kann man mit Schieberegistern arbeiten. Zwei dieser Bausteine sind bereits in der SW vorgesehen und können per menuconfig freigeschaltet werden. === 74HC165 als Eingangserweiterung === Der 74HC165 ist ein 8-bit Parallel-in/Seriell-out Schieberegister. Das kann man z.B. dazu benutzen um mehrere Schalteingänge seriell abzufragen. So könnte man z.B. 8 Taster mit nur 3 Leitungen abfragen und spart in diesem Fall 5 Portleitungen. Diese Schaltung ist kaskadierbar, so daß weitere Eingänge abgefragt werden können ohne mehr Portleitungen zu benötigen. Schaltbild siehe bei [http://www.mikrocontroller.net/articles/Porterweiterung_mit_SPI#Eing.C3.A4nge www.mikrocontroller.net] { ''menuconfig todo'' } { ''pinning todo'' } === 74HC595 als Ausgangserweiterung === Der 74HC595 ist ein 8-bit Seriell-in/Parallel-out Schieberegister mit Latch. Das Latch braucht man, damit beim seriellen reinschieben der Bits diese nicht nacheinander an den Ausgängen erscheinen, sondern erst wenn das ganze Datenwort reingeschoben ist. Der 74HC595 ist sogar kaskadierbar, d.h. man kann theoretisch beliebig viele Ausgänge realisieren, ohne weitere Portleitungen zu benötigen. Weitere Informationen siehe bei [http://www.mikrocontroller.net/articles/Porterweiterung_mit_SPI#Ausg.C3.A4nge www.mikrocontroller.net] [[File:Hc595_example.png|thumb|Schaltbild 74HC595]] Zunächst muss bei "make menuconfig" unter "I/O" "HC595 output expansion" aktiviert werden. In der bei "Hardware/Periphery Class" ausgewählten .m4-Datei muss angegeben werden, wo der 74HC595 angeschlossen ist, z.B.: <pre> pin(HC595_DATA, PC0) pin(HC595_CLOCK, PC1) pin(HC595_STORE, PC2) </pre> Über emcd ist der 74HC595, zumindest bei einem Net IO-Board, als Port 4 ansprechbar. Z.B.: io set port 4 ff === 74HC164 als Ausgangserweiterung === Der 74HC164 ist ein 8-bit Seriell-in/Parallel-out Schieberegister. Das kann man z.B. dazu benutzen um ein handelsübliches LCD mit HD44780-Controller mit nur 3 Leitungen anzusteuern (bei direkter Ansteuerung würden 7 Portleitungen benötigt), so wird das bei U. Radig's Webserver gemacht.<br> In diesem Fall wird kein Latch benötigt, da das LCD erst beim Schalten seiner "E"-Leitung (enable) die Daten aus dem Schieberegister übernimmt. Schaltbild siehe bei [http://www.ulrichradig.de/home/index.php/software/avr-webserver-software AVR Webserver Software] { ''menuconfig todo'' } { ''pinning todo'' } ==D/A-Wandler mit LTC1257== Der LTC1257 ist ein 12bit Digital-Analog-Wandler mit seriellem Eingang und interner Referenzspannung. Zur Steuerung benötigt er lediglich 3 Portleitungen. Da er laut [http://cds.linear.com/docs/Datasheet/1257fb.pdf Datenblatt] mindestens 4,75 Volt Versorgungsspannung braucht, ist er nicht in Systemen mit 3,3 Volt einsetzbar. Die einfachste Form der Anbindung könnte so aussehen: [[Bild:LTC1257.png]] Das nötige Pinning ist für AVR-NET-IO bereits vorhanden, in der Zuordnung *PA0 = LOAD *PA1 = DATA *PA2 = CLK Mit <code>ltc1257_init</code> werden die Portleitungen passend initialisiert (lt. Datenblatt). Mit <code>ltc1257_delay</code> kann die interne Wartezeit in µs gesetzt werden, die zum Erkennen des Flankenwechsels durch den DAC beim Schreiben eines Bits gewartet wird (ist vor allem hilfreich, wenn der LTC1257 über Optopkoppler (z.B. CNY17) entkoppelt ist). Mit <code>ltc1257_set</code> werden die tatsächlichen Werte gesetzt, die der LTC1257 dann als Analogsignal ausgibt. Bei der Verwendung von mehreren LTC1257 im Daisy Chain muss die Reihenfolge der Werte für <code>ltc1257_set</code> in der <b>umgekehrten</b> Reihenfolge der DACs gesendet werden (d.h. das erste Argument ist für den letzten DAC). [[Category:Ethersex]] [[Category:Hardware]] 9e7392d7f42d65c538c077f75a659a7927d160d1 354 344 2012-01-12T21:12:20Z Hugo790 425 wikitext text/x-wiki {{i18n|Porterweiterungen}} ==Porterweiterungen== Wenn am AVR schon viele Erweiterungen angeschlossen sind und die freien Ports langsam zur Neige gehen, kann man mit Schieberegistern arbeiten. Zwei dieser Bausteine sind bereits in der SW vorgesehen und können per menuconfig freigeschaltet werden. === 74HC165 als Eingangserweiterung === Der 74HC165 ist ein 8-bit Parallel-in/Seriell-out Schieberegister. Das kann man z.B. dazu benutzen um mehrere Schalteingänge seriell abzufragen. So könnte man z.B. 8 Taster mit nur 3 Leitungen abfragen und spart in diesem Fall 5 Portleitungen. Diese Schaltung ist kaskadierbar, so daß weitere Eingänge abgefragt werden können ohne mehr Portleitungen zu benötigen. Schaltbild siehe bei [http://www.mikrocontroller.net/articles/Porterweiterung_mit_SPI#Eing.C3.A4nge www.mikrocontroller.net] { ''menuconfig todo'' } { ''pinning todo'' } === 74HC595 als Ausgangserweiterung === Der 74HC595 ist ein 8-bit Seriell-in/Parallel-out Schieberegister mit Latch. Das Latch braucht man, damit beim seriellen reinschieben der Bits diese nicht nacheinander an den Ausgängen erscheinen, sondern erst wenn das ganze Datenwort reingeschoben ist. Der 74HC595 ist sogar kaskadierbar, d.h. man kann theoretisch beliebig viele Ausgänge realisieren, ohne weitere Portleitungen zu benötigen. ==== Anschluss ==== HC595_DATA: Serial Data Input (SI) (erster 74HC595) HC595_CLOCK: SCK (an alle) HC595_STORE: RCK (an alle) QH* bzw. Q7*: Serial Data Input (SI) (zweiter 74HC595) [[File:Hc595_example.png|thumb|Schaltbild 74HC595]] Weitere Informationen siehe bei [http://www.mikrocontroller.net/articles/Porterweiterung_mit_SPI#Ausg.C3.A4nge www.mikrocontroller.net] ==== Konfiguration ==== │ │ I/O ---> ... │ │ [*] HC595 output expansion ---> ... │ │ (1) Number of HC595 registers In der bei "Hardware/Periphery Class" ausgewählten .m4-Datei muss angegeben werden, wo der erste 74HC595 angeschlossen ist, z.B.: <pre> pin(HC595_DATA, PC0) pin(HC595_CLOCK, PC1) pin(HC595_STORE, PC2) </pre> ==== ECMD ==== {| border=1 | '''Syntax''' | '''Kurze Beschreibung''' |- | io set port NUM HEXVALUE [MASK] | Setzt Port NUM auf den Wert HEXVALUE (ggf. wird die angegebene MASK verwendet). Port 4 ist der erste, Port 5 der zweite 74HC595 etc. |- |} === 74HC164 als Ausgangserweiterung === Der 74HC164 ist ein 8-bit Seriell-in/Parallel-out Schieberegister. Das kann man z.B. dazu benutzen um ein handelsübliches LCD mit HD44780-Controller mit nur 3 Leitungen anzusteuern (bei direkter Ansteuerung würden 7 Portleitungen benötigt), so wird das bei U. Radig's Webserver gemacht.<br> In diesem Fall wird kein Latch benötigt, da das LCD erst beim Schalten seiner "E"-Leitung (enable) die Daten aus dem Schieberegister übernimmt. Schaltbild siehe bei [http://www.ulrichradig.de/home/index.php/software/avr-webserver-software AVR Webserver Software] { ''menuconfig todo'' } { ''pinning todo'' } ==D/A-Wandler mit LTC1257== Der LTC1257 ist ein 12bit Digital-Analog-Wandler mit seriellem Eingang und interner Referenzspannung. Zur Steuerung benötigt er lediglich 3 Portleitungen. Da er laut [http://cds.linear.com/docs/Datasheet/1257fb.pdf Datenblatt] mindestens 4,75 Volt Versorgungsspannung braucht, ist er nicht in Systemen mit 3,3 Volt einsetzbar. Die einfachste Form der Anbindung könnte so aussehen: [[Bild:LTC1257.png]] Das nötige Pinning ist für AVR-NET-IO bereits vorhanden, in der Zuordnung *PA0 = LOAD *PA1 = DATA *PA2 = CLK Mit <code>ltc1257_init</code> werden die Portleitungen passend initialisiert (lt. Datenblatt). Mit <code>ltc1257_delay</code> kann die interne Wartezeit in µs gesetzt werden, die zum Erkennen des Flankenwechsels durch den DAC beim Schreiben eines Bits gewartet wird (ist vor allem hilfreich, wenn der LTC1257 über Optopkoppler (z.B. CNY17) entkoppelt ist). Mit <code>ltc1257_set</code> werden die tatsächlichen Werte gesetzt, die der LTC1257 dann als Analogsignal ausgibt. Bei der Verwendung von mehreren LTC1257 im Daisy Chain muss die Reihenfolge der Werte für <code>ltc1257_set</code> in der <b>umgekehrten</b> Reihenfolge der DACs gesendet werden (d.h. das erste Argument ist für den letzten DAC). [[Category:Ethersex]] [[Category:Hardware]] f652fda74c714607995c32a3b0e6621492896222 355 354 2012-01-12T21:24:40Z Hugo790 425 /* 74HC165 als Eingangserweiterung */ wikitext text/x-wiki {{i18n|Porterweiterungen}} ==Porterweiterungen== Wenn am AVR schon viele Erweiterungen angeschlossen sind und die freien Ports langsam zur Neige gehen, kann man mit Schieberegistern arbeiten. Zwei dieser Bausteine sind bereits in der SW vorgesehen und können per menuconfig freigeschaltet werden. === 74HC165 als Eingangserweiterung === Der 74HC165 ist ein 8-bit Parallel-in/Seriell-out Schieberegister. Das kann man z.B. dazu benutzen um mehrere Schalteingänge seriell abzufragen. So könnte man z.B. 8 Taster mit nur 3 Leitungen abfragen und spart in diesem Fall 5 Portleitungen. Diese Schaltung ist kaskadierbar, so daß weitere Eingänge abgefragt werden können ohne mehr Portleitungen zu benötigen. ==== Anschluss ==== <pre> HC165_DATA: QH (erster 74HC165) HC165_CLOCK: CLOCK (alle) HC165_LOAD: Shift/Load (alle) GND: Clock Inhibit SERIAL INPUT: QH (zweiter 74HC165) </pre> Schaltbild siehe bei [http://www.mikrocontroller.net/articles/Porterweiterung_mit_SPI#Eing.C3.A4nge www.mikrocontroller.net] ==== Konfiguration ==== │ │ I/O ---> ... │ │ [*] HC165 input expansion ---> ... │ │ [ ] Inverse output │ │ (1) Number of HC165 registers In der bei "Hardware/Periphery Class" ausgewählten .m4-Datei muss angegeben werden, wo der erste 74HC165 angeschlossen ist, z.B.: <pre> pin(HC165_DATA, PC3) pin(HC165_CLOCK, PC4) pin(HC165_LOAD, PC5) </pre> ==== ECMD ==== {| border=1 | '''Syntax''' | '''Kurze Beschreibung''' |- | io get pin NUM | Liefert als Rückgabewert den Hexadezimalwert vom 74HC595. Pin 4 ist der erste, Pin 5 der zweite etc. |- |} === 74HC595 als Ausgangserweiterung === Der 74HC595 ist ein 8-bit Seriell-in/Parallel-out Schieberegister mit Latch. Das Latch braucht man, damit beim seriellen reinschieben der Bits diese nicht nacheinander an den Ausgängen erscheinen, sondern erst wenn das ganze Datenwort reingeschoben ist. Der 74HC595 ist sogar kaskadierbar, d.h. man kann theoretisch beliebig viele Ausgänge realisieren, ohne weitere Portleitungen zu benötigen. ==== Anschluss ==== HC595_DATA: Serial Data Input (SI) (erster 74HC595) HC595_CLOCK: SCK (an alle) HC595_STORE: RCK (an alle) QH* bzw. Q7*: Serial Data Input (SI) (zweiter 74HC595) [[File:Hc595_example.png|thumb|Schaltbild 74HC595]] Weitere Informationen siehe bei [http://www.mikrocontroller.net/articles/Porterweiterung_mit_SPI#Ausg.C3.A4nge www.mikrocontroller.net] ==== Konfiguration ==== │ │ I/O ---> ... │ │ [*] HC595 output expansion ---> ... │ │ (1) Number of HC595 registers In der bei "Hardware/Periphery Class" ausgewählten .m4-Datei muss angegeben werden, wo der erste 74HC595 angeschlossen ist, z.B.: <pre> pin(HC595_DATA, PC0) pin(HC595_CLOCK, PC1) pin(HC595_STORE, PC2) </pre> ==== ECMD ==== {| border=1 | '''Syntax''' | '''Kurze Beschreibung''' |- | io set port NUM HEXVALUE [MASK] | Setzt Port NUM auf den Wert HEXVALUE (ggf. wird die angegebene MASK verwendet). Port 4 ist der erste, Port 5 der zweite 74HC595 etc. |- |} === 74HC164 als Ausgangserweiterung === Der 74HC164 ist ein 8-bit Seriell-in/Parallel-out Schieberegister. Das kann man z.B. dazu benutzen um ein handelsübliches LCD mit HD44780-Controller mit nur 3 Leitungen anzusteuern (bei direkter Ansteuerung würden 7 Portleitungen benötigt), so wird das bei U. Radig's Webserver gemacht.<br> In diesem Fall wird kein Latch benötigt, da das LCD erst beim Schalten seiner "E"-Leitung (enable) die Daten aus dem Schieberegister übernimmt. Schaltbild siehe bei [http://www.ulrichradig.de/home/index.php/software/avr-webserver-software AVR Webserver Software] { ''menuconfig todo'' } { ''pinning todo'' } ==D/A-Wandler mit LTC1257== Der LTC1257 ist ein 12bit Digital-Analog-Wandler mit seriellem Eingang und interner Referenzspannung. Zur Steuerung benötigt er lediglich 3 Portleitungen. Da er laut [http://cds.linear.com/docs/Datasheet/1257fb.pdf Datenblatt] mindestens 4,75 Volt Versorgungsspannung braucht, ist er nicht in Systemen mit 3,3 Volt einsetzbar. Die einfachste Form der Anbindung könnte so aussehen: [[Bild:LTC1257.png]] Das nötige Pinning ist für AVR-NET-IO bereits vorhanden, in der Zuordnung *PA0 = LOAD *PA1 = DATA *PA2 = CLK Mit <code>ltc1257_init</code> werden die Portleitungen passend initialisiert (lt. Datenblatt). Mit <code>ltc1257_delay</code> kann die interne Wartezeit in µs gesetzt werden, die zum Erkennen des Flankenwechsels durch den DAC beim Schreiben eines Bits gewartet wird (ist vor allem hilfreich, wenn der LTC1257 über Optopkoppler (z.B. CNY17) entkoppelt ist). Mit <code>ltc1257_set</code> werden die tatsächlichen Werte gesetzt, die der LTC1257 dann als Analogsignal ausgibt. Bei der Verwendung von mehreren LTC1257 im Daisy Chain muss die Reihenfolge der Werte für <code>ltc1257_set</code> in der <b>umgekehrten</b> Reihenfolge der DACs gesendet werden (d.h. das erste Argument ist für den letzten DAC). [[Category:Ethersex]] [[Category:Hardware]] c6feed88a4a0b245e3856aa737ab4d4f8a1e0a07 356 355 2012-01-12T21:25:13Z Hugo790 425 /* Anschluss */ wikitext text/x-wiki {{i18n|Porterweiterungen}} ==Porterweiterungen== Wenn am AVR schon viele Erweiterungen angeschlossen sind und die freien Ports langsam zur Neige gehen, kann man mit Schieberegistern arbeiten. Zwei dieser Bausteine sind bereits in der SW vorgesehen und können per menuconfig freigeschaltet werden. === 74HC165 als Eingangserweiterung === Der 74HC165 ist ein 8-bit Parallel-in/Seriell-out Schieberegister. Das kann man z.B. dazu benutzen um mehrere Schalteingänge seriell abzufragen. So könnte man z.B. 8 Taster mit nur 3 Leitungen abfragen und spart in diesem Fall 5 Portleitungen. Diese Schaltung ist kaskadierbar, so daß weitere Eingänge abgefragt werden können ohne mehr Portleitungen zu benötigen. ==== Anschluss ==== <pre> HC165_DATA: QH (erster 74HC165) HC165_CLOCK: CLOCK (alle) HC165_LOAD: Shift/Load (alle) GND: Clock Inhibit SERIAL INPUT: QH (zweiter 74HC165) </pre> Schaltbild siehe bei [http://www.mikrocontroller.net/articles/Porterweiterung_mit_SPI#Eing.C3.A4nge www.mikrocontroller.net] ==== Konfiguration ==== │ │ I/O ---> ... │ │ [*] HC165 input expansion ---> ... │ │ [ ] Inverse output │ │ (1) Number of HC165 registers In der bei "Hardware/Periphery Class" ausgewählten .m4-Datei muss angegeben werden, wo der erste 74HC165 angeschlossen ist, z.B.: <pre> pin(HC165_DATA, PC3) pin(HC165_CLOCK, PC4) pin(HC165_LOAD, PC5) </pre> ==== ECMD ==== {| border=1 | '''Syntax''' | '''Kurze Beschreibung''' |- | io get pin NUM | Liefert als Rückgabewert den Hexadezimalwert vom 74HC595. Pin 4 ist der erste, Pin 5 der zweite etc. |- |} === 74HC595 als Ausgangserweiterung === Der 74HC595 ist ein 8-bit Seriell-in/Parallel-out Schieberegister mit Latch. Das Latch braucht man, damit beim seriellen reinschieben der Bits diese nicht nacheinander an den Ausgängen erscheinen, sondern erst wenn das ganze Datenwort reingeschoben ist. Der 74HC595 ist sogar kaskadierbar, d.h. man kann theoretisch beliebig viele Ausgänge realisieren, ohne weitere Portleitungen zu benötigen. ==== Anschluss ==== <pre> HC595_DATA: Serial Data Input (SI) (erster 74HC595) HC595_CLOCK: SCK (an alle) HC595_STORE: RCK (an alle) QH* bzw. Q7*: Serial Data Input (SI) (zweiter 74HC595) </pre> [[File:Hc595_example.png|thumb|Schaltbild 74HC595]] Weitere Informationen siehe bei [http://www.mikrocontroller.net/articles/Porterweiterung_mit_SPI#Ausg.C3.A4nge www.mikrocontroller.net] ==== Konfiguration ==== │ │ I/O ---> ... │ │ [*] HC595 output expansion ---> ... │ │ (1) Number of HC595 registers In der bei "Hardware/Periphery Class" ausgewählten .m4-Datei muss angegeben werden, wo der erste 74HC595 angeschlossen ist, z.B.: <pre> pin(HC595_DATA, PC0) pin(HC595_CLOCK, PC1) pin(HC595_STORE, PC2) </pre> ==== ECMD ==== {| border=1 | '''Syntax''' | '''Kurze Beschreibung''' |- | io set port NUM HEXVALUE [MASK] | Setzt Port NUM auf den Wert HEXVALUE (ggf. wird die angegebene MASK verwendet). Port 4 ist der erste, Port 5 der zweite 74HC595 etc. |- |} === 74HC164 als Ausgangserweiterung === Der 74HC164 ist ein 8-bit Seriell-in/Parallel-out Schieberegister. Das kann man z.B. dazu benutzen um ein handelsübliches LCD mit HD44780-Controller mit nur 3 Leitungen anzusteuern (bei direkter Ansteuerung würden 7 Portleitungen benötigt), so wird das bei U. Radig's Webserver gemacht.<br> In diesem Fall wird kein Latch benötigt, da das LCD erst beim Schalten seiner "E"-Leitung (enable) die Daten aus dem Schieberegister übernimmt. Schaltbild siehe bei [http://www.ulrichradig.de/home/index.php/software/avr-webserver-software AVR Webserver Software] { ''menuconfig todo'' } { ''pinning todo'' } ==D/A-Wandler mit LTC1257== Der LTC1257 ist ein 12bit Digital-Analog-Wandler mit seriellem Eingang und interner Referenzspannung. Zur Steuerung benötigt er lediglich 3 Portleitungen. Da er laut [http://cds.linear.com/docs/Datasheet/1257fb.pdf Datenblatt] mindestens 4,75 Volt Versorgungsspannung braucht, ist er nicht in Systemen mit 3,3 Volt einsetzbar. Die einfachste Form der Anbindung könnte so aussehen: [[Bild:LTC1257.png]] Das nötige Pinning ist für AVR-NET-IO bereits vorhanden, in der Zuordnung *PA0 = LOAD *PA1 = DATA *PA2 = CLK Mit <code>ltc1257_init</code> werden die Portleitungen passend initialisiert (lt. Datenblatt). Mit <code>ltc1257_delay</code> kann die interne Wartezeit in µs gesetzt werden, die zum Erkennen des Flankenwechsels durch den DAC beim Schreiben eines Bits gewartet wird (ist vor allem hilfreich, wenn der LTC1257 über Optopkoppler (z.B. CNY17) entkoppelt ist). Mit <code>ltc1257_set</code> werden die tatsächlichen Werte gesetzt, die der LTC1257 dann als Analogsignal ausgibt. Bei der Verwendung von mehreren LTC1257 im Daisy Chain muss die Reihenfolge der Werte für <code>ltc1257_set</code> in der <b>umgekehrten</b> Reihenfolge der DACs gesendet werden (d.h. das erste Argument ist für den letzten DAC). [[Category:Ethersex]] [[Category:Hardware]] 448e1c415d7de2eeadd0f1efd0269939fbf34627 358 356 2012-01-12T21:58:46Z Hugo790 425 /* D/A-Wandler mit LTC1257 */ wikitext text/x-wiki {{i18n|Porterweiterungen}} ==Porterweiterungen== Wenn am AVR schon viele Erweiterungen angeschlossen sind und die freien Ports langsam zur Neige gehen, kann man mit Schieberegistern arbeiten. Zwei dieser Bausteine sind bereits in der SW vorgesehen und können per menuconfig freigeschaltet werden. === 74HC165 als Eingangserweiterung === Der 74HC165 ist ein 8-bit Parallel-in/Seriell-out Schieberegister. Das kann man z.B. dazu benutzen um mehrere Schalteingänge seriell abzufragen. So könnte man z.B. 8 Taster mit nur 3 Leitungen abfragen und spart in diesem Fall 5 Portleitungen. Diese Schaltung ist kaskadierbar, so daß weitere Eingänge abgefragt werden können ohne mehr Portleitungen zu benötigen. ==== Anschluss ==== <pre> HC165_DATA: QH (erster 74HC165) HC165_CLOCK: CLOCK (alle) HC165_LOAD: Shift/Load (alle) GND: Clock Inhibit SERIAL INPUT: QH (zweiter 74HC165) </pre> Schaltbild siehe bei [http://www.mikrocontroller.net/articles/Porterweiterung_mit_SPI#Eing.C3.A4nge www.mikrocontroller.net] ==== Konfiguration ==== │ │ I/O ---> ... │ │ [*] HC165 input expansion ---> ... │ │ [ ] Inverse output │ │ (1) Number of HC165 registers In der bei "Hardware/Periphery Class" ausgewählten .m4-Datei muss angegeben werden, wo der erste 74HC165 angeschlossen ist, z.B.: <pre> pin(HC165_DATA, PC3) pin(HC165_CLOCK, PC4) pin(HC165_LOAD, PC5) </pre> ==== ECMD ==== {| border=1 | '''Syntax''' | '''Kurze Beschreibung''' |- | io get pin NUM | Liefert als Rückgabewert den Hexadezimalwert vom 74HC595. Pin 4 ist der erste, Pin 5 der zweite etc. |- |} === 74HC595 als Ausgangserweiterung === Der 74HC595 ist ein 8-bit Seriell-in/Parallel-out Schieberegister mit Latch. Das Latch braucht man, damit beim seriellen reinschieben der Bits diese nicht nacheinander an den Ausgängen erscheinen, sondern erst wenn das ganze Datenwort reingeschoben ist. Der 74HC595 ist sogar kaskadierbar, d.h. man kann theoretisch beliebig viele Ausgänge realisieren, ohne weitere Portleitungen zu benötigen. ==== Anschluss ==== <pre> HC595_DATA: Serial Data Input (SI) (erster 74HC595) HC595_CLOCK: SCK (an alle) HC595_STORE: RCK (an alle) QH* bzw. Q7*: Serial Data Input (SI) (zweiter 74HC595) </pre> [[File:Hc595_example.png|thumb|Schaltbild 74HC595]] Weitere Informationen siehe bei [http://www.mikrocontroller.net/articles/Porterweiterung_mit_SPI#Ausg.C3.A4nge www.mikrocontroller.net] ==== Konfiguration ==== │ │ I/O ---> ... │ │ [*] HC595 output expansion ---> ... │ │ (1) Number of HC595 registers In der bei "Hardware/Periphery Class" ausgewählten .m4-Datei muss angegeben werden, wo der erste 74HC595 angeschlossen ist, z.B.: <pre> pin(HC595_DATA, PC0) pin(HC595_CLOCK, PC1) pin(HC595_STORE, PC2) </pre> ==== ECMD ==== {| border=1 | '''Syntax''' | '''Kurze Beschreibung''' |- | io set port NUM HEXVALUE [MASK] | Setzt Port NUM auf den Wert HEXVALUE (ggf. wird die angegebene MASK verwendet). Port 4 ist der erste, Port 5 der zweite 74HC595 etc. |- |} === 74HC164 als Ausgangserweiterung === Der 74HC164 ist ein 8-bit Seriell-in/Parallel-out Schieberegister. Das kann man z.B. dazu benutzen um ein handelsübliches LCD mit HD44780-Controller mit nur 3 Leitungen anzusteuern (bei direkter Ansteuerung würden 7 Portleitungen benötigt), so wird das bei U. Radig's Webserver gemacht.<br> In diesem Fall wird kein Latch benötigt, da das LCD erst beim Schalten seiner "E"-Leitung (enable) die Daten aus dem Schieberegister übernimmt. Schaltbild siehe bei [http://www.ulrichradig.de/home/index.php/software/avr-webserver-software AVR Webserver Software] { ''menuconfig todo'' } { ''pinning todo'' } ==D/A-Wandler mit LTC1257== Der LTC1257 ist ein 12bit Digital-Analog-Wandler mit seriellem Eingang und interner Referenzspannung. Zur Steuerung benötigt er lediglich 3 Portleitungen. Da er laut [http://cds.linear.com/docs/Datasheet/1257fb.pdf Datenblatt] mindestens 4,75 Volt Versorgungsspannung braucht, ist er nicht in Systemen mit 3,3 Volt einsetzbar. === Anschluss === Für eine einfache Form der Anbindung siehe Schaltbild. [[File:LTC1257.png|thumb|Schaltbild LTC1257]] === Konfiguration === Das nötige Pinning ist für AVR-NET-IO bereits vorhanden, in der Zuordnung *PA0 = LOAD *PA1 = DATA *PA2 = CLK Mit <code>ltc1257_init</code> werden die Portleitungen passend initialisiert (lt. Datenblatt). Mit <code>ltc1257_delay</code> kann die interne Wartezeit in µs gesetzt werden, die zum Erkennen des Flankenwechsels durch den DAC beim Schreiben eines Bits gewartet wird (ist vor allem hilfreich, wenn der LTC1257 über Optopkoppler (z.B. CNY17) entkoppelt ist). Mit <code>ltc1257_set</code> werden die tatsächlichen Werte gesetzt, die der LTC1257 dann als Analogsignal ausgibt. Bei der Verwendung von mehreren LTC1257 im Daisy Chain muss die Reihenfolge der Werte für <code>ltc1257_set</code> in der <b>umgekehrten</b> Reihenfolge der DACs gesendet werden (d.h. das erste Argument ist für den letzten DAC). [[Category:Ethersex]] [[Category:Hardware]] 223e92daf14236531355f6ef88b27ac65762f3a8 359 358 2012-01-12T22:43:56Z Hugo790 425 /* Konfiguration */ wikitext text/x-wiki {{i18n|Porterweiterungen}} ==Porterweiterungen== Wenn am AVR schon viele Erweiterungen angeschlossen sind und die freien Ports langsam zur Neige gehen, kann man mit Schieberegistern arbeiten. Zwei dieser Bausteine sind bereits in der SW vorgesehen und können per menuconfig freigeschaltet werden. === 74HC165 als Eingangserweiterung === Der 74HC165 ist ein 8-bit Parallel-in/Seriell-out Schieberegister. Das kann man z.B. dazu benutzen um mehrere Schalteingänge seriell abzufragen. So könnte man z.B. 8 Taster mit nur 3 Leitungen abfragen und spart in diesem Fall 5 Portleitungen. Diese Schaltung ist kaskadierbar, so daß weitere Eingänge abgefragt werden können ohne mehr Portleitungen zu benötigen. ==== Anschluss ==== <pre> HC165_DATA: QH (erster 74HC165) HC165_CLOCK: CLOCK (alle) HC165_LOAD: Shift/Load (alle) GND: Clock Inhibit SERIAL INPUT: QH (zweiter 74HC165) </pre> Schaltbild siehe bei [http://www.mikrocontroller.net/articles/Porterweiterung_mit_SPI#Eing.C3.A4nge www.mikrocontroller.net] ==== Konfiguration ==== │ │ I/O ---> ... │ │ [*] HC165 input expansion ---> ... │ │ [ ] Inverse output │ │ (1) Number of HC165 registers In der bei "Hardware/Periphery Class" ausgewählten .m4-Datei muss angegeben werden, wo der erste 74HC165 angeschlossen ist, z.B.: <pre> pin(HC165_DATA, PC3) pin(HC165_CLOCK, PC4) pin(HC165_LOAD, PC5) </pre> ==== ECMD ==== {| border=1 | '''Syntax''' | '''Kurze Beschreibung''' |- | io get pin NUM | Liefert als Rückgabewert den Hexadezimalwert vom 74HC595. Pin 4 ist der erste, Pin 5 der zweite etc. |- |} === 74HC595 als Ausgangserweiterung === Der 74HC595 ist ein 8-bit Seriell-in/Parallel-out Schieberegister mit Latch. Das Latch braucht man, damit beim seriellen reinschieben der Bits diese nicht nacheinander an den Ausgängen erscheinen, sondern erst wenn das ganze Datenwort reingeschoben ist. Der 74HC595 ist sogar kaskadierbar, d.h. man kann theoretisch beliebig viele Ausgänge realisieren, ohne weitere Portleitungen zu benötigen. ==== Anschluss ==== <pre> HC595_DATA: Serial Data Input (SI) (erster 74HC595) HC595_CLOCK: SCK (an alle) HC595_STORE: RCK (an alle) QH* bzw. Q7*: Serial Data Input (SI) (zweiter 74HC595) </pre> [[File:Hc595_example.png|thumb|Schaltbild 74HC595]] Weitere Informationen siehe bei [http://www.mikrocontroller.net/articles/Porterweiterung_mit_SPI#Ausg.C3.A4nge www.mikrocontroller.net] ==== Konfiguration ==== │ │ I/O ---> ... │ │ [*] HC595 output expansion ---> ... │ │ (1) Number of HC595 registers In der bei "Hardware/Periphery Class" ausgewählten .m4-Datei muss angegeben werden, wo der erste 74HC595 angeschlossen ist, z.B.: <pre> pin(HC595_DATA, PC0) pin(HC595_CLOCK, PC1) pin(HC595_STORE, PC2) </pre> ==== ECMD ==== {| border=1 | '''Syntax''' | '''Kurze Beschreibung''' |- | io set port NUM HEXVALUE [MASK] | Setzt Port NUM auf den Wert HEXVALUE (ggf. wird die angegebene MASK verwendet). Port 4 ist der erste, Port 5 der zweite 74HC595 etc. |- |} === 74HC164 als Ausgangserweiterung === Der 74HC164 ist ein 8-bit Seriell-in/Parallel-out Schieberegister. Das kann man z.B. dazu benutzen um ein handelsübliches LCD mit HD44780-Controller mit nur 3 Leitungen anzusteuern (bei direkter Ansteuerung würden 7 Portleitungen benötigt), so wird das bei U. Radig's Webserver gemacht.<br> In diesem Fall wird kein Latch benötigt, da das LCD erst beim Schalten seiner "E"-Leitung (enable) die Daten aus dem Schieberegister übernimmt. Schaltbild siehe bei [http://www.ulrichradig.de/home/index.php/software/avr-webserver-software AVR Webserver Software] { ''menuconfig todo'' } { ''pinning todo'' } ==D/A-Wandler mit LTC1257== Der LTC1257 ist ein 12bit Digital-Analog-Wandler mit seriellem Eingang und interner Referenzspannung. Zur Steuerung benötigt er lediglich 3 Portleitungen. Da er laut [http://cds.linear.com/docs/Datasheet/1257fb.pdf Datenblatt] mindestens 4,75 Volt Versorgungsspannung braucht, ist er nicht in Systemen mit 3,3 Volt einsetzbar. === Anschluss === Für eine einfache Form der Anbindung siehe Schaltbild. [[File:LTC1257.png|thumb|Schaltbild LTC1257]] === Konfiguration === │ │ I/O ---> ... │ │ [*] digital-to-analog converter (DAC) ---> ... │ │ [*] LTC1257 Output │ │ (4) LTC1257: Maximum number of devices Das nötige Pinning ist für AVR-NET-IO bereits vorhanden, in der Zuordnung <pre> pin(LTC1257_CLK, PA2, OUTPUT) pin(LTC1257_DATA, PA1, OUTPUT) pin(LTC1257_LOAD, PA0, OUTPUT) </pre> Mit <code>ltc1257_init</code> werden die Portleitungen passend initialisiert (lt. Datenblatt). Mit <code>ltc1257_delay</code> kann die interne Wartezeit in µs gesetzt werden, die zum Erkennen des Flankenwechsels durch den DAC beim Schreiben eines Bits gewartet wird (ist vor allem hilfreich, wenn der LTC1257 über Optopkoppler (z.B. CNY17) entkoppelt ist). Mit <code>ltc1257_set</code> werden die tatsächlichen Werte gesetzt, die der LTC1257 dann als Analogsignal ausgibt. Bei der Verwendung von mehreren LTC1257 im Daisy Chain muss die Reihenfolge der Werte für <code>ltc1257_set</code> in der <b>umgekehrten</b> Reihenfolge der DACs gesendet werden (d.h. das erste Argument ist für den letzten DAC). [[Category:Ethersex]] [[Category:Hardware]] 55be10446ae5da1990bbe7c23a7c4d0b2766bc6d 1 146 341 2012-01-10T11:50:33Z Hugo790 425 Created page with "Seite vom alten wiki uebertragen und den Abschnitt HC595 angefangen anzupassen." wikitext text/x-wiki Seite vom alten wiki uebertragen und den Abschnitt HC595 angefangen anzupassen. 8e263cc5a05cbf79459bfefb5d8aa01cf2208d2c 346 341 2012-01-11T17:07:32Z Mgue 312 moved [[Talk:Porterweiterungen]] to [[Talk:Porterweiterungen (Deutsch)]]:&#32;Don't mix german pages with english pages! wikitext text/x-wiki Seite vom alten wiki uebertragen und den Abschnitt HC595 angefangen anzupassen. 8e263cc5a05cbf79459bfefb5d8aa01cf2208d2c 0 119 342 312 2012-01-10T20:49:37Z Morais 209 wikitext text/x-wiki {{i18n|DMX FXSlot}} {{Module |NAME=DMX FXSlot |MENUCONFIG={{Applications}}->DMX FXSlot |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] [[DMX Storage]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/services/dmx-fxslot https://github.com/ethersex/ethersex/tree/master/services/dmx-fxslot] }} DMX FXSlot provides slots which can be assigned to different effects/animations and devices during runtime. DMX FXslot is part of the [[Ethersex Lighting Architecture]]. == Idea of FXSlot == First advantage of FXSlot is, that you have to implement an effect or animation only once. One time you implement an effect you can multiple assign it with different speeds to different FXSlots during runtime. Second advantage is that an FXSlot can be assigned to different DMX channels during runtime. A small downside however is that effects can't communicate with each other. == Available Effects == {| !Name !Description !Number |- |Rainbow Effect |Fades through all "rainbow" colors - or 0->360° in the [http://en.wikipedia.org/wiki/HSL_and_HSV HSV Model] |1 |- |Random Colors |Generates a random color |2 |- |Fire Simulation |a nice open fire effect |3 |- |Water Simulation |Fades through common water colors |4 |- |} == EEPROM save and restore == You can enable the autosave feature to save all fxslots to the EEPROM each time you can something using the [[ECMD]] commands. The settings (not the effect values) will be restored when ethersex boots if you have checked the autorestore option in menuconfig. == Examples == 1. One RGB PAR with DMX adress 10 in universe 1 with random color effect. set device of FXSlot 0 : <code>dmx fxslot devices 0 1 0 10 1</code><br> <code>dmx fxslot devices [fxslot_number] [amount_of_devices] [universe] [startchannel] [margin_between_devices]</code> set effect of FXSlot 0 : <code>dmx fxslot effect 0 1 2 20</code><br> <code>dmx fxslot effect [fxslot_number] [active] [effect_number] [speed]</code> [[Category:e6la]] 7045a39c641035dd7d6625a1a2d265b4c87f275b 360 342 2012-01-16T22:58:07Z Morais 209 wikitext text/x-wiki {{i18n|DMX FXSlot}} {{Module |NAME=DMX FXSlot |MENUCONFIG={{Applications}}->DMX FXSlot |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] [[DMX Storage]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/services/dmx-fxslot https://github.com/ethersex/ethersex/tree/master/services/dmx-fxslot] }} DMX FXSlot provides slots which can be assigned to different effects/animations and devices during runtime. DMX FXslot is part of the [[Ethersex Lighting Architecture]]. == Idea of FXSlot == First advantage of FXSlot is, that you have to implement an effect or animation only once. One time you implement an effect you can multiple assign it with different speeds to different FXSlots during runtime. Second advantage is that an FXSlot can be assigned to different DMX channels during runtime. A small downside however is that effects can't communicate with each other. == Available Effects == {| !Name !Description !Number |- |Rainbow Effect |Fades through all "rainbow" colors - or 0->360° in the [http://en.wikipedia.org/wiki/HSL_and_HSV HSV Model] |1 |- |Random Colors |Generates a random color |2 |- |Fire Simulation |a nice open fire effect |3 |- |Water Simulation |Fades through common water colors |4 |- |} == EEPROM save and restore == You can enable the autosave feature to save all fxslots to the EEPROM each time you can something using the [[ECMD]] commands. The settings (not the effect values) will be restored when ethersex boots if you have checked the autorestore option in menuconfig. == Examples == 1. One RGB PAR with DMX adress 10 in universe 1 with random color effect. set device of FXSlot 0 : <code>dmx fxslot devices 0 1 0 10 1</code><br> <code>dmx fxslot devices [fxslot_number] [amount_of_devices] [margin_between_devices] [startchannel] [universe] </code> set effect of FXSlot 0 : <code>dmx fxslot effect 0 1 2 20</code><br> <code>dmx fxslot effect [fxslot_number] [active] [effect_number] [speed]</code> [[Category:e6la]] 18e4f1ffaf867f259671605000e266131f5c90c6 0 147 345 2012-01-11T17:07:32Z Mgue 312 moved [[Porterweiterungen]] to [[Porterweiterungen (Deutsch)]]:&#32;Don't mix german pages with english pages! wikitext text/x-wiki #REDIRECT [[Porterweiterungen (Deutsch)]] bbee784730f5c44884b8c1f83672444017aa9d7d 348 345 2012-01-11T17:08:07Z Mgue 312 wikitext text/x-wiki {{i18n|Porterweiterungen}} 8808fd7e9090c2a0bc971dbc3160cea7d1462b88 1 148 347 2012-01-11T17:07:32Z Mgue 312 moved [[Talk:Porterweiterungen]] to [[Talk:Porterweiterungen (Deutsch)]]:&#32;Don't mix german pages with english pages! wikitext text/x-wiki #REDIRECT [[Talk:Porterweiterungen (Deutsch)]] 905814f5e78294a0f0bd1fd9ec0344ca5e840b0d 349 347 2012-01-11T17:08:58Z Mgue 312 don't redirect wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 43 350 311 2012-01-12T00:42:07Z LadySM 0 Importing text file wikitext text/x-wiki <div class="errorbox"> This page is automatically generated from the files in the Ethersex source code repository. Do not edit this page but send [[patches]] for those files! </div> __NOTOC__ == Analog/Digital Conversion ([[ADC]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | adc get [CHANNEL] | Get the ADC value in hex of CHANNEL or if no channel set of all channels. |- | hr20 temp | Read HR20 temperature sensor. |- |} == DNS Resolver == {| border='1' | ''Command syntax'' | ''Short description'' |- | dns server [IPADDR] | Display/Set the IP address of the DNS server to use to IPADDR. |- | nslookup HOSTNAME | Do DNS lookup for HOSTNAME (call twice). |- |} == Digital/Analog Conversion ([[DAC]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ltc1257_delay `[VALUE] | Set (if VALUE given) or get (no VALUE) delay for LTC1257 output bit changes in µs' |- | ltc1257_set `[VALUE0] [VALUE1] ... | Set output to value (value: 0-4095)' |- | tlc5620 `[CHANNEL] [VALUE] | Set Output to value (Value: 0-0xff)' |- |} == Fnordlicht == {| border='1' | ''Command syntax'' | ''Short description'' |- | fnordlicht "ADDRESS RED | GREEN,BLUE",fnordlicht command to set RGB color |- | fnordlicht_init | fnordlicht init |- |} == HD44780 [[LCD]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | hr20 hourbar START STOP | Update hourbar to show ticks between START and STOP (range 0..23) |- | hr20 toggle SEG | Toggle segment SEG (a number, not a symbolic name!) |- | lcd backlight STATE | switch back light STATE to ON or OFF |- | lcd char N D1 D2 D3 D4 D5 D6 D7 D8 | Define use-definable char N with data D1..D8 (provide DATA in hex) |- | lcd clear [LINE] | Clear line LINE (0..3) or the whole display (if parameter is omitted) |- | lcd goto LINE COL | Move cursor to LINE and column COL (origin is 0/0) |- | lcd reinit CURSOR BLINK | Reinitialize the display, set whether to show the cursor (CURSOR, 0 or 1) and whether the cursor shall BLINK |- | lcd shift DIR | Shift the display to DIR (either ''left'' or ''right'') |- | lcd write TEXT | Write TEXT to the current cursor location |- |} == Infrared Send/Receive ([[IR-TRX]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ir receive | receive an IR command |- | ir send DEVICE COMMAND | send COMMAND to DEVICE |- |} == Infrared Send/Receive ([[IRMP]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | irmp receive | receive an IR command |- | irmp send PROTOCOL DEVICE COMMAND REPEAT | send COMMAND with REPEAT flag to DEVICE using PROTOCOL |- |} == NTP Client == {| border='1' | ''Command syntax'' | ''Short description'' |- | ntp query | Query the NTP server to get an NTP update. |- | ntp server [IPADDR] | Display/Set the IP address of the NTP server to use to IPADDR. |- | ntp status | Display NTP server status |- |} == Network configuration == {| border='1' | ''Command syntax'' | ''Short description'' |- | enc dump | Dump the internal state of the enc to serial |- | gw [IP] | Display/Set the address of the default router. |- | ip [IP] | Display/Set the IP address. |- | mac [xx:xx:xx:xx:xx:xx] | Display/Set the MAC address. |- | netmask [IP] | Display/Set the network mask. |- |} == Port I/O == {| border='1' | ''Command syntax'' | ''Short description'' |- | io get ddr PORTNUM | Display the current value of the DDR PORTNUM. |- | io get mask PORTNUM | Display the mask of the port PORTNUM. |- | io get pin PORTNUM | Display the current value of the PIN-register of the port PORTNUM. |- | io get port NUM | Display the current value of the PORT NUM. |- | io set ddr PORTNUM HEXVALUE [MASK] | Set the DDR of port PORTNUM to VALUE (possibly using the provided MASK). |- | io set port NUM HEXVALUE [MASK] | Set the PORT NUM to VALUE (possibly using the provided MASK). |- |} == Reading and Writing EEPROM Space on Device == {| border='1' | ''Command syntax'' | ''Short description'' |- | eer eer <ADDR> <LENGTH> | Read n bytes from address after the config in eeprom. |- | eew eew <ADDR> <HEXBYTES> | Write Hexbytes at address after the config in epprom. |- | fuse | Display current fuse settings |- | hostname | Display hostname. |- |} == Resetting the controller == {| border='1' | ''Command syntax'' | ''Short description'' |- | bootloader | Call the bootloader. |- | reset | Reset the Ethersex. |- | wdreset | Go into endless loop to trigger a watchdog timeout. |- |} == [[ADS]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | ads get | Get the ADC value in hex. |- | ads mean [COUNT] | Get the mean of power of 2 COUNT ADC values in hex. |- |} == [[Am_Puls_der_Zeit|Clock]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | date | Display the current date. |- | lastdcf | Display when last valid DCF Signal was received. |- | time [UNIXTIME] | Display/Set the current time in seconds since January 1st 1970. |- | uptime | Display ethersex uptime in unix format. |- | whm | Display ethersex uptime. |- |} == [[Application_Sample]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sample | Manually call application sample commands |- | sample_init | Manually call application sample init method |- | sample_periodic | Manually call application sample periodic method |- |} == [[Blinkenlights_MCUF|MCUF]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | mcuf modul N | Select module N |- | mcuf modul list | List all modules |- | mcuf showclock | Show digital clock |- | mcuf showstring MESSAGE | Show scrolling MESSAGE on the display |- |} == [[CRON-Dienst]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | cron_add MIN HOUR DAY MONTH DOW ECMD | Add ECMD to cron to be executed at given time |- | cron_list | Show all cron entries |- | cron_make_persistent | Mark a Job as persistent |- | cron_rm POSITION | Remove one cron entry |- | cron_save | Saves all persistent jobs |- |} == [[DALI]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dali cmd [TARGET] [COMMAND] [!][?] | "send the given command (decimal) to targets (all, g00 to g15, s00 to s63), auto repeat with !, read reply with ?" |- | dali dim [TARGET] [LEVEL] | "dim targets (all, g00 to g15, s00 to s63) to given level (0-254)" |- | dali raw [BYTE1] [BYTE2] | "send a raw frame (two bytes, given in hex) over the DALI bus" |- | dali scmd [SPECIAL COMMAND] [DATA] [!][?] | "send special command (256-287) with data, auto repeat with !, read reply with ?" |- |} == [[DMX_FXSlot]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx fxslot devices | set the device settings |- | dmx fxslot effect | set the effect settings |- | dmx fxslot reset | reset all fxslots and clear saved ones in EEPROM |- | dmx fxslot restore | restore the settings from EEPROM |- | dmx fxslot save | save the current fxslots to EEPROM |- |} == [[DMX_Storage]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx channels | Get channels per universe |- | dmx get | Return channel value |- | dmx set | Set channel values |- | dmx universe | Get a whole universe |- | dmx universes | Get universes |- |} == [[Dallas_1-wire_Bus]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | 1w convert [DEVICE] | Trigger temperature conversion of either DEVICE or all connected devices |- | 1w ds2450 convert [DEVICE] | `start conversion (with optional input mask and read out control)' |- | 1w ds2450 get [DEVICE] | `get conversion result (one or all channels)' |- | 1w ds2450 oc [DEVICE] | `get/set output control (per channel)' |- | 1w ds2450 oe [DEVICE] | `get/set output enable (per channel)' |- | 1w ds2450 por [DEVICE] | `get/set power on reset (per channel)' |- | 1w ds2450 power [DEVICE] | `get/set power supply of device (global)' |- | 1w ds2450 range [DEVICE] | `get/set input voltage range (per channel)' |- | 1w ds2450 res [DEVICE] | `get/set bit resolution of AD convert (per channel)' |- | 1w get DEVICE | Return temperature value of onewire DEVICE (provide 64-bit ID as 16-hex-digits) |- | 1w list | Return a list of the connected onewire devices |- |} == [[DataFlash]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | df status | Display internal status. |- | fs format | Format the filesystem. |- | fs inspect inode INODE | Inspect INODE (and associated page). |- | fs inspect node NODE | Inspect NODE and dump to serial. |- | fs list | List the directory. |- | fs mkfile NAME | Create a new file NAME. |- | fs remove NAME | Delete the file NAME. |- | fs truncate NAME LEN | Truncate the file NAME to LEN bytes. |- |} == [[Dc3840_camera|DC3840 mobil camera support]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dc3840 capture | Take a picture. Access 'dc3840' via VFS afterwards. See [[DC3840 Camera]] for details. |- | dc3840 light | Light level of camera |- | dc3840 send A B C D E | Send provided command bytes to the camera. |- | dc3840 sync | Re-sync to the camera |- | dc3840 zoom | Enable zoom of camera |- |} == [[ECMDScript]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | call FILENAME | Start script named FILENAME |- | cat FILENAME | cat file content (with debug only) |- | dec VAR | Decrement variable VAR (a number) |- | echo <any> | Print out all arguments of echo |- | exit | Exit currently running script |- | get VAR | Get value of variable VAR |- | goto N | Goto line N in currently running script |- | if ( CMD/VAR == CONST ) then CMD2 | If condition matches execute CMD2 |- | inc VAR | Increment variable VAR (a number) |- | rem <any> | Remark for anything |- | set VAR VALUE | Set variable VAR to VALUE |- | wait I | Wait I milliseconds |- |} == [[FS20]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fht send HOUSECODE ADDR CMD [CMD2] | Send FHT command. See [[FS20]] for details. |- | fs20 receive | Receive FS20/FHT sequence and display it. |- | fs20 send HOUSECODE ADDR CMD [CMD2] | Send FS20 command. See [[FS20]] for details. |- | fs20 ws300 | Receive FS20 sequence from WS300 weather station and decode it. |- |} == [[Frequency Counter]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fc %duty [CHANNEL] | "returns last on duty cycle in percent for given channel" |- | fc duty [CHANNEL] | "returns last on duty cycle (0-255) for given channel" |- | fc freq [CHANNEL] | "returns last frequency in Hz for given channel" |- | fc off [CHANNEL] | "switch off frequency counting on given channel" |- | fc on [CHANNEL] | "switch on frequency counting on given channel" |- | fc ticks [CHANNEL] | "returns last frequency in CPU ticks for given channel" |- |} == [[GLCD_Menu]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | glcdmenu key VALUE | Send a keypress to the menu |- | glcdmenu update | Update the menu |- |} == [[GPS]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | nmea get | Get latitude and longitude data |- | nmea satellites | Get satellites |- |} == [[H-Bridge]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | hbridge [action] [enable_l] [enable_r] | Set H-Bridge command |- | hbridge pwm int | Set H-Bridge enable line valueeg. speed |- |} == [[I2C]] (TWI) == {| border='1' | ''Command syntax'' | ''Short description'' |- | bmp085 apress | Get absolute pressure in Pa |- | bmp085 height PRESSNN | Get height in cm, pressure at N0 needed |- | bmp085 pressnn HEIGHT | Get pressure at N0, height in cm needed |- | bmp085 temp | Get temperature in 0.1°C |- | ds1631 convert ADDR VALUE | Initiate temperature conversions (0: stop, 1: convert) |- | ds1631 temp ADDR | Read last converted temperature |- | i2c detect | list detected I2C Chips |- | i2c rbb ADDR | read byte from I2C chip |- | i2c rbd CHIPADDR REGADDR | read byte from register address at I2C chip |- | i2c rwd CHIPADDR REGADDR | read word from register address at I2C chip |- | i2c wbb ADDR HEXVALUE | write byte to I2C chip |- | i2c wbd CHIPADDR REGADDR HEXVALUE | write byte to register address on I2C chip |- | i2c wwd CHIPADDR REGADDR HEXVALUE | write word to register address on I2C chip |- | lm75 ADDR | Get temperature |- | max7311 getDDRw ADDR | Get Direction-Register DDR |- | max7311 getINw ADDR | Get Input-Register IN |- | max7311 getOUTw ADDR | Get Output-Register OUT |- | max7311 pulse ADDR BIT TIME | Toggle Output-BIT for TIME (in ms) |- | max7311 set ADDR BIT VALUE | Set Output-BIT to VALUE (bool) |- | max7311 setDDRw ADDR VALUE | Set Direction-Register DDR (VALUE as hex) |- | max7311 setOUTw ADDR VALUE | Set Output-Register OUT (VALUE as hex) |- | pca9531 ADDR PERIODPWM1 DUTYPWM1 PERIODPWM2 DUTYPWM2 LED0..3 LED4..7 | set PWM1 and PWM2 and LED states |- | pca9685m ADDR | OUTDRV, IVRT, PRESCALE |- | pca9685s ADDR | LED, ON, OFF |- | pcf8574x read ADDR CHIP | Get bits |- | pcf8574x set ADDR CHIP HEXVALUE | Set bits |- | tsl2550 lux | Show light level by reading adc registers and computing level |- | tsl2550 mode VALUE | Set the TSL2550s operating mode (0: standard range, 1: extended range) |- | tsl2550 power VALUE | Set the TSL2550s power state (0: down, 1:up) |- |} == [[Jabber]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | jabber_host [HOSTNAME] | JABBER hostname |- | jabber_pass [PASSWORD] | JABBER password |- | jabber_resrc [RESOURCE] | JABBER resource |- | jabber_user [USERNAME] | JABBER username |- |} == [[KTY]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | kty autocalibrate CHANNEL | Calibrate to 1000 Ohm precision Resistor. |- | kty cal get | Return the calibration difference to 2k2 Resistor. |- | kty get [CHANNEL] | Get the temperature in xxx.x °C of CHANNEL or if no channel set of all channels. |- |} == [[MotorCurtain]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | curtain VALUE | Set value of curtain. 0=closed..7=open. If you use fewer sensors, use the corrent value instead of 7. |- | curtainlast | Return last known position |- | curtainmax | Return maximum position |- | curtainoff | Switch motor off |- |} == [[Named_PIN]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | pin get NAME | Read and display the status of pin NAME. |- | pin list | List all known named-pins. |- | pin set NAME STATUS | Set the status of pin NAME to STATUS. |- | pin toggle NAME | Toggle the status of pin NAME. |- |} == [[PWM]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dtmf CHARS | send CHARS as DTMF |- | freq set FREQUENCY DELAY | Set frequency for DELAY ms |- | pwm fade [channel +-diff startvalue] | Set fading at channel with startvalue and change each stepp to diff (must be signed 3 digit) |- | pwm set [channel value] | Set channel to value |- |} == [[RFM12]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | rfm12 reinit | Re-initialize RFM12 module. |- | rfm12 setbandwidth BW | Set RX bandwidth to BW. |- | rfm12 setbaud BAUD | Set baudrate to BAUD. |- | rfm12 setdrssi DRSSI | Set the drssi to DRSSI. |- | rfm12 setgain GAIN | Set preamplifier gain to GAIN. |- | rfm12 setmod MOD | Set modulation to MOD. |- | rfm12 status | Display internal status. |- |} == [[RFM12_ASK]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | rfm12 1527 | housecodeCommand delay cnt |- | rfm12 2272 | housecodeCommand delay cnt |- | rfm12 ask sense | Trigger (Tevion) ASK sensing. Enable ext. filter pin before! |- | rfm12 external filter [1] | Enable ext. filter pin if argument is present (disable otherwise) |- | rfm12 intertechno | family group device command |- | rfm12 tevion | housecode command delay cnt |- |} == [[SD-Karte]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sd dir | List contents of current SD directory. |- | sd mkdir PATH | Create directory hierarchy PATH. |- |} == [[SHT]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sht humid | Return humidity of SHT sensor |- | sht raw | Return raw hex temp (first line) and humidity value (second line) of SHT sensor |- | sht temp | Return temperature of SHT sensor |- |} == [[SMS77]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sms77 MESSAGE | Send MESSAGE to compiled in sms77 service |- | sms77_pass [PASSWORD] | SMS77 password |- | sms77_recv [RECEIVER] | SMS receiver |- | sms77_type [TYPE] | SMS type |- | sms77_user [USERNAME] | SMS77 username |- |} == [[Servo_Ansteuerung|PWM Servo Control]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | pwm servo_dec SERVONR | Decrement position of servo SERVONR |- | pwm servo_inc SERVONR | Increment position of servo SERVONR |- | pwm servo_set SERVONR POSITION | Set servo with SERVONR to POSITION |- |} == [[Sound]]/WAV support == {| border='1' | ''Command syntax'' | ''Short description'' |- | pwm stop | Stop wav |- | pwm wav <FILENAME> | Play wave file. Use VFS if compiled in. More details at [[Sound]] |- |} == [[Stella_Light]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | channel CHANNEL VALUE FUNCTION | Get/Set stella channel to value. Second and third parameters are optional. Function: You may use 's' for instant set, 'f' for fade and 'y' for flashy fade. |- | channels | Return stella channel size |- | fadestep FADESTEP | Get/Set stella fade step |- | stella load | Load values from eeprom |- | stella store | Store values in eeprom |- |} == [[USB]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | keyboard MESSAGE | Send MESSAGE as HID keyboard |- | mouse BUTTON DELTAX DELTAY | Send data as HID mouse |- |} == [[ZACwire]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | zac 306 PORT BIT | Return temperature of TSic 306 at BIT of PORT |- | zac 506 PORT BIT | Return temperature of TSic 506 at BIT of PORT |- | zac raw PORT BIT | Return raw hex temperature value of zacwire at BIT of PORT |- |} == lome6 == {| border='1' | ''Command syntax'' | ''Short description'' |- | lome6 get_t TYPE | get temperature command |- | lome6 power TYPE | press power command |- | lome6 reset | press reset command |- | lome6 set_t TYPE TEMPERATURE | set temperature command |- | lome6 state | get state command |- | lome6 uptime UPTIME | set/get uptime command |- |} == Miscelleanous == {| border='1' | ''Command syntax'' | ''Short description'' |- | alias list | List all available aliases |- | artnet test | artnet test |- | cw send MESSAGE | Send MESSAGE in Morce Code |- | d ADDR | Dump the memory at ADDR (16 bytes). |- | eeprom reinit | Force reinitialization of the EEPROM config area |- | free | Display free space. |- | help | List which commands are available. |- | ht MESSAGE | Send MESSAGE to compiled in httplog service |- | ipstats | Display IP statistics. |- | mb recv | Receive data from modbus |- | moodlight CHANNEL ONOFF | Set CHANNEL moodlight on=1 or off=0. If no channel is given return on if channel CHANNEL is moodlighted |- | motd [MESSAGE] | Save MESSAGE as new message of the day, otherwise just show current message |- | msr1 get | Get data |- | mysql query QUERY | Send specified MySQL query to the configured server |- | ns | update net statistic for public anouncment of currently running ethersex |- | pam USER PASSWORD | Use pam for user and password |- | push NUMBER | Push button identified by NUMBER |- | pwm melody [NUMBER] | Play melody |- | sanyoz700 CMD | Send command to projector |- | sll get | Request the logged data |- | sram memtest | Perform a memory test |- | srf05 | Read SRF05 measurement |- | to1 get | Request data from sensor |- | tw MESSAGE | Send MESSAGE to compiled in twitter service |- | upnp send | Manually send UPnP broadcast packet |- | usart baud BAUD | Set the USART baudrate to BAUD. |- | version | Display the version number. |- | wol MAC | Send WAKE-ON-LAN command to MAC |- | yport stats | Report statistic counters |- | zbus stats | Report statistic counters |- |} [[Category:Ethersex]] [[Category:ECMD]] ffc92840424a66b84338c5d7d84f91e94cda4567 361 350 2012-01-23T13:42:05Z LadySM 0 Importing text file wikitext text/x-wiki <div class="errorbox"> This page is automatically generated from the files in the Ethersex source code repository. Do not edit this page but send [[patches]] for those files! </div> __NOTOC__ == Analog/Digital Conversion ([[ADC]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | adc get [CHANNEL] | Get the ADC value in hex of CHANNEL or if no channel set of all channels. |- | hr20 temp | Read HR20 temperature sensor. |- |} == DNS Resolver == {| border='1' | ''Command syntax'' | ''Short description'' |- | dns server [IPADDR] | Display/Set the IP address of the DNS server to use to IPADDR. |- | nslookup HOSTNAME | Do DNS lookup for HOSTNAME (call twice). |- |} == Digital/Analog Conversion ([[DAC]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ltc1257_delay `[VALUE] | Set (if VALUE given) or get (no VALUE) delay for LTC1257 output bit changes in µs' |- | ltc1257_set `[VALUE0] [VALUE1] ... | Set output to value (value: 0-4095)' |- | tlc5620 `[CHANNEL] [VALUE] | Set Output to value (Value: 0-0xff)' |- |} == Fnordlicht == {| border='1' | ''Command syntax'' | ''Short description'' |- | fnordlicht "ADDRESS RED | GREEN,BLUE",fnordlicht command to set RGB color |- | fnordlicht_init | fnordlicht init |- |} == HD44780 [[LCD]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | hr20 hourbar START STOP | Update hourbar to show ticks between START and STOP (range 0..23) |- | hr20 toggle SEG | Toggle segment SEG (a number, not a symbolic name!) |- | lcd backlight STATE | switch back light STATE to ON or OFF |- | lcd char N D1 D2 D3 D4 D5 D6 D7 D8 | Define use-definable char N with data D1..D8 (provide DATA in hex) |- | lcd clear [LINE] | Clear line LINE (0..3) or the whole display (if parameter is omitted) |- | lcd goto LINE COL | Move cursor to LINE and column COL (origin is 0/0) |- | lcd reinit CURSOR BLINK | Reinitialize the display, set whether to show the cursor (CURSOR, 0 or 1) and whether the cursor shall BLINK |- | lcd shift DIR | Shift the display to DIR (either ''left'' or ''right'') |- | lcd write TEXT | Write TEXT to the current cursor location |- |} == Infrared Send/Receive ([[IR-TRX]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ir receive | receive an IR command |- | ir send DEVICE COMMAND | send COMMAND to DEVICE |- |} == Infrared Send/Receive ([[IRMP]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | irmp receive | receive an IR command |- | irmp send PROTOCOL DEVICE COMMAND REPEAT | send COMMAND with REPEAT flag to DEVICE using PROTOCOL |- |} == NTP Client == {| border='1' | ''Command syntax'' | ''Short description'' |- | ntp query | Query the NTP server to get an NTP update. |- | ntp server [IPADDR] | Display/Set the IP address of the NTP server to use to IPADDR. |- | ntp status | Display NTP server status |- |} == Network configuration == {| border='1' | ''Command syntax'' | ''Short description'' |- | enc dump | Dump the internal state of the enc to serial |- | gw [IP] | Display/Set the address of the default router. |- | ip [IP] | Display/Set the IP address. |- | mac [xx:xx:xx:xx:xx:xx] | Display/Set the MAC address. |- | netmask [IP] | Display/Set the network mask. |- |} == Port I/O == {| border='1' | ''Command syntax'' | ''Short description'' |- | io get ddr PORTNUM | Display the current value of the DDR PORTNUM. |- | io get mask PORTNUM | Display the mask of the port PORTNUM. |- | io get pin PORTNUM | Display the current value of the PIN-register of the port PORTNUM. |- | io get port NUM | Display the current value of the PORT NUM. |- | io set ddr PORTNUM HEXVALUE [MASK] | Set the DDR of port PORTNUM to VALUE (possibly using the provided MASK). |- | io set port NUM HEXVALUE [MASK] | Set the PORT NUM to VALUE (possibly using the provided MASK). |- |} == Reading and Writing EEPROM Space on Device == {| border='1' | ''Command syntax'' | ''Short description'' |- | eer eer <ADDR> <LENGTH> | Read n bytes from address after the config in eeprom. |- | eew eew <ADDR> <HEXBYTES> | Write Hexbytes at address after the config in epprom. |- | fuse | Display current fuse settings |- | hostname | Display hostname. |- |} == Resetting the controller == {| border='1' | ''Command syntax'' | ''Short description'' |- | bootloader | Call the bootloader. |- | reset | Reset the Ethersex. |- | wdreset | Go into endless loop to trigger a watchdog timeout. |- |} == [[ADS]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | ads get | Get the ADC value in hex. |- | ads mean [COUNT] | Get the mean of power of 2 COUNT ADC values in hex. |- |} == [[Am_Puls_der_Zeit|Clock]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | date | Display the current date. |- | lastdcf | Display when last valid DCF Signal was received. |- | time [UNIXTIME] | Display/Set the current time in seconds since January 1st 1970. |- | uptime | Display ethersex uptime in unix format. |- | whm | Display ethersex uptime. |- |} == [[Application_Sample]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sample | Manually call application sample commands |- | sample_init | Manually call application sample init method |- | sample_periodic | Manually call application sample periodic method |- |} == [[Blinkenlights_MCUF|MCUF]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | mcuf modul N | Select module N |- | mcuf modul list | List all modules |- | mcuf showclock | Show digital clock |- | mcuf showstring MESSAGE | Show scrolling MESSAGE on the display |- |} == [[CRC]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | crc calc | "read the ethersex program code and calc a crc16 of it" |- | crc read | "read out the crc16 value at the end of the program space" |- |} == [[CRON-Dienst]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | cron_add MIN HOUR DAY MONTH DOW ECMD | Add ECMD to cron to be executed at given time |- | cron_list | Show all cron entries |- | cron_make_persistent | Mark a Job as persistent |- | cron_rm POSITION | Remove one cron entry |- | cron_save | Saves all persistent jobs |- |} == [[DALI]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dali cmd [TARGET] [COMMAND] [!][?] | "send the given command (decimal) to targets (all, g00 to g15, s00 to s63), auto repeat with !, read reply with ?" |- | dali dim [TARGET] [LEVEL] | "dim targets (all, g00 to g15, s00 to s63) to given level (0-254)" |- | dali raw [BYTE1] [BYTE2] | "send a raw frame (two bytes, given in hex) over the DALI bus" |- | dali scmd [SPECIAL COMMAND] [DATA] [!][?] | "send special command (256-287) with data, auto repeat with !, read reply with ?" |- |} == [[DMX_FXSlot]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx fxslot devices | set the device settings |- | dmx fxslot effect | set the effect settings |- | dmx fxslot reset | reset all fxslots and clear saved ones in EEPROM |- | dmx fxslot restore | restore the settings from EEPROM |- | dmx fxslot save | save the current fxslots to EEPROM |- |} == [[DMX_Storage]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx channels | Get channels per universe |- | dmx get | Return channel value |- | dmx set | Set channel values |- | dmx universe | Get a whole universe |- | dmx universes | Get universes |- |} == [[Dallas_1-wire_Bus]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | 1w convert [DEVICE] | Trigger temperature conversion of either DEVICE or all connected devices |- | 1w ds2450 convert [DEVICE] | `start conversion (with optional input mask and read out control)' |- | 1w ds2450 get [DEVICE] | `get conversion result (one or all channels)' |- | 1w ds2450 oc [DEVICE] | `get/set output control (per channel)' |- | 1w ds2450 oe [DEVICE] | `get/set output enable (per channel)' |- | 1w ds2450 por [DEVICE] | `get/set power on reset (per channel)' |- | 1w ds2450 power [DEVICE] | `get/set power supply of device (global)' |- | 1w ds2450 range [DEVICE] | `get/set input voltage range (per channel)' |- | 1w ds2450 res [DEVICE] | `get/set bit resolution of AD convert (per channel)' |- | 1w get DEVICE | Return temperature value of onewire DEVICE (provide 64-bit ID as 16-hex-digits) |- | 1w list | Return a list of the connected onewire devices |- |} == [[DataFlash]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | df status | Display internal status. |- | fs format | Format the filesystem. |- | fs inspect inode INODE | Inspect INODE (and associated page). |- | fs inspect node NODE | Inspect NODE and dump to serial. |- | fs list | List the directory. |- | fs mkfile NAME | Create a new file NAME. |- | fs remove NAME | Delete the file NAME. |- | fs truncate NAME LEN | Truncate the file NAME to LEN bytes. |- |} == [[Dc3840_camera|DC3840 mobil camera support]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dc3840 capture | Take a picture. Access 'dc3840' via VFS afterwards. See [[DC3840 Camera]] for details. |- | dc3840 light | Light level of camera |- | dc3840 send A B C D E | Send provided command bytes to the camera. |- | dc3840 sync | Re-sync to the camera |- | dc3840 zoom | Enable zoom of camera |- |} == [[ECMDScript]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | call FILENAME | Start script named FILENAME |- | cat FILENAME | cat file content (with debug only) |- | dec VAR | Decrement variable VAR (a number) |- | echo <any> | Print out all arguments of echo |- | exit | Exit currently running script |- | get VAR | Get value of variable VAR |- | goto N | Goto line N in currently running script |- | if ( CMD/VAR == CONST ) then CMD2 | If condition matches execute CMD2 |- | inc VAR | Increment variable VAR (a number) |- | rem <any> | Remark for anything |- | set VAR VALUE | Set variable VAR to VALUE |- | wait I | Wait I milliseconds |- |} == [[FS20]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fht send HOUSECODE ADDR CMD [CMD2] | Send FHT command. See [[FS20]] for details. |- | fs20 receive | Receive FS20/FHT sequence and display it. |- | fs20 send HOUSECODE ADDR CMD [CMD2] | Send FS20 command. See [[FS20]] for details. |- | fs20 ws300 | Receive FS20 sequence from WS300 weather station and decode it. |- |} == [[Frequency Counter]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fc %duty [CHANNEL] | "returns last on duty cycle in percent for given channel" |- | fc duty [CHANNEL] | "returns last on duty cycle (0-255) for given channel" |- | fc freq [CHANNEL] | "returns last frequency in Hz for given channel" |- | fc off [CHANNEL] | "switch off frequency counting on given channel" |- | fc on [CHANNEL] | "switch on frequency counting on given channel" |- | fc ticks [CHANNEL] | "returns last frequency in CPU ticks for given channel" |- |} == [[GLCD_Menu]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | glcdmenu key VALUE | Send a keypress to the menu |- | glcdmenu update | Update the menu |- |} == [[GPS]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | nmea get | Get latitude and longitude data |- | nmea satellites | Get satellites |- |} == [[H-Bridge]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | hbridge [action] [enable_l] [enable_r] | Set H-Bridge command |- | hbridge pwm int | Set H-Bridge enable line valueeg. speed |- |} == [[I2C]] (TWI) == {| border='1' | ''Command syntax'' | ''Short description'' |- | bmp085 apress | Get absolute pressure in Pa |- | bmp085 height PRESSNN | Get height in cm, pressure at N0 needed |- | bmp085 pressnn HEIGHT | Get pressure at N0, height in cm needed |- | bmp085 temp | Get temperature in 0.1°C |- | ds1631 convert ADDR VALUE | Initiate temperature conversions (0: stop, 1: convert) |- | ds1631 temp ADDR | Read last converted temperature |- | i2c detect | list detected I2C Chips |- | i2c rbb ADDR | read byte from I2C chip |- | i2c rbd CHIPADDR REGADDR | read byte from register address at I2C chip |- | i2c rwd CHIPADDR REGADDR | read word from register address at I2C chip |- | i2c wbb ADDR HEXVALUE | write byte to I2C chip |- | i2c wbd CHIPADDR REGADDR HEXVALUE | write byte to register address on I2C chip |- | i2c wwd CHIPADDR REGADDR HEXVALUE | write word to register address on I2C chip |- | lm75 ADDR | Get temperature |- | max7311 getDDRw ADDR | Get Direction-Register DDR |- | max7311 getINw ADDR | Get Input-Register IN |- | max7311 getOUTw ADDR | Get Output-Register OUT |- | max7311 pulse ADDR BIT TIME | Toggle Output-BIT for TIME (in ms) |- | max7311 set ADDR BIT VALUE | Set Output-BIT to VALUE (bool) |- | max7311 setDDRw ADDR VALUE | Set Direction-Register DDR (VALUE as hex) |- | max7311 setOUTw ADDR VALUE | Set Output-Register OUT (VALUE as hex) |- | pca9531 ADDR PERIODPWM1 DUTYPWM1 PERIODPWM2 DUTYPWM2 LED0..3 LED4..7 | set PWM1 and PWM2 and LED states |- | pca9685m ADDR | OUTDRV, IVRT, PRESCALE |- | pca9685s ADDR | LED, ON, OFF |- | pcf8574x read ADDR CHIP | Get bits |- | pcf8574x set ADDR CHIP HEXVALUE | Set bits |- | tsl2550 lux | Show light level by reading adc registers and computing level |- | tsl2550 mode VALUE | Set the TSL2550s operating mode (0: standard range, 1: extended range) |- | tsl2550 power VALUE | Set the TSL2550s power state (0: down, 1:up) |- |} == [[Jabber]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | jabber_host [HOSTNAME] | JABBER hostname |- | jabber_pass [PASSWORD] | JABBER password |- | jabber_resrc [RESOURCE] | JABBER resource |- | jabber_user [USERNAME] | JABBER username |- |} == [[KTY]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | kty autocalibrate CHANNEL | Calibrate to 1000 Ohm precision Resistor. |- | kty cal get | Return the calibration difference to 2k2 Resistor. |- | kty get [CHANNEL] | Get the temperature in xxx.x °C of CHANNEL or if no channel set of all channels. |- |} == [[MotorCurtain]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | curtain VALUE | Set value of curtain. 0=closed..7=open. If you use fewer sensors, use the corrent value instead of 7. |- | curtainlast | Return last known position |- | curtainmax | Return maximum position |- | curtainoff | Switch motor off |- |} == [[Named_PIN]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | pin get NAME | Read and display the status of pin NAME. |- | pin list | List all known named-pins. |- | pin set NAME STATUS | Set the status of pin NAME to STATUS. |- | pin toggle NAME | Toggle the status of pin NAME. |- |} == [[PWM]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dtmf CHARS | send CHARS as DTMF |- | freq set FREQUENCY DELAY | Set frequency for DELAY ms |- | pwm fade [channel +-diff startvalue] | Set fading at channel with startvalue and change each stepp to diff (must be signed 3 digit) |- | pwm set [channel value] | Set channel to value |- |} == [[RFM12]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | rfm12 reinit | Re-initialize RFM12 module. |- | rfm12 setbandwidth BW | Set RX bandwidth to BW. |- | rfm12 setbaud BAUD | Set baudrate to BAUD. |- | rfm12 setdrssi DRSSI | Set the drssi to DRSSI. |- | rfm12 setgain GAIN | Set preamplifier gain to GAIN. |- | rfm12 setmod MOD | Set modulation to MOD. |- | rfm12 status | Display internal status. |- |} == [[RFM12_ASK]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | rfm12 1527 | housecodeCommand delay cnt |- | rfm12 2272 | housecodeCommand delay cnt |- | rfm12 ask sense | Trigger (Tevion) ASK sensing. Enable ext. filter pin before! |- | rfm12 external filter [1] | Enable ext. filter pin if argument is present (disable otherwise) |- | rfm12 intertechno | family group device command |- | rfm12 tevion | housecode command delay cnt |- |} == [[SD-Karte]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sd dir | List contents of current SD directory. |- | sd mkdir PATH | Create directory hierarchy PATH. |- |} == [[SHT]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sht humid | Return humidity of SHT sensor |- | sht raw | Return raw hex temp (first line) and humidity value (second line) of SHT sensor |- | sht temp | Return temperature of SHT sensor |- |} == [[SMS77]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sms77 MESSAGE | Send MESSAGE to compiled in sms77 service |- | sms77_pass [PASSWORD] | SMS77 password |- | sms77_recv [RECEIVER] | SMS receiver |- | sms77_type [TYPE] | SMS type |- | sms77_user [USERNAME] | SMS77 username |- |} == [[Servo_Ansteuerung|PWM Servo Control]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | pwm servo_dec SERVONR | Decrement position of servo SERVONR |- | pwm servo_inc SERVONR | Increment position of servo SERVONR |- | pwm servo_set SERVONR POSITION | Set servo with SERVONR to POSITION |- |} == [[Sound]]/WAV support == {| border='1' | ''Command syntax'' | ''Short description'' |- | pwm stop | Stop wav |- | pwm wav <FILENAME> | Play wave file. Use VFS if compiled in. More details at [[Sound]] |- |} == [[Stella_Light]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | channel CHANNEL VALUE FUNCTION | Get/Set stella channel to value. Second and third parameters are optional. Function: You may use 's' for instant set, 'f' for fade and 'y' for flashy fade. |- | channels | Return stella channel size |- | fadestep FADESTEP | Get/Set stella fade step |- | stella load | Load values from eeprom |- | stella store | Store values in eeprom |- |} == [[USB]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | keyboard MESSAGE | Send MESSAGE as HID keyboard |- | mouse BUTTON DELTAX DELTAY | Send data as HID mouse |- |} == [[ZACwire]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | zac 306 PORT BIT | Return temperature of TSic 306 at BIT of PORT |- | zac 506 PORT BIT | Return temperature of TSic 506 at BIT of PORT |- | zac raw PORT BIT | Return raw hex temperature value of zacwire at BIT of PORT |- |} == lome6 == {| border='1' | ''Command syntax'' | ''Short description'' |- | lome6 get_t TYPE | get temperature command |- | lome6 power TYPE | press power command |- | lome6 reset | press reset command |- | lome6 set_t TYPE TEMPERATURE | set temperature command |- | lome6 state | get state command |- | lome6 uptime UPTIME | set/get uptime command |- |} == Miscelleanous == {| border='1' | ''Command syntax'' | ''Short description'' |- | alias list | List all available aliases |- | artnet test | artnet test |- | cw send MESSAGE | Send MESSAGE in Morce Code |- | d ADDR | Dump the memory at ADDR (16 bytes). |- | eeprom reinit | Force reinitialization of the EEPROM config area |- | free | Display free space. |- | help | List which commands are available. |- | ht MESSAGE | Send MESSAGE to compiled in httplog service |- | ipstats | Display IP statistics. |- | mb recv | Receive data from modbus |- | moodlight CHANNEL ONOFF | Set CHANNEL moodlight on=1 or off=0. If no channel is given return on if channel CHANNEL is moodlighted |- | motd [MESSAGE] | Save MESSAGE as new message of the day, otherwise just show current message |- | msr1 get | Get data |- | mysql query QUERY | Send specified MySQL query to the configured server |- | ns | update net statistic for public anouncment of currently running ethersex |- | pam USER PASSWORD | Use pam for user and password |- | push NUMBER | Push button identified by NUMBER |- | pwm melody [NUMBER] | Play melody |- | sanyoz700 CMD | Send command to projector |- | sll get | Request the logged data |- | sram memtest | Perform a memory test |- | srf05 | Read SRF05 measurement |- | to1 get | Request data from sensor |- | tw MESSAGE | Send MESSAGE to compiled in twitter service |- | upnp send | Manually send UPnP broadcast packet |- | usart baud BAUD | Set the USART baudrate to BAUD. |- | version | Display the version number. |- | wol MAC | Send WAKE-ON-LAN command to MAC |- | yport stats | Report statistic counters |- | zbus stats | Report statistic counters |- |} [[Category:Ethersex]] [[Category:ECMD]] 429ffe8f2f61d8bdd458740e359997e303f24b92 362 361 2012-01-29T17:42:12Z LadySM 0 Importing text file wikitext text/x-wiki <div class="errorbox"> This page is automatically generated from the files in the Ethersex source code repository. Do not edit this page but send [[patches]] for those files! </div> __NOTOC__ == Analog/Digital Conversion ([[ADC]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | adc get [CHANNEL] | Get the ADC value in hex of CHANNEL or if no channel set of all channels. |- | hr20 temp | Read HR20 temperature sensor. |- |} == DNS Resolver == {| border='1' | ''Command syntax'' | ''Short description'' |- | dns server [IPADDR] | Display/Set the IP address of the DNS server to use to IPADDR. |- | nslookup HOSTNAME | Do DNS lookup for HOSTNAME (call twice). |- |} == Digital/Analog Conversion ([[DAC]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ltc1257_delay `[VALUE] | Set (if VALUE given) or get (no VALUE) delay for LTC1257 output bit changes in µs' |- | ltc1257_set `[VALUE0] [VALUE1] ... | Set output to value (value: 0-4095)' |- | tlc5620 `[CHANNEL] [VALUE] | Set Output to value (Value: 0-0xff)' |- |} == Fnordlicht == {| border='1' | ''Command syntax'' | ''Short description'' |- | fnordlicht "ADDRESS RED | GREEN,BLUE",fnordlicht command to set RGB color |- | fnordlicht_init | fnordlicht init |- |} == HD44780 [[LCD]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | hr20 hourbar START STOP | Update hourbar to show ticks between START and STOP (range 0..23) |- | hr20 toggle SEG | Toggle segment SEG (a number, not a symbolic name!) |- | lcd backlight STATE | switch back light STATE to ON or OFF |- | lcd char N D1 D2 D3 D4 D5 D6 D7 D8 | Define use-definable char N with data D1..D8 (provide DATA in hex) |- | lcd clear [LINE] | Clear line LINE (0..3) or the whole display (if parameter is omitted) |- | lcd goto LINE COL | Move cursor to LINE and column COL (origin is 0/0) |- | lcd reinit CURSOR BLINK | Reinitialize the display, set whether to show the cursor (CURSOR, 0 or 1) and whether the cursor shall BLINK |- | lcd shift DIR | Shift the display to DIR (either ''left'' or ''right'') |- | lcd write TEXT | Write TEXT to the current cursor location |- |} == Infrared Send/Receive ([[IR-TRX]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ir receive | receive an IR command |- | ir send DEVICE COMMAND | send COMMAND to DEVICE |- |} == Infrared Send/Receive ([[IRMP]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | irmp receive | receive an IR command |- | irmp send PROTOCOL DEVICE COMMAND REPEAT | send COMMAND with REPEAT flag to DEVICE using PROTOCOL |- |} == NTP Client == {| border='1' | ''Command syntax'' | ''Short description'' |- | ntp query | Query the NTP server to get an NTP update. |- | ntp server [IPADDR] | Display/Set the IP address of the NTP server to use to IPADDR. |- | ntp status | Display NTP server status |- |} == Network configuration == {| border='1' | ''Command syntax'' | ''Short description'' |- | enc dump | Dump the internal state of the enc to serial |- | gw [IP] | Display/Set the address of the default router. |- | ip [IP] | Display/Set the IP address. |- | mac [xx:xx:xx:xx:xx:xx] | Display/Set the MAC address. |- | netmask [IP] | Display/Set the network mask. |- |} == Port I/O == {| border='1' | ''Command syntax'' | ''Short description'' |- | io get ddr PORTNUM | Display the current value of the DDR PORTNUM. |- | io get mask PORTNUM | Display the mask of the port PORTNUM. |- | io get pin PORTNUM | Display the current value of the PIN-register of the port PORTNUM. |- | io get port NUM | Display the current value of the PORT NUM. |- | io set ddr PORTNUM HEXVALUE [MASK] | Set the DDR of port PORTNUM to VALUE (possibly using the provided MASK). |- | io set port NUM HEXVALUE [MASK] | Set the PORT NUM to VALUE (possibly using the provided MASK). |- |} == Reading and Writing EEPROM Space on Device == {| border='1' | ''Command syntax'' | ''Short description'' |- | eer eer <ADDR> <LENGTH> | Read n bytes from address after the config in eeprom. |- | eew eew <ADDR> <HEXBYTES> | Write Hexbytes at address after the config in epprom. |- | fuse | Display current fuse settings |- | hostname | Display hostname. |- |} == Resetting the controller == {| border='1' | ''Command syntax'' | ''Short description'' |- | bootloader | Call the bootloader. |- | reset | Reset the Ethersex. |- | wdreset | Go into endless loop to trigger a watchdog timeout. |- |} == [[ADS]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | ads get | Get the ADC value in hex. |- | ads mean [COUNT] | Get the mean of power of 2 COUNT ADC values in hex. |- |} == [[Am_Puls_der_Zeit|Clock]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | date | Display the current date. |- | lastdcf | Display when last valid DCF Signal was received. |- | time [UNIXTIME] | Display/Set the current time in seconds since January 1st 1970. |- | uptime | Display ethersex uptime in unix format. |- | whm | Display ethersex uptime. |- |} == [[Application_Sample]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sample | Manually call application sample commands |- | sample_init | Manually call application sample init method |- | sample_periodic | Manually call application sample periodic method |- |} == [[Blinkenlights_MCUF|MCUF]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | mcuf modul N | Select module N |- | mcuf modul list | List all modules |- | mcuf showclock | Show digital clock |- | mcuf showstring MESSAGE | Show scrolling MESSAGE on the display |- |} == [[CRC]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | crc calc | "read the ethersex program code and calc a crc16 of it" |- | crc read | "read out the crc16 value at the end of the program space" |- |} == [[CRON-Dienst]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | cron_add MIN HOUR DAY MONTH DOW ECMD | Add ECMD to cron to be executed at given time |- | cron_list | Show all cron entries |- | cron_make_persistent | Mark a Job as persistent |- | cron_rm POSITION | Remove one cron entry |- | cron_save | Saves all persistent jobs |- |} == [[DALI]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dali cmd [TARGET] [COMMAND] [!][?] | "send the given command (decimal) to targets (all, g00 to g15, s00 to s63), auto repeat with !, read reply with ?" |- | dali dim [TARGET] [LEVEL] | "dim targets (all, g00 to g15, s00 to s63) to given level (0-254)" |- | dali raw [BYTE1] [BYTE2] | "send a raw frame (two bytes, given in hex) over the DALI bus" |- | dali scmd [SPECIAL COMMAND] [DATA] [!][?] | "send special command (256-287) with data, auto repeat with !, read reply with ?" |- |} == [[DMX_FXSlot]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx fxslot devices | set the device settings |- | dmx fxslot effect | set the effect settings |- | dmx fxslot reset | reset all fxslots and clear saved ones in EEPROM |- | dmx fxslot restore | restore the settings from EEPROM |- | dmx fxslot save | save the current fxslots to EEPROM |- |} == [[DMX_Storage]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx channels | Get channels per universe |- | dmx get | Return channel value |- | dmx set | Set channel values |- | dmx universe | Get a whole universe |- | dmx universes | Get universes |- |} == [[Dallas_1-wire_Bus]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | 1w convert [DEVICE] | Trigger temperature conversion of either DEVICE or all connected devices |- | 1w ds2450 convert [DEVICE] | `start conversion (with optional input mask and read out control)' |- | 1w ds2450 get [DEVICE] | `get conversion result (one or all channels)' |- | 1w ds2450 oc [DEVICE] | `get/set output control (per channel)' |- | 1w ds2450 oe [DEVICE] | `get/set output enable (per channel)' |- | 1w ds2450 por [DEVICE] | `get/set power on reset (per channel)' |- | 1w ds2450 power [DEVICE] | `get/set power supply of device (global)' |- | 1w ds2450 range [DEVICE] | `get/set input voltage range (per channel)' |- | 1w ds2450 res [DEVICE] | `get/set bit resolution of AD convert (per channel)' |- | 1w get DEVICE | Return temperature value of onewire DEVICE (provide 64-bit ID as 16-hex-digits) |- | 1w list | Return a list of the connected onewire devices |- |} == [[DataFlash]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | df status | Display internal status. |- | fs format | Format the filesystem. |- | fs inspect inode INODE | Inspect INODE (and associated page). |- | fs inspect node NODE | Inspect NODE and dump to serial. |- | fs list | List the directory. |- | fs mkfile NAME | Create a new file NAME. |- | fs remove NAME | Delete the file NAME. |- | fs truncate NAME LEN | Truncate the file NAME to LEN bytes. |- |} == [[Dc3840_camera|DC3840 mobil camera support]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dc3840 capture | Take a picture. Access 'dc3840' via VFS afterwards. See [[DC3840 Camera]] for details. |- | dc3840 light | Light level of camera |- | dc3840 send A B C D E | Send provided command bytes to the camera. |- | dc3840 sync | Re-sync to the camera |- | dc3840 zoom | Enable zoom of camera |- |} == [[ECMDScript]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | call FILENAME | Start script named FILENAME |- | cat FILENAME | cat file content (with debug only) |- | dec VAR | Decrement variable VAR (a number) |- | echo <any> | Print out all arguments of echo |- | exit | Exit currently running script |- | get VAR | Get value of variable VAR |- | goto N | Goto line N in currently running script |- | if ( CMD/VAR == CONST ) then CMD2 | If condition matches execute CMD2 |- | inc VAR | Increment variable VAR (a number) |- | rem <any> | Remark for anything |- | set VAR VALUE | Set variable VAR to VALUE |- | wait I | Wait I milliseconds |- |} == [[FS20]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fht send HOUSECODE ADDR CMD [CMD2] | Send FHT command. See [[FS20]] for details. |- | fs20 receive | Receive FS20/FHT sequence and display it. |- | fs20 send HOUSECODE ADDR CMD [CMD2] | Send FS20 command. See [[FS20]] for details. |- | fs20 ws300 | Receive FS20 sequence from WS300 weather station and decode it. |- |} == [[Frequency Counter]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fc %duty [CHANNEL] | "returns last on duty cycle in percent for given channel" |- | fc duty [CHANNEL] | "returns last on duty cycle (0-255) for given channel" |- | fc freq [CHANNEL] | "returns last frequency in Hz for given channel" |- | fc off [CHANNEL] | "switch off frequency counting on given channel" |- | fc on [CHANNEL] | "switch on frequency counting on given channel" |- | fc ticks [CHANNEL] | "returns last frequency in CPU ticks for given channel" |- |} == [[GLCD_Menu]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | glcdmenu key VALUE | Send a keypress to the menu |- | glcdmenu update | Update the menu |- |} == [[GPS]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | nmea get | Get latitude and longitude data |- | nmea satellites | Get satellites |- |} == [[H-Bridge]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | hbridge [action] [enable_l] [enable_r] | Set H-Bridge command |- | hbridge pwm int | Set H-Bridge enable line valueeg. speed |- |} == [[I2C]] (TWI) == {| border='1' | ''Command syntax'' | ''Short description'' |- | bmp085 apress | Get absolute pressure in Pa |- | bmp085 height PRESSNN | Get height in cm, pressure at N0 needed |- | bmp085 pressnn HEIGHT | Get pressure at N0, height in cm needed |- | bmp085 temp | Get temperature in 0.1°C |- | ds1631 convert ADDR VALUE | Initiate temperature conversions (0: stop, 1: convert) |- | ds1631 temp ADDR | Read last converted temperature |- | i2c detect | list detected I2C Chips |- | i2c rbb ADDR | read byte from I2C chip |- | i2c rbd CHIPADDR REGADDR | read byte from register address at I2C chip |- | i2c rwd CHIPADDR REGADDR | read word from register address at I2C chip |- | i2c wbb ADDR HEXVALUE | write byte to I2C chip |- | i2c wbd CHIPADDR REGADDR HEXVALUE | write byte to register address on I2C chip |- | i2c wwd CHIPADDR REGADDR HEXVALUE | write word to register address on I2C chip |- | lm75 ADDR | Get temperature |- | max7311 getDDRw ADDR | Get Direction-Register DDR |- | max7311 getINw ADDR | Get Input-Register IN |- | max7311 getOUTw ADDR | Get Output-Register OUT |- | max7311 pulse ADDR BIT TIME | Toggle Output-BIT for TIME (in ms) |- | max7311 set ADDR BIT VALUE | Set Output-BIT to VALUE (bool) |- | max7311 setDDRw ADDR VALUE | Set Direction-Register DDR (VALUE as hex) |- | max7311 setOUTw ADDR VALUE | Set Output-Register OUT (VALUE as hex) |- | pca9531 ADDR PERIODPWM1 DUTYPWM1 PERIODPWM2 DUTYPWM2 LED0..3 LED4..7 | set PWM1 and PWM2 and LED states |- | pca9685m ADDR | OUTDRV, IVRT, PRESCALE |- | pca9685s ADDR | LED, ON, OFF |- | pcf8574x read ADDR CHIP | Get bits |- | pcf8574x set ADDR CHIP HEXVALUE | Set bits |- | tsl2550 lux | Show light level by reading adc registers and computing level |- | tsl2550 mode VALUE | Set the TSL2550s operating mode (0: standard range, 1: extended range) |- | tsl2550 power VALUE | Set the TSL2550s power state (0: down, 1:up) |- |} == [[Jabber]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | jabber_host [HOSTNAME] | JABBER hostname |- | jabber_pass [PASSWORD] | JABBER password |- | jabber_resrc [RESOURCE] | JABBER resource |- | jabber_user [USERNAME] | JABBER username |- |} == [[KTY]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | kty autocalibrate CHANNEL | Calibrate to 1000 Ohm precision Resistor. |- | kty cal get | Return the calibration difference to 2k2 Resistor. |- | kty get [CHANNEL] | Get the temperature in xxx.x °C of CHANNEL or if no channel set of all channels. |- |} == [[MotorCurtain]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | curtain VALUE | Set value of curtain. 0=closed..7=open. If you use fewer sensors, use the corrent value instead of 7. |- | curtainlast | Return last known position |- | curtainmax | Return maximum position |- | curtainoff | Switch motor off |- |} == [[Named_PIN]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | pin get NAME | Read and display the status of pin NAME. |- | pin list | List all known named-pins. |- | pin set NAME STATUS | Set the status of pin NAME to STATUS. |- | pin toggle NAME | Toggle the status of pin NAME. |- |} == [[PWM]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dtmf CHARS | send CHARS as DTMF |- | freq set FREQUENCY DELAY | Set frequency for DELAY ms |- | pwm fade [channel +-diff startvalue] | Set fading at channel with startvalue and change each stepp to diff (must be signed 3 digit) |- | pwm set [channel value] | Set channel to value |- |} == [[RFM12]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | rfm12 reinit | Re-initialize RFM12 module. |- | rfm12 setbandwidth BW | Set RX bandwidth to BW. |- | rfm12 setbaud BAUD | Set baudrate to BAUD. |- | rfm12 setdrssi DRSSI | Set the drssi to DRSSI. |- | rfm12 setgain GAIN | Set preamplifier gain to GAIN. |- | rfm12 setmod MOD | Set modulation to MOD. |- | rfm12 status | Display internal status. |- |} == [[RFM12_ASK]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | rfm12 1527 | housecodeCommand delay cnt |- | rfm12 2272 | housecodeCommand delay cnt |- | rfm12 ask sense | Trigger (Tevion) ASK sensing. Enable ext. filter pin before! |- | rfm12 external filter [1] | Enable ext. filter pin if argument is present (disable otherwise) |- | rfm12 intertechno | family group device command |- | rfm12 tevion | housecode command delay cnt |- |} == [[RFM12_FS20]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fht send | housecode addr command data |- | fs20 send | housecode addr command data |- |} == [[SD-Karte]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sd dir | List contents of current SD directory. |- | sd mkdir PATH | Create directory hierarchy PATH. |- |} == [[SHT]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sht humid | Return humidity of SHT sensor |- | sht raw | Return raw hex temp (first line) and humidity value (second line) of SHT sensor |- | sht temp | Return temperature of SHT sensor |- |} == [[SMS77]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sms77 MESSAGE | Send MESSAGE to compiled in sms77 service |- | sms77_pass [PASSWORD] | SMS77 password |- | sms77_recv [RECEIVER] | SMS receiver |- | sms77_type [TYPE] | SMS type |- | sms77_user [USERNAME] | SMS77 username |- |} == [[Servo_Ansteuerung|PWM Servo Control]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | pwm servo_dec SERVONR | Decrement position of servo SERVONR |- | pwm servo_inc SERVONR | Increment position of servo SERVONR |- | pwm servo_set SERVONR POSITION | Set servo with SERVONR to POSITION |- |} == [[Sound]]/WAV support == {| border='1' | ''Command syntax'' | ''Short description'' |- | pwm stop | Stop wav |- | pwm wav <FILENAME> | Play wave file. Use VFS if compiled in. More details at [[Sound]] |- |} == [[Stella_Light]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | channel CHANNEL VALUE FUNCTION | Get/Set stella channel to value. Second and third parameters are optional. Function: You may use 's' for instant set, 'f' for fade and 'y' for flashy fade. |- | channels | Return stella channel size |- | fadestep FADESTEP | Get/Set stella fade step |- | stella load | Load values from eeprom |- | stella store | Store values in eeprom |- |} == [[USB]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | keyboard MESSAGE | Send MESSAGE as HID keyboard |- | mouse BUTTON DELTAX DELTAY | Send data as HID mouse |- |} == [[ZACwire]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | zac 306 PORT BIT | Return temperature of TSic 306 at BIT of PORT |- | zac 506 PORT BIT | Return temperature of TSic 506 at BIT of PORT |- | zac raw PORT BIT | Return raw hex temperature value of zacwire at BIT of PORT |- |} == lome6 == {| border='1' | ''Command syntax'' | ''Short description'' |- | lome6 get_t TYPE | get temperature command |- | lome6 power TYPE | press power command |- | lome6 reset | press reset command |- | lome6 set_t TYPE TEMPERATURE | set temperature command |- | lome6 state | get state command |- | lome6 uptime UPTIME | set/get uptime command |- |} == Miscelleanous == {| border='1' | ''Command syntax'' | ''Short description'' |- | alias list | List all available aliases |- | artnet test | artnet test |- | cw send MESSAGE | Send MESSAGE in Morce Code |- | d ADDR | Dump the memory at ADDR (16 bytes). |- | eeprom reinit | Force reinitialization of the EEPROM config area |- | free | Display free space. |- | help | List which commands are available. |- | ht MESSAGE | Send MESSAGE to compiled in httplog service |- | ipstats | Display IP statistics. |- | mb recv | Receive data from modbus |- | moodlight CHANNEL ONOFF | Set CHANNEL moodlight on=1 or off=0. If no channel is given return on if channel CHANNEL is moodlighted |- | motd [MESSAGE] | Save MESSAGE as new message of the day, otherwise just show current message |- | msr1 get | Get data |- | mysql query QUERY | Send specified MySQL query to the configured server |- | ns | update net statistic for public anouncment of currently running ethersex |- | pam USER PASSWORD | Use pam for user and password |- | push NUMBER | Push button identified by NUMBER |- | pwm melody [NUMBER] | Play melody |- | sanyoz700 CMD | Send command to projector |- | sll get | Request the logged data |- | sram memtest | Perform a memory test |- | srf05 | Read SRF05 measurement |- | to1 get | Request data from sensor |- | tw MESSAGE | Send MESSAGE to compiled in twitter service |- | upnp send | Manually send UPnP broadcast packet |- | usart baud BAUD | Set the USART baudrate to BAUD. |- | version | Display the version number. |- | wol MAC | Send WAKE-ON-LAN command to MAC |- | yport stats | Report statistic counters |- | zbus stats | Report statistic counters |- |} [[Category:Ethersex]] [[Category:ECMD]] 45f415b28622d1c96a004ad426126a557c535654 363 362 2012-01-31T19:42:07Z LadySM 0 Importing text file wikitext text/x-wiki <div class="errorbox"> This page is automatically generated from the files in the Ethersex source code repository. Do not edit this page but send [[patches]] for those files! </div> __NOTOC__ == Analog/Digital Conversion ([[ADC]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | adc get [CHANNEL] | Get the ADC value in hex of CHANNEL or if no channel set of all channels. |- | hr20 temp | Read HR20 temperature sensor. |- |} == DNS Resolver == {| border='1' | ''Command syntax'' | ''Short description'' |- | dns server [IPADDR] | Display/Set the IP address of the DNS server to use to IPADDR. |- | nslookup HOSTNAME | Do DNS lookup for HOSTNAME (call twice). |- |} == Digital/Analog Conversion ([[DAC]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ltc1257_delay `[VALUE] | Set (if VALUE given) or get (no VALUE) delay for LTC1257 output bit changes in µs' |- | ltc1257_set `[VALUE0] [VALUE1] ... | Set output to value (value: 0-4095)' |- | tlc5620 `[CHANNEL] [VALUE] | Set Output to value (Value: 0-0xff)' |- |} == Fnordlicht == {| border='1' | ''Command syntax'' | ''Short description'' |- | fnordlicht "ADDRESS RED | GREEN,BLUE",fnordlicht command to set RGB color |- | fnordlicht_init | fnordlicht init |- |} == HD44780 [[LCD]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | hr20 hourbar START STOP | Update hourbar to show ticks between START and STOP (range 0..23) |- | hr20 toggle SEG | Toggle segment SEG (a number, not a symbolic name!) |- | lcd backlight STATE | switch back light STATE to ON or OFF |- | lcd char N D1 D2 D3 D4 D5 D6 D7 D8 | Define use-definable char N with data D1..D8 (provide DATA in hex) |- | lcd clear [LINE] | Clear line LINE (0..3) or the whole display (if parameter is omitted) |- | lcd goto LINE COL | Move cursor to LINE and column COL (origin is 0/0) |- | lcd reinit CURSOR BLINK | Reinitialize the display, set whether to show the cursor (CURSOR, 0 or 1) and whether the cursor shall BLINK |- | lcd shift DIR | Shift the display to DIR (either ''left'' or ''right'') |- | lcd write TEXT | Write TEXT to the current cursor location |- |} == Infrared Send/Receive ([[IR-TRX]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ir receive | receive an IR command |- | ir send DEVICE COMMAND | send COMMAND to DEVICE |- |} == Infrared Send/Receive ([[IRMP]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | irmp receive | receive an IR command |- | irmp send PROTOCOL DEVICE COMMAND REPEAT | send COMMAND with REPEAT flag to DEVICE using PROTOCOL |- |} == NTP Client == {| border='1' | ''Command syntax'' | ''Short description'' |- | ntp query | Query the NTP server to get an NTP update. |- | ntp server [IPADDR] | Display/Set the IP address of the NTP server to use to IPADDR. |- | ntp status | Display NTP server status |- |} == Network configuration == {| border='1' | ''Command syntax'' | ''Short description'' |- | enc dump | Dump the internal state of the enc to serial |- | gw [IP] | Display/Set the address of the default router. |- | ip [IP] | Display/Set the IP address. |- | mac [xx:xx:xx:xx:xx:xx] | Display/Set the MAC address. |- | netmask [IP] | Display/Set the network mask. |- |} == Port I/O == {| border='1' | ''Command syntax'' | ''Short description'' |- | io get ddr PORTNUM | Display the current value of the DDR PORTNUM. |- | io get mask PORTNUM | Display the mask of the port PORTNUM. |- | io get pin PORTNUM | Display the current value of the PIN-register of the port PORTNUM. |- | io get port NUM | Display the current value of the PORT NUM. |- | io set ddr PORTNUM HEXVALUE [MASK] | Set the DDR of port PORTNUM to VALUE (possibly using the provided MASK). |- | io set port NUM HEXVALUE [MASK] | Set the PORT NUM to VALUE (possibly using the provided MASK). |- |} == Reading and Writing EEPROM Space on Device == {| border='1' | ''Command syntax'' | ''Short description'' |- | eer eer <ADDR> <LENGTH> | Read n bytes from address after the config in eeprom. |- | eew eew <ADDR> <HEXBYTES> | Write Hexbytes at address after the config in epprom. |- | fuse | Display current fuse settings |- | hostname | Display hostname. |- |} == Resetting the controller == {| border='1' | ''Command syntax'' | ''Short description'' |- | bootloader | Call the bootloader. |- | reset | Reset the Ethersex. |- | wdreset | Go into endless loop to trigger a watchdog timeout. |- |} == [[ADS]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | ads get | Get the ADC value in hex. |- | ads mean [COUNT] | Get the mean of power of 2 COUNT ADC values in hex. |- |} == [[Am_Puls_der_Zeit|Clock]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | date | Print the current date. |- | lastdcf | Print when last valid DCF signal was received. |- | time [UNIXTIME] | Display/Set the current time in seconds since January 1st 1970. |- | timezone [[-]HH:MM [[-]HH:MM [m.w.d/h [m.w.d/h]]]] | Print or set the current timezone. |- | uptime | Display ethersex uptime in unix format. |- | whm | Display ethersex uptime. |- |} == [[Application_Sample]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sample | Manually call application sample commands |- | sample_init | Manually call application sample init method |- | sample_periodic | Manually call application sample periodic method |- |} == [[Blinkenlights_MCUF|MCUF]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | mcuf modul N | Select module N |- | mcuf modul list | List all modules |- | mcuf showclock | Show digital clock |- | mcuf showstring MESSAGE | Show scrolling MESSAGE on the display |- |} == [[CRC]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | crc calc | "read the ethersex program code and calc a crc16 of it" |- | crc read | "read out the crc16 value at the end of the program space" |- |} == [[CRON-Dienst]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | cron_add MIN HOUR DAY MONTH DOW ECMD | Add ECMD to cron to be executed at given time |- | cron_list | Show all cron entries |- | cron_make_persistent | Mark a Job as persistent |- | cron_rm POSITION | Remove one cron entry |- | cron_save | Saves all persistent jobs |- |} == [[DALI]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dali cmd [TARGET] [COMMAND] [!][?] | "send the given command (decimal) to targets (all, g00 to g15, s00 to s63), auto repeat with !, read reply with ?" |- | dali dim [TARGET] [LEVEL] | "dim targets (all, g00 to g15, s00 to s63) to given level (0-254)" |- | dali raw [BYTE1] [BYTE2] | "send a raw frame (two bytes, given in hex) over the DALI bus" |- | dali scmd [SPECIAL COMMAND] [DATA] [!][?] | "send special command (256-287) with data, auto repeat with !, read reply with ?" |- |} == [[DMX_FXSlot]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx fxslot devices | set the device settings |- | dmx fxslot effect | set the effect settings |- | dmx fxslot reset | reset all fxslots and clear saved ones in EEPROM |- | dmx fxslot restore | restore the settings from EEPROM |- | dmx fxslot save | save the current fxslots to EEPROM |- |} == [[DMX_Storage]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx channels | Get channels per universe |- | dmx get | Return channel value |- | dmx set | Set channel values |- | dmx universe | Get a whole universe |- | dmx universes | Get universes |- |} == [[Dallas_1-wire_Bus]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | 1w convert [DEVICE] | Trigger temperature conversion of either DEVICE or all connected devices |- | 1w ds2450 convert [DEVICE] | `start conversion (with optional input mask and read out control)' |- | 1w ds2450 get [DEVICE] | `get conversion result (one or all channels)' |- | 1w ds2450 oc [DEVICE] | `get/set output control (per channel)' |- | 1w ds2450 oe [DEVICE] | `get/set output enable (per channel)' |- | 1w ds2450 por [DEVICE] | `get/set power on reset (per channel)' |- | 1w ds2450 power [DEVICE] | `get/set power supply of device (global)' |- | 1w ds2450 range [DEVICE] | `get/set input voltage range (per channel)' |- | 1w ds2450 res [DEVICE] | `get/set bit resolution of AD convert (per channel)' |- | 1w get DEVICE | Return temperature value of onewire DEVICE (provide 64-bit ID as 16-hex-digits) |- | 1w list | Return a list of the connected onewire devices |- |} == [[DataFlash]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | df status | Display internal status. |- | fs format | Format the filesystem. |- | fs inspect inode INODE | Inspect INODE (and associated page). |- | fs inspect node NODE | Inspect NODE and dump to serial. |- | fs list | List the directory. |- | fs mkfile NAME | Create a new file NAME. |- | fs remove NAME | Delete the file NAME. |- | fs truncate NAME LEN | Truncate the file NAME to LEN bytes. |- |} == [[Dc3840_camera|DC3840 mobil camera support]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dc3840 capture | Take a picture. Access 'dc3840' via VFS afterwards. See [[DC3840 Camera]] for details. |- | dc3840 light | Light level of camera |- | dc3840 send A B C D E | Send provided command bytes to the camera. |- | dc3840 sync | Re-sync to the camera |- | dc3840 zoom | Enable zoom of camera |- |} == [[ECMDScript]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | call FILENAME | Start script named FILENAME |- | cat FILENAME | cat file content (with debug only) |- | dec VAR | Decrement variable VAR (a number) |- | echo <any> | Print out all arguments of echo |- | exit | Exit currently running script |- | get VAR | Get value of variable VAR |- | goto N | Goto line N in currently running script |- | if ( CMD/VAR == CONST ) then CMD2 | If condition matches execute CMD2 |- | inc VAR | Increment variable VAR (a number) |- | rem <any> | Remark for anything |- | set VAR VALUE | Set variable VAR to VALUE |- | wait I | Wait I milliseconds |- |} == [[FS20]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fht send HOUSECODE ADDR CMD [CMD2] | Send FHT command. See [[FS20]] for details. |- | fs20 receive | Receive FS20/FHT sequence and display it. |- | fs20 send HOUSECODE ADDR CMD [CMD2] | Send FS20 command. See [[FS20]] for details. |- | fs20 ws300 | Receive FS20 sequence from WS300 weather station and decode it. |- |} == [[Frequency Counter]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fc %duty [CHANNEL] | "returns last on duty cycle in percent for given channel" |- | fc duty [CHANNEL] | "returns last on duty cycle (0-255) for given channel" |- | fc freq [CHANNEL] | "returns last frequency in Hz for given channel" |- | fc off [CHANNEL] | "switch off frequency counting on given channel" |- | fc on [CHANNEL] | "switch on frequency counting on given channel" |- | fc ticks [CHANNEL] | "returns last frequency in CPU ticks for given channel" |- |} == [[GLCD_Menu]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | glcdmenu key VALUE | Send a keypress to the menu |- | glcdmenu update | Update the menu |- |} == [[GPS]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | nmea get | Get latitude and longitude data |- | nmea satellites | Get satellites |- |} == [[H-Bridge]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | hbridge [action] [enable_l] [enable_r] | Set H-Bridge command |- | hbridge pwm int | Set H-Bridge enable line valueeg. speed |- |} == [[I2C]] (TWI) == {| border='1' | ''Command syntax'' | ''Short description'' |- | bmp085 apress | Get absolute pressure in Pa |- | bmp085 height PRESSNN | Get height in cm, pressure at N0 needed |- | bmp085 pressnn HEIGHT | Get pressure at N0, height in cm needed |- | bmp085 temp | Get temperature in 0.1°C |- | ds1631 convert ADDR VALUE | Initiate temperature conversions (0: stop, 1: convert) |- | ds1631 temp ADDR | Read last converted temperature |- | i2c detect | list detected I2C Chips |- | i2c rbb ADDR | read byte from I2C chip |- | i2c rbd CHIPADDR REGADDR | read byte from register address at I2C chip |- | i2c rwd CHIPADDR REGADDR | read word from register address at I2C chip |- | i2c wbb ADDR HEXVALUE | write byte to I2C chip |- | i2c wbd CHIPADDR REGADDR HEXVALUE | write byte to register address on I2C chip |- | i2c wwd CHIPADDR REGADDR HEXVALUE | write word to register address on I2C chip |- | lm75 ADDR | Get temperature |- | max7311 getDDRw ADDR | Get Direction-Register DDR |- | max7311 getINw ADDR | Get Input-Register IN |- | max7311 getOUTw ADDR | Get Output-Register OUT |- | max7311 pulse ADDR BIT TIME | Toggle Output-BIT for TIME (in ms) |- | max7311 set ADDR BIT VALUE | Set Output-BIT to VALUE (bool) |- | max7311 setDDRw ADDR VALUE | Set Direction-Register DDR (VALUE as hex) |- | max7311 setOUTw ADDR VALUE | Set Output-Register OUT (VALUE as hex) |- | pca9531 ADDR PERIODPWM1 DUTYPWM1 PERIODPWM2 DUTYPWM2 LED0..3 LED4..7 | set PWM1 and PWM2 and LED states |- | pca9685m ADDR | OUTDRV, IVRT, PRESCALE |- | pca9685s ADDR | LED, ON, OFF |- | pcf8574x read ADDR CHIP | Get bits |- | pcf8574x set ADDR CHIP HEXVALUE | Set bits |- | tsl2550 lux | Show light level by reading adc registers and computing level |- | tsl2550 mode VALUE | Set the TSL2550s operating mode (0: standard range, 1: extended range) |- | tsl2550 power VALUE | Set the TSL2550s power state (0: down, 1:up) |- |} == [[Jabber]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | jabber_host [HOSTNAME] | JABBER hostname |- | jabber_pass [PASSWORD] | JABBER password |- | jabber_resrc [RESOURCE] | JABBER resource |- | jabber_user [USERNAME] | JABBER username |- |} == [[KTY]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | kty autocalibrate CHANNEL | Calibrate to 1000 Ohm precision Resistor. |- | kty cal get | Return the calibration difference to 2k2 Resistor. |- | kty get [CHANNEL] | Get the temperature in xxx.x °C of CHANNEL or if no channel set of all channels. |- |} == [[MotorCurtain]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | curtain VALUE | Set value of curtain. 0=closed..7=open. If you use fewer sensors, use the corrent value instead of 7. |- | curtainlast | Return last known position |- | curtainmax | Return maximum position |- | curtainoff | Switch motor off |- |} == [[Named_PIN]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | pin get NAME | Read and display the status of pin NAME. |- | pin list | List all known named-pins. |- | pin set NAME STATUS | Set the status of pin NAME to STATUS. |- | pin toggle NAME | Toggle the status of pin NAME. |- |} == [[PWM]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dtmf CHARS | send CHARS as DTMF |- | freq set FREQUENCY DELAY | Set frequency for DELAY ms |- | pwm fade [channel +-diff startvalue] | Set fading at channel with startvalue and change each stepp to diff (must be signed 3 digit) |- | pwm set [channel value] | Set channel to value |- |} == [[RFM12]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | rfm12 reinit | Re-initialize RFM12 module. |- | rfm12 setbandwidth BW | Set RX bandwidth to BW. |- | rfm12 setbaud BAUD | Set baudrate to BAUD. |- | rfm12 setdrssi DRSSI | Set the drssi to DRSSI. |- | rfm12 setgain GAIN | Set preamplifier gain to GAIN. |- | rfm12 setmod MOD | Set modulation to MOD. |- | rfm12 status | Display internal status. |- |} == [[RFM12_ASK]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | rfm12 1527 | housecodeCommand delay cnt |- | rfm12 2272 | housecodeCommand delay cnt |- | rfm12 ask sense | Trigger (Tevion) ASK sensing. Enable ext. filter pin before! |- | rfm12 external filter [1] | Enable ext. filter pin if argument is present (disable otherwise) |- | rfm12 intertechno | family group device command |- | rfm12 tevion | housecode command delay cnt |- |} == [[RFM12_FS20]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fht send | housecode addr command data |- | fs20 send | housecode addr command data |- |} == [[SD-Karte]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sd dir | List contents of current SD directory. |- | sd mkdir PATH | Create directory hierarchy PATH. |- |} == [[SHT]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sht humid | Return humidity of SHT sensor |- | sht raw | Return raw hex temp (first line) and humidity value (second line) of SHT sensor |- | sht temp | Return temperature of SHT sensor |- |} == [[SMS77]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sms77 MESSAGE | Send MESSAGE to compiled in sms77 service |- | sms77_pass [PASSWORD] | SMS77 password |- | sms77_recv [RECEIVER] | SMS receiver |- | sms77_type [TYPE] | SMS type |- | sms77_user [USERNAME] | SMS77 username |- |} == [[Servo_Ansteuerung|PWM Servo Control]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | pwm servo_dec SERVONR | Decrement position of servo SERVONR |- | pwm servo_inc SERVONR | Increment position of servo SERVONR |- | pwm servo_set SERVONR POSITION | Set servo with SERVONR to POSITION |- |} == [[Sound]]/WAV support == {| border='1' | ''Command syntax'' | ''Short description'' |- | pwm stop | Stop wav |- | pwm wav <FILENAME> | Play wave file. Use VFS if compiled in. More details at [[Sound]] |- |} == [[Stella_Light]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | channel CHANNEL VALUE FUNCTION | Get/Set stella channel to value. Second and third parameters are optional. Function: You may use 's' for instant set, 'f' for fade and 'y' for flashy fade. |- | channels | Return stella channel size |- | fadestep FADESTEP | Get/Set stella fade step |- | stella load | Load values from eeprom |- | stella store | Store values in eeprom |- |} == [[USB]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | keyboard MESSAGE | Send MESSAGE as HID keyboard |- | mouse BUTTON DELTAX DELTAY | Send data as HID mouse |- |} == [[ZACwire]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | zac 306 PORT BIT | Return temperature of TSic 306 at BIT of PORT |- | zac 506 PORT BIT | Return temperature of TSic 506 at BIT of PORT |- | zac raw PORT BIT | Return raw hex temperature value of zacwire at BIT of PORT |- |} == lome6 == {| border='1' | ''Command syntax'' | ''Short description'' |- | lome6 get_t TYPE | get temperature command |- | lome6 power TYPE | press power command |- | lome6 reset | press reset command |- | lome6 set_t TYPE TEMPERATURE | set temperature command |- | lome6 state | get state command |- | lome6 uptime UPTIME | set/get uptime command |- |} == Miscelleanous == {| border='1' | ''Command syntax'' | ''Short description'' |- | alias list | List all available aliases |- | artnet test | artnet test |- | cw send MESSAGE | Send MESSAGE in Morce Code |- | d ADDR | Dump the memory at ADDR (16 bytes). |- | eeprom reinit | Force reinitialization of the EEPROM config area |- | free | Display free space. |- | help | List which commands are available. |- | ht MESSAGE | Send MESSAGE to compiled in httplog service |- | ipstats | Display IP statistics. |- | mb recv | Receive data from modbus |- | moodlight CHANNEL ONOFF | Set CHANNEL moodlight on=1 or off=0. If no channel is given return on if channel CHANNEL is moodlighted |- | motd [MESSAGE] | Save MESSAGE as new message of the day, otherwise just show current message |- | msr1 get | Get data |- | mysql query QUERY | Send specified MySQL query to the configured server |- | ns | update net statistic for public anouncment of currently running ethersex |- | pam USER PASSWORD | Use pam for user and password |- | push NUMBER | Push button identified by NUMBER |- | pwm melody [NUMBER] | Play melody |- | sanyoz700 CMD | Send command to projector |- | sll get | Request the logged data |- | sram memtest | Perform a memory test |- | srf05 | Read SRF05 measurement |- | to1 get | Request data from sensor |- | tw MESSAGE | Send MESSAGE to compiled in twitter service |- | upnp send | Manually send UPnP broadcast packet |- | usart baud BAUD | Set the USART baudrate to BAUD. |- | version | Display the version number. |- | wol MAC | Send WAKE-ON-LAN command to MAC |- | yport stats | Report statistic counters |- | zbus stats | Report statistic counters |- |} [[Category:Ethersex]] [[Category:ECMD]] a5b23ed34490c38e4574dd0440049d9a1057691f 366 363 2012-02-01T18:42:05Z LadySM 0 Importing text file wikitext text/x-wiki <div class="errorbox"> This page is automatically generated from the files in the Ethersex source code repository. Do not edit this page but send [[patches]] for those files! </div> __NOTOC__ == Analog/Digital Conversion ([[ADC]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | adc get [CHANNEL] | Get the ADC value in hex of CHANNEL or if no channel set of all channels. |- | hr20 temp | Read HR20 temperature sensor. |- |} == DNS Resolver == {| border='1' | ''Command syntax'' | ''Short description'' |- | dns server [IPADDR] | Display/Set the IP address of the DNS server to use to IPADDR. |- | nslookup HOSTNAME | Do DNS lookup for HOSTNAME (call twice). |- |} == Digital/Analog Conversion ([[DAC]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ltc1257_delay `[VALUE] | Set (if VALUE given) or get (no VALUE) delay for LTC1257 output bit changes in µs' |- | ltc1257_set `[VALUE0] [VALUE1] ... | Set output to value (value: 0-4095)' |- | tlc5620 `[CHANNEL] [VALUE] | Set Output to value (Value: 0-0xff)' |- |} == Fnordlicht == {| border='1' | ''Command syntax'' | ''Short description'' |- | fnordlicht "ADDRESS RED | GREEN,BLUE",fnordlicht command to set RGB color |- | fnordlicht_init | fnordlicht init |- |} == HD44780 [[LCD]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | hr20 hourbar START STOP | Update hourbar to show ticks between START and STOP (range 0..23) |- | hr20 toggle SEG | Toggle segment SEG (a number, not a symbolic name!) |- | lcd backlight STATE | switch back light STATE to ON or OFF |- | lcd char N D1 D2 D3 D4 D5 D6 D7 D8 | Define use-definable char N with data D1..D8 (provide DATA in hex) |- | lcd clear [LINE] | Clear line LINE (0..3) or the whole display (if parameter is omitted) |- | lcd goto LINE COL | Move cursor to LINE and column COL (origin is 0/0) |- | lcd reinit CURSOR BLINK | Reinitialize the display, set whether to show the cursor (CURSOR, 0 or 1) and whether the cursor shall BLINK |- | lcd shift DIR | Shift the display to DIR (either ''left'' or ''right'') |- | lcd write TEXT | Write TEXT to the current cursor location |- |} == Infrared Send/Receive ([[IR-TRX]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ir receive | receive an IR command |- | ir send DEVICE COMMAND | send COMMAND to DEVICE |- |} == Infrared Send/Receive ([[IRMP]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | irmp receive | receive an IR command |- | irmp send PROTOCOL DEVICE COMMAND REPEAT | send COMMAND with REPEAT flag to DEVICE using PROTOCOL |- |} == NTP Client == {| border='1' | ''Command syntax'' | ''Short description'' |- | ntp query | Query the NTP server to get an NTP update. |- | ntp server [IPADDR] | Display/Set the IP address of the NTP server to use to IPADDR. |- | ntp status | Display NTP server status |- |} == Network configuration == {| border='1' | ''Command syntax'' | ''Short description'' |- | enc dump | Dump the internal state of the enc to serial |- | gw [IP] | Display/Set the address of the default router. |- | ip [IP] | Display/Set the IP address. |- | mac [xx:xx:xx:xx:xx:xx] | Display/Set the MAC address. |- | netmask [IP] | Display/Set the network mask. |- |} == Port I/O == {| border='1' | ''Command syntax'' | ''Short description'' |- | io get ddr PORTNUM | Display the current value of the DDR PORTNUM. |- | io get mask PORTNUM | Display the mask of the port PORTNUM. |- | io get pin PORTNUM | Display the current value of the PIN-register of the port PORTNUM. |- | io get port NUM | Display the current value of the PORT NUM. |- | io set ddr PORTNUM HEXVALUE [MASK] | Set the DDR of port PORTNUM to VALUE (possibly using the provided MASK). |- | io set port NUM HEXVALUE [MASK] | Set the PORT NUM to VALUE (possibly using the provided MASK). |- |} == Reading and Writing EEPROM Space on Device == {| border='1' | ''Command syntax'' | ''Short description'' |- | eer eer <ADDR> <LENGTH> | Read n bytes from address after the config in eeprom. |- | eew eew <ADDR> <HEXBYTES> | Write Hexbytes at address after the config in epprom. |- | fuse | Display current fuse settings |- | hostname | Display hostname. |- |} == Resetting the controller == {| border='1' | ''Command syntax'' | ''Short description'' |- | bootloader | Call the bootloader. |- | reset | Reset the Ethersex. |- | wdreset | Go into endless loop to trigger a watchdog timeout. |- |} == [[ADS]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | ads get | Get the ADC value in hex. |- | ads mean [COUNT] | Get the mean of power of 2 COUNT ADC values in hex. |- |} == [[Am_Puls_der_Zeit|Clock]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | date | Print the current date. |- | lastdcf | Print when last valid DCF signal was received. |- | time [UNIXTIME] | Display/Set the current time in seconds since January 1st 1970. |- | uptime | Display ethersex uptime in unix format. |- | whm | Display ethersex uptime. |- |} == [[Application_Sample]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sample | Manually call application sample commands |- | sample_init | Manually call application sample init method |- | sample_periodic | Manually call application sample periodic method |- |} == [[Blinkenlights_MCUF|MCUF]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | mcuf modul N | Select module N |- | mcuf modul list | List all modules |- | mcuf showclock | Show digital clock |- | mcuf showstring MESSAGE | Show scrolling MESSAGE on the display |- |} == [[CRC]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | crc calc | "read the ethersex program code and calc a crc16 of it" |- | crc read | "read out the crc16 value at the end of the program space" |- |} == [[CRON-Dienst]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | cron_add MIN HOUR DAY MONTH DOW ECMD | Add ECMD to cron to be executed at given time |- | cron_list | Show all cron entries |- | cron_make_persistent | Mark a Job as persistent |- | cron_rm POSITION | Remove one cron entry |- | cron_save | Saves all persistent jobs |- |} == [[DALI]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dali cmd [TARGET] [COMMAND] [!][?] | "send the given command (decimal) to targets (all, g00 to g15, s00 to s63), auto repeat with !, read reply with ?" |- | dali dim [TARGET] [LEVEL] | "dim targets (all, g00 to g15, s00 to s63) to given level (0-254)" |- | dali raw [BYTE1] [BYTE2] | "send a raw frame (two bytes, given in hex) over the DALI bus" |- | dali scmd [SPECIAL COMMAND] [DATA] [!][?] | "send special command (256-287) with data, auto repeat with !, read reply with ?" |- |} == [[DMX_FXSlot]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx fxslot devices | set the device settings |- | dmx fxslot effect | set the effect settings |- | dmx fxslot reset | reset all fxslots and clear saved ones in EEPROM |- | dmx fxslot restore | restore the settings from EEPROM |- | dmx fxslot save | save the current fxslots to EEPROM |- |} == [[DMX_Storage]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx channels | Get channels per universe |- | dmx get | Return channel value |- | dmx set | Set channel values |- | dmx universe | Get a whole universe |- | dmx universes | Get universes |- |} == [[Dallas_1-wire_Bus]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | 1w convert [DEVICE] | Trigger temperature conversion of either DEVICE or all connected devices |- | 1w ds2450 convert [DEVICE] | `start conversion (with optional input mask and read out control)' |- | 1w ds2450 get [DEVICE] | `get conversion result (one or all channels)' |- | 1w ds2450 oc [DEVICE] | `get/set output control (per channel)' |- | 1w ds2450 oe [DEVICE] | `get/set output enable (per channel)' |- | 1w ds2450 por [DEVICE] | `get/set power on reset (per channel)' |- | 1w ds2450 power [DEVICE] | `get/set power supply of device (global)' |- | 1w ds2450 range [DEVICE] | `get/set input voltage range (per channel)' |- | 1w ds2450 res [DEVICE] | `get/set bit resolution of AD convert (per channel)' |- | 1w get DEVICE | Return temperature value of onewire DEVICE (provide 64-bit ID as 16-hex-digits) |- | 1w list | Return a list of the connected onewire devices |- |} == [[DataFlash]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | df status | Display internal status. |- | fs format | Format the filesystem. |- | fs inspect inode INODE | Inspect INODE (and associated page). |- | fs inspect node NODE | Inspect NODE and dump to serial. |- | fs list | List the directory. |- | fs mkfile NAME | Create a new file NAME. |- | fs remove NAME | Delete the file NAME. |- | fs truncate NAME LEN | Truncate the file NAME to LEN bytes. |- |} == [[Dc3840_camera|DC3840 mobil camera support]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dc3840 capture | Take a picture. Access 'dc3840' via VFS afterwards. See [[DC3840 Camera]] for details. |- | dc3840 light | Light level of camera |- | dc3840 send A B C D E | Send provided command bytes to the camera. |- | dc3840 sync | Re-sync to the camera |- | dc3840 zoom | Enable zoom of camera |- |} == [[ECMDScript]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | call FILENAME | Start script named FILENAME |- | cat FILENAME | cat file content (with debug only) |- | dec VAR | Decrement variable VAR (a number) |- | echo <any> | Print out all arguments of echo |- | exit | Exit currently running script |- | get VAR | Get value of variable VAR |- | goto N | Goto line N in currently running script |- | if ( CMD/VAR == CONST ) then CMD2 | If condition matches execute CMD2 |- | inc VAR | Increment variable VAR (a number) |- | rem <any> | Remark for anything |- | set VAR VALUE | Set variable VAR to VALUE |- | wait I | Wait I milliseconds |- |} == [[FS20]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fht send HOUSECODE ADDR CMD [CMD2] | Send FHT command. See [[FS20]] for details. |- | fs20 receive | Receive FS20/FHT sequence and display it. |- | fs20 send HOUSECODE ADDR CMD [CMD2] | Send FS20 command. See [[FS20]] for details. |- | fs20 ws300 | Receive FS20 sequence from WS300 weather station and decode it. |- |} == [[Frequency Counter]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fc %duty [CHANNEL] | "returns last on duty cycle in percent for given channel" |- | fc duty [CHANNEL] | "returns last on duty cycle (0-255) for given channel" |- | fc freq [CHANNEL] | "returns last frequency in Hz for given channel" |- | fc off [CHANNEL] | "switch off frequency counting on given channel" |- | fc on [CHANNEL] | "switch on frequency counting on given channel" |- | fc ticks [CHANNEL] | "returns last frequency in CPU ticks for given channel" |- |} == [[GLCD_Menu]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | glcdmenu key VALUE | Send a keypress to the menu |- | glcdmenu update | Update the menu |- |} == [[GPS]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | nmea get | Get latitude and longitude data |- | nmea satellites | Get satellites |- |} == [[H-Bridge]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | hbridge [action] [enable_l] [enable_r] | Set H-Bridge command |- | hbridge pwm int | Set H-Bridge enable line valueeg. speed |- |} == [[I2C]] (TWI) == {| border='1' | ''Command syntax'' | ''Short description'' |- | bmp085 apress | Get absolute pressure in Pa |- | bmp085 height PRESSNN | Get height in cm, pressure at N0 needed |- | bmp085 pressnn HEIGHT | Get pressure at N0, height in cm needed |- | bmp085 temp | Get temperature in 0.1°C |- | ds1631 convert ADDR VALUE | Initiate temperature conversions (0: stop, 1: convert) |- | ds1631 temp ADDR | Read last converted temperature |- | i2c detect | list detected I2C Chips |- | i2c rbb ADDR | read byte from I2C chip |- | i2c rbd CHIPADDR REGADDR | read byte from register address at I2C chip |- | i2c rwd CHIPADDR REGADDR | read word from register address at I2C chip |- | i2c wbb ADDR HEXVALUE | write byte to I2C chip |- | i2c wbd CHIPADDR REGADDR HEXVALUE | write byte to register address on I2C chip |- | i2c wwd CHIPADDR REGADDR HEXVALUE | write word to register address on I2C chip |- | lm75 ADDR | Get temperature |- | max7311 getDDRw ADDR | Get Direction-Register DDR |- | max7311 getINw ADDR | Get Input-Register IN |- | max7311 getOUTw ADDR | Get Output-Register OUT |- | max7311 pulse ADDR BIT TIME | Toggle Output-BIT for TIME (in ms) |- | max7311 set ADDR BIT VALUE | Set Output-BIT to VALUE (bool) |- | max7311 setDDRw ADDR VALUE | Set Direction-Register DDR (VALUE as hex) |- | max7311 setOUTw ADDR VALUE | Set Output-Register OUT (VALUE as hex) |- | pca9531 ADDR PERIODPWM1 DUTYPWM1 PERIODPWM2 DUTYPWM2 LED0..3 LED4..7 | set PWM1 and PWM2 and LED states |- | pca9685m ADDR | OUTDRV, IVRT, PRESCALE |- | pca9685s ADDR | LED, ON, OFF |- | pcf8574x read ADDR CHIP | Get bits |- | pcf8574x set ADDR CHIP HEXVALUE | Set bits |- | tsl2550 lux | Show light level by reading adc registers and computing level |- | tsl2550 mode VALUE | Set the TSL2550s operating mode (0: standard range, 1: extended range) |- | tsl2550 power VALUE | Set the TSL2550s power state (0: down, 1:up) |- |} == [[Jabber]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | jabber_host [HOSTNAME] | JABBER hostname |- | jabber_pass [PASSWORD] | JABBER password |- | jabber_resrc [RESOURCE] | JABBER resource |- | jabber_user [USERNAME] | JABBER username |- |} == [[KTY]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | kty autocalibrate CHANNEL | Calibrate to 1000 Ohm precision Resistor. |- | kty cal get | Return the calibration difference to 2k2 Resistor. |- | kty get [CHANNEL] | Get the temperature in xxx.x °C of CHANNEL or if no channel set of all channels. |- |} == [[MotorCurtain]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | curtain VALUE | Set value of curtain. 0=closed..7=open. If you use fewer sensors, use the corrent value instead of 7. |- | curtainlast | Return last known position |- | curtainmax | Return maximum position |- | curtainoff | Switch motor off |- |} == [[Named_PIN]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | pin get NAME | Read and display the status of pin NAME. |- | pin list | List all known named-pins. |- | pin set NAME STATUS | Set the status of pin NAME to STATUS. |- | pin toggle NAME | Toggle the status of pin NAME. |- |} == [[PWM]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dtmf CHARS | send CHARS as DTMF |- | freq set FREQUENCY DELAY | Set frequency for DELAY ms |- | pwm fade [channel +-diff startvalue] | Set fading at channel with startvalue and change each stepp to diff (must be signed 3 digit) |- | pwm set [channel value] | Set channel to value |- |} == [[RFM12]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | rfm12 reinit | Re-initialize RFM12 module. |- | rfm12 setbandwidth BW | Set RX bandwidth to BW. |- | rfm12 setbaud BAUD | Set baudrate to BAUD. |- | rfm12 setdrssi DRSSI | Set the drssi to DRSSI. |- | rfm12 setgain GAIN | Set preamplifier gain to GAIN. |- | rfm12 setmod MOD | Set modulation to MOD. |- | rfm12 status | Display internal status. |- |} == [[RFM12_ASK]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | rfm12 1527 | housecodeCommand delay cnt |- | rfm12 2272 | housecodeCommand delay cnt |- | rfm12 ask sense | Trigger (Tevion) ASK sensing. Enable ext. filter pin before! |- | rfm12 external filter [1] | Enable ext. filter pin if argument is present (disable otherwise) |- | rfm12 intertechno | family group device command |- | rfm12 tevion | housecode command delay cnt |- |} == [[RFM12_FS20]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fht send | housecode addr command data |- | fs20 send | housecode addr command data |- |} == [[SD-Karte]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sd dir | List contents of current SD directory. |- | sd mkdir PATH | Create directory hierarchy PATH. |- |} == [[SHT]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sht humid | Return humidity of SHT sensor |- | sht raw | Return raw hex temp (first line) and humidity value (second line) of SHT sensor |- | sht temp | Return temperature of SHT sensor |- |} == [[SMS77]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sms77 MESSAGE | Send MESSAGE to compiled in sms77 service |- | sms77_pass [PASSWORD] | SMS77 password |- | sms77_recv [RECEIVER] | SMS receiver |- | sms77_type [TYPE] | SMS type |- | sms77_user [USERNAME] | SMS77 username |- |} == [[Servo_Ansteuerung|PWM Servo Control]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | pwm servo_dec SERVONR | Decrement position of servo SERVONR |- | pwm servo_inc SERVONR | Increment position of servo SERVONR |- | pwm servo_set SERVONR POSITION | Set servo with SERVONR to POSITION |- |} == [[Sound]]/WAV support == {| border='1' | ''Command syntax'' | ''Short description'' |- | pwm stop | Stop wav |- | pwm wav <FILENAME> | Play wave file. Use VFS if compiled in. More details at [[Sound]] |- |} == [[Stella_Light]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | channel CHANNEL VALUE FUNCTION | Get/Set stella channel to value. Second and third parameters are optional. Function: You may use 's' for instant set, 'f' for fade and 'y' for flashy fade. |- | channels | Return stella channel size |- | fadestep FADESTEP | Get/Set stella fade step |- | stella load | Load values from eeprom |- | stella store | Store values in eeprom |- |} == [[USB]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | keyboard MESSAGE | Send MESSAGE as HID keyboard |- | mouse BUTTON DELTAX DELTAY | Send data as HID mouse |- |} == [[ZACwire]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | zac 306 PORT BIT | Return temperature of TSic 306 at BIT of PORT |- | zac 506 PORT BIT | Return temperature of TSic 506 at BIT of PORT |- | zac raw PORT BIT | Return raw hex temperature value of zacwire at BIT of PORT |- |} == lome6 == {| border='1' | ''Command syntax'' | ''Short description'' |- | lome6 get_t TYPE | get temperature command |- | lome6 power TYPE | press power command |- | lome6 reset | press reset command |- | lome6 set_t TYPE TEMPERATURE | set temperature command |- | lome6 state | get state command |- | lome6 uptime UPTIME | set/get uptime command |- |} == Miscelleanous == {| border='1' | ''Command syntax'' | ''Short description'' |- | alias list | List all available aliases |- | artnet test | artnet test |- | cw send MESSAGE | Send MESSAGE in Morce Code |- | d ADDR | Dump the memory at ADDR (16 bytes). |- | eeprom reinit | Force reinitialization of the EEPROM config area |- | free | Display free space. |- | help | List which commands are available. |- | ht MESSAGE | Send MESSAGE to compiled in httplog service |- | ipstats | Display IP statistics. |- | mb recv | Receive data from modbus |- | moodlight CHANNEL ONOFF | Set CHANNEL moodlight on=1 or off=0. If no channel is given return on if channel CHANNEL is moodlighted |- | motd [MESSAGE] | Save MESSAGE as new message of the day, otherwise just show current message |- | msr1 get | Get data |- | mysql query QUERY | Send specified MySQL query to the configured server |- | ns | update net statistic for public anouncment of currently running ethersex |- | pam USER PASSWORD | Use pam for user and password |- | push NUMBER | Push button identified by NUMBER |- | pwm melody [NUMBER] | Play melody |- | sanyoz700 CMD | Send command to projector |- | sll get | Request the logged data |- | sram memtest | Perform a memory test |- | srf05 | Read SRF05 measurement |- | to1 get | Request data from sensor |- | tw MESSAGE | Send MESSAGE to compiled in twitter service |- | upnp send | Manually send UPnP broadcast packet |- | usart baud BAUD | Set the USART baudrate to BAUD. |- | version | Display the version number. |- | wol MAC | Send WAKE-ON-LAN command to MAC |- | yport stats | Report statistic counters |- | zbus stats | Report statistic counters |- |} [[Category:Ethersex]] [[Category:ECMD]] d67e52566a7046bf558c830fc104bb9f9627d195 0 149 351 2012-01-12T00:44:19Z Gvegidy 132 Created page with "{{Module |NAME=BMP085 |MENUCONFIG={{I/O}}->{{I2C Master}}->BMP085 |STATUS={{experimental}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]], [[I2C Master]] |REQUIRES…" wikitext text/x-wiki {{Module |NAME=BMP085 |MENUCONFIG={{I/O}}->{{I2C Master}}->BMP085 |STATUS={{experimental}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]], [[I2C Master]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/blob/master/hardware/i2c/master/i2c_bmp085.c https://github.com/ethersex/ethersex/blob/master/hardware/i2c/master/i2c_bmp085.c ] }} = Bosch BMP085 und BMP180 barometric pressure sensors = == Sensors == * Cheap (about 6 EUR) * Small * Precise (Resolution 0.25m, absolute accuracy +-2.5 hPa) * Digital readout via I2C * BMP085 and BMP180 are code-compatible, the BMP180 comes in a smaller package [http://www.bosch-sensortec.com/content/language1/html/3477.htm Datasheets] == Availibility == Pure sensors * [http://www.digikey.com Digikey] Breakout boards * [http://jeelabs.com/products/pressure-plug JeeLabs] * Sparkfun * [http://www.watterott.com/de/Breakout-Board-mit-dem-BMP085-absoluten-Drucksensor Watterott] == ECMD == c99e269b4c104aa3190199c67db621c5a70bbafa 352 351 2012-01-12T00:59:37Z Gvegidy 132 wikitext text/x-wiki {{Module |NAME=BMP085 |MENUCONFIG={{I/O}}->{{I2C Master}}->BMP085 |STATUS={{experimental}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]], [[I2C Master]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/blob/master/hardware/i2c/master/i2c_bmp085.c https://github.com/ethersex/ethersex/blob/master/hardware/i2c/master/i2c_bmp085.c ] }} = Bosch BMP085 und BMP180 barometric pressure sensors = == Sensors == * Cheap (about 6 EUR) * Small * Precise (Resolution 0.25m, absolute accuracy +-2.5 hPa) * Digital readout via I2C * BMP085 and BMP180 are code-compatible, the BMP180 comes in a smaller package [http://www.bosch-sensortec.com/content/language1/html/3477.htm Datasheets] == Availibility == Pure sensors * [http://www.digikey.com Digikey] Breakout boards * [http://jeelabs.com/products/pressure-plug JeeLabs] * Sparkfun * [http://www.watterott.com/de/Breakout-Board-mit-dem-BMP085-absoluten-Drucksensor Watterott] == [[ECMD]] == {| border=1 | '''Command Syntax''' | '''Short description''' |- | bmp085 temp | Returns the temperature in 0.1°C (16 Bit integer) |- | bmp085 apress | Returns the absolute pressure in Pa (32 Bit integer) |- | bmp085 height <p0> | Returns the height in cm. Needs the pressure p0 at NN as parameter (given in Pa, 32 Bit integer). |- | bmp085 pressnn <height> | Returns the pressure p0 at NN in Pa. Needs the current height in cm (32 Bit integer). |- |} == Pressure calculations == * Pressure calculations for the height and pressnn commands are done using the [http://en.wikipedia.org/wiki/Barometric_formula Barometric formula] == Precision == * The sensor is sensitive to air turbulences (propellers, fans, loud music) * The sensor is sensitive to power supply ripple - if not using a battery try to filter it well * The results will have some noise, filter them with a moving average or other algorithm to get good results 04048494889a553b8f55d5c6ded7bc809fad8416 353 352 2012-01-12T01:00:44Z Gvegidy 132 wikitext text/x-wiki {{Module |NAME=BMP085 |MENUCONFIG={{I/O}}->{{I2C Master}}->BMP085 |STATUS={{experimental}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]], [[I2C Master]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/blob/master/hardware/i2c/master/i2c_bmp085.c https://github.com/ethersex/ethersex/blob/master/hardware/i2c/master/i2c_bmp085.c ] }} = Bosch BMP085 and BMP180 barometric pressure sensors = == Sensors == * Cheap (about 6 EUR) * Small * Precise (Resolution 0.25m, absolute accuracy +-2.5 hPa) * Digital readout via I2C * BMP085 and BMP180 are code-compatible, the BMP180 comes in a smaller package [http://www.bosch-sensortec.com/content/language1/html/3477.htm Datasheets] == Availibility == Pure sensors * [http://www.digikey.com Digikey] Breakout boards * [http://jeelabs.com/products/pressure-plug JeeLabs] * Sparkfun * [http://www.watterott.com/de/Breakout-Board-mit-dem-BMP085-absoluten-Drucksensor Watterott] == [[ECMD]] == {| border=1 | '''Command Syntax''' | '''Short description''' |- | bmp085 temp | Returns the temperature in 0.1°C (16 Bit integer) |- | bmp085 apress | Returns the absolute pressure in Pa (32 Bit integer) |- | bmp085 height <p0> | Returns the height in cm. Needs the pressure p0 at NN as parameter (given in Pa, 32 Bit integer). |- | bmp085 pressnn <height> | Returns the pressure p0 at NN in Pa. Needs the current height in cm (32 Bit integer). |- |} == Pressure calculations == * Pressure calculations for the height and pressnn commands are done using the [http://en.wikipedia.org/wiki/Barometric_formula Barometric formula] == Precision == * The sensor is sensitive to air turbulences (propellers, fans, loud music) * The sensor is sensitive to power supply ripple - if not using a battery try to filter it well * The results will have some noise, filter them with a moving average or other algorithm to get good results ded3e9c2b3969ec89f0e1ddef762d423527e7732 6 150 357 2012-01-12T21:54:52Z Hugo790 425 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 151 364 2012-02-01T12:54:54Z GooPie4o 265 Created page with "{{i18n|Clock}} {{Module |NAME=Clock |MENUCONFIG={{Applications}}->System clock support |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] (optional) |REQUIRES= -…" wikitext text/x-wiki {{i18n|Clock}} {{Module |NAME=Clock |MENUCONFIG={{Applications}}->System clock support |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] (optional) |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/services/clock https://github.com/ethersex/ethersex/tree/master/services/clock] }} aba2177446b0d5c1e238890fbaf8aafc4580769b 14 152 365 2012-02-01T13:31:20Z GooPie4o 265 Created page with "This category lists all components with an "[[ECMD]]" interface." wikitext text/x-wiki This category lists all components with an "[[ECMD]]" interface. 80f58bd8ff1e28a536f1ab7f2119bd3617794d2e 0 153 367 2012-02-03T14:55:59Z GooPie4o 265 Created page with "{{i18n|Clock}} {{Module |NAME=Clock |MENUCONFIG={{Applications}}->System clock support |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] (optional) |REQUIRES= -…" wikitext text/x-wiki {{i18n|Clock}} {{Module |NAME=Clock |MENUCONFIG={{Applications}}->System clock support |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] (optional) |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/services/clock https://github.com/ethersex/ethersex/tree/master/services/clock] }} aba2177446b0d5c1e238890fbaf8aafc4580769b 0 35 368 218 2012-02-04T14:05:00Z GooPie4o 265 /* Current TODO List */ wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or any other incompatible licesne. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or any other incompatible license. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || NO |- |Riegel, Roland || NO || NO || NO || NO || NO |- |} == Current TODO List == * collect files with incompatible license. {| border="1" ! File !! License !! Status |- | core/gui/font.c || 3-clause BSD || OK |- | core/host/host.h || unknown || |- | core/host/util/crc16.h || unknown || |- | core/setbaud.h || unknown || |- | hardware/ir/irmp/irmp_lib.c || GPLv2+ || OK |- | hardware/lcd/s1d15g10/bunnies.h || unknown || |- | hardware/lcd/ST7626/4x6.h || unknown || |- | hardware/lcd/ST7626/ST7626.h || unknown || |- | hardware/sram/sram.h || unknown || |- | hardware/storage/sd_reader/byteordering.* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/fat* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/partition* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/sd_raw* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/sd-reader_config.h || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | protocols/bootp/bootphdr.h || unknown || |- | protocols/uip/uip-conf.h || unknown || |- | protocols/usb/usbconfig.h || GPLv2 or v3 || see the included protocols/usb/usbdrv/License.txt |- | protocols/ustream/vs1053.c || unknown || contacted 4.11.11, replied - agreed on MIT |- | protocols/ustream/vs1053.h || unknown || contacted 4.11.11, replied - agreed on MIT |- | services/glcdmenu/menu-interpreter/menudata-progmem.c || unknown || contacted 4.11.11, generated code - no need to license |- | services/glcdmenu/menu-interpreter/menu-interpreter-config.h || unknown || contacted 4.11.11, generated code - no need to license |- |} to find out all the authors of a certain file, run ''contrib/license-lister file'' . e.g. ''contrib/license-lister protocols/bootp/bootphdr.h'' * send an email to authors of source files with incompatible license == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD * Adam Dunkels' uIP Stack is licensed under the BSD http://en.wikipedia.org/wiki/UIP_(micro_IP) https://github.com/ethersex/ethersex/blob/master/protocols/uip/uip.c#L25 * MIT/X is compatible with GPLv3 ** http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing * reintegrate SD Reader library from http://www.roland-riegel.de/sd-reader/ ** done https://github.com/ethersex/ethersex/commit/0ba2a832b2f0e16e78cb26202b5e4fe4e266614b 11c49abbec18cf327de85228866f5f3d69fcf36f 369 368 2012-02-04T14:05:39Z GooPie4o 265 /* Current TODO List */ wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or any other incompatible licesne. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or any other incompatible license. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || NO |- |Riegel, Roland || NO || NO || NO || NO || NO |- |} == Current TODO List == * collect files with incompatible license. {| border="1" ! File !! License !! Status |- | core/gui/font.c || 3-clause BSD || OK |- | core/host/host.h || unknown || |- | core/host/util/crc16.h || unknown || |- | core/setbaud.h || unknown || |- | hardware/ir/irmp/irmp_lib.c || GPLv2+ || OK |- | hardware/lcd/s1d15g10/bunnies.h || unknown || |- | hardware/lcd/ST7626/4x6.h || unknown || |- | hardware/lcd/ST7626/ST7626.h || unknown || |- | hardware/sram/sram.h || unknown || |- | hardware/storage/sd_reader/byteordering.* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/fat* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/partition* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/sd_raw* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/sd-reader_config.h || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | protocols/bootp/bootphdr.h || unknown || |- | protocols/uip/uip-conf.h || unknown || |- | protocols/usb/usbconfig.h || GPLv2 or v3 || OK, see the included protocols/usb/usbdrv/License.txt |- | protocols/ustream/vs1053.c || unknown || contacted 4.11.11, replied - agreed on MIT |- | protocols/ustream/vs1053.h || unknown || contacted 4.11.11, replied - agreed on MIT |- | services/glcdmenu/menu-interpreter/menudata-progmem.c || unknown || contacted 4.11.11, generated code - no need to license |- | services/glcdmenu/menu-interpreter/menu-interpreter-config.h || unknown || contacted 4.11.11, generated code - no need to license |- |} to find out all the authors of a certain file, run ''contrib/license-lister file'' . e.g. ''contrib/license-lister protocols/bootp/bootphdr.h'' * send an email to authors of source files with incompatible license == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD * Adam Dunkels' uIP Stack is licensed under the BSD http://en.wikipedia.org/wiki/UIP_(micro_IP) https://github.com/ethersex/ethersex/blob/master/protocols/uip/uip.c#L25 * MIT/X is compatible with GPLv3 ** http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing * reintegrate SD Reader library from http://www.roland-riegel.de/sd-reader/ ** done https://github.com/ethersex/ethersex/commit/0ba2a832b2f0e16e78cb26202b5e4fe4e266614b b75b50fd82887f97b88dd2206e5b31f8ef34c937 370 369 2012-02-04T14:07:01Z GooPie4o 265 /* Relicensing progress */ wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or any other incompatible licesne. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or any other incompatible license. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || NO |- |Riegel, Roland || NO || NO || NO || NO || NO |- |} == Current TODO List == * collect files with incompatible license. {| border="1" ! File !! License !! Status |- | core/gui/font.c || 3-clause BSD || OK |- | core/host/host.h || unknown || |- | core/host/util/crc16.h || unknown || |- | core/setbaud.h || unknown || |- | hardware/ir/irmp/irmp_lib.c || GPLv2+ || OK |- | hardware/lcd/s1d15g10/bunnies.h || unknown || |- | hardware/lcd/ST7626/4x6.h || unknown || |- | hardware/lcd/ST7626/ST7626.h || unknown || |- | hardware/sram/sram.h || unknown || |- | hardware/storage/sd_reader/byteordering.* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/fat* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/partition* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/sd_raw* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/sd-reader_config.h || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | protocols/bootp/bootphdr.h || unknown || |- | protocols/uip/uip-conf.h || unknown || |- | protocols/usb/usbconfig.h || GPLv2 or v3 || OK, see the included protocols/usb/usbdrv/License.txt |- | protocols/ustream/vs1053.c || unknown || contacted 4.11.11, replied - agreed on MIT |- | protocols/ustream/vs1053.h || unknown || contacted 4.11.11, replied - agreed on MIT |- | services/glcdmenu/menu-interpreter/menudata-progmem.c || unknown || contacted 4.11.11, generated code - no need to license |- | services/glcdmenu/menu-interpreter/menu-interpreter-config.h || unknown || contacted 4.11.11, generated code - no need to license |- |} to find out all the authors of a certain file, run ''contrib/license-lister file'' . e.g. ''contrib/license-lister protocols/bootp/bootphdr.h'' * send an email to authors of source files with incompatible license == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD * Adam Dunkels' uIP Stack is licensed under the BSD http://en.wikipedia.org/wiki/UIP_(micro_IP) https://github.com/ethersex/ethersex/blob/master/protocols/uip/uip.c#L25 * MIT/X is compatible with GPLv3 ** http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing * reintegrate SD Reader library from http://www.roland-riegel.de/sd-reader/ ** done https://github.com/ethersex/ethersex/commit/0ba2a832b2f0e16e78cb26202b5e4fe4e266614b * reintegrate V-USB from http://www.obdev.at/products/vusb/download.html f81a1f4fae4e9ad67dc6c4a2b306c5e5c94c0eca 371 370 2012-02-04T14:31:40Z Mgue 312 setbaud wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or any other incompatible licesne. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or any other incompatible license. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || NO |- |Riegel, Roland || NO || NO || NO || NO || NO |- |} == Current TODO List == * collect files with incompatible license. {| border="1" ! File !! License !! Status |- | core/gui/font.c || 3-clause BSD || OK |- | core/host/host.h || unknown || |- | core/host/util/crc16.h || unknown || |- | core/setbaud.h || 3-clause BSD || OK - file may be expendable |- | hardware/ir/irmp/irmp_lib.c || GPLv2+ || OK |- | hardware/lcd/s1d15g10/bunnies.h || unknown || |- | hardware/lcd/ST7626/4x6.h || unknown || |- | hardware/lcd/ST7626/ST7626.h || unknown || |- | hardware/sram/sram.h || unknown || |- | hardware/storage/sd_reader/byteordering.* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/fat* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/partition* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/sd_raw* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/sd-reader_config.h || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | protocols/bootp/bootphdr.h || unknown || |- | protocols/uip/uip-conf.h || unknown || |- | protocols/usb/usbconfig.h || GPLv2 or v3 || OK, see the included protocols/usb/usbdrv/License.txt |- | protocols/ustream/vs1053.c || unknown || contacted 4.11.11, replied - agreed on MIT |- | protocols/ustream/vs1053.h || unknown || contacted 4.11.11, replied - agreed on MIT |- | services/glcdmenu/menu-interpreter/menudata-progmem.c || unknown || contacted 4.11.11, generated code - no need to license |- | services/glcdmenu/menu-interpreter/menu-interpreter-config.h || unknown || contacted 4.11.11, generated code - no need to license |- |} to find out all the authors of a certain file, run ''contrib/license-lister file'' . e.g. ''contrib/license-lister protocols/bootp/bootphdr.h'' * send an email to authors of source files with incompatible license == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD * Adam Dunkels' uIP Stack is licensed under the BSD http://en.wikipedia.org/wiki/UIP_(micro_IP) https://github.com/ethersex/ethersex/blob/master/protocols/uip/uip.c#L25 * MIT/X is compatible with GPLv3 ** http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing * reintegrate SD Reader library from http://www.roland-riegel.de/sd-reader/ ** done https://github.com/ethersex/ethersex/commit/0ba2a832b2f0e16e78cb26202b5e4fe4e266614b * reintegrate V-USB from http://www.obdev.at/products/vusb/download.html de09973fd3b56abdc0a22e08008aed20ed4700c2 0 35 372 371 2012-02-04T14:41:32Z GooPie4o 265 /* Relicensing progress */ wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or any other incompatible licesne. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or any other incompatible license. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || NO |- |Riegel, Roland || NO || NO || NO || NO || NO |- |} == Current TODO List == * collect files with incompatible license. {| border="1" ! File !! License !! Status |- | core/gui/font.c || 3-clause BSD || OK |- | core/host/host.h || unknown || |- | core/host/util/crc16.h || unknown || |- | core/setbaud.h || 3-clause BSD || OK - file may be expendable |- | hardware/ir/irmp/irmp_lib.c || GPLv2+ || OK |- | hardware/lcd/s1d15g10/bunnies.h || unknown || |- | hardware/lcd/ST7626/4x6.h || unknown || |- | hardware/lcd/ST7626/ST7626.h || unknown || |- | hardware/sram/sram.h || unknown || |- | hardware/storage/sd_reader/byteordering.* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/fat* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/partition* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/sd_raw* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/sd-reader_config.h || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | protocols/bootp/bootphdr.h || unknown || |- | protocols/uip/uip-conf.h || unknown || |- | protocols/usb/usbconfig.h || GPLv2 or v3 || OK, see the included protocols/usb/usbdrv/License.txt |- | protocols/ustream/vs1053.c || unknown || contacted 4.11.11, replied - agreed on MIT |- | protocols/ustream/vs1053.h || unknown || contacted 4.11.11, replied - agreed on MIT |- | services/glcdmenu/menu-interpreter/menudata-progmem.c || unknown || contacted 4.11.11, generated code - no need to license |- | services/glcdmenu/menu-interpreter/menu-interpreter-config.h || unknown || contacted 4.11.11, generated code - no need to license |- |} to find out all the authors of a certain file, run ''contrib/license-lister file'' . e.g. ''contrib/license-lister protocols/bootp/bootphdr.h'' * send an email to authors of source files with incompatible license == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD * Adam Dunkels' uIP Stack is licensed under the BSD http://en.wikipedia.org/wiki/UIP_(micro_IP) https://github.com/ethersex/ethersex/blob/master/protocols/uip/uip.c#L25 * MIT/X is compatible with GPLv3 ** http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing * reintegrate SD Reader library from http://www.roland-riegel.de/sd-reader/ ** done https://github.com/ethersex/ethersex/commit/0ba2a832b2f0e16e78cb26202b5e4fe4e266614b * reintegrate V-USB from http://www.obdev.at/products/vusb/download.html ** done https://github.com/ethersex/ethersex/commit/87c4d2b07c3939bf43779714d3b1cbcacd6848b3 48ae66decb30428699ff834dc3d27ea0fe2be3db 373 372 2012-02-04T15:53:19Z GooPie4o 265 /* Current TODO List */ wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or any other incompatible licesne. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or any other incompatible license. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || NO |- |Riegel, Roland || NO || NO || NO || NO || NO |- |} == Current TODO List == * collect files with incompatible license. {| border="1" ! File !! License !! Status |- | core/gui/font.c || 3-clause BSD || OK |- | core/host/host.h || unknown || |- | core/host/util/crc16.h || unknown || |- | core/setbaud.h || 3-clause BSD || removed - use utils/setbaud.h from avrlibc |- | hardware/ir/irmp/irmp_lib.c || GPLv2+ || OK |- | hardware/lcd/s1d15g10/bunnies.h || unknown || |- | hardware/lcd/ST7626/4x6.h || unknown || |- | hardware/lcd/ST7626/ST7626.h || unknown || |- | hardware/sram/sram.h || unknown || |- | hardware/storage/sd_reader/byteordering.* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/fat* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/partition* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/sd_raw* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/sd-reader_config.h || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | protocols/bootp/bootphdr.h || unknown || |- | protocols/uip/uip-conf.h || unknown || |- | protocols/usb/usbconfig.h || GPLv2 or v3 || OK, see the included protocols/usb/usbdrv/License.txt |- | protocols/ustream/vs1053.c || unknown || contacted 4.11.11, replied - agreed on MIT |- | protocols/ustream/vs1053.h || unknown || contacted 4.11.11, replied - agreed on MIT |- | services/glcdmenu/menu-interpreter/menudata-progmem.c || unknown || contacted 4.11.11, generated code - no need to license |- | services/glcdmenu/menu-interpreter/menu-interpreter-config.h || unknown || contacted 4.11.11, generated code - no need to license |- |} to find out all the authors of a certain file, run ''contrib/license-lister file'' . e.g. ''contrib/license-lister protocols/bootp/bootphdr.h'' * send an email to authors of source files with incompatible license == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD * Adam Dunkels' uIP Stack is licensed under the BSD http://en.wikipedia.org/wiki/UIP_(micro_IP) https://github.com/ethersex/ethersex/blob/master/protocols/uip/uip.c#L25 * MIT/X is compatible with GPLv3 ** http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing * reintegrate SD Reader library from http://www.roland-riegel.de/sd-reader/ ** done https://github.com/ethersex/ethersex/commit/0ba2a832b2f0e16e78cb26202b5e4fe4e266614b * reintegrate V-USB from http://www.obdev.at/products/vusb/download.html ** done https://github.com/ethersex/ethersex/commit/87c4d2b07c3939bf43779714d3b1cbcacd6848b3 93f20ef8f8c08227fdfab460d2da69b684a639aa 374 373 2012-02-04T16:27:02Z Mgue 312 wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or any other incompatible licesne. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or any other incompatible license. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || NO |- |Riegel, Roland || NO || NO || NO || NO || NO |- |} == Current TODO List == * collect files with incompatible license. {| border="1" ! File !! License !! Status |- | core/gui/font.c || 3-clause BSD || OK |- | core/host/host.h || unknown || OK empty file - does not need a license |- | core/host/util/crc16.h || unknown || |- | core/setbaud.h || 3-clause BSD || removed - use utils/setbaud.h from avrlibc |- | hardware/ir/irmp/irmp_lib.c || GPLv2+ || OK |- | hardware/lcd/s1d15g10/bunnies.h || unknown || |- | hardware/lcd/ST7626/4x6.h || unknown || |- | hardware/lcd/ST7626/ST7626.h || unknown || |- | hardware/sram/sram.h || unknown || |- | hardware/storage/sd_reader/byteordering.* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/fat* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/partition* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/sd_raw* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/sd-reader_config.h || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | protocols/bootp/bootphdr.h || unknown || |- | protocols/uip/uip-conf.h || unknown || |- | protocols/usb/usbconfig.h || GPLv2 or v3 || OK, see the included protocols/usb/usbdrv/License.txt |- | protocols/ustream/vs1053.c || unknown || contacted 4.11.11, replied - agreed on MIT |- | protocols/ustream/vs1053.h || unknown || contacted 4.11.11, replied - agreed on MIT |- | services/glcdmenu/menu-interpreter/menudata-progmem.c || unknown || contacted 4.11.11, generated code - no need to license |- | services/glcdmenu/menu-interpreter/menu-interpreter-config.h || unknown || contacted 4.11.11, generated code - no need to license |- |} to find out all the authors of a certain file, run ''contrib/license-lister file'' . e.g. ''contrib/license-lister protocols/bootp/bootphdr.h'' * send an email to authors of source files with incompatible license == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD * Adam Dunkels' uIP Stack is licensed under the BSD http://en.wikipedia.org/wiki/UIP_(micro_IP) https://github.com/ethersex/ethersex/blob/master/protocols/uip/uip.c#L25 * MIT/X is compatible with GPLv3 ** http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing * reintegrate SD Reader library from http://www.roland-riegel.de/sd-reader/ ** done https://github.com/ethersex/ethersex/commit/0ba2a832b2f0e16e78cb26202b5e4fe4e266614b * reintegrate V-USB from http://www.obdev.at/products/vusb/download.html ** done https://github.com/ethersex/ethersex/commit/87c4d2b07c3939bf43779714d3b1cbcacd6848b3 5ac1c253c8bc1babcb54492f2da2bed5335ca590 375 374 2012-02-04T16:39:42Z Mgue 312 crc16.h wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or any other incompatible licesne. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or any other incompatible license. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || NO |- |Riegel, Roland || NO || NO || NO || NO || NO |- |} == Current TODO List == * collect files with incompatible license. {| border="1" ! File !! License !! Status |- | core/gui/font.c || 3-clause BSD || OK |- | core/host/host.h || unknown || OK empty file - does not need a license |- | core/host/util/crc16.h || no license, has to be 3-clause BSD || File is a partial copy of util/crc16.h, so we should use the 3-clause BSD for that file |- | core/setbaud.h || 3-clause BSD || removed - use utils/setbaud.h from avrlibc |- | hardware/ir/irmp/irmp_lib.c || GPLv2+ || OK |- | hardware/lcd/s1d15g10/bunnies.h || unknown || |- | hardware/lcd/ST7626/4x6.h || unknown || |- | hardware/lcd/ST7626/ST7626.h || unknown || |- | hardware/sram/sram.h || unknown || |- | hardware/storage/sd_reader/byteordering.* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/fat* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/partition* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/sd_raw* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/sd-reader_config.h || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | protocols/bootp/bootphdr.h || unknown || |- | protocols/uip/uip-conf.h || unknown || |- | protocols/usb/usbconfig.h || GPLv2 or v3 || OK, see the included protocols/usb/usbdrv/License.txt |- | protocols/ustream/vs1053.c || unknown || contacted 4.11.11, replied - agreed on MIT |- | protocols/ustream/vs1053.h || unknown || contacted 4.11.11, replied - agreed on MIT |- | services/glcdmenu/menu-interpreter/menudata-progmem.c || unknown || contacted 4.11.11, generated code - no need to license |- | services/glcdmenu/menu-interpreter/menu-interpreter-config.h || unknown || contacted 4.11.11, generated code - no need to license |- |} to find out all the authors of a certain file, run ''contrib/license-lister file'' . e.g. ''contrib/license-lister protocols/bootp/bootphdr.h'' * send an email to authors of source files with incompatible license == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD * Adam Dunkels' uIP Stack is licensed under the BSD http://en.wikipedia.org/wiki/UIP_(micro_IP) https://github.com/ethersex/ethersex/blob/master/protocols/uip/uip.c#L25 * MIT/X is compatible with GPLv3 ** http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing * reintegrate SD Reader library from http://www.roland-riegel.de/sd-reader/ ** done https://github.com/ethersex/ethersex/commit/0ba2a832b2f0e16e78cb26202b5e4fe4e266614b * reintegrate V-USB from http://www.obdev.at/products/vusb/download.html ** done https://github.com/ethersex/ethersex/commit/87c4d2b07c3939bf43779714d3b1cbcacd6848b3 a8bfaa7b320b8f7f0d665737fb527248244a7124 376 375 2012-02-04T16:47:54Z Mgue 312 bootp wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or any other incompatible licesne. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or any other incompatible license. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || NO |- |Riegel, Roland || NO || NO || NO || NO || NO |- |} == Current TODO List == * collect files with incompatible license. {| border="1" ! File !! License !! Status |- | core/gui/font.c || 3-clause BSD || OK |- | core/host/host.h || unknown || OK empty file - does not need a license |- | core/host/util/crc16.h || no license, has to be 3-clause BSD || File is a partial copy of util/crc16.h, so we should use the 3-clause BSD for that file |- | core/setbaud.h || 3-clause BSD || removed - use utils/setbaud.h from avrlibc |- | hardware/ir/irmp/irmp_lib.c || GPLv2+ || OK |- | hardware/lcd/s1d15g10/bunnies.h || unknown || |- | hardware/lcd/ST7626/4x6.h || unknown || |- | hardware/lcd/ST7626/ST7626.h || unknown || |- | hardware/sram/sram.h || unknown || |- | hardware/storage/sd_reader/byteordering.* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/fat* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/partition* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/sd_raw* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/sd-reader_config.h || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | protocols/bootp/bootphdr.h || MIT || OK |- | protocols/uip/uip-conf.h || unknown || |- | protocols/usb/usbconfig.h || GPLv2 or v3 || OK, see the included protocols/usb/usbdrv/License.txt |- | protocols/ustream/vs1053.c || unknown || contacted 4.11.11, replied - agreed on MIT |- | protocols/ustream/vs1053.h || unknown || contacted 4.11.11, replied - agreed on MIT |- | services/glcdmenu/menu-interpreter/menudata-progmem.c || unknown || contacted 4.11.11, generated code - no need to license |- | services/glcdmenu/menu-interpreter/menu-interpreter-config.h || unknown || contacted 4.11.11, generated code - no need to license |- |} to find out all the authors of a certain file, run ''contrib/license-lister file'' . e.g. ''contrib/license-lister protocols/bootp/bootphdr.h'' * send an email to authors of source files with incompatible license == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD * Adam Dunkels' uIP Stack is licensed under the BSD http://en.wikipedia.org/wiki/UIP_(micro_IP) https://github.com/ethersex/ethersex/blob/master/protocols/uip/uip.c#L25 * MIT/X is compatible with GPLv3 ** http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing * reintegrate SD Reader library from http://www.roland-riegel.de/sd-reader/ ** done https://github.com/ethersex/ethersex/commit/0ba2a832b2f0e16e78cb26202b5e4fe4e266614b * reintegrate V-USB from http://www.obdev.at/products/vusb/download.html ** done https://github.com/ethersex/ethersex/commit/87c4d2b07c3939bf43779714d3b1cbcacd6848b3 a120fb46f6c6f8e7f1d908149931b2c4ec41e3ed 377 376 2012-02-05T15:55:55Z Mgue 312 sram wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or any other incompatible licesne. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or any other incompatible license. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || NO |- |Riegel, Roland || NO || NO || NO || NO || NO |- |} == Current TODO List == * collect files with incompatible license. {| border="1" ! File !! License !! Status |- | core/gui/font.c || 3-clause BSD || OK |- | core/host/host.h || unknown || OK empty file - does not need a license |- | core/host/util/crc16.h || no license, has to be 3-clause BSD || File is a partial copy of util/crc16.h, so we should use the 3-clause BSD for that file |- | core/setbaud.h || 3-clause BSD || removed - use utils/setbaud.h from avrlibc |- | hardware/ir/irmp/irmp_lib.c || GPLv2+ || OK |- | hardware/lcd/s1d15g10/bunnies.h || unknown || |- | hardware/lcd/ST7626/4x6.h || unknown || |- | hardware/lcd/ST7626/ST7626.h || unknown || |- | hardware/sram/sram.h || GPLv2+ || OK - we can assume GPLv2+ because of sram.c |- | hardware/storage/sd_reader/byteordering.* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/fat* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/partition* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/sd_raw* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/sd-reader_config.h || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | protocols/bootp/bootphdr.h || MIT || OK |- | protocols/uip/uip-conf.h || unknown || |- | protocols/usb/usbconfig.h || GPLv2 or v3 || OK, see the included protocols/usb/usbdrv/License.txt |- | protocols/ustream/vs1053.c || unknown || contacted 4.11.11, replied - agreed on MIT |- | protocols/ustream/vs1053.h || unknown || contacted 4.11.11, replied - agreed on MIT |- | services/glcdmenu/menu-interpreter/menudata-progmem.c || unknown || contacted 4.11.11, generated code - no need to license |- | services/glcdmenu/menu-interpreter/menu-interpreter-config.h || unknown || contacted 4.11.11, generated code - no need to license |- |} to find out all the authors of a certain file, run ''contrib/license-lister file'' . e.g. ''contrib/license-lister protocols/bootp/bootphdr.h'' * send an email to authors of source files with incompatible license == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD * Adam Dunkels' uIP Stack is licensed under the BSD http://en.wikipedia.org/wiki/UIP_(micro_IP) https://github.com/ethersex/ethersex/blob/master/protocols/uip/uip.c#L25 * MIT/X is compatible with GPLv3 ** http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing * reintegrate SD Reader library from http://www.roland-riegel.de/sd-reader/ ** done https://github.com/ethersex/ethersex/commit/0ba2a832b2f0e16e78cb26202b5e4fe4e266614b * reintegrate V-USB from http://www.obdev.at/products/vusb/download.html ** done https://github.com/ethersex/ethersex/commit/87c4d2b07c3939bf43779714d3b1cbcacd6848b3 5cd4251fe4f42d8a1ad160ed8481d3114bcc325d 378 377 2012-02-05T16:53:38Z Mgue 312 uip wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or any other incompatible licesne. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or any other incompatible license. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || NO |- |Riegel, Roland || NO || NO || NO || NO || NO |- |} == Current TODO List == * collect files with incompatible license. {| border="1" ! File !! License !! Status |- | core/gui/font.c || 3-clause BSD || OK |- | core/host/host.h || unknown || OK empty file - does not need a license |- | core/host/util/crc16.h || no license, has to be 3-clause BSD || File is a partial copy of util/crc16.h, so we should use the 3-clause BSD for that file |- | core/setbaud.h || 3-clause BSD || removed - use utils/setbaud.h from avrlibc |- | hardware/ir/irmp/irmp_lib.c || GPLv2+ || OK |- | hardware/lcd/s1d15g10/bunnies.h || unknown || |- | hardware/lcd/ST7626/4x6.h || unknown || |- | hardware/lcd/ST7626/ST7626.h || unknown || |- | hardware/sram/sram.h || GPLv2+ || OK - we can assume GPLv2+ because of sram.c |- | hardware/storage/sd_reader/byteordering.* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/fat* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/partition* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/sd_raw* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/sd-reader_config.h || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | protocols/bootp/bootphdr.h || MIT || OK |- | protocols/uip/uip-conf.h || BSD || OK - license and copyright disappeared with 7c2045a0b3e67b53a12e74a337abb124ee0c55bf |- | protocols/usb/usbconfig.h || GPLv2 or v3 || OK, see the included protocols/usb/usbdrv/License.txt |- | protocols/ustream/vs1053.c || unknown || contacted 4.11.11, replied - agreed on MIT |- | protocols/ustream/vs1053.h || unknown || contacted 4.11.11, replied - agreed on MIT |- | services/glcdmenu/menu-interpreter/menudata-progmem.c || unknown || contacted 4.11.11, generated code - no need to license |- | services/glcdmenu/menu-interpreter/menu-interpreter-config.h || unknown || contacted 4.11.11, generated code - no need to license |- |} to find out all the authors of a certain file, run ''contrib/license-lister file'' . e.g. ''contrib/license-lister protocols/bootp/bootphdr.h'' * send an email to authors of source files with incompatible license == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD * Adam Dunkels' uIP Stack is licensed under the BSD http://en.wikipedia.org/wiki/UIP_(micro_IP) https://github.com/ethersex/ethersex/blob/master/protocols/uip/uip.c#L25 * MIT/X is compatible with GPLv3 ** http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing * reintegrate SD Reader library from http://www.roland-riegel.de/sd-reader/ ** done https://github.com/ethersex/ethersex/commit/0ba2a832b2f0e16e78cb26202b5e4fe4e266614b * reintegrate V-USB from http://www.obdev.at/products/vusb/download.html ** done https://github.com/ethersex/ethersex/commit/87c4d2b07c3939bf43779714d3b1cbcacd6848b3 5b86a44b4c489569367f626fed3d4c16788b74e4 379 378 2012-02-06T17:08:41Z Mgue 312 /* Current TODO List */ wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or any other incompatible licesne. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or any other incompatible license. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || NO |- |Riegel, Roland || NO || NO || NO || NO || NO |- |} == Current TODO List == * collect files with incompatible license. {| border="1" ! File !! License !! Status |- | core/gui/font.c || 3-clause BSD || OK |- | core/host/host.h || unknown || OK empty file - does not need a license |- | core/host/util/crc16.h || no license, has to be 3-clause BSD || File is a partial copy of util/crc16.h, so we should use the 3-clause BSD for that file |- | core/setbaud.h || 3-clause BSD || removed - use utils/setbaud.h from avrlibc |- | hardware/ir/irmp/irmp_lib.c || GPLv2+ || OK |- | hardware/lcd/s1d15g10/bunnies.h || GPLv2+ assumed || OK |- | hardware/lcd/ST7626/4x6.h || unknown || |- | hardware/lcd/ST7626/ST7626.h || unknown || |- | hardware/sram/sram.h || GPLv2+ || OK - we can assume GPLv2+ because of sram.c |- | hardware/storage/sd_reader/byteordering.* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/fat* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/partition* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/sd_raw* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/sd-reader_config.h || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | protocols/bootp/bootphdr.h || MIT || OK |- | protocols/uip/uip-conf.h || BSD || OK - license and copyright disappeared with 7c2045a0b3e67b53a12e74a337abb124ee0c55bf |- | protocols/usb/usbconfig.h || GPLv2 or v3 || OK, see the included protocols/usb/usbdrv/License.txt |- | protocols/ustream/vs1053.c || unknown || contacted 4.11.11, replied - agreed on MIT |- | protocols/ustream/vs1053.h || unknown || contacted 4.11.11, replied - agreed on MIT |- | services/glcdmenu/menu-interpreter/menudata-progmem.c || unknown || contacted 4.11.11, generated code - no need to license |- | services/glcdmenu/menu-interpreter/menu-interpreter-config.h || unknown || contacted 4.11.11, generated code - no need to license |- |} to find out all the authors of a certain file, run ''contrib/license-lister file'' . e.g. ''contrib/license-lister protocols/bootp/bootphdr.h'' * send an email to authors of source files with incompatible license == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD * Adam Dunkels' uIP Stack is licensed under the BSD http://en.wikipedia.org/wiki/UIP_(micro_IP) https://github.com/ethersex/ethersex/blob/master/protocols/uip/uip.c#L25 * MIT/X is compatible with GPLv3 ** http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing * reintegrate SD Reader library from http://www.roland-riegel.de/sd-reader/ ** done https://github.com/ethersex/ethersex/commit/0ba2a832b2f0e16e78cb26202b5e4fe4e266614b * reintegrate V-USB from http://www.obdev.at/products/vusb/download.html ** done https://github.com/ethersex/ethersex/commit/87c4d2b07c3939bf43779714d3b1cbcacd6848b3 7442ec4864431136f80dd23061641579ac78951e 396 379 2012-03-05T18:08:04Z Mgue 312 ST7626 wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or any other incompatible licesne. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or any other incompatible license. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || NO |- |Kunze, Erik || YES || YES || YES || YES || NO |- |Riegel, Roland || NO || NO || NO || NO || NO |- |} == Current TODO List == * collect files with incompatible license. {| border="1" ! File !! License !! Status |- | core/gui/font.c || 3-clause BSD || OK |- | core/host/host.h || unknown || OK empty file - does not need a license |- | core/host/util/crc16.h || no license, has to be 3-clause BSD || File is a partial copy of util/crc16.h, so we should use the 3-clause BSD for that file |- | core/setbaud.h || 3-clause BSD || removed - use utils/setbaud.h from avrlibc |- | hardware/ir/irmp/irmp_lib.c || GPLv2+ || OK |- | hardware/lcd/s1d15g10/bunnies.h || GPLv2+ assumed || OK |- | hardware/lcd/ST7626/4x6.h || GPLv3+ || not replied, OK - we can assume GPLv3+ because of ST7626.c |- | hardware/lcd/ST7626/ST7626.h || GPLv3+ || not replied, OK - we can assume GPLv3+ because of ST7626.c |- | hardware/sram/sram.h || GPLv2+ || OK - we can assume GPLv2+ because of sram.c |- | hardware/storage/sd_reader/byteordering.* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/fat* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/partition* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/sd_raw* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/sd-reader_config.h || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | protocols/bootp/bootphdr.h || MIT || OK |- | protocols/uip/uip-conf.h || BSD || OK - license and copyright disappeared with 7c2045a0b3e67b53a12e74a337abb124ee0c55bf |- | protocols/usb/usbconfig.h || GPLv2 or v3 || OK, see the included protocols/usb/usbdrv/License.txt |- | protocols/ustream/vs1053.c || unknown || contacted 4.11.11, replied - agreed on MIT |- | protocols/ustream/vs1053.h || unknown || contacted 4.11.11, replied - agreed on MIT |- | services/glcdmenu/menu-interpreter/menudata-progmem.c || unknown || contacted 4.11.11, generated code - no need to license |- | services/glcdmenu/menu-interpreter/menu-interpreter-config.h || unknown || contacted 4.11.11, generated code - no need to license |- |} to find out all the authors of a certain file, run ''contrib/license-lister file'' . e.g. ''contrib/license-lister protocols/bootp/bootphdr.h'' * send an email to authors of source files with incompatible license == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD * Adam Dunkels' uIP Stack is licensed under the BSD http://en.wikipedia.org/wiki/UIP_(micro_IP) https://github.com/ethersex/ethersex/blob/master/protocols/uip/uip.c#L25 * MIT/X is compatible with GPLv3 ** http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing * reintegrate SD Reader library from http://www.roland-riegel.de/sd-reader/ ** done https://github.com/ethersex/ethersex/commit/0ba2a832b2f0e16e78cb26202b5e4fe4e266614b * reintegrate V-USB from http://www.obdev.at/products/vusb/download.html ** done https://github.com/ethersex/ethersex/commit/87c4d2b07c3939bf43779714d3b1cbcacd6848b3 7b376fe4c0db6517e879bc45a629d857726c7257 0 50 380 184 2012-02-07T11:53:20Z GooPie4o 265 wikitext text/x-wiki {{i18n|Dachs MSR1}} {{Module |NAME=Dachs MSR1 |MENUCONFIG={{Protocols}}->Senertec Dachs MSR1 Support |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6= - |DEPENDS=[[ECMD]] |REQUIRES=freie USART |CODE=[https://github.com/ethersex/ethersex/tree/master/protocols/msr1 https://github.com/ethersex/ethersex/tree/master/protocols/msr1] }} Die Dachs MSR1 ist ein Klein-Blockheizkraftwerk (BHKW) der Firma [http://www.senertec.de SenerTec], das sowohl Wärme als auch Strom erzeugt. Über eine serielle Schnittstelle können Betriebs- und Wartungsdaten ausgelesen werden. Eine genauere Beschreibung des Protokolls gibts [[Dachs_MSR1_Service_Protokoll_(Deutsch)|hier]]. == Anschluss == [[File:Dachs_msr1_anschluss.png|thumb]] Obwohl sowohl das Ethersex, als auch die MSR1 einen Slave (Weiblich) RS232 Anschluss hat braucht man ein 1:1 Kabel. Außerdem muss das RTS Signal des MSR1 auf eine logische Null gelegt werden, da sich die MSR1 sonst nicht für irgendwelche Befehle interessiert. Dazu verwendet man am besten den zweiten Kanal des verbauten MAX232, legt den Eingang auf GND und greift die +10V am Ausgang ab. Ansonsten ist der RS232 Anschluss ein 9600 8N1. == Alternative Kabelbelegung == Im [http://www.bhkw-forum.de BHKW-Forum] gibt es noch eine alternative Kabelbelegung. Zu beachten ist nur, das man die Leitungen nicht kreuzen darf. (getestet mit dem AVR-Net-IO) [[Media:Kabelbelegung_Dachs_MRS1.pdf]] Die dort beschriebene Belegung ist also für PC->Dachs gedacht. Diese Variante funktioniert mit einem ethersex nur dann, wenn an der RS232 Buchse auch der RTS Kanal durch den MAX232 geschleift wird. (Und die Ethersexfirmware um RTS Handshaking erweitert wurde *huestel*) == Auslesen == Der MSR1 kann man zwei verschiedene Datensätze entlocken, den "0xe8"-Datensatz und den "0xc0"-Datensatz. Beide enthalten teilweise redundante Daten, wobei jedoch letzterer weitaus mehr Informationen bietet. Den 0xe8 Datensatz bekommt man mit dem ecmd `msr1 get' bzw. `msr1 get 0'. Das erste Byte gibt an, wieviele Anfragen seit dem letzten erfolgreichen Versuch fehlgeschlagen sind. Den 0xc0-Datensatz bekommt man über `msr1 get 1'. == Einbindung in den [[HTTPD]] == [[File:800px-Msr1_screenshot.png|600px]] │ │ Load a Default Configuration ---> │ │ ... │ │ General Setup ---> │ │ ... │ │ [*] VFS (Virtual File System) ---> │ │ [*] VFS File Inling │ │ [*] Inline MSR1 Unter '''$ethersexip/msr.ht''' kann nun der aktuelle Status des Dachs ausgelesen werden. = Programm Beispiele = == Abfrage in Perl == === e8 === '''Ein Beispiel wie die Werte e8 abgefragt und aufbereitet werden.''' <source lang="perl"> #!/usr/bin/perl -w # Abfrage der Dachs e8-Werte per esex # # kleines Beispielscript, das die e8 Wert abholt ud anschliesend aufbereitet # in Variabeln schreibt. # Das Script kann als Vorlage für eigene Entwicklungen benutzt werden. # # Autor: Lothar Schweikle-Droll # Lizenz: GPL use strict; use Net::Telnet (); my $debug=1; my $esex; my $esexip="192.168.255.90"; my $esexport="2701"; my $e8hex; my @e8hex; my $BETRIEBSSTUNDEN; my $WARTUNG; my $RL; my $VL; my $ABGAS; my $EINSCH_TEMP_SOL; my $BETRIEBSZUSTAND; my $BETRIEBSZUSTAND_SOL; my $GEN_LEISTUNG_SOL; my @SERVICE_CODE_MODUL; #Modul 0 = Leitregler my %BETRIEBSZUSTAND = ( 10=>'Störabschaltung', 11=>'Abschaltung MV1', 11=>'Abschaltung MV2', 13=>'Drehzahl<200 n. 25 sek.', 14=>'Drehzahl>200 n. 25 sek.', 15=>'Abschaltung>1 Minute', 16=>'Abschaltung>4 Minuten', 20=>'Startvorbereitung', 21=>'Starteinleitung', 22=>'Start', 23=>'1,5 sek. nach Start', 24=>'Startende', 30=>'450<Drehz<800', 32=>'Zuschaltung Generator', 33=>'Leistungsregelung runter', 34=>'Leistungsregelung hoch', 35=>'Betrieb'); my $non; &e8_esex; &wertezuweisung; ### Ab hier kann eigener Code stehen if ( $debug == 1){ &debug; } ##### Subrotinen sub e8_esex { #Dachs e8 abfrge per Telnet über den ethersex $esex = Net::Telnet->new || die "kann Ethersex nicht finden"; $esex->open(Host => $esexip, Port => $esexport, Timeout => 1); $esex->print("msr1 get 0"); ($non, $e8hex) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); #den String in ein Array wandeln @e8hex = $e8hex =~ /(..)/g; } sub wertezuweisung { $BETRIEBSSTUNDEN=hex($e8hex[1].$e8hex[2]); $WARTUNG=hex($e8hex[3]); #RL auf negative Temp prüfen if (hex($e8hex[4]) >128 ) { $RL=hex($e8hex[4])-255; }else{ $RL=hex($e8hex[4]); } #VL auf negative Temp prüfen if (hex($e8hex[5]) >128 ) { $VL=hex($e8hex[5])-255; }else{ $VL=hex($e8hex[5]); } $ABGAS=hex($e8hex[6])+15; $EINSCH_TEMP_SOL=hex($e8hex[7]); $BETRIEBSZUSTAND=$BETRIEBSZUSTAND{hex($e8hex[8])}; $GEN_LEISTUNG_SOL= sprintf("%.3f" , hex($e8hex[9])/34); #Sollwert Der Generatorleistung gerundet auf 3 Stellen nach dem Komma my $i=0; while ($i <=5 ) { $SERVICE_CODE_MODUL[$i]=hex($e8hex[$i+10]); $i++ } $BETRIEBSZUSTAND_SOL=hex($e8hex[16]); } sub debug { print "\n*********** DEBUG Start *************\n\n"; print "e8-Hexwert:","@e8hex","\n\n"; print "Betriebstundenb:\t",$BETRIEBSSTUNDEN,"\n"; print "Wartung:\t\t",$WARTUNG,"\n"; print "VL:\t\t\t",$VL,"\n"; print "RL:\t\t\t",$RL,"\n"; print "Abgas:\t\t\t",$ABGAS,"\n"; print "EINSCH_TEMP_SOL:\t",$EINSCH_TEMP_SOL,"\n"; print "Betriebszustand:\t",$BETRIEBSZUSTAND,"\n"; print "Generator Leitsung Sol:\t",$GEN_LEISTUNG_SOL,"\n"; print "BETRIEBSZUSTAND_SOL:\t",$BETRIEBSZUSTAND_SOL,"\n"; my $i=0; while ($i <=5 ) { #$SERVICE_CODE_MODUL[$i]=hex($e8sex[$i+10]); print "SERVICE_CODE_MODUL[".$i."]\t".$SERVICE_CODE_MODUL[$i],"\n"; $i++ } print "\n"; print "*********** DEBUG Ende **************\n\n"; } </source> === c0 === '''Ein Beispiel für die c0 Werte''' <source lang="perl"> #!/usr/bin/perl -w # Abfrage der Dachs c0-Werte per esex # # kleines Beispielscript, das die c0 Wert abholt ud anschliesend aufbereitet # in Variabeln schreibt. # Das Script kann als Vorlage für eigene Entwicklungen benutzt werden. # # Autor: Lothar Schweikle-Droll # Lizenz: GPL use strict; use Net::Telnet (); my $debug=1; my $esex; my $esexip="192.168.255.90"; my $esexport="2701"; my $c0hex1; my $c0hex2; my $c0hex3; my $c0hex4; my $c0hex; my @c0hex; my $WARTUNG; my $RL; my $VL; my $SRL; my $SVL; my $BETRIEBSSTUNDEN; my $ABGAS; my $AUSENTEMP; my $F1TEMP; my $F2TEMP; my $GENERTEMP; my $MOTORTEMP; my $SERVICECODE; my $BETRIEBSART; my $BHKW_FREIGABE; my $BRENNER_FREIGABE; my $DREHZAHL; my $ERZEUGTE_E_ENERGIE; my $ERZEUGT_WAERME; my $GEN_LEISTUNG; my $STARTS; my $non; &e8_esex; &wertezuweisung; ### Ab hier kann eigener Code stehen if ( $debug == 1){ &debug; } ##### Subrotinen sub e8_esex { #Dachs C0 abfrge per Telnet über den ethersex $esex = Net::Telnet->new || die "kann Ethersex nicht finden"; $esex->open(Host => $esexip, Port => $esexport, Timeout => 1); # $c0hex1=$esex->cmd('msr1 get 1'); $esex->print("msr1 get 1"); ($non, $c0hex1) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $c0hex2) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $c0hex3) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $c0hex4) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); $c0hex = ($c0hex1).($c0hex2).($c0hex3).($c0hex4); #die vier Einzelwerte zu einem gesamt String zusammensetzen @c0hex = $c0hex =~ /(..)/g; #Den String in eine Array schreiben (nur die HEX-Werte ohne Leerstellen } sub wertezuweisung { $BETRIEBSSTUNDEN=hex($c0hex[19].$c0hex[20]); $WARTUNG=$c0hex[3]; #RL auf negative Temp prüfen if (hex($c0hex[22]) >128 ) { $RL=hex($c0hex[22])-255; }else{ $RL=hex($c0hex[22]); } $SRL=hex($c0hex[21]); #VL auf negative Temp prüfen if (hex($c0hex[24]) >128 ) { $VL=hex($c0hex[24])-255; }else{ $VL=hex($c0hex[24]); } $SVL=hex($c0hex[23]); #Ausentemp auf negative Temp prüfen if (hex($c0hex[25]) >128 ) { $AUSENTEMP=hex($c0hex[25])-255; }else{ $AUSENTEMP=hex($c0hex[25]); } #F1 und F2 auf negative Temp prüfen if (hex($c0hex[26]) >128 ) { $F1TEMP=hex($c0hex[26])-255; }else{ $F1TEMP=hex($c0hex[26]); } if (hex($c0hex[27]) >128 ) { $F2TEMP=hex($c0hex[27])-255; }else{ $F2TEMP=hex($c0hex[27]); } $GENERTEMP=hex($c0hex[28]); $SERVICECODE=hex($c0hex[30]); $BETRIEBSART=$c0hex[31]; $BHKW_FREIGABE=hex($c0hex[32]); $BRENNER_FREIGABE=hex($c0hex[33]); $MOTORTEMP=hex($c0hex[34]); $ABGAS=hex($c0hex[35])+15; $DREHZAHL=hex($c0hex[36].$c0hex[37]); $ERZEUGTE_E_ENERGIE=hex($c0hex[38].$c0hex[39].$c0hex[40].$c0hex[41]); $ERZEUGT_WAERME=hex($c0hex[42].$c0hex[43].$c0hex[44].$c0hex[45]); $GEN_LEISTUNG=sprintf("%.3f" , hex($c0hex[46])/34); #Sollwert Der Generatorleistung gerundet auf 3 Stellen nach dem Komma $STARTS=hex($c0hex[47].$c0hex[48]); } sub debug { print "\n*********** DEBUG Start *************\n\n"; print "c0-Hexwert:","@c0hex","\n\n"; print "Betriebstunden:\t\t",$BETRIEBSSTUNDEN,"\n"; print "Wartung:\t\t",$WARTUNG,"\n"; print "VL:\t\t\t",$VL,"\n"; print "RL:\t\t\t",$RL,"\n"; print "F1:\t\t\t",$F1TEMP,"\n"; print "F2:\t\t\t",$F2TEMP,"\n"; print "VL Soll:\t\t",$SVL,"\n"; print "RL Soll:\t\t",$SRL,"\n"; print "Ausen:\t\t\t",$AUSENTEMP,"\n"; print "Generator Temp:\t\t",$GENERTEMP,"\n"; print "Servicecode:\t\t",$SERVICECODE,"\n"; print "Betreibsart:\t\t",$BETRIEBSART,"\n"; print "BHKW Freigabe:\t\t",$BHKW_FREIGABE,"\n"; print "Brenner Freigabe:\t",$BRENNER_FREIGABE,"\n"; print "Motor Temp:\t\t",$MOTORTEMP,"\n"; print "Abgas:\t\t\t",$ABGAS,"\n"; print "Drehzahl:\t\t",$DREHZAHL,"\n"; print "erzeugte E-Energie:\t",$ERZEUGTE_E_ENERGIE,"\n"; print "erzeugte Wärme:\t\t",$ERZEUGT_WAERME,"\n"; print "Generator ist:\t\t",$GEN_LEISTUNG,"\n"; print "Startvorgang:\t\t",$STARTS,"\n"; print "\n"; print "*********** DEBUG Ende **************\n\n"; } </source> === 48 === '''Ein Beispiel für die 48 Werte''' <source lang="perl"> #!/usr/bin/perl -w # Abfrage der Dachs 48-Werte per esex # # kleines Beispielscript, das die 48 Wert abholt ud anschliesend aufbereitet # in Variabeln schreibt. # Das Script kann als Vorlage für eigene Entwicklungen benutzt werden. # # Autor: Lothar Schweikle-Droll # Lizenz: GPL use strict; use Net::Telnet (); my $debug=1; my $esex; my $esexip="192.168.255.90"; my $esexport="2701"; my $x48hex1; my $x48hex2; my $x48hex3; my $x48hex4; my $x48hex; my @x48hex; my $WARTUNG; my $BETRIEBSSTUNDEN; my $MAXABGAS; my $VL; my $STOERUNGEN; my $F1TEMP; my $F2TEMP; my $MAXGENERTEMP; my $MAXMOTORTEMP; my $STARTS; my $MITTELGENLEISTUNG; my $FLUESSIGKEITSCHALTER; my $LETZTEWARTUNG; my $NAECHSTEWARTUNGOEL; my $NAECHSTEWARTUNGGAS; my @FEHLERCODE; #000-127 my @FEHLERAUTO; #1=Autoentstörung my @FEHLERCODELANG; my @FEHLERMIN; my @FEHLERSTUNDEN; my @FEHLERTAG; my @FEHLERMON; my @FEHLERJAHR; my @FEHLERDATUM; my $non; my %Servicecode = ( 0=>'Allgemeine Hilfe', 1=>'Abgasfühler U/K', 2=>'Kuehlw.Motor U/K', 3=>'Kuehlw.Gener. U/K', 4=>'04', 5=>'Vorlauftemp. U/K', 6=>'Ruecklauftemp U/K', 7=>'Fuehler 1 U/K', 8=>'Fuehler 2 U/K', 9=>'Aussentemp. U/K', 10=>'Fluessigkeit. U/K', 11=>'11', 11=>'12', 13=>'13', 14=>'14', 15=>'15', 16=>'16', 17=>'17', 18=>'18', 19=>'19', 20=>'Abgas Motor zu hoch', 21=>'21', 22=>'Kuehlw. Motor > 95 C', 23=>'Abgastemp. zu hoch', 24=>'Kuehlw. Generator > 77 C', 25=>'25', 26=>'2h Vorlauft < Soll', 27=>'27', 28=>'28', 29=>'UP:Rueckleistung', 30=>'30', 31=>'HKA-Anl. < 100 U/min', 32=>'32', 33=>'HKA-Lauf < 2300 U/m', 34=>'34', 35=>'35', 36=>'36', 37=>'37', 38=>'38', 39=>'Generatorzuschalt', 40=>'Generatorabschalt', 41=>'Generator fehlt', 42=>'kein Text', 43=>'kein Text', 44=>'1h Si-Kette offen', 45=>'kein Text', 46=>'kein Text', 47=>'kein Text', 48=>'UP/LP:Int. b. Start', 49=>'UP: Intern', 50=>'UP/LP: Intern', 51=>'UP:Startfreigabe', 52=>'UP:Datentransfer', 53=>'UP:keine Daten', 54=>'kein Text', 55=>'kein Text', 56=>'UP:Messk Drehzahl', 56=>'kein Text', 57=>'kein Text', 58=>'kein Text', 59=>'UP:Spannung b.St.', 60=>'UP: Spannung', 61=>'kein Text', 62=>'Leistung zu hoch', 63=>'Leistung zu klein', 64=>'Leistung im Stand', 65=>'kein Text', 66=>'ENS-3 Abschaltung', 67=>'UP:Frequenz b.St', 68=>'UP:Frequenz', 69=>'UP:Phasen', 70=>'kein Text', 71=>'Oeldruckschalter', 72=>'Oeldruckmangel', 73=>'MV/Hubmag.undicht', 74=>'MV/Hubmag.undicht', 75=>'kein Text', 76=>'Programmdurchlauf', 77=>'kein Text', 78=>'kein Text', 79=>'4 Starts < 2300 U/m', 80=>'kein Text', 81=>'kein Text', 82=>'kein Text', 83=>'kein Text', 84=>'UP:Drehfeld', 85=>'Fluessigkeitssch', 86=>'UP: Zuendaussetzer', 87=>'Drehz. > 3300 U/min', 88=>'4 Starts 400-800U/m', 89=>'4Starts < 400 U/min', 90=>'kein Text', 91=>'UP:Drehz > 3500 U/m', 92=>'UP:verriegelt', 93=>'UP/RP-Prog.falsch', 94=>'kein Text', 95=>'No ClkRAM Kommuni', 96=>'No Ack-w I2C-Bus', 97=>'No Ack-r I2C-Bus', 98=>'Clk_RAM write nOK', 99=>'UP:Flags'); &x48_esex; &wertezuweisung; ### Ab hier kann eigener Code stehen if ( $debug == 1){ &debug; } ##### Subrotinen sub x48_esex { #Dachs 48 abfrge per Telnet über den ethersex $esex = Net::Telnet->new || die "kann Ethersex nicht finden"; $esex->open(Host => $esexip, Port => $esexport, Timeout => 1); # $x48hex1=$esex->cmd('msr1 get 1'); $esex->print("msr1 get 2"); ($non, $x48hex1) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $x48hex2) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $x48hex3) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $x48hex4) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); $x48hex = ($x48hex1).($x48hex2).($x48hex3).($x48hex4); #die vier Einzelwerte zu einem gesamt String zusammensetzen @x48hex = $x48hex =~ /(..)/g; #Den String in eine Array schreiben (nur die HEX-Werte ohne Leerstellen } sub wertezuweisung { $BETRIEBSSTUNDEN=hex($x48hex[1].$x48hex[2]); $STARTS=hex($x48hex[3].$x48hex[4]); $MAXABGAS=hex($x48hex[5])+15; $MAXGENERTEMP=hex($x48hex[7]); $MAXMOTORTEMP=hex($x48hex[6]); #MAXVL auf negative Temp prüfen if (hex($x48hex[8]) >128 ) { $VL=hex($x48hex[8])-255; }else{ $VL=hex($x48hex[8]); } #Max F1 und F2 auf negative Temp prüfen if (hex($x48hex[9]) >128 ) { $F1TEMP=hex($x48hex[9])-255; }else{ $F1TEMP=hex($x48hex[9]); } if (hex($x48hex[10]) >128 ) { $F2TEMP=hex($x48hex[10])-255; }else{ $F2TEMP=hex($x48hex[10]); } $MITTELGENLEISTUNG=(7.5 / 255 * hex($x48hex[11])); $STOERUNGEN=hex($x48hex[12]); $FLUESSIGKEITSCHALTER=hex($x48hex[55]); $LETZTEWARTUNG=hex($x48hex[59].$x48hex[60]); $NAECHSTEWARTUNGOEL=hex($x48hex[59].$x48hex[60])+2700; $NAECHSTEWARTUNGGAS=hex($x48hex[59].$x48hex[60])+3500; #Fehler Code zuweisen for ($non=1;$non<=7;$non++) { $FEHLERCODE[$non]=hex($x48hex[7+(6*$non)]); $FEHLERAUTO[$non]="0"; if ( $FEHLERCODE[$non] > 127 ) { $FEHLERCODE[$non]=$FEHLERCODE[$non]-128; $FEHLERAUTO[$non]="1"; } $FEHLERCODELANG[$non]=$Servicecode{$FEHLERCODE[$non]}; $FEHLERSTUNDEN[$non]=hex($x48hex[9+(6*$non)]); if ( $FEHLERSTUNDEN[$non]=~ /^[0-9]$/ ) { $FEHLERSTUNDEN[$non]='0'.$FEHLERSTUNDEN[$non]; } $FEHLERMIN[$non]=hex($x48hex[8+(6*$non)]); if ( $FEHLERMIN[$non]=~ /^[0-9]$/ ) { $FEHLERMIN[$non]='0'.$FEHLERMIN[$non]; } $FEHLERTAG[$non]=hex($x48hex[10+(6*$non)]); if ( $FEHLERTAG[$non]=~ /^[0-9]$/ ) { $FEHLERTAG[$non]='0'.$FEHLERTAG[$non]; } $FEHLERMON[$non]=hex($x48hex[11+(6*$non)]); if ( $FEHLERMON[$non]=~ /^[0-9]$/ ) { $FEHLERMON[$non]='0'.$FEHLERMON[$non]; } $FEHLERJAHR[$non]=hex($x48hex[12+(6*$non)]); if ( $FEHLERJAHR[$non]=~ /^[0-9]$/ ) { $FEHLERJAHR[$non]='0'.$FEHLERJAHR[$non]; } $FEHLERDATUM[$non]=$FEHLERSTUNDEN[$non].":".$FEHLERMIN[$non]." ".$FEHLERTAG[$non].".".$FEHLERMON[$non].".".$FEHLERJAHR[$non]; #Deutsch ohne Sekunden $FEHLERDATUM[$non]=$FEHLERJAHR[$non]."-".$FEHLERMON[$non]."-".$FEHLERTAG[$non]." ".$FEHLERSTUNDEN[$non].":".$FEHLERMIN[$non].":30"; #International mit gemittelte Sekunden #print "HEXzahl: ".(7 + (6 * $non))."\n"; } } sub debug { print "\n*********** DEBUG Start *************\n\n"; print "48-Hexwert:","@x48hex","\n\n"; print "Betriebstunden:\t\t",$BETRIEBSSTUNDEN,"\n"; print "Letzte Wartung:\t\t",$LETZTEWARTUNG,"\n"; print "Wartung bei Öl (alle 2700h):\t",$NAECHSTEWARTUNGOEL,"\n"; print "Wartung bei Gas (alle 3500h):\t",$NAECHSTEWARTUNGGAS,"\n"; print "Starts:\t\t\t",$STARTS,"\n"; print "MAX Abgas:\t\t",$MAXABGAS,"\n"; print "MAX Gen Temp:\t\t",$MAXGENERTEMP,"\n"; print "MAX Mot Temp:\t\t",$MAXMOTORTEMP,"\n"; print "Max VL:\t\t\t",$VL,"\n"; print "Max F1:\t\t\t",$F1TEMP,"\n"; print "Max F2:\t\t\t",$F2TEMP,"\n"; print "Mittlere Gen Leistung:\t",$MITTELGENLEISTUNG,"\n"; print "Anzahl Störungen:\t",$STOERUNGEN,"\n"; print "Fluessigkeitsschalter:\t",$FLUESSIGKEITSCHALTER,"\n\n"; print "Fehlerpeicher\n"; print "=============\n"; for ($non=1;$non<=7;$non++) { print "Fehler: ".$non."\n"; print "Fehlercode: ".$FEHLERCODE[$non]."\n"; print "Autoentstörung: ".$FEHLERAUTO[$non]."\n"; print "Zeit: ".$FEHLERSTUNDEN[$non].":".$FEHLERMIN[$non]." ".$FEHLERTAG[$non].".".$FEHLERMON[$non].".".$FEHLERJAHR[$non]."\n"; print "Datum: ".$FEHLERDATUM[$non]."\n"; print "Langtext: ".$FEHLERCODELANG[$non]."\n\n"; } print "\n"; print "*********** DEBUG Ende **************\n\n"; } </source> === 50 === '''Ein Beispiel für die 50 Werte''' <source lang="perl"> #!/usr/bin/perl -w # Abfrage der Dachs 50-Werte per esex # # kleines Beispielscript, das die 50 Wert abholt ud anschliesend aufbereitet # in Variabeln schreibt. # Das Script kann als Vorlage für eigene Entwicklungen benutzt werden. # # Autor: Lothar Schweikle-Droll # Lizenz: GPL use strict; use constant PI => 4 * atan2(1, 1); #Wegen cosph Berechnung use Net::Telnet (); my $debug=1; my $esex; my $esexip="192.168.255.90"; my $esexport="2701"; my $x50hex1; my $x50hex2; my $x50hex3; my $x50hex4; my $x50hex; my @x50hex; my $RL; my $VL; my $MOTORTEMP; my $ABGAS; my $AUSENTEMP; my $F1TEMP; my $F2TEMP; my $GENERTEMP; my $DREHZAHL; my $BIVAL_UMSCHALT_TMP; my $BIVAL_UMSCHALT_ZEIT; my $SERVICE; my $UMWALZPUMPESTATUS1; my $UMWALZPUMPESTATUS2; my $U1; my $U2; my $U3; my $I1; my $I2; my $I3; my $COSPHI; my $UE_PLATINE; my $non; &e8_esex; &wertezuweisung; ### Ab hier kann eigener Code stehen if ( $debug == 1){ &debug; } ##### Subrotinen sub e8_esex { #Dachs C0 abfrge per Telnet über den ethersex $esex = Net::Telnet->new || die "kann Ethersex nicht finden"; $esex->open(Host => $esexip, Port => $esexport, Timeout => 1); # $x50hex1=$esex->cmd('msr1 get 1'); $esex->print("msr1 get 3"); ($non, $x50hex1) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $x50hex2) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $x50hex3) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); ($non, $x50hex4) = $esex->waitfor(Timeout => 1, Match =>'/[0-9A-Fa-f]+/'); $x50hex = ($x50hex1).($x50hex2).($x50hex3).($x50hex4); #die vier Einzelwerte zu einem gesamt String zusammensetzen @x50hex = $x50hex =~ /(..)/g; #Den String in eine Array schreiben (nur die HEX-Werte ohne Leerstellen } sub wertezuweisung { #VL auf negative Temp prüfen if (hex($x50hex[1]) >128 ) { $VL=hex($x50hex[1])-255; }else{ $VL=hex($x50hex[1]); } #RL auf negative Temp prüfen if (hex($x50hex[2]) >128 ) { $RL=hex($x50hex[2])-255; }else{ $RL=hex($x50hex[2]); } $MOTORTEMP=hex($x50hex[3]); $ABGAS=hex($x50hex[4])+15; #Ausentemp auf negative Temp prüfen if (hex($x50hex[5]) >128 ) { $AUSENTEMP=hex($x50hex[5])-255; }else{ $AUSENTEMP=hex($x50hex[5]); } #F1 und F2 auf negative Temp prüfen if (hex($x50hex[6]) >128 ) { $F1TEMP=hex($x50hex[6])-255; }else{ $F1TEMP=hex($x50hex[6]); } if (hex($x50hex[7]) >128 ) { $F2TEMP=hex($x50hex[7])-255; }else{ $F2TEMP=hex($x50hex[7]); } $GENERTEMP=hex($x50hex[8]); $ABGAS=hex($x50hex[4])+15; $DREHZAHL=hex($x50hex[10].$x50hex[11]); $BIVAL_UMSCHALT_TMP=hex($x50hex[13]); $BIVAL_UMSCHALT_ZEIT=hex($x50hex[14].$x50hex[15]); #Wert in Minuten $SERVICE=hex($x50hex[16]); $UMWALZPUMPESTATUS1=hex($x50hex[21]); $UMWALZPUMPESTATUS2=hex($x50hex[21]); $U1=105.6 + (100.0 / 461) * (hex($x50hex[31].$x50hex[32])); #105.6V + (100.0 /0x1cd) * Wert $U2=314.4 - (100.0 / 461) * (hex($x50hex[33].$x50hex[34])); #314.4V - (100.0 /0x1cd) * Wert $U3=105.6 + (100.0 / 461) * (hex($x50hex[35].$x50hex[36])); #105.6V + (100.0 /0x1cd) * Wert $I1=hex($x50hex[37].$x50hex[38]) * (10.0 / 461) - (10.0 * 205) / 461 ; #Wert * (10.0A /0x1cd) - (10.0*0xcd)/0x1cd $I2=hex($x50hex[39].$x50hex[40]) * (10.0 / 461) - (10.0 * 205) / 461; #Wert * (10.0A /0x1cd) - (10.0*0xcd)/0x1cd $I3=10.0 / 461 * (757 - (hex($x50hex[41].$x50hex[42]))); #10.0A/0x1cd * (0x02f5 - Wert) #$x50hex[43]='C9'; $COSPHI=abs( cos(((hex($x50hex[43]))-128)*PI/180) ); if (hex($x50hex[45]) >= 253 ) { $UE_PLATINE='ok'; }else{ $UE_PLATINE='error'; } } sub debug { print "\n*********** DEBUG Start *************\n\n"; print "50-Hexwert:","@x50hex","\n\n"; print "VL:\t\t\t",$VL,"\n"; print "RL:\t\t\t",$RL,"\n"; print "Motor Temp:\t\t",$MOTORTEMP,"\n"; print "Abgas:\t\t\t",$ABGAS,"\n"; print "F1:\t\t\t",$F1TEMP,"\n"; print "F2:\t\t\t",$F2TEMP,"\n"; print "Generator Temp:\t\t",$GENERTEMP,"\n"; print "Drehzahl:\t\t",$DREHZAHL,"\n"; print "BIVAL_UMSCHALT_TMP:\t",$BIVAL_UMSCHALT_TMP,"\n"; print "BIVAL_UMSCHALT_ZEIT:\t",$BIVAL_UMSCHALT_ZEIT,"\n"; print "U1:\t\t\t",$U1," ",hex($x50hex[31].$x50hex[32]),"\n"; print "U2:\t\t\t",$U2," ",hex($x50hex[33].$x50hex[34]),"\n"; print "U3:\t\t\t",$U3," ",hex($x50hex[35].$x50hex[36]),"\n"; print "I1:\t\t\t",$I1," ",hex($x50hex[37].$x50hex[38]),"\n"; print "I2:\t\t\t",$I2," ",hex($x50hex[39].$x50hex[40]),"\n"; print "I3:\t\t\t",$I3," ",hex($x50hex[41].$x50hex[42]),"\n"; print "COSPHI:\t\t\t",$COSPHI," ",hex($x50hex[43]),"\n"; print "UE_PLATINE:\t\t",$UE_PLATINE," ",hex($x50hex[45]),"\n"; print "UMWALZPUMPESTATUS1:\t",$UMWALZPUMPESTATUS1,"\n"; print "UMWALZPUMPESTATUS2:\t",$UMWALZPUMPESTATUS2,"\n"; print "\n"; print "*********** DEBUG Ende **************\n\n"; } </source> [[Category:Ethersex]] [[Category:Home-Visualisierung]] [[Category:MSR1]] 63774d2794e67526816674b628ddeb7fb613e328 1 81 381 227 2012-02-07T11:55:02Z GooPie4o 265 wikitext text/x-wiki well, i would share the perl source code via an attached file f562dba59d586264cac0b5adbf32de5f4a5a3112 0 154 382 2012-02-09T06:47:21Z Loddel 64 Created page with "= Protokolle duplizieren = Es kommt immer mal wider vor, das man das gleiche Protokoll zweimal benötigt. Bei mir war der Fall, das ich ein Net-IO mit einem ATMega 644p ausgestat…" wikitext text/x-wiki = Protokolle duplizieren = Es kommt immer mal wider vor, das man das gleiche Protokoll zweimal benötigt. Bei mir war der Fall, das ich ein Net-IO mit einem ATMega 644p ausgestattet habe, der zwei UART besitz. Diese zwei Schnittstellen wollte ich zum auslesen meiner Wechselrichter nutzen. Das Protokoll der Wahl war bei mir sll (serial_line_log) Leider muste ich feststellen, das ich immer nur ein Protokoll auf ein UART binden kann. Da es bist jetzt noch keine gute Idee gibt, wie man so etwas besser lösen kann, hier ein kleiner Trick. Das Protokoll serial_line_log wird einfach dupliziert. Ich habe jedes "seria_" in ein "serialzwei_" gewandelt. * Kopieren des Ordners (cp -a ethersex/protocols/serial_line_log ethersex/protocols/serialzwei_line_log) * alle Dateien im Ordner umbenannt (auser Makefile und config.in) (cd ethersex/protocols/serialzwei_line_log; mv serial_<...>.c serialzwei_<...>.c * mit einem Editor Alle Variabeln und Symbolenamen geändert <code> vim serialzwei_line_log.c :%s/SERIAL_/SERIALZWEI_/g :%s/serial_/serialzwei_/g :%s/sll_/sllzwei_/g </code> * in der serialzwei_line_log_ecmd.c muss noch der ecmd Befehl angepasst werden (ganz am Schluss der META abschnitt) <code> vim serialzwei_line_log_ecmd.c :%s/sll get/sll2 get </code> * die config.in und das MAKEFILE an die neuen Namen anpassen Zum Schluss müssen noch zwei zentrale Dateien angepasst werden. <code> cd ethersex/ vim Makefile SUBDIRS += protocols/serialzwei_line_log </code> <code> vim config.in source protocols/serialzwei_line_log/config.in </code> Danach sollte <code> make menuconfig </code> Jetzt sollte unter Protokolle das Serial Line Log zweimal vorhanden sein. Anmerkung: Das gleiche Verfahren funktioniert auch mit dem yport-Protokoll. Wenn man z.B. einen ATMega644p besitzt und beide UARTs "gleichzeitig" benutzen will, kann man das yport-Protokoll mit dem hier vorgestellten Verfahren duplizieren. nc <ip> 7970 bzw nc <ip> 7971 liefert dann die Ausgabe der beiden Ports. f53f92423e098303a415f0d8fa079c760684593a 383 382 2012-02-09T07:22:19Z GooPie4o 265 moved [[Protokolle duplizieren]] to [[Protokolle duplizieren (Deutsch)]]:&#32;I18N wikitext text/x-wiki = Protokolle duplizieren = Es kommt immer mal wider vor, das man das gleiche Protokoll zweimal benötigt. Bei mir war der Fall, das ich ein Net-IO mit einem ATMega 644p ausgestattet habe, der zwei UART besitz. Diese zwei Schnittstellen wollte ich zum auslesen meiner Wechselrichter nutzen. Das Protokoll der Wahl war bei mir sll (serial_line_log) Leider muste ich feststellen, das ich immer nur ein Protokoll auf ein UART binden kann. Da es bist jetzt noch keine gute Idee gibt, wie man so etwas besser lösen kann, hier ein kleiner Trick. Das Protokoll serial_line_log wird einfach dupliziert. Ich habe jedes "seria_" in ein "serialzwei_" gewandelt. * Kopieren des Ordners (cp -a ethersex/protocols/serial_line_log ethersex/protocols/serialzwei_line_log) * alle Dateien im Ordner umbenannt (auser Makefile und config.in) (cd ethersex/protocols/serialzwei_line_log; mv serial_<...>.c serialzwei_<...>.c * mit einem Editor Alle Variabeln und Symbolenamen geändert <code> vim serialzwei_line_log.c :%s/SERIAL_/SERIALZWEI_/g :%s/serial_/serialzwei_/g :%s/sll_/sllzwei_/g </code> * in der serialzwei_line_log_ecmd.c muss noch der ecmd Befehl angepasst werden (ganz am Schluss der META abschnitt) <code> vim serialzwei_line_log_ecmd.c :%s/sll get/sll2 get </code> * die config.in und das MAKEFILE an die neuen Namen anpassen Zum Schluss müssen noch zwei zentrale Dateien angepasst werden. <code> cd ethersex/ vim Makefile SUBDIRS += protocols/serialzwei_line_log </code> <code> vim config.in source protocols/serialzwei_line_log/config.in </code> Danach sollte <code> make menuconfig </code> Jetzt sollte unter Protokolle das Serial Line Log zweimal vorhanden sein. Anmerkung: Das gleiche Verfahren funktioniert auch mit dem yport-Protokoll. Wenn man z.B. einen ATMega644p besitzt und beide UARTs "gleichzeitig" benutzen will, kann man das yport-Protokoll mit dem hier vorgestellten Verfahren duplizieren. nc <ip> 7970 bzw nc <ip> 7971 liefert dann die Ausgabe der beiden Ports. f53f92423e098303a415f0d8fa079c760684593a 385 383 2012-02-09T07:23:26Z GooPie4o 265 wikitext text/x-wiki {{i18n|Quick Start Guide}} = Protokolle duplizieren = Es kommt immer mal wider vor, das man das gleiche Protokoll zweimal benötigt. Bei mir war der Fall, das ich ein Net-IO mit einem ATMega 644p ausgestattet habe, der zwei UART besitz. Diese zwei Schnittstellen wollte ich zum auslesen meiner Wechselrichter nutzen. Das Protokoll der Wahl war bei mir sll (serial_line_log) Leider muste ich feststellen, das ich immer nur ein Protokoll auf ein UART binden kann. Da es bist jetzt noch keine gute Idee gibt, wie man so etwas besser lösen kann, hier ein kleiner Trick. Das Protokoll serial_line_log wird einfach dupliziert. Ich habe jedes "seria_" in ein "serialzwei_" gewandelt. * Kopieren des Ordners (cp -a ethersex/protocols/serial_line_log ethersex/protocols/serialzwei_line_log) * alle Dateien im Ordner umbenannt (auser Makefile und config.in) (cd ethersex/protocols/serialzwei_line_log; mv serial_<...>.c serialzwei_<...>.c * mit einem Editor Alle Variabeln und Symbolenamen geändert <code> vim serialzwei_line_log.c :%s/SERIAL_/SERIALZWEI_/g :%s/serial_/serialzwei_/g :%s/sll_/sllzwei_/g </code> * in der serialzwei_line_log_ecmd.c muss noch der ecmd Befehl angepasst werden (ganz am Schluss der META abschnitt) <code> vim serialzwei_line_log_ecmd.c :%s/sll get/sll2 get </code> * die config.in und das MAKEFILE an die neuen Namen anpassen Zum Schluss müssen noch zwei zentrale Dateien angepasst werden. <code> cd ethersex/ vim Makefile SUBDIRS += protocols/serialzwei_line_log </code> <code> vim config.in source protocols/serialzwei_line_log/config.in </code> Danach sollte <code> make menuconfig </code> Jetzt sollte unter Protokolle das Serial Line Log zweimal vorhanden sein. Anmerkung: Das gleiche Verfahren funktioniert auch mit dem yport-Protokoll. Wenn man z.B. einen ATMega644p besitzt und beide UARTs "gleichzeitig" benutzen will, kann man das yport-Protokoll mit dem hier vorgestellten Verfahren duplizieren. nc <ip> 7970 bzw nc <ip> 7971 liefert dann die Ausgabe der beiden Ports. 26af294e1a83a53f90226797db4e4ecbec65cfbe 386 385 2012-02-09T07:27:21Z GooPie4o 265 wikitext text/x-wiki {{i18n|Protokolle duplizieren}} = Protokolle duplizieren = Es kommt immer mal wider vor, das man das gleiche Protokoll zweimal benötigt. Bei mir war der Fall, das ich ein Net-IO mit einem ATMega 644p ausgestattet habe, der zwei UART besitz. Diese zwei Schnittstellen wollte ich zum auslesen meiner Wechselrichter nutzen. Das Protokoll der Wahl war bei mir sll (serial_line_log) Leider muste ich feststellen, das ich immer nur ein Protokoll auf ein UART binden kann. Da es bist jetzt noch keine gute Idee gibt, wie man so etwas besser lösen kann, hier ein kleiner Trick. Das Protokoll serial_line_log wird einfach dupliziert. Ich habe jedes "seria_" in ein "serialzwei_" gewandelt. * Kopieren des Ordners (cp -a ethersex/protocols/serial_line_log ethersex/protocols/serialzwei_line_log) * alle Dateien im Ordner umbenannt (auser Makefile und config.in) (cd ethersex/protocols/serialzwei_line_log; mv serial_<...>.c serialzwei_<...>.c * mit einem Editor Alle Variabeln und Symbolenamen geändert <code> vim serialzwei_line_log.c :%s/SERIAL_/SERIALZWEI_/g :%s/serial_/serialzwei_/g :%s/sll_/sllzwei_/g </code> * in der serialzwei_line_log_ecmd.c muss noch der ecmd Befehl angepasst werden (ganz am Schluss der META abschnitt) <code> vim serialzwei_line_log_ecmd.c :%s/sll get/sll2 get </code> * die config.in und das MAKEFILE an die neuen Namen anpassen Zum Schluss müssen noch zwei zentrale Dateien angepasst werden. <code> cd ethersex/ vim Makefile SUBDIRS += protocols/serialzwei_line_log </code> <code> vim config.in source protocols/serialzwei_line_log/config.in </code> Danach sollte <code> make menuconfig </code> Jetzt sollte unter Protokolle das Serial Line Log zweimal vorhanden sein. Anmerkung: Das gleiche Verfahren funktioniert auch mit dem yport-Protokoll. Wenn man z.B. einen ATMega644p besitzt und beide UARTs "gleichzeitig" benutzen will, kann man das yport-Protokoll mit dem hier vorgestellten Verfahren duplizieren. nc <ip> 7970 bzw nc <ip> 7971 liefert dann die Ausgabe der beiden Ports. 4094fef013ece408e988bcef77afb5c64eed41db 387 386 2012-02-09T07:27:41Z Loddel 64 wikitext text/x-wiki {{i18n|Protokolle duplizieren}} = Protokolle duplizieren = Es kommt immer mal wider vor, das man das gleiche Protokoll zweimal benötigt. Bei mir war der Fall, das ich ein Net-IO mit einem ATMega 644p ausgestattet habe, der zwei UART besitz. Diese zwei Schnittstellen wollte ich zum auslesen meiner Wechselrichter nutzen. Das Protokoll der Wahl war bei mir sll (serial_line_log) Leider muste ich feststellen, das ich immer nur ein Protokoll auf ein UART binden kann. Da es bist jetzt noch keine gute Idee gibt, wie man so etwas besser lösen kann, hier ein kleiner Trick. Das Protokoll serial_line_log wird einfach dupliziert. Ich habe jedes "seria_" in ein "serialzwei_" gewandelt. * Kopieren des Ordners (cp -a ethersex/protocols/serial_line_log ethersex/protocols/serialzwei_line_log) * alle Dateien im Ordner umbenannt (auser Makefile und config.in) (cd ethersex/protocols/serialzwei_line_log; mv serial_<...>.c serialzwei_<...>.c * mit einem Editor Alle Variabeln und Symbolenamen geändert <code> vim serialzwei_line_log.c :%s/SERIAL_/SERIALZWEI_/g :%s/serial_/serialzwei_/g :%s/sll_/sllzwei_/g </code> * in der serialzwei_line_log_ecmd.c muss noch der ecmd Befehl angepasst werden (ganz am Schluss der META abschnitt) <code> vim serialzwei_line_log_ecmd.c :%s/sll get/sll2 get </code> * in der protocols/serialzwei_line_log/config.in die Namen anpassen <code> vim config.in :%s/LINE_/LINE2_/g :%s/Line/Line2/g </code> * die ethersex/config.in und das MAKEFILE an die neuen Namen anpassen Zum Schluss müssen noch zwei zentrale Dateien angepasst werden. <code> cd ethersex/ vim Makefile SUBDIRS += protocols/serialzwei_line_log </code> <code> vim config.in source protocols/serialzwei_line_log/config.in </code> Danach sollte <code> make menuconfig </code> Jetzt sollte unter Protokolle das Serial Line Log zweimal vorhanden sein. Anmerkung: Das gleiche Verfahren funktioniert auch mit dem yport-Protokoll. Wenn man z.B. einen ATMega644p besitzt und beide UARTs "gleichzeitig" benutzen will, kann man das yport-Protokoll mit dem hier vorgestellten Verfahren duplizieren. nc <ip> 7970 bzw nc <ip> 7971 liefert dann die Ausgabe der beiden Ports. 63019584f328577028c400b5f78ffa59df0a786d 388 387 2012-02-09T08:21:35Z Loddel 64 wikitext text/x-wiki {{i18n|Protokolle duplizieren}} = Protokolle duplizieren = Es kommt immer mal wider vor, das man das gleiche Protokoll zweimal benötigt. Bei mir war der Fall, das ich ein Net-IO mit einem ATMega 644p ausgestattet habe, der zwei UART besitz. Diese zwei Schnittstellen wollte ich zum auslesen meiner Wechselrichter nutzen. Das Protokoll der Wahl war bei mir sll (serial_line_log) Leider muste ich feststellen, das ich immer nur ein Protokoll auf ein UART binden kann. Da es bist jetzt noch keine gute Idee gibt, wie man so etwas besser lösen kann, hier ein kleiner Trick. Das Protokoll serial_line_log wird einfach dupliziert. Ich habe jedes "seria_" in ein "serialzwei_" gewandelt. * Kopieren des Ordners (cp -a ethersex/protocols/serial_line_log ethersex/protocols/serialzwei_line_log) * alle Dateien im Ordner umbenannt (auser Makefile und config.in) (cd ethersex/protocols/serialzwei_line_log; mv serial_<...>.c serialzwei_<...>.c * mit einem Editor Alle Variabeln und Symbolenamen geändert <code> vim serialzwei_line_log.c :%s/SERIAL_/SERIALZWEI_/g :%s/serial_/serialzwei_/g :%s/sll_/sllzwei_/g </code> * in der serialzwei_line_log_ecmd.c muss noch der ecmd Befehl angepasst werden (ganz am Schluss der META abschnitt) <code> vim serialzwei_line_log_ecmd.c :%s/sll get/sll2 get :%s/sll_/sllzwei_/g </code> * in der protocols/serialzwei_line_log/config.in die Namen anpassen <code> vim config.in :%s/LINE_/LINE2_/g :%s/Line/Line2/g </code> * die ethersex/config.in und das MAKEFILE an die neuen Namen anpassen Zum Schluss müssen noch zwei zentrale Dateien angepasst werden. <code> cd ethersex/ vim Makefile SUBDIRS += protocols/serialzwei_line_log </code> <code> vim config.in source protocols/serialzwei_line_log/config.in </code> Danach sollte <code> make menuconfig </code> Jetzt sollte unter Protokolle das Serial Line Log zweimal vorhanden sein. Anmerkung: Das gleiche Verfahren funktioniert auch mit dem yport-Protokoll. Wenn man z.B. einen ATMega644p besitzt und beide UARTs "gleichzeitig" benutzen will, kann man das yport-Protokoll mit dem hier vorgestellten Verfahren duplizieren. nc <ip> 7970 bzw nc <ip> 7971 liefert dann die Ausgabe der beiden Ports. b56d7ae4362205a37785873946aa696642eddb20 0 156 389 2012-02-15T18:21:04Z GooPie4o 265 Created page with "{{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{I/O}}->RFM12 ASK |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6= |DEPENDS= |REQUIRES= - |CODE=[htt…" wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{I/O}}->RFM12 ASK |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6= |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} 487f02562ce7811a7d7e0dcae1459d8d253fa04f 397 389 2012-03-06T20:40:05Z Morais 209 wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{I/O}}->RFM12 ASK |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6= |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} RFM12 ASK schaltet Funksteckdosen von verschiedenen Hersteller. == unterstützte Systeme == ===Tevion=== Funksteckdosen mit einer 'Anlern-Taste' können mit Hilfe des LERN-Buttons auf der embeded Website des etherrapes */rf.ht auf den gesendeten Hauscode programmiert werden. Erstaunlicherweise können mit diesem Modul auch die Codes der X10 Fernbedienung von Pollin gesendet werden. Eine Code-Sammlung gibts [[X10-codes|hier]]. Getestet: * Tevion * MMANDOLYN LIBRA GmbH, Model No. WRC001 * X10 Pollin Best.Nr. 721 379 ===Intertechno (ITS-150)=== Bei Sender vom Typ Intertechno ITS-150 wird über einen Drehschalter auf der Rückseite der Familiencode eingestellt. Auf der Vorderseite gibt es einen Schieberegler für die Auswahl von Gruppe 1-4 sowie Ein/Aus Knöpfe für die Geräte 1-4 (siehe Bild). Die zusätzlich vorhandenen Gruppentaste funktioniert mit den Empfängern Intertechno CMR-500 nicht (deshalb nicht implementiert). ===2272=== Diese Steckdosen werden üblicherweise über einen Block von 10 DIP-Switches konfiguriert. Dabei wird mit den ersten fünf Schaltern der Hauscode gesetzt. Es ergeben sich also 32 mögliche Einstellungen. Die übrigen fünf Schalter geben die Adresse der Steckdose an. Bei Verwendung des mitgelieferten Senders wird jeweils einer der Adressschalter auf "1" gesetzt: In Dose A setzt man Dip 6 auf '1'; in Dose B Dip 7 auf '1'... Bei Ansteuerung mit dem Ethersex-System besteht diese Einschränkung nicht, so dass hier 32 verschiedene Adressen möglich sind. Getestet: {|class=wikitable |[[Bild:ELRO_AB440R.jpg|100px]] |[[Bild:düwiaktor.jpg|100px]] |[[Bild:Globusaktoren.jpg|100px]] |[[Bild:Kangtai2605.jpg|100px]] |[[Bild:Kangtai6899s.jpg|100px]] |- |valign=top|ELRO AB440R |valign=top|Düwi Modell 0369-3 |valign=top|Kangtai<br>v. Globus |valign=top|Kangtai<br>Model 2605 |valign=top|Kangtai<br>Model 6899s<br>[[Warnung vor Kangtai 6899s|'''Warnung!''']] |- |Delay 100 |Delay 60 |Delay 72 |Delay 72 |Delay 72 |} == 1527 == Anlernbare Unterputz-Dimmer (zB. Pollin Funkdimmerset FD-UP003) mit Fernbedienung. Die mitgelieferte Fernbedienung besitzt einen HS1527 Encoder (baugleich RT1527/ EV1527/FP1527/SC1527). Der gesendete Code bestehtaus 24 Bits, welche per ASK gesendet werden. Davon sind die ersten 20 Bits fest programmiert - der Hauscode sozusagen. Die letzten 4 Bits sind der eigentliche Schalt-Befehl. Getestet: {|class=wikitable |[[Bild:FD-UP003.jpg|Pollin Electronic FD-UP003|100px]] |- |valign=top|Pollin FD-UP003<br>[[Hinweis FD-UP003|'''Hinweis!''']] |} b174a26a49e6ad25f7324e7f82ac0d11c3928a04 398 397 2012-03-06T20:40:54Z Morais 209 /* 2272 */ wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{I/O}}->RFM12 ASK |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6= |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} RFM12 ASK schaltet Funksteckdosen von verschiedenen Hersteller. == unterstützte Systeme == ===Tevion=== Funksteckdosen mit einer 'Anlern-Taste' können mit Hilfe des LERN-Buttons auf der embeded Website des etherrapes */rf.ht auf den gesendeten Hauscode programmiert werden. Erstaunlicherweise können mit diesem Modul auch die Codes der X10 Fernbedienung von Pollin gesendet werden. Eine Code-Sammlung gibts [[X10-codes|hier]]. Getestet: * Tevion * MMANDOLYN LIBRA GmbH, Model No. WRC001 * X10 Pollin Best.Nr. 721 379 ===Intertechno (ITS-150)=== Bei Sender vom Typ Intertechno ITS-150 wird über einen Drehschalter auf der Rückseite der Familiencode eingestellt. Auf der Vorderseite gibt es einen Schieberegler für die Auswahl von Gruppe 1-4 sowie Ein/Aus Knöpfe für die Geräte 1-4 (siehe Bild). Die zusätzlich vorhandenen Gruppentaste funktioniert mit den Empfängern Intertechno CMR-500 nicht (deshalb nicht implementiert). ===2272=== Diese Steckdosen werden üblicherweise über einen Block von 10 DIP-Switches konfiguriert. Dabei wird mit den ersten fünf Schaltern der Hauscode gesetzt. Es ergeben sich also 32 mögliche Einstellungen. Die übrigen fünf Schalter geben die Adresse der Steckdose an. Bei Verwendung des mitgelieferten Senders wird jeweils einer der Adressschalter auf "1" gesetzt: In Dose A setzt man Dip 6 auf '1'; in Dose B Dip 7 auf '1'... Bei Ansteuerung mit dem Ethersex-System besteht diese Einschränkung nicht, so dass hier 32 verschiedene Adressen möglich sind. Getestet: {|class=wikitable |[[]] |[[Bild:düwiaktor.jpg|100px]] |[[Bild:Globusaktoren.jpg|100px]] |[[Bild:Kangtai2605.jpg|100px]] |[[Bild:Kangtai6899s.jpg|100px]] |- |valign=top|ELRO AB440R |valign=top|Düwi Modell 0369-3 |valign=top|Kangtai<br>v. Globus |valign=top|Kangtai<br>Model 2605 |valign=top|Kangtai<br>Model 6899s<br>[[Warnung vor Kangtai 6899s|'''Warnung!''']] |- |Delay 100 |Delay 60 |Delay 72 |Delay 72 |Delay 72 |} == 1527 == Anlernbare Unterputz-Dimmer (zB. Pollin Funkdimmerset FD-UP003) mit Fernbedienung. Die mitgelieferte Fernbedienung besitzt einen HS1527 Encoder (baugleich RT1527/ EV1527/FP1527/SC1527). Der gesendete Code bestehtaus 24 Bits, welche per ASK gesendet werden. Davon sind die ersten 20 Bits fest programmiert - der Hauscode sozusagen. Die letzten 4 Bits sind der eigentliche Schalt-Befehl. Getestet: {|class=wikitable |[[Bild:FD-UP003.jpg|Pollin Electronic FD-UP003|100px]] |- |valign=top|Pollin FD-UP003<br>[[Hinweis FD-UP003|'''Hinweis!''']] |} e6c26ca0e2bcf27e10f5b95647f5eb6ff509a4ad 2 157 390 2012-02-20T17:26:05Z Don H 164 Konstanten für SENDMAIL-Makro wikitext text/x-wiki E-Mails versenden / Unterschiedliche Netzwerke Beispiel: Ethersex soll bei n verschiedenen Ereignissen jeweils eine E-Mail versenden. Dann schreibt man n verschiedene Zeilen in seinen Quelltext. SENDMAIL(192.168.5.55, 25, "sender@domain.tld", "to-name@somewhe.re", "subject1", body1") Weil ich mehrere fast identische Net-IOs habe, die aber in verschiedenen Netzen arbeiten, ist die Editiererei in n verschiedenen Zeilen, lästig, aufwändig und fehleranfällig. Man kann sich die Arbeit mit ff. Definitionen etwas erleichtern. define(`smtp_ip', `192.168.5.55') ; define(`c_from', `"sender@domain.tld"') ; SENDMAIL(smpt_ip, 25, c_from, "to-name@somewhe.re", "subject1", body1") 60f0aebbc0574de73767d6e121c252c145242006 6 158 391 2012-03-03T16:58:28Z Mgue 312 The DMX Storage html interface in Chromium 17.0.963.56 wikitext text/x-wiki The DMX Storage html interface in Chromium 17.0.963.56 2f3c6b5f03c2975a9ce8a7d08b9125df65b7b9bf 0 28 392 315 2012-03-03T17:02:02Z Mgue 312 + HTML Interface wikitext text/x-wiki {{i18n|DMX Storage}} {{Module |NAME=DMX Storage |MENUCONFIG={{Applications}}->DMX Storage |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] (optional) |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/services/dmx-storage https://github.com/ethersex/ethersex/tree/master/services/dmx-storage] }} Dmx Storage provides a database-like storage layer for DMX information. It forms the core of the [[Ethersex Lighting Architecture]]. == Modules (input) == The following modules change/alter the DMX data *[[Artnet]] *[[DMX]] (not yet implemented) *[[DMX FXSlot]] == Modules (output) == The following modules display/use the dmx data *[[Artnet]] *[[DMX]] *[[Starburst]] *[[StellaLight]] == [[ECMD]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx channels | Get channels per universe |- | dmx get | Return channel value |- | dmx set | Set channel values |- | dmx universe | Get a whole universe |- | dmx universes | Get universes |- |} == HTML Interface == DMX Storage Channels can also be altered via the HTTP-Server. The interface currently works in most of the Webkit-based browsers (e.g. Google Chrome) and Mozilla Firefox (Version 4+). The interface can be enabled in the [VFS] menu. When using Firefox, make sure to enable "Support <input type=range> for Firefox". [[File:Ethersex-dmxUI.png|right|500px|thumb|The HTML interface in Chromium 17]] [[Category:e6la]] f0215975b3c11f50c7d2e28fb9ebe09732b1dc79 395 392 2012-03-05T16:29:10Z Mgue 312 Browsers wikitext text/x-wiki {{i18n|DMX Storage}} {{Module |NAME=DMX Storage |MENUCONFIG={{Applications}}->DMX Storage |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] (optional) |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/services/dmx-storage https://github.com/ethersex/ethersex/tree/master/services/dmx-storage] }} Dmx Storage provides a database-like storage layer for DMX information. It forms the core of the [[Ethersex Lighting Architecture]]. == Modules (input) == The following modules change/alter the DMX data *[[Artnet]] *[[DMX]] (not yet implemented) *[[DMX FXSlot]] == Modules (output) == The following modules display/use the dmx data *[[Artnet]] *[[DMX]] *[[Starburst]] *[[StellaLight]] == [[ECMD]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx channels | Get channels per universe |- | dmx get | Return channel value |- | dmx set | Set channel values |- | dmx universe | Get a whole universe |- | dmx universes | Get universes |- |} == HTML Interface == DMX Storage Channels can also be altered via the HTTP-Server. The interface currently works in most of the Webkit-based browsers (e.g. Google Chrome) and Mozilla Firefox (Version 4+). The interface can be enabled in the [VFS] menu. Tested browsers: {| border='1' |- | Browser | Version | Works |- | Firefox | 10.0.2 | yes (see note) |- | Chromium | 17.0.963.56 | yes |- | Konqueror | 4.8.00 | no |- | Android Browser | Android 4.? | no |- |} When using Firefox, make sure to enable "Support <input type=range> for Firefox". [[File:Ethersex-dmxUI.png|right|500px|thumb|The HTML interface in Chromium 17]] [[Category:e6la]] a00e0bcbfbdb3a124c4642494777c04f664d4981 405 395 2012-03-23T08:27:22Z Mgue 312 added input module "Web GUI" wikitext text/x-wiki {{i18n|DMX Storage}} {{Module |NAME=DMX Storage |MENUCONFIG={{Applications}}->DMX Storage |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] (optional) |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/services/dmx-storage https://github.com/ethersex/ethersex/tree/master/services/dmx-storage] }} Dmx Storage provides a database-like storage layer for DMX information. It forms the core of the [[Ethersex Lighting Architecture]]. == Modules (input) == The following modules change/alter the DMX data *[[Artnet]] *[[DMX]] (not yet implemented) *[[DMX FXSlot]] *[[DMX_Storage#HTML_Interface | DMX WebGUI]] == Modules (output) == The following modules display/use the dmx data *[[Artnet]] *[[DMX]] *[[Starburst]] *[[StellaLight]] == [[ECMD]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx channels | Get channels per universe |- | dmx get | Return channel value |- | dmx set | Set channel values |- | dmx universe | Get a whole universe |- | dmx universes | Get universes |- |} == Web GUI == DMX Storage Channels can also be altered via the HTTP-Server. The interface currently works in most of the Webkit-based browsers (e.g. Google Chrome) and Mozilla Firefox (Version 4+). The interface can be enabled in the [VFS] menu. Tested browsers: {| border='1' |- | Browser | Version | Works |- | Firefox | 10.0.2 | yes (see note) |- | Chromium | 17.0.963.56 | yes |- | Konqueror | 4.8.00 | no |- | Android Browser | Android 4.? | no |- |} When using Firefox, make sure to enable "Support <input type=range> for Firefox". [[File:Ethersex-dmxUI.png|right|500px|thumb|The HTML interface in Chromium 17]] [[Category:e6la]] 924f9013fc37b306dba45bdecb0aff6fbf08082e 0 160 399 2012-03-08T00:59:46Z FordPrfkt 187 Created the page wikitext text/x-wiki {{i18n|PCA9555}} {{Module |NAME=PCA9555 |MENUCONFIG={{I/O}}->I2C Master Support->I2C PCA9555 |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6= |DEPENDS=[[ECMD]] [[I2C Master]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/i2c/master/ https://github.com/ethersex/ethersex/tree/master/hardware/i2c/master] }} Driver for the PCA9555 16-Bit I2C digital I/O chip. == Connection == == Configuration == == [[ECMD]] == PCA9555 implements a [[ECMD]] interface for reading and writing the pin status. See [[ECMD_Reference|ECMD reference]]. ef8d9dad429c79d42d60c8858a898cd7d4de91ae 0 43 406 366 2012-03-23T11:33:52Z Unclestefan 459 /* ADS */ wikitext text/x-wiki <div class="errorbox"> This page is automatically generated from the files in the Ethersex source code repository. Do not edit this page but send [[patches]] for those files! </div> __NOTOC__ == Analog/Digital Conversion ([[ADC]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | adc get [CHANNEL] | Get the ADC value in hex of CHANNEL or if no channel set of all channels. |- | hr20 temp | Read HR20 temperature sensor. |- |} == DNS Resolver == {| border='1' | ''Command syntax'' | ''Short description'' |- | dns server [IPADDR] | Display/Set the IP address of the DNS server to use to IPADDR. |- | nslookup HOSTNAME | Do DNS lookup for HOSTNAME (call twice). |- |} == Digital/Analog Conversion ([[DAC]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ltc1257_delay `[VALUE] | Set (if VALUE given) or get (no VALUE) delay for LTC1257 output bit changes in µs' |- | ltc1257_set `[VALUE0] [VALUE1] ... | Set output to value (value: 0-4095)' |- | tlc5620 `[CHANNEL] [VALUE] | Set Output to value (Value: 0-0xff)' |- |} == Fnordlicht == {| border='1' | ''Command syntax'' | ''Short description'' |- | fnordlicht "ADDRESS RED | GREEN,BLUE",fnordlicht command to set RGB color |- | fnordlicht_init | fnordlicht init |- |} == HD44780 [[LCD]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | hr20 hourbar START STOP | Update hourbar to show ticks between START and STOP (range 0..23) |- | hr20 toggle SEG | Toggle segment SEG (a number, not a symbolic name!) |- | lcd backlight STATE | switch back light STATE to ON or OFF |- | lcd char N D1 D2 D3 D4 D5 D6 D7 D8 | Define use-definable char N with data D1..D8 (provide DATA in hex) |- | lcd clear [LINE] | Clear line LINE (0..3) or the whole display (if parameter is omitted) |- | lcd goto LINE COL | Move cursor to LINE and column COL (origin is 0/0) |- | lcd reinit CURSOR BLINK | Reinitialize the display, set whether to show the cursor (CURSOR, 0 or 1) and whether the cursor shall BLINK |- | lcd shift DIR | Shift the display to DIR (either ''left'' or ''right'') |- | lcd write TEXT | Write TEXT to the current cursor location |- |} == Infrared Send/Receive ([[IR-TRX]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ir receive | receive an IR command |- | ir send DEVICE COMMAND | send COMMAND to DEVICE |- |} == Infrared Send/Receive ([[IRMP]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | irmp receive | receive an IR command |- | irmp send PROTOCOL DEVICE COMMAND REPEAT | send COMMAND with REPEAT flag to DEVICE using PROTOCOL |- |} == NTP Client == {| border='1' | ''Command syntax'' | ''Short description'' |- | ntp query | Query the NTP server to get an NTP update. |- | ntp server [IPADDR] | Display/Set the IP address of the NTP server to use to IPADDR. |- | ntp status | Display NTP server status |- |} == Network configuration == {| border='1' | ''Command syntax'' | ''Short description'' |- | enc dump | Dump the internal state of the enc to serial |- | gw [IP] | Display/Set the address of the default router. |- | ip [IP] | Display/Set the IP address. |- | mac [xx:xx:xx:xx:xx:xx] | Display/Set the MAC address. |- | netmask [IP] | Display/Set the network mask. |- |} == Port I/O == {| border='1' | ''Command syntax'' | ''Short description'' |- | io get ddr PORTNUM | Display the current value of the DDR PORTNUM. |- | io get mask PORTNUM | Display the mask of the port PORTNUM. |- | io get pin PORTNUM | Display the current value of the PIN-register of the port PORTNUM. |- | io get port NUM | Display the current value of the PORT NUM. |- | io set ddr PORTNUM HEXVALUE [MASK] | Set the DDR of port PORTNUM to VALUE (possibly using the provided MASK). |- | io set port NUM HEXVALUE [MASK] | Set the PORT NUM to VALUE (possibly using the provided MASK). |- |} == Reading and Writing EEPROM Space on Device == {| border='1' | ''Command syntax'' | ''Short description'' |- | eer eer <ADDR> <LENGTH> | Read n bytes from address after the config in eeprom. |- | eew eew <ADDR> <HEXBYTES> | Write Hexbytes at address after the config in epprom. |- | fuse | Display current fuse settings |- | hostname | Display hostname. |- |} == Resetting the controller == {| border='1' | ''Command syntax'' | ''Short description'' |- | bootloader | Call the bootloader. |- | reset | Reset the Ethersex. |- | wdreset | Go into endless loop to trigger a watchdog timeout. |- |} == [[ADS]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | adc get | Get the ADC value in hex. |- | adc mean [COUNT] | Get the mean of power of 2 COUNT ADC values in hex. |- |} == [[Am_Puls_der_Zeit|Clock]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | date | Print the current date. |- | lastdcf | Print when last valid DCF signal was received. |- | time [UNIXTIME] | Display/Set the current time in seconds since January 1st 1970. |- | uptime | Display ethersex uptime in unix format. |- | whm | Display ethersex uptime. |- |} == [[Application_Sample]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sample | Manually call application sample commands |- | sample_init | Manually call application sample init method |- | sample_periodic | Manually call application sample periodic method |- |} == [[Blinkenlights_MCUF|MCUF]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | mcuf modul N | Select module N |- | mcuf modul list | List all modules |- | mcuf showclock | Show digital clock |- | mcuf showstring MESSAGE | Show scrolling MESSAGE on the display |- |} == [[CRC]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | crc calc | "read the ethersex program code and calc a crc16 of it" |- | crc read | "read out the crc16 value at the end of the program space" |- |} == [[CRON-Dienst]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | cron_add MIN HOUR DAY MONTH DOW ECMD | Add ECMD to cron to be executed at given time |- | cron_list | Show all cron entries |- | cron_make_persistent | Mark a Job as persistent |- | cron_rm POSITION | Remove one cron entry |- | cron_save | Saves all persistent jobs |- |} == [[DALI]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dali cmd [TARGET] [COMMAND] [!][?] | "send the given command (decimal) to targets (all, g00 to g15, s00 to s63), auto repeat with !, read reply with ?" |- | dali dim [TARGET] [LEVEL] | "dim targets (all, g00 to g15, s00 to s63) to given level (0-254)" |- | dali raw [BYTE1] [BYTE2] | "send a raw frame (two bytes, given in hex) over the DALI bus" |- | dali scmd [SPECIAL COMMAND] [DATA] [!][?] | "send special command (256-287) with data, auto repeat with !, read reply with ?" |- |} == [[DMX_FXSlot]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx fxslot devices | set the device settings |- | dmx fxslot effect | set the effect settings |- | dmx fxslot reset | reset all fxslots and clear saved ones in EEPROM |- | dmx fxslot restore | restore the settings from EEPROM |- | dmx fxslot save | save the current fxslots to EEPROM |- |} == [[DMX_Storage]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx channels | Get channels per universe |- | dmx get | Return channel value |- | dmx set | Set channel values |- | dmx universe | Get a whole universe |- | dmx universes | Get universes |- |} == [[Dallas_1-wire_Bus]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | 1w convert [DEVICE] | Trigger temperature conversion of either DEVICE or all connected devices |- | 1w ds2450 convert [DEVICE] | `start conversion (with optional input mask and read out control)' |- | 1w ds2450 get [DEVICE] | `get conversion result (one or all channels)' |- | 1w ds2450 oc [DEVICE] | `get/set output control (per channel)' |- | 1w ds2450 oe [DEVICE] | `get/set output enable (per channel)' |- | 1w ds2450 por [DEVICE] | `get/set power on reset (per channel)' |- | 1w ds2450 power [DEVICE] | `get/set power supply of device (global)' |- | 1w ds2450 range [DEVICE] | `get/set input voltage range (per channel)' |- | 1w ds2450 res [DEVICE] | `get/set bit resolution of AD convert (per channel)' |- | 1w get DEVICE | Return temperature value of onewire DEVICE (provide 64-bit ID as 16-hex-digits) |- | 1w list | Return a list of the connected onewire devices |- |} == [[DataFlash]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | df status | Display internal status. |- | fs format | Format the filesystem. |- | fs inspect inode INODE | Inspect INODE (and associated page). |- | fs inspect node NODE | Inspect NODE and dump to serial. |- | fs list | List the directory. |- | fs mkfile NAME | Create a new file NAME. |- | fs remove NAME | Delete the file NAME. |- | fs truncate NAME LEN | Truncate the file NAME to LEN bytes. |- |} == [[Dc3840_camera|DC3840 mobil camera support]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dc3840 capture | Take a picture. Access 'dc3840' via VFS afterwards. See [[DC3840 Camera]] for details. |- | dc3840 light | Light level of camera |- | dc3840 send A B C D E | Send provided command bytes to the camera. |- | dc3840 sync | Re-sync to the camera |- | dc3840 zoom | Enable zoom of camera |- |} == [[ECMDScript]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | call FILENAME | Start script named FILENAME |- | cat FILENAME | cat file content (with debug only) |- | dec VAR | Decrement variable VAR (a number) |- | echo <any> | Print out all arguments of echo |- | exit | Exit currently running script |- | get VAR | Get value of variable VAR |- | goto N | Goto line N in currently running script |- | if ( CMD/VAR == CONST ) then CMD2 | If condition matches execute CMD2 |- | inc VAR | Increment variable VAR (a number) |- | rem <any> | Remark for anything |- | set VAR VALUE | Set variable VAR to VALUE |- | wait I | Wait I milliseconds |- |} == [[FS20]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fht send HOUSECODE ADDR CMD [CMD2] | Send FHT command. See [[FS20]] for details. |- | fs20 receive | Receive FS20/FHT sequence and display it. |- | fs20 send HOUSECODE ADDR CMD [CMD2] | Send FS20 command. See [[FS20]] for details. |- | fs20 ws300 | Receive FS20 sequence from WS300 weather station and decode it. |- |} == [[Frequency Counter]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fc %duty [CHANNEL] | "returns last on duty cycle in percent for given channel" |- | fc duty [CHANNEL] | "returns last on duty cycle (0-255) for given channel" |- | fc freq [CHANNEL] | "returns last frequency in Hz for given channel" |- | fc off [CHANNEL] | "switch off frequency counting on given channel" |- | fc on [CHANNEL] | "switch on frequency counting on given channel" |- | fc ticks [CHANNEL] | "returns last frequency in CPU ticks for given channel" |- |} == [[GLCD_Menu]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | glcdmenu key VALUE | Send a keypress to the menu |- | glcdmenu update | Update the menu |- |} == [[GPS]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | nmea get | Get latitude and longitude data |- | nmea satellites | Get satellites |- |} == [[H-Bridge]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | hbridge [action] [enable_l] [enable_r] | Set H-Bridge command |- | hbridge pwm int | Set H-Bridge enable line valueeg. speed |- |} == [[I2C]] (TWI) == {| border='1' | ''Command syntax'' | ''Short description'' |- | bmp085 apress | Get absolute pressure in Pa |- | bmp085 height PRESSNN | Get height in cm, pressure at N0 needed |- | bmp085 pressnn HEIGHT | Get pressure at N0, height in cm needed |- | bmp085 temp | Get temperature in 0.1°C |- | ds1631 convert ADDR VALUE | Initiate temperature conversions (0: stop, 1: convert) |- | ds1631 temp ADDR | Read last converted temperature |- | i2c detect | list detected I2C Chips |- | i2c rbb ADDR | read byte from I2C chip |- | i2c rbd CHIPADDR REGADDR | read byte from register address at I2C chip |- | i2c rwd CHIPADDR REGADDR | read word from register address at I2C chip |- | i2c wbb ADDR HEXVALUE | write byte to I2C chip |- | i2c wbd CHIPADDR REGADDR HEXVALUE | write byte to register address on I2C chip |- | i2c wwd CHIPADDR REGADDR HEXVALUE | write word to register address on I2C chip |- | lm75 ADDR | Get temperature |- | max7311 getDDRw ADDR | Get Direction-Register DDR |- | max7311 getINw ADDR | Get Input-Register IN |- | max7311 getOUTw ADDR | Get Output-Register OUT |- | max7311 pulse ADDR BIT TIME | Toggle Output-BIT for TIME (in ms) |- | max7311 set ADDR BIT VALUE | Set Output-BIT to VALUE (bool) |- | max7311 setDDRw ADDR VALUE | Set Direction-Register DDR (VALUE as hex) |- | max7311 setOUTw ADDR VALUE | Set Output-Register OUT (VALUE as hex) |- | pca9531 ADDR PERIODPWM1 DUTYPWM1 PERIODPWM2 DUTYPWM2 LED0..3 LED4..7 | set PWM1 and PWM2 and LED states |- | pca9685m ADDR | OUTDRV, IVRT, PRESCALE |- | pca9685s ADDR | LED, ON, OFF |- | pcf8574x read ADDR CHIP | Get bits |- | pcf8574x set ADDR CHIP HEXVALUE | Set bits |- | tsl2550 lux | Show light level by reading adc registers and computing level |- | tsl2550 mode VALUE | Set the TSL2550s operating mode (0: standard range, 1: extended range) |- | tsl2550 power VALUE | Set the TSL2550s power state (0: down, 1:up) |- |} == [[Jabber]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | jabber_host [HOSTNAME] | JABBER hostname |- | jabber_pass [PASSWORD] | JABBER password |- | jabber_resrc [RESOURCE] | JABBER resource |- | jabber_user [USERNAME] | JABBER username |- |} == [[KTY]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | kty autocalibrate CHANNEL | Calibrate to 1000 Ohm precision Resistor. |- | kty cal get | Return the calibration difference to 2k2 Resistor. |- | kty get [CHANNEL] | Get the temperature in xxx.x °C of CHANNEL or if no channel set of all channels. |- |} == [[MotorCurtain]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | curtain VALUE | Set value of curtain. 0=closed..7=open. If you use fewer sensors, use the corrent value instead of 7. |- | curtainlast | Return last known position |- | curtainmax | Return maximum position |- | curtainoff | Switch motor off |- |} == [[Named_PIN]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | pin get NAME | Read and display the status of pin NAME. |- | pin list | List all known named-pins. |- | pin set NAME STATUS | Set the status of pin NAME to STATUS. |- | pin toggle NAME | Toggle the status of pin NAME. |- |} == [[PWM]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dtmf CHARS | send CHARS as DTMF |- | freq set FREQUENCY DELAY | Set frequency for DELAY ms |- | pwm fade [channel +-diff startvalue] | Set fading at channel with startvalue and change each stepp to diff (must be signed 3 digit) |- | pwm set [channel value] | Set channel to value |- |} == [[RFM12]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | rfm12 reinit | Re-initialize RFM12 module. |- | rfm12 setbandwidth BW | Set RX bandwidth to BW. |- | rfm12 setbaud BAUD | Set baudrate to BAUD. |- | rfm12 setdrssi DRSSI | Set the drssi to DRSSI. |- | rfm12 setgain GAIN | Set preamplifier gain to GAIN. |- | rfm12 setmod MOD | Set modulation to MOD. |- | rfm12 status | Display internal status. |- |} == [[RFM12_ASK]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | rfm12 1527 | housecodeCommand delay cnt |- | rfm12 2272 | housecodeCommand delay cnt |- | rfm12 ask sense | Trigger (Tevion) ASK sensing. Enable ext. filter pin before! |- | rfm12 external filter [1] | Enable ext. filter pin if argument is present (disable otherwise) |- | rfm12 intertechno | family group device command |- | rfm12 tevion | housecode command delay cnt |- |} == [[RFM12_FS20]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fht send | housecode addr command data |- | fs20 send | housecode addr command data |- |} == [[SD-Karte]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sd dir | List contents of current SD directory. |- | sd mkdir PATH | Create directory hierarchy PATH. |- |} == [[SHT]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sht humid | Return humidity of SHT sensor |- | sht raw | Return raw hex temp (first line) and humidity value (second line) of SHT sensor |- | sht temp | Return temperature of SHT sensor |- |} == [[SMS77]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sms77 MESSAGE | Send MESSAGE to compiled in sms77 service |- | sms77_pass [PASSWORD] | SMS77 password |- | sms77_recv [RECEIVER] | SMS receiver |- | sms77_type [TYPE] | SMS type |- | sms77_user [USERNAME] | SMS77 username |- |} == [[Servo_Ansteuerung|PWM Servo Control]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | pwm servo_dec SERVONR | Decrement position of servo SERVONR |- | pwm servo_inc SERVONR | Increment position of servo SERVONR |- | pwm servo_set SERVONR POSITION | Set servo with SERVONR to POSITION |- |} == [[Sound]]/WAV support == {| border='1' | ''Command syntax'' | ''Short description'' |- | pwm stop | Stop wav |- | pwm wav <FILENAME> | Play wave file. Use VFS if compiled in. More details at [[Sound]] |- |} == [[Stella_Light]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | channel CHANNEL VALUE FUNCTION | Get/Set stella channel to value. Second and third parameters are optional. Function: You may use 's' for instant set, 'f' for fade and 'y' for flashy fade. |- | channels | Return stella channel size |- | fadestep FADESTEP | Get/Set stella fade step |- | stella load | Load values from eeprom |- | stella store | Store values in eeprom |- |} == [[USB]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | keyboard MESSAGE | Send MESSAGE as HID keyboard |- | mouse BUTTON DELTAX DELTAY | Send data as HID mouse |- |} == [[ZACwire]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | zac 306 PORT BIT | Return temperature of TSic 306 at BIT of PORT |- | zac 506 PORT BIT | Return temperature of TSic 506 at BIT of PORT |- | zac raw PORT BIT | Return raw hex temperature value of zacwire at BIT of PORT |- |} == lome6 == {| border='1' | ''Command syntax'' | ''Short description'' |- | lome6 get_t TYPE | get temperature command |- | lome6 power TYPE | press power command |- | lome6 reset | press reset command |- | lome6 set_t TYPE TEMPERATURE | set temperature command |- | lome6 state | get state command |- | lome6 uptime UPTIME | set/get uptime command |- |} == Miscelleanous == {| border='1' | ''Command syntax'' | ''Short description'' |- | alias list | List all available aliases |- | artnet test | artnet test |- | cw send MESSAGE | Send MESSAGE in Morce Code |- | d ADDR | Dump the memory at ADDR (16 bytes). |- | eeprom reinit | Force reinitialization of the EEPROM config area |- | free | Display free space. |- | help | List which commands are available. |- | ht MESSAGE | Send MESSAGE to compiled in httplog service |- | ipstats | Display IP statistics. |- | mb recv | Receive data from modbus |- | moodlight CHANNEL ONOFF | Set CHANNEL moodlight on=1 or off=0. If no channel is given return on if channel CHANNEL is moodlighted |- | motd [MESSAGE] | Save MESSAGE as new message of the day, otherwise just show current message |- | msr1 get | Get data |- | mysql query QUERY | Send specified MySQL query to the configured server |- | ns | update net statistic for public anouncment of currently running ethersex |- | pam USER PASSWORD | Use pam for user and password |- | push NUMBER | Push button identified by NUMBER |- | pwm melody [NUMBER] | Play melody |- | sanyoz700 CMD | Send command to projector |- | sll get | Request the logged data |- | sram memtest | Perform a memory test |- | srf05 | Read SRF05 measurement |- | to1 get | Request data from sensor |- | tw MESSAGE | Send MESSAGE to compiled in twitter service |- | upnp send | Manually send UPnP broadcast packet |- | usart baud BAUD | Set the USART baudrate to BAUD. |- | version | Display the version number. |- | wol MAC | Send WAKE-ON-LAN command to MAC |- | yport stats | Report statistic counters |- | zbus stats | Report statistic counters |- |} [[Category:Ethersex]] [[Category:ECMD]] 638714522a0e66d5350109173d81a4572a552fc0 1 166 407 2012-03-24T14:30:35Z GooPie4o 265 Created page with "This page is generated. Change the source code in stead!" wikitext text/x-wiki This page is generated. Change the source code in stead! e33830be101f0d835b36184c23bfaa035eff1005 0 34 408 90 2012-03-25T14:21:12Z Mgue 312 wrong url wikitext text/x-wiki {{i18n|Artnet}} {{Module |NAME=Artnet |MENUCONFIG={{Protocols}}->Art-Net Node |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] (optional) [[DMX Storage]] |REQUIRES= NET_MAX_FRAME_LENGTH >= 572 |CODE=[https://github.com/ethersex/ethersex/tree/master/protocols/artnet https://github.com/ethersex/ethersex/tree/master/protocols/artnet] }} The Artnet module currently supports receiving aswell as broadcasting universes. Configuration packages are not yet implemented (like setting the IP address of your device using Artnet). The module is part of the [[Ethersex Lighting Architecture]] and stores/requests the DMX data using [[DMX Storage]]. == Configuration == Make sure that NET_MAX_FRAME_LENGTH is >= 572 or artnet will be unable to process any packages. == Known Issues == Some programs like [http://qlc.svn.sourceforge.net/ QLC] start the universe count with 1 instead of 0. Make sure that you adjust the universes according to that. [[Category:e6la]] 289da38feff84b78e64ed97c6584666eb619e296 0 167 409 2012-03-25T15:30:05Z Mgue 312 first version wikitext text/x-wiki {{i18n|ECMD}} {{Module |NAME=ECMD |MENUCONFIG={{Protocols}}->ECMD (Etherrape Command Interface) support |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/protocols/ecmd https://github.com/ethersex/ethersex/tree/master/protocols/ecmd] }} '''E'''thersex '''C'''o'''m'''man'''d''' or short '''ECMD''' is a simple, text-based protocol to communicate with a device running Ethersex. Using ECMD one can control Ethersex' internal settings like the IP address, change the behavior of modules and even flash the device with a new firmware. == ECMD Interfaces == ECMD can be accessed via various transport protocols and busses using a simple abstraction layer. Ethersex provides support for TCP, UDP, I2C, RS232/USART, HTTP and even SMS. 2412b288a7fb4be1d1f8cd4835071e9de04213cd 0 168 410 2012-03-27T18:29:16Z Mgue 312 first version wikitext text/x-wiki {{i18n|Development/ECMD}} For general information on ECMD, see [[ECMD]]. The following variables will be used on this page. Replace them for your module. * '''COMMAND''' - how the command will be invoked * '''ARGUMENT1'''...'''ARGUMENTN''' - the arguments that will be passed together with '''COMMAND''' * '''FUNCTIONNAME''' - the name of the function which will handle the command * '''MODULENAME''' - the name of the module = Preparations = * Create a new file inside the folder of the module '''MODULENAME_ecmd.c''' * Add this file to the [[Development/Makefile | Makefile]] of the module. * Open the file and "#include "protocols/ecmd/ecmd-base.h" and other necessary headers. * Add the header of the module, <string.h> etc. = Create a new command = Start with the following template: <source lang="c"> int16_t parse_cmd_FUNCTIONNAME (char *cmd, char *output, uint16_t len) { /* Your Code here */ return ECMD_FINAL_OK; } </source> Whenever '''COMMAND''' is invoked, this function will be called to handle it. == Parameters == * *cmd holds '''ARGUMENT1'''...'''ARGUMENTN''' which have been passed along with the command * len is the length of the command (*cmd). Use this for securely parsing *cmd. * *output is the output buffer which can hold 50 bytes/characters == Return values == {| border="1" | ECMD_FINAL_OK | the command has been executed without any errors. "OK" will be written to the caller's output. |- | ECMD_FINAL('''len''') | the command has been executed. '''len''' bytes of *output will be written to the caller's output |- | ECMD_AGAIN('''len''') | the command has been executed but needs to be called again. '''len''' bytes of *output will be written to the caller's output |- | ECMD_ERR_PARSE_ERROR | the command couldn't be executed (missing/wrong arguments etc.) |- | ECMD_ERR_READ_ERROR | the command couldn't be executed (not able to read from device/hardware) |- | ECMD_ERR_WRITE_ERROR | the command couldn't be executed (not able to write to device/hardware) |} == Announce the command == Append this to the bottom of '''MODULENAME_ecmd.c''' to let the ECMD parser know about the new command. <source lang="c"> /* -- Ethersex META -- block(MODULENAME) ecmd_feature(FUNCTIONNAME, "COMMAND", ARGUMENT1...ARGUMENTN , DESCRIPTION) */ </source> The '''COMMAND''' along with the arguments and the description will show up [[ECMD_Reference | here]] = Tips and best practice = == Recursive calling a command handler function == If you need to output a lot of data (>50 bytes) , you need to recursivly call the command handler function using '''ECMD_AGAIN()'''. Instead of using unsafe ''static'' variables to keep track of the current progress you can use the following code: <source lang="c"> /* trick: use bytes on cmd as "connection specific static variables" */ if (cmd[0] != 23) { /* indicator flag: real invocation: 0 */ cmd[0] = 23; /* continuing call: 23 */ cmd[1] = 0; /* local variable 1 */ } </source> [https://github.com/ethersex/ethersex/blob/master/protocols/ecmd/parser.c#L193 source] [https://github.com/ethersex/ethersex/blob/master/services/dmx-storage/dmx_storage_ecmd.c#L105 example] [[Category:Development]] 432e3924a146a162e9dabef607494ab524051cf3 10 39 411 164 2012-03-27T19:19:58Z Mgue 312 Development wikitext text/x-wiki <noinclude>{{i18n|Template:Documentation}}</noinclude> {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | colspan=2 style="background-color: #FFFFFF; text-align: center; border-bottom:1px solid #aaaaaa;" | '''Documentation''' |- | [[Wiki Guidelines]] ---- * [[:Category:Hardware|Hardware Drivers]] * [[:Category:Protocol|Protocol Support]] * [[:Category:Application|Services and Applications]] * [[ECMD Reference]] ---- * [[:Category:Development|For Developers]] |} bcc5cf4ca7ce28b5ae44e1a807e7ada4f47d1952 423 411 2012-04-01T23:53:07Z Mgue 312 no colspan here wikitext text/x-wiki <noinclude>{{i18n|Template:Documentation}}</noinclude> {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | style="background-color: #FFFFFF; text-align: center; border-bottom:1px solid #aaaaaa;" | '''Documentation''' |- | [[Wiki Guidelines]] ---- * [[:Category:Hardware|Hardware Drivers]] * [[:Category:Protocol|Protocol Support]] * [[:Category:Application|Services and Applications]] * [[ECMD Reference]] ---- * [[:Category:Development|For Developers]] |} 420642ec8ce38c291f6aabce2602a2dfe96fbcc7 0 169 412 2012-03-29T17:35:19Z Mgue 312 +ArchLinux wikitext text/x-wiki {{i18n|Quick Start Guide/Preparation}} === Download the Source from GITHUB === You can download Ethersex from github via git protocol git clone git://github.com/ethersex/ethersex.git or via http git clone http://github.com/ethersex/ethersex.git Updating a local version of ethersex is possible with: git pull origin === Requirements === * AVR GCC-Compiler (Version 4.1 or higher) * AVR LIBC (Version 1.6.8, for 128er ATMegas 1.7) * GNU-Tools (Bash, Make, m4, awk) * AVR-Programmer (e.g. avrdude) == Linux Debian / Ubuntu == apt-get install gcc-avr avr-libc binutils-avr m4 gawk libncurses5-dev make dialog git-core avrdude == Arch Linux == pacman -Sy m4 avr-binutils avr-libc avrdude avr-gcc git gawk ncurses make perl == Mac OSX == Using MacPorts (www.macports.org) Apple Bash and sed doesn't work, you need to install Bash V4.0 and GNU sed. First, sync the Port Repository to ensure that you´ll build the latest versions of the requirements. port selfupgrade port install git-core avrdude avr-binutils avr-gcc avr-libc bash sed You can also use the CrossPack, but MacPorts is more straightforward and updated. [http://www.obdev.at/products/crosspack/index-de.html] If the MacPort versions of avr-gcc or avrdude are too old. Here is a instuction how to build the toolchain manually: [http://www.heise.de/ct/projekte/machmit/ctbot/wiki/AVRToolchain] 555ab4346686516058b3644026d08c0f48495a56 413 412 2012-03-29T18:42:35Z Mgue 312 moved git part to the bottom wikitext text/x-wiki {{i18n|Quick Start Guide/Preparation}} = Requirements = * AVR GCC-Compiler (Version 4.1 or higher) * AVR LIBC (Version 1.6.8, for 128er ATMegas 1.7) * GNU-Tools (Bash, Make, m4, awk) * AVR-Programmer (e.g. avrdude) == Linux Debian / Ubuntu == apt-get install gcc-avr avr-libc binutils-avr m4 gawk libncurses5-dev make dialog git-core avrdude == Arch Linux == pacman -Sy m4 avr-binutils avr-libc avrdude avr-gcc git gawk ncurses make perl == Mac OSX == Using MacPorts (www.macports.org) Apple Bash and sed doesn't work, you need to install Bash V4.0 and GNU sed. First, sync the Port Repository to ensure that you´ll build the latest versions of the requirements. port selfupgrade port install git-core avrdude avr-binutils avr-gcc avr-libc bash sed You can also use the CrossPack, but MacPorts is more straightforward and updated. [http://www.obdev.at/products/crosspack/index-de.html] If the MacPort versions of avr-gcc or avrdude are too old. Here is a instuction how to build the toolchain manually: [http://www.heise.de/ct/projekte/machmit/ctbot/wiki/AVRToolchain] = Download the Source from GitHub = You can download Ethersex from github via git protocol git clone git://github.com/ethersex/ethersex.git or via http git clone http://github.com/ethersex/ethersex.git Updating a local version of ethersex is possible with: git pull origin 2d2462214f7c78e1d36b84a94421c0c659f1b515 414 413 2012-03-29T18:44:07Z Mgue 312 next step wikitext text/x-wiki {{i18n|Quick Start Guide/Preparation}} = Requirements = * AVR GCC-Compiler (Version 4.1 or higher) * AVR LIBC (Version 1.6.8, for 128er ATMegas 1.7) * GNU-Tools (Bash, Make, m4, awk) * AVR-Programmer (e.g. avrdude) == Linux Debian / Ubuntu == apt-get install gcc-avr avr-libc binutils-avr m4 gawk libncurses5-dev make dialog git-core avrdude == Arch Linux == pacman -Sy m4 avr-binutils avr-libc avrdude avr-gcc git gawk ncurses make perl == Mac OSX == Using MacPorts (www.macports.org) Apple Bash and sed doesn't work, you need to install Bash V4.0 and GNU sed. First, sync the Port Repository to ensure that you´ll build the latest versions of the requirements. port selfupgrade port install git-core avrdude avr-binutils avr-gcc avr-libc bash sed You can also use the CrossPack, but MacPorts is more straightforward and updated. [http://www.obdev.at/products/crosspack/index-de.html] If the MacPort versions of avr-gcc or avrdude are too old. Here is a instuction how to build the toolchain manually: [http://www.heise.de/ct/projekte/machmit/ctbot/wiki/AVRToolchain] = Download the Source from GitHub = You can download Ethersex from github via git protocol git clone git://github.com/ethersex/ethersex.git or via http git clone http://github.com/ethersex/ethersex.git Updating a local version of ethersex is possible with: git pull origin [[Quick_Start_Guide/Configuration | next step]] 82cd4bb55a845a40b054ae45edf12711d0d1c492 429 414 2012-04-02T10:50:41Z Mgue 312 binutils 2.22 bug wikitext text/x-wiki {{i18n|Quick Start Guide/Preparation}} = Requirements = * AVR GCC-Compiler (Version 4.1 or higher) * AVR LIBC (Version 1.6.8, for 128er ATMegas 1.7) * GNU-Tools (Bash, Make, m4, awk) * AVR-Programmer (e.g. avrdude) '''Attention:''' binutils ''2.22'' has a bug that causes the compilation of ethersex to fail. Install version 2.21 until [http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52692 GCC 4.7.1 has been released]. == Linux Debian / Ubuntu == apt-get install gcc-avr avr-libc binutils-avr m4 gawk libncurses5-dev make dialog git-core avrdude == Arch Linux == pacman -Sy m4 avr-binutils avr-libc avrdude avr-gcc git gawk ncurses make perl == Mac OSX == Using MacPorts (www.macports.org) Apple Bash and sed doesn't work, you need to install Bash V4.0 and GNU sed. First, sync the Port Repository to ensure that you´ll build the latest versions of the requirements. port selfupgrade port install git-core avrdude avr-binutils avr-gcc avr-libc bash sed You can also use the CrossPack, but MacPorts is more straightforward and updated. [http://www.obdev.at/products/crosspack/index-de.html] If the MacPort versions of avr-gcc or avrdude are too old. Here is a instuction how to build the toolchain manually: [http://www.heise.de/ct/projekte/machmit/ctbot/wiki/AVRToolchain] = Download the Source from GitHub = You can download Ethersex from github via git protocol git clone git://github.com/ethersex/ethersex.git or via http git clone http://github.com/ethersex/ethersex.git Updating a local version of ethersex is possible with: git pull origin [[Quick_Start_Guide/Configuration | next step]] 122b73fa6a8071c920169cc86cdce5db598069c2 6 170 415 2012-03-29T19:39:44Z Mgue 312 make menuconfig inside the hardware menu wikitext text/x-wiki make menuconfig inside the hardware menu ecabde9fe3969c4ed6a28c2ba7854e18edcf87d5 0 171 416 2012-03-29T22:57:08Z Mgue 312 first version wikitext text/x-wiki {{i18n|Quick Start Guide/Configuration}} [[File:E6menuconfig.png|right|thumb|400px| make menuconfig inside the hardware menu]] After [[Quick_Start_Guide/Preparation | installing the required software and cloning the repository]], ''cd'' to the root directory of ethersex. == General Settings == Type make menuconfig to start the text-based configuration UI of ethersex. Select the default configuration by selecting (enter). Load a Default Configuration ---> Now select for example Pollin AVR Net-IO Back in the main menu, enter General Setup ---> and select your '''Target MCU''' followed by the '''MCU frequency''' in Hz Go back to the main menu and enter the Network ---> menu. Select Ethernet (ENC28J60) support ---> and enter the '''MAC address''' Now adjust the '''IP address''' and '''Netmask''' for your network. Exit this menu as well as the '''Network''' menu. Hit the '''< Exit >''' button once again and select '''< Yes >''' to save your config. == Compiling == Run make to start the build process. This will only take a few seconds. If everything went well, which means you see something like this... <pre> =======The ethersex project======== Compiled for: atmega644p at 20000000Hz Imagesize: 36057/65536 bytes (55.02%) [================--------------] Program (.text + .data) : 28098 bytes Data (.data + .bss) : 1698 bytes =================================== </pre> ...you are ready to [[Quick_Start_Guide/Flashing | flash the firmware to your board!]] [[Quick_Start_Guide/Preparation | previous step]] | [[Quick_Start_Guide/Flashing | next step]] a211a44ad27326f2bc745c4e1b856d471f5fe0c9 0 42 417 265 2012-03-29T22:59:34Z Mgue 312 links wikitext text/x-wiki {{i18n|Quick Start Guide}} INTROTEXT GOES HERE [[Quick_Start_Guide/Preparation | Step 1: Preparation]] [[Quick_Start_Guide/Configuration | Step 2: Configuration]] [[Quick_Start_Guide/Flashing | Step 3: Flashing]] 63ee44b84418b2d4610d64ea2c6c896e050f4c28 0 172 418 2012-04-01T21:13:51Z Mgue 312 first version, pinning wikitext text/x-wiki {{Module |NAME=Onewire |MENUCONFIG={{I/O}}->Onewire support |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} = Pinning = Define your Onewire Pins with <source lang=c> ONEWIRE_PORT_RANGE(PX#, PX@) </source> where * PX# is a pin on PORTX * PX@ is a pin on PORTX every pin between and including PX# and PX@ will be a seperate Onewire bus. You can define up to eight buses on one PORT (all buses must be on the same PORT!) If you just need a single bus, define the range like this: <source lang=c> ONEWIRE_PORT_RANGE(PX#, PX#) </source> == Example == '''PORTD: PIN2, PIN3, PIN4''' <source lang=c> ONEWIRE_PORT_RANGE(PD2, PD4) </source> = Polling Mode = 2736475560c5f30cc315b58babca74a930c7d285 420 418 2012-04-01T23:33:54Z Mgue 312 i18n wikitext text/x-wiki {{i18n|Onewire}} {{Module |NAME=Onewire |MENUCONFIG={{I/O}}->Onewire support |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} = Pinning = Define your Onewire Pins with <source lang=c> ONEWIRE_PORT_RANGE(PX#, PX@) </source> where * PX# is a pin on PORTX * PX@ is a pin on PORTX every pin between and including PX# and PX@ will be a seperate Onewire bus. You can define up to eight buses on one PORT (all buses must be on the same PORT!) If you just need a single bus, define the range like this: <source lang=c> ONEWIRE_PORT_RANGE(PX#, PX#) </source> == Example == '''PORTD: PIN2, PIN3, PIN4''' <source lang=c> ONEWIRE_PORT_RANGE(PD2, PD4) </source> = Polling Mode = f12a106433518ee9f630a850f56929f723672f94 0 138 419 333 2012-04-01T23:02:40Z Mgue 312 typo fix wikitext text/x-wiki {{i18n|StellaLight}} {{Module |NAME=StellaLight |MENUCONFIG={{Applications}}->StellaLight: Multichannel pwm |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |DEPENDS=[[DMX Storage]] (optional) |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/services/stella https://github.com/ethersex/ethersex/tree/master/services/stella] }} StellaLight produces PWM signals on up to 16 independent pins for driving LEDs or servo motors. == Internals == Stella uses an 8-bit Timer of your choice for producing the PWM signals. Since the overflow interrupts need to be very consistent, StellaLight will not work flawlessy when other modules are active that disable the interrupts for a short amount of time. This is a list of module where you can expect some problems with: [[Onewire]], [[RFM12]] (please add more if you find some). Moreover StellaLight does not support [http://en.wikipedia.org/wiki/Gamma_correction Gamma Correction] since that would require at least 10-12 bit PWM. == Configuration == In Menuconfig you can select the prescaler. '''The higher the frequency, the more often the StellaLight PWM functions will be executed, leading to an higher overall load of the device. So if you run into problems, try decreasing the frequency, ergo increase the prescaler.''' {| border="1" ! Option ! Prescaler |- | Very slow | 1024 |- | Slow | 256 |- | Normal | 128 |- | Fast | 64 |- |} You can calculate the resulting frequency by using this formula: F_CPU: The clockspeed of your AVR (like 8Mhz, 16Mhz etc.) ''F_STELLA=F_CPU/Prescaler/512'' So given a setting of "Normal" on a 16Mhz device will result in '''244Hz''' which is pretty good for most setups. So more than enough for the human eye (10 times more) If you have enabled [[DMX Storage]] in Menuconfig, you also can set the universe and start channel of StellaLight, so you can control StellaLight via [[Artnet]] or [[DMX FXSlot]]. == Pinning == {| border="1" |- | STELLA_PORT1_RANGE(PX'''I''',PX'''J''') | sets the range ('''I''' to '''J''') of StellaLight controlled pins on PORTX |- | STELLA_PORT2_RANGE(PX2'''I''',PX2'''J''') | sets the range ('''I''' to '''J''') of StellaLight controlled pins on PORTX2 |- | STELLA_USE_TIMER('''I''') | programs Timer'''I''' for StellaLight |- |} Two examples: '''1. 3 LEDs (e.g. RGB) on PORTA, Pins: 0,1,2''' <source lang="c"> ifdef(`conf_STELLA', `dnl STELLA_PORT1_RANGE(PA0,PA2) STELLA_USE_TIMER(2) ')dnl </source> '''2. 15 LEDs (e.g. 5x RGB) on PORTA, Pins: 0,1,2,3,4,5,6,7 on PORTD, Pins: 0,1,2,3,4,5,6''' <source lang="c" > ifdef(`conf_STELLA', `dnl STELLA_PORT1_RANGE(PA0,PA7) STELLA_PORT2_RANGE(PD0,PD6) STELLA_USE_TIMER(2) ')dnl </source> == Alternative == Have a look at [[Starburst]] for an improved and more resource-conserving solution. [[Category:e6la]] ff83633cc31c548dbf70c69c42ac6feb894822fa 10 20 421 206 2012-04-01T23:52:15Z Mgue 312 no colspan here wikitext text/x-wiki <noinclude>{{i18n|Template:Facts}}</noinclude> {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | style="background-color: #FFFFFF; text-align: center; border-bottom:1px solid #aaaaaa;" | '''Overview''' |- |Ethersex is a community driven firmware with network support for 8-bit AVR microcontrollers. {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- !style="width:50%" | Features !style="width:50%" | Supported Boards |- | * Support for atmega 8,16,32,64,128,644 and many more * Uses the common '''ENC28J60''' * easily customizable and expandable to suit your needs Protocols: * TCP/IP IPv4/'''IPv6''' * OpenVPN * software USB stack * RFM12 / RFM12B (433 MHz / 868 MHz) * '''i²c''' Master (numerous chips supported)/Slave * onewire * http server * can be controlled remotely using the '''Ethersex Command Protocol (ECMD)''' * [[Features|and many more]] | * NetIO (Pollin) * Etherrape (lochraster.org) * AVR Module (Ulrich Radig) * Jackalope (lochraster.org * Probot (Conrad) * Fimser (OV Lennestadt) * JeeLink v2 (JeeLabs) * Funk-AVR-Evaluationsboard (Pollin) * TODO: Custom Board * [[Supported Boards |any many more]] |} |} 71da319db4b11abb22e9823b60518f8f548862d6 10 37 422 105 2012-04-01T23:52:38Z Mgue 312 no colspan here wikitext text/x-wiki <noinclude>{{i18n|Template:Getting Started}}</noinclude> {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | style="background-color: #FFFFFF; text-align: center; border-bottom:1px solid #aaaaaa;" | '''Getting started''' |- | * [[Quick Start Guide]] * [[Community]] * [[Contributing]] |} 330541b8a6a9e3d60e10feb78a4814a367aa8ec3 0 173 424 2012-04-02T00:09:45Z Mgue 312 first version....Yo dawg, I herd you like tables, so I put an table in your table so you can get mad while you get mad. wikitext text/x-wiki {{i18n|Ethersex Lighting Architecture}} = Design = {| style="width:100%" | colspan="2" | {| cellpadding="4" cellspacing="0" style="margin-top:5px; background:#F7F7F7; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | style="background-color: #93FF05; text-align: center; border-bottom:1px solid #aaaaaa;" | '''Display''' PWM/Servo Control Modules for Lighting Devices directly attached to ethersex |- | * [[StellaLight]] * [[Starburst]] * [[DMX_Storage#ECMD_commands | ECMD]] |} |- | colspan="2" style="background-color: #FF8C00; text-align: center; border-bottom:1px solid #aaaaaa; height:50px;" | '''[[DMX Storage | Storage]]''' provides an API for higher and lower layers (access and store) |- | style="width:50%" | {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#F7F7F7; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | style="background-color: #B9BCFF; text-align: center; border-bottom:1px solid #aaaaaa; " | '''Input/Modifiers''' receivers and modifiers for DMX data |- | * [[DMX]] * [[Artnet]] * [[DMX_Storage#ECMD_commands | ECMD]] * [[DMX_Storage#Web_GUI | HTTP]] * [[DMX FXSlot]] |} | style="width:50%" | {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#F7F7F7; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | style="background-color: #B9BCFF; text-align: center; border-bottom:1px solid #aaaaaa; " | '''Output''' DMX/Universe Routing (e.g. [[Artnet]] in => [[DMX]] RS485 out) |- | * [[DMX]] (not yet implemented) * [[Artnet]] * [[DMX_Storage#ECMD_commands | ECMD]] |} |} 9e288dd1382cc81c1d441e7cb58c3b89098a1793 425 424 2012-04-02T00:10:36Z Mgue 312 +[[Category:e6la]] wikitext text/x-wiki {{i18n|Ethersex Lighting Architecture}} = Design = {| style="width:100%" | colspan="2" | {| cellpadding="4" cellspacing="0" style="margin-top:5px; background:#F7F7F7; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | style="background-color: #93FF05; text-align: center; border-bottom:1px solid #aaaaaa;" | '''Display''' PWM/Servo Control Modules for Lighting Devices directly attached to ethersex |- | * [[StellaLight]] * [[Starburst]] * [[DMX_Storage#ECMD_commands | ECMD]] |} |- | colspan="2" style="background-color: #FF8C00; text-align: center; border-bottom:1px solid #aaaaaa; height:50px;" | '''[[DMX Storage | Storage]]''' provides an API for higher and lower layers (access and store) |- | style="width:50%" | {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#F7F7F7; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | style="background-color: #B9BCFF; text-align: center; border-bottom:1px solid #aaaaaa; " | '''Input/Modifiers''' receivers and modifiers for DMX data |- | * [[DMX]] * [[Artnet]] * [[DMX_Storage#ECMD_commands | ECMD]] * [[DMX_Storage#Web_GUI | HTTP]] * [[DMX FXSlot]] |} | style="width:50%" | {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#F7F7F7; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | style="background-color: #B9BCFF; text-align: center; border-bottom:1px solid #aaaaaa; " | '''Output''' DMX/Universe Routing (e.g. [[Artnet]] in => [[DMX]] RS485 out) |- | * [[DMX]] (not yet implemented) * [[Artnet]] * [[DMX_Storage#ECMD_commands | ECMD]] |} |} [[Category:e6la]] d73630ee8365e0c456c9e82d8de03f160008cc99 10 53 426 192 2012-04-02T00:12:10Z Mgue 312 no colspan here wikitext text/x-wiki <noinclude>{{i18n|Template:Getting Started}}</noinclude> {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | style="background-color: #FFFFFF; text-align: center; border-bottom:1px solid #aaaaaa;" | '''Einstieg''' |- | * [[Quick Start Guide (Deutsch)|Erste Schritte]] * [[Community (Deutsch)|Community]] * [[Contributing (Deutsch)|Mitmachen]] |} 45f7b6e65d2eb48252a36a4802d1e28dbae1eb83 10 56 427 205 2012-04-02T00:12:28Z Mgue 312 no colspan here wikitext text/x-wiki <noinclude>{{i18n|Template:Facts}}</noinclude> {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | style="background-color: #FFFFFF; text-align: center; border-bottom:1px solid #aaaaaa;" | '''Überblick''' |- |Ethersex eine Firmware mit Netzwerkunterstützung für 8-bit AVR Mikrokontroller, die durch eine Community entwickelt wird. {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- !style="width:50%" | Features !style="width:50%" | Unterstützte Boards |- | * unterstützt Atmega 8,16,32,64,128,644 und viele mehr * nutzt den Ethernet-Controller '''ENC28J60''' * leicht anzupassen und zu erweitern um deine Anforderungen zu erfüllen Protokolle: * TCP/IP IPv4/'''IPv6''' * OpenVPN * Software USB stack * RFM12 / RFM12B (433 MHz / 868 MHz) * '''i²c''' Master (Untersützung zahlreicher Chips) / Slave * onewire * http server * kann mit dem '''Ethersex Command Protocol (ECMD)''' ferngesteuert werden * [[Features (Deutsch)|und viele mehr]] | * NetIO (Pollin) * Etherrape (lochraster.org) * AVR Module (Ulrich Radig) * Jackalope (lochraster.org) * Probot (Conrad) * Fimser (OV Lennestadt) * JeeLink v2 (JeeLabs) * Funk-AVR-Evaluationsboard (Pollin) * TODO: Custom Board * [[Supported Boards (Deutsch)|und viele mehr]] |} |} b8daca91eb711ad07f78d4f2896a42f2ce1beb26 10 55 428 337 2012-04-02T00:12:59Z Mgue 312 no colspan here wikitext text/x-wiki <noinclude>{{i18n|Template:Documentation}}</noinclude> {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | style="background-color: #FFFFFF; text-align: center; border-bottom:1px solid #aaaaaa;" | '''Dokumentation''' |- | [[Wiki Guidelines (Deutsch)|Wiki Richtlinien]] ---- * [[:Category:Hardware|Hardware Treiber]] * [[:Category:Protocol|Protokoll Support]] * [[:Category:Application|Dienste und Applikationen]] * [[ECMD Reference|ECMD Befehlssatz]] |} 3805ccdc2c70e1e752e00978113fc3f3356d1d14 0 174 430 2012-04-02T13:05:30Z Sittner 461 Created page with "{{i18n|Tanklevel}} {{Module |NAME=Tank level meter |MENUCONFIG={{Applications}}->Tank level meter |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]], [[Clock]],…" wikitext text/x-wiki {{i18n|Tanklevel}} {{Module |NAME=Tank level meter |MENUCONFIG={{Applications}}->Tank level meter |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]], [[Clock]], [[ADC]], [[Cron]] (optional) |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/services/tanklevel https://github.com/ethersex/ethersex/tree/master/services/tanklevel] }} 5603f30813c6475ed8fe13bfbb4330cea244874e 431 430 2012-04-02T13:15:26Z Sittner 461 wikitext text/x-wiki {{i18n|Tanklevel}} {{Module |NAME=Tank level meter |MENUCONFIG={{Applications}}->Tank level meter |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]], [[Clock]], [[ADC]], [[Cron]] (optional) |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/services/tanklevel https://github.com/ethersex/ethersex/tree/master/services/tanklevel] }} Tanklevel provides an application for measurement of tank levels by hydrostatic pressure. == Internals == You need an aquarium air pump, some kind of pipe/tube, a Freescale MPX5050DP pressure sensor and an relay for the pump. Parameters are configurable by ECMD and stored in EEPROM. == Mechanical setup == +-------+ |Sensor | +---+---+ | +--------+ +---------------+-+ Pump | | +--------+ +------+------+ | | | | | | |------|------| | | | | | | | | | +-------------+ Tank == Electrical setup == Electrical Setup is quite simple. Connect the TANK_PUMP port with an relay (usually via an Transistor as current amp) and the output of the Sensor with the selected ADC channel (have a look at the datasheet for power supply decoupling and output filtering). Select a optimal Vref for the ADC if possible. fac23ebf3e8a7952d693b385faab8190fb830148 435 431 2012-04-02T13:32:34Z Sittner 461 wikitext text/x-wiki {{i18n|Tanklevel}} {{Module |NAME=Tank level meter |MENUCONFIG={{Applications}}->Tank level meter |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]], [[Clock]], [[ADC]], [[Cron]] (optional) |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/services/tanklevel https://github.com/ethersex/ethersex/tree/master/services/tanklevel] }} Tanklevel provides an application for measurement of tank levels by hydrostatic pressure. == Internals == You need an aquarium air pump, some kind of pipe/tube, a Freescale MPX5050DP pressure sensor and an relay for the pump. Parameters are configurable by ECMD and stored in EEPROM. == Mechanical setup == +-------+ |Sensor | +---+---+ | +--------+ +---------------+-+ Pump | | +--------+ +------+------+ | | | | | | |------|------| | | | | | | | | | +-------------+ Tank See the following example: [[File:Tanklevel_pump_assy.jpg|Pump assembly|177px]] [[File:Tanklevel_tank_assy.jpg|Tank assembly|100px]] == Electrical setup == Electrical Setup is quite simple. Connect the TANK_PUMP port with an relay (usually via an Transistor as current amp) and the output of the Sensor with the selected ADC channel (have a look at the datasheet for power supply decoupling and output filtering). Select a optimal Vref for the ADC if possible. Schematic could look like this: [[File:Tanklevel_schem.png|Electrical setup]] 7f966d6a3bde1185a49ad90722f52094153774b4 436 435 2012-04-02T14:22:29Z Sittner 461 wikitext text/x-wiki {{i18n|Tanklevel}} {{Module |NAME=Tank level meter |MENUCONFIG={{Applications}}->Tank level meter |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]], [[Clock]], [[ADC]], [[Cron]] (optional) |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/services/tanklevel https://github.com/ethersex/ethersex/tree/master/services/tanklevel] }} Tanklevel provides an application for measurement of tank levels by hydrostatic pressure. == Internals == You need an aquarium air pump, some kind of pipe/tube, a Freescale MPX5050DP pressure sensor and an relay for the pump. Parameters are configurable by ECMD and stored in EEPROM. == Configuration == │ │ (0) ADC channel │ │ │ │ [ ] Measure on system startup │ │ │ │ [ ] Measure at 12 am and 12 pm │ │ │ │ [ ] Inverted pump output │ │ │ │ [ ] Check lock input │ │ │ │ [ ] Inverted lock input │ │ │ │ [ ] Inline tank level │ │ * ADC channel - ADC channel that is connected to the MPX5050DP pressure sensor. * Measure on system startup - Start initial measurement at system startup. * Measure at 12 am and 12 pm - Start measurement at fixed time. Can be changed in services/cron/cron_static.c. * Inverted pump output - Output pin for pump is inverted. * Check lock input - Check lock pin before measurement and wait if needed. This is used to delay the measurement e.g. if the oil burner is running. * Inverted lock input - Lock input pin is inverted. * Inline tank level - Inline a page to query the tank level. == Pinning == Example pinning from pinning/hardware/netio.m4: ifdef(`conf_TANKLEVEL', ` pin(TANKLEVEL_PUMP, PC3, OUTPUT) ') ifdef(`conf_TANKLEVEL_LOCK', ` pin(TANKLEVEL_LOCK, PA2, INPUT) ') Meaning: * TANKLEVEL_PUMP - output pin for driving the pump relay * TANKLEVEL_LOCK - optional pin for external lock signal (see Configuration) == Mechanical setup == +-------+ |Sensor | +---+---+ | +--------+ +---------------+-+ Pump | | +--------+ +------+------+ | | | | | | |------|------| | | | | | | | | | +-------------+ Tank See the following example: [[File:Tanklevel_pump_assy.jpg|Pump assembly|177px]] [[File:Tanklevel_tank_assy.jpg|Tank assembly|100px]] == Electrical setup == Electrical setup is quite simple. Connect the TANK_PUMP port with an relay (usually via an Transistor as current amp) and the output of the Sensor with the selected ADC channel (have a look at the datasheet for power supply decoupling and output filtering). Select a optimal Vref for the ADC if possible. Schematic could look like this: [[File:Tanklevel_schem.png|Electrical setup]] == Parameters == Parameters can be viewed/set by ECMD commands: * sensor_offset - zero offset of the pressure sensor in mV * med_density - medium density in g/ltr (default of 840 for fuel oil) * ltr_per_m - Ltr per meter tank level * ltr_full - Tank capacity in ltr * raise_time - Pump time (in 1/50 secs) * hold_time - Hold time before measurement (in 1/50 secs) b5ea2be85098d1c36a5477f2965ea2fc66bf7c72 437 436 2012-04-02T14:49:28Z Sittner 461 wikitext text/x-wiki {{i18n|Tanklevel}} {{Module |NAME=Tank level meter |MENUCONFIG={{Applications}}->Tank level meter |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]], [[Clock]], [[ADC]], [[Cron]] (optional) |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/services/tanklevel https://github.com/ethersex/ethersex/tree/master/services/tanklevel] }} Tanklevel provides an application for measurement of tank levels by hydrostatic pressure. == Internals == You need an aquarium air pump, some kind of pipe/tube, a Freescale MPX5050DP pressure sensor and an relay for the pump. Parameters are configurable by ECMD and stored in EEPROM. == Configuration == │ │ (0) ADC channel │ │ │ │ [ ] Measure on system startup │ │ │ │ [ ] Measure at 12 am and 12 pm │ │ │ │ [ ] Inverted pump output │ │ │ │ [ ] Check lock input │ │ │ │ [ ] Inverted lock input │ │ │ │ [ ] Inline tank level │ │ * ADC channel - ADC channel that is connected to the MPX5050DP pressure sensor. * Measure on system startup - Start initial measurement at system startup. * Measure at 12 am and 12 pm - Start measurement at fixed time. Can be changed in services/cron/cron_static.c. * Inverted pump output - Output pin for pump is inverted. * Check lock input - Check lock pin before measurement and wait if needed. This is used to delay the measurement e.g. if the oil burner is running. * Inverted lock input - Lock input pin is inverted. * Inline tank level - Inline a page to query the tank level. == Pinning == Example pinning from pinning/hardware/netio.m4: ifdef(`conf_TANKLEVEL', ` pin(TANKLEVEL_PUMP, PC3, OUTPUT) ') ifdef(`conf_TANKLEVEL_LOCK', ` pin(TANKLEVEL_LOCK, PA2, INPUT) ') Meaning: * TANKLEVEL_PUMP - output pin for driving the pump relay * TANKLEVEL_LOCK - optional pin for external lock signal (see Configuration) == Mechanical setup == +-------+ |Sensor | +---+---+ | +--------+ +---------------+-+ Pump | | +--------+ +------+------+ | | | | | | |------|------| | | | | | | | | | +-------------+ Tank See the following example: [[File:Tanklevel_pump_assy.jpg|Pump assembly|177px]] [[File:Tanklevel_tank_assy.jpg|Tank assembly|100px]] == Electrical setup == Electrical setup is quite simple. Connect the TANK_PUMP port with an relay (usually via an Transistor as current amp) and the output of the Sensor with the selected ADC channel (have a look at the datasheet for power supply decoupling and output filtering). Select a optimal Vref for the ADC if possible. Schematic could look like this: [[File:Tanklevel_schem.png|Electrical setup]] == Parameters == Parameters can be viewed/set by ECMD commands: * sensor_offset - zero offset of the pressure sensor in mV * med_density - medium density in g/ltr (default of 840 for fuel oil) * ltr_per_m - Ltr per meter tank level * ltr_full - Tank capacity in ltr * raise_time - Pump time (in 1/50 secs) * hold_time - Hold time before measurement (in 1/50 secs) == SNMP support == If SNMP is enabled the level can be queried by this OID's: * .1.3.6.1.4.1.2021.13.23.4.0 = INTEGER: current level in ltr * .1.3.6.1.4.1.2021.13.23.4.1 = INTEGER: tank capacity in ltr * .1.3.6.1.4.1.2021.13.23.4.2 = INTEGER: timestamp of last measurement (unix date) * .1.3.6.1.4.1.2021.13.23.4.3 = STRING: timestamp of last measurement (clear text) cdda2de55d800d29763433cec192318e0f0f116b 6 175 432 2012-04-02T13:18:43Z Sittner 461 Tanklevel electrical setup wikitext text/x-wiki Tanklevel electrical setup 1c498a4d07f49d3aa28fc2b535edab4632cb65fa 6 176 433 2012-04-02T13:19:36Z Sittner 461 Tanklevel pump assembly wikitext text/x-wiki Tanklevel pump assembly 87aefebbf45a5b6c99fca24bf35a3c55b78d3f2d 6 177 434 2012-04-02T13:21:48Z Sittner 461 Tanklevel tank assembly wikitext text/x-wiki Tanklevel tank assembly fb69849f4e8a4fe7905c94730712f3206bf5ba5f 0 178 438 2012-04-04T17:34:25Z Sittner 461 Created page with "{{i18n|Cron}} {{Module |NAME=Tank level meter |MENUCONFIG={{Applications}}->Cron daemon |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]], [[Clock]] |REQUIRES= …" wikitext text/x-wiki {{i18n|Cron}} {{Module |NAME=Tank level meter |MENUCONFIG={{Applications}}->Cron daemon |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]], [[Clock]] |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/services/cron https://github.com/ethersex/ethersex/tree/master/services/cron] }} 519f2402aa929d468c7e82fe522aefc11b3babf6 445 438 2012-04-05T07:51:04Z Sittner 461 wikitext text/x-wiki {{i18n|Cron}} {{Module |NAME=Cron daemon |MENUCONFIG={{Applications}}->Cron daemon |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]], [[Clock]] |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/services/cron https://github.com/ethersex/ethersex/tree/master/services/cron] }} c38dd513c410cf8d8fa0cac5b69cfa19ab95fad3 446 445 2012-04-05T08:06:52Z Sittner 461 wikitext text/x-wiki {{i18n|Cron}} {{Module |NAME=Cron daemon |MENUCONFIG={{Applications}}->Cron daemon |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]], [[Clock]] |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/services/cron https://github.com/ethersex/ethersex/tree/master/services/cron] }} Cron daemon manage cron jobs. This rules define repeated or unique events that call certain commands. Cron jobs are implemented in two flavors: a static list that is defined at compile time and not changeable at runtime, and a dynamic approach, which loads the joblist to the RAM at statup. Jobs can be added and removed at runtime. == Preconditions == Beide Ansätze haben gemeinsam, dass du erst einmal eine Funktion definieren musst, welche vom Cron daemon zum bestimmten Zeitpunkt aufgerufen werden kann. Die Funktionssignatur sieht allerdings, abhängig davon welche Implementierung du wählst, leicht anders aus. == Menuconfig == Das Modul benötigt allerdings die aktuelle Zeit um richtig funktionieren zu können. Du musst daher im selben Untermenü mindestens eine Zeitquelle ebenfalls einschalten. Um Crontabs in ethersex zu aktivieren, wählt man im Menü │ │ Load a Default Configuration ---> │ │ ... │ │ Applications ---> │ │ ... │ │ [*] Cron daemon ---> │ │ [ ] Cron daemon (static jobs) == Static Cron Daemon == Die Funktion, welche der Daemon aufrufen soll, muss folgende Signatur haben '''void func(void)''' und muss direkt in cron_static/cron_static.c definiert werden. Es muss dann nur noch eine Regel in die Array Struktur events vom Typ ''cron_static_event_t'' eingefügt werden. Die Werte der Reihenfolge nach stehen für Minute, Stunde, Tag, Monat, Wochentag, Callback Funktion und ob UTC oder die lokale Zeitzone benutzt werden soll. Eine -1 steht für einen Platzhalter. Da die Einträge ca. jede Minute einmal geprüft werden, wird also ein Eintrag mit nur Platzhalter Werten auch ca. jede Minute ausgeführt. Werte unter -1 haben die Bedeutung von "jede x-te Minute/Stunde/etc". Also ein Wert von -4 an der Minutenstelle bedeutet, dass der Crontab jede 4te Minute ausgeführt wird. == Dynamic Cron Daemon == === View jobs via ecmd === Einfach den ecmd Befehl '''cron list''' zum Beispiel in deinem Browser ausführen. Es werden alle aktuellen Jobs angezeigt, pro Job zwei Zeilen. Die erste Zeile enthält die Attribute des Jobs (Position, Wiederholungen, ecmd/Callback-Job, UTC-Zeit, u.s.w.), in der zweiten Zeile werden die Zeitdaten (MIN HOUR DAY MONTH DAYOFWEEK) und der ecmd Befehl bzw. die Callback Addresse angezeigt. === Remove jobs via ecmd === '''cron rm N''' entfernt den Nten Job (fängt bei 0 an zu zählen) aus der cron Liste. Vorsicht! '''cron rm''' ohne Parameter entfernt ALLE cron jobs, und das ohne vorher nachzufragen! === Add jobs via ecmd === '''cron add MIN HOUR DAY MONTH DAYOFWEEK ECMD''' MIN HOUR DAY MONTH und DAYOFWEEK können -1 (als Platzhalterfunktion) annehmen. ECMD: Der ecmd Befehl, der ausgeführt werden soll. Nach dem Anlegen wird die Position des neuen Jobs in der Liste ausgegeben. === Mark job as persistent via ecmd === '''cron persistent N 1''' macht den Nten Job persistent '''cron persistent N 0''' löscht das persistent flag '''cron persistent N''' zeigt den aktuellen Status an === Write persistent jobs to VFS/EEPROM via ecmd === '''cron save''' alle als persistent markierten Jobs werden im VFS/EEPROM abgespeichert. === Mark job for UTC time via ecmd === '''cron utc N 1''' setzt den Nten Job auf UTC '''cron utc N 0''' löscht das UTC flag '''cron utc N''' zeigt den aktuellen Status an === Mark job as anacron job via ecmd === Dieses Flag bietet eine Art anacron-Funktion. Gedacht ist dies für Jobs, die bestimmte Stati setzen. Ein Beispiel wäre die Zirkulationspumpe einer Heizung. Angenommen die Pumpe soll um 6.00 Uhr eingesaltet und um 9.00 wieder ausgeschaltet werden, könnte das natürlich auch mit normalen Jobs erledigt werden. Sollte der Controller allerdings um 7.00 neu booten (z.B. wg. Stromausfall) bliebe Pumpe bis zum nächsten Tag 6.00 ausgeschaltet. Ähnliches gilt für grössere Zeitsprünge durch NTP-Updates. Um das Problem zu lösen, werden alle anacron-Jobs nachgezogen, die innerhalb des übersprungenen Zeitraums (also vom 1.1.1970 bis zur aktuellen Zeit im Falle das Boots) hätten ausgeführt werden müssen, wobei jeder Job nur einmal ausgeführt wird und auch in der korrekten Reihenfolge (jüngstes Ausführungsdatum zählt). Damit die Schleife zum Ermitteln der Jobs nicht unnötig lange dauert, ist der Startzeitpunkt in der Vergangenheit auf <Aktuelle Zeit> - CRON_ANACRON_MAXAGE Sekunden beschränkt. Voreingestellt ist hier ein Tag (86400 Sekunden). '''cron anacron N 1''' markiere den Nten Job als anacron Job '''cron anacron N 0''' löscht das UTC flag '''cron anacron N''' zeigt den aktuellen Status an === Define cronjob in source code: callback function === Wer scharf hinsieht, erkennt, dass diese Funktionalität auch durch den statischen Cron Daemon abgedeckt wird. Der statische Dienst verbraucht dabei sogar weniger Ressourcen. Aber, hier die Vorteile des dynamischen Dienstes: * Du musst keinen Quelltext in ein fremdes Modul einfügen (Übersichtlichkeit der cron_static.c nimmt mit jedem weiterem Modul ab) * Du kannst zur Laufzeit den cronjob auch wieder entfernen. * Du kannst Extradaten an die Callback Funktion übergeben Die Funktion, welche der Daemon aufrufen soll, muss folgende Signatur haben '''void func(char* data)''' und sollte ''nicht'' in der cron/cron.c Datei definiert werden, sondern in dem jeweiligen Modul, welche die Cron Funktionalität nutzen will. # Binde in dein Modul die Datei 'cron/cron.h' ein. # Nutze die Callback Variante des Cron-Einfügen Befehls '''cron_jobinsert_callback''' in der Initalisierungsfunktion deines Moduls um beim Start von ethersex cronjobs hinzuzufügen. # Die Funktionsparameter haben die folgende Semantik: * Minute, -1 für ignorieren, -2 für jede 2te Minute etc * Stunde, -1 für ignorieren, -2 für jede 2te Stunde etc * Tag, -1 für ignorieren, -2 für jeden 2te Tag etc * Monat, -1 für ignorieren, -2 für jeden 2te Monat etc * Wochentag, 1 für Sonntag, 2 für Montag, 4 für Dienstag, 8 für Mittwoch, 16 für Donnerstag, 32 für Freitag, 64 für Samstag oder eine Addition daraus * Wiederholen, INFINIT_RUNNING für endlos, 1=einmal etc * Position des Crons in der Cronliste (CRON_APPEND, wenn angehängt werden soll) * Callback Funktion * Größe von Extradaten * Extradaten Beispiel aus der Test Einträge Datei: void test(void* data) { /* tu was */ } // in init cron_jobinsert_callback(-1, -2, -1, -1, -1, INFINIT_RUNNING, CRON_APPEND, test, 0, NULL); Extradaten sind eine ziemlich coole Sache. Stella PWM zum Beispiel speichert darin Lichtkanal und Zielwert. Beim Aktivieren des Cronjobs wird der Zeiger auf diese Extradaten dann an die Callback Funktion mit übergeben und diese stehen direkt zur Verfügung. Bitte beachte hierbei aber, dass der Pointer auf die Extradaten durch einen Malloc Aufruf gewonnen werden muss, sprich die Speicherstelle für die Extradaten müssen vorher auf dem Heap allokiert werden. (Beispiel: '''char* extra = malloc(2);''' für 2 Bytes auf dem Heap) Du musst und solltest dich nicht um die Freigabe des allokierten Speichers kümmern. Dies erledigt der Cron daemon bereits. === Define cronjob in source code: ecmd command === Der statische cron daemon bot die Möglichkeit eine Funktion zu gegebenem Zeitpunkt aufzurufen. Wenn du jedoch den dynamischen Dienst nutzt, kannst du auch ecmd Befehle zeitabhängig aufrufen lassen (z.B. Pins setzen, Stella PWM kontrollieren, ethersex reseten etc). Die Funktion die du in dein Modul hierfür einbauen musst, lautet folgendermaßen: cron_jobinsert_ecmd(-1, -2, -1, -1, 127, INFINIT_RUNNING, CRON_APPEND, "ECMD"); 703cc3d9a1ec1baa73bca74b3c5fe06533c68639 447 446 2012-04-06T11:35:40Z Sittner 461 /* Preconditions */ wikitext text/x-wiki {{i18n|Cron}} {{Module |NAME=Cron daemon |MENUCONFIG={{Applications}}->Cron daemon |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]], [[Clock]] |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/services/cron https://github.com/ethersex/ethersex/tree/master/services/cron] }} Cron daemon manage cron jobs. This rules define repeated or unique events that call certain commands. Cron jobs are implemented in two flavors: a static list that is defined at compile time and not changeable at runtime, and a dynamic approach, which loads the joblist to the RAM at statup. Jobs can be added and removed at runtime. == Preconditions == Both approaches have in common that you need to define a function that is called from the con daemon at a appropriate time. The function signature, however, varies dependend on the choosen implementation. == Menuconfig == Das Modul benötigt allerdings die aktuelle Zeit um richtig funktionieren zu können. Du musst daher im selben Untermenü mindestens eine Zeitquelle ebenfalls einschalten. Um Crontabs in ethersex zu aktivieren, wählt man im Menü │ │ Load a Default Configuration ---> │ │ ... │ │ Applications ---> │ │ ... │ │ [*] Cron daemon ---> │ │ [ ] Cron daemon (static jobs) == Static Cron Daemon == Die Funktion, welche der Daemon aufrufen soll, muss folgende Signatur haben '''void func(void)''' und muss direkt in cron_static/cron_static.c definiert werden. Es muss dann nur noch eine Regel in die Array Struktur events vom Typ ''cron_static_event_t'' eingefügt werden. Die Werte der Reihenfolge nach stehen für Minute, Stunde, Tag, Monat, Wochentag, Callback Funktion und ob UTC oder die lokale Zeitzone benutzt werden soll. Eine -1 steht für einen Platzhalter. Da die Einträge ca. jede Minute einmal geprüft werden, wird also ein Eintrag mit nur Platzhalter Werten auch ca. jede Minute ausgeführt. Werte unter -1 haben die Bedeutung von "jede x-te Minute/Stunde/etc". Also ein Wert von -4 an der Minutenstelle bedeutet, dass der Crontab jede 4te Minute ausgeführt wird. == Dynamic Cron Daemon == === View jobs via ecmd === Einfach den ecmd Befehl '''cron list''' zum Beispiel in deinem Browser ausführen. Es werden alle aktuellen Jobs angezeigt, pro Job zwei Zeilen. Die erste Zeile enthält die Attribute des Jobs (Position, Wiederholungen, ecmd/Callback-Job, UTC-Zeit, u.s.w.), in der zweiten Zeile werden die Zeitdaten (MIN HOUR DAY MONTH DAYOFWEEK) und der ecmd Befehl bzw. die Callback Addresse angezeigt. === Remove jobs via ecmd === '''cron rm N''' entfernt den Nten Job (fängt bei 0 an zu zählen) aus der cron Liste. Vorsicht! '''cron rm''' ohne Parameter entfernt ALLE cron jobs, und das ohne vorher nachzufragen! === Add jobs via ecmd === '''cron add MIN HOUR DAY MONTH DAYOFWEEK ECMD''' MIN HOUR DAY MONTH und DAYOFWEEK können -1 (als Platzhalterfunktion) annehmen. ECMD: Der ecmd Befehl, der ausgeführt werden soll. Nach dem Anlegen wird die Position des neuen Jobs in der Liste ausgegeben. === Mark job as persistent via ecmd === '''cron persistent N 1''' macht den Nten Job persistent '''cron persistent N 0''' löscht das persistent flag '''cron persistent N''' zeigt den aktuellen Status an === Write persistent jobs to VFS/EEPROM via ecmd === '''cron save''' alle als persistent markierten Jobs werden im VFS/EEPROM abgespeichert. === Mark job for UTC time via ecmd === '''cron utc N 1''' setzt den Nten Job auf UTC '''cron utc N 0''' löscht das UTC flag '''cron utc N''' zeigt den aktuellen Status an === Mark job as anacron job via ecmd === Dieses Flag bietet eine Art anacron-Funktion. Gedacht ist dies für Jobs, die bestimmte Stati setzen. Ein Beispiel wäre die Zirkulationspumpe einer Heizung. Angenommen die Pumpe soll um 6.00 Uhr eingesaltet und um 9.00 wieder ausgeschaltet werden, könnte das natürlich auch mit normalen Jobs erledigt werden. Sollte der Controller allerdings um 7.00 neu booten (z.B. wg. Stromausfall) bliebe Pumpe bis zum nächsten Tag 6.00 ausgeschaltet. Ähnliches gilt für grössere Zeitsprünge durch NTP-Updates. Um das Problem zu lösen, werden alle anacron-Jobs nachgezogen, die innerhalb des übersprungenen Zeitraums (also vom 1.1.1970 bis zur aktuellen Zeit im Falle das Boots) hätten ausgeführt werden müssen, wobei jeder Job nur einmal ausgeführt wird und auch in der korrekten Reihenfolge (jüngstes Ausführungsdatum zählt). Damit die Schleife zum Ermitteln der Jobs nicht unnötig lange dauert, ist der Startzeitpunkt in der Vergangenheit auf <Aktuelle Zeit> - CRON_ANACRON_MAXAGE Sekunden beschränkt. Voreingestellt ist hier ein Tag (86400 Sekunden). '''cron anacron N 1''' markiere den Nten Job als anacron Job '''cron anacron N 0''' löscht das UTC flag '''cron anacron N''' zeigt den aktuellen Status an === Define cronjob in source code: callback function === Wer scharf hinsieht, erkennt, dass diese Funktionalität auch durch den statischen Cron Daemon abgedeckt wird. Der statische Dienst verbraucht dabei sogar weniger Ressourcen. Aber, hier die Vorteile des dynamischen Dienstes: * Du musst keinen Quelltext in ein fremdes Modul einfügen (Übersichtlichkeit der cron_static.c nimmt mit jedem weiterem Modul ab) * Du kannst zur Laufzeit den cronjob auch wieder entfernen. * Du kannst Extradaten an die Callback Funktion übergeben Die Funktion, welche der Daemon aufrufen soll, muss folgende Signatur haben '''void func(char* data)''' und sollte ''nicht'' in der cron/cron.c Datei definiert werden, sondern in dem jeweiligen Modul, welche die Cron Funktionalität nutzen will. # Binde in dein Modul die Datei 'cron/cron.h' ein. # Nutze die Callback Variante des Cron-Einfügen Befehls '''cron_jobinsert_callback''' in der Initalisierungsfunktion deines Moduls um beim Start von ethersex cronjobs hinzuzufügen. # Die Funktionsparameter haben die folgende Semantik: * Minute, -1 für ignorieren, -2 für jede 2te Minute etc * Stunde, -1 für ignorieren, -2 für jede 2te Stunde etc * Tag, -1 für ignorieren, -2 für jeden 2te Tag etc * Monat, -1 für ignorieren, -2 für jeden 2te Monat etc * Wochentag, 1 für Sonntag, 2 für Montag, 4 für Dienstag, 8 für Mittwoch, 16 für Donnerstag, 32 für Freitag, 64 für Samstag oder eine Addition daraus * Wiederholen, INFINIT_RUNNING für endlos, 1=einmal etc * Position des Crons in der Cronliste (CRON_APPEND, wenn angehängt werden soll) * Callback Funktion * Größe von Extradaten * Extradaten Beispiel aus der Test Einträge Datei: void test(void* data) { /* tu was */ } // in init cron_jobinsert_callback(-1, -2, -1, -1, -1, INFINIT_RUNNING, CRON_APPEND, test, 0, NULL); Extradaten sind eine ziemlich coole Sache. Stella PWM zum Beispiel speichert darin Lichtkanal und Zielwert. Beim Aktivieren des Cronjobs wird der Zeiger auf diese Extradaten dann an die Callback Funktion mit übergeben und diese stehen direkt zur Verfügung. Bitte beachte hierbei aber, dass der Pointer auf die Extradaten durch einen Malloc Aufruf gewonnen werden muss, sprich die Speicherstelle für die Extradaten müssen vorher auf dem Heap allokiert werden. (Beispiel: '''char* extra = malloc(2);''' für 2 Bytes auf dem Heap) Du musst und solltest dich nicht um die Freigabe des allokierten Speichers kümmern. Dies erledigt der Cron daemon bereits. === Define cronjob in source code: ecmd command === Der statische cron daemon bot die Möglichkeit eine Funktion zu gegebenem Zeitpunkt aufzurufen. Wenn du jedoch den dynamischen Dienst nutzt, kannst du auch ecmd Befehle zeitabhängig aufrufen lassen (z.B. Pins setzen, Stella PWM kontrollieren, ethersex reseten etc). Die Funktion die du in dein Modul hierfür einbauen musst, lautet folgendermaßen: cron_jobinsert_ecmd(-1, -2, -1, -1, 127, INFINIT_RUNNING, CRON_APPEND, "ECMD"); ed7a5a0c974ffa0e5eb089198d23777accf4f540 448 447 2012-04-06T11:39:33Z Sittner 461 /* Menuconfig */ wikitext text/x-wiki {{i18n|Cron}} {{Module |NAME=Cron daemon |MENUCONFIG={{Applications}}->Cron daemon |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]], [[Clock]] |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/services/cron https://github.com/ethersex/ethersex/tree/master/services/cron] }} Cron daemon manage cron jobs. This rules define repeated or unique events that call certain commands. Cron jobs are implemented in two flavors: a static list that is defined at compile time and not changeable at runtime, and a dynamic approach, which loads the joblist to the RAM at statup. Jobs can be added and removed at runtime. == Preconditions == Both approaches have in common that you need to define a function that is called from the con daemon at a appropriate time. The function signature, however, varies dependend on the choosen implementation. == Menuconfig == The module needs the current time to function properly. So you have to select at least one time source. To enable crontabs in ethersex select │ │ Load a Default Configuration ---> │ │ ... │ │ Applications ---> │ │ ... │ │ [*] Cron daemon ---> │ │ [ ] Cron daemon (static jobs) == Static Cron Daemon == Die Funktion, welche der Daemon aufrufen soll, muss folgende Signatur haben '''void func(void)''' und muss direkt in cron_static/cron_static.c definiert werden. Es muss dann nur noch eine Regel in die Array Struktur events vom Typ ''cron_static_event_t'' eingefügt werden. Die Werte der Reihenfolge nach stehen für Minute, Stunde, Tag, Monat, Wochentag, Callback Funktion und ob UTC oder die lokale Zeitzone benutzt werden soll. Eine -1 steht für einen Platzhalter. Da die Einträge ca. jede Minute einmal geprüft werden, wird also ein Eintrag mit nur Platzhalter Werten auch ca. jede Minute ausgeführt. Werte unter -1 haben die Bedeutung von "jede x-te Minute/Stunde/etc". Also ein Wert von -4 an der Minutenstelle bedeutet, dass der Crontab jede 4te Minute ausgeführt wird. == Dynamic Cron Daemon == === View jobs via ecmd === Einfach den ecmd Befehl '''cron list''' zum Beispiel in deinem Browser ausführen. Es werden alle aktuellen Jobs angezeigt, pro Job zwei Zeilen. Die erste Zeile enthält die Attribute des Jobs (Position, Wiederholungen, ecmd/Callback-Job, UTC-Zeit, u.s.w.), in der zweiten Zeile werden die Zeitdaten (MIN HOUR DAY MONTH DAYOFWEEK) und der ecmd Befehl bzw. die Callback Addresse angezeigt. === Remove jobs via ecmd === '''cron rm N''' entfernt den Nten Job (fängt bei 0 an zu zählen) aus der cron Liste. Vorsicht! '''cron rm''' ohne Parameter entfernt ALLE cron jobs, und das ohne vorher nachzufragen! === Add jobs via ecmd === '''cron add MIN HOUR DAY MONTH DAYOFWEEK ECMD''' MIN HOUR DAY MONTH und DAYOFWEEK können -1 (als Platzhalterfunktion) annehmen. ECMD: Der ecmd Befehl, der ausgeführt werden soll. Nach dem Anlegen wird die Position des neuen Jobs in der Liste ausgegeben. === Mark job as persistent via ecmd === '''cron persistent N 1''' macht den Nten Job persistent '''cron persistent N 0''' löscht das persistent flag '''cron persistent N''' zeigt den aktuellen Status an === Write persistent jobs to VFS/EEPROM via ecmd === '''cron save''' alle als persistent markierten Jobs werden im VFS/EEPROM abgespeichert. === Mark job for UTC time via ecmd === '''cron utc N 1''' setzt den Nten Job auf UTC '''cron utc N 0''' löscht das UTC flag '''cron utc N''' zeigt den aktuellen Status an === Mark job as anacron job via ecmd === Dieses Flag bietet eine Art anacron-Funktion. Gedacht ist dies für Jobs, die bestimmte Stati setzen. Ein Beispiel wäre die Zirkulationspumpe einer Heizung. Angenommen die Pumpe soll um 6.00 Uhr eingesaltet und um 9.00 wieder ausgeschaltet werden, könnte das natürlich auch mit normalen Jobs erledigt werden. Sollte der Controller allerdings um 7.00 neu booten (z.B. wg. Stromausfall) bliebe Pumpe bis zum nächsten Tag 6.00 ausgeschaltet. Ähnliches gilt für grössere Zeitsprünge durch NTP-Updates. Um das Problem zu lösen, werden alle anacron-Jobs nachgezogen, die innerhalb des übersprungenen Zeitraums (also vom 1.1.1970 bis zur aktuellen Zeit im Falle das Boots) hätten ausgeführt werden müssen, wobei jeder Job nur einmal ausgeführt wird und auch in der korrekten Reihenfolge (jüngstes Ausführungsdatum zählt). Damit die Schleife zum Ermitteln der Jobs nicht unnötig lange dauert, ist der Startzeitpunkt in der Vergangenheit auf <Aktuelle Zeit> - CRON_ANACRON_MAXAGE Sekunden beschränkt. Voreingestellt ist hier ein Tag (86400 Sekunden). '''cron anacron N 1''' markiere den Nten Job als anacron Job '''cron anacron N 0''' löscht das UTC flag '''cron anacron N''' zeigt den aktuellen Status an === Define cronjob in source code: callback function === Wer scharf hinsieht, erkennt, dass diese Funktionalität auch durch den statischen Cron Daemon abgedeckt wird. Der statische Dienst verbraucht dabei sogar weniger Ressourcen. Aber, hier die Vorteile des dynamischen Dienstes: * Du musst keinen Quelltext in ein fremdes Modul einfügen (Übersichtlichkeit der cron_static.c nimmt mit jedem weiterem Modul ab) * Du kannst zur Laufzeit den cronjob auch wieder entfernen. * Du kannst Extradaten an die Callback Funktion übergeben Die Funktion, welche der Daemon aufrufen soll, muss folgende Signatur haben '''void func(char* data)''' und sollte ''nicht'' in der cron/cron.c Datei definiert werden, sondern in dem jeweiligen Modul, welche die Cron Funktionalität nutzen will. # Binde in dein Modul die Datei 'cron/cron.h' ein. # Nutze die Callback Variante des Cron-Einfügen Befehls '''cron_jobinsert_callback''' in der Initalisierungsfunktion deines Moduls um beim Start von ethersex cronjobs hinzuzufügen. # Die Funktionsparameter haben die folgende Semantik: * Minute, -1 für ignorieren, -2 für jede 2te Minute etc * Stunde, -1 für ignorieren, -2 für jede 2te Stunde etc * Tag, -1 für ignorieren, -2 für jeden 2te Tag etc * Monat, -1 für ignorieren, -2 für jeden 2te Monat etc * Wochentag, 1 für Sonntag, 2 für Montag, 4 für Dienstag, 8 für Mittwoch, 16 für Donnerstag, 32 für Freitag, 64 für Samstag oder eine Addition daraus * Wiederholen, INFINIT_RUNNING für endlos, 1=einmal etc * Position des Crons in der Cronliste (CRON_APPEND, wenn angehängt werden soll) * Callback Funktion * Größe von Extradaten * Extradaten Beispiel aus der Test Einträge Datei: void test(void* data) { /* tu was */ } // in init cron_jobinsert_callback(-1, -2, -1, -1, -1, INFINIT_RUNNING, CRON_APPEND, test, 0, NULL); Extradaten sind eine ziemlich coole Sache. Stella PWM zum Beispiel speichert darin Lichtkanal und Zielwert. Beim Aktivieren des Cronjobs wird der Zeiger auf diese Extradaten dann an die Callback Funktion mit übergeben und diese stehen direkt zur Verfügung. Bitte beachte hierbei aber, dass der Pointer auf die Extradaten durch einen Malloc Aufruf gewonnen werden muss, sprich die Speicherstelle für die Extradaten müssen vorher auf dem Heap allokiert werden. (Beispiel: '''char* extra = malloc(2);''' für 2 Bytes auf dem Heap) Du musst und solltest dich nicht um die Freigabe des allokierten Speichers kümmern. Dies erledigt der Cron daemon bereits. === Define cronjob in source code: ecmd command === Der statische cron daemon bot die Möglichkeit eine Funktion zu gegebenem Zeitpunkt aufzurufen. Wenn du jedoch den dynamischen Dienst nutzt, kannst du auch ecmd Befehle zeitabhängig aufrufen lassen (z.B. Pins setzen, Stella PWM kontrollieren, ethersex reseten etc). Die Funktion die du in dein Modul hierfür einbauen musst, lautet folgendermaßen: cron_jobinsert_ecmd(-1, -2, -1, -1, 127, INFINIT_RUNNING, CRON_APPEND, "ECMD"); 02961935789d5be2ad956cb88c6648836ada98b9 449 448 2012-04-06T11:52:59Z Sittner 461 /* Static Cron Daemon */ wikitext text/x-wiki {{i18n|Cron}} {{Module |NAME=Cron daemon |MENUCONFIG={{Applications}}->Cron daemon |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]], [[Clock]] |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/services/cron https://github.com/ethersex/ethersex/tree/master/services/cron] }} Cron daemon manage cron jobs. This rules define repeated or unique events that call certain commands. Cron jobs are implemented in two flavors: a static list that is defined at compile time and not changeable at runtime, and a dynamic approach, which loads the joblist to the RAM at statup. Jobs can be added and removed at runtime. == Preconditions == Both approaches have in common that you need to define a function that is called from the con daemon at a appropriate time. The function signature, however, varies dependend on the choosen implementation. == Menuconfig == The module needs the current time to function properly. So you have to select at least one time source. To enable crontabs in ethersex select │ │ Load a Default Configuration ---> │ │ ... │ │ Applications ---> │ │ ... │ │ [*] Cron daemon ---> │ │ [ ] Cron daemon (static jobs) == Static Cron Daemon == The function to be called from the daemon has to have the signature '''void func(void)''' and has to be defined in cron_static/cron_static.c. Furthermore you have to insert a rule of the type ''cron_static_event_t'' to the structure array ''events''. The meaning of the values are minute, hour, day, month, days of week, callback function and a flag if UTC or local time is used (in that order). A value of -1 is a wildcard. The entries are checked every minute, so an entry with all wildcards will be executed every minute. Values less than -1 mean "every x-th minute/hour/etc.". So in case of -4 in the minute field the job will be executed every 4th minute. == Dynamic Cron Daemon == === View jobs via ecmd === Einfach den ecmd Befehl '''cron list''' zum Beispiel in deinem Browser ausführen. Es werden alle aktuellen Jobs angezeigt, pro Job zwei Zeilen. Die erste Zeile enthält die Attribute des Jobs (Position, Wiederholungen, ecmd/Callback-Job, UTC-Zeit, u.s.w.), in der zweiten Zeile werden die Zeitdaten (MIN HOUR DAY MONTH DAYOFWEEK) und der ecmd Befehl bzw. die Callback Addresse angezeigt. === Remove jobs via ecmd === '''cron rm N''' entfernt den Nten Job (fängt bei 0 an zu zählen) aus der cron Liste. Vorsicht! '''cron rm''' ohne Parameter entfernt ALLE cron jobs, und das ohne vorher nachzufragen! === Add jobs via ecmd === '''cron add MIN HOUR DAY MONTH DAYOFWEEK ECMD''' MIN HOUR DAY MONTH und DAYOFWEEK können -1 (als Platzhalterfunktion) annehmen. ECMD: Der ecmd Befehl, der ausgeführt werden soll. Nach dem Anlegen wird die Position des neuen Jobs in der Liste ausgegeben. === Mark job as persistent via ecmd === '''cron persistent N 1''' macht den Nten Job persistent '''cron persistent N 0''' löscht das persistent flag '''cron persistent N''' zeigt den aktuellen Status an === Write persistent jobs to VFS/EEPROM via ecmd === '''cron save''' alle als persistent markierten Jobs werden im VFS/EEPROM abgespeichert. === Mark job for UTC time via ecmd === '''cron utc N 1''' setzt den Nten Job auf UTC '''cron utc N 0''' löscht das UTC flag '''cron utc N''' zeigt den aktuellen Status an === Mark job as anacron job via ecmd === Dieses Flag bietet eine Art anacron-Funktion. Gedacht ist dies für Jobs, die bestimmte Stati setzen. Ein Beispiel wäre die Zirkulationspumpe einer Heizung. Angenommen die Pumpe soll um 6.00 Uhr eingesaltet und um 9.00 wieder ausgeschaltet werden, könnte das natürlich auch mit normalen Jobs erledigt werden. Sollte der Controller allerdings um 7.00 neu booten (z.B. wg. Stromausfall) bliebe Pumpe bis zum nächsten Tag 6.00 ausgeschaltet. Ähnliches gilt für grössere Zeitsprünge durch NTP-Updates. Um das Problem zu lösen, werden alle anacron-Jobs nachgezogen, die innerhalb des übersprungenen Zeitraums (also vom 1.1.1970 bis zur aktuellen Zeit im Falle das Boots) hätten ausgeführt werden müssen, wobei jeder Job nur einmal ausgeführt wird und auch in der korrekten Reihenfolge (jüngstes Ausführungsdatum zählt). Damit die Schleife zum Ermitteln der Jobs nicht unnötig lange dauert, ist der Startzeitpunkt in der Vergangenheit auf <Aktuelle Zeit> - CRON_ANACRON_MAXAGE Sekunden beschränkt. Voreingestellt ist hier ein Tag (86400 Sekunden). '''cron anacron N 1''' markiere den Nten Job als anacron Job '''cron anacron N 0''' löscht das UTC flag '''cron anacron N''' zeigt den aktuellen Status an === Define cronjob in source code: callback function === Wer scharf hinsieht, erkennt, dass diese Funktionalität auch durch den statischen Cron Daemon abgedeckt wird. Der statische Dienst verbraucht dabei sogar weniger Ressourcen. Aber, hier die Vorteile des dynamischen Dienstes: * Du musst keinen Quelltext in ein fremdes Modul einfügen (Übersichtlichkeit der cron_static.c nimmt mit jedem weiterem Modul ab) * Du kannst zur Laufzeit den cronjob auch wieder entfernen. * Du kannst Extradaten an die Callback Funktion übergeben Die Funktion, welche der Daemon aufrufen soll, muss folgende Signatur haben '''void func(char* data)''' und sollte ''nicht'' in der cron/cron.c Datei definiert werden, sondern in dem jeweiligen Modul, welche die Cron Funktionalität nutzen will. # Binde in dein Modul die Datei 'cron/cron.h' ein. # Nutze die Callback Variante des Cron-Einfügen Befehls '''cron_jobinsert_callback''' in der Initalisierungsfunktion deines Moduls um beim Start von ethersex cronjobs hinzuzufügen. # Die Funktionsparameter haben die folgende Semantik: * Minute, -1 für ignorieren, -2 für jede 2te Minute etc * Stunde, -1 für ignorieren, -2 für jede 2te Stunde etc * Tag, -1 für ignorieren, -2 für jeden 2te Tag etc * Monat, -1 für ignorieren, -2 für jeden 2te Monat etc * Wochentag, 1 für Sonntag, 2 für Montag, 4 für Dienstag, 8 für Mittwoch, 16 für Donnerstag, 32 für Freitag, 64 für Samstag oder eine Addition daraus * Wiederholen, INFINIT_RUNNING für endlos, 1=einmal etc * Position des Crons in der Cronliste (CRON_APPEND, wenn angehängt werden soll) * Callback Funktion * Größe von Extradaten * Extradaten Beispiel aus der Test Einträge Datei: void test(void* data) { /* tu was */ } // in init cron_jobinsert_callback(-1, -2, -1, -1, -1, INFINIT_RUNNING, CRON_APPEND, test, 0, NULL); Extradaten sind eine ziemlich coole Sache. Stella PWM zum Beispiel speichert darin Lichtkanal und Zielwert. Beim Aktivieren des Cronjobs wird der Zeiger auf diese Extradaten dann an die Callback Funktion mit übergeben und diese stehen direkt zur Verfügung. Bitte beachte hierbei aber, dass der Pointer auf die Extradaten durch einen Malloc Aufruf gewonnen werden muss, sprich die Speicherstelle für die Extradaten müssen vorher auf dem Heap allokiert werden. (Beispiel: '''char* extra = malloc(2);''' für 2 Bytes auf dem Heap) Du musst und solltest dich nicht um die Freigabe des allokierten Speichers kümmern. Dies erledigt der Cron daemon bereits. === Define cronjob in source code: ecmd command === Der statische cron daemon bot die Möglichkeit eine Funktion zu gegebenem Zeitpunkt aufzurufen. Wenn du jedoch den dynamischen Dienst nutzt, kannst du auch ecmd Befehle zeitabhängig aufrufen lassen (z.B. Pins setzen, Stella PWM kontrollieren, ethersex reseten etc). Die Funktion die du in dein Modul hierfür einbauen musst, lautet folgendermaßen: cron_jobinsert_ecmd(-1, -2, -1, -1, 127, INFINIT_RUNNING, CRON_APPEND, "ECMD"); b7f537db889d069763d07d3b840ce62e48485d2e 450 449 2012-04-06T12:00:10Z Sittner 461 /* View jobs via ecmd */ wikitext text/x-wiki {{i18n|Cron}} {{Module |NAME=Cron daemon |MENUCONFIG={{Applications}}->Cron daemon |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]], [[Clock]] |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/services/cron https://github.com/ethersex/ethersex/tree/master/services/cron] }} Cron daemon manage cron jobs. This rules define repeated or unique events that call certain commands. Cron jobs are implemented in two flavors: a static list that is defined at compile time and not changeable at runtime, and a dynamic approach, which loads the joblist to the RAM at statup. Jobs can be added and removed at runtime. == Preconditions == Both approaches have in common that you need to define a function that is called from the con daemon at a appropriate time. The function signature, however, varies dependend on the choosen implementation. == Menuconfig == The module needs the current time to function properly. So you have to select at least one time source. To enable crontabs in ethersex select │ │ Load a Default Configuration ---> │ │ ... │ │ Applications ---> │ │ ... │ │ [*] Cron daemon ---> │ │ [ ] Cron daemon (static jobs) == Static Cron Daemon == The function to be called from the daemon has to have the signature '''void func(void)''' and has to be defined in cron_static/cron_static.c. Furthermore you have to insert a rule of the type ''cron_static_event_t'' to the structure array ''events''. The meaning of the values are minute, hour, day, month, days of week, callback function and a flag if UTC or local time is used (in that order). A value of -1 is a wildcard. The entries are checked every minute, so an entry with all wildcards will be executed every minute. Values less than -1 mean "every x-th minute/hour/etc.". So in case of -4 in the minute field the job will be executed every 4th minute. == Dynamic Cron Daemon == === View jobs via ecmd === Simply execute the ecmd command '''cron list''' i.e. in your browser. All jobs will be displayed, two lines for each job. The first line contains the job attributes (position, repeats, ecmd/callback job, use UTC, etc.), the second line shows the timing data (MIN HOUR DAY MONTH DAYOFWEEK) and the ecmd command/address of the callback function to be executed. === Remove jobs via ecmd === '''cron rm N''' entfernt den Nten Job (fängt bei 0 an zu zählen) aus der cron Liste. Vorsicht! '''cron rm''' ohne Parameter entfernt ALLE cron jobs, und das ohne vorher nachzufragen! === Add jobs via ecmd === '''cron add MIN HOUR DAY MONTH DAYOFWEEK ECMD''' MIN HOUR DAY MONTH und DAYOFWEEK können -1 (als Platzhalterfunktion) annehmen. ECMD: Der ecmd Befehl, der ausgeführt werden soll. Nach dem Anlegen wird die Position des neuen Jobs in der Liste ausgegeben. === Mark job as persistent via ecmd === '''cron persistent N 1''' macht den Nten Job persistent '''cron persistent N 0''' löscht das persistent flag '''cron persistent N''' zeigt den aktuellen Status an === Write persistent jobs to VFS/EEPROM via ecmd === '''cron save''' alle als persistent markierten Jobs werden im VFS/EEPROM abgespeichert. === Mark job for UTC time via ecmd === '''cron utc N 1''' setzt den Nten Job auf UTC '''cron utc N 0''' löscht das UTC flag '''cron utc N''' zeigt den aktuellen Status an === Mark job as anacron job via ecmd === Dieses Flag bietet eine Art anacron-Funktion. Gedacht ist dies für Jobs, die bestimmte Stati setzen. Ein Beispiel wäre die Zirkulationspumpe einer Heizung. Angenommen die Pumpe soll um 6.00 Uhr eingesaltet und um 9.00 wieder ausgeschaltet werden, könnte das natürlich auch mit normalen Jobs erledigt werden. Sollte der Controller allerdings um 7.00 neu booten (z.B. wg. Stromausfall) bliebe Pumpe bis zum nächsten Tag 6.00 ausgeschaltet. Ähnliches gilt für grössere Zeitsprünge durch NTP-Updates. Um das Problem zu lösen, werden alle anacron-Jobs nachgezogen, die innerhalb des übersprungenen Zeitraums (also vom 1.1.1970 bis zur aktuellen Zeit im Falle das Boots) hätten ausgeführt werden müssen, wobei jeder Job nur einmal ausgeführt wird und auch in der korrekten Reihenfolge (jüngstes Ausführungsdatum zählt). Damit die Schleife zum Ermitteln der Jobs nicht unnötig lange dauert, ist der Startzeitpunkt in der Vergangenheit auf <Aktuelle Zeit> - CRON_ANACRON_MAXAGE Sekunden beschränkt. Voreingestellt ist hier ein Tag (86400 Sekunden). '''cron anacron N 1''' markiere den Nten Job als anacron Job '''cron anacron N 0''' löscht das UTC flag '''cron anacron N''' zeigt den aktuellen Status an === Define cronjob in source code: callback function === Wer scharf hinsieht, erkennt, dass diese Funktionalität auch durch den statischen Cron Daemon abgedeckt wird. Der statische Dienst verbraucht dabei sogar weniger Ressourcen. Aber, hier die Vorteile des dynamischen Dienstes: * Du musst keinen Quelltext in ein fremdes Modul einfügen (Übersichtlichkeit der cron_static.c nimmt mit jedem weiterem Modul ab) * Du kannst zur Laufzeit den cronjob auch wieder entfernen. * Du kannst Extradaten an die Callback Funktion übergeben Die Funktion, welche der Daemon aufrufen soll, muss folgende Signatur haben '''void func(char* data)''' und sollte ''nicht'' in der cron/cron.c Datei definiert werden, sondern in dem jeweiligen Modul, welche die Cron Funktionalität nutzen will. # Binde in dein Modul die Datei 'cron/cron.h' ein. # Nutze die Callback Variante des Cron-Einfügen Befehls '''cron_jobinsert_callback''' in der Initalisierungsfunktion deines Moduls um beim Start von ethersex cronjobs hinzuzufügen. # Die Funktionsparameter haben die folgende Semantik: * Minute, -1 für ignorieren, -2 für jede 2te Minute etc * Stunde, -1 für ignorieren, -2 für jede 2te Stunde etc * Tag, -1 für ignorieren, -2 für jeden 2te Tag etc * Monat, -1 für ignorieren, -2 für jeden 2te Monat etc * Wochentag, 1 für Sonntag, 2 für Montag, 4 für Dienstag, 8 für Mittwoch, 16 für Donnerstag, 32 für Freitag, 64 für Samstag oder eine Addition daraus * Wiederholen, INFINIT_RUNNING für endlos, 1=einmal etc * Position des Crons in der Cronliste (CRON_APPEND, wenn angehängt werden soll) * Callback Funktion * Größe von Extradaten * Extradaten Beispiel aus der Test Einträge Datei: void test(void* data) { /* tu was */ } // in init cron_jobinsert_callback(-1, -2, -1, -1, -1, INFINIT_RUNNING, CRON_APPEND, test, 0, NULL); Extradaten sind eine ziemlich coole Sache. Stella PWM zum Beispiel speichert darin Lichtkanal und Zielwert. Beim Aktivieren des Cronjobs wird der Zeiger auf diese Extradaten dann an die Callback Funktion mit übergeben und diese stehen direkt zur Verfügung. Bitte beachte hierbei aber, dass der Pointer auf die Extradaten durch einen Malloc Aufruf gewonnen werden muss, sprich die Speicherstelle für die Extradaten müssen vorher auf dem Heap allokiert werden. (Beispiel: '''char* extra = malloc(2);''' für 2 Bytes auf dem Heap) Du musst und solltest dich nicht um die Freigabe des allokierten Speichers kümmern. Dies erledigt der Cron daemon bereits. === Define cronjob in source code: ecmd command === Der statische cron daemon bot die Möglichkeit eine Funktion zu gegebenem Zeitpunkt aufzurufen. Wenn du jedoch den dynamischen Dienst nutzt, kannst du auch ecmd Befehle zeitabhängig aufrufen lassen (z.B. Pins setzen, Stella PWM kontrollieren, ethersex reseten etc). Die Funktion die du in dein Modul hierfür einbauen musst, lautet folgendermaßen: cron_jobinsert_ecmd(-1, -2, -1, -1, 127, INFINIT_RUNNING, CRON_APPEND, "ECMD"); 4b896fa24eef626041d9598f41a9b7b09dc962e7 451 450 2012-04-06T12:04:33Z Sittner 461 /* Remove jobs via ecmd */ wikitext text/x-wiki {{i18n|Cron}} {{Module |NAME=Cron daemon |MENUCONFIG={{Applications}}->Cron daemon |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]], [[Clock]] |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/services/cron https://github.com/ethersex/ethersex/tree/master/services/cron] }} Cron daemon manage cron jobs. This rules define repeated or unique events that call certain commands. Cron jobs are implemented in two flavors: a static list that is defined at compile time and not changeable at runtime, and a dynamic approach, which loads the joblist to the RAM at statup. Jobs can be added and removed at runtime. == Preconditions == Both approaches have in common that you need to define a function that is called from the con daemon at a appropriate time. The function signature, however, varies dependend on the choosen implementation. == Menuconfig == The module needs the current time to function properly. So you have to select at least one time source. To enable crontabs in ethersex select │ │ Load a Default Configuration ---> │ │ ... │ │ Applications ---> │ │ ... │ │ [*] Cron daemon ---> │ │ [ ] Cron daemon (static jobs) == Static Cron Daemon == The function to be called from the daemon has to have the signature '''void func(void)''' and has to be defined in cron_static/cron_static.c. Furthermore you have to insert a rule of the type ''cron_static_event_t'' to the structure array ''events''. The meaning of the values are minute, hour, day, month, days of week, callback function and a flag if UTC or local time is used (in that order). A value of -1 is a wildcard. The entries are checked every minute, so an entry with all wildcards will be executed every minute. Values less than -1 mean "every x-th minute/hour/etc.". So in case of -4 in the minute field the job will be executed every 4th minute. == Dynamic Cron Daemon == === View jobs via ecmd === Simply execute the ecmd command '''cron list''' i.e. in your browser. All jobs will be displayed, two lines for each job. The first line contains the job attributes (position, repeats, ecmd/callback job, use UTC, etc.), the second line shows the timing data (MIN HOUR DAY MONTH DAYOFWEEK) and the ecmd command/address of the callback function to be executed. === Remove jobs via ecmd === '''cron rm N''' removes the Nth job (start counting at 0) from the cron list. Caution! '''cron rm''' without paramater removes ALL jobs without confirmation request! === Add jobs via ecmd === '''cron add MIN HOUR DAY MONTH DAYOFWEEK ECMD''' MIN HOUR DAY MONTH und DAYOFWEEK können -1 (als Platzhalterfunktion) annehmen. ECMD: Der ecmd Befehl, der ausgeführt werden soll. Nach dem Anlegen wird die Position des neuen Jobs in der Liste ausgegeben. === Mark job as persistent via ecmd === '''cron persistent N 1''' macht den Nten Job persistent '''cron persistent N 0''' löscht das persistent flag '''cron persistent N''' zeigt den aktuellen Status an === Write persistent jobs to VFS/EEPROM via ecmd === '''cron save''' alle als persistent markierten Jobs werden im VFS/EEPROM abgespeichert. === Mark job for UTC time via ecmd === '''cron utc N 1''' setzt den Nten Job auf UTC '''cron utc N 0''' löscht das UTC flag '''cron utc N''' zeigt den aktuellen Status an === Mark job as anacron job via ecmd === Dieses Flag bietet eine Art anacron-Funktion. Gedacht ist dies für Jobs, die bestimmte Stati setzen. Ein Beispiel wäre die Zirkulationspumpe einer Heizung. Angenommen die Pumpe soll um 6.00 Uhr eingesaltet und um 9.00 wieder ausgeschaltet werden, könnte das natürlich auch mit normalen Jobs erledigt werden. Sollte der Controller allerdings um 7.00 neu booten (z.B. wg. Stromausfall) bliebe Pumpe bis zum nächsten Tag 6.00 ausgeschaltet. Ähnliches gilt für grössere Zeitsprünge durch NTP-Updates. Um das Problem zu lösen, werden alle anacron-Jobs nachgezogen, die innerhalb des übersprungenen Zeitraums (also vom 1.1.1970 bis zur aktuellen Zeit im Falle das Boots) hätten ausgeführt werden müssen, wobei jeder Job nur einmal ausgeführt wird und auch in der korrekten Reihenfolge (jüngstes Ausführungsdatum zählt). Damit die Schleife zum Ermitteln der Jobs nicht unnötig lange dauert, ist der Startzeitpunkt in der Vergangenheit auf <Aktuelle Zeit> - CRON_ANACRON_MAXAGE Sekunden beschränkt. Voreingestellt ist hier ein Tag (86400 Sekunden). '''cron anacron N 1''' markiere den Nten Job als anacron Job '''cron anacron N 0''' löscht das UTC flag '''cron anacron N''' zeigt den aktuellen Status an === Define cronjob in source code: callback function === Wer scharf hinsieht, erkennt, dass diese Funktionalität auch durch den statischen Cron Daemon abgedeckt wird. Der statische Dienst verbraucht dabei sogar weniger Ressourcen. Aber, hier die Vorteile des dynamischen Dienstes: * Du musst keinen Quelltext in ein fremdes Modul einfügen (Übersichtlichkeit der cron_static.c nimmt mit jedem weiterem Modul ab) * Du kannst zur Laufzeit den cronjob auch wieder entfernen. * Du kannst Extradaten an die Callback Funktion übergeben Die Funktion, welche der Daemon aufrufen soll, muss folgende Signatur haben '''void func(char* data)''' und sollte ''nicht'' in der cron/cron.c Datei definiert werden, sondern in dem jeweiligen Modul, welche die Cron Funktionalität nutzen will. # Binde in dein Modul die Datei 'cron/cron.h' ein. # Nutze die Callback Variante des Cron-Einfügen Befehls '''cron_jobinsert_callback''' in der Initalisierungsfunktion deines Moduls um beim Start von ethersex cronjobs hinzuzufügen. # Die Funktionsparameter haben die folgende Semantik: * Minute, -1 für ignorieren, -2 für jede 2te Minute etc * Stunde, -1 für ignorieren, -2 für jede 2te Stunde etc * Tag, -1 für ignorieren, -2 für jeden 2te Tag etc * Monat, -1 für ignorieren, -2 für jeden 2te Monat etc * Wochentag, 1 für Sonntag, 2 für Montag, 4 für Dienstag, 8 für Mittwoch, 16 für Donnerstag, 32 für Freitag, 64 für Samstag oder eine Addition daraus * Wiederholen, INFINIT_RUNNING für endlos, 1=einmal etc * Position des Crons in der Cronliste (CRON_APPEND, wenn angehängt werden soll) * Callback Funktion * Größe von Extradaten * Extradaten Beispiel aus der Test Einträge Datei: void test(void* data) { /* tu was */ } // in init cron_jobinsert_callback(-1, -2, -1, -1, -1, INFINIT_RUNNING, CRON_APPEND, test, 0, NULL); Extradaten sind eine ziemlich coole Sache. Stella PWM zum Beispiel speichert darin Lichtkanal und Zielwert. Beim Aktivieren des Cronjobs wird der Zeiger auf diese Extradaten dann an die Callback Funktion mit übergeben und diese stehen direkt zur Verfügung. Bitte beachte hierbei aber, dass der Pointer auf die Extradaten durch einen Malloc Aufruf gewonnen werden muss, sprich die Speicherstelle für die Extradaten müssen vorher auf dem Heap allokiert werden. (Beispiel: '''char* extra = malloc(2);''' für 2 Bytes auf dem Heap) Du musst und solltest dich nicht um die Freigabe des allokierten Speichers kümmern. Dies erledigt der Cron daemon bereits. === Define cronjob in source code: ecmd command === Der statische cron daemon bot die Möglichkeit eine Funktion zu gegebenem Zeitpunkt aufzurufen. Wenn du jedoch den dynamischen Dienst nutzt, kannst du auch ecmd Befehle zeitabhängig aufrufen lassen (z.B. Pins setzen, Stella PWM kontrollieren, ethersex reseten etc). Die Funktion die du in dein Modul hierfür einbauen musst, lautet folgendermaßen: cron_jobinsert_ecmd(-1, -2, -1, -1, 127, INFINIT_RUNNING, CRON_APPEND, "ECMD"); fc185aa4a5b437d76484521c8414547b064d568d 452 451 2012-04-06T12:08:17Z Sittner 461 /* Add jobs via ecmd */ wikitext text/x-wiki {{i18n|Cron}} {{Module |NAME=Cron daemon |MENUCONFIG={{Applications}}->Cron daemon |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]], [[Clock]] |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/services/cron https://github.com/ethersex/ethersex/tree/master/services/cron] }} Cron daemon manage cron jobs. This rules define repeated or unique events that call certain commands. Cron jobs are implemented in two flavors: a static list that is defined at compile time and not changeable at runtime, and a dynamic approach, which loads the joblist to the RAM at statup. Jobs can be added and removed at runtime. == Preconditions == Both approaches have in common that you need to define a function that is called from the con daemon at a appropriate time. The function signature, however, varies dependend on the choosen implementation. == Menuconfig == The module needs the current time to function properly. So you have to select at least one time source. To enable crontabs in ethersex select │ │ Load a Default Configuration ---> │ │ ... │ │ Applications ---> │ │ ... │ │ [*] Cron daemon ---> │ │ [ ] Cron daemon (static jobs) == Static Cron Daemon == The function to be called from the daemon has to have the signature '''void func(void)''' and has to be defined in cron_static/cron_static.c. Furthermore you have to insert a rule of the type ''cron_static_event_t'' to the structure array ''events''. The meaning of the values are minute, hour, day, month, days of week, callback function and a flag if UTC or local time is used (in that order). A value of -1 is a wildcard. The entries are checked every minute, so an entry with all wildcards will be executed every minute. Values less than -1 mean "every x-th minute/hour/etc.". So in case of -4 in the minute field the job will be executed every 4th minute. == Dynamic Cron Daemon == === View jobs via ecmd === Simply execute the ecmd command '''cron list''' i.e. in your browser. All jobs will be displayed, two lines for each job. The first line contains the job attributes (position, repeats, ecmd/callback job, use UTC, etc.), the second line shows the timing data (MIN HOUR DAY MONTH DAYOFWEEK) and the ecmd command/address of the callback function to be executed. === Remove jobs via ecmd === '''cron rm N''' removes the Nth job (start counting at 0) from the cron list. Caution! '''cron rm''' without paramater removes ALL jobs without confirmation request! === Add jobs via ecmd === '''cron add MIN HOUR DAY MONTH DAYOFWEEK ECMD''' MIN HOUR DAY MONTH and DAYOFWEEK can be -1 (as wildcard). ECMD: The ecmd command to be executed. After creating the new job it's position in the list will be displayed. === Mark job as persistent via ecmd === '''cron persistent N 1''' macht den Nten Job persistent '''cron persistent N 0''' löscht das persistent flag '''cron persistent N''' zeigt den aktuellen Status an === Write persistent jobs to VFS/EEPROM via ecmd === '''cron save''' alle als persistent markierten Jobs werden im VFS/EEPROM abgespeichert. === Mark job for UTC time via ecmd === '''cron utc N 1''' setzt den Nten Job auf UTC '''cron utc N 0''' löscht das UTC flag '''cron utc N''' zeigt den aktuellen Status an === Mark job as anacron job via ecmd === Dieses Flag bietet eine Art anacron-Funktion. Gedacht ist dies für Jobs, die bestimmte Stati setzen. Ein Beispiel wäre die Zirkulationspumpe einer Heizung. Angenommen die Pumpe soll um 6.00 Uhr eingesaltet und um 9.00 wieder ausgeschaltet werden, könnte das natürlich auch mit normalen Jobs erledigt werden. Sollte der Controller allerdings um 7.00 neu booten (z.B. wg. Stromausfall) bliebe Pumpe bis zum nächsten Tag 6.00 ausgeschaltet. Ähnliches gilt für grössere Zeitsprünge durch NTP-Updates. Um das Problem zu lösen, werden alle anacron-Jobs nachgezogen, die innerhalb des übersprungenen Zeitraums (also vom 1.1.1970 bis zur aktuellen Zeit im Falle das Boots) hätten ausgeführt werden müssen, wobei jeder Job nur einmal ausgeführt wird und auch in der korrekten Reihenfolge (jüngstes Ausführungsdatum zählt). Damit die Schleife zum Ermitteln der Jobs nicht unnötig lange dauert, ist der Startzeitpunkt in der Vergangenheit auf <Aktuelle Zeit> - CRON_ANACRON_MAXAGE Sekunden beschränkt. Voreingestellt ist hier ein Tag (86400 Sekunden). '''cron anacron N 1''' markiere den Nten Job als anacron Job '''cron anacron N 0''' löscht das UTC flag '''cron anacron N''' zeigt den aktuellen Status an === Define cronjob in source code: callback function === Wer scharf hinsieht, erkennt, dass diese Funktionalität auch durch den statischen Cron Daemon abgedeckt wird. Der statische Dienst verbraucht dabei sogar weniger Ressourcen. Aber, hier die Vorteile des dynamischen Dienstes: * Du musst keinen Quelltext in ein fremdes Modul einfügen (Übersichtlichkeit der cron_static.c nimmt mit jedem weiterem Modul ab) * Du kannst zur Laufzeit den cronjob auch wieder entfernen. * Du kannst Extradaten an die Callback Funktion übergeben Die Funktion, welche der Daemon aufrufen soll, muss folgende Signatur haben '''void func(char* data)''' und sollte ''nicht'' in der cron/cron.c Datei definiert werden, sondern in dem jeweiligen Modul, welche die Cron Funktionalität nutzen will. # Binde in dein Modul die Datei 'cron/cron.h' ein. # Nutze die Callback Variante des Cron-Einfügen Befehls '''cron_jobinsert_callback''' in der Initalisierungsfunktion deines Moduls um beim Start von ethersex cronjobs hinzuzufügen. # Die Funktionsparameter haben die folgende Semantik: * Minute, -1 für ignorieren, -2 für jede 2te Minute etc * Stunde, -1 für ignorieren, -2 für jede 2te Stunde etc * Tag, -1 für ignorieren, -2 für jeden 2te Tag etc * Monat, -1 für ignorieren, -2 für jeden 2te Monat etc * Wochentag, 1 für Sonntag, 2 für Montag, 4 für Dienstag, 8 für Mittwoch, 16 für Donnerstag, 32 für Freitag, 64 für Samstag oder eine Addition daraus * Wiederholen, INFINIT_RUNNING für endlos, 1=einmal etc * Position des Crons in der Cronliste (CRON_APPEND, wenn angehängt werden soll) * Callback Funktion * Größe von Extradaten * Extradaten Beispiel aus der Test Einträge Datei: void test(void* data) { /* tu was */ } // in init cron_jobinsert_callback(-1, -2, -1, -1, -1, INFINIT_RUNNING, CRON_APPEND, test, 0, NULL); Extradaten sind eine ziemlich coole Sache. Stella PWM zum Beispiel speichert darin Lichtkanal und Zielwert. Beim Aktivieren des Cronjobs wird der Zeiger auf diese Extradaten dann an die Callback Funktion mit übergeben und diese stehen direkt zur Verfügung. Bitte beachte hierbei aber, dass der Pointer auf die Extradaten durch einen Malloc Aufruf gewonnen werden muss, sprich die Speicherstelle für die Extradaten müssen vorher auf dem Heap allokiert werden. (Beispiel: '''char* extra = malloc(2);''' für 2 Bytes auf dem Heap) Du musst und solltest dich nicht um die Freigabe des allokierten Speichers kümmern. Dies erledigt der Cron daemon bereits. === Define cronjob in source code: ecmd command === Der statische cron daemon bot die Möglichkeit eine Funktion zu gegebenem Zeitpunkt aufzurufen. Wenn du jedoch den dynamischen Dienst nutzt, kannst du auch ecmd Befehle zeitabhängig aufrufen lassen (z.B. Pins setzen, Stella PWM kontrollieren, ethersex reseten etc). Die Funktion die du in dein Modul hierfür einbauen musst, lautet folgendermaßen: cron_jobinsert_ecmd(-1, -2, -1, -1, 127, INFINIT_RUNNING, CRON_APPEND, "ECMD"); 1314d7bcef7db61a223b7f43a3e64404635d17e4 453 452 2012-04-06T12:09:39Z Sittner 461 /* Mark job as persistent via ecmd */ wikitext text/x-wiki {{i18n|Cron}} {{Module |NAME=Cron daemon |MENUCONFIG={{Applications}}->Cron daemon |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]], [[Clock]] |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/services/cron https://github.com/ethersex/ethersex/tree/master/services/cron] }} Cron daemon manage cron jobs. This rules define repeated or unique events that call certain commands. Cron jobs are implemented in two flavors: a static list that is defined at compile time and not changeable at runtime, and a dynamic approach, which loads the joblist to the RAM at statup. Jobs can be added and removed at runtime. == Preconditions == Both approaches have in common that you need to define a function that is called from the con daemon at a appropriate time. The function signature, however, varies dependend on the choosen implementation. == Menuconfig == The module needs the current time to function properly. So you have to select at least one time source. To enable crontabs in ethersex select │ │ Load a Default Configuration ---> │ │ ... │ │ Applications ---> │ │ ... │ │ [*] Cron daemon ---> │ │ [ ] Cron daemon (static jobs) == Static Cron Daemon == The function to be called from the daemon has to have the signature '''void func(void)''' and has to be defined in cron_static/cron_static.c. Furthermore you have to insert a rule of the type ''cron_static_event_t'' to the structure array ''events''. The meaning of the values are minute, hour, day, month, days of week, callback function and a flag if UTC or local time is used (in that order). A value of -1 is a wildcard. The entries are checked every minute, so an entry with all wildcards will be executed every minute. Values less than -1 mean "every x-th minute/hour/etc.". So in case of -4 in the minute field the job will be executed every 4th minute. == Dynamic Cron Daemon == === View jobs via ecmd === Simply execute the ecmd command '''cron list''' i.e. in your browser. All jobs will be displayed, two lines for each job. The first line contains the job attributes (position, repeats, ecmd/callback job, use UTC, etc.), the second line shows the timing data (MIN HOUR DAY MONTH DAYOFWEEK) and the ecmd command/address of the callback function to be executed. === Remove jobs via ecmd === '''cron rm N''' removes the Nth job (start counting at 0) from the cron list. Caution! '''cron rm''' without paramater removes ALL jobs without confirmation request! === Add jobs via ecmd === '''cron add MIN HOUR DAY MONTH DAYOFWEEK ECMD''' MIN HOUR DAY MONTH and DAYOFWEEK can be -1 (as wildcard). ECMD: The ecmd command to be executed. After creating the new job it's position in the list will be displayed. === Mark job as persistent via ecmd === '''cron persistent N 1''' mark job N as persistent '''cron persistent N 0''' remove persistent flag '''cron persistent N''' show current state === Write persistent jobs to VFS/EEPROM via ecmd === '''cron save''' alle als persistent markierten Jobs werden im VFS/EEPROM abgespeichert. === Mark job for UTC time via ecmd === '''cron utc N 1''' setzt den Nten Job auf UTC '''cron utc N 0''' löscht das UTC flag '''cron utc N''' zeigt den aktuellen Status an === Mark job as anacron job via ecmd === Dieses Flag bietet eine Art anacron-Funktion. Gedacht ist dies für Jobs, die bestimmte Stati setzen. Ein Beispiel wäre die Zirkulationspumpe einer Heizung. Angenommen die Pumpe soll um 6.00 Uhr eingesaltet und um 9.00 wieder ausgeschaltet werden, könnte das natürlich auch mit normalen Jobs erledigt werden. Sollte der Controller allerdings um 7.00 neu booten (z.B. wg. Stromausfall) bliebe Pumpe bis zum nächsten Tag 6.00 ausgeschaltet. Ähnliches gilt für grössere Zeitsprünge durch NTP-Updates. Um das Problem zu lösen, werden alle anacron-Jobs nachgezogen, die innerhalb des übersprungenen Zeitraums (also vom 1.1.1970 bis zur aktuellen Zeit im Falle das Boots) hätten ausgeführt werden müssen, wobei jeder Job nur einmal ausgeführt wird und auch in der korrekten Reihenfolge (jüngstes Ausführungsdatum zählt). Damit die Schleife zum Ermitteln der Jobs nicht unnötig lange dauert, ist der Startzeitpunkt in der Vergangenheit auf <Aktuelle Zeit> - CRON_ANACRON_MAXAGE Sekunden beschränkt. Voreingestellt ist hier ein Tag (86400 Sekunden). '''cron anacron N 1''' markiere den Nten Job als anacron Job '''cron anacron N 0''' löscht das UTC flag '''cron anacron N''' zeigt den aktuellen Status an === Define cronjob in source code: callback function === Wer scharf hinsieht, erkennt, dass diese Funktionalität auch durch den statischen Cron Daemon abgedeckt wird. Der statische Dienst verbraucht dabei sogar weniger Ressourcen. Aber, hier die Vorteile des dynamischen Dienstes: * Du musst keinen Quelltext in ein fremdes Modul einfügen (Übersichtlichkeit der cron_static.c nimmt mit jedem weiterem Modul ab) * Du kannst zur Laufzeit den cronjob auch wieder entfernen. * Du kannst Extradaten an die Callback Funktion übergeben Die Funktion, welche der Daemon aufrufen soll, muss folgende Signatur haben '''void func(char* data)''' und sollte ''nicht'' in der cron/cron.c Datei definiert werden, sondern in dem jeweiligen Modul, welche die Cron Funktionalität nutzen will. # Binde in dein Modul die Datei 'cron/cron.h' ein. # Nutze die Callback Variante des Cron-Einfügen Befehls '''cron_jobinsert_callback''' in der Initalisierungsfunktion deines Moduls um beim Start von ethersex cronjobs hinzuzufügen. # Die Funktionsparameter haben die folgende Semantik: * Minute, -1 für ignorieren, -2 für jede 2te Minute etc * Stunde, -1 für ignorieren, -2 für jede 2te Stunde etc * Tag, -1 für ignorieren, -2 für jeden 2te Tag etc * Monat, -1 für ignorieren, -2 für jeden 2te Monat etc * Wochentag, 1 für Sonntag, 2 für Montag, 4 für Dienstag, 8 für Mittwoch, 16 für Donnerstag, 32 für Freitag, 64 für Samstag oder eine Addition daraus * Wiederholen, INFINIT_RUNNING für endlos, 1=einmal etc * Position des Crons in der Cronliste (CRON_APPEND, wenn angehängt werden soll) * Callback Funktion * Größe von Extradaten * Extradaten Beispiel aus der Test Einträge Datei: void test(void* data) { /* tu was */ } // in init cron_jobinsert_callback(-1, -2, -1, -1, -1, INFINIT_RUNNING, CRON_APPEND, test, 0, NULL); Extradaten sind eine ziemlich coole Sache. Stella PWM zum Beispiel speichert darin Lichtkanal und Zielwert. Beim Aktivieren des Cronjobs wird der Zeiger auf diese Extradaten dann an die Callback Funktion mit übergeben und diese stehen direkt zur Verfügung. Bitte beachte hierbei aber, dass der Pointer auf die Extradaten durch einen Malloc Aufruf gewonnen werden muss, sprich die Speicherstelle für die Extradaten müssen vorher auf dem Heap allokiert werden. (Beispiel: '''char* extra = malloc(2);''' für 2 Bytes auf dem Heap) Du musst und solltest dich nicht um die Freigabe des allokierten Speichers kümmern. Dies erledigt der Cron daemon bereits. === Define cronjob in source code: ecmd command === Der statische cron daemon bot die Möglichkeit eine Funktion zu gegebenem Zeitpunkt aufzurufen. Wenn du jedoch den dynamischen Dienst nutzt, kannst du auch ecmd Befehle zeitabhängig aufrufen lassen (z.B. Pins setzen, Stella PWM kontrollieren, ethersex reseten etc). Die Funktion die du in dein Modul hierfür einbauen musst, lautet folgendermaßen: cron_jobinsert_ecmd(-1, -2, -1, -1, 127, INFINIT_RUNNING, CRON_APPEND, "ECMD"); 607c538d1c26498213e29f8b218c2dec9b806552 454 453 2012-04-06T12:11:53Z Sittner 461 wikitext text/x-wiki {{i18n|Cron}} {{Module |NAME=Cron daemon |MENUCONFIG={{Applications}}->Cron daemon |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]], [[Clock]] |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/services/cron https://github.com/ethersex/ethersex/tree/master/services/cron] }} Cron daemon manage cron jobs. This rules define repeated or unique events that call certain commands. Cron jobs are implemented in two flavors: a static list that is defined at compile time and not changeable at runtime, and a dynamic approach, which loads the joblist to the RAM at statup. Jobs can be added and removed at runtime. == Preconditions == Both approaches have in common that you need to define a function that is called from the con daemon at a appropriate time. The function signature, however, varies dependend on the choosen implementation. == Menuconfig == The module needs the current time to function properly. So you have to select at least one time source. To enable crontabs in ethersex select │ │ Load a Default Configuration ---> │ │ ... │ │ Applications ---> │ │ ... │ │ [*] Cron daemon ---> │ │ [ ] Cron daemon (static jobs) == Static Cron Daemon == The function to be called from the daemon has to have the signature '''void func(void)''' and has to be defined in cron_static/cron_static.c. Furthermore you have to insert a rule of the type ''cron_static_event_t'' to the structure array ''events''. The meaning of the values are minute, hour, day, month, days of week, callback function and a flag if UTC or local time is used (in that order). A value of -1 is a wildcard. The entries are checked every minute, so an entry with all wildcards will be executed every minute. Values less than -1 mean "every x-th minute/hour/etc.". So in case of -4 in the minute field the job will be executed every 4th minute. == Dynamic Cron Daemon == === View jobs via ecmd === Simply execute the ecmd command '''cron list''' i.e. in your browser. All jobs will be displayed, two lines for each job. The first line contains the job attributes (position, repeats, ecmd/callback job, use UTC, etc.), the second line shows the timing data (MIN HOUR DAY MONTH DAYOFWEEK) and the ecmd command/address of the callback function to be executed. === Remove jobs via ecmd === '''cron rm N''' removes the Nth job (start counting at 0) from the cron list. Caution! '''cron rm''' without paramater removes ALL jobs without confirmation request! === Add jobs via ecmd === '''cron add MIN HOUR DAY MONTH DAYOFWEEK ECMD''' MIN HOUR DAY MONTH and DAYOFWEEK can be -1 (as wildcard). ECMD: The ecmd command to be executed. After creating the new job it's position in the list will be displayed. === Mark job as persistent via ecmd === '''cron persistent N 1''' mark job N as persistent '''cron persistent N 0''' remove persistent flag '''cron persistent N''' show current state === Write persistent jobs to VFS/EEPROM via ecmd === '''cron save''' alle als persistent markierten Jobs werden im VFS/EEPROM abgespeichert. === Mark job for UTC time via ecmd === '''cron utc N 1''' mark job N for UTC time '''cron utc N 0''' remove UTC flag '''cron utc N''' show current state === Mark job as anacron job via ecmd === Dieses Flag bietet eine Art anacron-Funktion. Gedacht ist dies für Jobs, die bestimmte Stati setzen. Ein Beispiel wäre die Zirkulationspumpe einer Heizung. Angenommen die Pumpe soll um 6.00 Uhr eingesaltet und um 9.00 wieder ausgeschaltet werden, könnte das natürlich auch mit normalen Jobs erledigt werden. Sollte der Controller allerdings um 7.00 neu booten (z.B. wg. Stromausfall) bliebe Pumpe bis zum nächsten Tag 6.00 ausgeschaltet. Ähnliches gilt für grössere Zeitsprünge durch NTP-Updates. Um das Problem zu lösen, werden alle anacron-Jobs nachgezogen, die innerhalb des übersprungenen Zeitraums (also vom 1.1.1970 bis zur aktuellen Zeit im Falle das Boots) hätten ausgeführt werden müssen, wobei jeder Job nur einmal ausgeführt wird und auch in der korrekten Reihenfolge (jüngstes Ausführungsdatum zählt). Damit die Schleife zum Ermitteln der Jobs nicht unnötig lange dauert, ist der Startzeitpunkt in der Vergangenheit auf <Aktuelle Zeit> - CRON_ANACRON_MAXAGE Sekunden beschränkt. Voreingestellt ist hier ein Tag (86400 Sekunden). '''cron anacron N 1''' mark job N as anacron job '''cron anacron N 0''' remove anacron flag '''cron anacron N''' show current state === Define cronjob in source code: callback function === Wer scharf hinsieht, erkennt, dass diese Funktionalität auch durch den statischen Cron Daemon abgedeckt wird. Der statische Dienst verbraucht dabei sogar weniger Ressourcen. Aber, hier die Vorteile des dynamischen Dienstes: * Du musst keinen Quelltext in ein fremdes Modul einfügen (Übersichtlichkeit der cron_static.c nimmt mit jedem weiterem Modul ab) * Du kannst zur Laufzeit den cronjob auch wieder entfernen. * Du kannst Extradaten an die Callback Funktion übergeben Die Funktion, welche der Daemon aufrufen soll, muss folgende Signatur haben '''void func(char* data)''' und sollte ''nicht'' in der cron/cron.c Datei definiert werden, sondern in dem jeweiligen Modul, welche die Cron Funktionalität nutzen will. # Binde in dein Modul die Datei 'cron/cron.h' ein. # Nutze die Callback Variante des Cron-Einfügen Befehls '''cron_jobinsert_callback''' in der Initalisierungsfunktion deines Moduls um beim Start von ethersex cronjobs hinzuzufügen. # Die Funktionsparameter haben die folgende Semantik: * Minute, -1 für ignorieren, -2 für jede 2te Minute etc * Stunde, -1 für ignorieren, -2 für jede 2te Stunde etc * Tag, -1 für ignorieren, -2 für jeden 2te Tag etc * Monat, -1 für ignorieren, -2 für jeden 2te Monat etc * Wochentag, 1 für Sonntag, 2 für Montag, 4 für Dienstag, 8 für Mittwoch, 16 für Donnerstag, 32 für Freitag, 64 für Samstag oder eine Addition daraus * Wiederholen, INFINIT_RUNNING für endlos, 1=einmal etc * Position des Crons in der Cronliste (CRON_APPEND, wenn angehängt werden soll) * Callback Funktion * Größe von Extradaten * Extradaten Beispiel aus der Test Einträge Datei: void test(void* data) { /* tu was */ } // in init cron_jobinsert_callback(-1, -2, -1, -1, -1, INFINIT_RUNNING, CRON_APPEND, test, 0, NULL); Extradaten sind eine ziemlich coole Sache. Stella PWM zum Beispiel speichert darin Lichtkanal und Zielwert. Beim Aktivieren des Cronjobs wird der Zeiger auf diese Extradaten dann an die Callback Funktion mit übergeben und diese stehen direkt zur Verfügung. Bitte beachte hierbei aber, dass der Pointer auf die Extradaten durch einen Malloc Aufruf gewonnen werden muss, sprich die Speicherstelle für die Extradaten müssen vorher auf dem Heap allokiert werden. (Beispiel: '''char* extra = malloc(2);''' für 2 Bytes auf dem Heap) Du musst und solltest dich nicht um die Freigabe des allokierten Speichers kümmern. Dies erledigt der Cron daemon bereits. === Define cronjob in source code: ecmd command === Der statische cron daemon bot die Möglichkeit eine Funktion zu gegebenem Zeitpunkt aufzurufen. Wenn du jedoch den dynamischen Dienst nutzt, kannst du auch ecmd Befehle zeitabhängig aufrufen lassen (z.B. Pins setzen, Stella PWM kontrollieren, ethersex reseten etc). Die Funktion die du in dein Modul hierfür einbauen musst, lautet folgendermaßen: cron_jobinsert_ecmd(-1, -2, -1, -1, 127, INFINIT_RUNNING, CRON_APPEND, "ECMD"); 43053baf4343979899f1f97b5db96faa590eef1d 456 454 2012-04-06T12:16:15Z Sittner 461 /* Write persistent jobs to VFS/EEPROM via ecmd */ wikitext text/x-wiki {{i18n|Cron}} {{Module |NAME=Cron daemon |MENUCONFIG={{Applications}}->Cron daemon |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]], [[Clock]] |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/services/cron https://github.com/ethersex/ethersex/tree/master/services/cron] }} Cron daemon manage cron jobs. This rules define repeated or unique events that call certain commands. Cron jobs are implemented in two flavors: a static list that is defined at compile time and not changeable at runtime, and a dynamic approach, which loads the joblist to the RAM at statup. Jobs can be added and removed at runtime. == Preconditions == Both approaches have in common that you need to define a function that is called from the con daemon at a appropriate time. The function signature, however, varies dependend on the choosen implementation. == Menuconfig == The module needs the current time to function properly. So you have to select at least one time source. To enable crontabs in ethersex select │ │ Load a Default Configuration ---> │ │ ... │ │ Applications ---> │ │ ... │ │ [*] Cron daemon ---> │ │ [ ] Cron daemon (static jobs) == Static Cron Daemon == The function to be called from the daemon has to have the signature '''void func(void)''' and has to be defined in cron_static/cron_static.c. Furthermore you have to insert a rule of the type ''cron_static_event_t'' to the structure array ''events''. The meaning of the values are minute, hour, day, month, days of week, callback function and a flag if UTC or local time is used (in that order). A value of -1 is a wildcard. The entries are checked every minute, so an entry with all wildcards will be executed every minute. Values less than -1 mean "every x-th minute/hour/etc.". So in case of -4 in the minute field the job will be executed every 4th minute. == Dynamic Cron Daemon == === View jobs via ecmd === Simply execute the ecmd command '''cron list''' i.e. in your browser. All jobs will be displayed, two lines for each job. The first line contains the job attributes (position, repeats, ecmd/callback job, use UTC, etc.), the second line shows the timing data (MIN HOUR DAY MONTH DAYOFWEEK) and the ecmd command/address of the callback function to be executed. === Remove jobs via ecmd === '''cron rm N''' removes the Nth job (start counting at 0) from the cron list. Caution! '''cron rm''' without paramater removes ALL jobs without confirmation request! === Add jobs via ecmd === '''cron add MIN HOUR DAY MONTH DAYOFWEEK ECMD''' MIN HOUR DAY MONTH and DAYOFWEEK can be -1 (as wildcard). ECMD: The ecmd command to be executed. After creating the new job it's position in the list will be displayed. === Mark job as persistent via ecmd === '''cron persistent N 1''' mark job N as persistent '''cron persistent N 0''' remove persistent flag '''cron persistent N''' show current state === Write persistent jobs to VFS/EEPROM via ecmd === '''cron save''' all persistent jobs will be stored in VFS/EEPROM. === Mark job for UTC time via ecmd === '''cron utc N 1''' mark job N for UTC time '''cron utc N 0''' remove UTC flag '''cron utc N''' show current state === Mark job as anacron job via ecmd === Dieses Flag bietet eine Art anacron-Funktion. Gedacht ist dies für Jobs, die bestimmte Stati setzen. Ein Beispiel wäre die Zirkulationspumpe einer Heizung. Angenommen die Pumpe soll um 6.00 Uhr eingesaltet und um 9.00 wieder ausgeschaltet werden, könnte das natürlich auch mit normalen Jobs erledigt werden. Sollte der Controller allerdings um 7.00 neu booten (z.B. wg. Stromausfall) bliebe Pumpe bis zum nächsten Tag 6.00 ausgeschaltet. Ähnliches gilt für grössere Zeitsprünge durch NTP-Updates. Um das Problem zu lösen, werden alle anacron-Jobs nachgezogen, die innerhalb des übersprungenen Zeitraums (also vom 1.1.1970 bis zur aktuellen Zeit im Falle das Boots) hätten ausgeführt werden müssen, wobei jeder Job nur einmal ausgeführt wird und auch in der korrekten Reihenfolge (jüngstes Ausführungsdatum zählt). Damit die Schleife zum Ermitteln der Jobs nicht unnötig lange dauert, ist der Startzeitpunkt in der Vergangenheit auf <Aktuelle Zeit> - CRON_ANACRON_MAXAGE Sekunden beschränkt. Voreingestellt ist hier ein Tag (86400 Sekunden). '''cron anacron N 1''' mark job N as anacron job '''cron anacron N 0''' remove anacron flag '''cron anacron N''' show current state === Define cronjob in source code: callback function === Wer scharf hinsieht, erkennt, dass diese Funktionalität auch durch den statischen Cron Daemon abgedeckt wird. Der statische Dienst verbraucht dabei sogar weniger Ressourcen. Aber, hier die Vorteile des dynamischen Dienstes: * Du musst keinen Quelltext in ein fremdes Modul einfügen (Übersichtlichkeit der cron_static.c nimmt mit jedem weiterem Modul ab) * Du kannst zur Laufzeit den cronjob auch wieder entfernen. * Du kannst Extradaten an die Callback Funktion übergeben Die Funktion, welche der Daemon aufrufen soll, muss folgende Signatur haben '''void func(char* data)''' und sollte ''nicht'' in der cron/cron.c Datei definiert werden, sondern in dem jeweiligen Modul, welche die Cron Funktionalität nutzen will. # Binde in dein Modul die Datei 'cron/cron.h' ein. # Nutze die Callback Variante des Cron-Einfügen Befehls '''cron_jobinsert_callback''' in der Initalisierungsfunktion deines Moduls um beim Start von ethersex cronjobs hinzuzufügen. # Die Funktionsparameter haben die folgende Semantik: * Minute, -1 für ignorieren, -2 für jede 2te Minute etc * Stunde, -1 für ignorieren, -2 für jede 2te Stunde etc * Tag, -1 für ignorieren, -2 für jeden 2te Tag etc * Monat, -1 für ignorieren, -2 für jeden 2te Monat etc * Wochentag, 1 für Sonntag, 2 für Montag, 4 für Dienstag, 8 für Mittwoch, 16 für Donnerstag, 32 für Freitag, 64 für Samstag oder eine Addition daraus * Wiederholen, INFINIT_RUNNING für endlos, 1=einmal etc * Position des Crons in der Cronliste (CRON_APPEND, wenn angehängt werden soll) * Callback Funktion * Größe von Extradaten * Extradaten Beispiel aus der Test Einträge Datei: void test(void* data) { /* tu was */ } // in init cron_jobinsert_callback(-1, -2, -1, -1, -1, INFINIT_RUNNING, CRON_APPEND, test, 0, NULL); Extradaten sind eine ziemlich coole Sache. Stella PWM zum Beispiel speichert darin Lichtkanal und Zielwert. Beim Aktivieren des Cronjobs wird der Zeiger auf diese Extradaten dann an die Callback Funktion mit übergeben und diese stehen direkt zur Verfügung. Bitte beachte hierbei aber, dass der Pointer auf die Extradaten durch einen Malloc Aufruf gewonnen werden muss, sprich die Speicherstelle für die Extradaten müssen vorher auf dem Heap allokiert werden. (Beispiel: '''char* extra = malloc(2);''' für 2 Bytes auf dem Heap) Du musst und solltest dich nicht um die Freigabe des allokierten Speichers kümmern. Dies erledigt der Cron daemon bereits. === Define cronjob in source code: ecmd command === Der statische cron daemon bot die Möglichkeit eine Funktion zu gegebenem Zeitpunkt aufzurufen. Wenn du jedoch den dynamischen Dienst nutzt, kannst du auch ecmd Befehle zeitabhängig aufrufen lassen (z.B. Pins setzen, Stella PWM kontrollieren, ethersex reseten etc). Die Funktion die du in dein Modul hierfür einbauen musst, lautet folgendermaßen: cron_jobinsert_ecmd(-1, -2, -1, -1, 127, INFINIT_RUNNING, CRON_APPEND, "ECMD"); 4cd3b4d27420af09543117d7c059e8e06074f4ae 457 456 2012-04-06T12:41:24Z Sittner 461 /* Mark job as anacron job via ecmd */ wikitext text/x-wiki {{i18n|Cron}} {{Module |NAME=Cron daemon |MENUCONFIG={{Applications}}->Cron daemon |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]], [[Clock]] |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/services/cron https://github.com/ethersex/ethersex/tree/master/services/cron] }} Cron daemon manage cron jobs. This rules define repeated or unique events that call certain commands. Cron jobs are implemented in two flavors: a static list that is defined at compile time and not changeable at runtime, and a dynamic approach, which loads the joblist to the RAM at statup. Jobs can be added and removed at runtime. == Preconditions == Both approaches have in common that you need to define a function that is called from the con daemon at a appropriate time. The function signature, however, varies dependend on the choosen implementation. == Menuconfig == The module needs the current time to function properly. So you have to select at least one time source. To enable crontabs in ethersex select │ │ Load a Default Configuration ---> │ │ ... │ │ Applications ---> │ │ ... │ │ [*] Cron daemon ---> │ │ [ ] Cron daemon (static jobs) == Static Cron Daemon == The function to be called from the daemon has to have the signature '''void func(void)''' and has to be defined in cron_static/cron_static.c. Furthermore you have to insert a rule of the type ''cron_static_event_t'' to the structure array ''events''. The meaning of the values are minute, hour, day, month, days of week, callback function and a flag if UTC or local time is used (in that order). A value of -1 is a wildcard. The entries are checked every minute, so an entry with all wildcards will be executed every minute. Values less than -1 mean "every x-th minute/hour/etc.". So in case of -4 in the minute field the job will be executed every 4th minute. == Dynamic Cron Daemon == === View jobs via ecmd === Simply execute the ecmd command '''cron list''' i.e. in your browser. All jobs will be displayed, two lines for each job. The first line contains the job attributes (position, repeats, ecmd/callback job, use UTC, etc.), the second line shows the timing data (MIN HOUR DAY MONTH DAYOFWEEK) and the ecmd command/address of the callback function to be executed. === Remove jobs via ecmd === '''cron rm N''' removes the Nth job (start counting at 0) from the cron list. Caution! '''cron rm''' without paramater removes ALL jobs without confirmation request! === Add jobs via ecmd === '''cron add MIN HOUR DAY MONTH DAYOFWEEK ECMD''' MIN HOUR DAY MONTH and DAYOFWEEK can be -1 (as wildcard). ECMD: The ecmd command to be executed. After creating the new job it's position in the list will be displayed. === Mark job as persistent via ecmd === '''cron persistent N 1''' mark job N as persistent '''cron persistent N 0''' remove persistent flag '''cron persistent N''' show current state === Write persistent jobs to VFS/EEPROM via ecmd === '''cron save''' all persistent jobs will be stored in VFS/EEPROM. === Mark job for UTC time via ecmd === '''cron utc N 1''' mark job N for UTC time '''cron utc N 0''' remove UTC flag '''cron utc N''' show current state === Mark job as anacron job via ecmd === This flag provides a kind of anacron functionality which is intended for jobs that set specific states. Take the circulation pump of a central heating as example. If the pump has to be switched on at 6.00 and switched off at 9.00 this could be realized by a simple cron job. But if the controller reboots at 7.00 (i.e. as the result of an blackout) the pump will not be switched on till 6.00 of the following day. The same counts in case of a time skip by NTP updates. To solve this problem all anacron jobs that falls in the skiped time range will be executed (in case of boot this means from 1.1.1970 till the current time), each job just one time and in correct order (latest execution time counts). To keep the runtime of the decision loop short, the starting point in the past is limited to <current time> - CRON_ANACRON_MAXAGE secs. Default is one day (86400 secs). '''cron anacron N 1''' mark job N as anacron job '''cron anacron N 0''' remove anacron flag '''cron anacron N''' show current state === Define cronjob in source code: callback function === Wer scharf hinsieht, erkennt, dass diese Funktionalität auch durch den statischen Cron Daemon abgedeckt wird. Der statische Dienst verbraucht dabei sogar weniger Ressourcen. Aber, hier die Vorteile des dynamischen Dienstes: * Du musst keinen Quelltext in ein fremdes Modul einfügen (Übersichtlichkeit der cron_static.c nimmt mit jedem weiterem Modul ab) * Du kannst zur Laufzeit den cronjob auch wieder entfernen. * Du kannst Extradaten an die Callback Funktion übergeben Die Funktion, welche der Daemon aufrufen soll, muss folgende Signatur haben '''void func(char* data)''' und sollte ''nicht'' in der cron/cron.c Datei definiert werden, sondern in dem jeweiligen Modul, welche die Cron Funktionalität nutzen will. # Binde in dein Modul die Datei 'cron/cron.h' ein. # Nutze die Callback Variante des Cron-Einfügen Befehls '''cron_jobinsert_callback''' in der Initalisierungsfunktion deines Moduls um beim Start von ethersex cronjobs hinzuzufügen. # Die Funktionsparameter haben die folgende Semantik: * Minute, -1 für ignorieren, -2 für jede 2te Minute etc * Stunde, -1 für ignorieren, -2 für jede 2te Stunde etc * Tag, -1 für ignorieren, -2 für jeden 2te Tag etc * Monat, -1 für ignorieren, -2 für jeden 2te Monat etc * Wochentag, 1 für Sonntag, 2 für Montag, 4 für Dienstag, 8 für Mittwoch, 16 für Donnerstag, 32 für Freitag, 64 für Samstag oder eine Addition daraus * Wiederholen, INFINIT_RUNNING für endlos, 1=einmal etc * Position des Crons in der Cronliste (CRON_APPEND, wenn angehängt werden soll) * Callback Funktion * Größe von Extradaten * Extradaten Beispiel aus der Test Einträge Datei: void test(void* data) { /* tu was */ } // in init cron_jobinsert_callback(-1, -2, -1, -1, -1, INFINIT_RUNNING, CRON_APPEND, test, 0, NULL); Extradaten sind eine ziemlich coole Sache. Stella PWM zum Beispiel speichert darin Lichtkanal und Zielwert. Beim Aktivieren des Cronjobs wird der Zeiger auf diese Extradaten dann an die Callback Funktion mit übergeben und diese stehen direkt zur Verfügung. Bitte beachte hierbei aber, dass der Pointer auf die Extradaten durch einen Malloc Aufruf gewonnen werden muss, sprich die Speicherstelle für die Extradaten müssen vorher auf dem Heap allokiert werden. (Beispiel: '''char* extra = malloc(2);''' für 2 Bytes auf dem Heap) Du musst und solltest dich nicht um die Freigabe des allokierten Speichers kümmern. Dies erledigt der Cron daemon bereits. === Define cronjob in source code: ecmd command === Der statische cron daemon bot die Möglichkeit eine Funktion zu gegebenem Zeitpunkt aufzurufen. Wenn du jedoch den dynamischen Dienst nutzt, kannst du auch ecmd Befehle zeitabhängig aufrufen lassen (z.B. Pins setzen, Stella PWM kontrollieren, ethersex reseten etc). Die Funktion die du in dein Modul hierfür einbauen musst, lautet folgendermaßen: cron_jobinsert_ecmd(-1, -2, -1, -1, 127, INFINIT_RUNNING, CRON_APPEND, "ECMD"); f34d6638407d0a22d66bc573d373cd7bc5ece66f 458 457 2012-04-06T15:46:22Z Sittner 461 /* Mark job as anacron job via ecmd */ wikitext text/x-wiki {{i18n|Cron}} {{Module |NAME=Cron daemon |MENUCONFIG={{Applications}}->Cron daemon |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]], [[Clock]] |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/services/cron https://github.com/ethersex/ethersex/tree/master/services/cron] }} Cron daemon manage cron jobs. This rules define repeated or unique events that call certain commands. Cron jobs are implemented in two flavors: a static list that is defined at compile time and not changeable at runtime, and a dynamic approach, which loads the joblist to the RAM at statup. Jobs can be added and removed at runtime. == Preconditions == Both approaches have in common that you need to define a function that is called from the con daemon at a appropriate time. The function signature, however, varies dependend on the choosen implementation. == Menuconfig == The module needs the current time to function properly. So you have to select at least one time source. To enable crontabs in ethersex select │ │ Load a Default Configuration ---> │ │ ... │ │ Applications ---> │ │ ... │ │ [*] Cron daemon ---> │ │ [ ] Cron daemon (static jobs) == Static Cron Daemon == The function to be called from the daemon has to have the signature '''void func(void)''' and has to be defined in cron_static/cron_static.c. Furthermore you have to insert a rule of the type ''cron_static_event_t'' to the structure array ''events''. The meaning of the values are minute, hour, day, month, days of week, callback function and a flag if UTC or local time is used (in that order). A value of -1 is a wildcard. The entries are checked every minute, so an entry with all wildcards will be executed every minute. Values less than -1 mean "every x-th minute/hour/etc.". So in case of -4 in the minute field the job will be executed every 4th minute. == Dynamic Cron Daemon == === View jobs via ecmd === Simply execute the ecmd command '''cron list''' i.e. in your browser. All jobs will be displayed, two lines for each job. The first line contains the job attributes (position, repeats, ecmd/callback job, use UTC, etc.), the second line shows the timing data (MIN HOUR DAY MONTH DAYOFWEEK) and the ecmd command/address of the callback function to be executed. === Remove jobs via ecmd === '''cron rm N''' removes the Nth job (start counting at 0) from the cron list. Caution! '''cron rm''' without paramater removes ALL jobs without confirmation request! === Add jobs via ecmd === '''cron add MIN HOUR DAY MONTH DAYOFWEEK ECMD''' MIN HOUR DAY MONTH and DAYOFWEEK can be -1 (as wildcard). ECMD: The ecmd command to be executed. After creating the new job it's position in the list will be displayed. === Mark job as persistent via ecmd === '''cron persistent N 1''' mark job N as persistent '''cron persistent N 0''' remove persistent flag '''cron persistent N''' show current state === Write persistent jobs to VFS/EEPROM via ecmd === '''cron save''' all persistent jobs will be stored in VFS/EEPROM. === Mark job for UTC time via ecmd === '''cron utc N 1''' mark job N for UTC time '''cron utc N 0''' remove UTC flag '''cron utc N''' show current state === Mark job as anacron job via ecmd === This flag provides a kind of anacron functionality which is intended for jobs that set specific states. Take the circulation pump of a central heating as example. If the pump has to be switched on at 6.00 and switched off at 9.00 this could be realized by a simple cron job. But if the controller reboots at 7.00 (i.e. as the result of a blackout) the pump will not be switched on till 6.00 of the following day. The same counts in case of a time skip by NTP updates. To solve this problem all anacron jobs that falls in the skiped time range will be executed (in case of boot this means from 1.1.1970 till the current time), each job just one time and in correct order (latest execution time counts). To keep the runtime of the decision loop short, the starting point in the past is limited to <current time> - CRON_ANACRON_MAXAGE secs. Default is one day (86400 secs). '''cron anacron N 1''' mark job N as anacron job '''cron anacron N 0''' remove anacron flag '''cron anacron N''' show current state === Define cronjob in source code: callback function === Wer scharf hinsieht, erkennt, dass diese Funktionalität auch durch den statischen Cron Daemon abgedeckt wird. Der statische Dienst verbraucht dabei sogar weniger Ressourcen. Aber, hier die Vorteile des dynamischen Dienstes: * Du musst keinen Quelltext in ein fremdes Modul einfügen (Übersichtlichkeit der cron_static.c nimmt mit jedem weiterem Modul ab) * Du kannst zur Laufzeit den cronjob auch wieder entfernen. * Du kannst Extradaten an die Callback Funktion übergeben Die Funktion, welche der Daemon aufrufen soll, muss folgende Signatur haben '''void func(char* data)''' und sollte ''nicht'' in der cron/cron.c Datei definiert werden, sondern in dem jeweiligen Modul, welche die Cron Funktionalität nutzen will. # Binde in dein Modul die Datei 'cron/cron.h' ein. # Nutze die Callback Variante des Cron-Einfügen Befehls '''cron_jobinsert_callback''' in der Initalisierungsfunktion deines Moduls um beim Start von ethersex cronjobs hinzuzufügen. # Die Funktionsparameter haben die folgende Semantik: * Minute, -1 für ignorieren, -2 für jede 2te Minute etc * Stunde, -1 für ignorieren, -2 für jede 2te Stunde etc * Tag, -1 für ignorieren, -2 für jeden 2te Tag etc * Monat, -1 für ignorieren, -2 für jeden 2te Monat etc * Wochentag, 1 für Sonntag, 2 für Montag, 4 für Dienstag, 8 für Mittwoch, 16 für Donnerstag, 32 für Freitag, 64 für Samstag oder eine Addition daraus * Wiederholen, INFINIT_RUNNING für endlos, 1=einmal etc * Position des Crons in der Cronliste (CRON_APPEND, wenn angehängt werden soll) * Callback Funktion * Größe von Extradaten * Extradaten Beispiel aus der Test Einträge Datei: void test(void* data) { /* tu was */ } // in init cron_jobinsert_callback(-1, -2, -1, -1, -1, INFINIT_RUNNING, CRON_APPEND, test, 0, NULL); Extradaten sind eine ziemlich coole Sache. Stella PWM zum Beispiel speichert darin Lichtkanal und Zielwert. Beim Aktivieren des Cronjobs wird der Zeiger auf diese Extradaten dann an die Callback Funktion mit übergeben und diese stehen direkt zur Verfügung. Bitte beachte hierbei aber, dass der Pointer auf die Extradaten durch einen Malloc Aufruf gewonnen werden muss, sprich die Speicherstelle für die Extradaten müssen vorher auf dem Heap allokiert werden. (Beispiel: '''char* extra = malloc(2);''' für 2 Bytes auf dem Heap) Du musst und solltest dich nicht um die Freigabe des allokierten Speichers kümmern. Dies erledigt der Cron daemon bereits. === Define cronjob in source code: ecmd command === Der statische cron daemon bot die Möglichkeit eine Funktion zu gegebenem Zeitpunkt aufzurufen. Wenn du jedoch den dynamischen Dienst nutzt, kannst du auch ecmd Befehle zeitabhängig aufrufen lassen (z.B. Pins setzen, Stella PWM kontrollieren, ethersex reseten etc). Die Funktion die du in dein Modul hierfür einbauen musst, lautet folgendermaßen: cron_jobinsert_ecmd(-1, -2, -1, -1, 127, INFINIT_RUNNING, CRON_APPEND, "ECMD"); c0bb44afef69b758c4f0508fe7842dbaced3c21b 481 458 2012-04-08T07:54:55Z Sittner 461 /* View jobs via ecmd */ wikitext text/x-wiki {{i18n|Cron}} {{Module |NAME=Cron daemon |MENUCONFIG={{Applications}}->Cron daemon |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]], [[Clock]] |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/services/cron https://github.com/ethersex/ethersex/tree/master/services/cron] }} Cron daemon manage cron jobs. This rules define repeated or unique events that call certain commands. Cron jobs are implemented in two flavors: a static list that is defined at compile time and not changeable at runtime, and a dynamic approach, which loads the joblist to the RAM at statup. Jobs can be added and removed at runtime. == Preconditions == Both approaches have in common that you need to define a function that is called from the con daemon at a appropriate time. The function signature, however, varies dependend on the choosen implementation. == Menuconfig == The module needs the current time to function properly. So you have to select at least one time source. To enable crontabs in ethersex select │ │ Load a Default Configuration ---> │ │ ... │ │ Applications ---> │ │ ... │ │ [*] Cron daemon ---> │ │ [ ] Cron daemon (static jobs) == Static Cron Daemon == The function to be called from the daemon has to have the signature '''void func(void)''' and has to be defined in cron_static/cron_static.c. Furthermore you have to insert a rule of the type ''cron_static_event_t'' to the structure array ''events''. The meaning of the values are minute, hour, day, month, days of week, callback function and a flag if UTC or local time is used (in that order). A value of -1 is a wildcard. The entries are checked every minute, so an entry with all wildcards will be executed every minute. Values less than -1 mean "every x-th minute/hour/etc.". So in case of -4 in the minute field the job will be executed every 4th minute. == Dynamic Cron Daemon == === View jobs via ecmd === Simply execute the ecmd command '''cron list''' in your browser for instance. All jobs will be displayed, two lines for each job. The first line contains the job attributes (position, repeats, ecmd/callback job, use UTC, etc.), the second line shows the timing data (MIN HOUR DAY MONTH DAYOFWEEK) and the ecmd command/address of the callback function to be executed. === Remove jobs via ecmd === '''cron rm N''' removes the Nth job (start counting at 0) from the cron list. Caution! '''cron rm''' without paramater removes ALL jobs without confirmation request! === Add jobs via ecmd === '''cron add MIN HOUR DAY MONTH DAYOFWEEK ECMD''' MIN HOUR DAY MONTH and DAYOFWEEK can be -1 (as wildcard). ECMD: The ecmd command to be executed. After creating the new job it's position in the list will be displayed. === Mark job as persistent via ecmd === '''cron persistent N 1''' mark job N as persistent '''cron persistent N 0''' remove persistent flag '''cron persistent N''' show current state === Write persistent jobs to VFS/EEPROM via ecmd === '''cron save''' all persistent jobs will be stored in VFS/EEPROM. === Mark job for UTC time via ecmd === '''cron utc N 1''' mark job N for UTC time '''cron utc N 0''' remove UTC flag '''cron utc N''' show current state === Mark job as anacron job via ecmd === This flag provides a kind of anacron functionality which is intended for jobs that set specific states. Take the circulation pump of a central heating as example. If the pump has to be switched on at 6.00 and switched off at 9.00 this could be realized by a simple cron job. But if the controller reboots at 7.00 (i.e. as the result of a blackout) the pump will not be switched on till 6.00 of the following day. The same counts in case of a time skip by NTP updates. To solve this problem all anacron jobs that falls in the skiped time range will be executed (in case of boot this means from 1.1.1970 till the current time), each job just one time and in correct order (latest execution time counts). To keep the runtime of the decision loop short, the starting point in the past is limited to <current time> - CRON_ANACRON_MAXAGE secs. Default is one day (86400 secs). '''cron anacron N 1''' mark job N as anacron job '''cron anacron N 0''' remove anacron flag '''cron anacron N''' show current state === Define cronjob in source code: callback function === Wer scharf hinsieht, erkennt, dass diese Funktionalität auch durch den statischen Cron Daemon abgedeckt wird. Der statische Dienst verbraucht dabei sogar weniger Ressourcen. Aber, hier die Vorteile des dynamischen Dienstes: * Du musst keinen Quelltext in ein fremdes Modul einfügen (Übersichtlichkeit der cron_static.c nimmt mit jedem weiterem Modul ab) * Du kannst zur Laufzeit den cronjob auch wieder entfernen. * Du kannst Extradaten an die Callback Funktion übergeben Die Funktion, welche der Daemon aufrufen soll, muss folgende Signatur haben '''void func(char* data)''' und sollte ''nicht'' in der cron/cron.c Datei definiert werden, sondern in dem jeweiligen Modul, welche die Cron Funktionalität nutzen will. # Binde in dein Modul die Datei 'cron/cron.h' ein. # Nutze die Callback Variante des Cron-Einfügen Befehls '''cron_jobinsert_callback''' in der Initalisierungsfunktion deines Moduls um beim Start von ethersex cronjobs hinzuzufügen. # Die Funktionsparameter haben die folgende Semantik: * Minute, -1 für ignorieren, -2 für jede 2te Minute etc * Stunde, -1 für ignorieren, -2 für jede 2te Stunde etc * Tag, -1 für ignorieren, -2 für jeden 2te Tag etc * Monat, -1 für ignorieren, -2 für jeden 2te Monat etc * Wochentag, 1 für Sonntag, 2 für Montag, 4 für Dienstag, 8 für Mittwoch, 16 für Donnerstag, 32 für Freitag, 64 für Samstag oder eine Addition daraus * Wiederholen, INFINIT_RUNNING für endlos, 1=einmal etc * Position des Crons in der Cronliste (CRON_APPEND, wenn angehängt werden soll) * Callback Funktion * Größe von Extradaten * Extradaten Beispiel aus der Test Einträge Datei: void test(void* data) { /* tu was */ } // in init cron_jobinsert_callback(-1, -2, -1, -1, -1, INFINIT_RUNNING, CRON_APPEND, test, 0, NULL); Extradaten sind eine ziemlich coole Sache. Stella PWM zum Beispiel speichert darin Lichtkanal und Zielwert. Beim Aktivieren des Cronjobs wird der Zeiger auf diese Extradaten dann an die Callback Funktion mit übergeben und diese stehen direkt zur Verfügung. Bitte beachte hierbei aber, dass der Pointer auf die Extradaten durch einen Malloc Aufruf gewonnen werden muss, sprich die Speicherstelle für die Extradaten müssen vorher auf dem Heap allokiert werden. (Beispiel: '''char* extra = malloc(2);''' für 2 Bytes auf dem Heap) Du musst und solltest dich nicht um die Freigabe des allokierten Speichers kümmern. Dies erledigt der Cron daemon bereits. === Define cronjob in source code: ecmd command === Der statische cron daemon bot die Möglichkeit eine Funktion zu gegebenem Zeitpunkt aufzurufen. Wenn du jedoch den dynamischen Dienst nutzt, kannst du auch ecmd Befehle zeitabhängig aufrufen lassen (z.B. Pins setzen, Stella PWM kontrollieren, ethersex reseten etc). Die Funktion die du in dein Modul hierfür einbauen musst, lautet folgendermaßen: cron_jobinsert_ecmd(-1, -2, -1, -1, 127, INFINIT_RUNNING, CRON_APPEND, "ECMD"); f7dbde1605fda3cd0c54de9ae460f567f2dc35ad 0 179 439 2012-04-04T17:50:55Z Sittner 461 Created page with "Der Cron daemon verwaltet so genannte cron jobs. Diese Regeln definieren bestimmte immer wiederkehrende oder einmalige Zeitpunkte zu denen dann Kommandos ausgeführt werden könn…" wikitext text/x-wiki Der Cron daemon verwaltet so genannte cron jobs. Diese Regeln definieren bestimmte immer wiederkehrende oder einmalige Zeitpunkte zu denen dann Kommandos ausgeführt werden können. Cronjobs sind auf zweifache Weise in Ethersex implementiert. Eine statische Liste, die zur Compilierzeit bestimmt werden muss und danach auch nicht mehr beeinflusst werden kann und einen dynamischen Ansatz, bei dem die Jobs beim Start von Ethersex in den Ram geladen werden. Danach können nach belieben Jobs entfernt und hinzugefügt werden. == Voraussetzungen == Beide Ansätze haben gemeinsam, dass du erst einmal eine Funktion definieren musst, welche vom Cron daemon zum bestimmten Zeitpunkt aufgerufen werden kann. Die Funktionssignatur sieht allerdings, abhängig davon welche Implementierung du wählst, leicht anders aus. == Menuconfig == Das Modul benötigt allerdings die aktuelle Zeit um richtig funktionieren zu können. Du musst daher im selben Untermenü mindestens eine Zeitquelle ebenfalls einschalten. Um Crontabs in ethersex zu aktivieren, wählt man im Menü │ │ Load a Default Configuration ---> │ │ ... │ │ Applications ---> │ │ ... │ │ [*] Cron daemon ---> │ │ [ ] Cron daemon (static jobs) == Statischer Cron Daemon == Die Funktion, welche der Daemon aufrufen soll, muss folgende Signatur haben '''void func(void)''' und muss direkt in cron_static/cron_static.c definiert werden. Es muss dann nur noch eine Regel in die Array Struktur events vom Typ ''cron_static_event_t'' eingefügt werden. Die Werte der Reihenfolge nach stehen für Minute, Stunde, Tag, Monat, Wochentag, Callback Funktion und ob UTC oder die lokale Zeitzone benutzt werden soll. Eine -1 steht für einen Platzhalter. Da die Einträge ca. jede Minute einmal geprüft werden, wird also ein Eintrag mit nur Platzhalter Werten auch ca. jede Minute ausgeführt. Werte unter -1 haben die Bedeutung von "jede x-te Minute/Stunde/etc". Also ein Wert von -4 an der Minutenstelle bedeutet, dass der Crontab jede 4te Minute ausgeführt wird. == Dynamischer Cron Daemon == === Auslesen per ecmd === Einfach den ecmd Befehl '''cron list''' zum Beispiel in deinem Browser ausführen. Es werden alle aktuellen jobs angezeigt, pro job zwei Zeilen. Die erste Zeile enthält die Attribute des Jobs (Position, Wiederholungen, ecmd/Callback-Job, UTC-Zeit, u.s.w.), in der zweiten Zeile werden die Zeitdaten (MIN HOUR DAY MONTH DAYOFWEEK) und der ecmd Befehl bzw. die Callback Addresse angezeigt. === Entfernen per ecmd === '''cron rm N''' entfernt den Nten Job (fängt bei 0 an zu zählen) aus der cron Liste. Vorsicht! '''cron rm''' ohne Parameter entfernt ALLE cron jobs, und das ohne vorher nachzufragen! === Hinzufügen per ecmd === '''cron add MIN HOUR DAY MONTH DAYOFWEEK ECMD''' MIN HOUR DAY MONTH und DAYOFWEEK können -1 (als Platzhalterfunktion) annehmen. ECMD: Der ecmd Befehl, der ausgeführt werden soll. Nach dem Anlegen wird die Position des neuen Jobs in der Liste ausgegeben. === Job als persistent markieren per ecmd === '''cron persistent N 1''' macht den Nten Job persistent '''cron persistent N 0''' löscht das persistent flag '''cron persistent N''' zeigt den aktuellen Status an === Persistente Jobs ins VFS/EEPROM schreiben per ecmd === '''cron save''' alle als persistent markierten Jobs werden im VFS/EEPROM abgespeichert. === Job für UTC-Zeit markieren === '''cron utc N 1''' setzt den Nten Job auf UTC '''cron utc N 0''' löscht das UTC flag '''cron utc N''' zeigt den aktuellen Status an === Cronjob im Quelltext definieren: Callback Funktion === Wer scharf hinsieht, erkennt, dass diese Funktionalität auch durch den statischen Cron Daemon abgedeckt wird. Der statische Dienst verbraucht dabei sogar weniger Ressourcen. Aber, hier die Vorteile des dynamischen Dienstes: * Du musst keinen Quelltext in ein fremdes Modul einfügen (Übersichtlichkeit der cron_static.c nimmt mit jedem weiterem Modul ab) * Du kannst zur Laufzeit den cronjob auch wieder entfernen. * Du kannst Extradaten an die Callback Funktion übergeben Die Funktion, welche der Daemon aufrufen soll, muss folgende Signatur haben '''void func(char* data)''' und sollte ''nicht'' in der cron/cron.c Datei definiert werden, sondern in dem jeweiligen Modul, welche die Cron Funktionalität nutzen will. # Binde in dein Modul die Datei 'cron/cron.h' ein. # Nutze die Callback Variante des Cron-Einfügen Befehls '''cron_jobinsert_callback''' in der Initalisierungsfunktion deines Moduls um beim Start von ethersex cronjobs hinzuzufügen. # Die Funktionsparameter haben die folgende Semantik: * Minute, -1 für ignorieren, -2 für jede 2te Minute etc * Stunde, -1 für ignorieren, -2 für jede 2te Stunde etc * Tag, -1 für ignorieren, -2 für jeden 2te Tag etc * Monat, -1 für ignorieren, -2 für jeden 2te Monat etc * Wochentag, 1 für Sonntag, 2 für Montag, 4 für Dienstag, 8 für Mittwoch, 16 für Donnerstag, 32 für Freitag, 64 für Samstag oder eine Addition daraus * Wiederholen, INFINIT_RUNNING für endlos, 1=einmal etc * Position des Crons in der Cronliste (CRON_APPEND, wenn angehängt werden soll) * Callback Funktion * Größe von Extradaten * Extradaten Beispiel aus der Test Einträge Datei: void test(void* data) { /* tu was */ } // in init cron_jobinsert_callback(-1, -2, -1, -1, -1, INFINIT_RUNNING, CRON_APPEND, test, 0, NULL); Extradaten sind eine ziemlich coole Sache. Stella PWM zum Beispiel speichert darin Lichtkanal und Zielwert. Beim Aktivieren des Cronjobs wird der Zeiger auf diese Extradaten dann an die Callback Funktion mit übergeben und diese stehen direkt zur Verfügung. Bitte beachte hierbei aber, dass der Pointer auf die Extradaten durch einen Malloc Aufruf gewonnen werden muss, sprich die Speicherstelle für die Extradaten müssen vorher auf dem Heap allokiert werden. (Beispiel: '''char* extra = malloc(2);''' für 2 Bytes auf dem Heap) Du musst und solltest dich nicht um die Freigabe des allokierten Speichers kümmern. Dies erledigt der Cron daemon bereits. === Cronjob im Quelltext definieren: Ecmd aufrufen === Der statische cron daemon bot die Möglichkeit eine Funktion zu gegebenem Zeitpunkt aufzurufen. Wenn du jedoch den dynamischen Dienst nutzt, kannst du auch ecmd Befehle zeitabhängig aufrufen lassen (z.B. Pins setzen, Stella PWM kontrollieren, ethersex reseten etc). Die Funktion die du in dein Modul hierfür einbauen musst, lautet folgendermaßen: cron_jobinsert_ecmd(-1, -2, -1, -1, 127, INFINIT_RUNNING, CRON_APPEND, "ECMD"); 70c7151be3648fcc74604687605965636a6f4b8b 440 439 2012-04-04T17:53:17Z Sittner 461 wikitext text/x-wiki {{i18n|Cron}} {{Module |NAME=Tank level meter |MENUCONFIG={{Applications}}->Cron daemon |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]], [[Clock]] |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/services/cron https://github.com/ethersex/ethersex/tree/master/services/cron] }} Der Cron daemon verwaltet so genannte cron jobs. Diese Regeln definieren bestimmte immer wiederkehrende oder einmalige Zeitpunkte zu denen dann Kommandos ausgeführt werden können. Cronjobs sind auf zweifache Weise in Ethersex implementiert. Eine statische Liste, die zur Compilierzeit bestimmt werden muss und danach auch nicht mehr beeinflusst werden kann und einen dynamischen Ansatz, bei dem die Jobs beim Start von Ethersex in den Ram geladen werden. Danach können nach belieben Jobs entfernt und hinzugefügt werden. == Voraussetzungen == Beide Ansätze haben gemeinsam, dass du erst einmal eine Funktion definieren musst, welche vom Cron daemon zum bestimmten Zeitpunkt aufgerufen werden kann. Die Funktionssignatur sieht allerdings, abhängig davon welche Implementierung du wählst, leicht anders aus. == Menuconfig == Das Modul benötigt allerdings die aktuelle Zeit um richtig funktionieren zu können. Du musst daher im selben Untermenü mindestens eine Zeitquelle ebenfalls einschalten. Um Crontabs in ethersex zu aktivieren, wählt man im Menü │ │ Load a Default Configuration ---> │ │ ... │ │ Applications ---> │ │ ... │ │ [*] Cron daemon ---> │ │ [ ] Cron daemon (static jobs) == Statischer Cron Daemon == Die Funktion, welche der Daemon aufrufen soll, muss folgende Signatur haben '''void func(void)''' und muss direkt in cron_static/cron_static.c definiert werden. Es muss dann nur noch eine Regel in die Array Struktur events vom Typ ''cron_static_event_t'' eingefügt werden. Die Werte der Reihenfolge nach stehen für Minute, Stunde, Tag, Monat, Wochentag, Callback Funktion und ob UTC oder die lokale Zeitzone benutzt werden soll. Eine -1 steht für einen Platzhalter. Da die Einträge ca. jede Minute einmal geprüft werden, wird also ein Eintrag mit nur Platzhalter Werten auch ca. jede Minute ausgeführt. Werte unter -1 haben die Bedeutung von "jede x-te Minute/Stunde/etc". Also ein Wert von -4 an der Minutenstelle bedeutet, dass der Crontab jede 4te Minute ausgeführt wird. == Dynamischer Cron Daemon == === Auslesen per ecmd === Einfach den ecmd Befehl '''cron list''' zum Beispiel in deinem Browser ausführen. Es werden alle aktuellen jobs angezeigt, pro job zwei Zeilen. Die erste Zeile enthält die Attribute des Jobs (Position, Wiederholungen, ecmd/Callback-Job, UTC-Zeit, u.s.w.), in der zweiten Zeile werden die Zeitdaten (MIN HOUR DAY MONTH DAYOFWEEK) und der ecmd Befehl bzw. die Callback Addresse angezeigt. === Entfernen per ecmd === '''cron rm N''' entfernt den Nten Job (fängt bei 0 an zu zählen) aus der cron Liste. Vorsicht! '''cron rm''' ohne Parameter entfernt ALLE cron jobs, und das ohne vorher nachzufragen! === Hinzufügen per ecmd === '''cron add MIN HOUR DAY MONTH DAYOFWEEK ECMD''' MIN HOUR DAY MONTH und DAYOFWEEK können -1 (als Platzhalterfunktion) annehmen. ECMD: Der ecmd Befehl, der ausgeführt werden soll. Nach dem Anlegen wird die Position des neuen Jobs in der Liste ausgegeben. === Job als persistent markieren per ecmd === '''cron persistent N 1''' macht den Nten Job persistent '''cron persistent N 0''' löscht das persistent flag '''cron persistent N''' zeigt den aktuellen Status an === Persistente Jobs ins VFS/EEPROM schreiben per ecmd === '''cron save''' alle als persistent markierten Jobs werden im VFS/EEPROM abgespeichert. === Job für UTC-Zeit markieren === '''cron utc N 1''' setzt den Nten Job auf UTC '''cron utc N 0''' löscht das UTC flag '''cron utc N''' zeigt den aktuellen Status an === Cronjob im Quelltext definieren: Callback Funktion === Wer scharf hinsieht, erkennt, dass diese Funktionalität auch durch den statischen Cron Daemon abgedeckt wird. Der statische Dienst verbraucht dabei sogar weniger Ressourcen. Aber, hier die Vorteile des dynamischen Dienstes: * Du musst keinen Quelltext in ein fremdes Modul einfügen (Übersichtlichkeit der cron_static.c nimmt mit jedem weiterem Modul ab) * Du kannst zur Laufzeit den cronjob auch wieder entfernen. * Du kannst Extradaten an die Callback Funktion übergeben Die Funktion, welche der Daemon aufrufen soll, muss folgende Signatur haben '''void func(char* data)''' und sollte ''nicht'' in der cron/cron.c Datei definiert werden, sondern in dem jeweiligen Modul, welche die Cron Funktionalität nutzen will. # Binde in dein Modul die Datei 'cron/cron.h' ein. # Nutze die Callback Variante des Cron-Einfügen Befehls '''cron_jobinsert_callback''' in der Initalisierungsfunktion deines Moduls um beim Start von ethersex cronjobs hinzuzufügen. # Die Funktionsparameter haben die folgende Semantik: * Minute, -1 für ignorieren, -2 für jede 2te Minute etc * Stunde, -1 für ignorieren, -2 für jede 2te Stunde etc * Tag, -1 für ignorieren, -2 für jeden 2te Tag etc * Monat, -1 für ignorieren, -2 für jeden 2te Monat etc * Wochentag, 1 für Sonntag, 2 für Montag, 4 für Dienstag, 8 für Mittwoch, 16 für Donnerstag, 32 für Freitag, 64 für Samstag oder eine Addition daraus * Wiederholen, INFINIT_RUNNING für endlos, 1=einmal etc * Position des Crons in der Cronliste (CRON_APPEND, wenn angehängt werden soll) * Callback Funktion * Größe von Extradaten * Extradaten Beispiel aus der Test Einträge Datei: void test(void* data) { /* tu was */ } // in init cron_jobinsert_callback(-1, -2, -1, -1, -1, INFINIT_RUNNING, CRON_APPEND, test, 0, NULL); Extradaten sind eine ziemlich coole Sache. Stella PWM zum Beispiel speichert darin Lichtkanal und Zielwert. Beim Aktivieren des Cronjobs wird der Zeiger auf diese Extradaten dann an die Callback Funktion mit übergeben und diese stehen direkt zur Verfügung. Bitte beachte hierbei aber, dass der Pointer auf die Extradaten durch einen Malloc Aufruf gewonnen werden muss, sprich die Speicherstelle für die Extradaten müssen vorher auf dem Heap allokiert werden. (Beispiel: '''char* extra = malloc(2);''' für 2 Bytes auf dem Heap) Du musst und solltest dich nicht um die Freigabe des allokierten Speichers kümmern. Dies erledigt der Cron daemon bereits. === Cronjob im Quelltext definieren: Ecmd aufrufen === Der statische cron daemon bot die Möglichkeit eine Funktion zu gegebenem Zeitpunkt aufzurufen. Wenn du jedoch den dynamischen Dienst nutzt, kannst du auch ecmd Befehle zeitabhängig aufrufen lassen (z.B. Pins setzen, Stella PWM kontrollieren, ethersex reseten etc). Die Funktion die du in dein Modul hierfür einbauen musst, lautet folgendermaßen: cron_jobinsert_ecmd(-1, -2, -1, -1, 127, INFINIT_RUNNING, CRON_APPEND, "ECMD"); 940c8a8d6e421b9ceee32e87adb3dbd6db9695d8 441 440 2012-04-04T17:56:08Z Sittner 461 wikitext text/x-wiki {{i18n|Cron}} {{Module |NAME=Tank level meter |MENUCONFIG={{Applications}}->Cron daemon |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]], [[Clock]] |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/services/cron https://github.com/ethersex/ethersex/tree/master/services/cron] }} Der Cron daemon verwaltet so genannte cron jobs. Diese Regeln definieren bestimmte immer wiederkehrende oder einmalige Zeitpunkte zu denen dann Kommandos ausgeführt werden können. Cronjobs sind auf zweifache Weise in Ethersex implementiert. Eine statische Liste, die zur Compilierzeit bestimmt werden muss und danach auch nicht mehr beeinflusst werden kann und einen dynamischen Ansatz, bei dem die Jobs beim Start von Ethersex in den Ram geladen werden. Danach können nach belieben Jobs entfernt und hinzugefügt werden. == Voraussetzungen == Beide Ansätze haben gemeinsam, dass du erst einmal eine Funktion definieren musst, welche vom Cron daemon zum bestimmten Zeitpunkt aufgerufen werden kann. Die Funktionssignatur sieht allerdings, abhängig davon welche Implementierung du wählst, leicht anders aus. == Menuconfig == Das Modul benötigt allerdings die aktuelle Zeit um richtig funktionieren zu können. Du musst daher im selben Untermenü mindestens eine Zeitquelle ebenfalls einschalten. Um Crontabs in ethersex zu aktivieren, wählt man im Menü │ │ Load a Default Configuration ---> │ │ ... │ │ Applications ---> │ │ ... │ │ [*] Cron daemon ---> │ │ [ ] Cron daemon (static jobs) == Statischer Cron Daemon == Die Funktion, welche der Daemon aufrufen soll, muss folgende Signatur haben '''void func(void)''' und muss direkt in cron_static/cron_static.c definiert werden. Es muss dann nur noch eine Regel in die Array Struktur events vom Typ ''cron_static_event_t'' eingefügt werden. Die Werte der Reihenfolge nach stehen für Minute, Stunde, Tag, Monat, Wochentag, Callback Funktion und ob UTC oder die lokale Zeitzone benutzt werden soll. Eine -1 steht für einen Platzhalter. Da die Einträge ca. jede Minute einmal geprüft werden, wird also ein Eintrag mit nur Platzhalter Werten auch ca. jede Minute ausgeführt. Werte unter -1 haben die Bedeutung von "jede x-te Minute/Stunde/etc". Also ein Wert von -4 an der Minutenstelle bedeutet, dass der Crontab jede 4te Minute ausgeführt wird. == Dynamischer Cron Daemon == === Auslesen per ecmd === Einfach den ecmd Befehl '''cron list''' zum Beispiel in deinem Browser ausführen. Es werden alle aktuellen jobs angezeigt, pro job zwei Zeilen. Die erste Zeile enthält die Attribute des Jobs (Position, Wiederholungen, ecmd/Callback-Job, UTC-Zeit, u.s.w.), in der zweiten Zeile werden die Zeitdaten (MIN HOUR DAY MONTH DAYOFWEEK) und der ecmd Befehl bzw. die Callback Addresse angezeigt. === Entfernen per ecmd === '''cron rm N''' entfernt den Nten Job (fängt bei 0 an zu zählen) aus der cron Liste. Vorsicht! '''cron rm''' ohne Parameter entfernt ALLE cron jobs, und das ohne vorher nachzufragen! === Hinzufügen per ecmd === '''cron add MIN HOUR DAY MONTH DAYOFWEEK ECMD''' MIN HOUR DAY MONTH und DAYOFWEEK können -1 (als Platzhalterfunktion) annehmen. ECMD: Der ecmd Befehl, der ausgeführt werden soll. Nach dem Anlegen wird die Position des neuen Jobs in der Liste ausgegeben. === Job als persistent markieren per ecmd === '''cron persistent N 1''' macht den Nten Job persistent '''cron persistent N 0''' löscht das persistent flag '''cron persistent N''' zeigt den aktuellen Status an === Persistente Jobs ins VFS/EEPROM schreiben per ecmd === '''cron save''' alle als persistent markierten Jobs werden im VFS/EEPROM abgespeichert. === Job für UTC-Zeit markieren per ecmd === '''cron utc N 1''' setzt den Nten Job auf UTC '''cron utc N 0''' löscht das UTC flag '''cron utc N''' zeigt den aktuellen Status an === Cronjob im Quelltext definieren: Callback Funktion === Wer scharf hinsieht, erkennt, dass diese Funktionalität auch durch den statischen Cron Daemon abgedeckt wird. Der statische Dienst verbraucht dabei sogar weniger Ressourcen. Aber, hier die Vorteile des dynamischen Dienstes: * Du musst keinen Quelltext in ein fremdes Modul einfügen (Übersichtlichkeit der cron_static.c nimmt mit jedem weiterem Modul ab) * Du kannst zur Laufzeit den cronjob auch wieder entfernen. * Du kannst Extradaten an die Callback Funktion übergeben Die Funktion, welche der Daemon aufrufen soll, muss folgende Signatur haben '''void func(char* data)''' und sollte ''nicht'' in der cron/cron.c Datei definiert werden, sondern in dem jeweiligen Modul, welche die Cron Funktionalität nutzen will. # Binde in dein Modul die Datei 'cron/cron.h' ein. # Nutze die Callback Variante des Cron-Einfügen Befehls '''cron_jobinsert_callback''' in der Initalisierungsfunktion deines Moduls um beim Start von ethersex cronjobs hinzuzufügen. # Die Funktionsparameter haben die folgende Semantik: * Minute, -1 für ignorieren, -2 für jede 2te Minute etc * Stunde, -1 für ignorieren, -2 für jede 2te Stunde etc * Tag, -1 für ignorieren, -2 für jeden 2te Tag etc * Monat, -1 für ignorieren, -2 für jeden 2te Monat etc * Wochentag, 1 für Sonntag, 2 für Montag, 4 für Dienstag, 8 für Mittwoch, 16 für Donnerstag, 32 für Freitag, 64 für Samstag oder eine Addition daraus * Wiederholen, INFINIT_RUNNING für endlos, 1=einmal etc * Position des Crons in der Cronliste (CRON_APPEND, wenn angehängt werden soll) * Callback Funktion * Größe von Extradaten * Extradaten Beispiel aus der Test Einträge Datei: void test(void* data) { /* tu was */ } // in init cron_jobinsert_callback(-1, -2, -1, -1, -1, INFINIT_RUNNING, CRON_APPEND, test, 0, NULL); Extradaten sind eine ziemlich coole Sache. Stella PWM zum Beispiel speichert darin Lichtkanal und Zielwert. Beim Aktivieren des Cronjobs wird der Zeiger auf diese Extradaten dann an die Callback Funktion mit übergeben und diese stehen direkt zur Verfügung. Bitte beachte hierbei aber, dass der Pointer auf die Extradaten durch einen Malloc Aufruf gewonnen werden muss, sprich die Speicherstelle für die Extradaten müssen vorher auf dem Heap allokiert werden. (Beispiel: '''char* extra = malloc(2);''' für 2 Bytes auf dem Heap) Du musst und solltest dich nicht um die Freigabe des allokierten Speichers kümmern. Dies erledigt der Cron daemon bereits. === Cronjob im Quelltext definieren: Ecmd aufrufen === Der statische cron daemon bot die Möglichkeit eine Funktion zu gegebenem Zeitpunkt aufzurufen. Wenn du jedoch den dynamischen Dienst nutzt, kannst du auch ecmd Befehle zeitabhängig aufrufen lassen (z.B. Pins setzen, Stella PWM kontrollieren, ethersex reseten etc). Die Funktion die du in dein Modul hierfür einbauen musst, lautet folgendermaßen: cron_jobinsert_ecmd(-1, -2, -1, -1, 127, INFINIT_RUNNING, CRON_APPEND, "ECMD"); 8ef9a63028dae57d368826620c10774fd252b7f4 442 441 2012-04-05T07:38:41Z Sittner 461 wikitext text/x-wiki {{i18n|Cron}} {{Module |NAME=Tank level meter |MENUCONFIG={{Applications}}->Cron daemon |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]], [[Clock]] |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/services/cron https://github.com/ethersex/ethersex/tree/master/services/cron] }} Der Cron daemon verwaltet so genannte cron jobs. Diese Regeln definieren bestimmte immer wiederkehrende oder einmalige Zeitpunkte zu denen dann Kommandos ausgeführt werden können. Cronjobs sind auf zweifache Weise in Ethersex implementiert. Eine statische Liste, die zur Compilierzeit bestimmt werden muss und danach auch nicht mehr beeinflusst werden kann und einen dynamischen Ansatz, bei dem die Jobs beim Start von Ethersex in den Ram geladen werden. Danach können nach belieben Jobs entfernt und hinzugefügt werden. == Voraussetzungen == Beide Ansätze haben gemeinsam, dass du erst einmal eine Funktion definieren musst, welche vom Cron daemon zum bestimmten Zeitpunkt aufgerufen werden kann. Die Funktionssignatur sieht allerdings, abhängig davon welche Implementierung du wählst, leicht anders aus. == Menuconfig == Das Modul benötigt allerdings die aktuelle Zeit um richtig funktionieren zu können. Du musst daher im selben Untermenü mindestens eine Zeitquelle ebenfalls einschalten. Um Crontabs in ethersex zu aktivieren, wählt man im Menü │ │ Load a Default Configuration ---> │ │ ... │ │ Applications ---> │ │ ... │ │ [*] Cron daemon ---> │ │ [ ] Cron daemon (static jobs) == Statischer Cron Daemon == Die Funktion, welche der Daemon aufrufen soll, muss folgende Signatur haben '''void func(void)''' und muss direkt in cron_static/cron_static.c definiert werden. Es muss dann nur noch eine Regel in die Array Struktur events vom Typ ''cron_static_event_t'' eingefügt werden. Die Werte der Reihenfolge nach stehen für Minute, Stunde, Tag, Monat, Wochentag, Callback Funktion und ob UTC oder die lokale Zeitzone benutzt werden soll. Eine -1 steht für einen Platzhalter. Da die Einträge ca. jede Minute einmal geprüft werden, wird also ein Eintrag mit nur Platzhalter Werten auch ca. jede Minute ausgeführt. Werte unter -1 haben die Bedeutung von "jede x-te Minute/Stunde/etc". Also ein Wert von -4 an der Minutenstelle bedeutet, dass der Crontab jede 4te Minute ausgeführt wird. == Dynamischer Cron Daemon == === Auslesen per ecmd === Einfach den ecmd Befehl '''cron list''' zum Beispiel in deinem Browser ausführen. Es werden alle aktuellen Jobs angezeigt, pro Job zwei Zeilen. Die erste Zeile enthält die Attribute des Jobs (Position, Wiederholungen, ecmd/Callback-Job, UTC-Zeit, u.s.w.), in der zweiten Zeile werden die Zeitdaten (MIN HOUR DAY MONTH DAYOFWEEK) und der ecmd Befehl bzw. die Callback Addresse angezeigt. === Entfernen per ecmd === '''cron rm N''' entfernt den Nten Job (fängt bei 0 an zu zählen) aus der cron Liste. Vorsicht! '''cron rm''' ohne Parameter entfernt ALLE cron jobs, und das ohne vorher nachzufragen! === Hinzufügen per ecmd === '''cron add MIN HOUR DAY MONTH DAYOFWEEK ECMD''' MIN HOUR DAY MONTH und DAYOFWEEK können -1 (als Platzhalterfunktion) annehmen. ECMD: Der ecmd Befehl, der ausgeführt werden soll. Nach dem Anlegen wird die Position des neuen Jobs in der Liste ausgegeben. === Job als persistent markieren per ecmd === '''cron persistent N 1''' macht den Nten Job persistent '''cron persistent N 0''' löscht das persistent flag '''cron persistent N''' zeigt den aktuellen Status an === Persistente Jobs ins VFS/EEPROM schreiben per ecmd === '''cron save''' alle als persistent markierten Jobs werden im VFS/EEPROM abgespeichert. === Job für UTC-Zeit markieren per ecmd === '''cron utc N 1''' setzt den Nten Job auf UTC '''cron utc N 0''' löscht das UTC flag '''cron utc N''' zeigt den aktuellen Status an === Job als anacron Job markieren per ecmd === Dieses Flag bietet eine Art anacron Funktion. Gedacht ist dies für Jobs, die bestimmte Stati setzen. Ein Beispiel wäre die Zirkulationspumpe einer Heizung. Angenommen die Pumpe soll um 6.00 Uhr eingesaltet und um 9.00 wieder ausgeschaltet werden, könnte das natürlich auch mit normalen Jobs erledigt werden. Sollte der Controller allerdings um 7.00 neu booten (z.B. wg. Stromausfall) bliebe Pumpe bis zum nächsten Tag 6.00 ausgeschaltet. Ähnliches gilt für grössere Zeitsprünge durch NTP-Updates. Um das Problem zu lösen, werden alle anacron Jobs nachgezogen, die innerhalb des übersprungenen Zeitraums (also vom 1.1.1970 bis zur aktuellen Zeit im Falle das Boots) hätten ausgeführt werden müssen, wobei jeder Job nur einmal ausgeführt wird und auch in der korrekten Reihenfolge (jüngstes Ausführungsdatum zählt). Damit die Schleife zum Ermitteln der Jobs nicht unnötog lange dauert, ist der Startzeitpunkt in der Vergangenheit auf <Aktuelle Zeit> - CRON_ANACRON_MAXAGE Sekunden beschränkt. Voreingestellt ist hier ein Tag (86400 Sekunden). '''cron anacron N 1''' markiere den Nten Job als anacron Job '''cron anacron N 0''' löscht das UTC flag '''cron anacron N''' zeigt den aktuellen Status an === Cronjob im Quelltext definieren: Callback Funktion === Wer scharf hinsieht, erkennt, dass diese Funktionalität auch durch den statischen Cron Daemon abgedeckt wird. Der statische Dienst verbraucht dabei sogar weniger Ressourcen. Aber, hier die Vorteile des dynamischen Dienstes: * Du musst keinen Quelltext in ein fremdes Modul einfügen (Übersichtlichkeit der cron_static.c nimmt mit jedem weiterem Modul ab) * Du kannst zur Laufzeit den cronjob auch wieder entfernen. * Du kannst Extradaten an die Callback Funktion übergeben Die Funktion, welche der Daemon aufrufen soll, muss folgende Signatur haben '''void func(char* data)''' und sollte ''nicht'' in der cron/cron.c Datei definiert werden, sondern in dem jeweiligen Modul, welche die Cron Funktionalität nutzen will. # Binde in dein Modul die Datei 'cron/cron.h' ein. # Nutze die Callback Variante des Cron-Einfügen Befehls '''cron_jobinsert_callback''' in der Initalisierungsfunktion deines Moduls um beim Start von ethersex cronjobs hinzuzufügen. # Die Funktionsparameter haben die folgende Semantik: * Minute, -1 für ignorieren, -2 für jede 2te Minute etc * Stunde, -1 für ignorieren, -2 für jede 2te Stunde etc * Tag, -1 für ignorieren, -2 für jeden 2te Tag etc * Monat, -1 für ignorieren, -2 für jeden 2te Monat etc * Wochentag, 1 für Sonntag, 2 für Montag, 4 für Dienstag, 8 für Mittwoch, 16 für Donnerstag, 32 für Freitag, 64 für Samstag oder eine Addition daraus * Wiederholen, INFINIT_RUNNING für endlos, 1=einmal etc * Position des Crons in der Cronliste (CRON_APPEND, wenn angehängt werden soll) * Callback Funktion * Größe von Extradaten * Extradaten Beispiel aus der Test Einträge Datei: void test(void* data) { /* tu was */ } // in init cron_jobinsert_callback(-1, -2, -1, -1, -1, INFINIT_RUNNING, CRON_APPEND, test, 0, NULL); Extradaten sind eine ziemlich coole Sache. Stella PWM zum Beispiel speichert darin Lichtkanal und Zielwert. Beim Aktivieren des Cronjobs wird der Zeiger auf diese Extradaten dann an die Callback Funktion mit übergeben und diese stehen direkt zur Verfügung. Bitte beachte hierbei aber, dass der Pointer auf die Extradaten durch einen Malloc Aufruf gewonnen werden muss, sprich die Speicherstelle für die Extradaten müssen vorher auf dem Heap allokiert werden. (Beispiel: '''char* extra = malloc(2);''' für 2 Bytes auf dem Heap) Du musst und solltest dich nicht um die Freigabe des allokierten Speichers kümmern. Dies erledigt der Cron daemon bereits. === Cronjob im Quelltext definieren: Ecmd aufrufen === Der statische cron daemon bot die Möglichkeit eine Funktion zu gegebenem Zeitpunkt aufzurufen. Wenn du jedoch den dynamischen Dienst nutzt, kannst du auch ecmd Befehle zeitabhängig aufrufen lassen (z.B. Pins setzen, Stella PWM kontrollieren, ethersex reseten etc). Die Funktion die du in dein Modul hierfür einbauen musst, lautet folgendermaßen: cron_jobinsert_ecmd(-1, -2, -1, -1, 127, INFINIT_RUNNING, CRON_APPEND, "ECMD"); 74a32759e1aa06320df28d350cf9d4e7bb20025f 443 442 2012-04-05T07:46:27Z Sittner 461 /* Job als anacron Job markieren per ecmd */ wikitext text/x-wiki {{i18n|Cron}} {{Module |NAME=Tank level meter |MENUCONFIG={{Applications}}->Cron daemon |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]], [[Clock]] |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/services/cron https://github.com/ethersex/ethersex/tree/master/services/cron] }} Der Cron daemon verwaltet so genannte cron jobs. Diese Regeln definieren bestimmte immer wiederkehrende oder einmalige Zeitpunkte zu denen dann Kommandos ausgeführt werden können. Cronjobs sind auf zweifache Weise in Ethersex implementiert. Eine statische Liste, die zur Compilierzeit bestimmt werden muss und danach auch nicht mehr beeinflusst werden kann und einen dynamischen Ansatz, bei dem die Jobs beim Start von Ethersex in den Ram geladen werden. Danach können nach belieben Jobs entfernt und hinzugefügt werden. == Voraussetzungen == Beide Ansätze haben gemeinsam, dass du erst einmal eine Funktion definieren musst, welche vom Cron daemon zum bestimmten Zeitpunkt aufgerufen werden kann. Die Funktionssignatur sieht allerdings, abhängig davon welche Implementierung du wählst, leicht anders aus. == Menuconfig == Das Modul benötigt allerdings die aktuelle Zeit um richtig funktionieren zu können. Du musst daher im selben Untermenü mindestens eine Zeitquelle ebenfalls einschalten. Um Crontabs in ethersex zu aktivieren, wählt man im Menü │ │ Load a Default Configuration ---> │ │ ... │ │ Applications ---> │ │ ... │ │ [*] Cron daemon ---> │ │ [ ] Cron daemon (static jobs) == Statischer Cron Daemon == Die Funktion, welche der Daemon aufrufen soll, muss folgende Signatur haben '''void func(void)''' und muss direkt in cron_static/cron_static.c definiert werden. Es muss dann nur noch eine Regel in die Array Struktur events vom Typ ''cron_static_event_t'' eingefügt werden. Die Werte der Reihenfolge nach stehen für Minute, Stunde, Tag, Monat, Wochentag, Callback Funktion und ob UTC oder die lokale Zeitzone benutzt werden soll. Eine -1 steht für einen Platzhalter. Da die Einträge ca. jede Minute einmal geprüft werden, wird also ein Eintrag mit nur Platzhalter Werten auch ca. jede Minute ausgeführt. Werte unter -1 haben die Bedeutung von "jede x-te Minute/Stunde/etc". Also ein Wert von -4 an der Minutenstelle bedeutet, dass der Crontab jede 4te Minute ausgeführt wird. == Dynamischer Cron Daemon == === Auslesen per ecmd === Einfach den ecmd Befehl '''cron list''' zum Beispiel in deinem Browser ausführen. Es werden alle aktuellen Jobs angezeigt, pro Job zwei Zeilen. Die erste Zeile enthält die Attribute des Jobs (Position, Wiederholungen, ecmd/Callback-Job, UTC-Zeit, u.s.w.), in der zweiten Zeile werden die Zeitdaten (MIN HOUR DAY MONTH DAYOFWEEK) und der ecmd Befehl bzw. die Callback Addresse angezeigt. === Entfernen per ecmd === '''cron rm N''' entfernt den Nten Job (fängt bei 0 an zu zählen) aus der cron Liste. Vorsicht! '''cron rm''' ohne Parameter entfernt ALLE cron jobs, und das ohne vorher nachzufragen! === Hinzufügen per ecmd === '''cron add MIN HOUR DAY MONTH DAYOFWEEK ECMD''' MIN HOUR DAY MONTH und DAYOFWEEK können -1 (als Platzhalterfunktion) annehmen. ECMD: Der ecmd Befehl, der ausgeführt werden soll. Nach dem Anlegen wird die Position des neuen Jobs in der Liste ausgegeben. === Job als persistent markieren per ecmd === '''cron persistent N 1''' macht den Nten Job persistent '''cron persistent N 0''' löscht das persistent flag '''cron persistent N''' zeigt den aktuellen Status an === Persistente Jobs ins VFS/EEPROM schreiben per ecmd === '''cron save''' alle als persistent markierten Jobs werden im VFS/EEPROM abgespeichert. === Job für UTC-Zeit markieren per ecmd === '''cron utc N 1''' setzt den Nten Job auf UTC '''cron utc N 0''' löscht das UTC flag '''cron utc N''' zeigt den aktuellen Status an === Job als anacron-Job markieren per ecmd === Dieses Flag bietet eine Art anacron-Funktion. Gedacht ist dies für Jobs, die bestimmte Stati setzen. Ein Beispiel wäre die Zirkulationspumpe einer Heizung. Angenommen die Pumpe soll um 6.00 Uhr eingesaltet und um 9.00 wieder ausgeschaltet werden, könnte das natürlich auch mit normalen Jobs erledigt werden. Sollte der Controller allerdings um 7.00 neu booten (z.B. wg. Stromausfall) bliebe Pumpe bis zum nächsten Tag 6.00 ausgeschaltet. Ähnliches gilt für grössere Zeitsprünge durch NTP-Updates. Um das Problem zu lösen, werden alle anacron-Jobs nachgezogen, die innerhalb des übersprungenen Zeitraums (also vom 1.1.1970 bis zur aktuellen Zeit im Falle das Boots) hätten ausgeführt werden müssen, wobei jeder Job nur einmal ausgeführt wird und auch in der korrekten Reihenfolge (jüngstes Ausführungsdatum zählt). Damit die Schleife zum Ermitteln der Jobs nicht unnötig lange dauert, ist der Startzeitpunkt in der Vergangenheit auf <Aktuelle Zeit> - CRON_ANACRON_MAXAGE Sekunden beschränkt. Voreingestellt ist hier ein Tag (86400 Sekunden). '''cron anacron N 1''' markiere den Nten Job als anacron Job '''cron anacron N 0''' löscht das UTC flag '''cron anacron N''' zeigt den aktuellen Status an === Cronjob im Quelltext definieren: Callback Funktion === Wer scharf hinsieht, erkennt, dass diese Funktionalität auch durch den statischen Cron Daemon abgedeckt wird. Der statische Dienst verbraucht dabei sogar weniger Ressourcen. Aber, hier die Vorteile des dynamischen Dienstes: * Du musst keinen Quelltext in ein fremdes Modul einfügen (Übersichtlichkeit der cron_static.c nimmt mit jedem weiterem Modul ab) * Du kannst zur Laufzeit den cronjob auch wieder entfernen. * Du kannst Extradaten an die Callback Funktion übergeben Die Funktion, welche der Daemon aufrufen soll, muss folgende Signatur haben '''void func(char* data)''' und sollte ''nicht'' in der cron/cron.c Datei definiert werden, sondern in dem jeweiligen Modul, welche die Cron Funktionalität nutzen will. # Binde in dein Modul die Datei 'cron/cron.h' ein. # Nutze die Callback Variante des Cron-Einfügen Befehls '''cron_jobinsert_callback''' in der Initalisierungsfunktion deines Moduls um beim Start von ethersex cronjobs hinzuzufügen. # Die Funktionsparameter haben die folgende Semantik: * Minute, -1 für ignorieren, -2 für jede 2te Minute etc * Stunde, -1 für ignorieren, -2 für jede 2te Stunde etc * Tag, -1 für ignorieren, -2 für jeden 2te Tag etc * Monat, -1 für ignorieren, -2 für jeden 2te Monat etc * Wochentag, 1 für Sonntag, 2 für Montag, 4 für Dienstag, 8 für Mittwoch, 16 für Donnerstag, 32 für Freitag, 64 für Samstag oder eine Addition daraus * Wiederholen, INFINIT_RUNNING für endlos, 1=einmal etc * Position des Crons in der Cronliste (CRON_APPEND, wenn angehängt werden soll) * Callback Funktion * Größe von Extradaten * Extradaten Beispiel aus der Test Einträge Datei: void test(void* data) { /* tu was */ } // in init cron_jobinsert_callback(-1, -2, -1, -1, -1, INFINIT_RUNNING, CRON_APPEND, test, 0, NULL); Extradaten sind eine ziemlich coole Sache. Stella PWM zum Beispiel speichert darin Lichtkanal und Zielwert. Beim Aktivieren des Cronjobs wird der Zeiger auf diese Extradaten dann an die Callback Funktion mit übergeben und diese stehen direkt zur Verfügung. Bitte beachte hierbei aber, dass der Pointer auf die Extradaten durch einen Malloc Aufruf gewonnen werden muss, sprich die Speicherstelle für die Extradaten müssen vorher auf dem Heap allokiert werden. (Beispiel: '''char* extra = malloc(2);''' für 2 Bytes auf dem Heap) Du musst und solltest dich nicht um die Freigabe des allokierten Speichers kümmern. Dies erledigt der Cron daemon bereits. === Cronjob im Quelltext definieren: Ecmd aufrufen === Der statische cron daemon bot die Möglichkeit eine Funktion zu gegebenem Zeitpunkt aufzurufen. Wenn du jedoch den dynamischen Dienst nutzt, kannst du auch ecmd Befehle zeitabhängig aufrufen lassen (z.B. Pins setzen, Stella PWM kontrollieren, ethersex reseten etc). Die Funktion die du in dein Modul hierfür einbauen musst, lautet folgendermaßen: cron_jobinsert_ecmd(-1, -2, -1, -1, 127, INFINIT_RUNNING, CRON_APPEND, "ECMD"); 5070dbfe2c79b84699c71739841c9fcc247a40b9 444 443 2012-04-05T07:50:34Z Sittner 461 wikitext text/x-wiki {{i18n|Cron}} {{Module |NAME=Cron daemon |MENUCONFIG={{Applications}}->Cron daemon |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]], [[Clock]] |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/services/cron https://github.com/ethersex/ethersex/tree/master/services/cron] }} Der Cron daemon verwaltet so genannte cron jobs. Diese Regeln definieren bestimmte immer wiederkehrende oder einmalige Zeitpunkte zu denen dann Kommandos ausgeführt werden können. Cronjobs sind auf zweifache Weise in Ethersex implementiert. Eine statische Liste, die zur Compilierzeit bestimmt werden muss und danach auch nicht mehr beeinflusst werden kann und einen dynamischen Ansatz, bei dem die Jobs beim Start von Ethersex in den Ram geladen werden. Danach können nach belieben Jobs entfernt und hinzugefügt werden. == Voraussetzungen == Beide Ansätze haben gemeinsam, dass du erst einmal eine Funktion definieren musst, welche vom Cron daemon zum bestimmten Zeitpunkt aufgerufen werden kann. Die Funktionssignatur sieht allerdings, abhängig davon welche Implementierung du wählst, leicht anders aus. == Menuconfig == Das Modul benötigt allerdings die aktuelle Zeit um richtig funktionieren zu können. Du musst daher im selben Untermenü mindestens eine Zeitquelle ebenfalls einschalten. Um Crontabs in ethersex zu aktivieren, wählt man im Menü │ │ Load a Default Configuration ---> │ │ ... │ │ Applications ---> │ │ ... │ │ [*] Cron daemon ---> │ │ [ ] Cron daemon (static jobs) == Statischer Cron Daemon == Die Funktion, welche der Daemon aufrufen soll, muss folgende Signatur haben '''void func(void)''' und muss direkt in cron_static/cron_static.c definiert werden. Es muss dann nur noch eine Regel in die Array Struktur events vom Typ ''cron_static_event_t'' eingefügt werden. Die Werte der Reihenfolge nach stehen für Minute, Stunde, Tag, Monat, Wochentag, Callback Funktion und ob UTC oder die lokale Zeitzone benutzt werden soll. Eine -1 steht für einen Platzhalter. Da die Einträge ca. jede Minute einmal geprüft werden, wird also ein Eintrag mit nur Platzhalter Werten auch ca. jede Minute ausgeführt. Werte unter -1 haben die Bedeutung von "jede x-te Minute/Stunde/etc". Also ein Wert von -4 an der Minutenstelle bedeutet, dass der Crontab jede 4te Minute ausgeführt wird. == Dynamischer Cron Daemon == === Auslesen per ecmd === Einfach den ecmd Befehl '''cron list''' zum Beispiel in deinem Browser ausführen. Es werden alle aktuellen Jobs angezeigt, pro Job zwei Zeilen. Die erste Zeile enthält die Attribute des Jobs (Position, Wiederholungen, ecmd/Callback-Job, UTC-Zeit, u.s.w.), in der zweiten Zeile werden die Zeitdaten (MIN HOUR DAY MONTH DAYOFWEEK) und der ecmd Befehl bzw. die Callback Addresse angezeigt. === Entfernen per ecmd === '''cron rm N''' entfernt den Nten Job (fängt bei 0 an zu zählen) aus der cron Liste. Vorsicht! '''cron rm''' ohne Parameter entfernt ALLE cron jobs, und das ohne vorher nachzufragen! === Hinzufügen per ecmd === '''cron add MIN HOUR DAY MONTH DAYOFWEEK ECMD''' MIN HOUR DAY MONTH und DAYOFWEEK können -1 (als Platzhalterfunktion) annehmen. ECMD: Der ecmd Befehl, der ausgeführt werden soll. Nach dem Anlegen wird die Position des neuen Jobs in der Liste ausgegeben. === Job als persistent markieren per ecmd === '''cron persistent N 1''' macht den Nten Job persistent '''cron persistent N 0''' löscht das persistent flag '''cron persistent N''' zeigt den aktuellen Status an === Persistente Jobs ins VFS/EEPROM schreiben per ecmd === '''cron save''' alle als persistent markierten Jobs werden im VFS/EEPROM abgespeichert. === Job für UTC-Zeit markieren per ecmd === '''cron utc N 1''' setzt den Nten Job auf UTC '''cron utc N 0''' löscht das UTC flag '''cron utc N''' zeigt den aktuellen Status an === Job als anacron-Job markieren per ecmd === Dieses Flag bietet eine Art anacron-Funktion. Gedacht ist dies für Jobs, die bestimmte Stati setzen. Ein Beispiel wäre die Zirkulationspumpe einer Heizung. Angenommen die Pumpe soll um 6.00 Uhr eingesaltet und um 9.00 wieder ausgeschaltet werden, könnte das natürlich auch mit normalen Jobs erledigt werden. Sollte der Controller allerdings um 7.00 neu booten (z.B. wg. Stromausfall) bliebe Pumpe bis zum nächsten Tag 6.00 ausgeschaltet. Ähnliches gilt für grössere Zeitsprünge durch NTP-Updates. Um das Problem zu lösen, werden alle anacron-Jobs nachgezogen, die innerhalb des übersprungenen Zeitraums (also vom 1.1.1970 bis zur aktuellen Zeit im Falle das Boots) hätten ausgeführt werden müssen, wobei jeder Job nur einmal ausgeführt wird und auch in der korrekten Reihenfolge (jüngstes Ausführungsdatum zählt). Damit die Schleife zum Ermitteln der Jobs nicht unnötig lange dauert, ist der Startzeitpunkt in der Vergangenheit auf <Aktuelle Zeit> - CRON_ANACRON_MAXAGE Sekunden beschränkt. Voreingestellt ist hier ein Tag (86400 Sekunden). '''cron anacron N 1''' markiere den Nten Job als anacron Job '''cron anacron N 0''' löscht das UTC flag '''cron anacron N''' zeigt den aktuellen Status an === Cronjob im Quelltext definieren: Callback Funktion === Wer scharf hinsieht, erkennt, dass diese Funktionalität auch durch den statischen Cron Daemon abgedeckt wird. Der statische Dienst verbraucht dabei sogar weniger Ressourcen. Aber, hier die Vorteile des dynamischen Dienstes: * Du musst keinen Quelltext in ein fremdes Modul einfügen (Übersichtlichkeit der cron_static.c nimmt mit jedem weiterem Modul ab) * Du kannst zur Laufzeit den cronjob auch wieder entfernen. * Du kannst Extradaten an die Callback Funktion übergeben Die Funktion, welche der Daemon aufrufen soll, muss folgende Signatur haben '''void func(char* data)''' und sollte ''nicht'' in der cron/cron.c Datei definiert werden, sondern in dem jeweiligen Modul, welche die Cron Funktionalität nutzen will. # Binde in dein Modul die Datei 'cron/cron.h' ein. # Nutze die Callback Variante des Cron-Einfügen Befehls '''cron_jobinsert_callback''' in der Initalisierungsfunktion deines Moduls um beim Start von ethersex cronjobs hinzuzufügen. # Die Funktionsparameter haben die folgende Semantik: * Minute, -1 für ignorieren, -2 für jede 2te Minute etc * Stunde, -1 für ignorieren, -2 für jede 2te Stunde etc * Tag, -1 für ignorieren, -2 für jeden 2te Tag etc * Monat, -1 für ignorieren, -2 für jeden 2te Monat etc * Wochentag, 1 für Sonntag, 2 für Montag, 4 für Dienstag, 8 für Mittwoch, 16 für Donnerstag, 32 für Freitag, 64 für Samstag oder eine Addition daraus * Wiederholen, INFINIT_RUNNING für endlos, 1=einmal etc * Position des Crons in der Cronliste (CRON_APPEND, wenn angehängt werden soll) * Callback Funktion * Größe von Extradaten * Extradaten Beispiel aus der Test Einträge Datei: void test(void* data) { /* tu was */ } // in init cron_jobinsert_callback(-1, -2, -1, -1, -1, INFINIT_RUNNING, CRON_APPEND, test, 0, NULL); Extradaten sind eine ziemlich coole Sache. Stella PWM zum Beispiel speichert darin Lichtkanal und Zielwert. Beim Aktivieren des Cronjobs wird der Zeiger auf diese Extradaten dann an die Callback Funktion mit übergeben und diese stehen direkt zur Verfügung. Bitte beachte hierbei aber, dass der Pointer auf die Extradaten durch einen Malloc Aufruf gewonnen werden muss, sprich die Speicherstelle für die Extradaten müssen vorher auf dem Heap allokiert werden. (Beispiel: '''char* extra = malloc(2);''' für 2 Bytes auf dem Heap) Du musst und solltest dich nicht um die Freigabe des allokierten Speichers kümmern. Dies erledigt der Cron daemon bereits. === Cronjob im Quelltext definieren: Ecmd aufrufen === Der statische cron daemon bot die Möglichkeit eine Funktion zu gegebenem Zeitpunkt aufzurufen. Wenn du jedoch den dynamischen Dienst nutzt, kannst du auch ecmd Befehle zeitabhängig aufrufen lassen (z.B. Pins setzen, Stella PWM kontrollieren, ethersex reseten etc). Die Funktion die du in dein Modul hierfür einbauen musst, lautet folgendermaßen: cron_jobinsert_ecmd(-1, -2, -1, -1, 127, INFINIT_RUNNING, CRON_APPEND, "ECMD"); 3b8e8057b1ec56b53ceb25b0e3d50ea012b6a92e 455 444 2012-04-06T12:13:48Z Sittner 461 wikitext text/x-wiki {{i18n|Cron}} {{Module |NAME=Cron daemon |MENUCONFIG={{Applications}}->Cron daemon |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]], [[Clock]] |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/services/cron https://github.com/ethersex/ethersex/tree/master/services/cron] }} Der Cron daemon verwaltet so genannte cron jobs. Diese Regeln definieren bestimmte immer wiederkehrende oder einmalige Zeitpunkte zu denen dann Kommandos ausgeführt werden können. Cronjobs sind auf zweifache Weise in Ethersex implementiert. Eine statische Liste, die zur Compilierzeit bestimmt werden muss und danach auch nicht mehr beeinflusst werden kann und einen dynamischen Ansatz, bei dem die Jobs beim Start von Ethersex in den Ram geladen werden. Danach können nach belieben Jobs entfernt und hinzugefügt werden. == Voraussetzungen == Beide Ansätze haben gemeinsam, dass du erst einmal eine Funktion definieren musst, welche vom Cron daemon zum bestimmten Zeitpunkt aufgerufen werden kann. Die Funktionssignatur sieht allerdings, abhängig davon welche Implementierung du wählst, leicht anders aus. == Menuconfig == Das Modul benötigt allerdings die aktuelle Zeit um richtig funktionieren zu können. Du musst daher im selben Untermenü mindestens eine Zeitquelle ebenfalls einschalten. Um Crontabs in ethersex zu aktivieren, wählt man im Menü │ │ Load a Default Configuration ---> │ │ ... │ │ Applications ---> │ │ ... │ │ [*] Cron daemon ---> │ │ [ ] Cron daemon (static jobs) == Statischer Cron Daemon == Die Funktion, welche der Daemon aufrufen soll, muss folgende Signatur haben '''void func(void)''' und muss direkt in cron_static/cron_static.c definiert werden. Es muss dann nur noch eine Regel in das Struktur-Array ''events'' vom Typ ''cron_static_event_t'' eingefügt werden. Die Werte der Reihenfolge nach stehen für Minute, Stunde, Tag, Monat, Wochentag, Callback Funktion und ob UTC oder die lokale Zeitzone benutzt werden soll. Eine -1 steht für einen Platzhalter. Da die Einträge ca. jede Minute einmal geprüft werden, wird also ein Eintrag mit nur Platzhalter Werten auch ca. jede Minute ausgeführt. Werte unter -1 haben die Bedeutung von "jede x-te Minute/Stunde/etc". Also ein Wert von -4 an der Minutenstelle bedeutet, dass der Crontab jede 4te Minute ausgeführt wird. == Dynamischer Cron Daemon == === Auslesen per ecmd === Einfach den ecmd Befehl '''cron list''' zum Beispiel in deinem Browser ausführen. Es werden alle aktuellen Jobs angezeigt, pro Job zwei Zeilen. Die erste Zeile enthält die Attribute des Jobs (Position, Wiederholungen, ecmd/Callback-Job, UTC-Zeit, u.s.w.), in der zweiten Zeile werden die Zeitdaten (MIN HOUR DAY MONTH DAYOFWEEK) und der ecmd Befehl bzw. die Callback Addresse angezeigt. === Entfernen per ecmd === '''cron rm N''' entfernt den Nten Job (fängt bei 0 an zu zählen) aus der cron Liste. Vorsicht! '''cron rm''' ohne Parameter entfernt ALLE cron jobs, und das ohne vorher nachzufragen! === Hinzufügen per ecmd === '''cron add MIN HOUR DAY MONTH DAYOFWEEK ECMD''' MIN HOUR DAY MONTH und DAYOFWEEK können -1 (als Platzhalterfunktion) annehmen. ECMD: Der ecmd Befehl, der ausgeführt werden soll. Nach dem Anlegen wird die Position des neuen Jobs in der Liste ausgegeben. === Job als persistent markieren per ecmd === '''cron persistent N 1''' macht den Nten Job persistent '''cron persistent N 0''' löscht das persistent flag '''cron persistent N''' zeigt den aktuellen Status an === Persistente Jobs ins VFS/EEPROM schreiben per ecmd === '''cron save''' alle als persistent markierten Jobs werden im VFS/EEPROM abgespeichert. === Job für UTC-Zeit markieren per ecmd === '''cron utc N 1''' setzt den Nten Job auf UTC '''cron utc N 0''' löscht das UTC flag '''cron utc N''' zeigt den aktuellen Status an === Job als anacron-Job markieren per ecmd === Dieses Flag bietet eine Art anacron-Funktion. Gedacht ist dies für Jobs, die bestimmte Stati setzen. Ein Beispiel wäre die Zirkulationspumpe einer Heizung. Angenommen die Pumpe soll um 6.00 Uhr eingesaltet und um 9.00 wieder ausgeschaltet werden, könnte das natürlich auch mit normalen Jobs erledigt werden. Sollte der Controller allerdings um 7.00 neu booten (z.B. wg. Stromausfall) bliebe Pumpe bis zum nächsten Tag 6.00 ausgeschaltet. Ähnliches gilt für grössere Zeitsprünge durch NTP-Updates. Um das Problem zu lösen, werden alle anacron-Jobs nachgezogen, die innerhalb des übersprungenen Zeitraums (also vom 1.1.1970 bis zur aktuellen Zeit im Falle das Boots) hätten ausgeführt werden müssen, wobei jeder Job nur einmal ausgeführt wird und auch in der korrekten Reihenfolge (jüngstes Ausführungsdatum zählt). Damit die Schleife zum Ermitteln der Jobs nicht unnötig lange dauert, ist der Startzeitpunkt in der Vergangenheit auf <Aktuelle Zeit> - CRON_ANACRON_MAXAGE Sekunden beschränkt. Voreingestellt ist hier ein Tag (86400 Sekunden). '''cron anacron N 1''' markiere den Nten Job als anacron Job '''cron anacron N 0''' löscht das anacron flag '''cron anacron N''' zeigt den aktuellen Status an === Cronjob im Quelltext definieren: Callback Funktion === Wer scharf hinsieht, erkennt, dass diese Funktionalität auch durch den statischen Cron Daemon abgedeckt wird. Der statische Dienst verbraucht dabei sogar weniger Ressourcen. Aber, hier die Vorteile des dynamischen Dienstes: * Du musst keinen Quelltext in ein fremdes Modul einfügen (Übersichtlichkeit der cron_static.c nimmt mit jedem weiterem Modul ab) * Du kannst zur Laufzeit den cronjob auch wieder entfernen. * Du kannst Extradaten an die Callback Funktion übergeben Die Funktion, welche der Daemon aufrufen soll, muss folgende Signatur haben '''void func(char* data)''' und sollte ''nicht'' in der cron/cron.c Datei definiert werden, sondern in dem jeweiligen Modul, welche die Cron Funktionalität nutzen will. # Binde in dein Modul die Datei 'cron/cron.h' ein. # Nutze die Callback Variante des Cron-Einfügen Befehls '''cron_jobinsert_callback''' in der Initalisierungsfunktion deines Moduls um beim Start von ethersex cronjobs hinzuzufügen. # Die Funktionsparameter haben die folgende Semantik: * Minute, -1 für ignorieren, -2 für jede 2te Minute etc * Stunde, -1 für ignorieren, -2 für jede 2te Stunde etc * Tag, -1 für ignorieren, -2 für jeden 2te Tag etc * Monat, -1 für ignorieren, -2 für jeden 2te Monat etc * Wochentag, 1 für Sonntag, 2 für Montag, 4 für Dienstag, 8 für Mittwoch, 16 für Donnerstag, 32 für Freitag, 64 für Samstag oder eine Addition daraus * Wiederholen, INFINIT_RUNNING für endlos, 1=einmal etc * Position des Crons in der Cronliste (CRON_APPEND, wenn angehängt werden soll) * Callback Funktion * Größe von Extradaten * Extradaten Beispiel aus der Test Einträge Datei: void test(void* data) { /* tu was */ } // in init cron_jobinsert_callback(-1, -2, -1, -1, -1, INFINIT_RUNNING, CRON_APPEND, test, 0, NULL); Extradaten sind eine ziemlich coole Sache. Stella PWM zum Beispiel speichert darin Lichtkanal und Zielwert. Beim Aktivieren des Cronjobs wird der Zeiger auf diese Extradaten dann an die Callback Funktion mit übergeben und diese stehen direkt zur Verfügung. Bitte beachte hierbei aber, dass der Pointer auf die Extradaten durch einen Malloc Aufruf gewonnen werden muss, sprich die Speicherstelle für die Extradaten müssen vorher auf dem Heap allokiert werden. (Beispiel: '''char* extra = malloc(2);''' für 2 Bytes auf dem Heap) Du musst und solltest dich nicht um die Freigabe des allokierten Speichers kümmern. Dies erledigt der Cron daemon bereits. === Cronjob im Quelltext definieren: Ecmd aufrufen === Der statische cron daemon bot die Möglichkeit eine Funktion zu gegebenem Zeitpunkt aufzurufen. Wenn du jedoch den dynamischen Dienst nutzt, kannst du auch ecmd Befehle zeitabhängig aufrufen lassen (z.B. Pins setzen, Stella PWM kontrollieren, ethersex reseten etc). Die Funktion die du in dein Modul hierfür einbauen musst, lautet folgendermaßen: cron_jobinsert_ecmd(-1, -2, -1, -1, 127, INFINIT_RUNNING, CRON_APPEND, "ECMD"); 497b33065a7c57275c9d2dfa94720752779e6fa7 0 180 459 2012-04-07T09:10:14Z Pirndi 462 Created page with "= Was ist ECMD? = ECMD steht für '''Ethersex Command'''. ECMD ist ein einfaches, textbasiertes Protokoll mit dem mit einem Ethersex-System kommuniziert werden kann. Neben der Ko…" wikitext text/x-wiki = Was ist ECMD? = ECMD steht für '''Ethersex Command'''. ECMD ist ein einfaches, textbasiertes Protokoll mit dem mit einem Ethersex-System kommuniziert werden kann. Neben der Konfiguration des Ethersex Systems können auch die Hardware Schnittstellen angesprochen werden. Viele Module bieten ebenfalls ecmd Unterstützung an. Einen Überblick über die implementieren Befehle gibt die [[ECMD Reference]]. = ECMD Schnittstellen = Unter [[ECMD Protocols|ECMD Protokolle]] kannst du nachlesen, wie dein ethersex mit ECMD angesprochen werden kann. Wenn du dein ethersex über Shell Scripte oder eigene Programme ansprechen möchtest, empfiehlt sich evtl. die libecmd (geschrieben in C) im contrib Ordner, welche alle [[ECMD Protocols|ECMD Protokolle]] beherrscht. = Eigenen ECMD Befehl erstellen = == Vorbereitung == # Wechsel in den Ordner des Moduls, welches ein neues ECMD bekommen soll. # Erstelle eine Datei <tt>[modulname]_ecmd.c</tt> # Füge <tt>#include "protocols/ecmd/ecmd-base.h</tt> ein == Funktionen == Baue nun Funktionen mit einer Signatur wie die folgende Funktion hat: <pre> int16_t parse_cmd_FUNCTIONSNAME (char *cmd, char *output, uint16_t len) { zu_was(); return ECMD_FINAL_OK; } </pre> ECMD_FINAL_OK bedeutet hier, das der Aufruf ein Erfolg war. Hierrauf wird im http Interface beispielsweise ein OK zurückgegeben. Wenn etwas schief läuft oder die Argumentanzahl falsch ist, dann kannst du ECMD_ERR_PARSE_ERROR zurückgeben. Wie läuft das eigentlich mit den ecmd Argumenten für dein neues Kommando? Hier siehst du ein kleines Beispiel um 3 Zahlen als Argumente entgegen zunehmen: <pre> int16_t parse_cmd_FUNCTIONSNAME2 (char *cmd, char *output, uint16_t len) { uint8_t val1=0; uint8_t val2=0; uint8_t val3 = 0; ret = sscanf_P(cmd, PSTR("%hhu %hhu %hhu"), &val1, &val2, &val3); if (ret == 3) return ECMD_FINAL_OK; else return ECMD_ERR_PARSE_ERROR; } </pre> Möchtest du auch andere Dinge als OK und PARSE ERROR zurückgeben können, nimmst du folgenden Code: <pre> return ECMD_FINAL(snprintf_P(output, len, PSTR("%u"), uint_value)); </pre> Hier wurde ein unsigned int zurückgegeben. == Bekanntmachen == Nun musst du deine Funktion noch dem Rest der Firmware bekannt machen. Füge daher ganz unten in der Datei folgendes ein: <pre> /* -- Ethersex META -- block(Cooles Modul) ecmd_feature(FUNCTIONSNAME, "NEW ECMD COMMAND",, DESCRIPTION) ecmd_feature(FUNCTIONSNAME2, "NEW ECMD COMMAND2",VAL1 VAL2 VAL3, DESCRIPTION) */ </pre> == Makefile erweitern == Läuft analog zu normalen anderen Quellcode Dateien. = ECMD Geschwindigkeit = Eine Untersuchung zur Geschwindigkeit verschiedener Anbindungen und Konfigurationen ist unter [[ECMD Geschwindigkeit]] zu finden. [[Kategorie:ECMD]] 7d0d579d017ad47671b8532814f20de7bf7cfeb4 467 459 2012-04-07T10:20:58Z Pirndi 462 wikitext text/x-wiki {{i18n|ECMD}} {{Module |NAME=ECMD |MENUCONFIG={{Protocols}}->ECMD (Etherrape Command Interface) support |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/protocols/ecmd https://github.com/ethersex/ethersex/tree/master/protocols/ecmd] }} = Was ist ECMD? = ECMD steht für '''Ethersex Command'''. ECMD ist ein einfaches, textbasiertes Protokoll mit dem mit einem Ethersex-System kommuniziert werden kann. Neben der Konfiguration des Ethersex Systems können auch die Hardware Schnittstellen angesprochen werden. Viele Module bieten ebenfalls ecmd Unterstützung an. Einen Überblick über die implementieren Befehle gibt die [[ECMD Reference]]. = ECMD Schnittstellen = Unter [[ECMD Protocols|ECMD Protokolle]] kannst du nachlesen, wie dein ethersex mit ECMD angesprochen werden kann. Wenn du dein ethersex über Shell Scripte oder eigene Programme ansprechen möchtest, empfiehlt sich evtl. die libecmd (geschrieben in C) im contrib Ordner, welche alle [[ECMD Protocols|ECMD Protokolle]] beherrscht. = Eigenen ECMD Befehl erstellen = == Vorbereitung == # Wechsel in den Ordner des Moduls, welches ein neues ECMD bekommen soll. # Erstelle eine Datei <tt>[modulname]_ecmd.c</tt> # Füge <tt>#include "protocols/ecmd/ecmd-base.h</tt> ein == Funktionen == Baue nun Funktionen mit einer Signatur wie die folgende Funktion hat: <pre> int16_t parse_cmd_FUNCTIONSNAME (char *cmd, char *output, uint16_t len) { zu_was(); return ECMD_FINAL_OK; } </pre> ECMD_FINAL_OK bedeutet hier, das der Aufruf ein Erfolg war. Hierrauf wird im http Interface beispielsweise ein OK zurückgegeben. Wenn etwas schief läuft oder die Argumentanzahl falsch ist, dann kannst du ECMD_ERR_PARSE_ERROR zurückgeben. Wie läuft das eigentlich mit den ecmd Argumenten für dein neues Kommando? Hier siehst du ein kleines Beispiel um 3 Zahlen als Argumente entgegen zunehmen: <pre> int16_t parse_cmd_FUNCTIONSNAME2 (char *cmd, char *output, uint16_t len) { uint8_t val1=0; uint8_t val2=0; uint8_t val3 = 0; ret = sscanf_P(cmd, PSTR("%hhu %hhu %hhu"), &val1, &val2, &val3); if (ret == 3) return ECMD_FINAL_OK; else return ECMD_ERR_PARSE_ERROR; } </pre> Möchtest du auch andere Dinge als OK und PARSE ERROR zurückgeben können, nimmst du folgenden Code: <pre> return ECMD_FINAL(snprintf_P(output, len, PSTR("%u"), uint_value)); </pre> Hier wurde ein unsigned int zurückgegeben. == Bekanntmachen == Nun musst du deine Funktion noch dem Rest der Firmware bekannt machen. Füge daher ganz unten in der Datei folgendes ein: <pre> /* -- Ethersex META -- block(Cooles Modul) ecmd_feature(FUNCTIONSNAME, "NEW ECMD COMMAND",, DESCRIPTION) ecmd_feature(FUNCTIONSNAME2, "NEW ECMD COMMAND2",VAL1 VAL2 VAL3, DESCRIPTION) */ </pre> == Makefile erweitern == Läuft analog zu normalen anderen Quellcode Dateien. = ECMD Geschwindigkeit = Eine Untersuchung zur Geschwindigkeit verschiedener Anbindungen und Konfigurationen ist unter [[ECMD Geschwindigkeit]] zu finden. [[Kategorie:ECMD]] 038c0a419d159dcc5109bca4e69e05350aa9d83b 473 467 2012-04-07T16:32:36Z Mgue 312 /* ECMD Geschwindigkeit */ wikitext text/x-wiki {{i18n|ECMD}} {{Module |NAME=ECMD |MENUCONFIG={{Protocols}}->ECMD (Etherrape Command Interface) support |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/protocols/ecmd https://github.com/ethersex/ethersex/tree/master/protocols/ecmd] }} = Was ist ECMD? = ECMD steht für '''Ethersex Command'''. ECMD ist ein einfaches, textbasiertes Protokoll mit dem mit einem Ethersex-System kommuniziert werden kann. Neben der Konfiguration des Ethersex Systems können auch die Hardware Schnittstellen angesprochen werden. Viele Module bieten ebenfalls ecmd Unterstützung an. Einen Überblick über die implementieren Befehle gibt die [[ECMD Reference]]. = ECMD Schnittstellen = Unter [[ECMD Protocols|ECMD Protokolle]] kannst du nachlesen, wie dein ethersex mit ECMD angesprochen werden kann. Wenn du dein ethersex über Shell Scripte oder eigene Programme ansprechen möchtest, empfiehlt sich evtl. die libecmd (geschrieben in C) im contrib Ordner, welche alle [[ECMD Protocols|ECMD Protokolle]] beherrscht. = Eigenen ECMD Befehl erstellen = == Vorbereitung == # Wechsel in den Ordner des Moduls, welches ein neues ECMD bekommen soll. # Erstelle eine Datei <tt>[modulname]_ecmd.c</tt> # Füge <tt>#include "protocols/ecmd/ecmd-base.h</tt> ein == Funktionen == Baue nun Funktionen mit einer Signatur wie die folgende Funktion hat: <pre> int16_t parse_cmd_FUNCTIONSNAME (char *cmd, char *output, uint16_t len) { zu_was(); return ECMD_FINAL_OK; } </pre> ECMD_FINAL_OK bedeutet hier, das der Aufruf ein Erfolg war. Hierrauf wird im http Interface beispielsweise ein OK zurückgegeben. Wenn etwas schief läuft oder die Argumentanzahl falsch ist, dann kannst du ECMD_ERR_PARSE_ERROR zurückgeben. Wie läuft das eigentlich mit den ecmd Argumenten für dein neues Kommando? Hier siehst du ein kleines Beispiel um 3 Zahlen als Argumente entgegen zunehmen: <pre> int16_t parse_cmd_FUNCTIONSNAME2 (char *cmd, char *output, uint16_t len) { uint8_t val1=0; uint8_t val2=0; uint8_t val3 = 0; ret = sscanf_P(cmd, PSTR("%hhu %hhu %hhu"), &val1, &val2, &val3); if (ret == 3) return ECMD_FINAL_OK; else return ECMD_ERR_PARSE_ERROR; } </pre> Möchtest du auch andere Dinge als OK und PARSE ERROR zurückgeben können, nimmst du folgenden Code: <pre> return ECMD_FINAL(snprintf_P(output, len, PSTR("%u"), uint_value)); </pre> Hier wurde ein unsigned int zurückgegeben. == Bekanntmachen == Nun musst du deine Funktion noch dem Rest der Firmware bekannt machen. Füge daher ganz unten in der Datei folgendes ein: <pre> /* -- Ethersex META -- block(Cooles Modul) ecmd_feature(FUNCTIONSNAME, "NEW ECMD COMMAND",, DESCRIPTION) ecmd_feature(FUNCTIONSNAME2, "NEW ECMD COMMAND2",VAL1 VAL2 VAL3, DESCRIPTION) */ </pre> == Makefile erweitern == Läuft analog zu normalen anderen Quellcode Dateien. = ECMD Geschwindigkeit = Eine Untersuchung zur Geschwindigkeit verschiedener Anbindungen und Konfigurationen ist unter [[ECMD Geschwindigkeit]] zu finden. 506e905a5159ac4f1be0af2a3f223aa775a03a50 0 181 460 2012-04-07T09:14:42Z Pirndi 462 Created page with "Unter Annahme, dass du ETHERSEX-IP, ECMD-PORT und ECMD-COMMAND entsprechend substituierst, kannst du unter folgenden Protokollen für die Übertragung von ecmd Befehlen wählen: …" wikitext text/x-wiki Unter Annahme, dass du ETHERSEX-IP, ECMD-PORT und ECMD-COMMAND entsprechend substituierst, kannst du unter folgenden Protokollen für die Übertragung von ecmd Befehlen wählen: == ECMD via HTTP == Muss in menuconfig eingeschaltet werden. Dann ist folgendes URL Schema möglich: <pre>http://ETHERSEX-IP/ecmd?ECMD-COMMAND</pre> == ECMD via USART == Muss in menuconfig eingeschaltet werden. Baue zum Beispiel mit dem Programm screen eine Verbindung zu deinem ethersex auf. Etwa wie folgt: <pre>screen /dev/ttyUSB0 115200</pre> Nun kannst du ecmd Befehle eintippen und mit Enter bestätigen. Die Rückgabe des Kommandos erfolgt dann auf dem Terminal. == ECMD via TWI (I2C) == Muss in menuconfig eingeschaltet werden. == ECMD via UDP == Muss in menuconfig eingeschaltet werden. Standard Port ist '''2701'''. Kann einfach in Unix shell scripts eingebunden werden. Ein Beispiel: (current timestamp on your Ethersex as a variable in your shell) * '''nc''' steht für '''netcat''' * nur '''"netcat-openbsd"''' kennt den Parameter '''"-q"''' <pre>ECMD_DATE=`echo 'date' | nc -u ETHERSEX-IP ECMD-PORT`</pre> oder <pre>ECMD_DATE=`echo "date"|nc -u -q 1 ETHERSEX-IP ECMD-PORT`</pre> == ECMD via TCP == Muss in menuconfig eingeschaltet werden. Standard Port ist '''2701'''. Hier ist eine Authentifizierung mit [[PAM]] möglich. Benutze ein Ausrufezeichen '''!''' vor einem ecmd Kommando um die tcp Verbindung sofort nach der Übertraung wieder abzubauen. Kann einfach in Unix shell scripts eingebunden werden. Ein Beispiel: (current timestamp on your Ethersex as a variable in your shell) * '''nc''' steht für '''netcat''' * nur '''"netcat-openbsd"''' kennt den Parameter '''"-q"''' <pre>ECMD_DATE=`echo '!date' | nc ETHERSEX-IP ECMD-PORT`</pre> oder <pre>ECMD_DATE=`echo '!date' | nc -q 1 ETHERSEX-IP ECMD-PORT`</pre> oder <pre>ECMD_DATE=`echo '!date' | socat stdio tcp4:ETHERSEX-IP ECMD-PORT`</pre> == ECMD via USB == Muss in menuconfig eingeschaltet werden. Hierfür gibt es im contrib Ordner ein kleines C Programm um Befehle via USB zu versenden. Siehe auch [[USB#ECMD_via_USB]] == ECMD via SMS == Hierzu muss in der menuconfig "SMS Support" unter I/O aktiviert werden, sowie "SMS" unter Protocols -> ECMD [[Category:Ethersex]] [[Kategorie:ECMD]] 8ebee50969b95110bf4bc6039aa37b638d957961 468 460 2012-04-07T10:34:34Z Pirndi 462 /* ECMD via TWI (I2C) */ wikitext text/x-wiki Unter Annahme, dass du ETHERSEX-IP, ECMD-PORT und ECMD-COMMAND entsprechend substituierst, kannst du unter folgenden Protokollen für die Übertragung von ecmd Befehlen wählen: == ECMD via HTTP == Muss in menuconfig eingeschaltet werden. Dann ist folgendes URL Schema möglich: <pre>http://ETHERSEX-IP/ecmd?ECMD-COMMAND</pre> == ECMD via USART == Muss in menuconfig eingeschaltet werden. Baue zum Beispiel mit dem Programm screen eine Verbindung zu deinem ethersex auf. Etwa wie folgt: <pre>screen /dev/ttyUSB0 115200</pre> Nun kannst du ecmd Befehle eintippen und mit Enter bestätigen. Die Rückgabe des Kommandos erfolgt dann auf dem Terminal. == ECMD via TWI (I2C) == * Muss in menuconfig eingeschaltet werden. * Die I2C Befehle können aus der [[ECMD Reference]] entnommen werden * Weitere Infos zu Ethersex [[I2C]] == ECMD via UDP == Muss in menuconfig eingeschaltet werden. Standard Port ist '''2701'''. Kann einfach in Unix shell scripts eingebunden werden. Ein Beispiel: (current timestamp on your Ethersex as a variable in your shell) * '''nc''' steht für '''netcat''' * nur '''"netcat-openbsd"''' kennt den Parameter '''"-q"''' <pre>ECMD_DATE=`echo 'date' | nc -u ETHERSEX-IP ECMD-PORT`</pre> oder <pre>ECMD_DATE=`echo "date"|nc -u -q 1 ETHERSEX-IP ECMD-PORT`</pre> == ECMD via TCP == Muss in menuconfig eingeschaltet werden. Standard Port ist '''2701'''. Hier ist eine Authentifizierung mit [[PAM]] möglich. Benutze ein Ausrufezeichen '''!''' vor einem ecmd Kommando um die tcp Verbindung sofort nach der Übertraung wieder abzubauen. Kann einfach in Unix shell scripts eingebunden werden. Ein Beispiel: (current timestamp on your Ethersex as a variable in your shell) * '''nc''' steht für '''netcat''' * nur '''"netcat-openbsd"''' kennt den Parameter '''"-q"''' <pre>ECMD_DATE=`echo '!date' | nc ETHERSEX-IP ECMD-PORT`</pre> oder <pre>ECMD_DATE=`echo '!date' | nc -q 1 ETHERSEX-IP ECMD-PORT`</pre> oder <pre>ECMD_DATE=`echo '!date' | socat stdio tcp4:ETHERSEX-IP ECMD-PORT`</pre> == ECMD via USB == Muss in menuconfig eingeschaltet werden. Hierfür gibt es im contrib Ordner ein kleines C Programm um Befehle via USB zu versenden. Siehe auch [[USB#ECMD_via_USB]] == ECMD via SMS == Hierzu muss in der menuconfig "SMS Support" unter I/O aktiviert werden, sowie "SMS" unter Protocols -> ECMD [[Category:Ethersex]] [[Kategorie:ECMD]] 62bb634c8141ef16ca526c76b14fe10cadf069ef 469 468 2012-04-07T10:53:38Z Pirndi 462 wikitext text/x-wiki Unter Annahme, dass du ETHERSEX-IP, ECMD-PORT und ECMD-COMMAND entsprechend substituierst, kannst du unter folgenden Protokollen für die Übertragung von ecmd Befehlen wählen: == ECMD via HTTP == Muss in menuconfig eingeschaltet werden. Dann ist folgendes URL Schema möglich: <pre>http://ETHERSEX-IP/ecmd?ECMD-COMMAND</pre> == ECMD via USART == Muss in menuconfig eingeschaltet werden. Baue zum Beispiel mit dem Programm screen eine Verbindung zu deinem ethersex auf. Etwa wie folgt: <pre>screen /dev/ttyUSB0 115200</pre> Nun kannst du ecmd Befehle eintippen und mit Enter bestätigen. Die Rückgabe des Kommandos erfolgt dann auf dem Terminal. == ECMD via TWI (I2C) == * Muss in menuconfig eingeschaltet werden. * Die I2C Befehle können aus der [[ECMD Reference]] entnommen werden * Weitere Infos zu Ethersex [[I2C (Deutsch)| I2C]] == ECMD via UDP == Muss in menuconfig eingeschaltet werden. Standard Port ist '''2701'''. Kann einfach in Unix shell scripts eingebunden werden. Ein Beispiel: (current timestamp on your Ethersex as a variable in your shell) * '''nc''' steht für '''netcat''' * nur '''"netcat-openbsd"''' kennt den Parameter '''"-q"''' <pre>ECMD_DATE=`echo 'date' | nc -u ETHERSEX-IP ECMD-PORT`</pre> oder <pre>ECMD_DATE=`echo "date"|nc -u -q 1 ETHERSEX-IP ECMD-PORT`</pre> == ECMD via TCP == Muss in menuconfig eingeschaltet werden. Standard Port ist '''2701'''. Hier ist eine Authentifizierung mit [[PAM]] möglich. Benutze ein Ausrufezeichen '''!''' vor einem ecmd Kommando um die tcp Verbindung sofort nach der Übertraung wieder abzubauen. Kann einfach in Unix shell scripts eingebunden werden. Ein Beispiel: (current timestamp on your Ethersex as a variable in your shell) * '''nc''' steht für '''netcat''' * nur '''"netcat-openbsd"''' kennt den Parameter '''"-q"''' <pre>ECMD_DATE=`echo '!date' | nc ETHERSEX-IP ECMD-PORT`</pre> oder <pre>ECMD_DATE=`echo '!date' | nc -q 1 ETHERSEX-IP ECMD-PORT`</pre> oder <pre>ECMD_DATE=`echo '!date' | socat stdio tcp4:ETHERSEX-IP ECMD-PORT`</pre> == ECMD via USB == Muss in menuconfig eingeschaltet werden. Hierfür gibt es im contrib Ordner ein kleines C Programm um Befehle via USB zu versenden. Siehe auch [[USB#ECMD_via_USB]] == ECMD via SMS == Hierzu muss in der menuconfig "SMS Support" unter I/O aktiviert werden, sowie "SMS" unter Protocols -> ECMD [[Category:Ethersex]] 007d1bd5c650e68be7ec6c0a4a06153e7df70d69 470 469 2012-04-07T15:09:41Z GooPie4o 265 moved [[ECMD Protocols]] to [[ECMD Protocols (Deutsch)]]:&#32;i18N wikitext text/x-wiki Unter Annahme, dass du ETHERSEX-IP, ECMD-PORT und ECMD-COMMAND entsprechend substituierst, kannst du unter folgenden Protokollen für die Übertragung von ecmd Befehlen wählen: == ECMD via HTTP == Muss in menuconfig eingeschaltet werden. Dann ist folgendes URL Schema möglich: <pre>http://ETHERSEX-IP/ecmd?ECMD-COMMAND</pre> == ECMD via USART == Muss in menuconfig eingeschaltet werden. Baue zum Beispiel mit dem Programm screen eine Verbindung zu deinem ethersex auf. Etwa wie folgt: <pre>screen /dev/ttyUSB0 115200</pre> Nun kannst du ecmd Befehle eintippen und mit Enter bestätigen. Die Rückgabe des Kommandos erfolgt dann auf dem Terminal. == ECMD via TWI (I2C) == * Muss in menuconfig eingeschaltet werden. * Die I2C Befehle können aus der [[ECMD Reference]] entnommen werden * Weitere Infos zu Ethersex [[I2C (Deutsch)| I2C]] == ECMD via UDP == Muss in menuconfig eingeschaltet werden. Standard Port ist '''2701'''. Kann einfach in Unix shell scripts eingebunden werden. Ein Beispiel: (current timestamp on your Ethersex as a variable in your shell) * '''nc''' steht für '''netcat''' * nur '''"netcat-openbsd"''' kennt den Parameter '''"-q"''' <pre>ECMD_DATE=`echo 'date' | nc -u ETHERSEX-IP ECMD-PORT`</pre> oder <pre>ECMD_DATE=`echo "date"|nc -u -q 1 ETHERSEX-IP ECMD-PORT`</pre> == ECMD via TCP == Muss in menuconfig eingeschaltet werden. Standard Port ist '''2701'''. Hier ist eine Authentifizierung mit [[PAM]] möglich. Benutze ein Ausrufezeichen '''!''' vor einem ecmd Kommando um die tcp Verbindung sofort nach der Übertraung wieder abzubauen. Kann einfach in Unix shell scripts eingebunden werden. Ein Beispiel: (current timestamp on your Ethersex as a variable in your shell) * '''nc''' steht für '''netcat''' * nur '''"netcat-openbsd"''' kennt den Parameter '''"-q"''' <pre>ECMD_DATE=`echo '!date' | nc ETHERSEX-IP ECMD-PORT`</pre> oder <pre>ECMD_DATE=`echo '!date' | nc -q 1 ETHERSEX-IP ECMD-PORT`</pre> oder <pre>ECMD_DATE=`echo '!date' | socat stdio tcp4:ETHERSEX-IP ECMD-PORT`</pre> == ECMD via USB == Muss in menuconfig eingeschaltet werden. Hierfür gibt es im contrib Ordner ein kleines C Programm um Befehle via USB zu versenden. Siehe auch [[USB#ECMD_via_USB]] == ECMD via SMS == Hierzu muss in der menuconfig "SMS Support" unter I/O aktiviert werden, sowie "SMS" unter Protocols -> ECMD [[Category:Ethersex]] 007d1bd5c650e68be7ec6c0a4a06153e7df70d69 472 470 2012-04-07T15:10:55Z GooPie4o 265 wikitext text/x-wiki {{i18n|ECMD Protocols}} Unter Annahme, dass du ETHERSEX-IP, ECMD-PORT und ECMD-COMMAND entsprechend substituierst, kannst du unter folgenden Protokollen für die Übertragung von ecmd Befehlen wählen: == ECMD via HTTP == Muss in menuconfig eingeschaltet werden. Dann ist folgendes URL Schema möglich: <pre>http://ETHERSEX-IP/ecmd?ECMD-COMMAND</pre> == ECMD via USART == Muss in menuconfig eingeschaltet werden. Baue zum Beispiel mit dem Programm screen eine Verbindung zu deinem ethersex auf. Etwa wie folgt: <pre>screen /dev/ttyUSB0 115200</pre> Nun kannst du ecmd Befehle eintippen und mit Enter bestätigen. Die Rückgabe des Kommandos erfolgt dann auf dem Terminal. == ECMD via TWI (I2C) == * Muss in menuconfig eingeschaltet werden. * Die I2C Befehle können aus der [[ECMD Reference]] entnommen werden * Weitere Infos zu Ethersex [[I2C (Deutsch)| I2C]] == ECMD via UDP == Muss in menuconfig eingeschaltet werden. Standard Port ist '''2701'''. Kann einfach in Unix shell scripts eingebunden werden. Ein Beispiel: (current timestamp on your Ethersex as a variable in your shell) * '''nc''' steht für '''netcat''' * nur '''"netcat-openbsd"''' kennt den Parameter '''"-q"''' <pre>ECMD_DATE=`echo 'date' | nc -u ETHERSEX-IP ECMD-PORT`</pre> oder <pre>ECMD_DATE=`echo "date"|nc -u -q 1 ETHERSEX-IP ECMD-PORT`</pre> == ECMD via TCP == Muss in menuconfig eingeschaltet werden. Standard Port ist '''2701'''. Hier ist eine Authentifizierung mit [[PAM]] möglich. Benutze ein Ausrufezeichen '''!''' vor einem ecmd Kommando um die tcp Verbindung sofort nach der Übertraung wieder abzubauen. Kann einfach in Unix shell scripts eingebunden werden. Ein Beispiel: (current timestamp on your Ethersex as a variable in your shell) * '''nc''' steht für '''netcat''' * nur '''"netcat-openbsd"''' kennt den Parameter '''"-q"''' <pre>ECMD_DATE=`echo '!date' | nc ETHERSEX-IP ECMD-PORT`</pre> oder <pre>ECMD_DATE=`echo '!date' | nc -q 1 ETHERSEX-IP ECMD-PORT`</pre> oder <pre>ECMD_DATE=`echo '!date' | socat stdio tcp4:ETHERSEX-IP ECMD-PORT`</pre> == ECMD via USB == Muss in menuconfig eingeschaltet werden. Hierfür gibt es im contrib Ordner ein kleines C Programm um Befehle via USB zu versenden. Siehe auch [[USB#ECMD_via_USB]] == ECMD via SMS == Hierzu muss in der menuconfig "SMS Support" unter I/O aktiviert werden, sowie "SMS" unter Protocols -> ECMD [[Category:Ethersex]] be31b7e79c71cc41d7200d53341ecb0af45dcf22 0 182 461 2012-04-07T09:16:27Z Pirndi 462 Created page with "ECMD steht für Ethersex Command. d.h. in dieser Kategorie sollen alle zum ECMD bezogenen Informationen gesammelt werden." wikitext text/x-wiki ECMD steht für Ethersex Command. d.h. in dieser Kategorie sollen alle zum ECMD bezogenen Informationen gesammelt werden. f9d88f2a2fb796140ba184fd0211dd6dc3ead214 0 183 462 2012-04-07T09:26:47Z Pirndi 462 Created page with "Der I2C-Bus (Inter Integrated Circuit) ist ein einfacher Zweidraht-Bus, der für die Kommunikation zwischen ICs innerhalb eines größeren Systems verwendet wird. Insbesondere bi…" wikitext text/x-wiki Der I2C-Bus (Inter Integrated Circuit) ist ein einfacher Zweidraht-Bus, der für die Kommunikation zwischen ICs innerhalb eines größeren Systems verwendet wird. Insbesondere bietet er sich an zur Kommunikation zwischen Microcontrollern und Peripheriegeräten. Das [[Ethersex]]-System kann sowohl als Master als auch als Slave in einem I2C-Bus arbeiten. In der Atmel-Dokumentation wird I2C als TWI (Two Wire Interface) geführt. ==Master Mode== Im Master-Mode kann das Ethersex-System auf angeschlossene I2C-Slaves zugreifen. Unterstützt werden im Moment: * 24cXX EEPROMs (Als Storage Backend für das Virtuelle Dateisystem) * LM75 Temperatursensoren * PCA9531 8 bit LED Dimmer * PCF8574x Port Extension ==Slave Mode== * Kann per I2C auf die [[ECMD]] Schnittstelle zugegriffen werden. * In menuconfig -> Protocols -> ECMD -> I2C aktivieren * [[Beispiel]] Ethersex und ein zweiter AVR ==Anschluss== Die Leitungen SCL (Clock) und SDA (Data) liegen als "Alternate Function" auf I/O Leitungen der Controller. Beim ATmega32 sind dies PC0 (SCL) und PC1 (SDA). ===Etherrape=== Beim [[Etherrape]] ist der I2C-Bus auf einem separaten Steckverbinder herausgeführt. ===Pollin AVR-NET-IO=== Beim Pollin [[AVR-NET-IO]] liegen die Leitungen des Ports C auf J3, dem 25poligen SUB-D Steckverbinder. Dort lassen sich auch Versorgungsspannung und Masse für die angeschlossenen Slaves abgreifen: {|class=wikitable !Pin !Funktion |- |2 |PC0 (SCL) |- |3 |PC1 (SDA) |- |15 |5V |- |18 |GND |} ==Konfiguration== Die Leitungen sind fest vorgegeben, daher muss keine Konfiguration des Pinnings erfolgen. Die Einstellungen für den Master-Mode finden sich unter "I/O support", "I2C Master Support". == ECMD == = I2C = Mittels "i2c detect" werden die gefundenen I2C Adressen aufgelistet i2c detect detected at: 0x20 (32) detected at: 0x48 (72) detected at: 0x60 (96) Mit den allgemeinen I2C-Kommandos können alle I2C-Chips angesprochen werden. Mit dem Befehl i2c wbb 72 81 wird z. B. die Temperatur-Konvertierung auf einem DS1631 gestartet. Geschrieben wird ein Byte mit dem Wert 81 an den Chip mit der Adresse 72. Mit dem Befehl i2c rwd 72 170 wird ein Word von der Adresse 170 des Chips mit der Adresse 72 gelesen. Damit wird die Temperatur des DS1631 ausgelesen. Die Umrechung muß man dann per Hand durchführen. = LM75 = Um den LM75 Temperatursensor auszulesen (Basisadresse 0x48) muss die IC Adresse angegeben werden. In diesem Falle ist das "0" weil die IC Adresse a0 bis a2 auf Masse gesetzt werden. -> binär 000 = 0 lm75 0 21.5 = DS1631 = Ein DS1631 Temperatursensor muß nach dem Einschalten der Stromversorgung erst aktiviert werden. Der erste DS1631 mit der Adresse 0x48 hat im Befehl die Adresse 0. Mit dem folgenden Befehl wird die Temperatur-Konvertierung eingeschaltet: ds1631 convert 0 1 Jetzt kann die Temperatur ausgelesen werden. Die Genauigkeit beträgt immer die vollen 12bits. ds1631 temp 0 22.875 Wahrscheinlich können auch DS1621-Sensoren ausgelesen werden, das wurde aber noch nicht getestet! = PCF8574 = Für die Porterweiterung gilt das Schema "pcf8574x read adresse chip" wobei die adresse 0-7 sein kann, und chip "0" oder "1", je nachdem ob man den pcf8574 oder den pcf8574A benutzt. pcf8574x read 0 0 FFFF Schalten von Ausgängen mit Wert 0xF0 am PCF8574 mit Adresse 5 (Das bedeutet das a0=1 und a2=1 ist, ergo 101) d.h. die ersten 4 Ausgänge werden auf "1" die anderen 4 Ausgänge auf "0" gesetzt. pcf8574x set 5 0 F0 [[Category:Ethersex]] [[Category:StepByStep]] [[Category:I2C]] [[Category:ECMD]] a7d97abb29cebdec2f496afc72a24b5610fe01e6 463 462 2012-04-07T10:09:04Z GooPie4o 265 moved [[I2C]] to [[I2C (Deutsch)]]:&#32;german version of page wikitext text/x-wiki Der I2C-Bus (Inter Integrated Circuit) ist ein einfacher Zweidraht-Bus, der für die Kommunikation zwischen ICs innerhalb eines größeren Systems verwendet wird. Insbesondere bietet er sich an zur Kommunikation zwischen Microcontrollern und Peripheriegeräten. Das [[Ethersex]]-System kann sowohl als Master als auch als Slave in einem I2C-Bus arbeiten. In der Atmel-Dokumentation wird I2C als TWI (Two Wire Interface) geführt. ==Master Mode== Im Master-Mode kann das Ethersex-System auf angeschlossene I2C-Slaves zugreifen. Unterstützt werden im Moment: * 24cXX EEPROMs (Als Storage Backend für das Virtuelle Dateisystem) * LM75 Temperatursensoren * PCA9531 8 bit LED Dimmer * PCF8574x Port Extension ==Slave Mode== * Kann per I2C auf die [[ECMD]] Schnittstelle zugegriffen werden. * In menuconfig -> Protocols -> ECMD -> I2C aktivieren * [[Beispiel]] Ethersex und ein zweiter AVR ==Anschluss== Die Leitungen SCL (Clock) und SDA (Data) liegen als "Alternate Function" auf I/O Leitungen der Controller. Beim ATmega32 sind dies PC0 (SCL) und PC1 (SDA). ===Etherrape=== Beim [[Etherrape]] ist der I2C-Bus auf einem separaten Steckverbinder herausgeführt. ===Pollin AVR-NET-IO=== Beim Pollin [[AVR-NET-IO]] liegen die Leitungen des Ports C auf J3, dem 25poligen SUB-D Steckverbinder. Dort lassen sich auch Versorgungsspannung und Masse für die angeschlossenen Slaves abgreifen: {|class=wikitable !Pin !Funktion |- |2 |PC0 (SCL) |- |3 |PC1 (SDA) |- |15 |5V |- |18 |GND |} ==Konfiguration== Die Leitungen sind fest vorgegeben, daher muss keine Konfiguration des Pinnings erfolgen. Die Einstellungen für den Master-Mode finden sich unter "I/O support", "I2C Master Support". == ECMD == = I2C = Mittels "i2c detect" werden die gefundenen I2C Adressen aufgelistet i2c detect detected at: 0x20 (32) detected at: 0x48 (72) detected at: 0x60 (96) Mit den allgemeinen I2C-Kommandos können alle I2C-Chips angesprochen werden. Mit dem Befehl i2c wbb 72 81 wird z. B. die Temperatur-Konvertierung auf einem DS1631 gestartet. Geschrieben wird ein Byte mit dem Wert 81 an den Chip mit der Adresse 72. Mit dem Befehl i2c rwd 72 170 wird ein Word von der Adresse 170 des Chips mit der Adresse 72 gelesen. Damit wird die Temperatur des DS1631 ausgelesen. Die Umrechung muß man dann per Hand durchführen. = LM75 = Um den LM75 Temperatursensor auszulesen (Basisadresse 0x48) muss die IC Adresse angegeben werden. In diesem Falle ist das "0" weil die IC Adresse a0 bis a2 auf Masse gesetzt werden. -> binär 000 = 0 lm75 0 21.5 = DS1631 = Ein DS1631 Temperatursensor muß nach dem Einschalten der Stromversorgung erst aktiviert werden. Der erste DS1631 mit der Adresse 0x48 hat im Befehl die Adresse 0. Mit dem folgenden Befehl wird die Temperatur-Konvertierung eingeschaltet: ds1631 convert 0 1 Jetzt kann die Temperatur ausgelesen werden. Die Genauigkeit beträgt immer die vollen 12bits. ds1631 temp 0 22.875 Wahrscheinlich können auch DS1621-Sensoren ausgelesen werden, das wurde aber noch nicht getestet! = PCF8574 = Für die Porterweiterung gilt das Schema "pcf8574x read adresse chip" wobei die adresse 0-7 sein kann, und chip "0" oder "1", je nachdem ob man den pcf8574 oder den pcf8574A benutzt. pcf8574x read 0 0 FFFF Schalten von Ausgängen mit Wert 0xF0 am PCF8574 mit Adresse 5 (Das bedeutet das a0=1 und a2=1 ist, ergo 101) d.h. die ersten 4 Ausgänge werden auf "1" die anderen 4 Ausgänge auf "0" gesetzt. pcf8574x set 5 0 F0 [[Category:Ethersex]] [[Category:StepByStep]] [[Category:I2C]] [[Category:ECMD]] a7d97abb29cebdec2f496afc72a24b5610fe01e6 466 463 2012-04-07T10:18:47Z GooPie4o 265 wikitext text/x-wiki {{i18n|I2C}} Der I2C-Bus (Inter Integrated Circuit) ist ein einfacher Zweidraht-Bus, der für die Kommunikation zwischen ICs innerhalb eines größeren Systems verwendet wird. Insbesondere bietet er sich an zur Kommunikation zwischen Microcontrollern und Peripheriegeräten. Das [[Ethersex]]-System kann sowohl als Master als auch als Slave in einem I2C-Bus arbeiten. In der Atmel-Dokumentation wird I2C als TWI (Two Wire Interface) geführt. ==Master Mode== Im Master-Mode kann das Ethersex-System auf angeschlossene I2C-Slaves zugreifen. Unterstützt werden im Moment: * 24cXX EEPROMs (Als Storage Backend für das Virtuelle Dateisystem) * LM75 Temperatursensoren * PCA9531 8 bit LED Dimmer * PCF8574x Port Extension ==Slave Mode== * Kann per I2C auf die [[ECMD]] Schnittstelle zugegriffen werden. * In menuconfig -> Protocols -> ECMD -> I2C aktivieren * [[Beispiel]] Ethersex und ein zweiter AVR ==Anschluss== Die Leitungen SCL (Clock) und SDA (Data) liegen als "Alternate Function" auf I/O Leitungen der Controller. Beim ATmega32 sind dies PC0 (SCL) und PC1 (SDA). ===Etherrape=== Beim [[Etherrape]] ist der I2C-Bus auf einem separaten Steckverbinder herausgeführt. ===Pollin AVR-NET-IO=== Beim Pollin [[AVR-NET-IO]] liegen die Leitungen des Ports C auf J3, dem 25poligen SUB-D Steckverbinder. Dort lassen sich auch Versorgungsspannung und Masse für die angeschlossenen Slaves abgreifen: {|class=wikitable !Pin !Funktion |- |2 |PC0 (SCL) |- |3 |PC1 (SDA) |- |15 |5V |- |18 |GND |} ==Konfiguration== Die Leitungen sind fest vorgegeben, daher muss keine Konfiguration des Pinnings erfolgen. Die Einstellungen für den Master-Mode finden sich unter "I/O support", "I2C Master Support". == ECMD == = I2C = Mittels "i2c detect" werden die gefundenen I2C Adressen aufgelistet i2c detect detected at: 0x20 (32) detected at: 0x48 (72) detected at: 0x60 (96) Mit den allgemeinen I2C-Kommandos können alle I2C-Chips angesprochen werden. Mit dem Befehl i2c wbb 72 81 wird z. B. die Temperatur-Konvertierung auf einem DS1631 gestartet. Geschrieben wird ein Byte mit dem Wert 81 an den Chip mit der Adresse 72. Mit dem Befehl i2c rwd 72 170 wird ein Word von der Adresse 170 des Chips mit der Adresse 72 gelesen. Damit wird die Temperatur des DS1631 ausgelesen. Die Umrechung muß man dann per Hand durchführen. = LM75 = Um den LM75 Temperatursensor auszulesen (Basisadresse 0x48) muss die IC Adresse angegeben werden. In diesem Falle ist das "0" weil die IC Adresse a0 bis a2 auf Masse gesetzt werden. -> binär 000 = 0 lm75 0 21.5 = DS1631 = Ein DS1631 Temperatursensor muß nach dem Einschalten der Stromversorgung erst aktiviert werden. Der erste DS1631 mit der Adresse 0x48 hat im Befehl die Adresse 0. Mit dem folgenden Befehl wird die Temperatur-Konvertierung eingeschaltet: ds1631 convert 0 1 Jetzt kann die Temperatur ausgelesen werden. Die Genauigkeit beträgt immer die vollen 12bits. ds1631 temp 0 22.875 Wahrscheinlich können auch DS1621-Sensoren ausgelesen werden, das wurde aber noch nicht getestet! = PCF8574 = Für die Porterweiterung gilt das Schema "pcf8574x read adresse chip" wobei die adresse 0-7 sein kann, und chip "0" oder "1", je nachdem ob man den pcf8574 oder den pcf8574A benutzt. pcf8574x read 0 0 FFFF Schalten von Ausgängen mit Wert 0xF0 am PCF8574 mit Adresse 5 (Das bedeutet das a0=1 und a2=1 ist, ergo 101) d.h. die ersten 4 Ausgänge werden auf "1" die anderen 4 Ausgänge auf "0" gesetzt. pcf8574x set 5 0 F0 [[Category:Ethersex]] [[Category:StepByStep]] [[Category:I2C]] [[Category:ECMD]] 912a7c1b61e96ffe8d731a9fdb47c0845f169086 480 466 2012-04-07T16:41:16Z Mgue 312 link to i2c slav example fixed wikitext text/x-wiki {{i18n|I2C}} Der I2C-Bus (Inter Integrated Circuit) ist ein einfacher Zweidraht-Bus, der für die Kommunikation zwischen ICs innerhalb eines größeren Systems verwendet wird. Insbesondere bietet er sich an zur Kommunikation zwischen Microcontrollern und Peripheriegeräten. Das [[Ethersex]]-System kann sowohl als Master als auch als Slave in einem I2C-Bus arbeiten. In der Atmel-Dokumentation wird I2C als TWI (Two Wire Interface) geführt. ==Master Mode== Im Master-Mode kann das Ethersex-System auf angeschlossene I2C-Slaves zugreifen. Unterstützt werden im Moment: * 24cXX EEPROMs (Als Storage Backend für das Virtuelle Dateisystem) * LM75 Temperatursensoren * PCA9531 8 bit LED Dimmer * PCF8574x Port Extension ==Slave Mode== * Kann per I2C auf die [[ECMD (Deutsch) | ECMD ]] Schnittstelle zugegriffen werden. * In menuconfig -> Protocols -> ECMD -> I2C aktivieren [[I2C/Slave Example (Deutsch) | Beispielimplementierung]] mit Ethersex (Slave) und einem zweiten AVR (Master). ==Anschluss== Die Leitungen SCL (Clock) und SDA (Data) liegen als "Alternate Function" auf I/O Leitungen der Controller. Beim ATmega32 sind dies PC0 (SCL) und PC1 (SDA). ===Etherrape=== Beim [[Etherrape]] ist der I2C-Bus auf einem separaten Steckverbinder herausgeführt. ===Pollin AVR-NET-IO=== Beim Pollin [[AVR-NET-IO]] liegen die Leitungen des Ports C auf J3, dem 25poligen SUB-D Steckverbinder. Dort lassen sich auch Versorgungsspannung und Masse für die angeschlossenen Slaves abgreifen: {|class=wikitable !Pin !Funktion |- |2 |PC0 (SCL) |- |3 |PC1 (SDA) |- |15 |5V |- |18 |GND |} ==Konfiguration== Die Leitungen sind fest vorgegeben, daher muss keine Konfiguration des Pinnings erfolgen. Die Einstellungen für den Master-Mode finden sich unter "I/O support", "I2C Master Support". == ECMD == = I2C = Mittels "i2c detect" werden die gefundenen I2C Adressen aufgelistet i2c detect detected at: 0x20 (32) detected at: 0x48 (72) detected at: 0x60 (96) Mit den allgemeinen I2C-Kommandos können alle I2C-Chips angesprochen werden. Mit dem Befehl i2c wbb 72 81 wird z. B. die Temperatur-Konvertierung auf einem DS1631 gestartet. Geschrieben wird ein Byte mit dem Wert 81 an den Chip mit der Adresse 72. Mit dem Befehl i2c rwd 72 170 wird ein Word von der Adresse 170 des Chips mit der Adresse 72 gelesen. Damit wird die Temperatur des DS1631 ausgelesen. Die Umrechung muß man dann per Hand durchführen. = LM75 = Um den LM75 Temperatursensor auszulesen (Basisadresse 0x48) muss die IC Adresse angegeben werden. In diesem Falle ist das "0" weil die IC Adresse a0 bis a2 auf Masse gesetzt werden. -> binär 000 = 0 lm75 0 21.5 = DS1631 = Ein DS1631 Temperatursensor muß nach dem Einschalten der Stromversorgung erst aktiviert werden. Der erste DS1631 mit der Adresse 0x48 hat im Befehl die Adresse 0. Mit dem folgenden Befehl wird die Temperatur-Konvertierung eingeschaltet: ds1631 convert 0 1 Jetzt kann die Temperatur ausgelesen werden. Die Genauigkeit beträgt immer die vollen 12bits. ds1631 temp 0 22.875 Wahrscheinlich können auch DS1621-Sensoren ausgelesen werden, das wurde aber noch nicht getestet! = PCF8574 = Für die Porterweiterung gilt das Schema "pcf8574x read adresse chip" wobei die adresse 0-7 sein kann, und chip "0" oder "1", je nachdem ob man den pcf8574 oder den pcf8574A benutzt. pcf8574x read 0 0 FFFF Schalten von Ausgängen mit Wert 0xF0 am PCF8574 mit Adresse 5 (Das bedeutet das a0=1 und a2=1 ist, ergo 101) d.h. die ersten 4 Ausgänge werden auf "1" die anderen 4 Ausgänge auf "0" gesetzt. pcf8574x set 5 0 F0 [[Category:Ethersex]] [[Category:StepByStep]] [[Category:I2C]] [[Category:ECMD]] e885e041be1beef128809d4fdac8ad3de1a40cc4 0 185 465 2012-04-07T10:16:45Z Pirndi 462 Created page with "In diesem Beispiel wird gezeigt wie man eine TWI Verbindung zwischen Ethersex und einem zweiten AVR herstellen kann.<br/> == Konfiguration == Zuerst muss Ethersex konfiguriert we…" wikitext text/x-wiki In diesem Beispiel wird gezeigt wie man eine TWI Verbindung zwischen Ethersex und einem zweiten AVR herstellen kann.<br/> == Konfiguration == Zuerst muss Ethersex konfiguriert werden.<br/> Menuconfig -> Protocols -> ECMD -> I2C aktivieren Die Standardadresse ist 8 und die Pufferlänge 50<br/> In diesem Beispiel wird die TWI Lib von [http://jump.to/fleury P. Fleury] verwendet.<br/> == Definition == Zuerst Definieren wir die Adresse für Lesen und Schreiben <source lang=c> #define E6WR (0x8 << 1) | I2C_WRITE #define E6RD (0x8 << 1) | I2C_READ </source> == Befehl senden == Danach benötigen wir einen Puffer für die Ausgelesenen Daten Z.B. <source lang=c> #define E6BUFLEN 50 char E6_data[E6BUFLEN]; </source> Nun senden wir einen ECMD Befehl: <source lang=c> if(!(i2c_start( E6WR ))) //Slave bereit zum schreiben? { i2c_write('i'); i2c_write('p'); i2c_write('\0'); //Befehl muss 0 Terminiert werden! } </source> == Daten Empfangen == Ethersex empfängt nun den Befehl und Wertet ihn automatisch aus. Jetzt müssen wir nur mehr das Ergebnis auslesen: <source lang=c> if(!(i2c_rep_start( E6RD ))) //Slave bereit zum lesen? { for(n=0;n<E6BUFLEN;n++) { E6_data[n] = i2c_readAck(); if(E6_data[n] == '\0') break; if(E6_data [n] == '\n') { E6_data[n+1] = '\0'; break; } } i2c_readNak(); i2c_stop(); } </source> Nun haben wir die IP Adresse im E6_data Array stehen. 886c71d3f93a7eb4b83de9365f094ee3331d3bd0 474 465 2012-04-07T16:34:38Z Mgue 312 format wikitext text/x-wiki {{i18n|I2C/Slave Example}} In diesem Beispiel wird gezeigt wie man eine TWI Verbindung zwischen Ethersex und einem zweiten AVR herstellen kann.<br/> == Konfiguration == Zuerst muss Ethersex konfiguriert werden.<br/> Menuconfig -> Protocols -> ECMD -> I2C aktivieren Die Standardadresse ist 8 und die Pufferlänge 50<br/> In diesem Beispiel wird die TWI Lib von [http://jump.to/fleury P. Fleury] verwendet.<br/> == Definition == Zuerst Definieren wir die Adresse für Lesen und Schreiben <source lang=c> #define E6WR (0x8 << 1) | I2C_WRITE #define E6RD (0x8 << 1) | I2C_READ </source> == Befehl senden == Danach benötigen wir einen Puffer für die Ausgelesenen Daten Z.B. <source lang=c> #define E6BUFLEN 50 char E6_data[E6BUFLEN]; </source> Nun senden wir einen ECMD Befehl: <source lang=c> if(!(i2c_start( E6WR ))) //Slave bereit zum schreiben? { i2c_write('i'); i2c_write('p'); i2c_write('\0'); //Befehl muss 0 Terminiert werden! } </source> == Daten Empfangen == Ethersex empfängt nun den Befehl und Wertet ihn automatisch aus. Jetzt müssen wir nur mehr das Ergebnis auslesen: <source lang=c> if(!(i2c_rep_start( E6RD ))) //Slave bereit zum lesen? { for(n=0;n<E6BUFLEN;n++) { E6_data[n] = i2c_readAck(); if(E6_data[n] == '\0') break; if(E6_data [n] == '\n') { E6_data[n+1] = '\0'; break; } } i2c_readNak(); i2c_stop(); } </source> Nun haben wir die IP Adresse im E6_data Array stehen. e3d083481fd53298155e13574284c98d142aa248 475 474 2012-04-07T16:34:58Z Mgue 312 moved [[Beispiel]] to [[I2C/Slave Example]]:&#32;Beispiel is a bit too general wikitext text/x-wiki {{i18n|I2C/Slave Example}} In diesem Beispiel wird gezeigt wie man eine TWI Verbindung zwischen Ethersex und einem zweiten AVR herstellen kann.<br/> == Konfiguration == Zuerst muss Ethersex konfiguriert werden.<br/> Menuconfig -> Protocols -> ECMD -> I2C aktivieren Die Standardadresse ist 8 und die Pufferlänge 50<br/> In diesem Beispiel wird die TWI Lib von [http://jump.to/fleury P. Fleury] verwendet.<br/> == Definition == Zuerst Definieren wir die Adresse für Lesen und Schreiben <source lang=c> #define E6WR (0x8 << 1) | I2C_WRITE #define E6RD (0x8 << 1) | I2C_READ </source> == Befehl senden == Danach benötigen wir einen Puffer für die Ausgelesenen Daten Z.B. <source lang=c> #define E6BUFLEN 50 char E6_data[E6BUFLEN]; </source> Nun senden wir einen ECMD Befehl: <source lang=c> if(!(i2c_start( E6WR ))) //Slave bereit zum schreiben? { i2c_write('i'); i2c_write('p'); i2c_write('\0'); //Befehl muss 0 Terminiert werden! } </source> == Daten Empfangen == Ethersex empfängt nun den Befehl und Wertet ihn automatisch aus. Jetzt müssen wir nur mehr das Ergebnis auslesen: <source lang=c> if(!(i2c_rep_start( E6RD ))) //Slave bereit zum lesen? { for(n=0;n<E6BUFLEN;n++) { E6_data[n] = i2c_readAck(); if(E6_data[n] == '\0') break; if(E6_data [n] == '\n') { E6_data[n+1] = '\0'; break; } } i2c_readNak(); i2c_stop(); } </source> Nun haben wir die IP Adresse im E6_data Array stehen. e3d083481fd53298155e13574284c98d142aa248 477 475 2012-04-07T16:36:45Z Mgue 312 moved [[I2C/Slave Example]] to [[I2C/Slave Example (Deutsch)]]:&#32;german version wikitext text/x-wiki {{i18n|I2C/Slave Example}} In diesem Beispiel wird gezeigt wie man eine TWI Verbindung zwischen Ethersex und einem zweiten AVR herstellen kann.<br/> == Konfiguration == Zuerst muss Ethersex konfiguriert werden.<br/> Menuconfig -> Protocols -> ECMD -> I2C aktivieren Die Standardadresse ist 8 und die Pufferlänge 50<br/> In diesem Beispiel wird die TWI Lib von [http://jump.to/fleury P. Fleury] verwendet.<br/> == Definition == Zuerst Definieren wir die Adresse für Lesen und Schreiben <source lang=c> #define E6WR (0x8 << 1) | I2C_WRITE #define E6RD (0x8 << 1) | I2C_READ </source> == Befehl senden == Danach benötigen wir einen Puffer für die Ausgelesenen Daten Z.B. <source lang=c> #define E6BUFLEN 50 char E6_data[E6BUFLEN]; </source> Nun senden wir einen ECMD Befehl: <source lang=c> if(!(i2c_start( E6WR ))) //Slave bereit zum schreiben? { i2c_write('i'); i2c_write('p'); i2c_write('\0'); //Befehl muss 0 Terminiert werden! } </source> == Daten Empfangen == Ethersex empfängt nun den Befehl und Wertet ihn automatisch aus. Jetzt müssen wir nur mehr das Ergebnis auslesen: <source lang=c> if(!(i2c_rep_start( E6RD ))) //Slave bereit zum lesen? { for(n=0;n<E6BUFLEN;n++) { E6_data[n] = i2c_readAck(); if(E6_data[n] == '\0') break; if(E6_data [n] == '\n') { E6_data[n+1] = '\0'; break; } } i2c_readNak(); i2c_stop(); } </source> Nun haben wir die IP Adresse im E6_data Array stehen. e3d083481fd53298155e13574284c98d142aa248 0 187 476 2012-04-07T16:34:58Z Mgue 312 moved [[Beispiel]] to [[I2C/Slave Example]]:&#32;Beispiel is a bit too general wikitext text/x-wiki #REDIRECT [[I2C/Slave Example]] c41b3720ef4fbd02b4ecaf11c41ca5b1f5f3f192 0 188 478 2012-04-07T16:36:45Z Mgue 312 moved [[I2C/Slave Example]] to [[I2C/Slave Example (Deutsch)]]:&#32;german version wikitext text/x-wiki #REDIRECT [[I2C/Slave Example (Deutsch)]] ae87d8335671b45108f763ed0902500ec136537d 479 478 2012-04-07T16:38:50Z Mgue 312 header wikitext text/x-wiki {{i18n|I2C/Slave Example}} 6e5ce392cf0d9722f01f541d966cf73ce90087ac 0 178 482 481 2012-04-08T07:55:58Z Sittner 461 /* Mark job as anacron job via ecmd */ wikitext text/x-wiki {{i18n|Cron}} {{Module |NAME=Cron daemon |MENUCONFIG={{Applications}}->Cron daemon |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]], [[Clock]] |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/services/cron https://github.com/ethersex/ethersex/tree/master/services/cron] }} Cron daemon manage cron jobs. This rules define repeated or unique events that call certain commands. Cron jobs are implemented in two flavors: a static list that is defined at compile time and not changeable at runtime, and a dynamic approach, which loads the joblist to the RAM at statup. Jobs can be added and removed at runtime. == Preconditions == Both approaches have in common that you need to define a function that is called from the con daemon at a appropriate time. The function signature, however, varies dependend on the choosen implementation. == Menuconfig == The module needs the current time to function properly. So you have to select at least one time source. To enable crontabs in ethersex select │ │ Load a Default Configuration ---> │ │ ... │ │ Applications ---> │ │ ... │ │ [*] Cron daemon ---> │ │ [ ] Cron daemon (static jobs) == Static Cron Daemon == The function to be called from the daemon has to have the signature '''void func(void)''' and has to be defined in cron_static/cron_static.c. Furthermore you have to insert a rule of the type ''cron_static_event_t'' to the structure array ''events''. The meaning of the values are minute, hour, day, month, days of week, callback function and a flag if UTC or local time is used (in that order). A value of -1 is a wildcard. The entries are checked every minute, so an entry with all wildcards will be executed every minute. Values less than -1 mean "every x-th minute/hour/etc.". So in case of -4 in the minute field the job will be executed every 4th minute. == Dynamic Cron Daemon == === View jobs via ecmd === Simply execute the ecmd command '''cron list''' in your browser for instance. All jobs will be displayed, two lines for each job. The first line contains the job attributes (position, repeats, ecmd/callback job, use UTC, etc.), the second line shows the timing data (MIN HOUR DAY MONTH DAYOFWEEK) and the ecmd command/address of the callback function to be executed. === Remove jobs via ecmd === '''cron rm N''' removes the Nth job (start counting at 0) from the cron list. Caution! '''cron rm''' without paramater removes ALL jobs without confirmation request! === Add jobs via ecmd === '''cron add MIN HOUR DAY MONTH DAYOFWEEK ECMD''' MIN HOUR DAY MONTH and DAYOFWEEK can be -1 (as wildcard). ECMD: The ecmd command to be executed. After creating the new job it's position in the list will be displayed. === Mark job as persistent via ecmd === '''cron persistent N 1''' mark job N as persistent '''cron persistent N 0''' remove persistent flag '''cron persistent N''' show current state === Write persistent jobs to VFS/EEPROM via ecmd === '''cron save''' all persistent jobs will be stored in VFS/EEPROM. === Mark job for UTC time via ecmd === '''cron utc N 1''' mark job N for UTC time '''cron utc N 0''' remove UTC flag '''cron utc N''' show current state === Mark job as anacron job via ecmd === This flag provides a kind of anacron functionality which is intended for jobs that set specific states. Take the circulation pump of a central heating as example. If the pump has to be switched on at 6.00 and switched off at 9.00 this could be realized by a simple cron job. But if the controller reboots at 7.00 (as the result of a blackout for instance) the pump will not be switched on till 6.00 of the following day. The same counts in case of a time skip by NTP updates. To solve this problem all anacron jobs that falls in the skiped time range will be executed (in case of boot this means from 1.1.1970 till the current time), each job just one time and in correct order (latest execution time counts). To keep the runtime of the decision loop short, the starting point in the past is limited to <current time> - CRON_ANACRON_MAXAGE secs. Default is one day (86400 secs). '''cron anacron N 1''' mark job N as anacron job '''cron anacron N 0''' remove anacron flag '''cron anacron N''' show current state === Define cronjob in source code: callback function === Wer scharf hinsieht, erkennt, dass diese Funktionalität auch durch den statischen Cron Daemon abgedeckt wird. Der statische Dienst verbraucht dabei sogar weniger Ressourcen. Aber, hier die Vorteile des dynamischen Dienstes: * Du musst keinen Quelltext in ein fremdes Modul einfügen (Übersichtlichkeit der cron_static.c nimmt mit jedem weiterem Modul ab) * Du kannst zur Laufzeit den cronjob auch wieder entfernen. * Du kannst Extradaten an die Callback Funktion übergeben Die Funktion, welche der Daemon aufrufen soll, muss folgende Signatur haben '''void func(char* data)''' und sollte ''nicht'' in der cron/cron.c Datei definiert werden, sondern in dem jeweiligen Modul, welche die Cron Funktionalität nutzen will. # Binde in dein Modul die Datei 'cron/cron.h' ein. # Nutze die Callback Variante des Cron-Einfügen Befehls '''cron_jobinsert_callback''' in der Initalisierungsfunktion deines Moduls um beim Start von ethersex cronjobs hinzuzufügen. # Die Funktionsparameter haben die folgende Semantik: * Minute, -1 für ignorieren, -2 für jede 2te Minute etc * Stunde, -1 für ignorieren, -2 für jede 2te Stunde etc * Tag, -1 für ignorieren, -2 für jeden 2te Tag etc * Monat, -1 für ignorieren, -2 für jeden 2te Monat etc * Wochentag, 1 für Sonntag, 2 für Montag, 4 für Dienstag, 8 für Mittwoch, 16 für Donnerstag, 32 für Freitag, 64 für Samstag oder eine Addition daraus * Wiederholen, INFINIT_RUNNING für endlos, 1=einmal etc * Position des Crons in der Cronliste (CRON_APPEND, wenn angehängt werden soll) * Callback Funktion * Größe von Extradaten * Extradaten Beispiel aus der Test Einträge Datei: void test(void* data) { /* tu was */ } // in init cron_jobinsert_callback(-1, -2, -1, -1, -1, INFINIT_RUNNING, CRON_APPEND, test, 0, NULL); Extradaten sind eine ziemlich coole Sache. Stella PWM zum Beispiel speichert darin Lichtkanal und Zielwert. Beim Aktivieren des Cronjobs wird der Zeiger auf diese Extradaten dann an die Callback Funktion mit übergeben und diese stehen direkt zur Verfügung. Bitte beachte hierbei aber, dass der Pointer auf die Extradaten durch einen Malloc Aufruf gewonnen werden muss, sprich die Speicherstelle für die Extradaten müssen vorher auf dem Heap allokiert werden. (Beispiel: '''char* extra = malloc(2);''' für 2 Bytes auf dem Heap) Du musst und solltest dich nicht um die Freigabe des allokierten Speichers kümmern. Dies erledigt der Cron daemon bereits. === Define cronjob in source code: ecmd command === Der statische cron daemon bot die Möglichkeit eine Funktion zu gegebenem Zeitpunkt aufzurufen. Wenn du jedoch den dynamischen Dienst nutzt, kannst du auch ecmd Befehle zeitabhängig aufrufen lassen (z.B. Pins setzen, Stella PWM kontrollieren, ethersex reseten etc). Die Funktion die du in dein Modul hierfür einbauen musst, lautet folgendermaßen: cron_jobinsert_ecmd(-1, -2, -1, -1, 127, INFINIT_RUNNING, CRON_APPEND, "ECMD"); 0dc2825f7aec9849e850383c48718b59582a3efb 483 482 2012-04-08T07:59:49Z Sittner 461 /* Define cronjob in source code: callback function */ wikitext text/x-wiki {{i18n|Cron}} {{Module |NAME=Cron daemon |MENUCONFIG={{Applications}}->Cron daemon |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]], [[Clock]] |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/services/cron https://github.com/ethersex/ethersex/tree/master/services/cron] }} Cron daemon manage cron jobs. This rules define repeated or unique events that call certain commands. Cron jobs are implemented in two flavors: a static list that is defined at compile time and not changeable at runtime, and a dynamic approach, which loads the joblist to the RAM at statup. Jobs can be added and removed at runtime. == Preconditions == Both approaches have in common that you need to define a function that is called from the con daemon at a appropriate time. The function signature, however, varies dependend on the choosen implementation. == Menuconfig == The module needs the current time to function properly. So you have to select at least one time source. To enable crontabs in ethersex select │ │ Load a Default Configuration ---> │ │ ... │ │ Applications ---> │ │ ... │ │ [*] Cron daemon ---> │ │ [ ] Cron daemon (static jobs) == Static Cron Daemon == The function to be called from the daemon has to have the signature '''void func(void)''' and has to be defined in cron_static/cron_static.c. Furthermore you have to insert a rule of the type ''cron_static_event_t'' to the structure array ''events''. The meaning of the values are minute, hour, day, month, days of week, callback function and a flag if UTC or local time is used (in that order). A value of -1 is a wildcard. The entries are checked every minute, so an entry with all wildcards will be executed every minute. Values less than -1 mean "every x-th minute/hour/etc.". So in case of -4 in the minute field the job will be executed every 4th minute. == Dynamic Cron Daemon == === View jobs via ecmd === Simply execute the ecmd command '''cron list''' in your browser for instance. All jobs will be displayed, two lines for each job. The first line contains the job attributes (position, repeats, ecmd/callback job, use UTC, etc.), the second line shows the timing data (MIN HOUR DAY MONTH DAYOFWEEK) and the ecmd command/address of the callback function to be executed. === Remove jobs via ecmd === '''cron rm N''' removes the Nth job (start counting at 0) from the cron list. Caution! '''cron rm''' without paramater removes ALL jobs without confirmation request! === Add jobs via ecmd === '''cron add MIN HOUR DAY MONTH DAYOFWEEK ECMD''' MIN HOUR DAY MONTH and DAYOFWEEK can be -1 (as wildcard). ECMD: The ecmd command to be executed. After creating the new job it's position in the list will be displayed. === Mark job as persistent via ecmd === '''cron persistent N 1''' mark job N as persistent '''cron persistent N 0''' remove persistent flag '''cron persistent N''' show current state === Write persistent jobs to VFS/EEPROM via ecmd === '''cron save''' all persistent jobs will be stored in VFS/EEPROM. === Mark job for UTC time via ecmd === '''cron utc N 1''' mark job N for UTC time '''cron utc N 0''' remove UTC flag '''cron utc N''' show current state === Mark job as anacron job via ecmd === This flag provides a kind of anacron functionality which is intended for jobs that set specific states. Take the circulation pump of a central heating as example. If the pump has to be switched on at 6.00 and switched off at 9.00 this could be realized by a simple cron job. But if the controller reboots at 7.00 (as the result of a blackout for instance) the pump will not be switched on till 6.00 of the following day. The same counts in case of a time skip by NTP updates. To solve this problem all anacron jobs that falls in the skiped time range will be executed (in case of boot this means from 1.1.1970 till the current time), each job just one time and in correct order (latest execution time counts). To keep the runtime of the decision loop short, the starting point in the past is limited to <current time> - CRON_ANACRON_MAXAGE secs. Default is one day (86400 secs). '''cron anacron N 1''' mark job N as anacron job '''cron anacron N 0''' remove anacron flag '''cron anacron N''' show current state === Define cronjob in source code: callback function === As you may have noticed this functionality is also be covered by the static cron daemon, wich even consumes less resources. But there are some advantages: * No need to add code to a foreign module (clarity of cron_static.c suffers with every additional module) * You can remove the cronjob at runtime * You can pass extra data to the callback funtion The function to be called by the daemon has to have the signature '''void func(char* data)''' and should ''not'' be defined in cron/cron.c but in the particular module that uses the cron functionality. # Include 'cron/cron.h' in your module # Call the function '''cron_jobinsert_callback''' from your initialization function to insert cronjobs on startup of ethersex. # The semantic of the function parameters is: * Minute, -1 as wildcard, -2 means every 2nd minute, etc. * Hour, -1 as wildcard, -2 means every 2nd hour, etc. * Day, -1 as wildcard, -2 means every 2nd day, etc. * Month, -1 as wildcard, -2 means every 2nd month, etc. * Day of week, 1 = Sunday, 2 = Monday, 4 = Tuesday, 8 = Wednesday, 16 = Thursday, 32 = Friday, 64 = Saturday or adding of multiple values * Number of repeats, INFINIT_RUNNING for never ending, 1=once, etc. * Position to add to the cron list (CRON_APPEND = add to end) * Callback function * Size of extra data * Pointer to extra data Example taken from the test entry file: void test(void* data) { /* do something */ } // in init cron_jobinsert_callback(-1, -2, -1, -1, -1, INFINIT_RUNNING, CRON_APPEND, test, 0, NULL); Extra data is cool stuff. Stella PWM for instance uses it to store the chanel no and the target value. If the cronjob is executed, it's extra data is passed to the callback function and can be processed. Please keep in mind that the pointer to extra data has be be the result of a call to malloc, which allocates the memory on the heap. (Example: '''char* extra = malloc(2);''' for 2 bytes on the heap) Don't care about freeing the allocated memory. The cron daemon will do this job. === Define cronjob in source code: ecmd command === Der statische cron daemon bot die Möglichkeit eine Funktion zu gegebenem Zeitpunkt aufzurufen. Wenn du jedoch den dynamischen Dienst nutzt, kannst du auch ecmd Befehle zeitabhängig aufrufen lassen (z.B. Pins setzen, Stella PWM kontrollieren, ethersex reseten etc). Die Funktion die du in dein Modul hierfür einbauen musst, lautet folgendermaßen: cron_jobinsert_ecmd(-1, -2, -1, -1, 127, INFINIT_RUNNING, CRON_APPEND, "ECMD"); 0e907f6708e31aa49b5ea81f220e7d744d8db728 484 483 2012-04-08T08:12:50Z Sittner 461 /* Define cronjob in source code: callback function */ wikitext text/x-wiki {{i18n|Cron}} {{Module |NAME=Cron daemon |MENUCONFIG={{Applications}}->Cron daemon |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]], [[Clock]] |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/services/cron https://github.com/ethersex/ethersex/tree/master/services/cron] }} Cron daemon manage cron jobs. This rules define repeated or unique events that call certain commands. Cron jobs are implemented in two flavors: a static list that is defined at compile time and not changeable at runtime, and a dynamic approach, which loads the joblist to the RAM at statup. Jobs can be added and removed at runtime. == Preconditions == Both approaches have in common that you need to define a function that is called from the con daemon at a appropriate time. The function signature, however, varies dependend on the choosen implementation. == Menuconfig == The module needs the current time to function properly. So you have to select at least one time source. To enable crontabs in ethersex select │ │ Load a Default Configuration ---> │ │ ... │ │ Applications ---> │ │ ... │ │ [*] Cron daemon ---> │ │ [ ] Cron daemon (static jobs) == Static Cron Daemon == The function to be called from the daemon has to have the signature '''void func(void)''' and has to be defined in cron_static/cron_static.c. Furthermore you have to insert a rule of the type ''cron_static_event_t'' to the structure array ''events''. The meaning of the values are minute, hour, day, month, days of week, callback function and a flag if UTC or local time is used (in that order). A value of -1 is a wildcard. The entries are checked every minute, so an entry with all wildcards will be executed every minute. Values less than -1 mean "every x-th minute/hour/etc.". So in case of -4 in the minute field the job will be executed every 4th minute. == Dynamic Cron Daemon == === View jobs via ecmd === Simply execute the ecmd command '''cron list''' in your browser for instance. All jobs will be displayed, two lines for each job. The first line contains the job attributes (position, repeats, ecmd/callback job, use UTC, etc.), the second line shows the timing data (MIN HOUR DAY MONTH DAYOFWEEK) and the ecmd command/address of the callback function to be executed. === Remove jobs via ecmd === '''cron rm N''' removes the Nth job (start counting at 0) from the cron list. Caution! '''cron rm''' without paramater removes ALL jobs without confirmation request! === Add jobs via ecmd === '''cron add MIN HOUR DAY MONTH DAYOFWEEK ECMD''' MIN HOUR DAY MONTH and DAYOFWEEK can be -1 (as wildcard). ECMD: The ecmd command to be executed. After creating the new job it's position in the list will be displayed. === Mark job as persistent via ecmd === '''cron persistent N 1''' mark job N as persistent '''cron persistent N 0''' remove persistent flag '''cron persistent N''' show current state === Write persistent jobs to VFS/EEPROM via ecmd === '''cron save''' all persistent jobs will be stored in VFS/EEPROM. === Mark job for UTC time via ecmd === '''cron utc N 1''' mark job N for UTC time '''cron utc N 0''' remove UTC flag '''cron utc N''' show current state === Mark job as anacron job via ecmd === This flag provides a kind of anacron functionality which is intended for jobs that set specific states. Take the circulation pump of a central heating as example. If the pump has to be switched on at 6.00 and switched off at 9.00 this could be realized by a simple cron job. But if the controller reboots at 7.00 (as the result of a blackout for instance) the pump will not be switched on till 6.00 of the following day. The same counts in case of a time skip by NTP updates. To solve this problem all anacron jobs that falls in the skiped time range will be executed (in case of boot this means from 1.1.1970 till the current time), each job just one time and in correct order (latest execution time counts). To keep the runtime of the decision loop short, the starting point in the past is limited to <current time> - CRON_ANACRON_MAXAGE secs. Default is one day (86400 secs). '''cron anacron N 1''' mark job N as anacron job '''cron anacron N 0''' remove anacron flag '''cron anacron N''' show current state === Define cronjob in source code: callback function === As you may have noticed this functionality is also be covered by the static cron daemon, wich even consumes less resources. But there are some advantages: * No need to add code to a foreign module (clarity of cron_static.c suffers with every additional module) * You can remove the cronjob at runtime * You can pass extra data to the callback funtion The function to be called by the daemon has to have the signature '''void func(char* data)''' and should ''not'' be defined in cron/cron.c but in the particular module that uses the cron functionality. # Include 'cron/cron.h' in your module # Call the function '''cron_jobinsert_callback''' from your initialization function to insert cronjobs on startup of ethersex. # The semantic of the function parameters is: * Minute, -1 as wildcard, -2 means every 2nd minute, etc. * Hour, -1 as wildcard, -2 means every 2nd hour, etc. * Day, -1 as wildcard, -2 means every 2nd day, etc. * Month, -1 as wildcard, -2 means every 2nd month, etc. * Day of week, 1 = Sunday, 2 = Monday, 4 = Tuesday, 8 = Wednesday, 16 = Thursday, 32 = Friday, 64 = Saturday or adding of multiple values * Number of repeats, INFINIT_RUNNING for never ending, 1=once, etc. * Position to add to the cron list (CRON_APPEND = add to end) * Callback function * Size of extra data * Pointer to extra data Example taken from the test entry file: void test(void* data) { /* do something */ } // in init cron_jobinsert_callback(-1, -2, -1, -1, -1, INFINIT_RUNNING, CRON_APPEND, test, 0, NULL); Extra data is cool stuff. Stella PWM for instance uses it to store the chanel no and the target value. If the cronjob is executed, it's extra data is passed to the callback function and can be processed. Please keep in mind that the pointer to extra data has to be the result of a call to malloc, which allocates the memory on the heap. (Example: '''char* extra = malloc(2);''' for 2 bytes on the heap) Don't care about freeing the allocated memory. The cron daemon will do this job. === Define cronjob in source code: ecmd command === Der statische cron daemon bot die Möglichkeit eine Funktion zu gegebenem Zeitpunkt aufzurufen. Wenn du jedoch den dynamischen Dienst nutzt, kannst du auch ecmd Befehle zeitabhängig aufrufen lassen (z.B. Pins setzen, Stella PWM kontrollieren, ethersex reseten etc). Die Funktion die du in dein Modul hierfür einbauen musst, lautet folgendermaßen: cron_jobinsert_ecmd(-1, -2, -1, -1, 127, INFINIT_RUNNING, CRON_APPEND, "ECMD"); 683951680af5abedc2d407cfa3fef712946d22c7 485 484 2012-04-08T08:18:45Z Sittner 461 /* Define cronjob in source code: ecmd command */ wikitext text/x-wiki {{i18n|Cron}} {{Module |NAME=Cron daemon |MENUCONFIG={{Applications}}->Cron daemon |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]], [[Clock]] |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/services/cron https://github.com/ethersex/ethersex/tree/master/services/cron] }} Cron daemon manage cron jobs. This rules define repeated or unique events that call certain commands. Cron jobs are implemented in two flavors: a static list that is defined at compile time and not changeable at runtime, and a dynamic approach, which loads the joblist to the RAM at statup. Jobs can be added and removed at runtime. == Preconditions == Both approaches have in common that you need to define a function that is called from the con daemon at a appropriate time. The function signature, however, varies dependend on the choosen implementation. == Menuconfig == The module needs the current time to function properly. So you have to select at least one time source. To enable crontabs in ethersex select │ │ Load a Default Configuration ---> │ │ ... │ │ Applications ---> │ │ ... │ │ [*] Cron daemon ---> │ │ [ ] Cron daemon (static jobs) == Static Cron Daemon == The function to be called from the daemon has to have the signature '''void func(void)''' and has to be defined in cron_static/cron_static.c. Furthermore you have to insert a rule of the type ''cron_static_event_t'' to the structure array ''events''. The meaning of the values are minute, hour, day, month, days of week, callback function and a flag if UTC or local time is used (in that order). A value of -1 is a wildcard. The entries are checked every minute, so an entry with all wildcards will be executed every minute. Values less than -1 mean "every x-th minute/hour/etc.". So in case of -4 in the minute field the job will be executed every 4th minute. == Dynamic Cron Daemon == === View jobs via ecmd === Simply execute the ecmd command '''cron list''' in your browser for instance. All jobs will be displayed, two lines for each job. The first line contains the job attributes (position, repeats, ecmd/callback job, use UTC, etc.), the second line shows the timing data (MIN HOUR DAY MONTH DAYOFWEEK) and the ecmd command/address of the callback function to be executed. === Remove jobs via ecmd === '''cron rm N''' removes the Nth job (start counting at 0) from the cron list. Caution! '''cron rm''' without paramater removes ALL jobs without confirmation request! === Add jobs via ecmd === '''cron add MIN HOUR DAY MONTH DAYOFWEEK ECMD''' MIN HOUR DAY MONTH and DAYOFWEEK can be -1 (as wildcard). ECMD: The ecmd command to be executed. After creating the new job it's position in the list will be displayed. === Mark job as persistent via ecmd === '''cron persistent N 1''' mark job N as persistent '''cron persistent N 0''' remove persistent flag '''cron persistent N''' show current state === Write persistent jobs to VFS/EEPROM via ecmd === '''cron save''' all persistent jobs will be stored in VFS/EEPROM. === Mark job for UTC time via ecmd === '''cron utc N 1''' mark job N for UTC time '''cron utc N 0''' remove UTC flag '''cron utc N''' show current state === Mark job as anacron job via ecmd === This flag provides a kind of anacron functionality which is intended for jobs that set specific states. Take the circulation pump of a central heating as example. If the pump has to be switched on at 6.00 and switched off at 9.00 this could be realized by a simple cron job. But if the controller reboots at 7.00 (as the result of a blackout for instance) the pump will not be switched on till 6.00 of the following day. The same counts in case of a time skip by NTP updates. To solve this problem all anacron jobs that falls in the skiped time range will be executed (in case of boot this means from 1.1.1970 till the current time), each job just one time and in correct order (latest execution time counts). To keep the runtime of the decision loop short, the starting point in the past is limited to <current time> - CRON_ANACRON_MAXAGE secs. Default is one day (86400 secs). '''cron anacron N 1''' mark job N as anacron job '''cron anacron N 0''' remove anacron flag '''cron anacron N''' show current state === Define cronjob in source code: callback function === As you may have noticed this functionality is also be covered by the static cron daemon, wich even consumes less resources. But there are some advantages: * No need to add code to a foreign module (clarity of cron_static.c suffers with every additional module) * You can remove the cronjob at runtime * You can pass extra data to the callback funtion The function to be called by the daemon has to have the signature '''void func(char* data)''' and should ''not'' be defined in cron/cron.c but in the particular module that uses the cron functionality. # Include 'cron/cron.h' in your module # Call the function '''cron_jobinsert_callback''' from your initialization function to insert cronjobs on startup of ethersex. # The semantic of the function parameters is: * Minute, -1 as wildcard, -2 means every 2nd minute, etc. * Hour, -1 as wildcard, -2 means every 2nd hour, etc. * Day, -1 as wildcard, -2 means every 2nd day, etc. * Month, -1 as wildcard, -2 means every 2nd month, etc. * Day of week, 1 = Sunday, 2 = Monday, 4 = Tuesday, 8 = Wednesday, 16 = Thursday, 32 = Friday, 64 = Saturday or adding of multiple values * Number of repeats, INFINIT_RUNNING for never ending, 1=once, etc. * Position to add to the cron list (CRON_APPEND = add to end) * Callback function * Size of extra data * Pointer to extra data Example taken from the test entry file: void test(void* data) { /* do something */ } // in init cron_jobinsert_callback(-1, -2, -1, -1, -1, INFINIT_RUNNING, CRON_APPEND, test, 0, NULL); Extra data is cool stuff. Stella PWM for instance uses it to store the chanel no and the target value. If the cronjob is executed, it's extra data is passed to the callback function and can be processed. Please keep in mind that the pointer to extra data has to be the result of a call to malloc, which allocates the memory on the heap. (Example: '''char* extra = malloc(2);''' for 2 bytes on the heap) Don't care about freeing the allocated memory. The cron daemon will do this job. === Define cronjob in source code: ecmd command === The static cron daemon is limited to use callback functions. With the dynamic cron daemon you are even able to call ecmd commands (set output pins, control Stella PWM, reset ethersex, etc.) Here an example of a function call to insert such a job: cron_jobinsert_ecmd(-1, -2, -1, -1, 127, INFINIT_RUNNING, CRON_APPEND, "ECMD"); b329a80f22365cb6a4e82da83b224aa66f55fbcf 0 189 486 2012-04-14T09:06:03Z Sittner 461 Created page with "{{i18n|Onewire}} {{Module |NAME=Onewire |MENUCONFIG={{I/O}}->Onewire support |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] [[HT…" wikitext text/x-wiki {{i18n|Onewire}} {{Module |NAME=Onewire |MENUCONFIG={{I/O}}->Onewire support |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] [[HTTPD]] (optional) [[SNMP]] (optional) |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} Ethersex kann 1-wire Temperatursensoren mit [[ECMD]] auflisten und abfragen. Es wird eine reine Softwareimplementierung des Protokolls benutzt, was keine weiteren Hardware erfordert, als die Temperatursensoren selbst. = Pinning = In der Standardkonfiguration liegt der Datapin des Buses auf PD6 (kann z.B. in der pinning/hardware/netio.m4 oder pinning/hardware/etherrape.m4 geändert werden). Die Definition der Pins erfolgt mit: <source lang=c> ONEWIRE_PORT_RANGE(PXn, PXm) </source> wobei PXn und PNm Pins auf PORTX sind. Jeder Pin zwischen und einschließlich PXn und PXm bildet einen eingenständigen Onewire Bus. Du kannst bis zu acht Busse auf einem PORT definieren (alle Busse müssen auf dem selben PORT liegen!) == Beispiele == Wenn Du nur einen einzigen Bus benötigst, definiere den Bereich wie folgt: '''PORTD: PIN2''' <source lang=c> ONEWIRE_PORT_RANGE(PD2, PD2) </source> Für drei Busse würde das ganze etwa so aussehen: '''PORTD: PIN2, PIN3, PIN4''' <source lang=c> ONEWIRE_PORT_RANGE(PD2, PD4) </source> = Polling Modus = = Benennung von Sensoren = = Unterstützte Hardware = Folgende 1-wire Hardware wird momentan durch Ethersex unterstützt: * DS1820 (Temperatursensor) * DS18B20 (Temperatursensor) * DS1822 (Temperatursensor) * DS2502 (EEPROM) * DS2450 (4 Kanal ADC) = Onewire Befehle = unter Linux als erstes netcat starten (hierbei natürlich die IP ggf modifizieren): netcat 192.168.0.15 2701 danach am prompt: 1w list Gibt eine Liste mit Hexcodes aller angeschlossenen und erkannten Onewire(tm) Sensoren aus. 1w convert <hexcode> Veranlasst eine Temperaturmessung des addressierten Sensors, oder wenn das Argument <hexcode> weggelassen wird aller angeschlossener Sensoren. 1w get <hexcode> Gibt die gemessene Temperatur eines Sensors aus. = Einbindung in die [[HTTPD]]-Weboberfläche = Unter httpd/embed/ow.ht.m4, bzw httpd/embed/Xow.ht.m4 liegt eine Weboberflaeche, die alle Sensoren erkennt und ihre aktuelle Temperatur regelmässig per Ajax abfragt und anzeigt. Im Falle von Xow.ht.m4 wird sogar Graph der Temperatur mittels SVG gemalt. Um die Dateien einzubinden, muss man einfach bei aktiviertem Onewiresupport den [[Webserver]] und das Datei Inlining aktivieren. Die Dateien können dann unter ow.ht bzw. unter Xow.ht angezeigt werden. [[Bild:onewire-svg.png]] = Anschluss AVR-NET-IO = Für das Pollin [[AVR-NET-IO]] Board können die Sensoren DS18S20+ , normal Betrieb [[Bild:netio-1wire_normal.png]] parasitären Modus [[Bild:netio-1wire.png]] Anmerkung: Wenn man beim Net-IO nicht alle Analogeingänge benötigt, lässt sich der 1-Wire-Bus auch an der Schraubklemme ADC1 ganz gut aufschalten. Vorteil ist, dass man gleich alle passenden Spannungen (GND, +5V) an den beiden nebenliegenden Schraubklemmen hat. Das Pinning muss dann entspechend in der kann in der Datei pinning/hardware/netio.m4 von PD6 auf PA4 geändert werden. Vorteil dieser Konfiguration ist, dass man den DB-25-Verbinder zum Anschluss der Relaisplatine K8IO von Pollin frei hat und den EXT Steckverbinder zum Anschluss eines LCD über ein 4bit-Interface nutzen kann, ohne die Erweiterungsplatine von Pollin zu benötigen. Pinbelegung: [[Bild:ds18s20-par-pinout.jpg]] = Anschluss Etherrape = Die Schaltung je nach parasitärem oder normalem Betriebsmodus kann aus der NetIO Skizze übernommen werden. Data liegt auf PORTD an Pin 7: PORTD +---+ |x x| |x X| <- Pin 7 |x x |x x| |x x| +---+ Direkt neben PORTD befinden sich 2 Pins mit GND und 5V als Beschriftung. GND kann als GND und 5V als Vcc genutzt werden. = Einbindung in [[Control6]] = Die Sensoren können mit '''ONEWIRE_GET''' einfach abgefragt werden. Die Funktion führt automatisch ein ''convert'' aus, es sind also keine zwei Schritte erforderlich wie bei dem Zugriff über [[ECMD]]. Die Rückgabe erfolgt (analog der Funktion '''KTY_GET''') in Centigrad, also Temperatur * 10. Hier vielleicht ein kleines Beispiel, das die Daten per [[SYSLOG]] ausgibt sobald sich die Temperatur um mehr als ein Grad zur letzten Messung verändert hat. <pre> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO div_t res = div(Temperatur,10); SYSLOG("temperature changed %d.%d",res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> = Abfrage per [[SNMP]] = = Beispiele = == sh oder bash == Einfaches SH (Linux Shell) Script von stesie (irc) zum Auslesen von einem Wert (udp support muss enabled sein oder option -u nicht verwenden!) <source lang="bash"> #! /bin/sh SENSORID=10529f7001080016 #ESEXIP=2001:6f8:1209:23:42::17 #IPv6 Adresse ESEXIP=192.168.255.90 #IPv6 #echo 1w convert $SENSORID | nc6 -u $ESEXIP 2701 -q 1 2>/dev/null | grep -qe OK || exit 1 #echo 1w get $SENSORID | nc6 -u $ESEXIP 2701 -q 1 2>/dev/null | sed -e 's/Temperatur: //' #IPv4 echo 1w convert $SENSORID | nc -u $ESEXIP 2701 -q 1 2>/dev/null | grep -qe OK || exit 1 echo 1w get $SENSORID | nc -u $ESEXIP 2701 -q 1 2>/dev/null | sed -e 's/Temperatur: //' </source> bash Script von Tron12 zum Auslesen aller Werte (Achtung Port 2701 ist nicht standard!! Sowie udp support muss enabled sein oder option -u nicht verwenden!) <source lang="bash"> #! /bin/sh # # netcat-openbsd 1.89-3ubuntu2 NETIOIP="-4 192.168.178.249" #für IPv6: #NETIOIP="-6 2001:6f8:1209:23:42::17" NETIOPORT="2702" N_DATE=`echo date | nc -u $NETIOIP $NETIOPORT -q 1 ` N_GET_ID=`echo 1w list | nc -u $NETIOIP $NETIOPORT -q 1 | grep -qe OK || exit 1` echo "Date: $N_DATE" echo "---------------------------------" for i in $N_GET_ID do tmp=`echo 1w convert $i | nc -u $NETIOIP $NETIOPORT -q 1 2>/dev/null | grep -qe OK || exit 1` tmp=`echo 1w get $i | nc -u $NETIOIP $NETIOPORT -q 1 2>/dev/null ` echo "Sensor: $i :: $tmp" done </source> == Perl == Beispiel in Perl das alle Sensoren ermittelt und anschließend die Werte ausgibt. Benötigt wird das Modul NET das kein IPv6 kann <source lang="perl"> #!/usr/bin/perl -w #Auslesen der 1 Wire Sensoren an einem AVR-NET-IO mit ethersex use strict; use Net::Telnet (); my $esexip="192.168.255.90"; my $esexport="2701"; my $esex; my @sensor; my $sensor; my $dummy; my $temp; $esex = Net::Telnet->new || die "kann Ethersex nicht finden";; $esex->open(Host => $esexip, Port => $esexport, Timeout => 2); #Alles Sensor-IDs auslesen und dem Array @sensor zuweisen $esex->print("1w list"); ($sensor) = $esex->waitfor(Timeout => 2, String => "OK"); @sensor=split(/\s+/, $sensor); print "@sensor","\n"; #Kontrollausgabe my $zahler=@sensor; print "Anzahl der Elemente :",$zahler,"\n\n"; #Alles Sensore Temperatur einlesen $esex->print("1w convert"); $esex->waitfor(Timeout => 2, String => "OK"); #Sensor ID inklusive Wert ausgeben foreach (@sensor) { $esex->print("1w get $_"); ($dummy,$temp)=$esex->waitfor(Match =>'/[-]?\d+\.\d+/', Timeout => 5); print "Temperatur vom ID ",$_,": ",$temp," C°","\n"; } </source> == Python == <source lang="python"> #!/usr/bin/python from socket import * def connectEP(): s = socket(AF_INET, SOCK_STREAM) s.settimeout(5) s.connect(("192.168.5.3", 2701)) return s def getTemperature(): s.send("1w list\n") sensors = [] sensors_result = {} # list aller Sensoren while 1: response = s.recv(1024).rstrip("\n") if not response: break if response != "OK": sensors.append(response) else: break # wert konvertieren for sensor in sensors: s.send("1w convert " + sensor + "\n") while 1: response = s.recv(1024).rstrip("\n") if response == "OK": break # wert auslesen s.send("1w get " + sensor + "\n") response = s.recv(1024).rstrip("\n").lstrip() sensors_result[sensor] = response return(sensors_result) s = connectEP() for sensor, value in getTemperature().iteritems(): print sensor + " " + value </source> == PHP == <source lang="php"> <html> <head> <title>ethersex php example</title> </head> <body> <?php define(IP, '192.168.10.9'); // deine ethersex ip adresse define(PORT, 2701); // standard port im image request("1w convert"); $response = request("1w list"); $explode = explode("\n", $response); for ($i=0; $i < count($explode)-2; $i++) { echo "Sensor: " . trim($explode[$i]); echo " -- Wert: " . request("1w get " . $explode[$i]); echo "<br>\n"; } function request($request) { $rs = fsockopen(IP, PORT); if (!$rs) { $response = "Kann Verbindung nicht aufbauen!"; } else { $response =""; $request = "!" . $request . "\r\n"; fputs($rs, $request); while (!feof($rs)) { $response .= fgets($rs, 128); } fclose($rs); } return $response; } ?> </body> </source> [[Category:Ethersex]] [[Category:StepByStep]] [[Category:Onewire]] = Bezugsquellen = * Laut Michael Schultz (k1w1) hat er immer DS1820 auf Lager und kann sie sehr günstig weiterverkaufen. Auch Mindermengen. Mail: ethersex [AT] keyb [DOT] de 4cccf63b3d088b6d3ddfe4eed9d466e624f5a3dd 491 486 2012-04-14T09:12:43Z Sittner 461 wikitext text/x-wiki {{i18n|Onewire}} {{Module |NAME=Onewire |MENUCONFIG={{I/O}}->Onewire support |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] [[HTTPD]] (optional) [[SNMP]] (optional) |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} Ethersex kann 1-wire Temperatursensoren mit [[ECMD]] auflisten und abfragen. Es wird eine reine Softwareimplementierung des Protokolls benutzt, was keine weiteren Hardware erfordert, als die Temperatursensoren selbst. = Pinning = In der Standardkonfiguration liegt der Datapin des Buses auf PD6 (kann z.B. in der pinning/hardware/netio.m4 oder pinning/hardware/etherrape.m4 geändert werden). Die Definition der Pins erfolgt mit: <source lang=c> ONEWIRE_PORT_RANGE(PXn, PXm) </source> wobei PXn und PNm Pins auf PORTX sind. Jeder Pin zwischen und einschließlich PXn und PXm bildet einen eingenständigen Onewire Bus. Du kannst bis zu acht Busse auf einem PORT definieren (alle Busse müssen auf dem selben PORT liegen!) == Beispiele == Wenn Du nur einen einzigen Bus benötigst, definiere den Bereich wie folgt: '''PORTD: PIN2''' <source lang=c> ONEWIRE_PORT_RANGE(PD2, PD2) </source> Für drei Busse würde das ganze etwa so aussehen: '''PORTD: PIN2, PIN3, PIN4''' <source lang=c> ONEWIRE_PORT_RANGE(PD2, PD4) </source> = Polling Modus = = Benennung von Sensoren = = Unterstützte Hardware = Folgende 1-wire Hardware wird momentan durch Ethersex unterstützt: * DS1820 (Temperatursensor) * DS18B20 (Temperatursensor) * DS1822 (Temperatursensor) * DS2502 (EEPROM) * DS2450 (4 Kanal ADC) = Onewire Befehle = unter Linux als erstes netcat starten (hierbei natürlich die IP ggf modifizieren): netcat 192.168.0.15 2701 danach am prompt: 1w list Gibt eine Liste mit Hexcodes aller angeschlossenen und erkannten Onewire(tm) Sensoren aus. 1w convert <hexcode> Veranlasst eine Temperaturmessung des addressierten Sensors, oder wenn das Argument <hexcode> weggelassen wird aller angeschlossener Sensoren. 1w get <hexcode> Gibt die gemessene Temperatur eines Sensors aus. = Einbindung in die [[HTTPD]]-Weboberfläche = Unter httpd/embed/ow.ht.m4, bzw httpd/embed/Xow.ht.m4 liegt eine Weboberflaeche, die alle Sensoren erkennt und ihre aktuelle Temperatur regelmässig per Ajax abfragt und anzeigt. Im Falle von Xow.ht.m4 wird sogar Graph der Temperatur mittels SVG gemalt. Um die Dateien einzubinden, muss man einfach bei aktiviertem Onewiresupport den [[Webserver]] und das Datei Inlining aktivieren. Die Dateien können dann unter ow.ht bzw. unter Xow.ht angezeigt werden. [[File:onewire-svg.png]] = Anschluss AVR-NET-IO = Für das Pollin [[AVR-NET-IO]] Board können die Sensoren DS18S20+ , normal Betrieb [[File:netio-1wire_normal.png]] parasitären Modus [[File:netio-1wire.png]] Anmerkung: Wenn man beim Net-IO nicht alle Analogeingänge benötigt, lässt sich der 1-Wire-Bus auch an der Schraubklemme ADC1 ganz gut aufschalten. Vorteil ist, dass man gleich alle passenden Spannungen (GND, +5V) an den beiden nebenliegenden Schraubklemmen hat. Das Pinning muss dann entspechend in der kann in der Datei pinning/hardware/netio.m4 von PD6 auf PA4 geändert werden. Vorteil dieser Konfiguration ist, dass man den DB-25-Verbinder zum Anschluss der Relaisplatine K8IO von Pollin frei hat und den EXT Steckverbinder zum Anschluss eines LCD über ein 4bit-Interface nutzen kann, ohne die Erweiterungsplatine von Pollin zu benötigen. Pinbelegung: [[File:ds18s20-par-pinout.jpg]] = Anschluss Etherrape = Die Schaltung je nach parasitärem oder normalem Betriebsmodus kann aus der NetIO Skizze übernommen werden. Data liegt auf PORTD an Pin 7: PORTD +---+ |x x| |x X| <- Pin 7 |x x |x x| |x x| +---+ Direkt neben PORTD befinden sich 2 Pins mit GND und 5V als Beschriftung. GND kann als GND und 5V als Vcc genutzt werden. = Einbindung in [[Control6]] = Die Sensoren können mit '''ONEWIRE_GET''' einfach abgefragt werden. Die Funktion führt automatisch ein ''convert'' aus, es sind also keine zwei Schritte erforderlich wie bei dem Zugriff über [[ECMD]]. Die Rückgabe erfolgt (analog der Funktion '''KTY_GET''') in Centigrad, also Temperatur * 10. Hier vielleicht ein kleines Beispiel, das die Daten per [[SYSLOG]] ausgibt sobald sich die Temperatur um mehr als ein Grad zur letzten Messung verändert hat. <pre> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO div_t res = div(Temperatur,10); SYSLOG("temperature changed %d.%d",res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> = Abfrage per [[SNMP]] = = Beispiele = == sh oder bash == Einfaches SH (Linux Shell) Script von stesie (irc) zum Auslesen von einem Wert (udp support muss enabled sein oder option -u nicht verwenden!) <source lang="bash"> #! /bin/sh SENSORID=10529f7001080016 #ESEXIP=2001:6f8:1209:23:42::17 #IPv6 Adresse ESEXIP=192.168.255.90 #IPv6 #echo 1w convert $SENSORID | nc6 -u $ESEXIP 2701 -q 1 2>/dev/null | grep -qe OK || exit 1 #echo 1w get $SENSORID | nc6 -u $ESEXIP 2701 -q 1 2>/dev/null | sed -e 's/Temperatur: //' #IPv4 echo 1w convert $SENSORID | nc -u $ESEXIP 2701 -q 1 2>/dev/null | grep -qe OK || exit 1 echo 1w get $SENSORID | nc -u $ESEXIP 2701 -q 1 2>/dev/null | sed -e 's/Temperatur: //' </source> bash Script von Tron12 zum Auslesen aller Werte (Achtung Port 2701 ist nicht standard!! Sowie udp support muss enabled sein oder option -u nicht verwenden!) <source lang="bash"> #! /bin/sh # # netcat-openbsd 1.89-3ubuntu2 NETIOIP="-4 192.168.178.249" #für IPv6: #NETIOIP="-6 2001:6f8:1209:23:42::17" NETIOPORT="2702" N_DATE=`echo date | nc -u $NETIOIP $NETIOPORT -q 1 ` N_GET_ID=`echo 1w list | nc -u $NETIOIP $NETIOPORT -q 1 | grep -qe OK || exit 1` echo "Date: $N_DATE" echo "---------------------------------" for i in $N_GET_ID do tmp=`echo 1w convert $i | nc -u $NETIOIP $NETIOPORT -q 1 2>/dev/null | grep -qe OK || exit 1` tmp=`echo 1w get $i | nc -u $NETIOIP $NETIOPORT -q 1 2>/dev/null ` echo "Sensor: $i :: $tmp" done </source> == Perl == Beispiel in Perl das alle Sensoren ermittelt und anschließend die Werte ausgibt. Benötigt wird das Modul NET das kein IPv6 kann <source lang="perl"> #!/usr/bin/perl -w #Auslesen der 1 Wire Sensoren an einem AVR-NET-IO mit ethersex use strict; use Net::Telnet (); my $esexip="192.168.255.90"; my $esexport="2701"; my $esex; my @sensor; my $sensor; my $dummy; my $temp; $esex = Net::Telnet->new || die "kann Ethersex nicht finden";; $esex->open(Host => $esexip, Port => $esexport, Timeout => 2); #Alles Sensor-IDs auslesen und dem Array @sensor zuweisen $esex->print("1w list"); ($sensor) = $esex->waitfor(Timeout => 2, String => "OK"); @sensor=split(/\s+/, $sensor); print "@sensor","\n"; #Kontrollausgabe my $zahler=@sensor; print "Anzahl der Elemente :",$zahler,"\n\n"; #Alles Sensore Temperatur einlesen $esex->print("1w convert"); $esex->waitfor(Timeout => 2, String => "OK"); #Sensor ID inklusive Wert ausgeben foreach (@sensor) { $esex->print("1w get $_"); ($dummy,$temp)=$esex->waitfor(Match =>'/[-]?\d+\.\d+/', Timeout => 5); print "Temperatur vom ID ",$_,": ",$temp," C°","\n"; } </source> == Python == <source lang="python"> #!/usr/bin/python from socket import * def connectEP(): s = socket(AF_INET, SOCK_STREAM) s.settimeout(5) s.connect(("192.168.5.3", 2701)) return s def getTemperature(): s.send("1w list\n") sensors = [] sensors_result = {} # list aller Sensoren while 1: response = s.recv(1024).rstrip("\n") if not response: break if response != "OK": sensors.append(response) else: break # wert konvertieren for sensor in sensors: s.send("1w convert " + sensor + "\n") while 1: response = s.recv(1024).rstrip("\n") if response == "OK": break # wert auslesen s.send("1w get " + sensor + "\n") response = s.recv(1024).rstrip("\n").lstrip() sensors_result[sensor] = response return(sensors_result) s = connectEP() for sensor, value in getTemperature().iteritems(): print sensor + " " + value </source> == PHP == <source lang="php"> <html> <head> <title>ethersex php example</title> </head> <body> <?php define(IP, '192.168.10.9'); // deine ethersex ip adresse define(PORT, 2701); // standard port im image request("1w convert"); $response = request("1w list"); $explode = explode("\n", $response); for ($i=0; $i < count($explode)-2; $i++) { echo "Sensor: " . trim($explode[$i]); echo " -- Wert: " . request("1w get " . $explode[$i]); echo "<br>\n"; } function request($request) { $rs = fsockopen(IP, PORT); if (!$rs) { $response = "Kann Verbindung nicht aufbauen!"; } else { $response =""; $request = "!" . $request . "\r\n"; fputs($rs, $request); while (!feof($rs)) { $response .= fgets($rs, 128); } fclose($rs); } return $response; } ?> </body> </source> [[Category:Ethersex]] [[Category:StepByStep]] [[Category:Onewire]] = Bezugsquellen = * Laut Michael Schultz (k1w1) hat er immer DS1820 auf Lager und kann sie sehr günstig weiterverkaufen. Auch Mindermengen. Mail: ethersex [AT] keyb [DOT] de 5fefbaf47d4a0d08c0370df56f2b443853ce02f4 492 491 2012-04-14T09:24:27Z Sittner 461 wikitext text/x-wiki {{i18n|Onewire}} {{Module |NAME=Onewire |MENUCONFIG={{I/O}}->Onewire support |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] [[HTTPD]] (optional) [[SNMP]] (optional) |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} Ethersex kann 1-wire Temperatursensoren mit [[ECMD]] auflisten und abfragen. Es wird eine reine Softwareimplementierung des Protokolls benutzt, was keine weiteren Hardware erfordert, als die Temperatursensoren selbst. = Pinning = In der Standardkonfiguration liegt der Datapin des Buses auf PD6 (kann z.B. in der pinning/hardware/netio.m4 oder pinning/hardware/etherrape.m4 geändert werden). Die Definition der Pins erfolgt mit: <source lang=c> ONEWIRE_PORT_RANGE(PXn, PXm) </source> wobei PXn und PNm Pins auf PORTX sind. Jeder Pin zwischen und einschließlich PXn und PXm bildet einen eingenständigen Onewire Bus. Du kannst bis zu acht Busse auf einem PORT definieren (alle Busse müssen auf dem selben PORT liegen!) == Beispiele == Wenn Du nur einen einzigen Bus benötigst, definiere den Bereich wie folgt: '''PORTD: PIN2''' <source lang=c> ONEWIRE_PORT_RANGE(PD2, PD2) </source> Für drei Busse würde das ganze etwa so aussehen: '''PORTD: PIN2, PIN3, PIN4''' <source lang=c> ONEWIRE_PORT_RANGE(PD2, PD4) </source> = Polling Modus = = Benennung von Sensoren = = Unterstützte Hardware = Folgende 1-wire Hardware wird momentan durch Ethersex unterstützt: * DS1820 (Temperatursensor) * DS18B20 (Temperatursensor) * DS1822 (Temperatursensor) * DS2502 (EEPROM) * DS2450 (4 Kanal ADC) = Onewire Befehle = unter Linux als erstes netcat starten (hierbei natürlich die IP ggf modifizieren): netcat 192.168.0.15 2701 danach am prompt: 1w list Gibt eine Liste mit Hexcodes aller angeschlossenen und erkannten Onewire(tm) Sensoren aus. Bei aktiviertem Naming-Support wird (per TAB getrennt) zusätzlich der Name ausgegeben. Außerdem kann mit '''ECMD 1w list with values (ONEWIRE_ECMD_LIST_VALUE_SUPPORT)''' der aktuelle Temperaturwert mit ausgegeben werden. Dies erspart zusätzliche '''1w get''' Aufrufe, setzt allerding Polling-Support vorraus. 1w convert <hexcode> Veranlasst eine Temperaturmessung des addressierten Sensors, oder wenn das Argument <hexcode> weggelassen wird aller angeschlossener Sensoren. 1w get <hexcode> Gibt die gemessene Temperatur eines Sensors aus. = Einbindung in die [[HTTPD]]-Weboberfläche = Unter httpd/embed/ow.ht.m4, bzw httpd/embed/Xow.ht.m4 liegt eine Weboberflaeche, die alle Sensoren erkennt und ihre aktuelle Temperatur regelmässig per Ajax abfragt und anzeigt. Im Falle von Xow.ht.m4 wird sogar Graph der Temperatur mittels SVG gemalt. Um die Dateien einzubinden, muss man einfach bei aktiviertem Onewiresupport den Webserver und das Datei Inlining aktivieren. Die Dateien können dann unter ow.ht bzw. unter Xow.ht angezeigt werden. Das Beispiel zeigt die SVG-Version mit Naming-Support: [[File:onewire-svg.png]] = Anschluss AVR-NET-IO = Für das Pollin AVR-NET-IO Board können die Sensoren DS18S20+ , normal Betrieb [[File:netio-1wire_normal.png]] parasitären Modus [[File:netio-1wire.png]] Anmerkung: Wenn man beim Net-IO nicht alle Analogeingänge benötigt, lässt sich der 1-Wire-Bus auch an der Schraubklemme ADC1 ganz gut aufschalten. Vorteil ist, dass man gleich alle passenden Spannungen (GND, +5V) an den beiden nebenliegenden Schraubklemmen hat. Das Pinning muss dann entspechend in der kann in der Datei pinning/hardware/netio.m4 von PD6 auf PA4 geändert werden. Vorteil dieser Konfiguration ist, dass man den DB-25-Verbinder zum Anschluss der Relaisplatine K8IO von Pollin frei hat und den EXT Steckverbinder zum Anschluss eines LCD über ein 4bit-Interface nutzen kann, ohne die Erweiterungsplatine von Pollin zu benötigen. Pinbelegung: [[File:ds18s20-par-pinout.jpg]] = Anschluss Etherrape = Die Schaltung je nach parasitärem oder normalem Betriebsmodus kann aus der NetIO Skizze übernommen werden. Data liegt auf PORTD an Pin 7: PORTD +---+ |x x| |x X| <- Pin 7 |x x |x x| |x x| +---+ Direkt neben PORTD befinden sich 2 Pins mit GND und 5V als Beschriftung. GND kann als GND und 5V als Vcc genutzt werden. = Einbindung in [[Control6]] = Die Sensoren können mit '''ONEWIRE_GET''' einfach abgefragt werden. Die Funktion führt automatisch ein ''convert'' aus, es sind also keine zwei Schritte erforderlich wie bei dem Zugriff über [[ECMD]]. Die Rückgabe erfolgt (analog der Funktion '''KTY_GET''') in Centigrad, also Temperatur * 10. Hier vielleicht ein kleines Beispiel, das die Daten per [[SYSLOG]] ausgibt sobald sich die Temperatur um mehr als ein Grad zur letzten Messung verändert hat. <pre> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO div_t res = div(Temperatur,10); SYSLOG("temperature changed %d.%d",res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> = Abfrage per [[SNMP]] = = Beispiele = == sh oder bash == Einfaches SH (Linux Shell) Script von stesie (irc) zum Auslesen von einem Wert (udp support muss enabled sein oder option -u nicht verwenden!) <source lang="bash"> #! /bin/sh SENSORID=10529f7001080016 #ESEXIP=2001:6f8:1209:23:42::17 #IPv6 Adresse ESEXIP=192.168.255.90 #IPv6 #echo 1w convert $SENSORID | nc6 -u $ESEXIP 2701 -q 1 2>/dev/null | grep -qe OK || exit 1 #echo 1w get $SENSORID | nc6 -u $ESEXIP 2701 -q 1 2>/dev/null | sed -e 's/Temperatur: //' #IPv4 echo 1w convert $SENSORID | nc -u $ESEXIP 2701 -q 1 2>/dev/null | grep -qe OK || exit 1 echo 1w get $SENSORID | nc -u $ESEXIP 2701 -q 1 2>/dev/null | sed -e 's/Temperatur: //' </source> bash Script von Tron12 zum Auslesen aller Werte (Achtung Port 2701 ist nicht standard!! Sowie udp support muss enabled sein oder option -u nicht verwenden!) <source lang="bash"> #! /bin/sh # # netcat-openbsd 1.89-3ubuntu2 NETIOIP="-4 192.168.178.249" #für IPv6: #NETIOIP="-6 2001:6f8:1209:23:42::17" NETIOPORT="2702" N_DATE=`echo date | nc -u $NETIOIP $NETIOPORT -q 1 ` N_GET_ID=`echo 1w list | nc -u $NETIOIP $NETIOPORT -q 1 | grep -qe OK || exit 1` echo "Date: $N_DATE" echo "---------------------------------" for i in $N_GET_ID do tmp=`echo 1w convert $i | nc -u $NETIOIP $NETIOPORT -q 1 2>/dev/null | grep -qe OK || exit 1` tmp=`echo 1w get $i | nc -u $NETIOIP $NETIOPORT -q 1 2>/dev/null ` echo "Sensor: $i :: $tmp" done </source> == Perl == Beispiel in Perl das alle Sensoren ermittelt und anschließend die Werte ausgibt. Benötigt wird das Modul NET das kein IPv6 kann <source lang="perl"> #!/usr/bin/perl -w #Auslesen der 1 Wire Sensoren an einem AVR-NET-IO mit ethersex use strict; use Net::Telnet (); my $esexip="192.168.255.90"; my $esexport="2701"; my $esex; my @sensor; my $sensor; my $dummy; my $temp; $esex = Net::Telnet->new || die "kann Ethersex nicht finden";; $esex->open(Host => $esexip, Port => $esexport, Timeout => 2); #Alles Sensor-IDs auslesen und dem Array @sensor zuweisen $esex->print("1w list"); ($sensor) = $esex->waitfor(Timeout => 2, String => "OK"); @sensor=split(/\s+/, $sensor); print "@sensor","\n"; #Kontrollausgabe my $zahler=@sensor; print "Anzahl der Elemente :",$zahler,"\n\n"; #Alles Sensore Temperatur einlesen $esex->print("1w convert"); $esex->waitfor(Timeout => 2, String => "OK"); #Sensor ID inklusive Wert ausgeben foreach (@sensor) { $esex->print("1w get $_"); ($dummy,$temp)=$esex->waitfor(Match =>'/[-]?\d+\.\d+/', Timeout => 5); print "Temperatur vom ID ",$_,": ",$temp," C°","\n"; } </source> == Python == <source lang="python"> #!/usr/bin/python from socket import * def connectEP(): s = socket(AF_INET, SOCK_STREAM) s.settimeout(5) s.connect(("192.168.5.3", 2701)) return s def getTemperature(): s.send("1w list\n") sensors = [] sensors_result = {} # list aller Sensoren while 1: response = s.recv(1024).rstrip("\n") if not response: break if response != "OK": sensors.append(response) else: break # wert konvertieren for sensor in sensors: s.send("1w convert " + sensor + "\n") while 1: response = s.recv(1024).rstrip("\n") if response == "OK": break # wert auslesen s.send("1w get " + sensor + "\n") response = s.recv(1024).rstrip("\n").lstrip() sensors_result[sensor] = response return(sensors_result) s = connectEP() for sensor, value in getTemperature().iteritems(): print sensor + " " + value </source> == PHP == <source lang="php"> <html> <head> <title>ethersex php example</title> </head> <body> <?php define(IP, '192.168.10.9'); // deine ethersex ip adresse define(PORT, 2701); // standard port im image request("1w convert"); $response = request("1w list"); $explode = explode("\n", $response); for ($i=0; $i < count($explode)-2; $i++) { echo "Sensor: " . trim($explode[$i]); echo " -- Wert: " . request("1w get " . $explode[$i]); echo "<br>\n"; } function request($request) { $rs = fsockopen(IP, PORT); if (!$rs) { $response = "Kann Verbindung nicht aufbauen!"; } else { $response =""; $request = "!" . $request . "\r\n"; fputs($rs, $request); while (!feof($rs)) { $response .= fgets($rs, 128); } fclose($rs); } return $response; } ?> </body> </source> [[Category:Ethersex]] [[Category:StepByStep]] [[Category:Onewire]] = Bezugsquellen = * Laut Michael Schultz (k1w1) hat er immer DS1820 auf Lager und kann sie sehr günstig weiterverkaufen. Auch Mindermengen. Mail: ethersex [AT] keyb [DOT] de 37992416f365756e0b22bae646edf406e8223264 493 492 2012-04-14T09:37:32Z Sittner 461 /* Abfrage per SNMP */ wikitext text/x-wiki {{i18n|Onewire}} {{Module |NAME=Onewire |MENUCONFIG={{I/O}}->Onewire support |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] [[HTTPD]] (optional) [[SNMP]] (optional) |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} Ethersex kann 1-wire Temperatursensoren mit [[ECMD]] auflisten und abfragen. Es wird eine reine Softwareimplementierung des Protokolls benutzt, was keine weiteren Hardware erfordert, als die Temperatursensoren selbst. = Pinning = In der Standardkonfiguration liegt der Datapin des Buses auf PD6 (kann z.B. in der pinning/hardware/netio.m4 oder pinning/hardware/etherrape.m4 geändert werden). Die Definition der Pins erfolgt mit: <source lang=c> ONEWIRE_PORT_RANGE(PXn, PXm) </source> wobei PXn und PNm Pins auf PORTX sind. Jeder Pin zwischen und einschließlich PXn und PXm bildet einen eingenständigen Onewire Bus. Du kannst bis zu acht Busse auf einem PORT definieren (alle Busse müssen auf dem selben PORT liegen!) == Beispiele == Wenn Du nur einen einzigen Bus benötigst, definiere den Bereich wie folgt: '''PORTD: PIN2''' <source lang=c> ONEWIRE_PORT_RANGE(PD2, PD2) </source> Für drei Busse würde das ganze etwa so aussehen: '''PORTD: PIN2, PIN3, PIN4''' <source lang=c> ONEWIRE_PORT_RANGE(PD2, PD4) </source> = Polling Modus = = Benennung von Sensoren = = Unterstützte Hardware = Folgende 1-wire Hardware wird momentan durch Ethersex unterstützt: * DS1820 (Temperatursensor) * DS18B20 (Temperatursensor) * DS1822 (Temperatursensor) * DS2502 (EEPROM) * DS2450 (4 Kanal ADC) = Onewire Befehle = unter Linux als erstes netcat starten (hierbei natürlich die IP ggf modifizieren): netcat 192.168.0.15 2701 danach am prompt: 1w list Gibt eine Liste mit Hexcodes aller angeschlossenen und erkannten Onewire(tm) Sensoren aus. Bei aktiviertem Naming-Support wird (per TAB getrennt) zusätzlich der Name ausgegeben. Außerdem kann mit '''ECMD 1w list with values (ONEWIRE_ECMD_LIST_VALUE_SUPPORT)''' der aktuelle Temperaturwert mit ausgegeben werden. Dies erspart zusätzliche '''1w get''' Aufrufe, setzt allerding Polling-Support vorraus. 1w convert <hexcode> Veranlasst eine Temperaturmessung des addressierten Sensors, oder wenn das Argument <hexcode> weggelassen wird aller angeschlossener Sensoren. 1w get <hexcode> Gibt die gemessene Temperatur eines Sensors aus. = Einbindung in die [[HTTPD]]-Weboberfläche = Unter httpd/embed/ow.ht.m4, bzw httpd/embed/Xow.ht.m4 liegt eine Weboberflaeche, die alle Sensoren erkennt und ihre aktuelle Temperatur regelmässig per Ajax abfragt und anzeigt. Im Falle von Xow.ht.m4 wird sogar Graph der Temperatur mittels SVG gemalt. Um die Dateien einzubinden, muss man einfach bei aktiviertem Onewiresupport den Webserver und das Datei Inlining aktivieren. Die Dateien können dann unter ow.ht bzw. unter Xow.ht angezeigt werden. Das Beispiel zeigt die SVG-Version mit Naming-Support: [[File:onewire-svg.png]] = Anschluss AVR-NET-IO = Für das Pollin AVR-NET-IO Board können die Sensoren DS18S20+ , normal Betrieb [[File:netio-1wire_normal.png]] parasitären Modus [[File:netio-1wire.png]] Anmerkung: Wenn man beim Net-IO nicht alle Analogeingänge benötigt, lässt sich der 1-Wire-Bus auch an der Schraubklemme ADC1 ganz gut aufschalten. Vorteil ist, dass man gleich alle passenden Spannungen (GND, +5V) an den beiden nebenliegenden Schraubklemmen hat. Das Pinning muss dann entspechend in der kann in der Datei pinning/hardware/netio.m4 von PD6 auf PA4 geändert werden. Vorteil dieser Konfiguration ist, dass man den DB-25-Verbinder zum Anschluss der Relaisplatine K8IO von Pollin frei hat und den EXT Steckverbinder zum Anschluss eines LCD über ein 4bit-Interface nutzen kann, ohne die Erweiterungsplatine von Pollin zu benötigen. Pinbelegung: [[File:ds18s20-par-pinout.jpg]] = Anschluss Etherrape = Die Schaltung je nach parasitärem oder normalem Betriebsmodus kann aus der NetIO Skizze übernommen werden. Data liegt auf PORTD an Pin 7: PORTD +---+ |x x| |x X| <- Pin 7 |x x |x x| |x x| +---+ Direkt neben PORTD befinden sich 2 Pins mit GND und 5V als Beschriftung. GND kann als GND und 5V als Vcc genutzt werden. = Einbindung in [[Control6]] = Die Sensoren können mit '''ONEWIRE_GET''' einfach abgefragt werden. Die Funktion führt automatisch ein ''convert'' aus, es sind also keine zwei Schritte erforderlich wie bei dem Zugriff über [[ECMD]]. Die Rückgabe erfolgt (analog der Funktion '''KTY_GET''') in Centigrad, also Temperatur * 10. Hier vielleicht ein kleines Beispiel, das die Daten per [[SYSLOG]] ausgibt sobald sich die Temperatur um mehr als ein Grad zur letzten Messung verändert hat. <pre> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO div_t res = div(Temperatur,10); SYSLOG("temperature changed %d.%d",res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> = Abfrage per [[SNMP]] = Falls Polling-Support aktiviert wurde können die Sensorwerte per SNMP abgefragt werden. Mit Naming-Support stehen auch die Namen per SNMP zur Verfügung und die Index-Nummern sind fix auf die Position in der Namenstabelle festgelegt. Dies ist sehr hilfreich, um bestimmte Sensoren über den SNMP-Index anzusprechen. Es gibt folgende OIDs: * .1.3.6.1.4.1.2021.13.23.3.1.<idx> : ROM-Code des Sensors * .1.3.6.1.4.1.2021.13.23.3.2.<idx> : Sensor-Name (nur mit Naming-Support) * .1.3.6.1.4.1.2021.13.23.3.3.<idx> : Temperaturwert in Centigrad * .1.3.6.1.4.1.2021.13.23.3.4.<idx> : 0 = Sensor nicht vorhanden, 1 = Sensor vorhanden Hier ein Beispiel: <pre> # snmpwalk -Osn -c public -v 1 10.0.0.105 1.3.6.1.4.1.2021.13.23.3 .1.3.6.1.4.1.2021.13.23.3.1.0 = STRING: "1080cff6010800f9" .1.3.6.1.4.1.2021.13.23.3.1.1 = STRING: "10c8cff60108002d" .1.3.6.1.4.1.2021.13.23.3.1.2 = STRING: "1029f6dc0108002f" .1.3.6.1.4.1.2021.13.23.3.1.3 = STRING: "10f2d0f60108001c" .1.3.6.1.4.1.2021.13.23.3.1.4 = STRING: "105a17f70108001d" .1.3.6.1.4.1.2021.13.23.3.1.5 = STRING: "10b8d8f601080098" .1.3.6.1.4.1.2021.13.23.3.1.6 = STRING: "104dedf601080057" .1.3.6.1.4.1.2021.13.23.3.1.7 = STRING: "10011af701080027" .1.3.6.1.4.1.2021.13.23.3.1.8 = STRING: "0000000000000000" .1.3.6.1.4.1.2021.13.23.3.1.9 = STRING: "0000000000000000" .1.3.6.1.4.1.2021.13.23.3.2.0 = STRING: "kessel" .1.3.6.1.4.1.2021.13.23.3.2.1 = STRING: "warmwasser" .1.3.6.1.4.1.2021.13.23.3.2.2 = STRING: "aussen" .1.3.6.1.4.1.2021.13.23.3.2.3 = STRING: "speicher" .1.3.6.1.4.1.2021.13.23.3.2.4 = STRING: "heizung vl" .1.3.6.1.4.1.2021.13.23.3.2.5 = STRING: "heizung rl" .1.3.6.1.4.1.2021.13.23.3.2.6 = STRING: "boiler vl" .1.3.6.1.4.1.2021.13.23.3.2.7 = STRING: "boiler rl" .1.3.6.1.4.1.2021.13.23.3.2.8 = "" .1.3.6.1.4.1.2021.13.23.3.2.9 = "" .1.3.6.1.4.1.2021.13.23.3.3.0 = INTEGER: 334 .1.3.6.1.4.1.2021.13.23.3.3.1 = INTEGER: 467 .1.3.6.1.4.1.2021.13.23.3.3.2 = INTEGER: 127 .1.3.6.1.4.1.2021.13.23.3.3.3 = INTEGER: 185 .1.3.6.1.4.1.2021.13.23.3.3.4 = INTEGER: 318 .1.3.6.1.4.1.2021.13.23.3.3.5 = INTEGER: 269 .1.3.6.1.4.1.2021.13.23.3.3.6 = INTEGER: 366 .1.3.6.1.4.1.2021.13.23.3.3.7 = INTEGER: 291 .1.3.6.1.4.1.2021.13.23.3.3.8 = INTEGER: 0 .1.3.6.1.4.1.2021.13.23.3.3.9 = INTEGER: 0 .1.3.6.1.4.1.2021.13.23.3.4.0 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.1 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.2 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.3 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.4 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.5 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.6 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.7 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.8 = INTEGER: 0 .1.3.6.1.4.1.2021.13.23.3.4.9 = INTEGER: 0 </pre> = Beispiele = == sh oder bash == Einfaches SH (Linux Shell) Script von stesie (irc) zum Auslesen von einem Wert (udp support muss enabled sein oder option -u nicht verwenden!) <source lang="bash"> #! /bin/sh SENSORID=10529f7001080016 #ESEXIP=2001:6f8:1209:23:42::17 #IPv6 Adresse ESEXIP=192.168.255.90 #IPv6 #echo 1w convert $SENSORID | nc6 -u $ESEXIP 2701 -q 1 2>/dev/null | grep -qe OK || exit 1 #echo 1w get $SENSORID | nc6 -u $ESEXIP 2701 -q 1 2>/dev/null | sed -e 's/Temperatur: //' #IPv4 echo 1w convert $SENSORID | nc -u $ESEXIP 2701 -q 1 2>/dev/null | grep -qe OK || exit 1 echo 1w get $SENSORID | nc -u $ESEXIP 2701 -q 1 2>/dev/null | sed -e 's/Temperatur: //' </source> bash Script von Tron12 zum Auslesen aller Werte (Achtung Port 2701 ist nicht standard!! Sowie udp support muss enabled sein oder option -u nicht verwenden!) <source lang="bash"> #! /bin/sh # # netcat-openbsd 1.89-3ubuntu2 NETIOIP="-4 192.168.178.249" #für IPv6: #NETIOIP="-6 2001:6f8:1209:23:42::17" NETIOPORT="2702" N_DATE=`echo date | nc -u $NETIOIP $NETIOPORT -q 1 ` N_GET_ID=`echo 1w list | nc -u $NETIOIP $NETIOPORT -q 1 | grep -qe OK || exit 1` echo "Date: $N_DATE" echo "---------------------------------" for i in $N_GET_ID do tmp=`echo 1w convert $i | nc -u $NETIOIP $NETIOPORT -q 1 2>/dev/null | grep -qe OK || exit 1` tmp=`echo 1w get $i | nc -u $NETIOIP $NETIOPORT -q 1 2>/dev/null ` echo "Sensor: $i :: $tmp" done </source> == Perl == Beispiel in Perl das alle Sensoren ermittelt und anschließend die Werte ausgibt. Benötigt wird das Modul NET das kein IPv6 kann <source lang="perl"> #!/usr/bin/perl -w #Auslesen der 1 Wire Sensoren an einem AVR-NET-IO mit ethersex use strict; use Net::Telnet (); my $esexip="192.168.255.90"; my $esexport="2701"; my $esex; my @sensor; my $sensor; my $dummy; my $temp; $esex = Net::Telnet->new || die "kann Ethersex nicht finden";; $esex->open(Host => $esexip, Port => $esexport, Timeout => 2); #Alles Sensor-IDs auslesen und dem Array @sensor zuweisen $esex->print("1w list"); ($sensor) = $esex->waitfor(Timeout => 2, String => "OK"); @sensor=split(/\s+/, $sensor); print "@sensor","\n"; #Kontrollausgabe my $zahler=@sensor; print "Anzahl der Elemente :",$zahler,"\n\n"; #Alles Sensore Temperatur einlesen $esex->print("1w convert"); $esex->waitfor(Timeout => 2, String => "OK"); #Sensor ID inklusive Wert ausgeben foreach (@sensor) { $esex->print("1w get $_"); ($dummy,$temp)=$esex->waitfor(Match =>'/[-]?\d+\.\d+/', Timeout => 5); print "Temperatur vom ID ",$_,": ",$temp," C°","\n"; } </source> == Python == <source lang="python"> #!/usr/bin/python from socket import * def connectEP(): s = socket(AF_INET, SOCK_STREAM) s.settimeout(5) s.connect(("192.168.5.3", 2701)) return s def getTemperature(): s.send("1w list\n") sensors = [] sensors_result = {} # list aller Sensoren while 1: response = s.recv(1024).rstrip("\n") if not response: break if response != "OK": sensors.append(response) else: break # wert konvertieren for sensor in sensors: s.send("1w convert " + sensor + "\n") while 1: response = s.recv(1024).rstrip("\n") if response == "OK": break # wert auslesen s.send("1w get " + sensor + "\n") response = s.recv(1024).rstrip("\n").lstrip() sensors_result[sensor] = response return(sensors_result) s = connectEP() for sensor, value in getTemperature().iteritems(): print sensor + " " + value </source> == PHP == <source lang="php"> <html> <head> <title>ethersex php example</title> </head> <body> <?php define(IP, '192.168.10.9'); // deine ethersex ip adresse define(PORT, 2701); // standard port im image request("1w convert"); $response = request("1w list"); $explode = explode("\n", $response); for ($i=0; $i < count($explode)-2; $i++) { echo "Sensor: " . trim($explode[$i]); echo " -- Wert: " . request("1w get " . $explode[$i]); echo "<br>\n"; } function request($request) { $rs = fsockopen(IP, PORT); if (!$rs) { $response = "Kann Verbindung nicht aufbauen!"; } else { $response =""; $request = "!" . $request . "\r\n"; fputs($rs, $request); while (!feof($rs)) { $response .= fgets($rs, 128); } fclose($rs); } return $response; } ?> </body> </source> [[Category:Ethersex]] [[Category:StepByStep]] [[Category:Onewire]] = Bezugsquellen = * Laut Michael Schultz (k1w1) hat er immer DS1820 auf Lager und kann sie sehr günstig weiterverkaufen. Auch Mindermengen. Mail: ethersex [AT] keyb [DOT] de 3325e560f72de34f0b1016f65708790660f6f995 494 493 2012-04-14T09:39:54Z Sittner 461 /* Abfrage per SNMP */ wikitext text/x-wiki {{i18n|Onewire}} {{Module |NAME=Onewire |MENUCONFIG={{I/O}}->Onewire support |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] [[HTTPD]] (optional) [[SNMP]] (optional) |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} Ethersex kann 1-wire Temperatursensoren mit [[ECMD]] auflisten und abfragen. Es wird eine reine Softwareimplementierung des Protokolls benutzt, was keine weiteren Hardware erfordert, als die Temperatursensoren selbst. = Pinning = In der Standardkonfiguration liegt der Datapin des Buses auf PD6 (kann z.B. in der pinning/hardware/netio.m4 oder pinning/hardware/etherrape.m4 geändert werden). Die Definition der Pins erfolgt mit: <source lang=c> ONEWIRE_PORT_RANGE(PXn, PXm) </source> wobei PXn und PNm Pins auf PORTX sind. Jeder Pin zwischen und einschließlich PXn und PXm bildet einen eingenständigen Onewire Bus. Du kannst bis zu acht Busse auf einem PORT definieren (alle Busse müssen auf dem selben PORT liegen!) == Beispiele == Wenn Du nur einen einzigen Bus benötigst, definiere den Bereich wie folgt: '''PORTD: PIN2''' <source lang=c> ONEWIRE_PORT_RANGE(PD2, PD2) </source> Für drei Busse würde das ganze etwa so aussehen: '''PORTD: PIN2, PIN3, PIN4''' <source lang=c> ONEWIRE_PORT_RANGE(PD2, PD4) </source> = Polling Modus = = Benennung von Sensoren = = Unterstützte Hardware = Folgende 1-wire Hardware wird momentan durch Ethersex unterstützt: * DS1820 (Temperatursensor) * DS18B20 (Temperatursensor) * DS1822 (Temperatursensor) * DS2502 (EEPROM) * DS2450 (4 Kanal ADC) = Onewire Befehle = unter Linux als erstes netcat starten (hierbei natürlich die IP ggf modifizieren): netcat 192.168.0.15 2701 danach am prompt: 1w list Gibt eine Liste mit Hexcodes aller angeschlossenen und erkannten Onewire(tm) Sensoren aus. Bei aktiviertem Naming-Support wird (per TAB getrennt) zusätzlich der Name ausgegeben. Außerdem kann mit '''ECMD 1w list with values (ONEWIRE_ECMD_LIST_VALUE_SUPPORT)''' der aktuelle Temperaturwert mit ausgegeben werden. Dies erspart zusätzliche '''1w get''' Aufrufe, setzt allerding Polling-Support vorraus. 1w convert <hexcode> Veranlasst eine Temperaturmessung des addressierten Sensors, oder wenn das Argument <hexcode> weggelassen wird aller angeschlossener Sensoren. 1w get <hexcode> Gibt die gemessene Temperatur eines Sensors aus. = Einbindung in die [[HTTPD]]-Weboberfläche = Unter httpd/embed/ow.ht.m4, bzw httpd/embed/Xow.ht.m4 liegt eine Weboberflaeche, die alle Sensoren erkennt und ihre aktuelle Temperatur regelmässig per Ajax abfragt und anzeigt. Im Falle von Xow.ht.m4 wird sogar Graph der Temperatur mittels SVG gemalt. Um die Dateien einzubinden, muss man einfach bei aktiviertem Onewiresupport den Webserver und das Datei Inlining aktivieren. Die Dateien können dann unter ow.ht bzw. unter Xow.ht angezeigt werden. Das Beispiel zeigt die SVG-Version mit Naming-Support: [[File:onewire-svg.png]] = Anschluss AVR-NET-IO = Für das Pollin AVR-NET-IO Board können die Sensoren DS18S20+ , normal Betrieb [[File:netio-1wire_normal.png]] parasitären Modus [[File:netio-1wire.png]] Anmerkung: Wenn man beim Net-IO nicht alle Analogeingänge benötigt, lässt sich der 1-Wire-Bus auch an der Schraubklemme ADC1 ganz gut aufschalten. Vorteil ist, dass man gleich alle passenden Spannungen (GND, +5V) an den beiden nebenliegenden Schraubklemmen hat. Das Pinning muss dann entspechend in der kann in der Datei pinning/hardware/netio.m4 von PD6 auf PA4 geändert werden. Vorteil dieser Konfiguration ist, dass man den DB-25-Verbinder zum Anschluss der Relaisplatine K8IO von Pollin frei hat und den EXT Steckverbinder zum Anschluss eines LCD über ein 4bit-Interface nutzen kann, ohne die Erweiterungsplatine von Pollin zu benötigen. Pinbelegung: [[File:ds18s20-par-pinout.jpg]] = Anschluss Etherrape = Die Schaltung je nach parasitärem oder normalem Betriebsmodus kann aus der NetIO Skizze übernommen werden. Data liegt auf PORTD an Pin 7: PORTD +---+ |x x| |x X| <- Pin 7 |x x |x x| |x x| +---+ Direkt neben PORTD befinden sich 2 Pins mit GND und 5V als Beschriftung. GND kann als GND und 5V als Vcc genutzt werden. = Einbindung in [[Control6]] = Die Sensoren können mit '''ONEWIRE_GET''' einfach abgefragt werden. Die Funktion führt automatisch ein ''convert'' aus, es sind also keine zwei Schritte erforderlich wie bei dem Zugriff über [[ECMD]]. Die Rückgabe erfolgt (analog der Funktion '''KTY_GET''') in Centigrad, also Temperatur * 10. Hier vielleicht ein kleines Beispiel, das die Daten per [[SYSLOG]] ausgibt sobald sich die Temperatur um mehr als ein Grad zur letzten Messung verändert hat. <pre> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO div_t res = div(Temperatur,10); SYSLOG("temperature changed %d.%d",res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> = Abfrage per [[SNMP]] = Falls Polling-Support aktiviert wurde können die Sensorwerte per SNMP abgefragt werden. Mit Naming-Support stehen auch die Namen per SNMP zur Verfügung und die Index-Nummern sind fix auf die Position in der Namenstabelle festgelegt. Dies ist sehr hilfreich, um bestimmte Sensoren über den SNMP-Index anzusprechen. Es gibt folgende OIDs: * .1.3.6.1.4.1.2021.13.23.3.1.<idx> : ROM-Code des Sensors * .1.3.6.1.4.1.2021.13.23.3.2.<idx> : Sensor-Name (nur mit Naming-Support) * .1.3.6.1.4.1.2021.13.23.3.3.<idx> : Temperaturwert in Centigrad * .1.3.6.1.4.1.2021.13.23.3.4.<idx> : 0 = Sensor nicht vorhanden, 1 = Sensor vorhanden Hier ein Beispiel: <pre> # snmpwalk -Osn -c public -v 1 192.168.255.90 1.3.6.1.4.1.2021.13.23.3 .1.3.6.1.4.1.2021.13.23.3.1.0 = STRING: "1080cff6010800f9" .1.3.6.1.4.1.2021.13.23.3.1.1 = STRING: "10c8cff60108002d" .1.3.6.1.4.1.2021.13.23.3.1.2 = STRING: "1029f6dc0108002f" .1.3.6.1.4.1.2021.13.23.3.1.3 = STRING: "10f2d0f60108001c" .1.3.6.1.4.1.2021.13.23.3.1.4 = STRING: "105a17f70108001d" .1.3.6.1.4.1.2021.13.23.3.1.5 = STRING: "10b8d8f601080098" .1.3.6.1.4.1.2021.13.23.3.1.6 = STRING: "104dedf601080057" .1.3.6.1.4.1.2021.13.23.3.1.7 = STRING: "10011af701080027" .1.3.6.1.4.1.2021.13.23.3.1.8 = STRING: "0000000000000000" .1.3.6.1.4.1.2021.13.23.3.1.9 = STRING: "0000000000000000" .1.3.6.1.4.1.2021.13.23.3.2.0 = STRING: "kessel" .1.3.6.1.4.1.2021.13.23.3.2.1 = STRING: "warmwasser" .1.3.6.1.4.1.2021.13.23.3.2.2 = STRING: "aussen" .1.3.6.1.4.1.2021.13.23.3.2.3 = STRING: "speicher" .1.3.6.1.4.1.2021.13.23.3.2.4 = STRING: "heizung vl" .1.3.6.1.4.1.2021.13.23.3.2.5 = STRING: "heizung rl" .1.3.6.1.4.1.2021.13.23.3.2.6 = STRING: "boiler vl" .1.3.6.1.4.1.2021.13.23.3.2.7 = STRING: "boiler rl" .1.3.6.1.4.1.2021.13.23.3.2.8 = "" .1.3.6.1.4.1.2021.13.23.3.2.9 = "" .1.3.6.1.4.1.2021.13.23.3.3.0 = INTEGER: 334 .1.3.6.1.4.1.2021.13.23.3.3.1 = INTEGER: 467 .1.3.6.1.4.1.2021.13.23.3.3.2 = INTEGER: 127 .1.3.6.1.4.1.2021.13.23.3.3.3 = INTEGER: 185 .1.3.6.1.4.1.2021.13.23.3.3.4 = INTEGER: 318 .1.3.6.1.4.1.2021.13.23.3.3.5 = INTEGER: 269 .1.3.6.1.4.1.2021.13.23.3.3.6 = INTEGER: 366 .1.3.6.1.4.1.2021.13.23.3.3.7 = INTEGER: 291 .1.3.6.1.4.1.2021.13.23.3.3.8 = INTEGER: 0 .1.3.6.1.4.1.2021.13.23.3.3.9 = INTEGER: 0 .1.3.6.1.4.1.2021.13.23.3.4.0 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.1 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.2 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.3 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.4 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.5 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.6 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.7 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.8 = INTEGER: 0 .1.3.6.1.4.1.2021.13.23.3.4.9 = INTEGER: 0 </pre> = Beispiele = == sh oder bash == Einfaches SH (Linux Shell) Script von stesie (irc) zum Auslesen von einem Wert (udp support muss enabled sein oder option -u nicht verwenden!) <source lang="bash"> #! /bin/sh SENSORID=10529f7001080016 #ESEXIP=2001:6f8:1209:23:42::17 #IPv6 Adresse ESEXIP=192.168.255.90 #IPv6 #echo 1w convert $SENSORID | nc6 -u $ESEXIP 2701 -q 1 2>/dev/null | grep -qe OK || exit 1 #echo 1w get $SENSORID | nc6 -u $ESEXIP 2701 -q 1 2>/dev/null | sed -e 's/Temperatur: //' #IPv4 echo 1w convert $SENSORID | nc -u $ESEXIP 2701 -q 1 2>/dev/null | grep -qe OK || exit 1 echo 1w get $SENSORID | nc -u $ESEXIP 2701 -q 1 2>/dev/null | sed -e 's/Temperatur: //' </source> bash Script von Tron12 zum Auslesen aller Werte (Achtung Port 2701 ist nicht standard!! Sowie udp support muss enabled sein oder option -u nicht verwenden!) <source lang="bash"> #! /bin/sh # # netcat-openbsd 1.89-3ubuntu2 NETIOIP="-4 192.168.178.249" #für IPv6: #NETIOIP="-6 2001:6f8:1209:23:42::17" NETIOPORT="2702" N_DATE=`echo date | nc -u $NETIOIP $NETIOPORT -q 1 ` N_GET_ID=`echo 1w list | nc -u $NETIOIP $NETIOPORT -q 1 | grep -qe OK || exit 1` echo "Date: $N_DATE" echo "---------------------------------" for i in $N_GET_ID do tmp=`echo 1w convert $i | nc -u $NETIOIP $NETIOPORT -q 1 2>/dev/null | grep -qe OK || exit 1` tmp=`echo 1w get $i | nc -u $NETIOIP $NETIOPORT -q 1 2>/dev/null ` echo "Sensor: $i :: $tmp" done </source> == Perl == Beispiel in Perl das alle Sensoren ermittelt und anschließend die Werte ausgibt. Benötigt wird das Modul NET das kein IPv6 kann <source lang="perl"> #!/usr/bin/perl -w #Auslesen der 1 Wire Sensoren an einem AVR-NET-IO mit ethersex use strict; use Net::Telnet (); my $esexip="192.168.255.90"; my $esexport="2701"; my $esex; my @sensor; my $sensor; my $dummy; my $temp; $esex = Net::Telnet->new || die "kann Ethersex nicht finden";; $esex->open(Host => $esexip, Port => $esexport, Timeout => 2); #Alles Sensor-IDs auslesen und dem Array @sensor zuweisen $esex->print("1w list"); ($sensor) = $esex->waitfor(Timeout => 2, String => "OK"); @sensor=split(/\s+/, $sensor); print "@sensor","\n"; #Kontrollausgabe my $zahler=@sensor; print "Anzahl der Elemente :",$zahler,"\n\n"; #Alles Sensore Temperatur einlesen $esex->print("1w convert"); $esex->waitfor(Timeout => 2, String => "OK"); #Sensor ID inklusive Wert ausgeben foreach (@sensor) { $esex->print("1w get $_"); ($dummy,$temp)=$esex->waitfor(Match =>'/[-]?\d+\.\d+/', Timeout => 5); print "Temperatur vom ID ",$_,": ",$temp," C°","\n"; } </source> == Python == <source lang="python"> #!/usr/bin/python from socket import * def connectEP(): s = socket(AF_INET, SOCK_STREAM) s.settimeout(5) s.connect(("192.168.5.3", 2701)) return s def getTemperature(): s.send("1w list\n") sensors = [] sensors_result = {} # list aller Sensoren while 1: response = s.recv(1024).rstrip("\n") if not response: break if response != "OK": sensors.append(response) else: break # wert konvertieren for sensor in sensors: s.send("1w convert " + sensor + "\n") while 1: response = s.recv(1024).rstrip("\n") if response == "OK": break # wert auslesen s.send("1w get " + sensor + "\n") response = s.recv(1024).rstrip("\n").lstrip() sensors_result[sensor] = response return(sensors_result) s = connectEP() for sensor, value in getTemperature().iteritems(): print sensor + " " + value </source> == PHP == <source lang="php"> <html> <head> <title>ethersex php example</title> </head> <body> <?php define(IP, '192.168.10.9'); // deine ethersex ip adresse define(PORT, 2701); // standard port im image request("1w convert"); $response = request("1w list"); $explode = explode("\n", $response); for ($i=0; $i < count($explode)-2; $i++) { echo "Sensor: " . trim($explode[$i]); echo " -- Wert: " . request("1w get " . $explode[$i]); echo "<br>\n"; } function request($request) { $rs = fsockopen(IP, PORT); if (!$rs) { $response = "Kann Verbindung nicht aufbauen!"; } else { $response =""; $request = "!" . $request . "\r\n"; fputs($rs, $request); while (!feof($rs)) { $response .= fgets($rs, 128); } fclose($rs); } return $response; } ?> </body> </source> [[Category:Ethersex]] [[Category:StepByStep]] [[Category:Onewire]] = Bezugsquellen = * Laut Michael Schultz (k1w1) hat er immer DS1820 auf Lager und kann sie sehr günstig weiterverkaufen. Auch Mindermengen. Mail: ethersex [AT] keyb [DOT] de 76bdd162a567ae518fcf190dbe6f242dcbac74e6 495 494 2012-04-14T10:22:39Z Sittner 461 /* Onewire Befehle */ wikitext text/x-wiki {{i18n|Onewire}} {{Module |NAME=Onewire |MENUCONFIG={{I/O}}->Onewire support |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] [[HTTPD]] (optional) [[SNMP]] (optional) |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} Ethersex kann 1-wire Temperatursensoren mit [[ECMD]] auflisten und abfragen. Es wird eine reine Softwareimplementierung des Protokolls benutzt, was keine weiteren Hardware erfordert, als die Temperatursensoren selbst. = Pinning = In der Standardkonfiguration liegt der Datapin des Buses auf PD6 (kann z.B. in der pinning/hardware/netio.m4 oder pinning/hardware/etherrape.m4 geändert werden). Die Definition der Pins erfolgt mit: <source lang=c> ONEWIRE_PORT_RANGE(PXn, PXm) </source> wobei PXn und PNm Pins auf PORTX sind. Jeder Pin zwischen und einschließlich PXn und PXm bildet einen eingenständigen Onewire Bus. Du kannst bis zu acht Busse auf einem PORT definieren (alle Busse müssen auf dem selben PORT liegen!) == Beispiele == Wenn Du nur einen einzigen Bus benötigst, definiere den Bereich wie folgt: '''PORTD: PIN2''' <source lang=c> ONEWIRE_PORT_RANGE(PD2, PD2) </source> Für drei Busse würde das ganze etwa so aussehen: '''PORTD: PIN2, PIN3, PIN4''' <source lang=c> ONEWIRE_PORT_RANGE(PD2, PD4) </source> = Polling Modus = = Benennung von Sensoren = = Unterstützte Hardware = Folgende 1-wire Hardware wird momentan durch Ethersex unterstützt: * DS1820 (Temperatursensor) * DS18B20 (Temperatursensor) * DS1822 (Temperatursensor) * DS2502 (EEPROM) * DS2450 (4 Kanal ADC) = Onewire Befehle = unter Linux als erstes netcat starten (hierbei natürlich die IP ggf modifizieren): netcat 192.168.0.15 2701 danach am prompt: 1w list Gibt eine Liste mit Hexcodes aller angeschlossenen und erkannten Onewire(tm) Sensoren aus. Bei aktiviertem Naming-Support wird (per TAB getrennt) zusätzlich der Name ausgegeben. Außerdem kann mit '''ECMD 1w list with values (ONEWIRE_ECMD_LIST_VALUE_SUPPORT)''' der aktuelle Temperaturwert mit ausgegeben werden. Dies erspart zusätzliche '''1w get''' Aufrufe, setzt allerding Polling-Support vorraus. 1w convert <hexcode> Veranlasst eine Temperaturmessung des addressierten Sensors, oder, wenn das Argument <hexcode> weggelassen wird, aller angeschlossener Sensoren. Im Polling-Modus wird dieses Kommando ignoriert. 1w get <hexcode> Gibt die gemessene Temperatur eines Sensors aus. = Einbindung in die [[HTTPD]]-Weboberfläche = Unter httpd/embed/ow.ht.m4, bzw httpd/embed/Xow.ht.m4 liegt eine Weboberflaeche, die alle Sensoren erkennt und ihre aktuelle Temperatur regelmässig per Ajax abfragt und anzeigt. Im Falle von Xow.ht.m4 wird sogar Graph der Temperatur mittels SVG gemalt. Um die Dateien einzubinden, muss man einfach bei aktiviertem Onewiresupport den Webserver und das Datei Inlining aktivieren. Die Dateien können dann unter ow.ht bzw. unter Xow.ht angezeigt werden. Das Beispiel zeigt die SVG-Version mit Naming-Support: [[File:onewire-svg.png]] = Anschluss AVR-NET-IO = Für das Pollin AVR-NET-IO Board können die Sensoren DS18S20+ , normal Betrieb [[File:netio-1wire_normal.png]] parasitären Modus [[File:netio-1wire.png]] Anmerkung: Wenn man beim Net-IO nicht alle Analogeingänge benötigt, lässt sich der 1-Wire-Bus auch an der Schraubklemme ADC1 ganz gut aufschalten. Vorteil ist, dass man gleich alle passenden Spannungen (GND, +5V) an den beiden nebenliegenden Schraubklemmen hat. Das Pinning muss dann entspechend in der kann in der Datei pinning/hardware/netio.m4 von PD6 auf PA4 geändert werden. Vorteil dieser Konfiguration ist, dass man den DB-25-Verbinder zum Anschluss der Relaisplatine K8IO von Pollin frei hat und den EXT Steckverbinder zum Anschluss eines LCD über ein 4bit-Interface nutzen kann, ohne die Erweiterungsplatine von Pollin zu benötigen. Pinbelegung: [[File:ds18s20-par-pinout.jpg]] = Anschluss Etherrape = Die Schaltung je nach parasitärem oder normalem Betriebsmodus kann aus der NetIO Skizze übernommen werden. Data liegt auf PORTD an Pin 7: PORTD +---+ |x x| |x X| <- Pin 7 |x x |x x| |x x| +---+ Direkt neben PORTD befinden sich 2 Pins mit GND und 5V als Beschriftung. GND kann als GND und 5V als Vcc genutzt werden. = Einbindung in [[Control6]] = Die Sensoren können mit '''ONEWIRE_GET''' einfach abgefragt werden. Die Funktion führt automatisch ein ''convert'' aus, es sind also keine zwei Schritte erforderlich wie bei dem Zugriff über [[ECMD]]. Die Rückgabe erfolgt (analog der Funktion '''KTY_GET''') in Centigrad, also Temperatur * 10. Hier vielleicht ein kleines Beispiel, das die Daten per [[SYSLOG]] ausgibt sobald sich die Temperatur um mehr als ein Grad zur letzten Messung verändert hat. <pre> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO div_t res = div(Temperatur,10); SYSLOG("temperature changed %d.%d",res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> = Abfrage per [[SNMP]] = Falls Polling-Support aktiviert wurde können die Sensorwerte per SNMP abgefragt werden. Mit Naming-Support stehen auch die Namen per SNMP zur Verfügung und die Index-Nummern sind fix auf die Position in der Namenstabelle festgelegt. Dies ist sehr hilfreich, um bestimmte Sensoren über den SNMP-Index anzusprechen. Es gibt folgende OIDs: * .1.3.6.1.4.1.2021.13.23.3.1.<idx> : ROM-Code des Sensors * .1.3.6.1.4.1.2021.13.23.3.2.<idx> : Sensor-Name (nur mit Naming-Support) * .1.3.6.1.4.1.2021.13.23.3.3.<idx> : Temperaturwert in Centigrad * .1.3.6.1.4.1.2021.13.23.3.4.<idx> : 0 = Sensor nicht vorhanden, 1 = Sensor vorhanden Hier ein Beispiel: <pre> # snmpwalk -Osn -c public -v 1 192.168.255.90 1.3.6.1.4.1.2021.13.23.3 .1.3.6.1.4.1.2021.13.23.3.1.0 = STRING: "1080cff6010800f9" .1.3.6.1.4.1.2021.13.23.3.1.1 = STRING: "10c8cff60108002d" .1.3.6.1.4.1.2021.13.23.3.1.2 = STRING: "1029f6dc0108002f" .1.3.6.1.4.1.2021.13.23.3.1.3 = STRING: "10f2d0f60108001c" .1.3.6.1.4.1.2021.13.23.3.1.4 = STRING: "105a17f70108001d" .1.3.6.1.4.1.2021.13.23.3.1.5 = STRING: "10b8d8f601080098" .1.3.6.1.4.1.2021.13.23.3.1.6 = STRING: "104dedf601080057" .1.3.6.1.4.1.2021.13.23.3.1.7 = STRING: "10011af701080027" .1.3.6.1.4.1.2021.13.23.3.1.8 = STRING: "0000000000000000" .1.3.6.1.4.1.2021.13.23.3.1.9 = STRING: "0000000000000000" .1.3.6.1.4.1.2021.13.23.3.2.0 = STRING: "kessel" .1.3.6.1.4.1.2021.13.23.3.2.1 = STRING: "warmwasser" .1.3.6.1.4.1.2021.13.23.3.2.2 = STRING: "aussen" .1.3.6.1.4.1.2021.13.23.3.2.3 = STRING: "speicher" .1.3.6.1.4.1.2021.13.23.3.2.4 = STRING: "heizung vl" .1.3.6.1.4.1.2021.13.23.3.2.5 = STRING: "heizung rl" .1.3.6.1.4.1.2021.13.23.3.2.6 = STRING: "boiler vl" .1.3.6.1.4.1.2021.13.23.3.2.7 = STRING: "boiler rl" .1.3.6.1.4.1.2021.13.23.3.2.8 = "" .1.3.6.1.4.1.2021.13.23.3.2.9 = "" .1.3.6.1.4.1.2021.13.23.3.3.0 = INTEGER: 334 .1.3.6.1.4.1.2021.13.23.3.3.1 = INTEGER: 467 .1.3.6.1.4.1.2021.13.23.3.3.2 = INTEGER: 127 .1.3.6.1.4.1.2021.13.23.3.3.3 = INTEGER: 185 .1.3.6.1.4.1.2021.13.23.3.3.4 = INTEGER: 318 .1.3.6.1.4.1.2021.13.23.3.3.5 = INTEGER: 269 .1.3.6.1.4.1.2021.13.23.3.3.6 = INTEGER: 366 .1.3.6.1.4.1.2021.13.23.3.3.7 = INTEGER: 291 .1.3.6.1.4.1.2021.13.23.3.3.8 = INTEGER: 0 .1.3.6.1.4.1.2021.13.23.3.3.9 = INTEGER: 0 .1.3.6.1.4.1.2021.13.23.3.4.0 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.1 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.2 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.3 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.4 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.5 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.6 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.7 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.8 = INTEGER: 0 .1.3.6.1.4.1.2021.13.23.3.4.9 = INTEGER: 0 </pre> = Beispiele = == sh oder bash == Einfaches SH (Linux Shell) Script von stesie (irc) zum Auslesen von einem Wert (udp support muss enabled sein oder option -u nicht verwenden!) <source lang="bash"> #! /bin/sh SENSORID=10529f7001080016 #ESEXIP=2001:6f8:1209:23:42::17 #IPv6 Adresse ESEXIP=192.168.255.90 #IPv6 #echo 1w convert $SENSORID | nc6 -u $ESEXIP 2701 -q 1 2>/dev/null | grep -qe OK || exit 1 #echo 1w get $SENSORID | nc6 -u $ESEXIP 2701 -q 1 2>/dev/null | sed -e 's/Temperatur: //' #IPv4 echo 1w convert $SENSORID | nc -u $ESEXIP 2701 -q 1 2>/dev/null | grep -qe OK || exit 1 echo 1w get $SENSORID | nc -u $ESEXIP 2701 -q 1 2>/dev/null | sed -e 's/Temperatur: //' </source> bash Script von Tron12 zum Auslesen aller Werte (Achtung Port 2701 ist nicht standard!! Sowie udp support muss enabled sein oder option -u nicht verwenden!) <source lang="bash"> #! /bin/sh # # netcat-openbsd 1.89-3ubuntu2 NETIOIP="-4 192.168.178.249" #für IPv6: #NETIOIP="-6 2001:6f8:1209:23:42::17" NETIOPORT="2702" N_DATE=`echo date | nc -u $NETIOIP $NETIOPORT -q 1 ` N_GET_ID=`echo 1w list | nc -u $NETIOIP $NETIOPORT -q 1 | grep -qe OK || exit 1` echo "Date: $N_DATE" echo "---------------------------------" for i in $N_GET_ID do tmp=`echo 1w convert $i | nc -u $NETIOIP $NETIOPORT -q 1 2>/dev/null | grep -qe OK || exit 1` tmp=`echo 1w get $i | nc -u $NETIOIP $NETIOPORT -q 1 2>/dev/null ` echo "Sensor: $i :: $tmp" done </source> == Perl == Beispiel in Perl das alle Sensoren ermittelt und anschließend die Werte ausgibt. Benötigt wird das Modul NET das kein IPv6 kann <source lang="perl"> #!/usr/bin/perl -w #Auslesen der 1 Wire Sensoren an einem AVR-NET-IO mit ethersex use strict; use Net::Telnet (); my $esexip="192.168.255.90"; my $esexport="2701"; my $esex; my @sensor; my $sensor; my $dummy; my $temp; $esex = Net::Telnet->new || die "kann Ethersex nicht finden";; $esex->open(Host => $esexip, Port => $esexport, Timeout => 2); #Alles Sensor-IDs auslesen und dem Array @sensor zuweisen $esex->print("1w list"); ($sensor) = $esex->waitfor(Timeout => 2, String => "OK"); @sensor=split(/\s+/, $sensor); print "@sensor","\n"; #Kontrollausgabe my $zahler=@sensor; print "Anzahl der Elemente :",$zahler,"\n\n"; #Alles Sensore Temperatur einlesen $esex->print("1w convert"); $esex->waitfor(Timeout => 2, String => "OK"); #Sensor ID inklusive Wert ausgeben foreach (@sensor) { $esex->print("1w get $_"); ($dummy,$temp)=$esex->waitfor(Match =>'/[-]?\d+\.\d+/', Timeout => 5); print "Temperatur vom ID ",$_,": ",$temp," C°","\n"; } </source> == Python == <source lang="python"> #!/usr/bin/python from socket import * def connectEP(): s = socket(AF_INET, SOCK_STREAM) s.settimeout(5) s.connect(("192.168.5.3", 2701)) return s def getTemperature(): s.send("1w list\n") sensors = [] sensors_result = {} # list aller Sensoren while 1: response = s.recv(1024).rstrip("\n") if not response: break if response != "OK": sensors.append(response) else: break # wert konvertieren for sensor in sensors: s.send("1w convert " + sensor + "\n") while 1: response = s.recv(1024).rstrip("\n") if response == "OK": break # wert auslesen s.send("1w get " + sensor + "\n") response = s.recv(1024).rstrip("\n").lstrip() sensors_result[sensor] = response return(sensors_result) s = connectEP() for sensor, value in getTemperature().iteritems(): print sensor + " " + value </source> == PHP == <source lang="php"> <html> <head> <title>ethersex php example</title> </head> <body> <?php define(IP, '192.168.10.9'); // deine ethersex ip adresse define(PORT, 2701); // standard port im image request("1w convert"); $response = request("1w list"); $explode = explode("\n", $response); for ($i=0; $i < count($explode)-2; $i++) { echo "Sensor: " . trim($explode[$i]); echo " -- Wert: " . request("1w get " . $explode[$i]); echo "<br>\n"; } function request($request) { $rs = fsockopen(IP, PORT); if (!$rs) { $response = "Kann Verbindung nicht aufbauen!"; } else { $response =""; $request = "!" . $request . "\r\n"; fputs($rs, $request); while (!feof($rs)) { $response .= fgets($rs, 128); } fclose($rs); } return $response; } ?> </body> </source> [[Category:Ethersex]] [[Category:StepByStep]] [[Category:Onewire]] = Bezugsquellen = * Laut Michael Schultz (k1w1) hat er immer DS1820 auf Lager und kann sie sehr günstig weiterverkaufen. Auch Mindermengen. Mail: ethersex [AT] keyb [DOT] de 0ac0a08a189004089349b5ef8e65eaf8f7340a3a 504 495 2012-04-15T23:28:41Z Mgue 312 moved Code to seperate pages wikitext text/x-wiki {{i18n|Onewire}} {{Module |NAME=Onewire |MENUCONFIG={{I/O}}->Onewire support |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] [[HTTPD]] (optional) [[SNMP]] (optional) |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} Ethersex kann 1-wire Temperatursensoren mit [[ECMD]] auflisten und abfragen. Es wird eine reine Softwareimplementierung des Protokolls benutzt, was keine weiteren Hardware erfordert, als die Temperatursensoren selbst. = Pinning = In der Standardkonfiguration liegt der Datapin des Buses auf PD6 (kann z.B. in der pinning/hardware/netio.m4 oder pinning/hardware/etherrape.m4 geändert werden). Die Definition der Pins erfolgt mit: <source lang=c> ONEWIRE_PORT_RANGE(PXn, PXm) </source> wobei PXn und PNm Pins auf PORTX sind. Jeder Pin zwischen und einschließlich PXn und PXm bildet einen eingenständigen Onewire Bus. Du kannst bis zu acht Busse auf einem PORT definieren (alle Busse müssen auf dem selben PORT liegen!) == Beispiele == Wenn Du nur einen einzigen Bus benötigst, definiere den Bereich wie folgt: '''PORTD: PIN2''' <source lang=c> ONEWIRE_PORT_RANGE(PD2, PD2) </source> Für drei Busse würde das ganze etwa so aussehen: '''PORTD: PIN2, PIN3, PIN4''' <source lang=c> ONEWIRE_PORT_RANGE(PD2, PD4) </source> = Polling Modus = = Benennung von Sensoren = = Unterstützte Hardware = Folgende 1-wire Hardware wird momentan durch Ethersex unterstützt: * DS1820 (Temperatursensor) * DS18B20 (Temperatursensor) * DS1822 (Temperatursensor) * DS2502 (EEPROM) * DS2450 (4 Kanal ADC) = Onewire Befehle = unter Linux als erstes netcat starten (hierbei natürlich die IP ggf modifizieren): netcat 192.168.0.15 2701 danach am prompt: 1w list Gibt eine Liste mit Hexcodes aller angeschlossenen und erkannten Onewire(tm) Sensoren aus. Bei aktiviertem Naming-Support wird (per TAB getrennt) zusätzlich der Name ausgegeben. Außerdem kann mit '''ECMD 1w list with values (ONEWIRE_ECMD_LIST_VALUE_SUPPORT)''' der aktuelle Temperaturwert mit ausgegeben werden. Dies erspart zusätzliche '''1w get''' Aufrufe, setzt allerding Polling-Support vorraus. 1w convert <hexcode> Veranlasst eine Temperaturmessung des addressierten Sensors, oder, wenn das Argument <hexcode> weggelassen wird, aller angeschlossener Sensoren. Im Polling-Modus wird dieses Kommando ignoriert. 1w get <hexcode> Gibt die gemessene Temperatur eines Sensors aus. = Einbindung in die [[HTTPD]]-Weboberfläche = Unter httpd/embed/ow.ht.m4, bzw httpd/embed/Xow.ht.m4 liegt eine Weboberflaeche, die alle Sensoren erkennt und ihre aktuelle Temperatur regelmässig per Ajax abfragt und anzeigt. Im Falle von Xow.ht.m4 wird sogar Graph der Temperatur mittels SVG gemalt. Um die Dateien einzubinden, muss man einfach bei aktiviertem Onewiresupport den Webserver und das Datei Inlining aktivieren. Die Dateien können dann unter ow.ht bzw. unter Xow.ht angezeigt werden. Das Beispiel zeigt die SVG-Version mit Naming-Support: [[File:onewire-svg.png]] = Anschluss AVR-NET-IO = Für das Pollin AVR-NET-IO Board können die Sensoren DS18S20+ , normal Betrieb [[File:netio-1wire_normal.png]] parasitären Modus [[File:netio-1wire.png]] Anmerkung: Wenn man beim Net-IO nicht alle Analogeingänge benötigt, lässt sich der 1-Wire-Bus auch an der Schraubklemme ADC1 ganz gut aufschalten. Vorteil ist, dass man gleich alle passenden Spannungen (GND, +5V) an den beiden nebenliegenden Schraubklemmen hat. Das Pinning muss dann entspechend in der kann in der Datei pinning/hardware/netio.m4 von PD6 auf PA4 geändert werden. Vorteil dieser Konfiguration ist, dass man den DB-25-Verbinder zum Anschluss der Relaisplatine K8IO von Pollin frei hat und den EXT Steckverbinder zum Anschluss eines LCD über ein 4bit-Interface nutzen kann, ohne die Erweiterungsplatine von Pollin zu benötigen. Pinbelegung: [[File:ds18s20-par-pinout.jpg]] = Anschluss Etherrape = Die Schaltung je nach parasitärem oder normalem Betriebsmodus kann aus der NetIO Skizze übernommen werden. Data liegt auf PORTD an Pin 7: PORTD +---+ |x x| |x X| <- Pin 7 |x x |x x| |x x| +---+ Direkt neben PORTD befinden sich 2 Pins mit GND und 5V als Beschriftung. GND kann als GND und 5V als Vcc genutzt werden. = Einbindung in [[Control6]] = Die Sensoren können mit '''ONEWIRE_GET''' einfach abgefragt werden. Die Funktion führt automatisch ein ''convert'' aus, es sind also keine zwei Schritte erforderlich wie bei dem Zugriff über [[ECMD]]. Die Rückgabe erfolgt (analog der Funktion '''KTY_GET''') in Centigrad, also Temperatur * 10. Hier vielleicht ein kleines Beispiel, das die Daten per [[SYSLOG]] ausgibt sobald sich die Temperatur um mehr als ein Grad zur letzten Messung verändert hat. <pre> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO div_t res = div(Temperatur,10); SYSLOG("temperature changed %d.%d",res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> = Abfrage per [[SNMP]] = Falls Polling-Support aktiviert wurde können die Sensorwerte per SNMP abgefragt werden. Mit Naming-Support stehen auch die Namen per SNMP zur Verfügung und die Index-Nummern sind fix auf die Position in der Namenstabelle festgelegt. Dies ist sehr hilfreich, um bestimmte Sensoren über den SNMP-Index anzusprechen. Es gibt folgende OIDs: * .1.3.6.1.4.1.2021.13.23.3.1.<idx> : ROM-Code des Sensors * .1.3.6.1.4.1.2021.13.23.3.2.<idx> : Sensor-Name (nur mit Naming-Support) * .1.3.6.1.4.1.2021.13.23.3.3.<idx> : Temperaturwert in Centigrad * .1.3.6.1.4.1.2021.13.23.3.4.<idx> : 0 = Sensor nicht vorhanden, 1 = Sensor vorhanden Hier ein Beispiel: <pre> # snmpwalk -Osn -c public -v 1 192.168.255.90 1.3.6.1.4.1.2021.13.23.3 .1.3.6.1.4.1.2021.13.23.3.1.0 = STRING: "1080cff6010800f9" .1.3.6.1.4.1.2021.13.23.3.1.1 = STRING: "10c8cff60108002d" .1.3.6.1.4.1.2021.13.23.3.1.2 = STRING: "1029f6dc0108002f" .1.3.6.1.4.1.2021.13.23.3.1.3 = STRING: "10f2d0f60108001c" .1.3.6.1.4.1.2021.13.23.3.1.4 = STRING: "105a17f70108001d" .1.3.6.1.4.1.2021.13.23.3.1.5 = STRING: "10b8d8f601080098" .1.3.6.1.4.1.2021.13.23.3.1.6 = STRING: "104dedf601080057" .1.3.6.1.4.1.2021.13.23.3.1.7 = STRING: "10011af701080027" .1.3.6.1.4.1.2021.13.23.3.1.8 = STRING: "0000000000000000" .1.3.6.1.4.1.2021.13.23.3.1.9 = STRING: "0000000000000000" .1.3.6.1.4.1.2021.13.23.3.2.0 = STRING: "kessel" .1.3.6.1.4.1.2021.13.23.3.2.1 = STRING: "warmwasser" .1.3.6.1.4.1.2021.13.23.3.2.2 = STRING: "aussen" .1.3.6.1.4.1.2021.13.23.3.2.3 = STRING: "speicher" .1.3.6.1.4.1.2021.13.23.3.2.4 = STRING: "heizung vl" .1.3.6.1.4.1.2021.13.23.3.2.5 = STRING: "heizung rl" .1.3.6.1.4.1.2021.13.23.3.2.6 = STRING: "boiler vl" .1.3.6.1.4.1.2021.13.23.3.2.7 = STRING: "boiler rl" .1.3.6.1.4.1.2021.13.23.3.2.8 = "" .1.3.6.1.4.1.2021.13.23.3.2.9 = "" .1.3.6.1.4.1.2021.13.23.3.3.0 = INTEGER: 334 .1.3.6.1.4.1.2021.13.23.3.3.1 = INTEGER: 467 .1.3.6.1.4.1.2021.13.23.3.3.2 = INTEGER: 127 .1.3.6.1.4.1.2021.13.23.3.3.3 = INTEGER: 185 .1.3.6.1.4.1.2021.13.23.3.3.4 = INTEGER: 318 .1.3.6.1.4.1.2021.13.23.3.3.5 = INTEGER: 269 .1.3.6.1.4.1.2021.13.23.3.3.6 = INTEGER: 366 .1.3.6.1.4.1.2021.13.23.3.3.7 = INTEGER: 291 .1.3.6.1.4.1.2021.13.23.3.3.8 = INTEGER: 0 .1.3.6.1.4.1.2021.13.23.3.3.9 = INTEGER: 0 .1.3.6.1.4.1.2021.13.23.3.4.0 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.1 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.2 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.3 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.4 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.5 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.6 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.7 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.8 = INTEGER: 0 .1.3.6.1.4.1.2021.13.23.3.4.9 = INTEGER: 0 </pre> = Codebeispiele = * [[Onewire/Example/PHP (Deutsch) | PHP]] * [[Onewire/Example/Perl (Deutsch) | Perl]] * [[Onewire/Example/Python | Python]] * [[Onewire/Example/Shell | sh/bash]] [[Category:Ethersex]] [[Category:StepByStep]] [[Category:Onewire]] = Bezugsquellen = * Laut Michael Schultz (k1w1) hat er immer DS1820 auf Lager und kann sie sehr günstig weiterverkaufen. Auch Mindermengen. Mail: ethersex [AT] keyb [DOT] de 6d1ca75fbc853d515a4ea948db0d8a9ebbff8256 509 504 2012-04-20T14:58:58Z Sittner 461 /* Polling Modus */ wikitext text/x-wiki {{i18n|Onewire}} {{Module |NAME=Onewire |MENUCONFIG={{I/O}}->Onewire support |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] [[HTTPD]] (optional) [[SNMP]] (optional) |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} Ethersex kann 1-wire Temperatursensoren mit [[ECMD]] auflisten und abfragen. Es wird eine reine Softwareimplementierung des Protokolls benutzt, was keine weiteren Hardware erfordert, als die Temperatursensoren selbst. = Pinning = In der Standardkonfiguration liegt der Datapin des Buses auf PD6 (kann z.B. in der pinning/hardware/netio.m4 oder pinning/hardware/etherrape.m4 geändert werden). Die Definition der Pins erfolgt mit: <source lang=c> ONEWIRE_PORT_RANGE(PXn, PXm) </source> wobei PXn und PNm Pins auf PORTX sind. Jeder Pin zwischen und einschließlich PXn und PXm bildet einen eingenständigen Onewire Bus. Du kannst bis zu acht Busse auf einem PORT definieren (alle Busse müssen auf dem selben PORT liegen!) == Beispiele == Wenn Du nur einen einzigen Bus benötigst, definiere den Bereich wie folgt: '''PORTD: PIN2''' <source lang=c> ONEWIRE_PORT_RANGE(PD2, PD2) </source> Für drei Busse würde das ganze etwa so aussehen: '''PORTD: PIN2, PIN3, PIN4''' <source lang=c> ONEWIRE_PORT_RANGE(PD2, PD4) </source> = Polling Modus = │ │ [*] Onewire Polling │ │ │ │ (375) Time between discoveries in 0.8s steps │ │ │ │ (12) Time between polling in 0.8s steps │ │ │ │ [*] ECMD 1w list with values │ │ │ │ (10) Maximum sensor count │ │ Im Polling-Modus werden die Sensoren im Hintergrund abgefragt, so dass die Werte bei Bedarf direkt zur Verfügung stehen und nicht erst gewandelt bzw. eingelesen werden müssen. Der Intervall zwischen den Discoveries und zwischen den Abfragen der Werte kann getrennt eingestellt werden. Die Option '''ECMD 1w list with values''' bietet die Möglichkeit, die aktuellen Werte bei Aufruf von '''1w list''' mit ausgeben zu lassen. So können darauf folgende '''1w get''' Kommandos entfallen. Da zur Pufferung der Werte, ROM-Codes, etc. RAM-Speicher benötigt wird, muss per '''Maximum sensor count''' angegeben werden, für wie viele Sensoren Speicher reserviert wird. = Benennung von Sensoren = = Unterstützte Hardware = Folgende 1-wire Hardware wird momentan durch Ethersex unterstützt: * DS1820 (Temperatursensor) * DS18B20 (Temperatursensor) * DS1822 (Temperatursensor) * DS2502 (EEPROM) * DS2450 (4 Kanal ADC) = Onewire Befehle = unter Linux als erstes netcat starten (hierbei natürlich die IP ggf modifizieren): netcat 192.168.0.15 2701 danach am prompt: 1w list Gibt eine Liste mit Hexcodes aller angeschlossenen und erkannten Onewire(tm) Sensoren aus. Bei aktiviertem Naming-Support wird (per TAB getrennt) zusätzlich der Name ausgegeben. Außerdem kann mit '''ECMD 1w list with values (ONEWIRE_ECMD_LIST_VALUE_SUPPORT)''' der aktuelle Temperaturwert mit ausgegeben werden. Dies erspart zusätzliche '''1w get''' Aufrufe, setzt allerding Polling-Support vorraus. 1w convert <hexcode> Veranlasst eine Temperaturmessung des addressierten Sensors, oder, wenn das Argument <hexcode> weggelassen wird, aller angeschlossener Sensoren. Im Polling-Modus wird dieses Kommando ignoriert. 1w get <hexcode> Gibt die gemessene Temperatur eines Sensors aus. = Einbindung in die [[HTTPD]]-Weboberfläche = Unter httpd/embed/ow.ht.m4, bzw httpd/embed/Xow.ht.m4 liegt eine Weboberflaeche, die alle Sensoren erkennt und ihre aktuelle Temperatur regelmässig per Ajax abfragt und anzeigt. Im Falle von Xow.ht.m4 wird sogar Graph der Temperatur mittels SVG gemalt. Um die Dateien einzubinden, muss man einfach bei aktiviertem Onewiresupport den Webserver und das Datei Inlining aktivieren. Die Dateien können dann unter ow.ht bzw. unter Xow.ht angezeigt werden. Das Beispiel zeigt die SVG-Version mit Naming-Support: [[File:onewire-svg.png]] = Anschluss AVR-NET-IO = Für das Pollin AVR-NET-IO Board können die Sensoren DS18S20+ , normal Betrieb [[File:netio-1wire_normal.png]] parasitären Modus [[File:netio-1wire.png]] Anmerkung: Wenn man beim Net-IO nicht alle Analogeingänge benötigt, lässt sich der 1-Wire-Bus auch an der Schraubklemme ADC1 ganz gut aufschalten. Vorteil ist, dass man gleich alle passenden Spannungen (GND, +5V) an den beiden nebenliegenden Schraubklemmen hat. Das Pinning muss dann entspechend in der kann in der Datei pinning/hardware/netio.m4 von PD6 auf PA4 geändert werden. Vorteil dieser Konfiguration ist, dass man den DB-25-Verbinder zum Anschluss der Relaisplatine K8IO von Pollin frei hat und den EXT Steckverbinder zum Anschluss eines LCD über ein 4bit-Interface nutzen kann, ohne die Erweiterungsplatine von Pollin zu benötigen. Pinbelegung: [[File:ds18s20-par-pinout.jpg]] = Anschluss Etherrape = Die Schaltung je nach parasitärem oder normalem Betriebsmodus kann aus der NetIO Skizze übernommen werden. Data liegt auf PORTD an Pin 7: PORTD +---+ |x x| |x X| <- Pin 7 |x x |x x| |x x| +---+ Direkt neben PORTD befinden sich 2 Pins mit GND und 5V als Beschriftung. GND kann als GND und 5V als Vcc genutzt werden. = Einbindung in [[Control6]] = Die Sensoren können mit '''ONEWIRE_GET''' einfach abgefragt werden. Die Funktion führt automatisch ein ''convert'' aus, es sind also keine zwei Schritte erforderlich wie bei dem Zugriff über [[ECMD]]. Die Rückgabe erfolgt (analog der Funktion '''KTY_GET''') in Centigrad, also Temperatur * 10. Hier vielleicht ein kleines Beispiel, das die Daten per [[SYSLOG]] ausgibt sobald sich die Temperatur um mehr als ein Grad zur letzten Messung verändert hat. <pre> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO div_t res = div(Temperatur,10); SYSLOG("temperature changed %d.%d",res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> = Abfrage per [[SNMP]] = Falls Polling-Support aktiviert wurde können die Sensorwerte per SNMP abgefragt werden. Mit Naming-Support stehen auch die Namen per SNMP zur Verfügung und die Index-Nummern sind fix auf die Position in der Namenstabelle festgelegt. Dies ist sehr hilfreich, um bestimmte Sensoren über den SNMP-Index anzusprechen. Es gibt folgende OIDs: * .1.3.6.1.4.1.2021.13.23.3.1.<idx> : ROM-Code des Sensors * .1.3.6.1.4.1.2021.13.23.3.2.<idx> : Sensor-Name (nur mit Naming-Support) * .1.3.6.1.4.1.2021.13.23.3.3.<idx> : Temperaturwert in Centigrad * .1.3.6.1.4.1.2021.13.23.3.4.<idx> : 0 = Sensor nicht vorhanden, 1 = Sensor vorhanden Hier ein Beispiel: <pre> # snmpwalk -Osn -c public -v 1 192.168.255.90 1.3.6.1.4.1.2021.13.23.3 .1.3.6.1.4.1.2021.13.23.3.1.0 = STRING: "1080cff6010800f9" .1.3.6.1.4.1.2021.13.23.3.1.1 = STRING: "10c8cff60108002d" .1.3.6.1.4.1.2021.13.23.3.1.2 = STRING: "1029f6dc0108002f" .1.3.6.1.4.1.2021.13.23.3.1.3 = STRING: "10f2d0f60108001c" .1.3.6.1.4.1.2021.13.23.3.1.4 = STRING: "105a17f70108001d" .1.3.6.1.4.1.2021.13.23.3.1.5 = STRING: "10b8d8f601080098" .1.3.6.1.4.1.2021.13.23.3.1.6 = STRING: "104dedf601080057" .1.3.6.1.4.1.2021.13.23.3.1.7 = STRING: "10011af701080027" .1.3.6.1.4.1.2021.13.23.3.1.8 = STRING: "0000000000000000" .1.3.6.1.4.1.2021.13.23.3.1.9 = STRING: "0000000000000000" .1.3.6.1.4.1.2021.13.23.3.2.0 = STRING: "kessel" .1.3.6.1.4.1.2021.13.23.3.2.1 = STRING: "warmwasser" .1.3.6.1.4.1.2021.13.23.3.2.2 = STRING: "aussen" .1.3.6.1.4.1.2021.13.23.3.2.3 = STRING: "speicher" .1.3.6.1.4.1.2021.13.23.3.2.4 = STRING: "heizung vl" .1.3.6.1.4.1.2021.13.23.3.2.5 = STRING: "heizung rl" .1.3.6.1.4.1.2021.13.23.3.2.6 = STRING: "boiler vl" .1.3.6.1.4.1.2021.13.23.3.2.7 = STRING: "boiler rl" .1.3.6.1.4.1.2021.13.23.3.2.8 = "" .1.3.6.1.4.1.2021.13.23.3.2.9 = "" .1.3.6.1.4.1.2021.13.23.3.3.0 = INTEGER: 334 .1.3.6.1.4.1.2021.13.23.3.3.1 = INTEGER: 467 .1.3.6.1.4.1.2021.13.23.3.3.2 = INTEGER: 127 .1.3.6.1.4.1.2021.13.23.3.3.3 = INTEGER: 185 .1.3.6.1.4.1.2021.13.23.3.3.4 = INTEGER: 318 .1.3.6.1.4.1.2021.13.23.3.3.5 = INTEGER: 269 .1.3.6.1.4.1.2021.13.23.3.3.6 = INTEGER: 366 .1.3.6.1.4.1.2021.13.23.3.3.7 = INTEGER: 291 .1.3.6.1.4.1.2021.13.23.3.3.8 = INTEGER: 0 .1.3.6.1.4.1.2021.13.23.3.3.9 = INTEGER: 0 .1.3.6.1.4.1.2021.13.23.3.4.0 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.1 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.2 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.3 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.4 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.5 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.6 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.7 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.8 = INTEGER: 0 .1.3.6.1.4.1.2021.13.23.3.4.9 = INTEGER: 0 </pre> = Codebeispiele = * [[Onewire/Example/PHP (Deutsch) | PHP]] * [[Onewire/Example/Perl (Deutsch) | Perl]] * [[Onewire/Example/Python | Python]] * [[Onewire/Example/Shell | sh/bash]] [[Category:Ethersex]] [[Category:StepByStep]] [[Category:Onewire]] = Bezugsquellen = * Laut Michael Schultz (k1w1) hat er immer DS1820 auf Lager und kann sie sehr günstig weiterverkaufen. Auch Mindermengen. Mail: ethersex [AT] keyb [DOT] de 8d7d38b1a7876fe49f57669b7f91f58226a8da32 510 509 2012-04-20T15:14:19Z Sittner 461 wikitext text/x-wiki {{i18n|Onewire}} {{Module |NAME=Onewire |MENUCONFIG={{I/O}}->Onewire support |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] [[HTTPD]] (optional) [[SNMP]] (optional) |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} Ethersex kann 1-wire Temperatursensoren mit [[ECMD]] auflisten und abfragen. Es wird eine reine Softwareimplementierung des Protokolls benutzt, was keine weiteren Hardware erfordert, als die Temperatursensoren selbst. = Pinning = In der Standardkonfiguration liegt der Datapin des Buses auf PD6 (kann z.B. in der pinning/hardware/netio.m4 oder pinning/hardware/etherrape.m4 geändert werden). Die Definition der Pins erfolgt mit: <source lang=c> ONEWIRE_PORT_RANGE(PXn, PXm) </source> wobei PXn und PNm Pins auf PORTX sind. Jeder Pin zwischen und einschließlich PXn und PXm bildet einen eingenständigen Onewire Bus. Du kannst bis zu acht Busse auf einem PORT definieren (alle Busse müssen auf dem selben PORT liegen!) == Beispiele == Wenn Du nur einen einzigen Bus benötigst, definiere den Bereich wie folgt: '''PORTD: PIN2''' <source lang=c> ONEWIRE_PORT_RANGE(PD2, PD2) </source> Für drei Busse würde das ganze etwa so aussehen: '''PORTD: PIN2, PIN3, PIN4''' <source lang=c> ONEWIRE_PORT_RANGE(PD2, PD4) </source> = Polling Modus = │ │ [*] Onewire Polling │ │ │ │ (375) Time between discoveries in 0.8s steps │ │ │ │ (12) Time between polling in 0.8s steps │ │ │ │ [*] ECMD 1w list with values │ │ │ │ (10) Maximum sensor count │ │ Im Polling-Modus werden die Sensoren im Hintergrund abgefragt, so dass die Werte bei Bedarf direkt zur Verfügung stehen und nicht erst gewandelt bzw. eingelesen werden müssen. Der Intervall zwischen den Discoveries und zwischen den Abfragen der Werte kann getrennt eingestellt werden. Die Option '''ECMD 1w list with values''' bietet die Möglichkeit, die aktuellen Werte bei Aufruf von '''1w list''' mit ausgeben zu lassen. So können darauf folgende '''1w get''' Kommandos entfallen. Da zur Pufferung der Werte, ROM-Codes, etc. RAM-Speicher benötigt wird, muss per '''Maximum sensor count''' angegeben werden, für wie viele Sensoren Speicher reserviert wird. = Benennung von Sensoren = │ │ [*] Onewire naming support │ │ │ │ (10) Maximum sensor count │ │ Um den Sensoren sinnvolle Namen zu geben besteht die Möglichkeit im EEPROM eine entsprechende Zuweisungstabelle anzulegen (ROM-Code -> Name). Die Namen werden bei bei Aufruf von '''1w list''' mit ausgegeben. Dazu gibt es folgende ECMD Kommandos: 1w name list Auflistung der aktuellen Zuweisungen (Spalten: ID, ROM-Code, Name). Die ID bezeichnet die Position in der Zuweisungstabelle und kann u.a. dazu benutzt werden, Sensoren bei SNMP-Abfragen eindeutig zu referenzieren. 1w name set <ID> <ROM-Code> <Name> Erstellt einen entsprechenden Tabelleneintrag. 1w name clear <ID> Löscht die Felder eines Tabelleneintrags. 1w name save Speichert die aktuelle Tabelle im EEPROM = Unterstützte Hardware = Folgende 1-wire Hardware wird momentan durch Ethersex unterstützt: * DS1820 (Temperatursensor) * DS18B20 (Temperatursensor) * DS1822 (Temperatursensor) * DS2502 (EEPROM) * DS2450 (4 Kanal ADC) = Onewire Befehle = unter Linux als erstes netcat starten (hierbei natürlich die IP ggf modifizieren): netcat 192.168.0.15 2701 danach am prompt: 1w list Gibt eine Liste mit Hexcodes aller angeschlossenen und erkannten Onewire(tm) Sensoren aus. Bei aktiviertem Naming-Support wird (per TAB getrennt) zusätzlich der Name ausgegeben. Außerdem kann mit '''ECMD 1w list with values (ONEWIRE_ECMD_LIST_VALUE_SUPPORT)''' der aktuelle Temperaturwert mit ausgegeben werden. Dies erspart zusätzliche '''1w get''' Aufrufe, setzt allerding Polling-Support vorraus. 1w convert <hexcode> Veranlasst eine Temperaturmessung des addressierten Sensors, oder, wenn das Argument <hexcode> weggelassen wird, aller angeschlossener Sensoren. Im Polling-Modus wird dieses Kommando ignoriert. 1w get <hexcode> Gibt die gemessene Temperatur eines Sensors aus. = Einbindung in die [[HTTPD]]-Weboberfläche = Unter httpd/embed/ow.ht.m4, bzw httpd/embed/Xow.ht.m4 liegt eine Weboberflaeche, die alle Sensoren erkennt und ihre aktuelle Temperatur regelmässig per Ajax abfragt und anzeigt. Im Falle von Xow.ht.m4 wird sogar Graph der Temperatur mittels SVG gemalt. Um die Dateien einzubinden, muss man einfach bei aktiviertem Onewiresupport den Webserver und das Datei Inlining aktivieren. Die Dateien können dann unter ow.ht bzw. unter Xow.ht angezeigt werden. Das Beispiel zeigt die SVG-Version mit Naming-Support: [[File:onewire-svg.png]] = Anschluss AVR-NET-IO = Für das Pollin AVR-NET-IO Board können die Sensoren DS18S20+ , normal Betrieb [[File:netio-1wire_normal.png]] parasitären Modus [[File:netio-1wire.png]] Anmerkung: Wenn man beim Net-IO nicht alle Analogeingänge benötigt, lässt sich der 1-Wire-Bus auch an der Schraubklemme ADC1 ganz gut aufschalten. Vorteil ist, dass man gleich alle passenden Spannungen (GND, +5V) an den beiden nebenliegenden Schraubklemmen hat. Das Pinning muss dann entspechend in der kann in der Datei pinning/hardware/netio.m4 von PD6 auf PA4 geändert werden. Vorteil dieser Konfiguration ist, dass man den DB-25-Verbinder zum Anschluss der Relaisplatine K8IO von Pollin frei hat und den EXT Steckverbinder zum Anschluss eines LCD über ein 4bit-Interface nutzen kann, ohne die Erweiterungsplatine von Pollin zu benötigen. Pinbelegung: [[File:ds18s20-par-pinout.jpg]] = Anschluss Etherrape = Die Schaltung je nach parasitärem oder normalem Betriebsmodus kann aus der NetIO Skizze übernommen werden. Data liegt auf PORTD an Pin 7: PORTD +---+ |x x| |x X| <- Pin 7 |x x |x x| |x x| +---+ Direkt neben PORTD befinden sich 2 Pins mit GND und 5V als Beschriftung. GND kann als GND und 5V als Vcc genutzt werden. = Einbindung in [[Control6]] = Die Sensoren können mit '''ONEWIRE_GET''' einfach abgefragt werden. Die Funktion führt automatisch ein ''convert'' aus, es sind also keine zwei Schritte erforderlich wie bei dem Zugriff über [[ECMD]]. Die Rückgabe erfolgt (analog der Funktion '''KTY_GET''') in Centigrad, also Temperatur * 10. Hier vielleicht ein kleines Beispiel, das die Daten per [[SYSLOG]] ausgibt sobald sich die Temperatur um mehr als ein Grad zur letzten Messung verändert hat. <pre> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO div_t res = div(Temperatur,10); SYSLOG("temperature changed %d.%d",res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> = Abfrage per [[SNMP]] = Falls Polling-Support aktiviert wurde können die Sensorwerte per SNMP abgefragt werden. Mit Naming-Support stehen auch die Namen per SNMP zur Verfügung und die Index-Nummern sind fix auf die Position in der Namenstabelle festgelegt. Dies ist sehr hilfreich, um bestimmte Sensoren über den SNMP-Index anzusprechen. Es gibt folgende OIDs: * .1.3.6.1.4.1.2021.13.23.3.1.<idx> : ROM-Code des Sensors * .1.3.6.1.4.1.2021.13.23.3.2.<idx> : Sensor-Name (nur mit Naming-Support) * .1.3.6.1.4.1.2021.13.23.3.3.<idx> : Temperaturwert in Centigrad * .1.3.6.1.4.1.2021.13.23.3.4.<idx> : 0 = Sensor nicht vorhanden, 1 = Sensor vorhanden Hier ein Beispiel: <pre> # snmpwalk -Osn -c public -v 1 192.168.255.90 1.3.6.1.4.1.2021.13.23.3 .1.3.6.1.4.1.2021.13.23.3.1.0 = STRING: "1080cff6010800f9" .1.3.6.1.4.1.2021.13.23.3.1.1 = STRING: "10c8cff60108002d" .1.3.6.1.4.1.2021.13.23.3.1.2 = STRING: "1029f6dc0108002f" .1.3.6.1.4.1.2021.13.23.3.1.3 = STRING: "10f2d0f60108001c" .1.3.6.1.4.1.2021.13.23.3.1.4 = STRING: "105a17f70108001d" .1.3.6.1.4.1.2021.13.23.3.1.5 = STRING: "10b8d8f601080098" .1.3.6.1.4.1.2021.13.23.3.1.6 = STRING: "104dedf601080057" .1.3.6.1.4.1.2021.13.23.3.1.7 = STRING: "10011af701080027" .1.3.6.1.4.1.2021.13.23.3.1.8 = STRING: "0000000000000000" .1.3.6.1.4.1.2021.13.23.3.1.9 = STRING: "0000000000000000" .1.3.6.1.4.1.2021.13.23.3.2.0 = STRING: "kessel" .1.3.6.1.4.1.2021.13.23.3.2.1 = STRING: "warmwasser" .1.3.6.1.4.1.2021.13.23.3.2.2 = STRING: "aussen" .1.3.6.1.4.1.2021.13.23.3.2.3 = STRING: "speicher" .1.3.6.1.4.1.2021.13.23.3.2.4 = STRING: "heizung vl" .1.3.6.1.4.1.2021.13.23.3.2.5 = STRING: "heizung rl" .1.3.6.1.4.1.2021.13.23.3.2.6 = STRING: "boiler vl" .1.3.6.1.4.1.2021.13.23.3.2.7 = STRING: "boiler rl" .1.3.6.1.4.1.2021.13.23.3.2.8 = "" .1.3.6.1.4.1.2021.13.23.3.2.9 = "" .1.3.6.1.4.1.2021.13.23.3.3.0 = INTEGER: 334 .1.3.6.1.4.1.2021.13.23.3.3.1 = INTEGER: 467 .1.3.6.1.4.1.2021.13.23.3.3.2 = INTEGER: 127 .1.3.6.1.4.1.2021.13.23.3.3.3 = INTEGER: 185 .1.3.6.1.4.1.2021.13.23.3.3.4 = INTEGER: 318 .1.3.6.1.4.1.2021.13.23.3.3.5 = INTEGER: 269 .1.3.6.1.4.1.2021.13.23.3.3.6 = INTEGER: 366 .1.3.6.1.4.1.2021.13.23.3.3.7 = INTEGER: 291 .1.3.6.1.4.1.2021.13.23.3.3.8 = INTEGER: 0 .1.3.6.1.4.1.2021.13.23.3.3.9 = INTEGER: 0 .1.3.6.1.4.1.2021.13.23.3.4.0 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.1 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.2 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.3 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.4 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.5 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.6 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.7 = INTEGER: 1 .1.3.6.1.4.1.2021.13.23.3.4.8 = INTEGER: 0 .1.3.6.1.4.1.2021.13.23.3.4.9 = INTEGER: 0 </pre> = Codebeispiele = * [[Onewire/Example/PHP (Deutsch) | PHP]] * [[Onewire/Example/Perl (Deutsch) | Perl]] * [[Onewire/Example/Python | Python]] * [[Onewire/Example/Shell | sh/bash]] [[Category:Ethersex]] [[Category:StepByStep]] [[Category:Onewire]] = Bezugsquellen = * Laut Michael Schultz (k1w1) hat er immer DS1820 auf Lager und kann sie sehr günstig weiterverkaufen. Auch Mindermengen. Mail: ethersex [AT] keyb [DOT] de 8a6c2e0292a631621b38c48608f436f4a48ad1bd 6 190 487 2012-04-14T09:10:20Z Sittner 461 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 191 488 2012-04-14T09:10:39Z Sittner 461 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 192 489 2012-04-14T09:10:50Z Sittner 461 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 193 490 2012-04-14T09:11:04Z Sittner 461 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 198 502 2012-04-15T23:13:58Z Mgue 312 taken from [[Onewire]] wikitext text/x-wiki {{i18n|Onewire/Example/Shell}} Einfaches SH (Linux Shell) Script von stesie (irc) zum Auslesen von einem Wert (udp support muss enabled sein oder option -u nicht verwenden!) <source lang="bash"> #! /bin/sh SENSORID=10529f7001080016 #ESEXIP=2001:6f8:1209:23:42::17 #IPv6 Adresse ESEXIP=192.168.255.90 #IPv6 #echo 1w convert $SENSORID | nc6 -u $ESEXIP 2701 -q 1 2>/dev/null | grep -qe OK || exit 1 #echo 1w get $SENSORID | nc6 -u $ESEXIP 2701 -q 1 2>/dev/null | sed -e 's/Temperatur: //' #IPv4 echo 1w convert $SENSORID | nc -u $ESEXIP 2701 -q 1 2>/dev/null | grep -qe OK || exit 1 echo 1w get $SENSORID | nc -u $ESEXIP 2701 -q 1 2>/dev/null | sed -e 's/Temperatur: //' </source> bash Script von Tron12 zum Auslesen aller Werte (Achtung Port 2701 ist nicht standard!! Sowie udp support muss enabled sein oder option -u nicht verwenden!) <source lang="bash"> #! /bin/sh # # netcat-openbsd 1.89-3ubuntu2 NETIOIP="-4 192.168.178.249" #für IPv6: #NETIOIP="-6 2001:6f8:1209:23:42::17" NETIOPORT="2702" N_DATE=`echo date | nc -u $NETIOIP $NETIOPORT -q 1 ` N_GET_ID=`echo 1w list | nc -u $NETIOIP $NETIOPORT -q 1 | grep -qe OK || exit 1` echo "Date: $N_DATE" echo "---------------------------------" for i in $N_GET_ID do tmp=`echo 1w convert $i | nc -u $NETIOIP $NETIOPORT -q 1 2>/dev/null | grep -qe OK || exit 1` tmp=`echo 1w get $i | nc -u $NETIOIP $NETIOPORT -q 1 2>/dev/null ` echo "Sensor: $i :: $tmp" done </source> 8e720f406848b3d51a5b25c1a9c2a0f3a5353130 0 138 505 419 2012-04-18T07:40:12Z Rayofhope 20 udp protocol wikitext text/x-wiki {{i18n|StellaLight}} {{Module |NAME=StellaLight |MENUCONFIG={{Applications}}->StellaLight: Multichannel pwm |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |DEPENDS=[[DMX Storage]] (optional), udpStella (optional) |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/services/stella https://github.com/ethersex/ethersex/tree/master/services/stella] }} StellaLight produces PWM signals on up to 16 independent pins for driving LEDs or servo motors. == Internals == Stella uses an 8-bit Timer of your choice for producing the PWM signals. Since the overflow interrupts need to be very consistent, StellaLight will not work flawlessy when other modules are active that disable the interrupts for a short amount of time. This is a list of module where you can expect some problems with: [[Onewire]], [[RFM12]] (please add more if you find some). Moreover StellaLight does not support [http://en.wikipedia.org/wiki/Gamma_correction Gamma Correction] since that would require at least 10-12 bit PWM. == Configuration == In Menuconfig you can select the prescaler. '''The higher the frequency, the more often the StellaLight PWM functions will be executed, leading to an higher overall load of the device. So if you run into problems, try decreasing the frequency, ergo increase the prescaler.''' {| border="1" ! Option ! Prescaler |- | Very slow | 1024 |- | Slow | 256 |- | Normal | 128 |- | Fast | 64 |- |} You can calculate the resulting frequency by using this formula: F_CPU: The clockspeed of your AVR (like 8Mhz, 16Mhz etc.) ''F_STELLA=F_CPU/Prescaler/512'' So given a setting of "Normal" on a 16Mhz device will result in '''244Hz''' which is pretty good for most setups. So more than enough for the human eye (10 times more) If you have enabled [[DMX Storage]] in Menuconfig, you also can set the universe and start channel of StellaLight, so you can control StellaLight via [[Artnet]] or [[DMX FXSlot]]. == Pinning == {| border="1" |- | STELLA_PORT1_RANGE(PX'''I''',PX'''J''') | sets the range ('''I''' to '''J''') of StellaLight controlled pins on PORTX |- | STELLA_PORT2_RANGE(PX2'''I''',PX2'''J''') | sets the range ('''I''' to '''J''') of StellaLight controlled pins on PORTX2 |- | STELLA_USE_TIMER('''I''') | programs Timer'''I''' for StellaLight |- |} Two examples: '''1. 3 LEDs (e.g. RGB) on PORTA, Pins: 0,1,2''' <source lang="c"> ifdef(`conf_STELLA', `dnl STELLA_PORT1_RANGE(PA0,PA2) STELLA_USE_TIMER(2) ')dnl </source> '''2. 15 LEDs (e.g. 5x RGB) on PORTA, Pins: 0,1,2,3,4,5,6,7 on PORTD, Pins: 0,1,2,3,4,5,6''' <source lang="c" > ifdef(`conf_STELLA', `dnl STELLA_PORT1_RANGE(PA0,PA7) STELLA_PORT2_RANGE(PD0,PD6) STELLA_USE_TIMER(2) ')dnl </source> == udp control == We recommend to use the [[DMX Storage]]. But for easy set ups it is possible to use a simple udp protocol to control stella channels. Activate protocols->udpStella and configure the port. A datagram for stella has three bytes: {| border="1" ! Byte # ! Semantic ! Valid values |- | 1 | Command Byte | STELLA_SET_IMMEDIATELY=0, STELLA_SET_FADE=1, STELLA_SET_FLASHY=2, STELLA_SET_IMMEDIATELY_RELATIVE=3, STELLA_SET_FADESTEP=4, STELLA_GETALL = 255 |- | 2 | Channel | 0-15 |- | 3 | Value | 0-255 |- |} == Alternative == Have a look at [[Starburst]] for an improved and more resource-conserving solution. [[Category:e6la]] f6624a3ed9657caca762f21c1d2a142ada7cd7e6 506 505 2012-04-18T07:44:28Z Rayofhope 20 /* udp control */ wikitext text/x-wiki {{i18n|StellaLight}} {{Module |NAME=StellaLight |MENUCONFIG={{Applications}}->StellaLight: Multichannel pwm |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |DEPENDS=[[DMX Storage]] (optional), udpStella (optional) |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/services/stella https://github.com/ethersex/ethersex/tree/master/services/stella] }} StellaLight produces PWM signals on up to 16 independent pins for driving LEDs or servo motors. == Internals == Stella uses an 8-bit Timer of your choice for producing the PWM signals. Since the overflow interrupts need to be very consistent, StellaLight will not work flawlessy when other modules are active that disable the interrupts for a short amount of time. This is a list of module where you can expect some problems with: [[Onewire]], [[RFM12]] (please add more if you find some). Moreover StellaLight does not support [http://en.wikipedia.org/wiki/Gamma_correction Gamma Correction] since that would require at least 10-12 bit PWM. == Configuration == In Menuconfig you can select the prescaler. '''The higher the frequency, the more often the StellaLight PWM functions will be executed, leading to an higher overall load of the device. So if you run into problems, try decreasing the frequency, ergo increase the prescaler.''' {| border="1" ! Option ! Prescaler |- | Very slow | 1024 |- | Slow | 256 |- | Normal | 128 |- | Fast | 64 |- |} You can calculate the resulting frequency by using this formula: F_CPU: The clockspeed of your AVR (like 8Mhz, 16Mhz etc.) ''F_STELLA=F_CPU/Prescaler/512'' So given a setting of "Normal" on a 16Mhz device will result in '''244Hz''' which is pretty good for most setups. So more than enough for the human eye (10 times more) If you have enabled [[DMX Storage]] in Menuconfig, you also can set the universe and start channel of StellaLight, so you can control StellaLight via [[Artnet]] or [[DMX FXSlot]]. == Pinning == {| border="1" |- | STELLA_PORT1_RANGE(PX'''I''',PX'''J''') | sets the range ('''I''' to '''J''') of StellaLight controlled pins on PORTX |- | STELLA_PORT2_RANGE(PX2'''I''',PX2'''J''') | sets the range ('''I''' to '''J''') of StellaLight controlled pins on PORTX2 |- | STELLA_USE_TIMER('''I''') | programs Timer'''I''' for StellaLight |- |} Two examples: '''1. 3 LEDs (e.g. RGB) on PORTA, Pins: 0,1,2''' <source lang="c"> ifdef(`conf_STELLA', `dnl STELLA_PORT1_RANGE(PA0,PA2) STELLA_USE_TIMER(2) ')dnl </source> '''2. 15 LEDs (e.g. 5x RGB) on PORTA, Pins: 0,1,2,3,4,5,6,7 on PORTD, Pins: 0,1,2,3,4,5,6''' <source lang="c" > ifdef(`conf_STELLA', `dnl STELLA_PORT1_RANGE(PA0,PA7) STELLA_PORT2_RANGE(PD0,PD6) STELLA_USE_TIMER(2) ')dnl </source> == udp control == We recommend to use the [[DMX Storage]]. But for easy set ups it is possible to use a simple udp protocol to control stella channels. Activate protocols->udpStella and configure the port. A datagram for stella has three bytes: {| border="1" ! Byte # ! Semantic ! Valid values |- | 1 | Command Byte | STELLA_SET_IMMEDIATELY=0, STELLA_SET_FADE=1, STELLA_SET_FLASHY=2, STELLA_SET_IMMEDIATELY_RELATIVE=3, STELLA_SET_FADESTEP=4, STELLA_GETALL = 255 |- | 2 | Channel | 0-15 |- | 3 | Value | 0-255 |- |} You will get back an UDP datagram if you send the STELLA_GETALL command. It consists of an identifier ["STELLA"]+[Amount of channels]+[channel#1]+..+[channel#n] == Alternative == Have a look at [[Starburst]] for an improved and more resource-conserving solution. [[Category:e6la]] ebe1b5b2bfd2ea19450f1722a02ff7e96a8ee9e6 0 5 511 304 2012-04-22T23:44:39Z Mgue 312 changed structure wikitext text/x-wiki {{i18n|Main Page}} {{NewWiki}} == Welcome to ethersex.de - the universal AVR firmware == {|style="width:100%;" |style="width:33%;"|{{Facts}} |style="width:33%;vertical-align:baseline;height:100%"|{{Getting Started}} |style="width:33%;vertical-align:baseline;height:100%"|{{Documentation}} |- |} 51c594a36adb4c230b648eabad4ebe5c25ae16eb 0 57 512 313 2012-04-22T23:45:31Z Mgue 312 changed structure wikitext text/x-wiki {{i18n|Main Page}} {{NewWiki (Deutsch)}} == Willkommen bei ethersex.de - der universalen AVR Firmware == {|style="width:100%;" |style="width:33%;"|{{Facts (Deutsch)}} |style="width:33%;vertical-align:baseline;height:100%"|{{Getting Started (Deutsch)}} |style="width:33%;vertical-align:baseline;height:100%"|{{Documentation (Deutsch)}} |- |} 770a2b33aa3e609090e4422cfdc8d9888b63837e 0 38 514 106 2012-04-24T17:28:19Z Mgue 312 description wikitext text/x-wiki {{i18n|Community}} = Mailing lists = *[http://list.zerties.org/cgi-bin/mailman/listinfo/ethersex-devel ethersex-devel] '''Discussion, Feature Request, Problems.''' Post your questions in German or English *[https://list.zerties.org/cgi-bin/mailman/listinfo/ethersex-commit ethersex-commit] '''Do not send messages to this list''' This list is read-only. Subscribe to this list if you want to be notified about changes in the code. = IRC = You can find us on [irc://freenode.net/#ethersex #ethersex] (freenode.net) If you have any questions...just ask! If no one answers right away - don't take it personally. We might just be away from keyboard. Just stick around for some time. c5d161a3df455944b9bb3234e6871dd3784f22e0 2 204 516 2012-05-01T08:16:35Z Tkaltenbrunner 475 Created page with "== Über mich == Mein Background sind ein Studium der Informatik und mehr als 20 Jahre SW-Entwicklung. C und die andere hier eingesetzten SW-Techniken habe ich allerdings nur gel…" wikitext text/x-wiki == Über mich == Mein Background sind ein Studium der Informatik und mehr als 20 Jahre SW-Entwicklung. C und die andere hier eingesetzten SW-Techniken habe ich allerdings nur gelegentlich oder gar nicht genutzt. Microprozessor basierte Systeme kenne ich bisher nur aus der z.T. engen Zusammenarbeit mit der benachbarten HW-Abteilung bei meinem Arbeitgeber. Dadurch sind mir ein paar Ideen und Grundlagen der Microprozessorprogrammierung bekannt - ohne dabei jedoch praktische Erfahrung gesammelt zu haben. == Motivation == Durch die Verfügbarkeit von preiswerten Microcontrollerschaltungen mit Netzwerk-Anbindung ist bei mir die Idee gewachsen auch mal ein solches Gerät mir zu besorgen und damit die eine oder andere Idee, die sich bei mir im Hinterkopf angesammelt haben und auf Verwirklichung warten umzusetzen. Diese lagen insbesondere im Bereich der Lichtsteuerung. Nach ein paar Recherchen in diesem Bereich habe ich das preiswerte AVR-NET-IO-Board von Pollin gefunden. Da klar war, dass ich mit der vorkonfigurierten Firmware nicht die Dinge umsetzen kann, die ich vor hatte, ist mit dem umfangreichen Firmware-Projekt Ethersex die nächste Wahl getroffen worden, da es schon eine Menge mitbringt, was man nur geschickt kombinieren muss ... Außerdem denke ich, dass man auch in der Firmware entwicklung nicht bei Null anfangen sollte, sondern auf einer gewissen Basis aufsetzen sollte, die die gesammelte Erfahrung andere Entwickler enthält. Da es für mich wichtig st die Dinge richtig zu versehen, habe ich mich entschlossen, die Erkenntnisse, die ich beim Studium der Ethersex Quellen gewinne, als Doku in das Wiki einfließen zu lassen. 0c68871d78cc206ba84e1bffef6d9cb18b4ef3c1 517 516 2012-05-01T08:47:17Z Tkaltenbrunner 475 wikitext text/x-wiki == Über mich == Mein Background sind ein Studium der Informatik und mehr als 20 Jahre SW-Entwicklung. C und die andere hier eingesetzten SW-Techniken habe ich allerdings nur gelegentlich oder gar nicht genutzt. Microprozessor basierte Systeme kenne ich bisher nur aus der z.T. engen Zusammenarbeit mit der benachbarten HW-Abteilung bei meinem Arbeitgeber. Dadurch sind mir ein paar Ideen und Grundlagen der Microprozessorprogrammierung bekannt - ohne dabei jedoch praktische Erfahrung gesammelt zu haben. == Motivation == Durch die Verfügbarkeit von preiswerten Microcontrollerschaltungen mit Netzwerk-Anbindung ist bei mir die Idee gewachsen auch mal ein solches Gerät mir zu besorgen und damit die eine oder andere Idee, die sich bei mir im Hinterkopf angesammelt haben und auf Verwirklichung warten umzusetzen. Diese lagen insbesondere im Bereich der Lichtsteuerung. Nach ein paar Recherchen in diesem Bereich habe ich das preiswerte AVR-NET-IO-Board von Pollin gefunden. Da klar war, dass ich mit der vorkonfigurierten Firmware nicht die Dinge umsetzen kann, die ich vor hatte, ist mit dem umfangreichen Firmware-Projekt Ethersex die nächste Wahl getroffen worden, da es schon eine Menge mitbringt, was man nur geschickt kombinieren muss ... Außerdem denke ich, dass man auch in der Firmware entwicklung nicht bei Null anfangen sollte, sondern auf einer gewissen Basis aufsetzen sollte, die die gesammelte Erfahrung andere Entwickler enthält. Da es für mich wichtig st die Dinge richtig zu versehen, habe ich mich entschlossen, die Erkenntnisse, die ich beim Studium der Ethersex Quellen gewinne, als Doku in das Wiki einfließen zu lassen. == About me == I studied computer science and have more than 20 years expierence in SW developement. C and other used SW techniques I did not use very often. Microprocessor based systems I knew from a some times tide colaboration with the HW departement of my my employer. Because of this I knew some of the ideas and basics of microprocessor programming - but till now I don't have gained any practical expierience. == Motivation == Because of the availibilty of cheap microcontroller boards with network connection I got the wish to get such a kind of board to realize one or the other idea which has grown in my head over the time. I wanted mainly to do some light control. After some inverstigation in this area I found the cheap AVR-NET-IO board from Pollin. Of course the installed firmware could not do the things I wanted the board to do, so I looked for a firmware project which supports the board and I choose Ethersex, because it contains so much already, which has to be combined smartly ... Furthermore I think, also firmware development should not start from scratch, instead it should start on a good base, which contains already the collected developer expirience. It is important for me to understand things right, so I decided to fill this Wiki with my insights, I will find while studying and working with Ethersex. 36674384a4f6abfc1f8b6a841e9211d465637957 0 154 518 388 2012-05-01T08:58:19Z Tkaltenbrunner 475 wikitext text/x-wiki {{i18n|Protokolle duplizieren}} = Protokolle duplizieren = Es kommt immer mal wider vor, das man das gleiche Protokoll zweimal benötigt. Bei mir war der Fall, das ich ein Net-IO mit einem ATMega 644p ausgestattet habe, der zwei UART besitz. Diese zwei Schnittstellen wollte ich zum auslesen meiner Wechselrichter nutzen. Das Protokoll der Wahl war bei mir sll (serial_line_log) Leider muste ich feststellen, das ich immer nur ein Protokoll auf ein UART binden kann. Da es bist jetzt noch keine gute Idee gibt, wie man so etwas besser lösen kann, hier ein kleiner Trick. Das Protokoll serial_line_log wird einfach dupliziert. Ich habe jedes "seria_" in ein "serialzwei_" gewandelt. * Kopieren des Ordners (cp -a ethersex/protocols/serial_line_log ethersex/protocols/serialzwei_line_log) * alle Dateien im Ordner umbenannt (auser Makefile und config.in) (cd ethersex/protocols/serialzwei_line_log; mv serial_<...>.c serialzwei_<...>.c * mit einem Editor Alle Variabeln und Symbolenamen geändert <code> vim serialzwei_line_log.c :%s/SERIAL_/SERIALZWEI_/g :%s/serial_/serialzwei_/g :%s/sll_/sllzwei_/g </code> * in der serialzwei_line_log_ecmd.c muss noch der ecmd Befehl angepasst werden (ganz am Schluss der META abschnitt) <code> vim serialzwei_line_log_ecmd.c :%s/sll get/sll2 get :%s/sll_/sllzwei_/g </code> * in der protocols/serialzwei_line_log/config.in die Namen anpassen <code> vim config.in :%s/LINE_/LINE2_/g :%s/Line/Line2/g </code> * die ethersex/config.in und das MAKEFILE an die neuen Namen anpassen Zum Schluss müssen noch zwei zentrale Dateien angepasst werden. <code> cd ethersex/ vim Makefile SUBDIRS += protocols/serialzwei_line_log </code> <code> vim config.in source protocols/serialzwei_line_log/config.in </code> Danach sollte <code> make menuconfig </code> Jetzt sollte unter Protokolle das Serial Line Log zweimal vorhanden sein. Anmerkung: Das gleiche Verfahren funktioniert auch mit dem yport-Protokoll. Wenn man z.B. einen ATMega644p besitzt und beide UARTs "gleichzeitig" benutzen will, kann man das yport-Protokoll mit dem hier vorgestellten Verfahren duplizieren. nc <ip> 7970 bzw nc <ip> 7971 liefert dann die Ausgabe der beiden Ports. [[Category:Development]] 7860a810b1d3707a81d6146a978cc086985cdabb 0 205 519 2012-05-01T09:13:02Z Tkaltenbrunner 475 Created page with "{{i18n|TITLE}} [[Category:Developement]]" wikitext text/x-wiki {{i18n|TITLE}} [[Category:Developement]] bb674f2faed981e0f5efd969797a3591bcb42b59 520 519 2012-05-01T09:13:31Z Tkaltenbrunner 475 wikitext text/x-wiki {{i18n|TITLE}} [[Category:Development]] f138da3e4a57f9386ce446803191b2da84e2f5e7 523 520 2012-05-01T09:18:05Z Tkaltenbrunner 475 wikitext text/x-wiki {{i18n|TITLE}} == Intro == This page will explain some of the details behind menuconfig. It is meant for developers who want o look behind the curtain or if you want debug a modul which does not work or compile any more .... [[Category:Development]] 13acc20af1723fc13daaa59b26a1c8b594c7408c 524 523 2012-05-01T09:20:32Z Tkaltenbrunner 475 wikitext text/x-wiki {{i18n|Template:i18n}} == Intro == This page will explain some of the details behind menuconfig. It is meant for developers who want o look behind the curtain or if you want debug a modul which does not work or compile any more .... [[Category:Development]] 4cd06d55f5e170d71502e554554283361f926af1 525 524 2012-05-01T09:21:29Z Tkaltenbrunner 475 wikitext text/x-wiki {{i18n|Configuration of Boards and Pins:i18n}} == Intro == This page will explain some of the details behind menuconfig. It is meant for developers who want o look behind the curtain or if you want debug a modul which does not work or compile any more .... [[Category:Development]] 9ad6b9ce2ecbfa638d03e234a1c5268a835dd80c 526 525 2012-05-01T09:22:30Z Tkaltenbrunner 475 wikitext text/x-wiki {{i18n|Configuration of Boards and Pins}} == Intro == This page will explain some of the details behind menuconfig. It is meant for developers who want o look behind the curtain or if you want debug a modul which does not work or compile any more .... [[Category:Development]] b23e03c7f17084f4b0a25c9ae5ba5fe6c30f5c3e 527 526 2012-05-01T09:38:19Z Tkaltenbrunner 475 wikitext text/x-wiki {{i18n|Configuration of Boards and Pins}} == Intro == This page will explain some of the details behind menuconfig. It is meant for developers who want to look behind the curtain or if someone wants to debug a modul which does not work or compile any more .... == make menuconfig == May be someone can explain how to add or extend the menuconfig system - here a look at the results and the output of menuconfig. The configuration is saved in two different formats: * file .config for the menuconfig itself - ** it is used for including it into the makefile ** definition auf makefile variables * file autoconfig.h - ** it is for including it in the compilation ** definition of C preprocessor macros and defines I thing the details of the configuration should become clear after doing the menuconfig and reading about the modules. == make == The first steps in the build process are to get all the configuration information and build some source files which put it all together. === meta.m4 === === pinning.c === === meta.h === [[Category:Development]] 96509197461e04e89e8b831f8679680d321157a7 528 527 2012-05-01T09:40:09Z Tkaltenbrunner 475 /* make menuconfig */ wikitext text/x-wiki {{i18n|Configuration of Boards and Pins}} == Intro == This page will explain some of the details behind menuconfig. It is meant for developers who want to look behind the curtain or if someone wants to debug a modul which does not work or compile any more .... == make menuconfig == May be someone can explain how to add or extend the menuconfig system - here a look at the results and the output of menuconfig. The configuration is saved in two different formats: * file .config for the menuconfig itself - ** it is used for including it into the makefile ** definition auf makefile variables * file autoconfig.h - ** it is for including it in the compilation ** definition of C preprocessor macros and defines I thing the details of the configuration should become clear after doing the menuconfig and reading about the modules. May be I can explain some "core" configuration later. == make == The first steps in the build process are to get all the configuration information and build some source files which put it all together. === meta.m4 === === pinning.c === === meta.h === [[Category:Development]] 85efe956ae73eda31c924cced7f46b6acbd52171 529 528 2012-05-01T09:44:29Z Tkaltenbrunner 475 /* make */ wikitext text/x-wiki {{i18n|Configuration of Boards and Pins}} == Intro == This page will explain some of the details behind menuconfig. It is meant for developers who want to look behind the curtain or if someone wants to debug a modul which does not work or compile any more .... == make menuconfig == May be someone can explain how to add or extend the menuconfig system - here a look at the results and the output of menuconfig. The configuration is saved in two different formats: * file .config for the menuconfig itself - ** it is used for including it into the makefile ** definition auf makefile variables * file autoconfig.h - ** it is for including it in the compilation ** definition of C preprocessor macros and defines I thing the details of the configuration should become clear after doing the menuconfig and reading about the modules. May be I can explain some "core" configuration later. == make == The first steps in the build process are to get all the configuration information and build some source files which put it all together. Besides some usual unix tools like sed the m4 macro processor plays an important role. Even if it is not in the scope of this wiki, I added a very short intro here: [[m4 - very short intro]] === meta.m4 === === pinning.c === === meta.h === [[Category:Development]] d6292a9da6e9b0ffd183ebdb0d5f6ad01c216779 538 529 2012-05-01T10:37:23Z Tkaltenbrunner 475 /* meta.m4 */ wikitext text/x-wiki {{i18n|Configuration of Boards and Pins}} == Intro == This page will explain some of the details behind menuconfig. It is meant for developers who want to look behind the curtain or if someone wants to debug a modul which does not work or compile any more .... == make menuconfig == May be someone can explain how to add or extend the menuconfig system - here a look at the results and the output of menuconfig. The configuration is saved in two different formats: * file .config for the menuconfig itself - ** it is used for including it into the makefile ** definition auf makefile variables * file autoconfig.h - ** it is for including it in the compilation ** definition of C preprocessor macros and defines I thing the details of the configuration should become clear after doing the menuconfig and reading about the modules. May be I can explain some "core" configuration later. == make == The first steps in the build process are to get all the configuration information and build some source files which put it all together. Besides some usual unix tools like sed the m4 macro processor plays an important role. Even if it is not in the scope of this wiki, I added a very short intro here: [[m4 - very short intro]] === meta.m4 === If you have look at the different source codes of the modules, you find at the bottom of the main c-file a comment section starting with "-- Ethersex META --". You find there m4 macros which are used to integrate the modul into the main program of ethersex. Details later. meta.m4 is the extraction and collection of these sections. === pinning.c === === meta.h === [[Category:Development]] e3e063be7c0c4f0a791d404670fa0c9a6fecd249 539 538 2012-05-01T11:20:09Z Tkaltenbrunner 475 /* meta.m4 */ wikitext text/x-wiki {{i18n|Configuration of Boards and Pins}} == Intro == This page will explain some of the details behind menuconfig. It is meant for developers who want to look behind the curtain or if someone wants to debug a modul which does not work or compile any more .... == make menuconfig == May be someone can explain how to add or extend the menuconfig system - here a look at the results and the output of menuconfig. The configuration is saved in two different formats: * file .config for the menuconfig itself - ** it is used for including it into the makefile ** definition auf makefile variables * file autoconfig.h - ** it is for including it in the compilation ** definition of C preprocessor macros and defines I thing the details of the configuration should become clear after doing the menuconfig and reading about the modules. May be I can explain some "core" configuration later. == make == The first steps in the build process are to get all the configuration information and build some source files which put it all together. Besides some usual unix tools like sed the m4 macro processor plays an important role. Even if it is not in the scope of this wiki, I added a very short intro here: [[m4 - very short intro]] === meta.m4 === If you have look at the different source codes of the modules, you find at the bottom of the main c-file a comment section starting with "-- Ethersex META --". You find there m4 macros which are used to integrate the modul into the main program of ethersex. Details later. meta.m4 is the extraction and collection of these sections. === meta.c === Is generated by m4 macros. The inputs are: (controlled centrally in the Makefile!) * autoconfig.h *: is converted and each define line results into one m4 command line parameter of the form -Dconf_<parname> * scripts/meta_magic.m4 *: contains the framework for meta.c * protocols/ecmd/ecmd_magic.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * protocols/soap/soap_magic.m4 *: only if SOAP support is activated - make var $(SOAP_SUPPORT) must be set to "y" * meta.m4 *: see above * protocols/ecmd/ecmd_defs.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced thru the make var ${named_pin_simple_files} *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced thru the make var $(y_NP_SIMPLE_META_SRC) *: unconditional ... but contain the following files, if ECMD parser or SOAP support is activated: ** protocols/ecmd/ecmd_defs.m4 ** ${named_pin_simple_files} *: so I think it could be a small bug - if ECMD parser support is on, the files are added twice - may be this does not matter. === pinning.c === === meta.h === [[Category:Development]] 37dd590590b1ecdf2c2c8ede22ebed0a3a8d1843 540 539 2012-05-01T11:30:12Z Tkaltenbrunner 475 /* meta.m4 */ wikitext text/x-wiki {{i18n|Configuration of Boards and Pins}} == Intro == This page will explain some of the details behind menuconfig. It is meant for developers who want to look behind the curtain or if someone wants to debug a modul which does not work or compile any more .... == make menuconfig == May be someone can explain how to add or extend the menuconfig system - here a look at the results and the output of menuconfig. The configuration is saved in two different formats: * file .config for the menuconfig itself - ** it is used for including it into the makefile ** definition auf makefile variables * file autoconfig.h - ** it is for including it in the compilation ** definition of C preprocessor macros and defines I thing the details of the configuration should become clear after doing the menuconfig and reading about the modules. May be I can explain some "core" configuration later. == make == The first steps in the build process are to get all the configuration information and build some source files which put it all together. Besides some usual unix tools like sed the m4 macro processor plays an important role. Even if it is not in the scope of this wiki, I added a very short intro here: [[m4 - very short intro]] === meta.m4 === If you have look at the different source codes of the modules, you find at the bottom of the main c-file a comment section starting with "-- Ethersex META --". You find there m4 macros which are used to integrate the modul into the main program of ethersex. Details later. meta.m4 is the extraction and collection of these sections. The files which are used, are denfined by the makefile of each "module". Each C source files has to be added to the make var "y_SRC". A nice trick is used there by the use of ".config", where all the used and configured feature are assigned a "y" to make vars. i.e. MODULX_GENERAL_SUPPORT=y Then in the makefile of ModuleX: $(MODULX_GENERAL_SUPPORT)_SRC += file1.c file2.c ... If the module is not activated the files added to _SRC instaeda of y_SRC. === meta.c === Is generated by m4 macros. The inputs are: (controlled centrally in the Makefile!) * autoconfig.h *: is converted and each define line results into one m4 command line parameter of the form -Dconf_<parname> * scripts/meta_magic.m4 *: contains the framework for meta.c * protocols/ecmd/ecmd_magic.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * protocols/soap/soap_magic.m4 *: only if SOAP support is activated - make var $(SOAP_SUPPORT) must be set to "y" * meta.m4 *: see above * protocols/ecmd/ecmd_defs.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced thru the make var ${named_pin_simple_files} *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced thru the make var $(y_NP_SIMPLE_META_SRC) *: unconditional ... but contain the following files, if ECMD parser or SOAP support is activated: ** protocols/ecmd/ecmd_defs.m4 ** ${named_pin_simple_files} *: so I think it could be a small bug - if ECMD parser support is on, the files are added twice - may be this does not matter. === pinning.c === === meta.h === [[Category:Development]] a4a1b58e23d1637826da47829cf4a21bbb127f46 541 540 2012-05-01T11:30:45Z Tkaltenbrunner 475 /* meta.m4 */ wikitext text/x-wiki {{i18n|Configuration of Boards and Pins}} == Intro == This page will explain some of the details behind menuconfig. It is meant for developers who want to look behind the curtain or if someone wants to debug a modul which does not work or compile any more .... == make menuconfig == May be someone can explain how to add or extend the menuconfig system - here a look at the results and the output of menuconfig. The configuration is saved in two different formats: * file .config for the menuconfig itself - ** it is used for including it into the makefile ** definition auf makefile variables * file autoconfig.h - ** it is for including it in the compilation ** definition of C preprocessor macros and defines I thing the details of the configuration should become clear after doing the menuconfig and reading about the modules. May be I can explain some "core" configuration later. == make == The first steps in the build process are to get all the configuration information and build some source files which put it all together. Besides some usual unix tools like sed the m4 macro processor plays an important role. Even if it is not in the scope of this wiki, I added a very short intro here: [[m4 - very short intro]] === meta.m4 === If you have look at the different source codes of the modules, you find at the bottom of the main c-file a comment section starting with "-- Ethersex META --". You find there m4 macros which are used to integrate the modul into the main program of ethersex. Details later. meta.m4 is the extraction and collection of these sections. The files which are used, are denfined by the makefile of each "module". Each C source files has to be added to the make var "y_SRC". A nice trick is used there by the use of ".config", where all the used and configured feature are assigned a "y" to make vars. i.e. MODULX_GENERAL_SUPPORT=y Then in the makefile of ModuleX: $(MODULX_GENERAL_SUPPORT)_SRC += file1.c file2.c ... If the module is not activated the files added to _SRC instead of y_SRC. === meta.c === Is generated by m4 macros. The inputs are: (controlled centrally in the Makefile!) * autoconfig.h *: is converted and each define line results into one m4 command line parameter of the form -Dconf_<parname> * scripts/meta_magic.m4 *: contains the framework for meta.c * protocols/ecmd/ecmd_magic.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * protocols/soap/soap_magic.m4 *: only if SOAP support is activated - make var $(SOAP_SUPPORT) must be set to "y" * meta.m4 *: see above * protocols/ecmd/ecmd_defs.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced thru the make var ${named_pin_simple_files} *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced thru the make var $(y_NP_SIMPLE_META_SRC) *: unconditional ... but contain the following files, if ECMD parser or SOAP support is activated: ** protocols/ecmd/ecmd_defs.m4 ** ${named_pin_simple_files} *: so I think it could be a small bug - if ECMD parser support is on, the files are added twice - may be this does not matter. === pinning.c === === meta.h === [[Category:Development]] 1e7782ab4bd2f4cfbac36f3ccca46178bce9ff67 542 541 2012-05-01T15:16:04Z Tkaltenbrunner 475 wikitext text/x-wiki {{i18n|Configuration of Boards and Pins}} == Intro == This page will explain some of the details behind menuconfig. It is meant for developers who want to look behind the curtain or if someone wants to debug a modul which does not work or compile any more .... == make menuconfig == May be someone can explain how to add or extend the menuconfig system - here a look at the results and the output of menuconfig. The configuration is saved in two different formats: * file .config for the menuconfig itself - ** it is used for including it into the makefile ** definition auf makefile variables * file autoconfig.h - ** it is for including it in the compilation ** definition of C preprocessor macros and defines I thing the details of the configuration should become clear after doing the menuconfig and reading about the modules. May be I can explain some "core" configuration later. == make == The first steps in the build process are to get all the configuration information and build some source files which put it all together. Besides some usual unix tools like sed the m4 macro processor plays an important role. Even if it is not in the scope of this wiki, I added a very short intro here: [[m4 - very short intro]] === meta.m4 === If you have look at the different source codes of the modules, you find at the bottom of the main c-file a comment section starting with "-- Ethersex META --". You find there m4 macros which are used to integrate the modul into the main program of ethersex. Details later. meta.m4 is the extraction and collection of these sections. The files which are used, are denfined by the makefile of each "module". Each C source files has to be added to the make var "y_SRC". A nice trick is used there by the use of ".config", where all the used and configured feature are assigned a "y" to make vars. i.e. MODULX_GENERAL_SUPPORT=y Then in the makefile of ModuleX: $(MODULX_GENERAL_SUPPORT)_SRC += file1.c file2.c ... If the module is not activated the files added to _SRC instead of y_SRC. === meta.c === Is generated by m4 macros. The inputs are: (controlled centrally in the Makefile!) * autoconfig.h *: is converted and each define line results into one m4 command line parameter of the form -Dconf_<parname> * scripts/meta_magic.m4 *: contains the framework for meta.c * protocols/ecmd/ecmd_magic.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * protocols/soap/soap_magic.m4 *: only if SOAP support is activated - make var $(SOAP_SUPPORT) must be set to "y" * meta.m4 *: see above * protocols/ecmd/ecmd_defs.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced by the make var ${named_pin_simple_files} *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced by the make var $(y_NP_SIMPLE_META_SRC) *: unconditional ... but contain the following files, if ECMD parser or SOAP support is activated: ** protocols/ecmd/ecmd_defs.m4 ** ${named_pin_simple_files} *: so I think it could be a small bug - if ECMD parser support is on, the files are added twice - may be this does not matter. ==== What is in ${named_pin_simple_files}? ==== That should be a chapter for itself - containing how the internals of defining pins works. In the default case that are probably the following files: * core/portio/np_simple.m4 * protocols/ecmd/np_simple_glue.m4 === pinning.c === === meta.h === [[Category:Development]] 24b826f655b25d37789683bcf30107f59ebdb733 543 542 2012-05-01T15:20:30Z Tkaltenbrunner 475 /* make menuconfig */ wikitext text/x-wiki {{i18n|Configuration of Boards and Pins}} == Intro == This page will explain some of the details behind menuconfig. It is meant for developers who want to look behind the curtain or if someone wants to debug a modul which does not work or compile any more .... == make menuconfig == May be someone can explain how to add or extend the menuconfig system - here a look at the results and the output of menuconfig. The configuration is saved in two different formats: * file .config for the menuconfig itself - ** it is used for including it into the makefile ** it incluences also the build process of the binary file ** definition auf makefile variables * file autoconfig.h - ** it is for including it in the compilation ** definition of C preprocessor macros and defines I thing the details of the configuration should become clear after doing the menuconfig and reading about the modules. May be I can explain some "core" configuration later. == make == The first steps in the build process are to get all the configuration information and build some source files which put it all together. Besides some usual unix tools like sed the m4 macro processor plays an important role. Even if it is not in the scope of this wiki, I added a very short intro here: [[m4 - very short intro]] === meta.m4 === If you have look at the different source codes of the modules, you find at the bottom of the main c-file a comment section starting with "-- Ethersex META --". You find there m4 macros which are used to integrate the modul into the main program of ethersex. Details later. meta.m4 is the extraction and collection of these sections. The files which are used, are denfined by the makefile of each "module". Each C source files has to be added to the make var "y_SRC". A nice trick is used there by the use of ".config", where all the used and configured feature are assigned a "y" to make vars. i.e. MODULX_GENERAL_SUPPORT=y Then in the makefile of ModuleX: $(MODULX_GENERAL_SUPPORT)_SRC += file1.c file2.c ... If the module is not activated the files added to _SRC instead of y_SRC. === meta.c === Is generated by m4 macros. The inputs are: (controlled centrally in the Makefile!) * autoconfig.h *: is converted and each define line results into one m4 command line parameter of the form -Dconf_<parname> * scripts/meta_magic.m4 *: contains the framework for meta.c * protocols/ecmd/ecmd_magic.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * protocols/soap/soap_magic.m4 *: only if SOAP support is activated - make var $(SOAP_SUPPORT) must be set to "y" * meta.m4 *: see above * protocols/ecmd/ecmd_defs.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced by the make var ${named_pin_simple_files} *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced by the make var $(y_NP_SIMPLE_META_SRC) *: unconditional ... but contain the following files, if ECMD parser or SOAP support is activated: ** protocols/ecmd/ecmd_defs.m4 ** ${named_pin_simple_files} *: so I think it could be a small bug - if ECMD parser support is on, the files are added twice - may be this does not matter. ==== What is in ${named_pin_simple_files}? ==== That should be a chapter for itself - containing how the internals of defining pins works. In the default case that are probably the following files: * core/portio/np_simple.m4 * protocols/ecmd/np_simple_glue.m4 === pinning.c === === meta.h === [[Category:Development]] c119e7ec85a1e3aeb90dcfd34f331254a259c337 544 543 2012-05-01T15:45:17Z Tkaltenbrunner 475 /* pinning.c */ wikitext text/x-wiki {{i18n|Configuration of Boards and Pins}} == Intro == This page will explain some of the details behind menuconfig. It is meant for developers who want to look behind the curtain or if someone wants to debug a modul which does not work or compile any more .... == make menuconfig == May be someone can explain how to add or extend the menuconfig system - here a look at the results and the output of menuconfig. The configuration is saved in two different formats: * file .config for the menuconfig itself - ** it is used for including it into the makefile ** it incluences also the build process of the binary file ** definition auf makefile variables * file autoconfig.h - ** it is for including it in the compilation ** definition of C preprocessor macros and defines I thing the details of the configuration should become clear after doing the menuconfig and reading about the modules. May be I can explain some "core" configuration later. == make == The first steps in the build process are to get all the configuration information and build some source files which put it all together. Besides some usual unix tools like sed the m4 macro processor plays an important role. Even if it is not in the scope of this wiki, I added a very short intro here: [[m4 - very short intro]] === meta.m4 === If you have look at the different source codes of the modules, you find at the bottom of the main c-file a comment section starting with "-- Ethersex META --". You find there m4 macros which are used to integrate the modul into the main program of ethersex. Details later. meta.m4 is the extraction and collection of these sections. The files which are used, are denfined by the makefile of each "module". Each C source files has to be added to the make var "y_SRC". A nice trick is used there by the use of ".config", where all the used and configured feature are assigned a "y" to make vars. i.e. MODULX_GENERAL_SUPPORT=y Then in the makefile of ModuleX: $(MODULX_GENERAL_SUPPORT)_SRC += file1.c file2.c ... If the module is not activated the files added to _SRC instead of y_SRC. === meta.c === Is generated by m4 macros. The inputs are: (controlled centrally in the Makefile!) * autoconfig.h *: is converted and each define line results into one m4 command line parameter of the form -Dconf_<parname> * scripts/meta_magic.m4 *: contains the framework for meta.c * protocols/ecmd/ecmd_magic.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * protocols/soap/soap_magic.m4 *: only if SOAP support is activated - make var $(SOAP_SUPPORT) must be set to "y" * meta.m4 *: see above * protocols/ecmd/ecmd_defs.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced by the make var ${named_pin_simple_files} *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced by the make var $(y_NP_SIMPLE_META_SRC) *: unconditional ... but contain the following files, if ECMD parser or SOAP support is activated: ** protocols/ecmd/ecmd_defs.m4 ** ${named_pin_simple_files} *: so I think it could be a small bug - if ECMD parser support is on, the files are added twice - may be this does not matter. ==== What is in ${named_pin_simple_files}? ==== That should be a chapter for itself - containing how the internals of defining pins works. In the default case that are probably the following files: * core/portio/np_simple.m4 * protocols/ecmd/np_simple_glue.m4 === pinning.c === The detailied concept of pinning will be descriped in an own chapter. At the moment is important to know that each processor has several ports which can have different functions and are connected sometimes to devices on the board already. If you connect your own hardware to the board which should be supported by an ethersex module you must configure the port(s) which are connects the hardware with the processor. Files from which pinning.c is build: * pinning/internals/header.m4 === meta.h === [[Category:Development]] 9a9080a80468d2bb430c26dd6c4f15efd9da4e37 0 207 530 2012-05-01T09:46:47Z Tkaltenbrunner 475 Created page with "{{i8n:M4 - very short intro}} Text" wikitext text/x-wiki {{i8n:M4 - very short intro}} Text d1665ed646b6eb3bb8cf210d11eb605d9fb21c0d 531 530 2012-05-01T09:47:59Z Tkaltenbrunner 475 wikitext text/x-wiki {{i18n:M4 - very short intro}} Text 42dc8e93f4e0116637e41d0744f9598214fb5d02 532 531 2012-05-01T09:49:13Z Tkaltenbrunner 475 wikitext text/x-wiki {{i18n|M4 - very short intro}} Text 52d910a30da1b7fa7125b0923e0476772da77e64 535 532 2012-05-01T10:13:03Z Tkaltenbrunner 475 wikitext text/x-wiki {{i18n|M4 - very short intro}} it is only avalable in german now ... Otherwise have a look at the offical documentation: http://www.gnu.org/software/m4/manual/index.html e54cdc073e2e00345955aa3d0bf928a94de62a98 536 535 2012-05-01T10:15:12Z Tkaltenbrunner 475 wikitext text/x-wiki {{i18n|M4 - very short intro}} it is only available in german now ... [[]] Otherwise have a look at the offical documentation: http://www.gnu.org/software/m4/manual/index.html 3be3fd6bf2b728caf2cf73dc8a41a6ec6429ab8b 537 536 2012-05-01T10:16:40Z Tkaltenbrunner 475 wikitext text/x-wiki {{i18n|M4 - very short intro}} it is only available in german now ... [[M4 - very short intro (Deutsch)]] Otherwise have a look at the offical documentation: http://www.gnu.org/software/m4/manual/index.html 44f4658be1df4e69f0730c396e830476dca70747 0 208 533 2012-05-01T10:09:07Z Tkaltenbrunner 475 Created page with "== Einleitung == Die offizielle Doku gibt es hier: http://www.gnu.org/software/m4/manual/index.html Hier noch ein ganze kurze Einführung: Von der Idee her, ist es mit dem C-Pr…" wikitext text/x-wiki == Einleitung == Die offizielle Doku gibt es hier: http://www.gnu.org/software/m4/manual/index.html Hier noch ein ganze kurze Einführung: Von der Idee her, ist es mit dem C-Präprocessor vergleichbar, der ebenfalls Macro-Ersetzungen durchführt und das Ergebnis an den C-Compiler weiterleitet. Bei m4 ist das Ergebnisse lediglich der Text, den die Macro-Ersetzungen ergeben. Wie es genau funktioniert, aber unbedingt nachlesen, da es manchmal auch auf die Feinheiten ankommt. Kommentare werden mit # wie in C gekennzeichnet. Es gibt keinen "Befehlsterminator" wie z.B. ein Semikolon. Ersetzungen werden aber ähnlich wie ein Funktionen in einer Programmiersprache aufgerufen. Wichtig ist auch die Quotierung mit ` und ' , die das Verhalten bei der Macro-Expandierung entscheidend beeinflusst. siehe hier und folgende http://www.gnu.org/software/m4/manual/m4.html#Quoting-Arguments == Macro definieren == Im Gegensatz zum C-Präprocessor wird hier ein sogenanntes "builtin" benutzt: define(name, [expansion]) Zu beachten: werden die Argumente nicht quotiert, kann hier schon die Macro-Erweiterung zuschlagen, was dann zu unerwünschten Ergebnissen führen kann. Mit den "Pseudo-Variablen" $1, $2, etc. kann man die Argumente des Macros in der Expansion referenzieren. Im Gegensatz zum C-Präprozessor, der überwiegend mit benannten Parametern arbeitet. * $* - alle Argumente * $@ - alle Argumente quotiert - Im Gegensatz zur vorhergehenden Variante werden die Argumente nicht weiter expandiert. * $# - Anzahl der Argumente == "Kontrol-Strukturen" == Hiermit sind bedingte Ausführung und Schleifen gemeint. * ifdef(name, string1, [string2]) *: - wenn name definiert ist, dann ist das Ergebnis string1, sonst string2 * ifelse(string1, string2, equal1, string3, string4, equal2, ..., [not_equal]) *: - wenn string1 = string2, dann equal1, sonst if string3 = string4, dann equal2, sonst ..., sonst not_equal * join oder joinall([separator], [args....]) *: - args zusammenfügen, Separator dazwischen setzen. Bei joinall wird immer der Separator gesetzt - auch wenn ein Argument leer ist. * Rekursive Macro-Definitionen sind auch möglich - hilfreich dabei die shift Funktion, die jeweils das erste Argument abschneidet. * forloop (iterator, start, end, text) *:- iterator muss ein gültiger Macroname sein, Start und Ende ganze Zahlen, der Text wird gemäß der Schleifendurchläufe ersetzt. * foreach (iterator, paren-list, text) / foreachq (iterator, paren-list, text) *: - jedes Argument der parent-list wird an den Iterator gebunden und dann eine Ersetzung für Text ausgeführt. Bemerkung: die Sprache ist sehr mächtig und man kann "wildes" konstruieren, dass man nach 2 Tagen selber nicht mehr versteht ;-) == Wichtiges == * dnl - "Discard to next line" - Schließt die Zeile ab - alles nachfolgende wird ignoriert. * divert - der nachfolgende Text wird ausgegeben. Der Text endet beim erneuten auftauchen des Wortes "divert". Das Wort selber kann man deshalb nur mit im Handbuch beschriebenen Tricks im Text verwenden werden .... da8aefe0068d7141a50372ca8075fa956d02d625 534 533 2012-05-01T10:10:10Z Tkaltenbrunner 475 /* Macro definieren */ wikitext text/x-wiki == Einleitung == Die offizielle Doku gibt es hier: http://www.gnu.org/software/m4/manual/index.html Hier noch ein ganze kurze Einführung: Von der Idee her, ist es mit dem C-Präprocessor vergleichbar, der ebenfalls Macro-Ersetzungen durchführt und das Ergebnis an den C-Compiler weiterleitet. Bei m4 ist das Ergebnisse lediglich der Text, den die Macro-Ersetzungen ergeben. Wie es genau funktioniert, aber unbedingt nachlesen, da es manchmal auch auf die Feinheiten ankommt. Kommentare werden mit # wie in C gekennzeichnet. Es gibt keinen "Befehlsterminator" wie z.B. ein Semikolon. Ersetzungen werden aber ähnlich wie ein Funktionen in einer Programmiersprache aufgerufen. Wichtig ist auch die Quotierung mit ` und ' , die das Verhalten bei der Macro-Expandierung entscheidend beeinflusst. siehe hier und folgende http://www.gnu.org/software/m4/manual/m4.html#Quoting-Arguments == Macro definieren == Im Gegensatz zum C-Präprocessor wird hier ein sogenanntes "builtin" benutzt: define(name, [expansion]) Zu beachten: werden die Argumente nicht quotiert, kann hier schon die Macro-Erweiterung zuschlagen, was dann zu unerwünschten Ergebnissen führen kann. Mit den "Pseudo-Variablen" $1, $2, etc. kann man die Argumente des Macros in der Expansion referenzieren. Im Gegensatz zum C-Präprozessor, der überwiegend mit benannten Parametern arbeitet. * $* - alle Argumente * $@ - alle Argumente quotiert - Im Gegensatz zur vorhergehenden Variante werden die Argumente nicht weiter expandiert. * $# - Anzahl der Argumente == "Kontrol-Strukturen" == Hiermit sind bedingte Ausführung und Schleifen gemeint. * ifdef(name, string1, [string2]) *: - wenn name definiert ist, dann ist das Ergebnis string1, sonst string2 * ifelse(string1, string2, equal1, string3, string4, equal2, ..., [not_equal]) *: - wenn string1 = string2, dann equal1, sonst if string3 = string4, dann equal2, sonst ..., sonst not_equal * join oder joinall([separator], [args....]) *: - args zusammenfügen, Separator dazwischen setzen. Bei joinall wird immer der Separator gesetzt - auch wenn ein Argument leer ist. * Rekursive Macro-Definitionen sind auch möglich - hilfreich dabei die shift Funktion, die jeweils das erste Argument abschneidet. * forloop (iterator, start, end, text) *:- iterator muss ein gültiger Macroname sein, Start und Ende ganze Zahlen, der Text wird gemäß der Schleifendurchläufe ersetzt. * foreach (iterator, paren-list, text) / foreachq (iterator, paren-list, text) *: - jedes Argument der parent-list wird an den Iterator gebunden und dann eine Ersetzung für Text ausgeführt. Bemerkung: die Sprache ist sehr mächtig und man kann "wildes" konstruieren, dass man nach 2 Tagen selber nicht mehr versteht ;-) == Wichtiges == * dnl - "Discard to next line" - Schließt die Zeile ab - alles nachfolgende wird ignoriert. * divert - der nachfolgende Text wird ausgegeben. Der Text endet beim erneuten auftauchen des Wortes "divert". Das Wort selber kann man deshalb nur mit im Handbuch beschriebenen Tricks im Text verwenden werden .... 0297e59006ddebe78d4e0b04c408be5ce31ae717 0 205 545 544 2012-05-01T17:15:56Z Tkaltenbrunner 475 wikitext text/x-wiki {{i18n|Configuration of Boards and Pins}} == Intro == This page will explain some of the details behind menuconfig. It is meant for developers who want to look behind the curtain or if someone wants to debug a modul which does not work or compile any more .... == make menuconfig == May be someone can explain how to add or extend the menuconfig system - here a look at the results and the output of menuconfig. The configuration is saved in two different formats: * file .config for the menuconfig itself - ** it is used for including it into the makefile ** it incluences also the build process of the binary file ** definition auf makefile variables * file autoconfig.h - ** it is for including it in the compilation ** definition of C preprocessor macros and defines I thing the details of the configuration should become clear after doing the menuconfig and reading about the modules. May be I can explain some "core" configuration later. == make == The first steps in the build process are to get all the configuration information and build some source files which put it all together. Besides some usual unix tools like sed the m4 macro processor plays an important role. Even if it is not in the scope of this wiki, I added a very short intro here: [[m4 - very short intro]] === meta.m4 === If you have look at the different source codes of the modules, you find at the bottom of the main c-file a comment section starting with "-- Ethersex META --". You find there m4 macros which are used to integrate the modul into the main program of ethersex. Details later. meta.m4 is the extraction and collection of these sections. The files which are used, are denfined by the makefile of each "module". Each C source files has to be added to the make var "y_SRC". A nice trick is used there by the use of ".config", where all the used and configured feature are assigned a "y" to make vars. i.e. MODULX_GENERAL_SUPPORT=y Then in the makefile of ModuleX: $(MODULX_GENERAL_SUPPORT)_SRC += file1.c file2.c ... If the module is not activated the files added to _SRC instead of y_SRC. === meta.c === Is generated by m4 macros. The inputs are: (controlled centrally in the Makefile!) * autoconfig.h *: is converted and each define line results into one m4 command line parameter of the form -Dconf_<parname> * scripts/meta_magic.m4 *: contains the framework for meta.c * protocols/ecmd/ecmd_magic.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * protocols/soap/soap_magic.m4 *: only if SOAP support is activated - make var $(SOAP_SUPPORT) must be set to "y" * meta.m4 *: see above * protocols/ecmd/ecmd_defs.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced by the make var ${named_pin_simple_files} *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced by the make var $(y_NP_SIMPLE_META_SRC) *: unconditional ... but contain the following files, if ECMD parser or SOAP support is activated: ** protocols/ecmd/ecmd_defs.m4 ** ${named_pin_simple_files} *: so I think it could be a small bug - if ECMD parser support is on, the files are added twice - may be this does not matter. ==== What is in ${named_pin_simple_files}? ==== That should be a chapter for itself - containing how the internals of defining pins works. In the default case that are probably the following files: * core/portio/np_simple.m4 * protocols/ecmd/np_simple_glue.m4 === pinning.c === The detailied concept of pinning will be descriped in an own chapter. At the moment is important to know that each processor has several ports which can have different functions and are connected sometimes to devices on the board already. If you connect your own hardware to the board which should be supported by an ethersex module you must configure the port(s) which are connects the hardware with the processor. Files from which pinning.c is build: * pinning/internals/header.m4 * pinning/controllers/<mcuname>.m4 *: mcuname is defined by make var MCU * pinning/internals/hackery_<mcuname>.m4 * pinning/hardware/<boardname>.m4 *: <boardname> is definned by make var HARDWARE * pinning/internals/footer.m4 * autoconfig.h *: is converted and each define line results into one m4 command line parameter of the form -Dconf_<parname> What you should realize is, the pinning.c file is independent from any module, so the connection of module and pinning must be defined in one of the mentioned files! === meta.h === [[Category:Development]] cdc186675d84b54069e958ba021798dd9bfb4f79 546 545 2012-05-01T17:27:53Z Tkaltenbrunner 475 /* meta.h */ wikitext text/x-wiki {{i18n|Configuration of Boards and Pins}} == Intro == This page will explain some of the details behind menuconfig. It is meant for developers who want to look behind the curtain or if someone wants to debug a modul which does not work or compile any more .... == make menuconfig == May be someone can explain how to add or extend the menuconfig system - here a look at the results and the output of menuconfig. The configuration is saved in two different formats: * file .config for the menuconfig itself - ** it is used for including it into the makefile ** it incluences also the build process of the binary file ** definition auf makefile variables * file autoconfig.h - ** it is for including it in the compilation ** definition of C preprocessor macros and defines I thing the details of the configuration should become clear after doing the menuconfig and reading about the modules. May be I can explain some "core" configuration later. == make == The first steps in the build process are to get all the configuration information and build some source files which put it all together. Besides some usual unix tools like sed the m4 macro processor plays an important role. Even if it is not in the scope of this wiki, I added a very short intro here: [[m4 - very short intro]] === meta.m4 === If you have look at the different source codes of the modules, you find at the bottom of the main c-file a comment section starting with "-- Ethersex META --". You find there m4 macros which are used to integrate the modul into the main program of ethersex. Details later. meta.m4 is the extraction and collection of these sections. The files which are used, are denfined by the makefile of each "module". Each C source files has to be added to the make var "y_SRC". A nice trick is used there by the use of ".config", where all the used and configured feature are assigned a "y" to make vars. i.e. MODULX_GENERAL_SUPPORT=y Then in the makefile of ModuleX: $(MODULX_GENERAL_SUPPORT)_SRC += file1.c file2.c ... If the module is not activated the files added to _SRC instead of y_SRC. === meta.c === Is generated by m4 macros. The inputs are: (controlled centrally in the Makefile!) * autoconfig.h *: is converted and each define line results into one m4 command line parameter of the form -Dconf_<parname> * scripts/meta_magic.m4 *: contains the framework for meta.c * protocols/ecmd/ecmd_magic.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * protocols/soap/soap_magic.m4 *: only if SOAP support is activated - make var $(SOAP_SUPPORT) must be set to "y" * meta.m4 *: see above * protocols/ecmd/ecmd_defs.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced by the make var ${named_pin_simple_files} *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced by the make var $(y_NP_SIMPLE_META_SRC) *: unconditional ... but contain the following files, if ECMD parser or SOAP support is activated: ** protocols/ecmd/ecmd_defs.m4 ** ${named_pin_simple_files} *: so I think it could be a small bug - if ECMD parser support is on, the files are added twice - may be this does not matter. ==== What is in ${named_pin_simple_files}? ==== That should be a chapter for itself - containing how the internals of defining pins works. In the default case that are probably the following files: * core/portio/np_simple.m4 * protocols/ecmd/np_simple_glue.m4 === pinning.c === The detailied concept of pinning will be descriped in an own chapter. At the moment is important to know that each processor has several ports which can have different functions and are connected sometimes to devices on the board already. If you connect your own hardware to the board which should be supported by an ethersex module you must configure the port(s) which are connects the hardware with the processor. Files from which pinning.c is build: * pinning/internals/header.m4 * pinning/controllers/<mcuname>.m4 *: mcuname is defined by make var MCU * pinning/internals/hackery_<mcuname>.m4 * pinning/hardware/<boardname>.m4 *: <boardname> is definned by make var HARDWARE * pinning/internals/footer.m4 * autoconfig.h *: is converted and each define line results into one m4 command line parameter of the form -Dconf_<parname> What you should realize is, the pinning.c file is independent from any module, so the connection of module and pinning must be defined in one of the mentioned files! === meta.h === is also generated from m4 macros. Files used: * scripts/meta_header_magic.m4 *: framework of meta.h and macros. * meta.m4 meta.m4 is part of meta.c and meta.h - how is it possible, may someone ask. The answer: macros, which are not defined, eval to empty string. So it depends on the defined macros to what meta.m4 is expanded. [[Category:Development]] e8531f248ea1f82d6ee28235beeede87a8fe7feb 547 546 2012-05-01T17:29:34Z Tkaltenbrunner 475 wikitext text/x-wiki {{i18n|Configuration of Boards and Pins}} == Intro == This page will explain some of the details behind menuconfig. It is meant for developers who want to look behind the curtain or if someone wants to debug a modul which does not work or compile any more .... == make menuconfig == May be someone can explain how to add or extend the menuconfig system - here a look at the results and the output of menuconfig. The configuration is saved in two different formats: * file .config for the menuconfig itself - ** it is used for including it into the makefile ** it incluences also the build process of the binary file ** definition auf makefile variables * file autoconfig.h - ** it is for including it in the compilation ** definition of C preprocessor macros and defines I thing the details of the configuration should become clear after doing the menuconfig and reading about the modules. May be I can explain some "core" configuration later. == make == The first steps in the build process are to get all the configuration information and build some source files which put it all together. Besides some usual unix tools like sed the m4 macro processor plays an important role. Even if it is not in the scope of this wiki, I added a very short intro here: [[m4 - very short intro]] === meta.m4 === If you have look at the different source codes of the modules, you find at the bottom of the main c-file a comment section starting with "-- Ethersex META --". You find there m4 macros which are used to integrate the modul into the main program of ethersex. Details later. meta.m4 is the extraction and collection of these sections. The files which are used, are denfined by the makefile of each "module". Each C source files has to be added to the make var "y_SRC". A nice trick is used there by the use of ".config", where all the used and configured feature are assigned a "y" to make vars. i.e. MODULX_GENERAL_SUPPORT=y Then in the makefile of ModuleX: $(MODULX_GENERAL_SUPPORT)_SRC += file1.c file2.c ... If the module is not activated the files added to _SRC instead of y_SRC. === meta.c === Is generated by m4 macros. The inputs are: (controlled centrally in the Makefile!) * autoconfig.h *: is converted and each define line results into one m4 command line parameter of the form -Dconf_<parname> * scripts/meta_magic.m4 *: contains the framework for meta.c * protocols/ecmd/ecmd_magic.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * protocols/soap/soap_magic.m4 *: only if SOAP support is activated - make var $(SOAP_SUPPORT) must be set to "y" * meta.m4 *: see above * protocols/ecmd/ecmd_defs.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced by the make var ${named_pin_simple_files} *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced by the make var $(y_NP_SIMPLE_META_SRC) *: unconditional ... but contain the following files, if ECMD parser or SOAP support is activated: ** protocols/ecmd/ecmd_defs.m4 ** ${named_pin_simple_files} *: so I think it could be a small bug - if ECMD parser support is on, the files are added twice - may be this does not matter. ==== What is in ${named_pin_simple_files}? ==== That should be a chapter for itself - containing how the internals of defining pins works. In the default case that are probably the following files: * core/portio/np_simple.m4 * protocols/ecmd/np_simple_glue.m4 === meta.h === is also generated from m4 macros. Files used: * scripts/meta_header_magic.m4 *: framework of meta.h and macros. * meta.m4 meta.m4 is part of meta.c and meta.h - how is it possible, may someone ask. The answer: macros, which are not defined, eval to empty string. So it depends on the defined macros to what meta.m4 is expanded. === pinning.c === The detailied concept of pinning will be descriped in an own chapter. At the moment is important to know that each processor has several ports which can have different functions and are connected sometimes to devices on the board already. If you connect your own hardware to the board which should be supported by an ethersex module you must configure the port(s) which are connects the hardware with the processor. Files from which pinning.c is build: * pinning/internals/header.m4 * pinning/controllers/<mcuname>.m4 *: mcuname is defined by make var MCU * pinning/internals/hackery_<mcuname>.m4 * pinning/hardware/<boardname>.m4 *: <boardname> is definned by make var HARDWARE * pinning/internals/footer.m4 * autoconfig.h *: is converted and each define line results into one m4 command line parameter of the form -Dconf_<parname> What you should realize is, the pinning.c file is independent from any module, so the connection of module and pinning must be defined in one of the mentioned files! [[Category:Development]] b4274205484135a42374f59a0b00334e994cf663 548 547 2012-05-01T17:31:59Z Tkaltenbrunner 475 /* meta.h */ wikitext text/x-wiki {{i18n|Configuration of Boards and Pins}} == Intro == This page will explain some of the details behind menuconfig. It is meant for developers who want to look behind the curtain or if someone wants to debug a modul which does not work or compile any more .... == make menuconfig == May be someone can explain how to add or extend the menuconfig system - here a look at the results and the output of menuconfig. The configuration is saved in two different formats: * file .config for the menuconfig itself - ** it is used for including it into the makefile ** it incluences also the build process of the binary file ** definition auf makefile variables * file autoconfig.h - ** it is for including it in the compilation ** definition of C preprocessor macros and defines I thing the details of the configuration should become clear after doing the menuconfig and reading about the modules. May be I can explain some "core" configuration later. == make == The first steps in the build process are to get all the configuration information and build some source files which put it all together. Besides some usual unix tools like sed the m4 macro processor plays an important role. Even if it is not in the scope of this wiki, I added a very short intro here: [[m4 - very short intro]] === meta.m4 === If you have look at the different source codes of the modules, you find at the bottom of the main c-file a comment section starting with "-- Ethersex META --". You find there m4 macros which are used to integrate the modul into the main program of ethersex. Details later. meta.m4 is the extraction and collection of these sections. The files which are used, are denfined by the makefile of each "module". Each C source files has to be added to the make var "y_SRC". A nice trick is used there by the use of ".config", where all the used and configured feature are assigned a "y" to make vars. i.e. MODULX_GENERAL_SUPPORT=y Then in the makefile of ModuleX: $(MODULX_GENERAL_SUPPORT)_SRC += file1.c file2.c ... If the module is not activated the files added to _SRC instead of y_SRC. === meta.c === Is generated by m4 macros. The inputs are: (controlled centrally in the Makefile!) * autoconfig.h *: is converted and each define line results into one m4 command line parameter of the form -Dconf_<parname> * scripts/meta_magic.m4 *: contains the framework for meta.c * protocols/ecmd/ecmd_magic.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * protocols/soap/soap_magic.m4 *: only if SOAP support is activated - make var $(SOAP_SUPPORT) must be set to "y" * meta.m4 *: see above * protocols/ecmd/ecmd_defs.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced by the make var ${named_pin_simple_files} *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced by the make var $(y_NP_SIMPLE_META_SRC) *: unconditional ... but contain the following files, if ECMD parser or SOAP support is activated: ** protocols/ecmd/ecmd_defs.m4 ** ${named_pin_simple_files} *: so I think it could be a small bug - if ECMD parser support is on, the files are added twice - may be this does not matter. ==== What is in ${named_pin_simple_files}? ==== That should be a chapter for itself - containing how the internals of defining pins works. In the default case that are probably the following files: * core/portio/np_simple.m4 * protocols/ecmd/np_simple_glue.m4 === meta.h === is also generated from m4 macros. Files used: * scripts/meta_header_magic.m4 *: framework of meta.h and macros. * meta.m4 meta.m4 is part of meta.c and meta.h - how is it possible, may someone ask. The answer: macros, which are not defined, eval to empty string. So it depends on the defined macros to what meta.m4 is expanded. More about the he interesting [[concept of meta]]. === pinning.c === The detailied concept of pinning will be descriped in an own chapter. At the moment is important to know that each processor has several ports which can have different functions and are connected sometimes to devices on the board already. If you connect your own hardware to the board which should be supported by an ethersex module you must configure the port(s) which are connects the hardware with the processor. Files from which pinning.c is build: * pinning/internals/header.m4 * pinning/controllers/<mcuname>.m4 *: mcuname is defined by make var MCU * pinning/internals/hackery_<mcuname>.m4 * pinning/hardware/<boardname>.m4 *: <boardname> is definned by make var HARDWARE * pinning/internals/footer.m4 * autoconfig.h *: is converted and each define line results into one m4 command line parameter of the form -Dconf_<parname> What you should realize is, the pinning.c file is independent from any module, so the connection of module and pinning must be defined in one of the mentioned files! [[Category:Development]] 15f6c52e47f7f4e7f9516b60f469ee5a87fe6398 596 548 2012-05-06T17:23:19Z Tkaltenbrunner 475 /* make menuconfig */ wikitext text/x-wiki {{i18n|Configuration of Boards and Pins}} == Intro == This page will explain some of the details behind menuconfig. It is meant for developers who want to look behind the curtain or if someone wants to debug a modul which does not work or compile any more .... == make menuconfig == Integration of modules into menuconfig look is described on this page [[Own module#Menuconfig]] - here a look at the results and the output of menuconfig. The configuration is saved in two different formats: * file .config for the menuconfig itself - ** it is used for including it into the makefile ** it incluences also the build process of the binary file ** definition auf makefile variables * file autoconfig.h - ** it is for including it in the compilation ** definition of C preprocessor macros and defines I thing the details of the configuration should become clear after doing the menuconfig and reading about the modules. May be I can explain some "core" configuration later. == make == The first steps in the build process are to get all the configuration information and build some source files which put it all together. Besides some usual unix tools like sed the m4 macro processor plays an important role. Even if it is not in the scope of this wiki, I added a very short intro here: [[m4 - very short intro]] === meta.m4 === If you have look at the different source codes of the modules, you find at the bottom of the main c-file a comment section starting with "-- Ethersex META --". You find there m4 macros which are used to integrate the modul into the main program of ethersex. Details later. meta.m4 is the extraction and collection of these sections. The files which are used, are denfined by the makefile of each "module". Each C source files has to be added to the make var "y_SRC". A nice trick is used there by the use of ".config", where all the used and configured feature are assigned a "y" to make vars. i.e. MODULX_GENERAL_SUPPORT=y Then in the makefile of ModuleX: $(MODULX_GENERAL_SUPPORT)_SRC += file1.c file2.c ... If the module is not activated the files added to _SRC instead of y_SRC. === meta.c === Is generated by m4 macros. The inputs are: (controlled centrally in the Makefile!) * autoconfig.h *: is converted and each define line results into one m4 command line parameter of the form -Dconf_<parname> * scripts/meta_magic.m4 *: contains the framework for meta.c * protocols/ecmd/ecmd_magic.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * protocols/soap/soap_magic.m4 *: only if SOAP support is activated - make var $(SOAP_SUPPORT) must be set to "y" * meta.m4 *: see above * protocols/ecmd/ecmd_defs.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced by the make var ${named_pin_simple_files} *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced by the make var $(y_NP_SIMPLE_META_SRC) *: unconditional ... but contain the following files, if ECMD parser or SOAP support is activated: ** protocols/ecmd/ecmd_defs.m4 ** ${named_pin_simple_files} *: so I think it could be a small bug - if ECMD parser support is on, the files are added twice - may be this does not matter. ==== What is in ${named_pin_simple_files}? ==== That should be a chapter for itself - containing how the internals of defining pins works. In the default case that are probably the following files: * core/portio/np_simple.m4 * protocols/ecmd/np_simple_glue.m4 === meta.h === is also generated from m4 macros. Files used: * scripts/meta_header_magic.m4 *: framework of meta.h and macros. * meta.m4 meta.m4 is part of meta.c and meta.h - how is it possible, may someone ask. The answer: macros, which are not defined, eval to empty string. So it depends on the defined macros to what meta.m4 is expanded. More about the he interesting [[concept of meta]]. === pinning.c === The detailied concept of pinning will be descriped in an own chapter. At the moment is important to know that each processor has several ports which can have different functions and are connected sometimes to devices on the board already. If you connect your own hardware to the board which should be supported by an ethersex module you must configure the port(s) which are connects the hardware with the processor. Files from which pinning.c is build: * pinning/internals/header.m4 * pinning/controllers/<mcuname>.m4 *: mcuname is defined by make var MCU * pinning/internals/hackery_<mcuname>.m4 * pinning/hardware/<boardname>.m4 *: <boardname> is definned by make var HARDWARE * pinning/internals/footer.m4 * autoconfig.h *: is converted and each define line results into one m4 command line parameter of the form -Dconf_<parname> What you should realize is, the pinning.c file is independent from any module, so the connection of module and pinning must be defined in one of the mentioned files! [[Category:Development]] f3e42f775fc3fbe87d90b40612537c5a98f5410b 611 596 2012-05-17T17:27:17Z Tkaltenbrunner 475 /* meta.m4 */ wikitext text/x-wiki {{i18n|Configuration of Boards and Pins}} == Intro == This page will explain some of the details behind menuconfig. It is meant for developers who want to look behind the curtain or if someone wants to debug a modul which does not work or compile any more .... == make menuconfig == Integration of modules into menuconfig look is described on this page [[Own module#Menuconfig]] - here a look at the results and the output of menuconfig. The configuration is saved in two different formats: * file .config for the menuconfig itself - ** it is used for including it into the makefile ** it incluences also the build process of the binary file ** definition auf makefile variables * file autoconfig.h - ** it is for including it in the compilation ** definition of C preprocessor macros and defines I thing the details of the configuration should become clear after doing the menuconfig and reading about the modules. May be I can explain some "core" configuration later. == make == The first steps in the build process are to get all the configuration information and build some source files which put it all together. Besides some usual unix tools like sed the m4 macro processor plays an important role. Even if it is not in the scope of this wiki, I added a very short intro here: [[m4 - very short intro]] === meta.m4 === If you have a look at the different source codes of the modules, you find at the bottom of the main c-file a comment section starting with "-- Ethersex META --". You find there m4 macros which are used to integrate the modul into the main program of ethersex. Details later. meta.m4 is the extraction and collection of these sections. The files which are used, are denfined by the makefile of each "module". Each C source files has to be added to the make var "y_SRC". A nice trick is used there by the use of ".config", where all the used and configured feature are assigned a "y" to make vars. i.e. MODULX_GENERAL_SUPPORT=y Then in the makefile of ModuleX: $(MODULX_GENERAL_SUPPORT)_SRC += file1.c file2.c ... If the module is not activated the files added to _SRC instead of y_SRC. === meta.c === Is generated by m4 macros. The inputs are: (controlled centrally in the Makefile!) * autoconfig.h *: is converted and each define line results into one m4 command line parameter of the form -Dconf_<parname> * scripts/meta_magic.m4 *: contains the framework for meta.c * protocols/ecmd/ecmd_magic.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * protocols/soap/soap_magic.m4 *: only if SOAP support is activated - make var $(SOAP_SUPPORT) must be set to "y" * meta.m4 *: see above * protocols/ecmd/ecmd_defs.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced by the make var ${named_pin_simple_files} *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced by the make var $(y_NP_SIMPLE_META_SRC) *: unconditional ... but contain the following files, if ECMD parser or SOAP support is activated: ** protocols/ecmd/ecmd_defs.m4 ** ${named_pin_simple_files} *: so I think it could be a small bug - if ECMD parser support is on, the files are added twice - may be this does not matter. ==== What is in ${named_pin_simple_files}? ==== That should be a chapter for itself - containing how the internals of defining pins works. In the default case that are probably the following files: * core/portio/np_simple.m4 * protocols/ecmd/np_simple_glue.m4 === meta.h === is also generated from m4 macros. Files used: * scripts/meta_header_magic.m4 *: framework of meta.h and macros. * meta.m4 meta.m4 is part of meta.c and meta.h - how is it possible, may someone ask. The answer: macros, which are not defined, eval to empty string. So it depends on the defined macros to what meta.m4 is expanded. More about the he interesting [[concept of meta]]. === pinning.c === The detailied concept of pinning will be descriped in an own chapter. At the moment is important to know that each processor has several ports which can have different functions and are connected sometimes to devices on the board already. If you connect your own hardware to the board which should be supported by an ethersex module you must configure the port(s) which are connects the hardware with the processor. Files from which pinning.c is build: * pinning/internals/header.m4 * pinning/controllers/<mcuname>.m4 *: mcuname is defined by make var MCU * pinning/internals/hackery_<mcuname>.m4 * pinning/hardware/<boardname>.m4 *: <boardname> is definned by make var HARDWARE * pinning/internals/footer.m4 * autoconfig.h *: is converted and each define line results into one m4 command line parameter of the form -Dconf_<parname> What you should realize is, the pinning.c file is independent from any module, so the connection of module and pinning must be defined in one of the mentioned files! [[Category:Development]] 2070d0fde0921cf9b16a7aa427ab5ed4afaef699 612 611 2012-05-17T17:31:03Z Tkaltenbrunner 475 /* meta.h */ wikitext text/x-wiki {{i18n|Configuration of Boards and Pins}} == Intro == This page will explain some of the details behind menuconfig. It is meant for developers who want to look behind the curtain or if someone wants to debug a modul which does not work or compile any more .... == make menuconfig == Integration of modules into menuconfig look is described on this page [[Own module#Menuconfig]] - here a look at the results and the output of menuconfig. The configuration is saved in two different formats: * file .config for the menuconfig itself - ** it is used for including it into the makefile ** it incluences also the build process of the binary file ** definition auf makefile variables * file autoconfig.h - ** it is for including it in the compilation ** definition of C preprocessor macros and defines I thing the details of the configuration should become clear after doing the menuconfig and reading about the modules. May be I can explain some "core" configuration later. == make == The first steps in the build process are to get all the configuration information and build some source files which put it all together. Besides some usual unix tools like sed the m4 macro processor plays an important role. Even if it is not in the scope of this wiki, I added a very short intro here: [[m4 - very short intro]] === meta.m4 === If you have a look at the different source codes of the modules, you find at the bottom of the main c-file a comment section starting with "-- Ethersex META --". You find there m4 macros which are used to integrate the modul into the main program of ethersex. Details later. meta.m4 is the extraction and collection of these sections. The files which are used, are denfined by the makefile of each "module". Each C source files has to be added to the make var "y_SRC". A nice trick is used there by the use of ".config", where all the used and configured feature are assigned a "y" to make vars. i.e. MODULX_GENERAL_SUPPORT=y Then in the makefile of ModuleX: $(MODULX_GENERAL_SUPPORT)_SRC += file1.c file2.c ... If the module is not activated the files added to _SRC instead of y_SRC. === meta.c === Is generated by m4 macros. The inputs are: (controlled centrally in the Makefile!) * autoconfig.h *: is converted and each define line results into one m4 command line parameter of the form -Dconf_<parname> * scripts/meta_magic.m4 *: contains the framework for meta.c * protocols/ecmd/ecmd_magic.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * protocols/soap/soap_magic.m4 *: only if SOAP support is activated - make var $(SOAP_SUPPORT) must be set to "y" * meta.m4 *: see above * protocols/ecmd/ecmd_defs.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced by the make var ${named_pin_simple_files} *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced by the make var $(y_NP_SIMPLE_META_SRC) *: unconditional ... but contain the following files, if ECMD parser or SOAP support is activated: ** protocols/ecmd/ecmd_defs.m4 ** ${named_pin_simple_files} *: so I think it could be a small bug - if ECMD parser support is on, the files are added twice - may be this does not matter. ==== What is in ${named_pin_simple_files}? ==== That should be a chapter for itself - containing how the internals of defining pins works. In the default case that are probably the following files: * core/portio/np_simple.m4 * protocols/ecmd/np_simple_glue.m4 === meta.h === is also generated from m4 macros. Files used: * scripts/meta_header_magic.m4 *: framework of meta.h and macros. * meta.m4 meta.m4 is part of meta.c and meta.h - how is it possible, may someone ask. The answer: macros, which are not defined, eval to empty string. So it depends on the defined macros to what meta.m4 is expanded. More about the interesting [[concept of meta]]. === pinning.c === The detailied concept of pinning will be descriped in an own chapter. At the moment is important to know that each processor has several ports which can have different functions and are connected sometimes to devices on the board already. If you connect your own hardware to the board which should be supported by an ethersex module you must configure the port(s) which are connects the hardware with the processor. Files from which pinning.c is build: * pinning/internals/header.m4 * pinning/controllers/<mcuname>.m4 *: mcuname is defined by make var MCU * pinning/internals/hackery_<mcuname>.m4 * pinning/hardware/<boardname>.m4 *: <boardname> is definned by make var HARDWARE * pinning/internals/footer.m4 * autoconfig.h *: is converted and each define line results into one m4 command line parameter of the form -Dconf_<parname> What you should realize is, the pinning.c file is independent from any module, so the connection of module and pinning must be defined in one of the mentioned files! [[Category:Development]] 31e7b81da9a24bb1208c6bee89bd7ac4efacecea 613 612 2012-05-17T17:33:14Z Tkaltenbrunner 475 /* pinning.c */ wikitext text/x-wiki {{i18n|Configuration of Boards and Pins}} == Intro == This page will explain some of the details behind menuconfig. It is meant for developers who want to look behind the curtain or if someone wants to debug a modul which does not work or compile any more .... == make menuconfig == Integration of modules into menuconfig look is described on this page [[Own module#Menuconfig]] - here a look at the results and the output of menuconfig. The configuration is saved in two different formats: * file .config for the menuconfig itself - ** it is used for including it into the makefile ** it incluences also the build process of the binary file ** definition auf makefile variables * file autoconfig.h - ** it is for including it in the compilation ** definition of C preprocessor macros and defines I thing the details of the configuration should become clear after doing the menuconfig and reading about the modules. May be I can explain some "core" configuration later. == make == The first steps in the build process are to get all the configuration information and build some source files which put it all together. Besides some usual unix tools like sed the m4 macro processor plays an important role. Even if it is not in the scope of this wiki, I added a very short intro here: [[m4 - very short intro]] === meta.m4 === If you have a look at the different source codes of the modules, you find at the bottom of the main c-file a comment section starting with "-- Ethersex META --". You find there m4 macros which are used to integrate the modul into the main program of ethersex. Details later. meta.m4 is the extraction and collection of these sections. The files which are used, are denfined by the makefile of each "module". Each C source files has to be added to the make var "y_SRC". A nice trick is used there by the use of ".config", where all the used and configured feature are assigned a "y" to make vars. i.e. MODULX_GENERAL_SUPPORT=y Then in the makefile of ModuleX: $(MODULX_GENERAL_SUPPORT)_SRC += file1.c file2.c ... If the module is not activated the files added to _SRC instead of y_SRC. === meta.c === Is generated by m4 macros. The inputs are: (controlled centrally in the Makefile!) * autoconfig.h *: is converted and each define line results into one m4 command line parameter of the form -Dconf_<parname> * scripts/meta_magic.m4 *: contains the framework for meta.c * protocols/ecmd/ecmd_magic.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * protocols/soap/soap_magic.m4 *: only if SOAP support is activated - make var $(SOAP_SUPPORT) must be set to "y" * meta.m4 *: see above * protocols/ecmd/ecmd_defs.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced by the make var ${named_pin_simple_files} *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced by the make var $(y_NP_SIMPLE_META_SRC) *: unconditional ... but contain the following files, if ECMD parser or SOAP support is activated: ** protocols/ecmd/ecmd_defs.m4 ** ${named_pin_simple_files} *: so I think it could be a small bug - if ECMD parser support is on, the files are added twice - may be this does not matter. ==== What is in ${named_pin_simple_files}? ==== That should be a chapter for itself - containing how the internals of defining pins works. In the default case that are probably the following files: * core/portio/np_simple.m4 * protocols/ecmd/np_simple_glue.m4 === meta.h === is also generated from m4 macros. Files used: * scripts/meta_header_magic.m4 *: framework of meta.h and macros. * meta.m4 meta.m4 is part of meta.c and meta.h - how is it possible, may someone ask. The answer: macros, which are not defined, eval to empty string. So it depends on the defined macros to what meta.m4 is expanded. More about the interesting [[concept of meta]]. === pinning.c === The detailied concept of pinning will be descriped in an own chapter. At the moment is important to know that each processor has several ports which can have different functions and are connected sometimes to devices on the board already. If you connect your own hardware to the board which should be supported by an ethersex module you must configure the port(s) which connects the hardware with the processor. Files from which pinning.c is build: * pinning/internals/header.m4 * pinning/controllers/<mcuname>.m4 *: mcuname is defined by the make var MCU * pinning/internals/hackery_<mcuname>.m4 * pinning/hardware/<boardname>.m4 *: <boardname> is definned by make var HARDWARE * pinning/internals/footer.m4 * autoconfig.h *: is converted and each define line results into one m4 command line parameter of the form -Dconf_<parname> What you should realize is, the pinning.c file is independent from any module, so the connection of module and pinning must be defined in one of the mentioned files! [[Category:Development]] 2278559011d03830431b291db51bfd00122a32d2 0 209 549 2012-05-01T17:50:24Z Tkaltenbrunner 475 Created page with "{{i18n:Concept of meta}} == Intro == With meta information in each module the main program is set up depending on the configuration. AT the end there will be a short exemaple of…" wikitext text/x-wiki {{i18n:Concept of meta}} == Intro == With meta information in each module the main program is set up depending on the configuration. AT the end there will be a short exemaple of such meta information. == meta.c == The creation of this file is mainly controlled by the file "meta_magic.m4". What is in the file? [[Category:Development]] 3d506ada6f6a96013009f7435a82e42c4565057b 550 549 2012-05-01T17:50:55Z Tkaltenbrunner 475 wikitext text/x-wiki {{i18n|Concept of meta}} == Intro == With meta information in each module the main program is set up depending on the configuration. AT the end there will be a short exemaple of such meta information. == meta.c == The creation of this file is mainly controlled by the file "meta_magic.m4". What is in the file? [[Category:Development]] 668d9bd571d4a86321b9c1c8256d4710db5b0f36 555 550 2012-05-01T18:37:22Z Tkaltenbrunner 475 wikitext text/x-wiki {{i18n|Concept of meta}} == Intro == With meta information in each module the main program is set up depending on the configuration. At the end there will be a short example of such meta information. == meta.c / meta_magic.m4 == The creation of this file is mainly controlled by the file "meta_magic.m4". What is in the file meta_magic.m4? === framework of the file meta.c === The framework consists of several divert sections, in which code of the used modules is injected. Only the idea of the injection is explained with the first injection point. The second section starts with "divert(initearly_divert)dnl" and contains the function "ethersex_meta_init", but the final closing brace of the function is missing. So if you define further divert sections with the index "initearly_divert", then it will be in the output before the closing brace and so part of "ethersex_meta_init". Therefore later in in the file some macros are defined - in this case it is named "initearly". This macros and some others are all defined the same way: define(`initearly',`dnl divert(inetearly_divert) $1 (); divert(-1)') So if the meta macro initearly(<module-initearly-functionname>) is used, the module initearly function will be called from the function ethersex_meta_init, because the function call will be in the output directly after the section. The closing brace of the function is part of the next section "divert(net_init_divert)". [[Category:Development]] 178f1abf15865f69bfcd26e1b13b4338569083e3 556 555 2012-05-01T18:57:09Z Tkaltenbrunner 475 wikitext text/x-wiki {{i18n|Concept of meta}} == Intro == With meta information in each module the main program is set up depending on the configuration. At the end there will be a short example of such meta information. == meta.c / meta_magic.m4 == The creation of this file is mainly controlled by the file "meta_magic.m4". What is in the file meta_magic.m4? === framework for the file meta.c === The framework consists of several divert sections, in which code of the used modules is injected. Only the idea of the injection is explained with the first injection point. The second section starts with "divert(initearly_divert)dnl" and contains the function "ethersex_meta_init", but the final closing brace of the function is missing. So if you define further divert sections with the index "initearly_divert", then it will be in the output before the closing brace and so part of "ethersex_meta_init". Therefore later in in the file some macros are defined - in this case it is named "initearly". This macros and some others are all defined the same way: define(`initearly',`dnl divert(inetearly_divert) $1 (); divert(-1)') So if the meta macro initearly(<module-initearly-functionname>) is used, the module initearly function will be called from the function ethersex_meta_init, because the function call will be in the output directly after the section. The closing brace of the function is part of the next section "divert(net_init_divert)". === structure of meta.c === meta.c itself contains several functions, which are called at important points in the firmware: * ethersex_meta_init *: is called in the startup before the pins are initialized * ethersex_meta_startup *: is called before the main loop starts * ethersex_meta_mainloop *: is called in the main loop - injected functions should do only short processings or reset the watchdog by thereselfs ... to be continued ... [[Category:Development]] fba7c54ed219786fb57dd693f2baec770f49904f 614 556 2012-05-17T17:38:26Z Tkaltenbrunner 475 /* Intro */ wikitext text/x-wiki {{i18n|Concept of meta}} == Intro == With meta information in each module the main program is set up depending on the configuration. At the end there will be a short example of such meta information. If you continue to read, you should understand this concept: [[M4 - very short intro (Deutsch)#divert]] == meta.c / meta_magic.m4 == The creation of this file is mainly controlled by the file "meta_magic.m4". What is in the file meta_magic.m4? === framework for the file meta.c === The framework consists of several divert sections, in which code of the used modules is injected. Only the idea of the injection is explained with the first injection point. The second section starts with "divert(initearly_divert)dnl" and contains the function "ethersex_meta_init", but the final closing brace of the function is missing. So if you define further divert sections with the index "initearly_divert", then it will be in the output before the closing brace and so part of "ethersex_meta_init". Therefore later in in the file some macros are defined - in this case it is named "initearly". This macros and some others are all defined the same way: define(`initearly',`dnl divert(inetearly_divert) $1 (); divert(-1)') So if the meta macro initearly(<module-initearly-functionname>) is used, the module initearly function will be called from the function ethersex_meta_init, because the function call will be in the output directly after the section. The closing brace of the function is part of the next section "divert(net_init_divert)". === structure of meta.c === meta.c itself contains several functions, which are called at important points in the firmware: * ethersex_meta_init *: is called in the startup before the pins are initialized * ethersex_meta_startup *: is called before the main loop starts * ethersex_meta_mainloop *: is called in the main loop - injected functions should do only short processings or reset the watchdog by thereselfs ... to be continued ... [[Category:Development]] 3228eea5a637afa4d5ca0e1e9bc10bc66d67a1e1 615 614 2012-05-17T17:40:16Z Tkaltenbrunner 475 /* Intro */ wikitext text/x-wiki {{i18n|Concept of meta}} == Intro == With meta information in each module the main program is set up depending on the configuration. At the end there will be a short example of such meta information. If you continue to read, you should understand this concept: [[M4 - very short intro (Deutsch)#divert]] Also have a look at the files explained while reading - that will help. == meta.c / meta_magic.m4 == The creation of this file is mainly controlled by the file "meta_magic.m4". What is in the file meta_magic.m4? === framework for the file meta.c === The framework consists of several divert sections, in which code of the used modules is injected. Only the idea of the injection is explained with the first injection point. The second section starts with "divert(initearly_divert)dnl" and contains the function "ethersex_meta_init", but the final closing brace of the function is missing. So if you define further divert sections with the index "initearly_divert", then it will be in the output before the closing brace and so part of "ethersex_meta_init". Therefore later in in the file some macros are defined - in this case it is named "initearly". This macros and some others are all defined the same way: define(`initearly',`dnl divert(inetearly_divert) $1 (); divert(-1)') So if the meta macro initearly(<module-initearly-functionname>) is used, the module initearly function will be called from the function ethersex_meta_init, because the function call will be in the output directly after the section. The closing brace of the function is part of the next section "divert(net_init_divert)". === structure of meta.c === meta.c itself contains several functions, which are called at important points in the firmware: * ethersex_meta_init *: is called in the startup before the pins are initialized * ethersex_meta_startup *: is called before the main loop starts * ethersex_meta_mainloop *: is called in the main loop - injected functions should do only short processings or reset the watchdog by thereselfs ... to be continued ... [[Category:Development]] 4030dd99bc9922f199d5b4292bb23ec9325299c7 0 208 551 534 2012-05-01T18:04:26Z Tkaltenbrunner 475 /* "Kontrol-Strukturen" */ wikitext text/x-wiki == Einleitung == Die offizielle Doku gibt es hier: http://www.gnu.org/software/m4/manual/index.html Hier noch ein ganze kurze Einführung: Von der Idee her, ist es mit dem C-Präprocessor vergleichbar, der ebenfalls Macro-Ersetzungen durchführt und das Ergebnis an den C-Compiler weiterleitet. Bei m4 ist das Ergebnisse lediglich der Text, den die Macro-Ersetzungen ergeben. Wie es genau funktioniert, aber unbedingt nachlesen, da es manchmal auch auf die Feinheiten ankommt. Kommentare werden mit # wie in C gekennzeichnet. Es gibt keinen "Befehlsterminator" wie z.B. ein Semikolon. Ersetzungen werden aber ähnlich wie ein Funktionen in einer Programmiersprache aufgerufen. Wichtig ist auch die Quotierung mit ` und ' , die das Verhalten bei der Macro-Expandierung entscheidend beeinflusst. siehe hier und folgende http://www.gnu.org/software/m4/manual/m4.html#Quoting-Arguments == Macro definieren == Im Gegensatz zum C-Präprocessor wird hier ein sogenanntes "builtin" benutzt: define(name, [expansion]) Zu beachten: werden die Argumente nicht quotiert, kann hier schon die Macro-Erweiterung zuschlagen, was dann zu unerwünschten Ergebnissen führen kann. Mit den "Pseudo-Variablen" $1, $2, etc. kann man die Argumente des Macros in der Expansion referenzieren. Im Gegensatz zum C-Präprozessor, der überwiegend mit benannten Parametern arbeitet. * $* - alle Argumente * $@ - alle Argumente quotiert - Im Gegensatz zur vorhergehenden Variante werden die Argumente nicht weiter expandiert. * $# - Anzahl der Argumente == Kontrol-Strukturen == Hiermit sind bedingte Ausführung und Schleifen gemeint. * ifdef(name, string1, [string2]) *: - wenn name definiert ist, dann ist das Ergebnis string1, sonst string2 * ifelse(string1, string2, equal1, string3, string4, equal2, ..., [not_equal]) *: - wenn string1 = string2, dann equal1, sonst if string3 = string4, dann equal2, sonst ..., sonst not_equal * join oder joinall([separator], [args....]) *: - args zusammenfügen, Separator dazwischen setzen. Bei joinall wird immer der Separator gesetzt - auch wenn ein Argument leer ist. * Rekursive Macro-Definitionen sind auch möglich - hilfreich dabei die shift Funktion, die jeweils das erste Argument abschneidet. * forloop (iterator, start, end, text) *:- iterator muss ein gültiger Macroname sein, Start und Ende ganze Zahlen, der Text wird gemäß der Schleifendurchläufe ersetzt. * foreach (iterator, paren-list, text) / foreachq (iterator, paren-list, text) *: - jedes Argument der parent-list wird an den Iterator gebunden und dann eine Ersetzung für Text ausgeführt. == divert == Da dieses Konstrukt häufig in Ethersex eingesetzt wird, hier noch ein paar Extra-Bemerkungen: Mit divert(<ausgabeidx>) wird ein Text-Abschnitt begonnen, der an der durch <ausgabeindex> definierten Stelle in die Ausgabe-Text eingefügt wird. <ausgabeidx> ist eine ganze, positive Zahl. Abschnitt 1 wird vor 2, 2 wird vor 3, usw. ausgegeben. Dabei spielt es keine Rolle, in welcher Reiehnfolge die Abschnitt in der m4-Quelldatei definiert werden. Der Textabschnitt wird durch ein weiteres "divert" beendet, wobei "divert(-1)" dafür sorgt, dass kein neuer Abschnitt beginnt. Sind mehrer Abschnitte mit dem gleichen <ausgabeidx> definiert, so werden sie mit der Reihenfolge ihrer Defnition ausgegeben. === Beispiel: === divert(3)dnl Das ist Abschnitt 3 divert(2) Das ist Abschnitt 2a divert(1)dnl Das ist Abschnitt 1 divert(2) Das ist Abschnitt 2b divert(-1) Die Ausgabe sind dann wie folgt aus: Das ist Abschnitt 1 Das ist Abschnitt 2a Das ist Abschnitt 2b Das ist Abschnitt 3 Bemerkung: die Sprache ist sehr mächtig und man kann "Wildes" konstruieren, dass man nach 2 Tagen selber nicht mehr versteht ;-) == Wichtiges == * dnl - "Discard to next line" - Schließt die Zeile ab - alles nachfolgende wird ignoriert. * divert - der nachfolgende Text wird ausgegeben. Der Text endet beim erneuten auftauchen des Wortes "divert". Das Wort selber kann man deshalb nur mit im Handbuch beschriebenen Tricks im Text verwenden werden .... 865d0698db0f2f884a18dc3d82b41a56206a7021 552 551 2012-05-01T18:05:15Z Tkaltenbrunner 475 /* Beispiel: */ wikitext text/x-wiki == Einleitung == Die offizielle Doku gibt es hier: http://www.gnu.org/software/m4/manual/index.html Hier noch ein ganze kurze Einführung: Von der Idee her, ist es mit dem C-Präprocessor vergleichbar, der ebenfalls Macro-Ersetzungen durchführt und das Ergebnis an den C-Compiler weiterleitet. Bei m4 ist das Ergebnisse lediglich der Text, den die Macro-Ersetzungen ergeben. Wie es genau funktioniert, aber unbedingt nachlesen, da es manchmal auch auf die Feinheiten ankommt. Kommentare werden mit # wie in C gekennzeichnet. Es gibt keinen "Befehlsterminator" wie z.B. ein Semikolon. Ersetzungen werden aber ähnlich wie ein Funktionen in einer Programmiersprache aufgerufen. Wichtig ist auch die Quotierung mit ` und ' , die das Verhalten bei der Macro-Expandierung entscheidend beeinflusst. siehe hier und folgende http://www.gnu.org/software/m4/manual/m4.html#Quoting-Arguments == Macro definieren == Im Gegensatz zum C-Präprocessor wird hier ein sogenanntes "builtin" benutzt: define(name, [expansion]) Zu beachten: werden die Argumente nicht quotiert, kann hier schon die Macro-Erweiterung zuschlagen, was dann zu unerwünschten Ergebnissen führen kann. Mit den "Pseudo-Variablen" $1, $2, etc. kann man die Argumente des Macros in der Expansion referenzieren. Im Gegensatz zum C-Präprozessor, der überwiegend mit benannten Parametern arbeitet. * $* - alle Argumente * $@ - alle Argumente quotiert - Im Gegensatz zur vorhergehenden Variante werden die Argumente nicht weiter expandiert. * $# - Anzahl der Argumente == Kontrol-Strukturen == Hiermit sind bedingte Ausführung und Schleifen gemeint. * ifdef(name, string1, [string2]) *: - wenn name definiert ist, dann ist das Ergebnis string1, sonst string2 * ifelse(string1, string2, equal1, string3, string4, equal2, ..., [not_equal]) *: - wenn string1 = string2, dann equal1, sonst if string3 = string4, dann equal2, sonst ..., sonst not_equal * join oder joinall([separator], [args....]) *: - args zusammenfügen, Separator dazwischen setzen. Bei joinall wird immer der Separator gesetzt - auch wenn ein Argument leer ist. * Rekursive Macro-Definitionen sind auch möglich - hilfreich dabei die shift Funktion, die jeweils das erste Argument abschneidet. * forloop (iterator, start, end, text) *:- iterator muss ein gültiger Macroname sein, Start und Ende ganze Zahlen, der Text wird gemäß der Schleifendurchläufe ersetzt. * foreach (iterator, paren-list, text) / foreachq (iterator, paren-list, text) *: - jedes Argument der parent-list wird an den Iterator gebunden und dann eine Ersetzung für Text ausgeführt. == divert == Da dieses Konstrukt häufig in Ethersex eingesetzt wird, hier noch ein paar Extra-Bemerkungen: Mit divert(<ausgabeidx>) wird ein Text-Abschnitt begonnen, der an der durch <ausgabeindex> definierten Stelle in die Ausgabe-Text eingefügt wird. <ausgabeidx> ist eine ganze, positive Zahl. Abschnitt 1 wird vor 2, 2 wird vor 3, usw. ausgegeben. Dabei spielt es keine Rolle, in welcher Reiehnfolge die Abschnitt in der m4-Quelldatei definiert werden. Der Textabschnitt wird durch ein weiteres "divert" beendet, wobei "divert(-1)" dafür sorgt, dass kein neuer Abschnitt beginnt. Sind mehrer Abschnitte mit dem gleichen <ausgabeidx> definiert, so werden sie mit der Reihenfolge ihrer Defnition ausgegeben. === Beispiel: === divert(3)dnl Das ist Abschnitt 3 divert(2)dnl Das ist Abschnitt 2a divert(1)dnl Das ist Abschnitt 1 divert(2)dnl Das ist Abschnitt 2b divert(-1)dnl Die Ausgabe sind dann wie folgt aus: Das ist Abschnitt 1 Das ist Abschnitt 2a Das ist Abschnitt 2b Das ist Abschnitt 3 Bemerkung: die Sprache ist sehr mächtig und man kann "Wildes" konstruieren, dass man nach 2 Tagen selber nicht mehr versteht ;-) == Wichtiges == * dnl - "Discard to next line" - Schließt die Zeile ab - alles nachfolgende wird ignoriert. * divert - der nachfolgende Text wird ausgegeben. Der Text endet beim erneuten auftauchen des Wortes "divert". Das Wort selber kann man deshalb nur mit im Handbuch beschriebenen Tricks im Text verwenden werden .... e0c0b097ebd1c914e7f198faecba354643b3a91e 553 552 2012-05-01T18:07:17Z Tkaltenbrunner 475 /* Wichtiges */ wikitext text/x-wiki == Einleitung == Die offizielle Doku gibt es hier: http://www.gnu.org/software/m4/manual/index.html Hier noch ein ganze kurze Einführung: Von der Idee her, ist es mit dem C-Präprocessor vergleichbar, der ebenfalls Macro-Ersetzungen durchführt und das Ergebnis an den C-Compiler weiterleitet. Bei m4 ist das Ergebnisse lediglich der Text, den die Macro-Ersetzungen ergeben. Wie es genau funktioniert, aber unbedingt nachlesen, da es manchmal auch auf die Feinheiten ankommt. Kommentare werden mit # wie in C gekennzeichnet. Es gibt keinen "Befehlsterminator" wie z.B. ein Semikolon. Ersetzungen werden aber ähnlich wie ein Funktionen in einer Programmiersprache aufgerufen. Wichtig ist auch die Quotierung mit ` und ' , die das Verhalten bei der Macro-Expandierung entscheidend beeinflusst. siehe hier und folgende http://www.gnu.org/software/m4/manual/m4.html#Quoting-Arguments == Macro definieren == Im Gegensatz zum C-Präprocessor wird hier ein sogenanntes "builtin" benutzt: define(name, [expansion]) Zu beachten: werden die Argumente nicht quotiert, kann hier schon die Macro-Erweiterung zuschlagen, was dann zu unerwünschten Ergebnissen führen kann. Mit den "Pseudo-Variablen" $1, $2, etc. kann man die Argumente des Macros in der Expansion referenzieren. Im Gegensatz zum C-Präprozessor, der überwiegend mit benannten Parametern arbeitet. * $* - alle Argumente * $@ - alle Argumente quotiert - Im Gegensatz zur vorhergehenden Variante werden die Argumente nicht weiter expandiert. * $# - Anzahl der Argumente == Kontrol-Strukturen == Hiermit sind bedingte Ausführung und Schleifen gemeint. * ifdef(name, string1, [string2]) *: - wenn name definiert ist, dann ist das Ergebnis string1, sonst string2 * ifelse(string1, string2, equal1, string3, string4, equal2, ..., [not_equal]) *: - wenn string1 = string2, dann equal1, sonst if string3 = string4, dann equal2, sonst ..., sonst not_equal * join oder joinall([separator], [args....]) *: - args zusammenfügen, Separator dazwischen setzen. Bei joinall wird immer der Separator gesetzt - auch wenn ein Argument leer ist. * Rekursive Macro-Definitionen sind auch möglich - hilfreich dabei die shift Funktion, die jeweils das erste Argument abschneidet. * forloop (iterator, start, end, text) *:- iterator muss ein gültiger Macroname sein, Start und Ende ganze Zahlen, der Text wird gemäß der Schleifendurchläufe ersetzt. * foreach (iterator, paren-list, text) / foreachq (iterator, paren-list, text) *: - jedes Argument der parent-list wird an den Iterator gebunden und dann eine Ersetzung für Text ausgeführt. == divert == Da dieses Konstrukt häufig in Ethersex eingesetzt wird, hier noch ein paar Extra-Bemerkungen: Mit divert(<ausgabeidx>) wird ein Text-Abschnitt begonnen, der an der durch <ausgabeindex> definierten Stelle in die Ausgabe-Text eingefügt wird. <ausgabeidx> ist eine ganze, positive Zahl. Abschnitt 1 wird vor 2, 2 wird vor 3, usw. ausgegeben. Dabei spielt es keine Rolle, in welcher Reiehnfolge die Abschnitt in der m4-Quelldatei definiert werden. Der Textabschnitt wird durch ein weiteres "divert" beendet, wobei "divert(-1)" dafür sorgt, dass kein neuer Abschnitt beginnt. Sind mehrer Abschnitte mit dem gleichen <ausgabeidx> definiert, so werden sie mit der Reihenfolge ihrer Defnition ausgegeben. === Beispiel: === divert(3)dnl Das ist Abschnitt 3 divert(2)dnl Das ist Abschnitt 2a divert(1)dnl Das ist Abschnitt 1 divert(2)dnl Das ist Abschnitt 2b divert(-1)dnl Die Ausgabe sind dann wie folgt aus: Das ist Abschnitt 1 Das ist Abschnitt 2a Das ist Abschnitt 2b Das ist Abschnitt 3 Bemerkung: die Sprache ist sehr mächtig und man kann "Wildes" konstruieren, dass man nach 2 Tagen selber nicht mehr versteht ;-) == Wichtiges == * dnl - "Discard to next line" - Schließt die Zeile ab - alles nachfolgende wird ignoriert. * changecom(<newcomment-start>) - ändert das Kommentarzeichen auf die angegebene Zeichenfolge (Defualt: #) 8dee198831cbdfbedc82ee6d858d3d18f8f1d1bf 554 553 2012-05-01T18:10:38Z Tkaltenbrunner 475 /* divert */ wikitext text/x-wiki == Einleitung == Die offizielle Doku gibt es hier: http://www.gnu.org/software/m4/manual/index.html Hier noch ein ganze kurze Einführung: Von der Idee her, ist es mit dem C-Präprocessor vergleichbar, der ebenfalls Macro-Ersetzungen durchführt und das Ergebnis an den C-Compiler weiterleitet. Bei m4 ist das Ergebnisse lediglich der Text, den die Macro-Ersetzungen ergeben. Wie es genau funktioniert, aber unbedingt nachlesen, da es manchmal auch auf die Feinheiten ankommt. Kommentare werden mit # wie in C gekennzeichnet. Es gibt keinen "Befehlsterminator" wie z.B. ein Semikolon. Ersetzungen werden aber ähnlich wie ein Funktionen in einer Programmiersprache aufgerufen. Wichtig ist auch die Quotierung mit ` und ' , die das Verhalten bei der Macro-Expandierung entscheidend beeinflusst. siehe hier und folgende http://www.gnu.org/software/m4/manual/m4.html#Quoting-Arguments == Macro definieren == Im Gegensatz zum C-Präprocessor wird hier ein sogenanntes "builtin" benutzt: define(name, [expansion]) Zu beachten: werden die Argumente nicht quotiert, kann hier schon die Macro-Erweiterung zuschlagen, was dann zu unerwünschten Ergebnissen führen kann. Mit den "Pseudo-Variablen" $1, $2, etc. kann man die Argumente des Macros in der Expansion referenzieren. Im Gegensatz zum C-Präprozessor, der überwiegend mit benannten Parametern arbeitet. * $* - alle Argumente * $@ - alle Argumente quotiert - Im Gegensatz zur vorhergehenden Variante werden die Argumente nicht weiter expandiert. * $# - Anzahl der Argumente == Kontrol-Strukturen == Hiermit sind bedingte Ausführung und Schleifen gemeint. * ifdef(name, string1, [string2]) *: - wenn name definiert ist, dann ist das Ergebnis string1, sonst string2 * ifelse(string1, string2, equal1, string3, string4, equal2, ..., [not_equal]) *: - wenn string1 = string2, dann equal1, sonst if string3 = string4, dann equal2, sonst ..., sonst not_equal * join oder joinall([separator], [args....]) *: - args zusammenfügen, Separator dazwischen setzen. Bei joinall wird immer der Separator gesetzt - auch wenn ein Argument leer ist. * Rekursive Macro-Definitionen sind auch möglich - hilfreich dabei die shift Funktion, die jeweils das erste Argument abschneidet. * forloop (iterator, start, end, text) *:- iterator muss ein gültiger Macroname sein, Start und Ende ganze Zahlen, der Text wird gemäß der Schleifendurchläufe ersetzt. * foreach (iterator, paren-list, text) / foreachq (iterator, paren-list, text) *: - jedes Argument der parent-list wird an den Iterator gebunden und dann eine Ersetzung für Text ausgeführt. == divert == Da dieses Konstrukt häufig in Ethersex eingesetzt wird, hier noch ein paar Extra-Bemerkungen: Mit divert(<ausgabeidx>) wird ein Text-Abschnitt begonnen, der an der durch <ausgabeindex> definierten Stelle in die Ausgabe-Text eingefügt wird. <ausgabeidx> ist eine ganze, positive Zahl. Abschnitt 1 wird vor 2, 2 wird vor 3, usw. ausgegeben. Dabei spielt es keine Rolle, in welcher Reiehnfolge die Abschnitt in der m4-Quelldatei definiert werden. Der Textabschnitt wird durch ein weiteres "divert" beendet, wobei "divert(-1)" dafür sorgt, dass kein neuer Abschnitt beginnt. Sind mehrer Abschnitte mit dem gleichen <ausgabeidx> definiert, so werden sie mit der Reihenfolge ihrer Defnition ausgegeben. === Beispiel: === divert(3)dnl Das ist Abschnitt 3 divert(2)dnl Das ist Abschnitt 2a divert(1)dnl Das ist Abschnitt 1 divert(2)dnl Das ist Abschnitt 2b divert(-1)dnl Die Ausgabe sind dann wie folgt aus: Das ist Abschnitt 1 Das ist Abschnitt 2a Das ist Abschnitt 2b Das ist Abschnitt 3 Bemerkung: die Sprache ist sehr mächtig und man kann "Wildes" konstruieren, dass man nach 2 Tagen selber nicht mehr versteht ;-) == Wichtiges == * dnl - "Discard to next line" - Schließt die Zeile ab - alles nachfolgende wird ignoriert. * changecom(<newcomment-start>) - ändert das Kommentarzeichen auf die angegebene Zeichenfolge (Defualt: #) a4578fef7fe497355991e5685532a33c1f4d0b00 0 183 557 480 2012-05-03T10:12:47Z Joe 146 +modul template wikitext text/x-wiki {{i18n|I2C}} {{Module |NAME=I2C |MENUCONFIG={{I/O}}->I2C Master Support |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6= - |DEPENDS= - |REQUIRES= CONFIG_EXPERIMENTAL |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/i2c/master https://github.com/ethersex/ethersex/tree/master/hardware/i2c/master] }} Der I2C-Bus (Inter Integrated Circuit) ist ein einfacher Zweidraht-Bus, der für die Kommunikation zwischen ICs innerhalb eines größeren Systems verwendet wird. Insbesondere bietet er sich an zur Kommunikation zwischen Microcontrollern und Peripheriegeräten. Das [[Ethersex]]-System kann sowohl als Master als auch als Slave in einem I2C-Bus arbeiten. In der Atmel-Dokumentation wird I2C als TWI (Two Wire Interface) geführt. ==Master Mode== Im Master-Mode kann das Ethersex-System auf angeschlossene I2C-Slaves zugreifen. Unterstützt werden im Moment: * 24cXX EEPROMs (Als Storage Backend für das Virtuelle Dateisystem) * LM75 Temperatursensoren * PCA9531 8 bit LED Dimmer * PCF8574x Port Extension ==Slave Mode== * Kann per I2C auf die [[ECMD (Deutsch) | ECMD ]] Schnittstelle zugegriffen werden. * In menuconfig -> Protocols -> ECMD -> I2C aktivieren [[I2C/Slave Example (Deutsch) | Beispielimplementierung]] mit Ethersex (Slave) und einem zweiten AVR (Master). ==Anschluss== Die Leitungen SCL (Clock) und SDA (Data) liegen als "Alternate Function" auf I/O Leitungen der Controller. Beim ATmega32 sind dies PC0 (SCL) und PC1 (SDA). ===Etherrape=== Beim [[Etherrape]] ist der I2C-Bus auf einem separaten Steckverbinder herausgeführt. ===Pollin AVR-NET-IO=== Beim Pollin [[AVR-NET-IO]] liegen die Leitungen des Ports C auf J3, dem 25poligen SUB-D Steckverbinder. Dort lassen sich auch Versorgungsspannung und Masse für die angeschlossenen Slaves abgreifen: {|class=wikitable !Pin !Funktion |- |2 |PC0 (SCL) |- |3 |PC1 (SDA) |- |15 |5V |- |18 |GND |} ==Konfiguration== Die Leitungen sind fest vorgegeben, daher muss keine Konfiguration des Pinnings erfolgen. Die Einstellungen für den Master-Mode finden sich unter "I/O support", "I2C Master Support". == ECMD == = I2C = Mittels "i2c detect" werden die gefundenen I2C Adressen aufgelistet i2c detect detected at: 0x20 (32) detected at: 0x48 (72) detected at: 0x60 (96) Mit den allgemeinen I2C-Kommandos können alle I2C-Chips angesprochen werden. Mit dem Befehl i2c wbb 72 81 wird z. B. die Temperatur-Konvertierung auf einem DS1631 gestartet. Geschrieben wird ein Byte mit dem Wert 81 an den Chip mit der Adresse 72. Mit dem Befehl i2c rwd 72 170 wird ein Word von der Adresse 170 des Chips mit der Adresse 72 gelesen. Damit wird die Temperatur des DS1631 ausgelesen. Die Umrechung muß man dann per Hand durchführen. = LM75 = Um den LM75 Temperatursensor auszulesen (Basisadresse 0x48) muss die IC Adresse angegeben werden. In diesem Falle ist das "0" weil die IC Adresse a0 bis a2 auf Masse gesetzt werden. -> binär 000 = 0 lm75 0 21.5 = DS1631 = Ein DS1631 Temperatursensor muß nach dem Einschalten der Stromversorgung erst aktiviert werden. Der erste DS1631 mit der Adresse 0x48 hat im Befehl die Adresse 0. Mit dem folgenden Befehl wird die Temperatur-Konvertierung eingeschaltet: ds1631 convert 0 1 Jetzt kann die Temperatur ausgelesen werden. Die Genauigkeit beträgt immer die vollen 12bits. ds1631 temp 0 22.875 Wahrscheinlich können auch DS1621-Sensoren ausgelesen werden, das wurde aber noch nicht getestet! = PCF8574 = Für die Porterweiterung gilt das Schema "pcf8574x read adresse chip" wobei die adresse 0-7 sein kann, und chip "0" oder "1", je nachdem ob man den pcf8574 oder den pcf8574A benutzt. pcf8574x read 0 0 FFFF Schalten von Ausgängen mit Wert 0xF0 am PCF8574 mit Adresse 5 (Das bedeutet das a0=1 und a2=1 ist, ergo 101) d.h. die ersten 4 Ausgänge werden auf "1" die anderen 4 Ausgänge auf "0" gesetzt. pcf8574x set 5 0 F0 [[Category:Ethersex]] [[Category:StepByStep]] [[Category:I2C]] [[Category:ECMD]] 424f1709a521542acb3d88f1aeb0e1d17747fce2 566 557 2012-05-03T10:54:14Z Joe 146 +modul template wikitext text/x-wiki {{i18n|I2C}} {{Module |NAME=I2C |MENUCONFIG={{I/O}}-{{I2C Master}} |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6= - |DEPENDS= - |REQUIRES= CONFIG_EXPERIMENTAL |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/i2c/master https://github.com/ethersex/ethersex/tree/master/hardware/i2c/master] }} Der I2C-Bus (Inter Integrated Circuit) ist ein einfacher Zweidraht-Bus, der für die Kommunikation zwischen ICs innerhalb eines größeren Systems verwendet wird. Insbesondere bietet er sich an zur Kommunikation zwischen Microcontrollern und Peripheriegeräten. Das [[Ethersex]]-System kann sowohl als Master als auch als Slave in einem I2C-Bus arbeiten. In der Atmel-Dokumentation wird I2C als TWI (Two Wire Interface) geführt. ==Master Mode== Im Master-Mode kann das Ethersex-System auf angeschlossene I2C-Slaves zugreifen. Unterstützt werden im Moment: * 24cXX EEPROMs (Als Storage Backend für das Virtuelle Dateisystem) * LM75 Temperatursensoren * PCA9531 8 bit LED Dimmer * PCF8574x Port Extension ==Slave Mode== * Kann per I2C auf die [[ECMD (Deutsch) | ECMD ]] Schnittstelle zugegriffen werden. * In menuconfig -> Protocols -> ECMD -> I2C aktivieren [[I2C/Slave Example (Deutsch) | Beispielimplementierung]] mit Ethersex (Slave) und einem zweiten AVR (Master). ==Anschluss== Die Leitungen SCL (Clock) und SDA (Data) liegen als "Alternate Function" auf I/O Leitungen der Controller. Beim ATmega32 sind dies PC0 (SCL) und PC1 (SDA). ===Etherrape=== Beim [[Etherrape]] ist der I2C-Bus auf einem separaten Steckverbinder herausgeführt. ===Pollin AVR-NET-IO=== Beim Pollin [[AVR-NET-IO]] liegen die Leitungen des Ports C auf J3, dem 25poligen SUB-D Steckverbinder. Dort lassen sich auch Versorgungsspannung und Masse für die angeschlossenen Slaves abgreifen: {|class=wikitable !Pin !Funktion |- |2 |PC0 (SCL) |- |3 |PC1 (SDA) |- |15 |5V |- |18 |GND |} ==Konfiguration== Die Leitungen sind fest vorgegeben, daher muss keine Konfiguration des Pinnings erfolgen. Die Einstellungen für den Master-Mode finden sich unter "I/O support", "I2C Master Support". == ECMD == = I2C = Mittels "i2c detect" werden die gefundenen I2C Adressen aufgelistet i2c detect detected at: 0x20 (32) detected at: 0x48 (72) detected at: 0x60 (96) Mit den allgemeinen I2C-Kommandos können alle I2C-Chips angesprochen werden. Mit dem Befehl i2c wbb 72 81 wird z. B. die Temperatur-Konvertierung auf einem DS1631 gestartet. Geschrieben wird ein Byte mit dem Wert 81 an den Chip mit der Adresse 72. Mit dem Befehl i2c rwd 72 170 wird ein Word von der Adresse 170 des Chips mit der Adresse 72 gelesen. Damit wird die Temperatur des DS1631 ausgelesen. Die Umrechung muß man dann per Hand durchführen. = LM75 = Um den LM75 Temperatursensor auszulesen (Basisadresse 0x48) muss die IC Adresse angegeben werden. In diesem Falle ist das "0" weil die IC Adresse a0 bis a2 auf Masse gesetzt werden. -> binär 000 = 0 lm75 0 21.5 = DS1631 = Ein DS1631 Temperatursensor muß nach dem Einschalten der Stromversorgung erst aktiviert werden. Der erste DS1631 mit der Adresse 0x48 hat im Befehl die Adresse 0. Mit dem folgenden Befehl wird die Temperatur-Konvertierung eingeschaltet: ds1631 convert 0 1 Jetzt kann die Temperatur ausgelesen werden. Die Genauigkeit beträgt immer die vollen 12bits. ds1631 temp 0 22.875 Wahrscheinlich können auch DS1621-Sensoren ausgelesen werden, das wurde aber noch nicht getestet! = PCF8574 = Für die Porterweiterung gilt das Schema "pcf8574x read adresse chip" wobei die adresse 0-7 sein kann, und chip "0" oder "1", je nachdem ob man den pcf8574 oder den pcf8574A benutzt. pcf8574x read 0 0 FFFF Schalten von Ausgängen mit Wert 0xF0 am PCF8574 mit Adresse 5 (Das bedeutet das a0=1 und a2=1 ist, ergo 101) d.h. die ersten 4 Ausgänge werden auf "1" die anderen 4 Ausgänge auf "0" gesetzt. pcf8574x set 5 0 F0 [[Category:Ethersex]] [[Category:StepByStep]] [[Category:I2C]] [[Category:ECMD]] cc80de0ef86dfc3c2a25cd9c5446966cbcf8358f 10 210 558 2012-05-03T10:21:35Z Joe 146 +Experimental Modul Template wikitext text/x-wiki <div style="text-align:center;background-color: #2da045;color: #FFFFFF;">Experimental</div> [[Category:Experimental Module| ]] 164a1e75357165cf8d8159e4a7d2dbcb6bcbb1b1 10 15 559 69 2012-05-03T10:25:34Z Joe 146 +Experimental Modul Status wikitext text/x-wiki <onlyinclude>{| style="float:right;margin:1em 0 1em 1em; border:1px #AAA solid;background: #f9f9f9;width:330px; font-size:95%;margin-top:0px;" !colspan="2" style="background-color:#CEDAF2; text-align:center"| {{#if: {{{NAME|}}}|<big>{{{NAME}}}</big>|<big>{{PAGENAME}}</big>}} |- {{#if: {{{STATUS|}}}| {{!}} style="vertical-align:top;" {{!}}Status {{!}} {{{STATUS}}} }} |- {{#if: {{{MENUCONFIG|}}}| {{!}} style="vertical-align:top;" {{!}}menuconfig {{!}} {{{MENUCONFIG}}} }} |- {{#if: {{{PINNING|}}}| {{!}} style="vertical-align:top;" {{!}}Pinning {{!}} {{{PINNING}}} }} |- {{#if: {{{ECMD|}}}| {{!}} style="vertical-align:top;" {{!}}Ecmd {{!}} {{{ECMD}}} }} |- {{#if: {{{CONTROL6|}}}| {{!}} style="vertical-align:top;" {{!}}Control6 {{!}} {{{CONTROL6}}} }} |- {{#if: {{{DEPENDS|}}}| {{!}} style="vertical-align:top;" {{!}}Depends on {{!}} {{{DEPENDS}}} }} |- {{#if: {{{REQUIRES|}}}| {{!}} style="vertical-align:top;" {{!}}Requires {{!}} {{{REQUIRES}}} }} |- {{#if: {{{CODE|}}}| {{!}} style="vertical-align:top;" {{!}}Code {{!}} {{{CODE}}} }} |- |}</onlyinclude> == Templates for menuconfig == If you use one of the following templates, the module will automatically added to the proper category {{Codeline|<nowiki>{{I/O}}</nowiki>}} {{Codeline|<nowiki>{{Protocols}}</nowiki>}} {{Codeline|<nowiki>{{Applications}}</nowiki>}} == Templates for STATUS == {| style="width:50%" |- | {{Codeline|<nowiki>{{stable}}</nowiki>}} {{stable}} {{Codeline|<nowiki>{{Experimental}}</nowiki>}} {{Experimental}} {{Codeline|<nowiki>{{In_Development}}</nowiki>}} {{In Development}} {{Codeline|<nowiki>{{Unstable}}</nowiki>}} {{Unstable}} {{Codeline|<nowiki>{{Deprecated}}</nowiki>}} {{Deprecated}} |} == Templates for ECMD == {| style="width:50%" |- | {{Codeline|<nowiki>{{has_ecmd}}</nowiki>}} |} or leave blank == Templates for CONTROL6 == {| style="width:50%" |- | {{Codeline|<nowiki>{{has_control6}}</nowiki>}} |} or leave blank == Example == <pre><nowiki> {{Module |NAME=Onewire |MENUCONFIG={{I/O}}->Onewire support |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }}</nowiki></pre> == Result == {{Module |NAME=Onewire |MENUCONFIG={{I/O}}->Onewire support |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} 5a314b82897b6ce8c6dc45dd6057c976c02fdb1a 14 211 560 2012-05-03T10:27:58Z Joe 146 +Experimental Category wikitext text/x-wiki These modules can be considered as Experimental. 34d24685206476c7fbbc815e2d825bd404f7b212 10 212 561 2012-05-03T10:42:08Z Joe 146 Created page with "I2C [[Category:I2C| ]]" wikitext text/x-wiki I2C [[Category:I2C| ]] 53ec20763696d311e65a503bdd9e726a8702777f 562 561 2012-05-03T10:46:37Z Joe 146 +I2C template wikitext text/x-wiki [[:Category:I2C|I2C ]] [[Category:I2C|I2C ]] 04bae23e5fa3139045fbf11c2ee5a428ae911cf5 564 562 2012-05-03T10:51:20Z Joe 146 +I2C template wikitext text/x-wiki [[:Category:I2C|I2C Master Support]] [[Category:I2C|I2C ]] 5bc6c02b0ec5f8af2cee45d91dca1f802a725322 14 213 563 2012-05-03T10:48:46Z Joe 146 +I2C Category wikitext text/x-wiki This category lists all articles about modules listed under "I/O->I2C" in the menuconfig. df20a00e3153d4118448a9d70a1cb587fb13c429 565 563 2012-05-03T10:52:02Z Joe 146 +Experimental Category wikitext text/x-wiki This category lists all articles about modules listed under "I/O->I2C Master Support" in the menuconfig. 8e25fec0a9ba4141e5cca10fde8bce2ef0a00e9d 0 160 567 399 2012-05-03T10:55:11Z Joe 146 +I2C in modul description wikitext text/x-wiki {{i18n|PCA9555}} {{Module |NAME=PCA9555 |MENUCONFIG={{I/O}}->{{I2C Master}}->I2C PCA9555 |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6= |DEPENDS=[[ECMD]] [[I2C Master]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/i2c/master/ https://github.com/ethersex/ethersex/tree/master/hardware/i2c/master] }} Driver for the PCA9555 16-Bit I2C digital I/O chip. == Connection == == Configuration == == [[ECMD]] == PCA9555 implements a [[ECMD]] interface for reading and writing the pin status. See [[ECMD_Reference|ECMD reference]]. 65ff42b78907fd5c09bcd80cdf5e6455d45d1b88 0 185 568 477 2012-05-03T10:58:34Z Joe 146 +I2C Category link wikitext text/x-wiki {{i18n|I2C/Slave Example}} In diesem Beispiel wird gezeigt wie man eine TWI Verbindung zwischen Ethersex und einem zweiten AVR herstellen kann.<br/> == Konfiguration == Zuerst muss Ethersex konfiguriert werden.<br/> Menuconfig -> Protocols -> ECMD -> I2C aktivieren Die Standardadresse ist 8 und die Pufferlänge 50<br/> In diesem Beispiel wird die TWI Lib von [http://jump.to/fleury P. Fleury] verwendet.<br/> == Definition == Zuerst Definieren wir die Adresse für Lesen und Schreiben <source lang=c> #define E6WR (0x8 << 1) | I2C_WRITE #define E6RD (0x8 << 1) | I2C_READ </source> == Befehl senden == Danach benötigen wir einen Puffer für die Ausgelesenen Daten Z.B. <source lang=c> #define E6BUFLEN 50 char E6_data[E6BUFLEN]; </source> Nun senden wir einen ECMD Befehl: <source lang=c> if(!(i2c_start( E6WR ))) //Slave bereit zum schreiben? { i2c_write('i'); i2c_write('p'); i2c_write('\0'); //Befehl muss 0 Terminiert werden! } </source> == Daten Empfangen == Ethersex empfängt nun den Befehl und Wertet ihn automatisch aus. Jetzt müssen wir nur mehr das Ergebnis auslesen: <source lang=c> if(!(i2c_rep_start( E6RD ))) //Slave bereit zum lesen? { for(n=0;n<E6BUFLEN;n++) { E6_data[n] = i2c_readAck(); if(E6_data[n] == '\0') break; if(E6_data [n] == '\n') { E6_data[n+1] = '\0'; break; } } i2c_readNak(); i2c_stop(); } </source> Nun haben wir die IP Adresse im E6_data Array stehen. [[Category:I2C|I2C]] f3a7081055d9796010e902a558f7bdce4022a131 0 188 569 479 2012-05-03T10:59:10Z Joe 146 +I2C Category link wikitext text/x-wiki {{i18n|I2C/Slave Example}} [[Category:I2C|I2C]] 9652472e0f6a1284d67d0c952f3528e760940cd7 0 149 570 353 2012-05-03T11:05:09Z Joe 146 link to I2C wikitext text/x-wiki {{Module |NAME=BMP085 |MENUCONFIG={{I/O}}->{{I2C Master}}->BMP085 |STATUS={{experimental}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]], [[I2C]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/blob/master/hardware/i2c/master/i2c_bmp085.c https://github.com/ethersex/ethersex/blob/master/hardware/i2c/master/i2c_bmp085.c ] }} = Bosch BMP085 and BMP180 barometric pressure sensors = == Sensors == * Cheap (about 6 EUR) * Small * Precise (Resolution 0.25m, absolute accuracy +-2.5 hPa) * Digital readout via I2C * BMP085 and BMP180 are code-compatible, the BMP180 comes in a smaller package [http://www.bosch-sensortec.com/content/language1/html/3477.htm Datasheets] == Availibility == Pure sensors * [http://www.digikey.com Digikey] Breakout boards * [http://jeelabs.com/products/pressure-plug JeeLabs] * Sparkfun * [http://www.watterott.com/de/Breakout-Board-mit-dem-BMP085-absoluten-Drucksensor Watterott] == [[ECMD]] == {| border=1 | '''Command Syntax''' | '''Short description''' |- | bmp085 temp | Returns the temperature in 0.1°C (16 Bit integer) |- | bmp085 apress | Returns the absolute pressure in Pa (32 Bit integer) |- | bmp085 height <p0> | Returns the height in cm. Needs the pressure p0 at NN as parameter (given in Pa, 32 Bit integer). |- | bmp085 pressnn <height> | Returns the pressure p0 at NN in Pa. Needs the current height in cm (32 Bit integer). |- |} == Pressure calculations == * Pressure calculations for the height and pressnn commands are done using the [http://en.wikipedia.org/wiki/Barometric_formula Barometric formula] == Precision == * The sensor is sensitive to air turbulences (propellers, fans, loud music) * The sensor is sensitive to power supply ripple - if not using a battery try to filter it well * The results will have some noise, filter them with a moving average or other algorithm to get good results 645ad6cde58b5efb774cca4a24a90385fc170faf 14 215 572 2012-05-03T11:57:07Z Joe 146 Created page with "for developers" wikitext text/x-wiki for developers 9cc76d99d83504abe88f08b8aa8c049a0bfd0da0 0 141 573 336 2012-05-03T11:58:51Z Joe 146 +development category wikitext text/x-wiki {{i18n|Own module}} Hier findest du die wichtigsten Informationen, um dein eigenes Modul entwickeln zu können. Beachte bitte auch den projektweit gültigen [[Coding_style|coding style]] und weitere Infos wie unter [[Pins in Ethersex definieren]]. == Lizenz == Damit dein Modul mit ethersex veröffentlicht werden kann, musst du deinen Code unter eine GPLv3-kompatible Lizenz stellen. Füge dazu am besten folgenen Lizenzkopf in jede deiner Quellcode Dateien (*.h,*.c) ein: /* * * Copyright (c) 2012 by DEIN_NAME <DAVOR@DANACH.net> * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * as published by the Free Software Foundation; either version 3 * of the License, or (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. * * For more information on the GPL, please go to: * http://www.gnu.org/copyleft/gpl.html */ * Vergiss nicht, DEIN_NAME durch deinen Namen zu ersetzen. == Richtiges Verzeichnis == Du kannst dein Modul in eines der Verzeichnisse „hardware“, „services“ oder „protocols“ einsortieren. Wenn dein Modul mehrere dieser Kategorien erfüllt, muss das Modul eventuell in kleinere Untermodule aufgeteilt werden. Genaue Beschreibungen findest du im jeweiligen Verzeichnis in der Datei "content.txt". Wenn du dir nicht sicher bist, wo dein Modul genau einsortiert werden sollte, frag in der Mailingliste nach. Die 3 Kategorien grob umrissen: * Hardware: Module, die es ermöglichen externe Hardware anzusteuern. * Services: Module, die Anwendungen/Daemons/Services realisieren. * Protocols: Module, die Protokolle implementieren. == Dateien in Make-Prozess aufnehmen == Du hast in einem beliebigen Unterverzeichnis eine Datei hinzugefügt und möchtest natürlich, dass das Make-System diese jetzt auch mit berücksichtigt. Dazu musst du ein Makefile erstellen, welches beispielsweise wie folgt aussehen kann: <pre> TOPDIR ?= ../.. include $(TOPDIR)/.config $(DC3840_SUPPORT)_SRC += hardware/camera/dc3840.c ############################################################################## # generic fluff include $(TOPDIR)/scripts/rules.mk </pre> Anstelle der Variable, die auf _SRC endet, kannst du eine der folgenden Alternativen wählen: # Die Datei soll immer mit eingelinkt werden.<pre>SRC += Pfad/deinedatei.c</pre> # Die Datei soll in Abhängigkeit von einer Konfigurationsoption aus Menuconfig mit eingebunden werden.<pre>${DEINGENIALESMODUL_SUPPORT}_SRC += Pfad/deinedatei.c</pre> # Die Datei soll in Abhängigkeit von einer Konfigurationsoption mit eingebunden werden, wenn der ECMD-Parser aktiviert ist.<pre>${DEINGENIALESMODUL_SUPPORT}_ECMD_SRC += Pfad/deinedatei.c</pre> Abhängig von der Ordnertiefe des von dir angelegten Ordners musst du selbstverständlich die Zahl der ''../'' betreffend ''TOPDIR'' anpassen. Weiterhin musst du dein Makefile dem eigentlichen Makefile in $(TOPDIR) bekannt machen, indem du es folgendermaßen hinzufügst: SUBDIRS += hardware/camera == Menuconfig == Um dein Modul zur grafischen Konfiguration hinzuzufügen (make menuconfig), brauchst du im Ordner deines Moduls eine Datei namens config.in, beispielsweise mit folgendem Inhalt: dep_bool_menu 'Genius module' DEINGENIALESMODUL_SUPPORT $TCP_SUPPORT Dieser Eintrag bedeutet, dass du dein Modul nur dann aktivieren kannst, wenn TCP_SUPPORT aktiviert ist. Weiters wird hier noch ein Untermenü angelegt. Um dein Modul ohne Abhängigkeiten und ohne zusätzlichem Menü aktivieren zu können solltest du folgende Methode wählen: bool 'Genius module' DEINGENIALESMODUL_SUPPORT Dieses musst du, analog zum Makefile, in $(TOPDIR)/config.in hinzufügen: source hardware/camera/config.in == Funktion beim Boot und Periodisch aufrufen lassen == # Du hast ein neues Modul entwickelt, dieses Enthält eine Initialisierungsfunktion, die beim Start der Ethersex-Firmware aufgerufen werden muss. # Dein Modul enthält eine Funktion, die nach Möglichkeit ständig wieder aufgerufen wird (bzw. möglichst oft, soviel Rechenzeit wie die anderen Applikationen die ebenfalls ihre Dienste verrichten sollen, übrig lassen) Hierzu gibt es die ''Ethersex Meta''-Bereiche, die du evtl. bereits am Ende der einen oder anderen C-Datei entdeckt hast. Diese haben grundsätzlich den folgenden Aufbau: <pre> /* -- Ethersex META -- mainloop(stella_process) init(stella_init) */ </pre> Diese Zeilen, am Dateiende eingefügt, sorgen dafür, dass die Funktion ''stella_init'' einmal beim Start der von dir modifizierten Ethersex-Firmware aufgerufen wird und die Funktion ''stella_process' möglichst oft. Du kannst in den Meta-Bereich auch mehrere ''init''-Direktiven aufnehmen, etc. Weitere Direktiven sind: * '''initearly''' - funktioniert wie ''init''. Die Funktionen werden nur vor ''init'' aufgerufen. Dies ist bei Abhängigkeiten praktisch, in der Regel solltest du jedoch ''init'' verwenden. * '''net_init''' - zum Initialisieren von Netzwerkanwendungen. Die Funktionen werden nach den ''init''-Funktionen ausgeführt. * '''startup''' - diese Funktionen werden vor Aufruf der Mainloop gestartet. Der Sendmail-Service sendet hier beispielsweise die Startnachricht. * '''timer''' - Periodisch (alle 20ms) wie bei mainloop. Beispiel: timer(50, function()) ruft function() alle 50*20ms auf, also 1x pro Sekunde. * '''header''' - nicht dokumentiert Bei den aufzurufenden Funktionen muss bei init(<fkt>) die Funktion ohne Klammern und bei timer(<int>, <fkt>()) mit Klammern geschrieben werden. == Debug-Ausgaben == Für eingebettete Systeme zu programmieren kann manchmal ziemlich nervenaufreibend sein. In der Regel hat man nicht die nötige Hardware (JTAG) um step-by-step Debugging durchführen zu können. Der ethersex Core bietet dir einige Debug-Ausgabefunktionen an um zumindest über syslog oder die serielle Schnittstelle den Programmablauf mitverfolgen zu können. Folgende Debugfunktionen kannst du nutzen, nachdem du core/debug.h inkludiert hast: * void debug_printf(s, args...); // Syntax wie bei printf aus der standard C library * char* debug_binary(uint8_t); // Gibt eine 8 Byte lange Zeichenfolge von 0/1 zurück, die den integer repräsentiert Folgende Debug Funktionen kannst du nutzen, nachdem du protocols/syslog/syslog.h inkludiert hast: * void syslog_sendf(s, args...); // Syntax wie bei printf aus der standard C library [[Category:Ethersex]] [[Category:StepByStep]] [[Category:Development]] 74b654eb58295b0ba109f8c9d3325245be600e60 0 139 574 322 2012-05-03T11:59:12Z Joe 146 +development category wikitext text/x-wiki {{i18n|own_module}} [[Category:Ethersex]] [[Category:StepByStep]] [[Category:Development]] ffe94ba407cf2536722af9023fab274f2a7d7ade 575 574 2012-05-03T12:00:01Z Joe 146 deleted empty page wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 576 575 2012-05-03T12:02:30Z Joe 146 +restored to last change wikitext text/x-wiki {{i18n|own_module}} [[Category:Ethersex]] [[Category:StepByStep]] [[Category:Development]] ffe94ba407cf2536722af9023fab274f2a7d7ade 584 576 2012-05-04T19:15:05Z Joe 146 site translation wikitext text/x-wiki {{i18n|own_module}} Here you can find the most relevant information in order to develop your own module. Note also the project-wide [[Contributing#Coding_Style | coding style]] and other information as described in [[define pins in ethersex]]. == License == In order to publish your module with Ethersex you have to put your code under a GPLv3-compatible license. At best include the following license header in each of your source code files (*.h, *.c): /* * * Copyright (c) 2012 by YOUR_NAME <FIRST@SIR.net> * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * as published by the Free Software Foundation; either version 3 * of the License, or (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. * * For more information on the GPL, please go to: * http://www.gnu.org/copyleft/gpl.html */ Don't forget to replace YOUR_NAME with your Name. == proper directory == You can place your module in one of the directories „hardware“, „services“ or „protocols“. If your module fulfills several of these categories, the module may be divided into smaller sub-modules. Detailed descriptions can be found in each directory in the file "content.txt". If you're not sure where to put your module, ask on the mailing list. the three categories roughly outlined: * Hardware: modules to control external hardware. * Services: modules implementing applications/daemons/services. * Protocols: modules implementing protocols. == include files in make-process == Let's assume you've added a file in a subdirectory. In order to make the file known to the make-system you need to create a Makefile, which can look like the following example: <pre> TOPDIR ?= ../.. include $(TOPDIR)/.config $(DC3840_SUPPORT)_SRC += hardware/camera/dc3840.c ############################################################################## # generic fluff include $(TOPDIR)/scripts/rules.mk </pre> Instead of the variable, which ends on _SRC, you can choose one of the following alternatives: # the file should be linked always. <pre> SRC += path/yourfile.c </pre> # the files inclusion depends on a config option in Menuconfig. <pre>${YOURBRILLIANTMODUL_SUPPORT}_SRC += path/yourfile.c </pre> # the files inclusion depends on another config option, if the ecmd parser is enabled. <pre>${YOURBRILLIANTMODUL_SUPPORT}_ECMD_SRC += path/yourfile.c </pre> Depending on the depth of the folder you have created, the path to your folder must of course adapt the number of '' ../'' to your TOPDIR. Furthermore, you have to include your Makefile in the main Makefile in $(TOPDIR). Include the directory of your module in the main Makefile with: SUBDIRS += hardware/camera == Menuconfig == To add your module for graphical configuration (make menuconfig), you need a file in your module folder called config.in, for example, with the following contents: dep_bool_menu 'brilliant module' YOURBRILLIANTMODUL_SUPPORT $TCP_SUPPORT This entry creates a submenu and you can activate your module only if TCP_SUPPORT is enabled. To activate your module without dependencies and without an additional menu to choose from you should use be following method: bool 'brilliant module' YOURBRILLIANTMODUL_SUPPORT Analogous to the Makefile you have to include your config.in in $(TOPDIR)/config.in: source hardware/camera/config.in == starting functions after boot and periodically == # You have developed a new module, that contains an initialization function which should be called after boot. # Your module contains a function that is constantly called if possible (or as often as possible, at least as much computing time is left ofter by the other application which run as a service. Therefore are the ''Ethersex Meta'' areas, maybe you've already discovered them at the end of some C-files. It basically has the following structure: <pre> / * - Ethersex META - mainloop(stella_process) init(stella_init) * / </pre> These lines, inserted at end of a file, ensure that the function ''stella_init'' is called once at the start of your modified Ethersex-Firmware and the function ''stella_process'' is called as often as possible. You can include multiple ''init'', ''mainloop'' and ... directives in the meta area. Other directives are: * '''initearly''' - works like ''init''. The functions are called just before'' init''. This is useful for dependencies, in general, you should use, however, ''init''. * '''net_init''' - to initialize network applications. The functions are called after the'' init'' functions. * '''startup''' - these functions are started before calling the mainloop. The Sendmail service for example sends the start message. * '''timer''' - Periodically (every 20ms) as in mainloop. Example: timer(50, function()) calls function() every 50*20ms, thus 1x per second. * '''header''' - not documented the functions must be called in case of init with parentheses init(<fkt>) and the timer directive without brackets timer(<int> <fkt>()) . == debug output == Programming for embedded systems can be quite unnerving sometimes. Normally you do not have the necessary hardware (JTAG) for step-by-step debugging. The Ethersex core offers you some debug output functions to a least observe the program flow via syslog or the serial interface. The following debug functions are available after you include core/debug.h in your files: * void debug_printf(s, args ...) // syntax like printf from the standard C library * char* debug_binary(uint8_t) // returns an 8 Byte long string of 0/1, which represent the integer The following debug functions are available after you include protocols/syslog/syslog.h in your files : * void syslog_sendf(s, args...) // syntax like printf from the standard C library [[Category:Ethersex]] [[Category:StepByStep]] [[Category:Development]] 356322527c5c75ab001d3ffbd61981657873901d 586 584 2012-05-05T22:34:07Z Joe 146 minor fnord wikitext text/x-wiki {{i18n|own_module}} Here you can find the most relevant information in order to develop your own module. Note also the project-wide [[Contributing#Coding_Style | coding style]] and other information as described in [[define pins in ethersex]]. == License == In order to publish your module with Ethersex you have to put your code under a GPLv3-compatible license. At best include the following license header in each of your source code files (*.h, *.c): /* * * Copyright (c) 2012 by YOUR_NAME <FIRST@SIR.net> * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * as published by the Free Software Foundation; either version 3 * of the License, or (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. * * For more information on the GPL, please go to: * http://www.gnu.org/copyleft/gpl.html */ Don't forget to replace YOUR_NAME with your Name. == proper directory == You can place your module in one of the directories „hardware“, „services“ or „protocols“. If your module fulfills several of these categories, the module may be divided into smaller sub-modules. Detailed descriptions can be found in each directory in the file "content.txt". If you're not sure where to put your module, ask on the mailing list. the three categories roughly outlined: * Hardware: modules to control external hardware. * Services: modules implementing applications/daemons/services. * Protocols: modules implementing protocols. == include files in make-process == Let's assume you've added a file in a subdirectory. In order to make the file known to the make-system you need to create a Makefile, which can look like the following example: <pre> TOPDIR ?= ../.. include $(TOPDIR)/.config $(DC3840_SUPPORT)_SRC += hardware/camera/dc3840.c ############################################################################## # generic fluff include $(TOPDIR)/scripts/rules.mk </pre> Instead of the variable, which ends on _SRC, you can choose one of the following alternatives: # the file should be linked always. <pre> SRC += path/yourfile.c </pre> # the files inclusion depends on a config option in Menuconfig. <pre>${YOURBRILLIANTMODUL_SUPPORT}_SRC += path/yourfile.c </pre> # the files inclusion depends on another config option, if the ecmd parser is enabled. <pre>${YOURBRILLIANTMODUL_SUPPORT}_ECMD_SRC += path/yourfile.c </pre> Depending on the depth of the folder you have created, the path to your folder must of course adapt the number of '' ../'' to your folder. Furthermore, you have to include your Makefile in the main Makefile in $(TOPDIR). Include the directory of your module in the main Makefile with: SUBDIRS += hardware/camera == Menuconfig == To add your module for graphical configuration (make menuconfig), you need a file in your module folder called config.in, for example, with the following contents: dep_bool_menu 'brilliant module' YOURBRILLIANTMODUL_SUPPORT $TCP_SUPPORT This entry creates a submenu and you can activate your module only if TCP_SUPPORT is enabled. To activate your module without dependencies and without an additional menu to choose from you should use be following method: bool 'brilliant module' YOURBRILLIANTMODUL_SUPPORT Analogous to the Makefile you have to include your config.in in $(TOPDIR)/config.in: source hardware/camera/config.in == starting functions after boot and periodically == # You have developed a new module, that contains an initialization function which should be called after boot. # Your module contains a function that is constantly called if possible (or as often as possible, at least as much computing time is left over by the other application which run as a service. Therefore are the ''Ethersex Meta'' areas, maybe you've already discovered them at the end of some C-files. It basically has the following structure: <pre> / * - Ethersex META - mainloop(stella_process) init(stella_init) * / </pre> These lines, inserted at end of a file, ensure that the function ''stella_init'' is called once at the start of your modified Ethersex-Firmware and the function ''stella_process'' is called as often as possible. You can include multiple ''init'', ''mainloop'' and ... directives in the meta area. Other directives are: * '''initearly''' - works like ''init''. The functions are called just before'' init''. This is useful for dependencies, in general, you should use, however, ''init''. * '''net_init''' - to initialize network applications. The functions are called after the'' init'' functions. * '''startup''' - these functions are started before calling the mainloop. The Sendmail service for example sends the start message. * '''timer''' - Periodically (every 20ms) as in mainloop. Example: timer(50, function()) calls function() every 50*20ms, thus 1x per second. * '''header''' - not documented the functions must be called in case of init without parentheses init(<fkt>) and the timer directive without brackets timer(<int> <fkt>()) . == debug output == Programming for embedded systems can be quite unnerving sometimes. Normally you do not have the necessary hardware (JTAG) for step-by-step debugging. The Ethersex core offers you some debug output functions to at least observe the program flow via syslog or the serial interface. The following debug functions are available after you include core/debug.h in your files: * void debug_printf(s, args...) // syntax like printf from the standard C library * char* debug_binary(uint8_t) // returns an 8 Byte long string of 0/1, which represents the integer The following debug functions are available after you include protocols/syslog/syslog.h in your files: * void syslog_sendf(s, args...) // syntax like printf from the standard C library [[Category:Ethersex]] [[Category:StepByStep]] [[Category:Development]] 48616322ae5744b5241ca29bfbdb1a8ffe3b76cd 0 216 577 2012-05-03T12:58:28Z Joe 146 +appsample modul wikitext text/x-wiki {{i18n|Application Sample}} {{i18n|Application Sample}} {{Module |NAME=Application Sample |MENUCONFIG={{Applications}}->Application Sample |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS= |REQUIRES= Config Experimental |CODE=[https://github.com/ethersex/ethersex/tree/master/services/appsample https://github.com/ethersex/ethersex/tree/master/services/appsample] }} == Application Sample == Es enthält einige leere Funktionen, die als Vorlage für eigene Code-Schipsel und Modifikationen genutzt werden können. Dazu können einfach an den entsprechenden Stellen die eigenen Codezeilen eingefügt werden. Die Funktionen werden zur Laufzeit automatisch aufgerufen. Die Automatik des Aufrufs kann in '''menuconfig''' geändert werden. Applications ---> [*] Application Sample (EXPERIMENTAL) ---> [*] Method init auto start [*] Method periodic auto start Die Datei '''services/appsample/appsample.c''' enthält die wichtigsten Funktionen: * "app_sample_init" wird während des Bootvorgangs ausgeführt. * "app_sample_periodic" wird periodisch ausgeführt. * "app_sample_onrequest" wird (momentan) nur via ECMD ausgeführt. Um die Zeit des periodischen Aufrufs zu ändern, muss man nur den Timer-Wert anpassen. Der Vorgabewert 100 bedeutet, dass die Funktion alle 100*20ms = 2 Sekunden automatisch aufgerufen wird. timer(100,app_sample_periodic()) Bei aktiviertem ECMD können die folgenden 3 Befehle benutzt werden. * "sample" ruft die Funktion "app_sample_onrequest" auf * "sample_init" ruft manuell die Funktion "app_sample_init" auf * "sample_periodic" ruft manuell die Funktion "app_sample_periodic" auf [[Category:Ethersex]] f4f4dc64a44945619a1d5b0380ab8083a86239d9 578 577 2012-05-03T12:58:53Z Joe 146 +appsample modul wikitext text/x-wiki {{i18n|Application Sample}} {{Module |NAME=Application Sample |MENUCONFIG={{Applications}}->Application Sample |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS= |REQUIRES= Config Experimental |CODE=[https://github.com/ethersex/ethersex/tree/master/services/appsample https://github.com/ethersex/ethersex/tree/master/services/appsample] }} == Application Sample == Es enthält einige leere Funktionen, die als Vorlage für eigene Code-Schipsel und Modifikationen genutzt werden können. Dazu können einfach an den entsprechenden Stellen die eigenen Codezeilen eingefügt werden. Die Funktionen werden zur Laufzeit automatisch aufgerufen. Die Automatik des Aufrufs kann in '''menuconfig''' geändert werden. Applications ---> [*] Application Sample (EXPERIMENTAL) ---> [*] Method init auto start [*] Method periodic auto start Die Datei '''services/appsample/appsample.c''' enthält die wichtigsten Funktionen: * "app_sample_init" wird während des Bootvorgangs ausgeführt. * "app_sample_periodic" wird periodisch ausgeführt. * "app_sample_onrequest" wird (momentan) nur via ECMD ausgeführt. Um die Zeit des periodischen Aufrufs zu ändern, muss man nur den Timer-Wert anpassen. Der Vorgabewert 100 bedeutet, dass die Funktion alle 100*20ms = 2 Sekunden automatisch aufgerufen wird. timer(100,app_sample_periodic()) Bei aktiviertem ECMD können die folgenden 3 Befehle benutzt werden. * "sample" ruft die Funktion "app_sample_onrequest" auf * "sample_init" ruft manuell die Funktion "app_sample_init" auf * "sample_periodic" ruft manuell die Funktion "app_sample_periodic" auf [[Category:Ethersex]] d02dd839acb5c1fdb452d32652b43267b71b83a3 579 578 2012-05-03T12:59:49Z Joe 146 +appsample modul wikitext text/x-wiki {{i18n|Application Sample}} {{Module |NAME=Application Sample |MENUCONFIG={{Applications}}->Application Sample |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS= |REQUIRES= Config Experimental |CODE=[https://github.com/ethersex/ethersex/tree/master/services/appsample https://github.com/ethersex/ethersex/tree/master/services/appsample] }} == Application Sample == Es enthält einige leere Funktionen, die als Vorlage für eigene Code-Schipsel und Modifikationen genutzt werden können. Dazu können einfach an den entsprechenden Stellen die eigenen Codezeilen eingefügt werden. Die Funktionen werden zur Laufzeit automatisch aufgerufen. Die Automatik des Aufrufs kann in '''menuconfig''' geändert werden. Applications ---> [*] Application Sample (EXPERIMENTAL) ---> [*] Method init auto start [*] Method periodic auto start Die Datei '''services/appsample/appsample.c''' enthält die wichtigsten Funktionen: * "app_sample_init" wird während des Bootvorgangs ausgeführt. * "app_sample_periodic" wird periodisch ausgeführt. * "app_sample_onrequest" wird (momentan) nur via ECMD ausgeführt. Um die Zeit des periodischen Aufrufs zu ändern, muss man nur den Timer-Wert anpassen. Der Vorgabewert 100 bedeutet, dass die Funktion alle 100*20ms = 2 Sekunden automatisch aufgerufen wird. timer(100,app_sample_periodic()) Bei aktiviertem ECMD können die folgenden 3 Befehle benutzt werden. * "sample" ruft die Funktion "app_sample_onrequest" auf * "sample_init" ruft manuell die Funktion "app_sample_init" auf * "sample_periodic" ruft manuell die Funktion "app_sample_periodic" auf [[Category:Ethersex]] [[Category:development]] 9ef490560ab80bb06a9b31bd5e2e0995a4a0e739 3 221 585 2012-05-05T08:23:46Z GooPie4o 265 Created page with "Nice work! Thanks." wikitext text/x-wiki Nice work! Thanks. 680a743941d2992ace688fae0aa8cbbc5ade797c 0 222 587 2012-05-05T23:17:25Z Joe 146 import config.mk (de) from old.ethersex.de wikitext text/x-wiki Die Datei '''config.mk''' im Hauptverzeichnis der Ethersex-Ordnerstruktur ist quasi der Schlüssel zur Entwicklung eigener Ethersex-Komponenten, '''die nicht in Ethersex aufgenommen werden sollen''', weil sie schlicht zu speziell sind. Als Grundregel sollte in etwa gelten: Wenn du etwas an Ethersex ergänzen möchtest, das nicht groß veröffentlicht werden soll, solltest du zusehen, dass du die bestehenden Dateien, die in Ethersex enthalten sind, nicht modifizierst. Die Datei ''config.mk'' sowie Mechanismen wie die Meta-Bereiche ermöglichen dies weitestgehend. Dieses Vorgehen hat für dich den Vorteil, dass es beim Aktualisieren auf eine neue Ethersex-Version nicht zu Konflikten zwischen deinen und unseren Modifikationen kommen kann. Wenn du ab und an Patches erstellen möchtest, machst du dir das Leben so ebenfalls einfacher, da du nicht mehr aufpassen musst, versehentlich etwas zu committen, das eigentlich gar nicht eingecheckt werden sollte. Also: Alles, was du am liebsten in die Datei ''Makefile'' im Hauptverzeichnis eintragen möchtest, trägst du einfach in die Datei ''config.mk'' ein. Wenn es diese noch nicht gibt, leg' sie einfach an. == Weitere Ergänzungsdateien == === protocols/ecmd/ecmd_defs.m4 === Statt die ''ecmd_defs.m4'' zu bearbeiten, kannst du auch irgendwo eine neue Datei anlegen und die gleiche Syntax wie in ''ecmd_defs.m4'' verwenden. Dass das Make-System die Datei berücksichtigt, musst du sie noch registrieren. Dazu dient wieder die ''config.mk'': ECMD_DEFS_EXTRA += mycruft/private_ecmds.m4 ... und schon werden auch die Einträge in der Datei mycruft/private_ecmds.m4 entsprechend berücksichtigt. === named_pin Konfiguration === Zunächst kopierst du dir am besten die Datei ''core/portio/config'' irgendwo hin und verwendest sie als Vorlage. Um diese zu registrieren, verwenden wir die folgende Zeile in ''config.mk'': NP_CONFIG = mycruft/named_pin.conf === [[Control6]] Skript === Ein eigenes [[Control6]] Skript in einer von control6/control6.src abweichenden Datei kann du mit folgendem Statement registrieren: C6_SOURCE = mycruft/wecky.src or C6_SOURCE = $(TOPDIR)/control6/you_programm.src == mögliche weitere Einträge == === avrdude mit 'make dude644' aufrufen === dude644: ethersex.hex avrdude -p m644 -c usbasp -V -Uflash:w:$< === AVR mit 'make reset' via ISP resetten === reset: avrdude -p m644 -c usbasp [[Category:Ethersex]] a5e362c9b7bb18605e18704e1b589e90e3423e93 588 587 2012-05-06T02:09:18Z Joe 146 +category and lang in compliance to new ethersex wiki wikitext text/x-wiki {{i18n|Config.mk}} Die Datei '''config.mk''' im Hauptverzeichnis der Ethersex-Ordnerstruktur ist quasi der Schlüssel zur Entwicklung eigener Ethersex-Komponenten, '''die nicht in Ethersex aufgenommen werden sollen''', weil sie schlicht zu speziell sind. Als Grundregel sollte in etwa gelten: Wenn du etwas an Ethersex ergänzen möchtest, das nicht groß veröffentlicht werden soll, solltest du zusehen, dass du die bestehenden Dateien, die in Ethersex enthalten sind, nicht modifizierst. Die Datei ''config.mk'' sowie Mechanismen wie die Meta-Bereiche ermöglichen dies weitestgehend. Dieses Vorgehen hat für dich den Vorteil, dass es beim Aktualisieren auf eine neue Ethersex-Version nicht zu Konflikten zwischen deinen und unseren Modifikationen kommen kann. Wenn du ab und an Patches erstellen möchtest, machst du dir das Leben so ebenfalls einfacher, da du nicht mehr aufpassen musst, versehentlich etwas zu committen, das eigentlich gar nicht eingecheckt werden sollte. Also: Alles, was du am liebsten in die Datei ''Makefile'' im Hauptverzeichnis eintragen möchtest, trägst du einfach in die Datei ''config.mk'' ein. Wenn es diese noch nicht gibt, leg' sie einfach an. == Weitere Ergänzungsdateien == === protocols/ecmd/ecmd_defs.m4 === Statt die ''ecmd_defs.m4'' zu bearbeiten, kannst du auch irgendwo eine neue Datei anlegen und die gleiche Syntax wie in ''ecmd_defs.m4'' verwenden. Dass das Make-System die Datei berücksichtigt, musst du sie noch registrieren. Dazu dient wieder die ''config.mk'': ECMD_DEFS_EXTRA += mycruft/private_ecmds.m4 ... und schon werden auch die Einträge in der Datei mycruft/private_ecmds.m4 entsprechend berücksichtigt. === named_pin Konfiguration === Zunächst kopierst du dir am besten die Datei ''core/portio/config'' irgendwo hin und verwendest sie als Vorlage. Um diese zu registrieren, verwenden wir die folgende Zeile in ''config.mk'': NP_CONFIG = mycruft/named_pin.conf === [[Control6]] Skript === Ein eigenes [[Control6]] Skript in einer von control6/control6.src abweichenden Datei kann du mit folgendem Statement registrieren: C6_SOURCE = mycruft/wecky.src or C6_SOURCE = $(TOPDIR)/control6/you_programm.src == mögliche weitere Einträge == === avrdude mit 'make dude644' aufrufen === dude644: ethersex.hex avrdude -p m644 -c usbasp -V -Uflash:w:$< === AVR mit 'make reset' via ISP resetten === reset: avrdude -p m644 -c usbasp [[Category:development]] 5df9aac80416988802d9b29e2e0e251afa335b40 589 588 2012-05-06T02:10:59Z Joe 146 moved [[Config.mk (Deutsch)]] to [[Config.mk tmp (Deutsch)]]:&#32;case sensitive, he is wikitext text/x-wiki {{i18n|Config.mk}} Die Datei '''config.mk''' im Hauptverzeichnis der Ethersex-Ordnerstruktur ist quasi der Schlüssel zur Entwicklung eigener Ethersex-Komponenten, '''die nicht in Ethersex aufgenommen werden sollen''', weil sie schlicht zu speziell sind. Als Grundregel sollte in etwa gelten: Wenn du etwas an Ethersex ergänzen möchtest, das nicht groß veröffentlicht werden soll, solltest du zusehen, dass du die bestehenden Dateien, die in Ethersex enthalten sind, nicht modifizierst. Die Datei ''config.mk'' sowie Mechanismen wie die Meta-Bereiche ermöglichen dies weitestgehend. Dieses Vorgehen hat für dich den Vorteil, dass es beim Aktualisieren auf eine neue Ethersex-Version nicht zu Konflikten zwischen deinen und unseren Modifikationen kommen kann. Wenn du ab und an Patches erstellen möchtest, machst du dir das Leben so ebenfalls einfacher, da du nicht mehr aufpassen musst, versehentlich etwas zu committen, das eigentlich gar nicht eingecheckt werden sollte. Also: Alles, was du am liebsten in die Datei ''Makefile'' im Hauptverzeichnis eintragen möchtest, trägst du einfach in die Datei ''config.mk'' ein. Wenn es diese noch nicht gibt, leg' sie einfach an. == Weitere Ergänzungsdateien == === protocols/ecmd/ecmd_defs.m4 === Statt die ''ecmd_defs.m4'' zu bearbeiten, kannst du auch irgendwo eine neue Datei anlegen und die gleiche Syntax wie in ''ecmd_defs.m4'' verwenden. Dass das Make-System die Datei berücksichtigt, musst du sie noch registrieren. Dazu dient wieder die ''config.mk'': ECMD_DEFS_EXTRA += mycruft/private_ecmds.m4 ... und schon werden auch die Einträge in der Datei mycruft/private_ecmds.m4 entsprechend berücksichtigt. === named_pin Konfiguration === Zunächst kopierst du dir am besten die Datei ''core/portio/config'' irgendwo hin und verwendest sie als Vorlage. Um diese zu registrieren, verwenden wir die folgende Zeile in ''config.mk'': NP_CONFIG = mycruft/named_pin.conf === [[Control6]] Skript === Ein eigenes [[Control6]] Skript in einer von control6/control6.src abweichenden Datei kann du mit folgendem Statement registrieren: C6_SOURCE = mycruft/wecky.src or C6_SOURCE = $(TOPDIR)/control6/you_programm.src == mögliche weitere Einträge == === avrdude mit 'make dude644' aufrufen === dude644: ethersex.hex avrdude -p m644 -c usbasp -V -Uflash:w:$< === AVR mit 'make reset' via ISP resetten === reset: avrdude -p m644 -c usbasp [[Category:development]] 5df9aac80416988802d9b29e2e0e251afa335b40 591 589 2012-05-06T02:11:23Z Joe 146 moved [[Config.mk tmp (Deutsch)]] to [[Config.mk (Deutsch)]] over redirect: case sensitive, he is. wikitext text/x-wiki {{i18n|Config.mk}} Die Datei '''config.mk''' im Hauptverzeichnis der Ethersex-Ordnerstruktur ist quasi der Schlüssel zur Entwicklung eigener Ethersex-Komponenten, '''die nicht in Ethersex aufgenommen werden sollen''', weil sie schlicht zu speziell sind. Als Grundregel sollte in etwa gelten: Wenn du etwas an Ethersex ergänzen möchtest, das nicht groß veröffentlicht werden soll, solltest du zusehen, dass du die bestehenden Dateien, die in Ethersex enthalten sind, nicht modifizierst. Die Datei ''config.mk'' sowie Mechanismen wie die Meta-Bereiche ermöglichen dies weitestgehend. Dieses Vorgehen hat für dich den Vorteil, dass es beim Aktualisieren auf eine neue Ethersex-Version nicht zu Konflikten zwischen deinen und unseren Modifikationen kommen kann. Wenn du ab und an Patches erstellen möchtest, machst du dir das Leben so ebenfalls einfacher, da du nicht mehr aufpassen musst, versehentlich etwas zu committen, das eigentlich gar nicht eingecheckt werden sollte. Also: Alles, was du am liebsten in die Datei ''Makefile'' im Hauptverzeichnis eintragen möchtest, trägst du einfach in die Datei ''config.mk'' ein. Wenn es diese noch nicht gibt, leg' sie einfach an. == Weitere Ergänzungsdateien == === protocols/ecmd/ecmd_defs.m4 === Statt die ''ecmd_defs.m4'' zu bearbeiten, kannst du auch irgendwo eine neue Datei anlegen und die gleiche Syntax wie in ''ecmd_defs.m4'' verwenden. Dass das Make-System die Datei berücksichtigt, musst du sie noch registrieren. Dazu dient wieder die ''config.mk'': ECMD_DEFS_EXTRA += mycruft/private_ecmds.m4 ... und schon werden auch die Einträge in der Datei mycruft/private_ecmds.m4 entsprechend berücksichtigt. === named_pin Konfiguration === Zunächst kopierst du dir am besten die Datei ''core/portio/config'' irgendwo hin und verwendest sie als Vorlage. Um diese zu registrieren, verwenden wir die folgende Zeile in ''config.mk'': NP_CONFIG = mycruft/named_pin.conf === [[Control6]] Skript === Ein eigenes [[Control6]] Skript in einer von control6/control6.src abweichenden Datei kann du mit folgendem Statement registrieren: C6_SOURCE = mycruft/wecky.src or C6_SOURCE = $(TOPDIR)/control6/you_programm.src == mögliche weitere Einträge == === avrdude mit 'make dude644' aufrufen === dude644: ethersex.hex avrdude -p m644 -c usbasp -V -Uflash:w:$< === AVR mit 'make reset' via ISP resetten === reset: avrdude -p m644 -c usbasp [[Category:development]] 5df9aac80416988802d9b29e2e0e251afa335b40 0 225 593 2012-05-06T02:11:46Z Joe 146 +site translation wikitext text/x-wiki {{i18n|Config.mk}} The file'' 'config.mk''' in the root directory of the ethersex folder structure is the key for developing your own Ethersex components, '''which should not be included in Ethersex''', simply because they are too specific. Perhaps as basic rule should apply: If you want to add something to Ethersex, which will not be published, make sure that the existing files that are included in Ethersex are not modified. The file '''config.mk''' and mechanisms such as the meta-areas make this feasible to the greatest possible extend. This approach has the advantage for you, that if you upgrade to a new Ethersex Version there are no conflicts between your and our modifications. If you supply patches from time to time, this makes your life easier too, you don't have to be careful to accidentally commit something that was not even supposed to be checked in. So, everything you would put in the ''Makefile'' in the root directory, you just put it in the file ''config.mk''. If it doesnt exist yes, just create it. == more supplementing files == === protocols/ecmd/ecmd_defs.m4 === Instead of editing ''ecmd_defs.m4'', you can also create a new file somewhere with the same syntax as shown in ''ecmd_defs.m4''. To make your new file known to the make-system you have to register it. This again is done in ''config.mk'': ECMD_DEFS_EXTRA += mycruft/private_ecmds.m4 ... and already the entries in the file mycruft/private_ecmds.m4 are taken into account. === named_pin Configuration === For the time being and to come of best, simply copy the file ''core/portio/config'' somewhere and use it as a template. To Register you file, use the following line in ''config.mk'': NP_CONFIG = mycruft/named_pin.conf === [[Control6]] script === Your own [[Control6]] script in another location than control6/control6.src is registered with the following statement: C6_SOURCE = mycruft/wacky.src or C6_SOURCE = $(TOPDIR)/control6/your_programm.src == other possible entries == === call avrdude with 'make dude644' === dude644: etherse.hex avrdude -p m644 -c usbasp -V -Uflash:w$< === reset AVR with 'make reset' via ISP Programmer === reset: avrdude -p m644 -c usbasp [[Category:development]] f7a7a53725aedc8f92bb11072eaa98b4a5132e59 0 40 594 199 2012-05-06T02:38:52Z Joe 146 internationalization ftw wikitext text/x-wiki {{i18n|Wiki Guidelines}} == Languages == This is an sense an international wiki. Please include this on top of every page you create: {{Codeline|<nowiki>{{i18n|TITLE}}</nowiki>}} Replace TITLE with the title of the page you are editing. This will insert a language bar like the one you can see above. If you want to translate a page, simply click on the language and start editing. Make sure that you include the language template as well. *Categories are not internationalized == Modules == If you want to document a module, please make use of the [[Template:Module | Module Template]]. A well documented module should look similar to [[IRMP | this ]]. For the title, please use the name of the module in menuconfig or how it is called in the code (e.g. the folder name). Please do not chose a title that doesn't match with either one of these. == More rules == * Refrain from putting all information related to a module into one single page. Create subpages for examples and specific setups. 9e6c9c9e778e9d1967cf98f2c7c8f5681327f3b4 595 594 2012-05-06T02:39:39Z Joe 146 typo/spell wikitext text/x-wiki {{i18n|Wiki Guidelines}} == Languages == This is an sense a international wiki. Please include this on top of every page you create: {{Codeline|<nowiki>{{i18n|TITLE}}</nowiki>}} Replace TITLE with the title of the page you are editing. This will insert a language bar like the one you can see above. If you want to translate a page, simply click on the language and start editing. Make sure that you include the language template as well. *Categories are not internationalized == Modules == If you want to document a module, please make use of the [[Template:Module | Module Template]]. A well documented module should look similar to [[IRMP | this ]]. For the title, please use the name of the module in menuconfig or how it is called in the code (e.g. the folder name). Please do not chose a title that doesn't match with either one of these. == More rules == * Refrain from putting all information related to a module into one single page. Create subpages for examples and specific setups. e834b040b9ef844d03d6f7af0d20c157c378915f 0 209 616 615 2012-05-17T17:48:02Z Tkaltenbrunner 475 /* structure of meta.c */ wikitext text/x-wiki {{i18n|Concept of meta}} == Intro == With meta information in each module the main program is set up depending on the configuration. At the end there will be a short example of such meta information. If you continue to read, you should understand this concept: [[M4 - very short intro (Deutsch)#divert]] Also have a look at the files explained while reading - that will help. == meta.c / meta_magic.m4 == The creation of this file is mainly controlled by the file "meta_magic.m4". What is in the file meta_magic.m4? === framework for the file meta.c === The framework consists of several divert sections, in which code of the used modules is injected. Only the idea of the injection is explained with the first injection point. The second section starts with "divert(initearly_divert)dnl" and contains the function "ethersex_meta_init", but the final closing brace of the function is missing. So if you define further divert sections with the index "initearly_divert", then it will be in the output before the closing brace and so part of "ethersex_meta_init". Therefore later in in the file some macros are defined - in this case it is named "initearly". This macros and some others are all defined the same way: define(`initearly',`dnl divert(inetearly_divert) $1 (); divert(-1)') So if the meta macro initearly(<module-initearly-functionname>) is used, the module initearly function will be called from the function ethersex_meta_init, because the function call will be in the output directly after the section. The closing brace of the function is part of the next section "divert(net_init_divert)". === structure of meta.c === meta.c itself contains several functions, which are called at important points in the firmware: * ethersex_meta_init *: is called in the startup before the pins are initialized * ethersex_meta_startup *: is called before the main loop starts * ethersex_meta_mainloop *: is called in the main loop - injected functions should do only short processings or reset the watchdog by thereselfs ... == Closing == After all this explained I want to mention that some modules are not only in that structured way integrated into the project. There are also direct compiler directives for them in the framework itself ... may be this can be changed someday ;-) to be continued ... [[Category:Development]] 61de54732da8f313ad4ad4b5b4e8674648d3f68b 619 616 2012-05-17T18:04:38Z Tkaltenbrunner 475 /* structure of meta.c */ wikitext text/x-wiki {{i18n|Concept of meta}} == Intro == With meta information in each module the main program is set up depending on the configuration. At the end there will be a short example of such meta information. If you continue to read, you should understand this concept: [[M4 - very short intro (Deutsch)#divert]] Also have a look at the files explained while reading - that will help. == meta.c / meta_magic.m4 == The creation of this file is mainly controlled by the file "meta_magic.m4". What is in the file meta_magic.m4? === framework for the file meta.c === The framework consists of several divert sections, in which code of the used modules is injected. Only the idea of the injection is explained with the first injection point. The second section starts with "divert(initearly_divert)dnl" and contains the function "ethersex_meta_init", but the final closing brace of the function is missing. So if you define further divert sections with the index "initearly_divert", then it will be in the output before the closing brace and so part of "ethersex_meta_init". Therefore later in in the file some macros are defined - in this case it is named "initearly". This macros and some others are all defined the same way: define(`initearly',`dnl divert(inetearly_divert) $1 (); divert(-1)') So if the meta macro initearly(<module-initearly-functionname>) is used, the module initearly function will be called from the function ethersex_meta_init, because the function call will be in the output directly after the section. The closing brace of the function is part of the next section "divert(net_init_divert)". === structure of meta.c === meta.c itself contains several functions, which are called at important points in the firmware: * ethersex_meta_init *: is called in the startup before the pins are initialized * ethersex_meta_startup *: is called before the main loop starts * ethersex_meta_mainloop *: is called in the main loop - injected functions should do only short processings or reset the watchdog by thereselfs ... * periodic_process *: is the last function called in ethersex_meta_mainloop - after all the injected modules function *: does some network and console reading (ECMD support and other) - at the momenet I don't know the backgrounds of this operations. *: further operations can be injected here - a counter incremented on each call can be used to delay the injected code ... == Closing == After all this explained I want to mention that some modules are not only in that structured way integrated into the project. There are also direct compiler directives for them in the framework itself ... may be this can be changed someday ;-) to be continued ... [[Category:Development]] 07190614a38573305df7aa26c228c9e7541a5a25 620 619 2012-05-17T18:07:12Z Tkaltenbrunner 475 /* Closing */ wikitext text/x-wiki {{i18n|Concept of meta}} == Intro == With meta information in each module the main program is set up depending on the configuration. At the end there will be a short example of such meta information. If you continue to read, you should understand this concept: [[M4 - very short intro (Deutsch)#divert]] Also have a look at the files explained while reading - that will help. == meta.c / meta_magic.m4 == The creation of this file is mainly controlled by the file "meta_magic.m4". What is in the file meta_magic.m4? === framework for the file meta.c === The framework consists of several divert sections, in which code of the used modules is injected. Only the idea of the injection is explained with the first injection point. The second section starts with "divert(initearly_divert)dnl" and contains the function "ethersex_meta_init", but the final closing brace of the function is missing. So if you define further divert sections with the index "initearly_divert", then it will be in the output before the closing brace and so part of "ethersex_meta_init". Therefore later in in the file some macros are defined - in this case it is named "initearly". This macros and some others are all defined the same way: define(`initearly',`dnl divert(inetearly_divert) $1 (); divert(-1)') So if the meta macro initearly(<module-initearly-functionname>) is used, the module initearly function will be called from the function ethersex_meta_init, because the function call will be in the output directly after the section. The closing brace of the function is part of the next section "divert(net_init_divert)". === structure of meta.c === meta.c itself contains several functions, which are called at important points in the firmware: * ethersex_meta_init *: is called in the startup before the pins are initialized * ethersex_meta_startup *: is called before the main loop starts * ethersex_meta_mainloop *: is called in the main loop - injected functions should do only short processings or reset the watchdog by thereselfs ... * periodic_process *: is the last function called in ethersex_meta_mainloop - after all the injected modules function *: does some network and console reading (ECMD support and other) - at the momenet I don't know the backgrounds of this operations. *: further operations can be injected here - a counter incremented on each call can be used to delay the injected code ... == Closing == After all this explained I want to mention that some modules are not only in that structured way integrated into the project. There are also direct compiler directives for them in the framework itself ... this looks like needed "hacks". [[Category:Development]] 6bf7ddb5cffe2388a85b4851e7af8887d3490418 621 620 2012-05-17T18:18:01Z Tkaltenbrunner 475 /* structure of meta.c */ wikitext text/x-wiki {{i18n|Concept of meta}} == Intro == With meta information in each module the main program is set up depending on the configuration. At the end there will be a short example of such meta information. If you continue to read, you should understand this concept: [[M4 - very short intro (Deutsch)#divert]] Also have a look at the files explained while reading - that will help. == meta.c / meta_magic.m4 == The creation of this file is mainly controlled by the file "meta_magic.m4". What is in the file meta_magic.m4? === framework for the file meta.c === The framework consists of several divert sections, in which code of the used modules is injected. Only the idea of the injection is explained with the first injection point. The second section starts with "divert(initearly_divert)dnl" and contains the function "ethersex_meta_init", but the final closing brace of the function is missing. So if you define further divert sections with the index "initearly_divert", then it will be in the output before the closing brace and so part of "ethersex_meta_init". Therefore later in in the file some macros are defined - in this case it is named "initearly". This macros and some others are all defined the same way: define(`initearly',`dnl divert(inetearly_divert) $1 (); divert(-1)') So if the meta macro initearly(<module-initearly-functionname>) is used, the module initearly function will be called from the function ethersex_meta_init, because the function call will be in the output directly after the section. The closing brace of the function is part of the next section "divert(net_init_divert)". === structure of meta.c === meta.c itself contains several functions, which are called at important points in the firmware: * ethersex_meta_init *: is called in the startup before the pins are initialized * ethersex_meta_startup *: is called before the main loop starts * ethersex_meta_mainloop *: is called in the main loop - injected functions should do only short processings or reset the watchdog by thereselfs ... * periodic_process *: is the last function called in ethersex_meta_mainloop - after all the injected modules function *: does some network and console reading (ECMD support and other) - at the momenet I don't know the backgrounds of this operations. *: further operations can be injected here - a counter incremented on each call can be used to delay the injected code ... == meta.h / meta_header_magic.m4 == Contains the structures * uip_udp_connection_state and * uuip_tcp_conenction state which can be extenede with the macros * state_udp * state_tcp Why you should do that? - Dig into the network stuff! - I don't know at the moment. === Macro state_header === By use if this macro it is possible to include additional ".h" files into meta.h. Usage: state_header(<path_and_filename>) Expands to #include "<path_and_filename>" == Closing == After all this explained I want to mention that some modules are not only in that structured way integrated into the project. There are also direct compiler directives for them in the framework itself ... this looks like needed "hacks". [[Category:Development]] 016be8b2d75039af530cb2641aea6dc16c12f2c0 622 621 2012-05-17T18:34:34Z Tkaltenbrunner 475 /* Macro state_header */ wikitext text/x-wiki {{i18n|Concept of meta}} == Intro == With meta information in each module the main program is set up depending on the configuration. At the end there will be a short example of such meta information. If you continue to read, you should understand this concept: [[M4 - very short intro (Deutsch)#divert]] Also have a look at the files explained while reading - that will help. == meta.c / meta_magic.m4 == The creation of this file is mainly controlled by the file "meta_magic.m4". What is in the file meta_magic.m4? === framework for the file meta.c === The framework consists of several divert sections, in which code of the used modules is injected. Only the idea of the injection is explained with the first injection point. The second section starts with "divert(initearly_divert)dnl" and contains the function "ethersex_meta_init", but the final closing brace of the function is missing. So if you define further divert sections with the index "initearly_divert", then it will be in the output before the closing brace and so part of "ethersex_meta_init". Therefore later in in the file some macros are defined - in this case it is named "initearly". This macros and some others are all defined the same way: define(`initearly',`dnl divert(inetearly_divert) $1 (); divert(-1)') So if the meta macro initearly(<module-initearly-functionname>) is used, the module initearly function will be called from the function ethersex_meta_init, because the function call will be in the output directly after the section. The closing brace of the function is part of the next section "divert(net_init_divert)". === structure of meta.c === meta.c itself contains several functions, which are called at important points in the firmware: * ethersex_meta_init *: is called in the startup before the pins are initialized * ethersex_meta_startup *: is called before the main loop starts * ethersex_meta_mainloop *: is called in the main loop - injected functions should do only short processings or reset the watchdog by thereselfs ... * periodic_process *: is the last function called in ethersex_meta_mainloop - after all the injected modules function *: does some network and console reading (ECMD support and other) - at the momenet I don't know the backgrounds of this operations. *: further operations can be injected here - a counter incremented on each call can be used to delay the injected code ... == meta.h / meta_header_magic.m4 == Contains the structures * uip_udp_connection_state and * uuip_tcp_conenction state which can be extenede with the macros * state_udp * state_tcp Why you should do that? - Dig into the network stuff! - I don't know at the moment. === Macro state_header === By use if this macro it is possible to include additional ".h" files into meta.h. Usage: state_header(<path_and_filename>) Expands to #include "<path_and_filename>" == Examlpe meta section == From tanklevel.c -- Ethersex META -- header(services/tanklevel/tanklevel.h) init(tanklevel_init) timer(1, tanklevel_periodic()) * header ** include file for meta.c * init ** Aufruf von tanklevel_init() in meta_init * timer ** Aufruf von tanklevel_periodic() bei jedem Durchlauf der main_loop == Closing == After all this explained I want to mention that some modules are not only in that structured way integrated into the project. There are also direct compiler directives for them in the framework itself ... this looks like needed "hacks". [[Category:Development]] 734c3ac5bb58e0960f97c7c859eead2db0f83745 623 622 2012-05-17T18:35:32Z Tkaltenbrunner 475 /* framework for the file meta.c */ wikitext text/x-wiki {{i18n|Concept of meta}} == Intro == With meta information in each module the main program is set up depending on the configuration. At the end there will be a short example of such meta information. If you continue to read, you should understand this concept: [[M4 - very short intro (Deutsch)#divert]] Also have a look at the files explained while reading - that will help. == meta.c / meta_magic.m4 == The creation of this file is mainly controlled by the file "meta_magic.m4". What is in the file meta_magic.m4? === framework for the file meta.c === The framework consists of several divert sections, in which code of the used modules is injected. Only the idea of the injection is explained with the first injection point. The second section starts with "divert(initearly_divert)dnl" and contains the function "ethersex_meta_init", but the final closing brace of the function is missing. So if you define further divert sections with the index "initearly_divert", then it will be in the output before the closing brace and so part of "ethersex_meta_init". Therefore later in in the file some macros are defined - in this case it is named "initearly". This macros and some others are all defined the same way: define(`initearly',`dnl divert(initearly_divert) $1 (); divert(-1)') So if the meta macro initearly(<module-initearly-functionname>) is used, the module initearly function will be called from the function ethersex_meta_init, because the function call will be in the output directly after the section. The closing brace of the function is part of the next section "divert(net_init_divert)". === structure of meta.c === meta.c itself contains several functions, which are called at important points in the firmware: * ethersex_meta_init *: is called in the startup before the pins are initialized * ethersex_meta_startup *: is called before the main loop starts * ethersex_meta_mainloop *: is called in the main loop - injected functions should do only short processings or reset the watchdog by thereselfs ... * periodic_process *: is the last function called in ethersex_meta_mainloop - after all the injected modules function *: does some network and console reading (ECMD support and other) - at the momenet I don't know the backgrounds of this operations. *: further operations can be injected here - a counter incremented on each call can be used to delay the injected code ... == meta.h / meta_header_magic.m4 == Contains the structures * uip_udp_connection_state and * uuip_tcp_conenction state which can be extenede with the macros * state_udp * state_tcp Why you should do that? - Dig into the network stuff! - I don't know at the moment. === Macro state_header === By use if this macro it is possible to include additional ".h" files into meta.h. Usage: state_header(<path_and_filename>) Expands to #include "<path_and_filename>" == Examlpe meta section == From tanklevel.c -- Ethersex META -- header(services/tanklevel/tanklevel.h) init(tanklevel_init) timer(1, tanklevel_periodic()) * header ** include file for meta.c * init ** Aufruf von tanklevel_init() in meta_init * timer ** Aufruf von tanklevel_periodic() bei jedem Durchlauf der main_loop == Closing == After all this explained I want to mention that some modules are not only in that structured way integrated into the project. There are also direct compiler directives for them in the framework itself ... this looks like needed "hacks". [[Category:Development]] bc253873f199fb319d885dc61b133d28a18646c0 624 623 2012-05-17T18:42:29Z Tkaltenbrunner 475 /* meta.h / meta_header_magic.m4 */ wikitext text/x-wiki {{i18n|Concept of meta}} == Intro == With meta information in each module the main program is set up depending on the configuration. At the end there will be a short example of such meta information. If you continue to read, you should understand this concept: [[M4 - very short intro (Deutsch)#divert]] Also have a look at the files explained while reading - that will help. == meta.c / meta_magic.m4 == The creation of this file is mainly controlled by the file "meta_magic.m4". What is in the file meta_magic.m4? === framework for the file meta.c === The framework consists of several divert sections, in which code of the used modules is injected. Only the idea of the injection is explained with the first injection point. The second section starts with "divert(initearly_divert)dnl" and contains the function "ethersex_meta_init", but the final closing brace of the function is missing. So if you define further divert sections with the index "initearly_divert", then it will be in the output before the closing brace and so part of "ethersex_meta_init". Therefore later in in the file some macros are defined - in this case it is named "initearly". This macros and some others are all defined the same way: define(`initearly',`dnl divert(initearly_divert) $1 (); divert(-1)') So if the meta macro initearly(<module-initearly-functionname>) is used, the module initearly function will be called from the function ethersex_meta_init, because the function call will be in the output directly after the section. The closing brace of the function is part of the next section "divert(net_init_divert)". === structure of meta.c === meta.c itself contains several functions, which are called at important points in the firmware: * ethersex_meta_init *: is called in the startup before the pins are initialized * ethersex_meta_startup *: is called before the main loop starts * ethersex_meta_mainloop *: is called in the main loop - injected functions should do only short processings or reset the watchdog by thereselfs ... * periodic_process *: is the last function called in ethersex_meta_mainloop - after all the injected modules function *: does some network and console reading (ECMD support and other) - at the momenet I don't know the backgrounds of this operations. *: further operations can be injected here - a counter incremented on each call can be used to delay the injected code ... == meta.h / meta_header_magic.m4 == Contains the structures * uip_udp_connection_state and * uip_tcp_conenction state which can be extended with the macros * state_udp * state_tcp If a module wants to save a network relevant state as part of it's functionality, it has to be part of the connection_state structure. Since it is a union, I think, it is neccessary for passing the structure to the network functions. I.e. the module dyndns puts the dyndns connection state structure there. But look into the details by yourself - if you like. === Macro state_header === By use if this macro it is possible to include additional ".h" files into meta.h. Usage: state_header(<path_and_filename>) Expands to #include "<path_and_filename>" == Examlpe meta section == From tanklevel.c -- Ethersex META -- header(services/tanklevel/tanklevel.h) init(tanklevel_init) timer(1, tanklevel_periodic()) * header ** include file for meta.c * init ** Aufruf von tanklevel_init() in meta_init * timer ** Aufruf von tanklevel_periodic() bei jedem Durchlauf der main_loop == Closing == After all this explained I want to mention that some modules are not only in that structured way integrated into the project. There are also direct compiler directives for them in the framework itself ... this looks like needed "hacks". [[Category:Development]] f4c3e6a491e0801f3bd724c4a41b5b7d7b018723 625 624 2012-05-17T18:44:24Z Tkaltenbrunner 475 /* Examlpe meta section */ wikitext text/x-wiki {{i18n|Concept of meta}} == Intro == With meta information in each module the main program is set up depending on the configuration. At the end there will be a short example of such meta information. If you continue to read, you should understand this concept: [[M4 - very short intro (Deutsch)#divert]] Also have a look at the files explained while reading - that will help. == meta.c / meta_magic.m4 == The creation of this file is mainly controlled by the file "meta_magic.m4". What is in the file meta_magic.m4? === framework for the file meta.c === The framework consists of several divert sections, in which code of the used modules is injected. Only the idea of the injection is explained with the first injection point. The second section starts with "divert(initearly_divert)dnl" and contains the function "ethersex_meta_init", but the final closing brace of the function is missing. So if you define further divert sections with the index "initearly_divert", then it will be in the output before the closing brace and so part of "ethersex_meta_init". Therefore later in in the file some macros are defined - in this case it is named "initearly". This macros and some others are all defined the same way: define(`initearly',`dnl divert(initearly_divert) $1 (); divert(-1)') So if the meta macro initearly(<module-initearly-functionname>) is used, the module initearly function will be called from the function ethersex_meta_init, because the function call will be in the output directly after the section. The closing brace of the function is part of the next section "divert(net_init_divert)". === structure of meta.c === meta.c itself contains several functions, which are called at important points in the firmware: * ethersex_meta_init *: is called in the startup before the pins are initialized * ethersex_meta_startup *: is called before the main loop starts * ethersex_meta_mainloop *: is called in the main loop - injected functions should do only short processings or reset the watchdog by thereselfs ... * periodic_process *: is the last function called in ethersex_meta_mainloop - after all the injected modules function *: does some network and console reading (ECMD support and other) - at the momenet I don't know the backgrounds of this operations. *: further operations can be injected here - a counter incremented on each call can be used to delay the injected code ... == meta.h / meta_header_magic.m4 == Contains the structures * uip_udp_connection_state and * uip_tcp_conenction state which can be extended with the macros * state_udp * state_tcp If a module wants to save a network relevant state as part of it's functionality, it has to be part of the connection_state structure. Since it is a union, I think, it is neccessary for passing the structure to the network functions. I.e. the module dyndns puts the dyndns connection state structure there. But look into the details by yourself - if you like. === Macro state_header === By use if this macro it is possible to include additional ".h" files into meta.h. Usage: state_header(<path_and_filename>) Expands to #include "<path_and_filename>" == Examlpe meta section == From tanklevel.c -- Ethersex META -- header(services/tanklevel/tanklevel.h) init(tanklevel_init) timer(1, tanklevel_periodic()) * header ** include file for meta.c * init ** call of tanklevel_init() in meta_init * timer ** call of tanklevel_periodic() in every time (1) the main_loop function is called. == Closing == After all this explained I want to mention that some modules are not only in that structured way integrated into the project. There are also direct compiler directives for them in the framework itself ... this looks like needed "hacks". [[Category:Development]] fd5ab1edb9613c776458479ce47f7d3709ced80f 628 625 2012-05-17T19:18:05Z Tkaltenbrunner 475 /* structure of meta.c */ wikitext text/x-wiki {{i18n|Concept of meta}} == Intro == With meta information in each module the main program is set up depending on the configuration. At the end there will be a short example of such meta information. If you continue to read, you should understand this concept: [[M4 - very short intro (Deutsch)#divert]] Also have a look at the files explained while reading - that will help. == meta.c / meta_magic.m4 == The creation of this file is mainly controlled by the file "meta_magic.m4". What is in the file meta_magic.m4? === framework for the file meta.c === The framework consists of several divert sections, in which code of the used modules is injected. Only the idea of the injection is explained with the first injection point. The second section starts with "divert(initearly_divert)dnl" and contains the function "ethersex_meta_init", but the final closing brace of the function is missing. So if you define further divert sections with the index "initearly_divert", then it will be in the output before the closing brace and so part of "ethersex_meta_init". Therefore later in in the file some macros are defined - in this case it is named "initearly". This macros and some others are all defined the same way: define(`initearly',`dnl divert(initearly_divert) $1 (); divert(-1)') So if the meta macro initearly(<module-initearly-functionname>) is used, the module initearly function will be called from the function ethersex_meta_init, because the function call will be in the output directly after the section. The closing brace of the function is part of the next section "divert(net_init_divert)". === structure of meta.c === meta.c itself contains several functions, which are called at important points in the firmware: * ethersex_meta_init *: is called in the startup before the pins are initialized * ethersex_meta_startup *: is called before the main loop starts * ethersex_meta_mainloop *: is called in the main loop - injected functions should do only short processings or reset the watchdog by thereselfs ... * periodic_process *: is the last function called in ethersex_meta_mainloop - after all the injected modules function *: does some network and console reading (ECMD support and other) - at the moment I don't know the backgrounds of this operations. *: further operations can be injected here - by use of the "timer" macro see below. * ethersex_meta_exit *: is called when a sigint is detected ... * ethersex_meta_netinit *: is called in network.c in the function network_init - after the initialization of the network stack *: remark: network.c has is own meta section which, is used to include the network functionality. === m4 macros ==== * header *: define include file for meta.c * initearly *: define a call at the start of ethersex_meta_init * init *: define a normal call in ethersex_meta_init * atexit *: define a call on shutdown - in ethersex_meta_exit * net_init *: define a call in ethersex_meta_netinit * startup *: define a call in ethersex_meta_startup * mainloop *: define a call in ethersex_meta_mainloop *: this call is done unconditional every time ethersex_meta_mainloop is called. After that the watchdog timer is resetted. * timer *: takes two parameters, the first one says in which run of periodic_process function the second paramater will be executed (every nth run). == meta.h / meta_header_magic.m4 == Contains the structures * uip_udp_connection_state and * uip_tcp_conenction state which can be extended with the macros * state_udp * state_tcp If a module wants to save a network relevant state as part of it's functionality, it has to be part of the connection_state structure. Since it is a union, I think, it is neccessary for passing the structure to the network functions. I.e. the module dyndns puts the dyndns connection state structure there. But look into the details by yourself - if you like. === Macro state_header === By use if this macro it is possible to include additional ".h" files into meta.h. Usage: state_header(<path_and_filename>) Expands to #include "<path_and_filename>" == Examlpe meta section == From tanklevel.c -- Ethersex META -- header(services/tanklevel/tanklevel.h) init(tanklevel_init) timer(1, tanklevel_periodic()) * header ** include file for meta.c * init ** call of tanklevel_init() in meta_init * timer ** call of tanklevel_periodic() in every time (1) the main_loop function is called. == Closing == After all this explained I want to mention that some modules are not only in that structured way integrated into the project. There are also direct compiler directives for them in the framework itself ... this looks like needed "hacks". [[Category:Development]] b474f04b468a865c43b326c49e1359dbba87aaa7 629 628 2012-05-17T19:18:39Z Tkaltenbrunner 475 /* m4 macros = */ wikitext text/x-wiki {{i18n|Concept of meta}} == Intro == With meta information in each module the main program is set up depending on the configuration. At the end there will be a short example of such meta information. If you continue to read, you should understand this concept: [[M4 - very short intro (Deutsch)#divert]] Also have a look at the files explained while reading - that will help. == meta.c / meta_magic.m4 == The creation of this file is mainly controlled by the file "meta_magic.m4". What is in the file meta_magic.m4? === framework for the file meta.c === The framework consists of several divert sections, in which code of the used modules is injected. Only the idea of the injection is explained with the first injection point. The second section starts with "divert(initearly_divert)dnl" and contains the function "ethersex_meta_init", but the final closing brace of the function is missing. So if you define further divert sections with the index "initearly_divert", then it will be in the output before the closing brace and so part of "ethersex_meta_init". Therefore later in in the file some macros are defined - in this case it is named "initearly". This macros and some others are all defined the same way: define(`initearly',`dnl divert(initearly_divert) $1 (); divert(-1)') So if the meta macro initearly(<module-initearly-functionname>) is used, the module initearly function will be called from the function ethersex_meta_init, because the function call will be in the output directly after the section. The closing brace of the function is part of the next section "divert(net_init_divert)". === structure of meta.c === meta.c itself contains several functions, which are called at important points in the firmware: * ethersex_meta_init *: is called in the startup before the pins are initialized * ethersex_meta_startup *: is called before the main loop starts * ethersex_meta_mainloop *: is called in the main loop - injected functions should do only short processings or reset the watchdog by thereselfs ... * periodic_process *: is the last function called in ethersex_meta_mainloop - after all the injected modules function *: does some network and console reading (ECMD support and other) - at the moment I don't know the backgrounds of this operations. *: further operations can be injected here - by use of the "timer" macro see below. * ethersex_meta_exit *: is called when a sigint is detected ... * ethersex_meta_netinit *: is called in network.c in the function network_init - after the initialization of the network stack *: remark: network.c has is own meta section which, is used to include the network functionality. === m4 macros === * header *: define include file for meta.c * initearly *: define a call at the start of ethersex_meta_init * init *: define a normal call in ethersex_meta_init * atexit *: define a call on shutdown - in ethersex_meta_exit * net_init *: define a call in ethersex_meta_netinit * startup *: define a call in ethersex_meta_startup * mainloop *: define a call in ethersex_meta_mainloop *: this call is done unconditional every time ethersex_meta_mainloop is called. After that the watchdog timer is resetted. * timer *: takes two parameters, the first one says in which run of periodic_process function the second paramater will be executed (every nth run). == meta.h / meta_header_magic.m4 == Contains the structures * uip_udp_connection_state and * uip_tcp_conenction state which can be extended with the macros * state_udp * state_tcp If a module wants to save a network relevant state as part of it's functionality, it has to be part of the connection_state structure. Since it is a union, I think, it is neccessary for passing the structure to the network functions. I.e. the module dyndns puts the dyndns connection state structure there. But look into the details by yourself - if you like. === Macro state_header === By use if this macro it is possible to include additional ".h" files into meta.h. Usage: state_header(<path_and_filename>) Expands to #include "<path_and_filename>" == Examlpe meta section == From tanklevel.c -- Ethersex META -- header(services/tanklevel/tanklevel.h) init(tanklevel_init) timer(1, tanklevel_periodic()) * header ** include file for meta.c * init ** call of tanklevel_init() in meta_init * timer ** call of tanklevel_periodic() in every time (1) the main_loop function is called. == Closing == After all this explained I want to mention that some modules are not only in that structured way integrated into the project. There are also direct compiler directives for them in the framework itself ... this looks like needed "hacks". [[Category:Development]] 825bebc40858d9a7de15b93ceb89a9afac497e11 632 629 2012-05-17T19:22:36Z Tkaltenbrunner 475 /* m4 macros */ wikitext text/x-wiki {{i18n|Concept of meta}} == Intro == With meta information in each module the main program is set up depending on the configuration. At the end there will be a short example of such meta information. If you continue to read, you should understand this concept: [[M4 - very short intro (Deutsch)#divert]] Also have a look at the files explained while reading - that will help. == meta.c / meta_magic.m4 == The creation of this file is mainly controlled by the file "meta_magic.m4". What is in the file meta_magic.m4? === framework for the file meta.c === The framework consists of several divert sections, in which code of the used modules is injected. Only the idea of the injection is explained with the first injection point. The second section starts with "divert(initearly_divert)dnl" and contains the function "ethersex_meta_init", but the final closing brace of the function is missing. So if you define further divert sections with the index "initearly_divert", then it will be in the output before the closing brace and so part of "ethersex_meta_init". Therefore later in in the file some macros are defined - in this case it is named "initearly". This macros and some others are all defined the same way: define(`initearly',`dnl divert(initearly_divert) $1 (); divert(-1)') So if the meta macro initearly(<module-initearly-functionname>) is used, the module initearly function will be called from the function ethersex_meta_init, because the function call will be in the output directly after the section. The closing brace of the function is part of the next section "divert(net_init_divert)". === structure of meta.c === meta.c itself contains several functions, which are called at important points in the firmware: * ethersex_meta_init *: is called in the startup before the pins are initialized * ethersex_meta_startup *: is called before the main loop starts * ethersex_meta_mainloop *: is called in the main loop - injected functions should do only short processings or reset the watchdog by thereselfs ... * periodic_process *: is the last function called in ethersex_meta_mainloop - after all the injected modules function *: does some network and console reading (ECMD support and other) - at the moment I don't know the backgrounds of this operations. *: further operations can be injected here - by use of the "timer" macro see below. * ethersex_meta_exit *: is called when a sigint is detected ... * ethersex_meta_netinit *: is called in network.c in the function network_init - after the initialization of the network stack *: remark: network.c has is own meta section which, is used to include the network functionality. === m4 macros === * header *: define include file for meta.c * initearly *: define a call at the start of ethersex_meta_init * init *: define a normal call in ethersex_meta_init * atexit *: define a call on shutdown - in ethersex_meta_exit * net_init *: define a call in ethersex_meta_netinit * startup *: define a call in ethersex_meta_startup * mainloop *: define a call in ethersex_meta_mainloop *: this call is done unconditional every time ethersex_meta_mainloop is called. After that the watchdog timer is resetted. *: I think, it is only for important fuctions - use timer instead. * timer *: takes two parameters, the first one says in which run of periodic_process function the second paramater will be executed (every nth run). == meta.h / meta_header_magic.m4 == Contains the structures * uip_udp_connection_state and * uip_tcp_conenction state which can be extended with the macros * state_udp * state_tcp If a module wants to save a network relevant state as part of it's functionality, it has to be part of the connection_state structure. Since it is a union, I think, it is neccessary for passing the structure to the network functions. I.e. the module dyndns puts the dyndns connection state structure there. But look into the details by yourself - if you like. === Macro state_header === By use if this macro it is possible to include additional ".h" files into meta.h. Usage: state_header(<path_and_filename>) Expands to #include "<path_and_filename>" == Examlpe meta section == From tanklevel.c -- Ethersex META -- header(services/tanklevel/tanklevel.h) init(tanklevel_init) timer(1, tanklevel_periodic()) * header ** include file for meta.c * init ** call of tanklevel_init() in meta_init * timer ** call of tanklevel_periodic() in every time (1) the main_loop function is called. == Closing == After all this explained I want to mention that some modules are not only in that structured way integrated into the project. There are also direct compiler directives for them in the framework itself ... this looks like needed "hacks". [[Category:Development]] 06cb85a0a9057b155502ddbf3af22116acee77e0 0 208 626 554 2012-05-17T18:46:39Z Tkaltenbrunner 475 /* Wichtiges */ wikitext text/x-wiki == Einleitung == Die offizielle Doku gibt es hier: http://www.gnu.org/software/m4/manual/index.html Hier noch ein ganze kurze Einführung: Von der Idee her, ist es mit dem C-Präprocessor vergleichbar, der ebenfalls Macro-Ersetzungen durchführt und das Ergebnis an den C-Compiler weiterleitet. Bei m4 ist das Ergebnisse lediglich der Text, den die Macro-Ersetzungen ergeben. Wie es genau funktioniert, aber unbedingt nachlesen, da es manchmal auch auf die Feinheiten ankommt. Kommentare werden mit # wie in C gekennzeichnet. Es gibt keinen "Befehlsterminator" wie z.B. ein Semikolon. Ersetzungen werden aber ähnlich wie ein Funktionen in einer Programmiersprache aufgerufen. Wichtig ist auch die Quotierung mit ` und ' , die das Verhalten bei der Macro-Expandierung entscheidend beeinflusst. siehe hier und folgende http://www.gnu.org/software/m4/manual/m4.html#Quoting-Arguments == Macro definieren == Im Gegensatz zum C-Präprocessor wird hier ein sogenanntes "builtin" benutzt: define(name, [expansion]) Zu beachten: werden die Argumente nicht quotiert, kann hier schon die Macro-Erweiterung zuschlagen, was dann zu unerwünschten Ergebnissen führen kann. Mit den "Pseudo-Variablen" $1, $2, etc. kann man die Argumente des Macros in der Expansion referenzieren. Im Gegensatz zum C-Präprozessor, der überwiegend mit benannten Parametern arbeitet. * $* - alle Argumente * $@ - alle Argumente quotiert - Im Gegensatz zur vorhergehenden Variante werden die Argumente nicht weiter expandiert. * $# - Anzahl der Argumente == Kontrol-Strukturen == Hiermit sind bedingte Ausführung und Schleifen gemeint. * ifdef(name, string1, [string2]) *: - wenn name definiert ist, dann ist das Ergebnis string1, sonst string2 * ifelse(string1, string2, equal1, string3, string4, equal2, ..., [not_equal]) *: - wenn string1 = string2, dann equal1, sonst if string3 = string4, dann equal2, sonst ..., sonst not_equal * join oder joinall([separator], [args....]) *: - args zusammenfügen, Separator dazwischen setzen. Bei joinall wird immer der Separator gesetzt - auch wenn ein Argument leer ist. * Rekursive Macro-Definitionen sind auch möglich - hilfreich dabei die shift Funktion, die jeweils das erste Argument abschneidet. * forloop (iterator, start, end, text) *:- iterator muss ein gültiger Macroname sein, Start und Ende ganze Zahlen, der Text wird gemäß der Schleifendurchläufe ersetzt. * foreach (iterator, paren-list, text) / foreachq (iterator, paren-list, text) *: - jedes Argument der parent-list wird an den Iterator gebunden und dann eine Ersetzung für Text ausgeführt. == divert == Da dieses Konstrukt häufig in Ethersex eingesetzt wird, hier noch ein paar Extra-Bemerkungen: Mit divert(<ausgabeidx>) wird ein Text-Abschnitt begonnen, der an der durch <ausgabeindex> definierten Stelle in die Ausgabe-Text eingefügt wird. <ausgabeidx> ist eine ganze, positive Zahl. Abschnitt 1 wird vor 2, 2 wird vor 3, usw. ausgegeben. Dabei spielt es keine Rolle, in welcher Reiehnfolge die Abschnitt in der m4-Quelldatei definiert werden. Der Textabschnitt wird durch ein weiteres "divert" beendet, wobei "divert(-1)" dafür sorgt, dass kein neuer Abschnitt beginnt. Sind mehrer Abschnitte mit dem gleichen <ausgabeidx> definiert, so werden sie mit der Reihenfolge ihrer Defnition ausgegeben. === Beispiel: === divert(3)dnl Das ist Abschnitt 3 divert(2)dnl Das ist Abschnitt 2a divert(1)dnl Das ist Abschnitt 1 divert(2)dnl Das ist Abschnitt 2b divert(-1)dnl Die Ausgabe sind dann wie folgt aus: Das ist Abschnitt 1 Das ist Abschnitt 2a Das ist Abschnitt 2b Das ist Abschnitt 3 Bemerkung: die Sprache ist sehr mächtig und man kann "Wildes" konstruieren, dass man nach 2 Tagen selber nicht mehr versteht ;-) == Wichtiges == * dnl - "Discard to next line" - Schließt die Zeile ab - alles nachfolgende wird ignoriert. * changecom(<newcomment-start>) - ändert das Kommentarzeichen auf die angegebene Zeichenfolge (Default: #) 0820b7eb5bc0ef7f33fffbfba45ecf8989af6c47 0 205 627 613 2012-05-17T18:48:50Z Tkaltenbrunner 475 /* make menuconfig */ wikitext text/x-wiki {{i18n|Configuration of Boards and Pins}} == Intro == This page will explain some of the details behind menuconfig. It is meant for developers who want to look behind the curtain or if someone wants to debug a modul which does not work or compile any more .... == make menuconfig == Integration of modules into menuconfig is described on this page [[Own module#Menuconfig]] - here a look at the results and the output of menuconfig. The configuration is saved in two different formats: * file .config for the menuconfig itself - ** it is used for including it into the makefile ** it incluences also the build process of the binary file ** definition auf makefile variables * file autoconfig.h - ** it is for including it in the compilation ** definition of C preprocessor macros and defines I thing the details of the configuration should become clear after doing the menuconfig and reading about the modules. May be I can explain some "core" configuration later. == make == The first steps in the build process are to get all the configuration information and build some source files which put it all together. Besides some usual unix tools like sed the m4 macro processor plays an important role. Even if it is not in the scope of this wiki, I added a very short intro here: [[m4 - very short intro]] === meta.m4 === If you have a look at the different source codes of the modules, you find at the bottom of the main c-file a comment section starting with "-- Ethersex META --". You find there m4 macros which are used to integrate the modul into the main program of ethersex. Details later. meta.m4 is the extraction and collection of these sections. The files which are used, are denfined by the makefile of each "module". Each C source files has to be added to the make var "y_SRC". A nice trick is used there by the use of ".config", where all the used and configured feature are assigned a "y" to make vars. i.e. MODULX_GENERAL_SUPPORT=y Then in the makefile of ModuleX: $(MODULX_GENERAL_SUPPORT)_SRC += file1.c file2.c ... If the module is not activated the files added to _SRC instead of y_SRC. === meta.c === Is generated by m4 macros. The inputs are: (controlled centrally in the Makefile!) * autoconfig.h *: is converted and each define line results into one m4 command line parameter of the form -Dconf_<parname> * scripts/meta_magic.m4 *: contains the framework for meta.c * protocols/ecmd/ecmd_magic.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * protocols/soap/soap_magic.m4 *: only if SOAP support is activated - make var $(SOAP_SUPPORT) must be set to "y" * meta.m4 *: see above * protocols/ecmd/ecmd_defs.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced by the make var ${named_pin_simple_files} *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced by the make var $(y_NP_SIMPLE_META_SRC) *: unconditional ... but contain the following files, if ECMD parser or SOAP support is activated: ** protocols/ecmd/ecmd_defs.m4 ** ${named_pin_simple_files} *: so I think it could be a small bug - if ECMD parser support is on, the files are added twice - may be this does not matter. ==== What is in ${named_pin_simple_files}? ==== That should be a chapter for itself - containing how the internals of defining pins works. In the default case that are probably the following files: * core/portio/np_simple.m4 * protocols/ecmd/np_simple_glue.m4 === meta.h === is also generated from m4 macros. Files used: * scripts/meta_header_magic.m4 *: framework of meta.h and macros. * meta.m4 meta.m4 is part of meta.c and meta.h - how is it possible, may someone ask. The answer: macros, which are not defined, eval to empty string. So it depends on the defined macros to what meta.m4 is expanded. More about the interesting [[concept of meta]]. === pinning.c === The detailied concept of pinning will be descriped in an own chapter. At the moment is important to know that each processor has several ports which can have different functions and are connected sometimes to devices on the board already. If you connect your own hardware to the board which should be supported by an ethersex module you must configure the port(s) which connects the hardware with the processor. Files from which pinning.c is build: * pinning/internals/header.m4 * pinning/controllers/<mcuname>.m4 *: mcuname is defined by the make var MCU * pinning/internals/hackery_<mcuname>.m4 * pinning/hardware/<boardname>.m4 *: <boardname> is definned by make var HARDWARE * pinning/internals/footer.m4 * autoconfig.h *: is converted and each define line results into one m4 command line parameter of the form -Dconf_<parname> What you should realize is, the pinning.c file is independent from any module, so the connection of module and pinning must be defined in one of the mentioned files! [[Category:Development]] 3df8ef2b3074d5e5b93b3db16f6dc08b898a5cf7 633 627 2012-05-17T19:24:52Z Tkaltenbrunner 475 /* make menuconfig */ wikitext text/x-wiki {{i18n|Configuration of Boards and Pins}} == Intro == This page will explain some of the details behind menuconfig. It is meant for developers who want to look behind the curtain or if someone wants to debug a modul which does not work or compile any more .... == make menuconfig == Integration of modules into menuconfig is described on this page [[Own module#Menuconfig]] - here a look at the results and the output of menuconfig. The configuration is saved in two different formats: * file .config for the menuconfig itself - ** it is used for including it into the makefile ** it influences also the build process of the binary file ** definition auf makefile variables * file autoconfig.h - ** it is for including it in the compilation ** definition of C preprocessor macros and defines I thing the details of the configuration should become clear after doing the menuconfig and reading about the modules. May be I can explain some "core" configuration later. == make == The first steps in the build process are to get all the configuration information and build some source files which put it all together. Besides some usual unix tools like sed the m4 macro processor plays an important role. Even if it is not in the scope of this wiki, I added a very short intro here: [[m4 - very short intro]] === meta.m4 === If you have a look at the different source codes of the modules, you find at the bottom of the main c-file a comment section starting with "-- Ethersex META --". You find there m4 macros which are used to integrate the modul into the main program of ethersex. Details later. meta.m4 is the extraction and collection of these sections. The files which are used, are denfined by the makefile of each "module". Each C source files has to be added to the make var "y_SRC". A nice trick is used there by the use of ".config", where all the used and configured feature are assigned a "y" to make vars. i.e. MODULX_GENERAL_SUPPORT=y Then in the makefile of ModuleX: $(MODULX_GENERAL_SUPPORT)_SRC += file1.c file2.c ... If the module is not activated the files added to _SRC instead of y_SRC. === meta.c === Is generated by m4 macros. The inputs are: (controlled centrally in the Makefile!) * autoconfig.h *: is converted and each define line results into one m4 command line parameter of the form -Dconf_<parname> * scripts/meta_magic.m4 *: contains the framework for meta.c * protocols/ecmd/ecmd_magic.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * protocols/soap/soap_magic.m4 *: only if SOAP support is activated - make var $(SOAP_SUPPORT) must be set to "y" * meta.m4 *: see above * protocols/ecmd/ecmd_defs.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced by the make var ${named_pin_simple_files} *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced by the make var $(y_NP_SIMPLE_META_SRC) *: unconditional ... but contain the following files, if ECMD parser or SOAP support is activated: ** protocols/ecmd/ecmd_defs.m4 ** ${named_pin_simple_files} *: so I think it could be a small bug - if ECMD parser support is on, the files are added twice - may be this does not matter. ==== What is in ${named_pin_simple_files}? ==== That should be a chapter for itself - containing how the internals of defining pins works. In the default case that are probably the following files: * core/portio/np_simple.m4 * protocols/ecmd/np_simple_glue.m4 === meta.h === is also generated from m4 macros. Files used: * scripts/meta_header_magic.m4 *: framework of meta.h and macros. * meta.m4 meta.m4 is part of meta.c and meta.h - how is it possible, may someone ask. The answer: macros, which are not defined, eval to empty string. So it depends on the defined macros to what meta.m4 is expanded. More about the interesting [[concept of meta]]. === pinning.c === The detailied concept of pinning will be descriped in an own chapter. At the moment is important to know that each processor has several ports which can have different functions and are connected sometimes to devices on the board already. If you connect your own hardware to the board which should be supported by an ethersex module you must configure the port(s) which connects the hardware with the processor. Files from which pinning.c is build: * pinning/internals/header.m4 * pinning/controllers/<mcuname>.m4 *: mcuname is defined by the make var MCU * pinning/internals/hackery_<mcuname>.m4 * pinning/hardware/<boardname>.m4 *: <boardname> is definned by make var HARDWARE * pinning/internals/footer.m4 * autoconfig.h *: is converted and each define line results into one m4 command line parameter of the form -Dconf_<parname> What you should realize is, the pinning.c file is independent from any module, so the connection of module and pinning must be defined in one of the mentioned files! [[Category:Development]] bddc50d6886268641de4dd82aaef760201cc7c3b 634 633 2012-05-17T19:26:01Z Tkaltenbrunner 475 /* meta.m4 */ wikitext text/x-wiki {{i18n|Configuration of Boards and Pins}} == Intro == This page will explain some of the details behind menuconfig. It is meant for developers who want to look behind the curtain or if someone wants to debug a modul which does not work or compile any more .... == make menuconfig == Integration of modules into menuconfig is described on this page [[Own module#Menuconfig]] - here a look at the results and the output of menuconfig. The configuration is saved in two different formats: * file .config for the menuconfig itself - ** it is used for including it into the makefile ** it influences also the build process of the binary file ** definition auf makefile variables * file autoconfig.h - ** it is for including it in the compilation ** definition of C preprocessor macros and defines I thing the details of the configuration should become clear after doing the menuconfig and reading about the modules. May be I can explain some "core" configuration later. == make == The first steps in the build process are to get all the configuration information and build some source files which put it all together. Besides some usual unix tools like sed the m4 macro processor plays an important role. Even if it is not in the scope of this wiki, I added a very short intro here: [[m4 - very short intro]] === meta.m4 === If you have a look at the different source codes of the modules, you find at the bottom of the main c-file a comment section starting with "-- Ethersex META --". You find there m4 macros which are used to integrate the modul into the main program of ethersex. Details here: [[Concept of meta]]. meta.m4 is the extraction and collection of these sections. The files which are used, are denfined by the makefile of each "module". Each C source files has to be added to the make var "y_SRC". A nice trick is used there by the use of ".config", where all the used and configured feature are assigned a "y" to make vars. i.e. MODULX_GENERAL_SUPPORT=y Then in the makefile of ModuleX: $(MODULX_GENERAL_SUPPORT)_SRC += file1.c file2.c ... If the module is not activated the files added to _SRC instead of y_SRC. === meta.c === Is generated by m4 macros. The inputs are: (controlled centrally in the Makefile!) * autoconfig.h *: is converted and each define line results into one m4 command line parameter of the form -Dconf_<parname> * scripts/meta_magic.m4 *: contains the framework for meta.c * protocols/ecmd/ecmd_magic.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * protocols/soap/soap_magic.m4 *: only if SOAP support is activated - make var $(SOAP_SUPPORT) must be set to "y" * meta.m4 *: see above * protocols/ecmd/ecmd_defs.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced by the make var ${named_pin_simple_files} *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced by the make var $(y_NP_SIMPLE_META_SRC) *: unconditional ... but contain the following files, if ECMD parser or SOAP support is activated: ** protocols/ecmd/ecmd_defs.m4 ** ${named_pin_simple_files} *: so I think it could be a small bug - if ECMD parser support is on, the files are added twice - may be this does not matter. ==== What is in ${named_pin_simple_files}? ==== That should be a chapter for itself - containing how the internals of defining pins works. In the default case that are probably the following files: * core/portio/np_simple.m4 * protocols/ecmd/np_simple_glue.m4 === meta.h === is also generated from m4 macros. Files used: * scripts/meta_header_magic.m4 *: framework of meta.h and macros. * meta.m4 meta.m4 is part of meta.c and meta.h - how is it possible, may someone ask. The answer: macros, which are not defined, eval to empty string. So it depends on the defined macros to what meta.m4 is expanded. More about the interesting [[concept of meta]]. === pinning.c === The detailied concept of pinning will be descriped in an own chapter. At the moment is important to know that each processor has several ports which can have different functions and are connected sometimes to devices on the board already. If you connect your own hardware to the board which should be supported by an ethersex module you must configure the port(s) which connects the hardware with the processor. Files from which pinning.c is build: * pinning/internals/header.m4 * pinning/controllers/<mcuname>.m4 *: mcuname is defined by the make var MCU * pinning/internals/hackery_<mcuname>.m4 * pinning/hardware/<boardname>.m4 *: <boardname> is definned by make var HARDWARE * pinning/internals/footer.m4 * autoconfig.h *: is converted and each define line results into one m4 command line parameter of the form -Dconf_<parname> What you should realize is, the pinning.c file is independent from any module, so the connection of module and pinning must be defined in one of the mentioned files! [[Category:Development]] 0d495772a1266485a4f1ae55d96c6176b7ea77c2 635 634 2012-05-17T19:26:41Z Tkaltenbrunner 475 /* meta.m4 */ wikitext text/x-wiki {{i18n|Configuration of Boards and Pins}} == Intro == This page will explain some of the details behind menuconfig. It is meant for developers who want to look behind the curtain or if someone wants to debug a modul which does not work or compile any more .... == make menuconfig == Integration of modules into menuconfig is described on this page [[Own module#Menuconfig]] - here a look at the results and the output of menuconfig. The configuration is saved in two different formats: * file .config for the menuconfig itself - ** it is used for including it into the makefile ** it influences also the build process of the binary file ** definition auf makefile variables * file autoconfig.h - ** it is for including it in the compilation ** definition of C preprocessor macros and defines I thing the details of the configuration should become clear after doing the menuconfig and reading about the modules. May be I can explain some "core" configuration later. == make == The first steps in the build process are to get all the configuration information and build some source files which put it all together. Besides some usual unix tools like sed the m4 macro processor plays an important role. Even if it is not in the scope of this wiki, I added a very short intro here: [[m4 - very short intro]] === meta.m4 === If you have a look at the different source codes of the modules, you find at the bottom of the main c-file a comment section starting with "-- Ethersex META --". You find there m4 macros which are used to integrate the modul into the main program of ethersex. Details here: [[Concept of meta]]. meta.m4 is the extraction and collection of these sections. The files which are used, are defined by the makefile of each "module". Each C source files has to be added to the make var "y_SRC". A nice trick is used there by the use of ".config", where all the used and configured feature are assigned a "y" to make vars. i.e. MODULX_GENERAL_SUPPORT=y Then in the makefile of ModuleX: $(MODULX_GENERAL_SUPPORT)_SRC += file1.c file2.c ... If the module is not activated the files added to _SRC instead of y_SRC. === meta.c === Is generated by m4 macros. The inputs are: (controlled centrally in the Makefile!) * autoconfig.h *: is converted and each define line results into one m4 command line parameter of the form -Dconf_<parname> * scripts/meta_magic.m4 *: contains the framework for meta.c * protocols/ecmd/ecmd_magic.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * protocols/soap/soap_magic.m4 *: only if SOAP support is activated - make var $(SOAP_SUPPORT) must be set to "y" * meta.m4 *: see above * protocols/ecmd/ecmd_defs.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced by the make var ${named_pin_simple_files} *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced by the make var $(y_NP_SIMPLE_META_SRC) *: unconditional ... but contain the following files, if ECMD parser or SOAP support is activated: ** protocols/ecmd/ecmd_defs.m4 ** ${named_pin_simple_files} *: so I think it could be a small bug - if ECMD parser support is on, the files are added twice - may be this does not matter. ==== What is in ${named_pin_simple_files}? ==== That should be a chapter for itself - containing how the internals of defining pins works. In the default case that are probably the following files: * core/portio/np_simple.m4 * protocols/ecmd/np_simple_glue.m4 === meta.h === is also generated from m4 macros. Files used: * scripts/meta_header_magic.m4 *: framework of meta.h and macros. * meta.m4 meta.m4 is part of meta.c and meta.h - how is it possible, may someone ask. The answer: macros, which are not defined, eval to empty string. So it depends on the defined macros to what meta.m4 is expanded. More about the interesting [[concept of meta]]. === pinning.c === The detailied concept of pinning will be descriped in an own chapter. At the moment is important to know that each processor has several ports which can have different functions and are connected sometimes to devices on the board already. If you connect your own hardware to the board which should be supported by an ethersex module you must configure the port(s) which connects the hardware with the processor. Files from which pinning.c is build: * pinning/internals/header.m4 * pinning/controllers/<mcuname>.m4 *: mcuname is defined by the make var MCU * pinning/internals/hackery_<mcuname>.m4 * pinning/hardware/<boardname>.m4 *: <boardname> is definned by make var HARDWARE * pinning/internals/footer.m4 * autoconfig.h *: is converted and each define line results into one m4 command line parameter of the form -Dconf_<parname> What you should realize is, the pinning.c file is independent from any module, so the connection of module and pinning must be defined in one of the mentioned files! [[Category:Development]] 876e4b61ae567f56dbe8e0d63fd5d11dc4dd28e9 638 635 2012-05-18T18:39:00Z Tkaltenbrunner 475 /* pinning.c */ wikitext text/x-wiki {{i18n|Configuration of Boards and Pins}} == Intro == This page will explain some of the details behind menuconfig. It is meant for developers who want to look behind the curtain or if someone wants to debug a modul which does not work or compile any more .... == make menuconfig == Integration of modules into menuconfig is described on this page [[Own module#Menuconfig]] - here a look at the results and the output of menuconfig. The configuration is saved in two different formats: * file .config for the menuconfig itself - ** it is used for including it into the makefile ** it influences also the build process of the binary file ** definition auf makefile variables * file autoconfig.h - ** it is for including it in the compilation ** definition of C preprocessor macros and defines I thing the details of the configuration should become clear after doing the menuconfig and reading about the modules. May be I can explain some "core" configuration later. == make == The first steps in the build process are to get all the configuration information and build some source files which put it all together. Besides some usual unix tools like sed the m4 macro processor plays an important role. Even if it is not in the scope of this wiki, I added a very short intro here: [[m4 - very short intro]] === meta.m4 === If you have a look at the different source codes of the modules, you find at the bottom of the main c-file a comment section starting with "-- Ethersex META --". You find there m4 macros which are used to integrate the modul into the main program of ethersex. Details here: [[Concept of meta]]. meta.m4 is the extraction and collection of these sections. The files which are used, are defined by the makefile of each "module". Each C source files has to be added to the make var "y_SRC". A nice trick is used there by the use of ".config", where all the used and configured feature are assigned a "y" to make vars. i.e. MODULX_GENERAL_SUPPORT=y Then in the makefile of ModuleX: $(MODULX_GENERAL_SUPPORT)_SRC += file1.c file2.c ... If the module is not activated the files added to _SRC instead of y_SRC. === meta.c === Is generated by m4 macros. The inputs are: (controlled centrally in the Makefile!) * autoconfig.h *: is converted and each define line results into one m4 command line parameter of the form -Dconf_<parname> * scripts/meta_magic.m4 *: contains the framework for meta.c * protocols/ecmd/ecmd_magic.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * protocols/soap/soap_magic.m4 *: only if SOAP support is activated - make var $(SOAP_SUPPORT) must be set to "y" * meta.m4 *: see above * protocols/ecmd/ecmd_defs.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced by the make var ${named_pin_simple_files} *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced by the make var $(y_NP_SIMPLE_META_SRC) *: unconditional ... but contain the following files, if ECMD parser or SOAP support is activated: ** protocols/ecmd/ecmd_defs.m4 ** ${named_pin_simple_files} *: so I think it could be a small bug - if ECMD parser support is on, the files are added twice - may be this does not matter. ==== What is in ${named_pin_simple_files}? ==== That should be a chapter for itself - containing how the internals of defining pins works. In the default case that are probably the following files: * core/portio/np_simple.m4 * protocols/ecmd/np_simple_glue.m4 === meta.h === is also generated from m4 macros. Files used: * scripts/meta_header_magic.m4 *: framework of meta.h and macros. * meta.m4 meta.m4 is part of meta.c and meta.h - how is it possible, may someone ask. The answer: macros, which are not defined, eval to empty string. So it depends on the defined macros to what meta.m4 is expanded. More about the interesting [[concept of meta]]. === pinning.c === The detailied concept of pinning will be descriped in a chapter by its own. At the moment is important to know that each processor has several ports which can have different functions and are connected sometimes to devices on the board already. If you connect your own hardware to the board which should be supported by an ethersex module you must configure the port(s) which connects the hardware with the processor. Files from which pinning.c is build: * pinning/internals/header.m4 * pinning/controllers/<mcuname>.m4 *: mcuname is defined by the make var MCU * pinning/internals/hackery_<mcuname>.m4 * pinning/hardware/<boardname>.m4 *: <boardname> is definned by make var HARDWARE * pinning/internals/footer.m4 * autoconfig.h *: is converted and each define line results into one m4 command line parameter of the form -Dconf_<parname> What you should realize is, the pinning.c file is independent from any module, so the connection of module and pinning must be defined in one of the mentioned files! [[Category:Development]] ba5314caaa663a755935060d803d6b38dd945d5c 639 638 2012-05-18T19:20:33Z Tkaltenbrunner 475 /* pinning.c */ wikitext text/x-wiki {{i18n|Configuration of Boards and Pins}} == Intro == This page will explain some of the details behind menuconfig. It is meant for developers who want to look behind the curtain or if someone wants to debug a modul which does not work or compile any more .... == make menuconfig == Integration of modules into menuconfig is described on this page [[Own module#Menuconfig]] - here a look at the results and the output of menuconfig. The configuration is saved in two different formats: * file .config for the menuconfig itself - ** it is used for including it into the makefile ** it influences also the build process of the binary file ** definition auf makefile variables * file autoconfig.h - ** it is for including it in the compilation ** definition of C preprocessor macros and defines I thing the details of the configuration should become clear after doing the menuconfig and reading about the modules. May be I can explain some "core" configuration later. == make == The first steps in the build process are to get all the configuration information and build some source files which put it all together. Besides some usual unix tools like sed the m4 macro processor plays an important role. Even if it is not in the scope of this wiki, I added a very short intro here: [[m4 - very short intro]] === meta.m4 === If you have a look at the different source codes of the modules, you find at the bottom of the main c-file a comment section starting with "-- Ethersex META --". You find there m4 macros which are used to integrate the modul into the main program of ethersex. Details here: [[Concept of meta]]. meta.m4 is the extraction and collection of these sections. The files which are used, are defined by the makefile of each "module". Each C source files has to be added to the make var "y_SRC". A nice trick is used there by the use of ".config", where all the used and configured feature are assigned a "y" to make vars. i.e. MODULX_GENERAL_SUPPORT=y Then in the makefile of ModuleX: $(MODULX_GENERAL_SUPPORT)_SRC += file1.c file2.c ... If the module is not activated the files added to _SRC instead of y_SRC. === meta.c === Is generated by m4 macros. The inputs are: (controlled centrally in the Makefile!) * autoconfig.h *: is converted and each define line results into one m4 command line parameter of the form -Dconf_<parname> * scripts/meta_magic.m4 *: contains the framework for meta.c * protocols/ecmd/ecmd_magic.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * protocols/soap/soap_magic.m4 *: only if SOAP support is activated - make var $(SOAP_SUPPORT) must be set to "y" * meta.m4 *: see above * protocols/ecmd/ecmd_defs.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced by the make var ${named_pin_simple_files} *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced by the make var $(y_NP_SIMPLE_META_SRC) *: unconditional ... but contain the following files, if ECMD parser or SOAP support is activated: ** protocols/ecmd/ecmd_defs.m4 ** ${named_pin_simple_files} *: so I think it could be a small bug - if ECMD parser support is on, the files are added twice - may be this does not matter. ==== What is in ${named_pin_simple_files}? ==== That should be a chapter for itself - containing how the internals of defining pins works. In the default case that are probably the following files: * core/portio/np_simple.m4 * protocols/ecmd/np_simple_glue.m4 === meta.h === is also generated from m4 macros. Files used: * scripts/meta_header_magic.m4 *: framework of meta.h and macros. * meta.m4 meta.m4 is part of meta.c and meta.h - how is it possible, may someone ask. The answer: macros, which are not defined, eval to empty string. So it depends on the defined macros to what meta.m4 is expanded. More about the interesting [[concept of meta]]. === pinning.c === The detailied concept of pinning will be descriped in a chapter by its own. At the moment is important to know that each processor has several ports which can have different functions and are connected sometimes to devices on the board already. If you connect your own hardware to the board which should be supported by an ethersex module you must configure the port(s) which connects the hardware with the processor. Files from which pinning.c is build: * pinning/internals/header.m4 * pinning/controllers/<mcuname>.m4 *: mcuname is defined by the make var MCU * pinning/internals/hackery_<mcuname>.m4 * pinning/hardware/<boardname>.m4 *: <boardname> is definned by make var HARDWARE * pinning/internals/footer.m4 * autoconfig.h *: is converted and each define line results into one m4 command line parameter of the form -Dconf_<parname> What you should realize is, the pinning.c file is independent from any module, so the connection of module and pinning must be defined in one of the mentioned files! ==== pinning/internals/header.m4 ===== Is difficult to understand at the first look. Looks like to much module specific stuff (macros) is placed in this file (for convinience I think). So it is hard to identify the multi purpose macros. Perhabs I will find out later, what is important. Here the important one used very often: pin(<module_named_pin>, <processer_named_pin>) With this macros the pin name, with is used in a module is assigned to a pin of the processor or mcu. It is some kind of wiring - here on the level of the software. ==== pinning/controllers/<mcuname>.m4 ==== Here connections of special functions like SPI or I2C are connected to ports, because this ports are often fixed and cannot be switched to another port. Furtheron some mcu features are defined like number ADC_CHANNELS and other defines for special characteristics of the mcu, which need extra handling. ==== pinning/internals/hackery_<mcuname>.m4 ==== ???? ==== pinning/hardware/<boardname>.m4 ==== Here you find the connections between processor an onboard hardware like the network module. Also you find pin configuration of modules that need connected hardware, i.e. the DCF77 module. So you see, this is the place, where all connections to external devices are defined. I think, when connect your own hardware or want to use other ports as defined here, make a copy of the default m4 file and work with your version of the board file. [[Category:Development]] 03c982b66ebf496d3f5c2bf7e931c38a3e7578bb 640 639 2012-05-18T19:21:22Z Tkaltenbrunner 475 /* pinning/internals/header.m4 = */ wikitext text/x-wiki {{i18n|Configuration of Boards and Pins}} == Intro == This page will explain some of the details behind menuconfig. It is meant for developers who want to look behind the curtain or if someone wants to debug a modul which does not work or compile any more .... == make menuconfig == Integration of modules into menuconfig is described on this page [[Own module#Menuconfig]] - here a look at the results and the output of menuconfig. The configuration is saved in two different formats: * file .config for the menuconfig itself - ** it is used for including it into the makefile ** it influences also the build process of the binary file ** definition auf makefile variables * file autoconfig.h - ** it is for including it in the compilation ** definition of C preprocessor macros and defines I thing the details of the configuration should become clear after doing the menuconfig and reading about the modules. May be I can explain some "core" configuration later. == make == The first steps in the build process are to get all the configuration information and build some source files which put it all together. Besides some usual unix tools like sed the m4 macro processor plays an important role. Even if it is not in the scope of this wiki, I added a very short intro here: [[m4 - very short intro]] === meta.m4 === If you have a look at the different source codes of the modules, you find at the bottom of the main c-file a comment section starting with "-- Ethersex META --". You find there m4 macros which are used to integrate the modul into the main program of ethersex. Details here: [[Concept of meta]]. meta.m4 is the extraction and collection of these sections. The files which are used, are defined by the makefile of each "module". Each C source files has to be added to the make var "y_SRC". A nice trick is used there by the use of ".config", where all the used and configured feature are assigned a "y" to make vars. i.e. MODULX_GENERAL_SUPPORT=y Then in the makefile of ModuleX: $(MODULX_GENERAL_SUPPORT)_SRC += file1.c file2.c ... If the module is not activated the files added to _SRC instead of y_SRC. === meta.c === Is generated by m4 macros. The inputs are: (controlled centrally in the Makefile!) * autoconfig.h *: is converted and each define line results into one m4 command line parameter of the form -Dconf_<parname> * scripts/meta_magic.m4 *: contains the framework for meta.c * protocols/ecmd/ecmd_magic.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * protocols/soap/soap_magic.m4 *: only if SOAP support is activated - make var $(SOAP_SUPPORT) must be set to "y" * meta.m4 *: see above * protocols/ecmd/ecmd_defs.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced by the make var ${named_pin_simple_files} *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced by the make var $(y_NP_SIMPLE_META_SRC) *: unconditional ... but contain the following files, if ECMD parser or SOAP support is activated: ** protocols/ecmd/ecmd_defs.m4 ** ${named_pin_simple_files} *: so I think it could be a small bug - if ECMD parser support is on, the files are added twice - may be this does not matter. ==== What is in ${named_pin_simple_files}? ==== That should be a chapter for itself - containing how the internals of defining pins works. In the default case that are probably the following files: * core/portio/np_simple.m4 * protocols/ecmd/np_simple_glue.m4 === meta.h === is also generated from m4 macros. Files used: * scripts/meta_header_magic.m4 *: framework of meta.h and macros. * meta.m4 meta.m4 is part of meta.c and meta.h - how is it possible, may someone ask. The answer: macros, which are not defined, eval to empty string. So it depends on the defined macros to what meta.m4 is expanded. More about the interesting [[concept of meta]]. === pinning.c === The detailied concept of pinning will be descriped in a chapter by its own. At the moment is important to know that each processor has several ports which can have different functions and are connected sometimes to devices on the board already. If you connect your own hardware to the board which should be supported by an ethersex module you must configure the port(s) which connects the hardware with the processor. Files from which pinning.c is build: * pinning/internals/header.m4 * pinning/controllers/<mcuname>.m4 *: mcuname is defined by the make var MCU * pinning/internals/hackery_<mcuname>.m4 * pinning/hardware/<boardname>.m4 *: <boardname> is definned by make var HARDWARE * pinning/internals/footer.m4 * autoconfig.h *: is converted and each define line results into one m4 command line parameter of the form -Dconf_<parname> What you should realize is, the pinning.c file is independent from any module, so the connection of module and pinning must be defined in one of the mentioned files! ==== pinning/internals/header.m4 ==== Is difficult to understand at the first look. Looks like to much module specific stuff (macros) is placed in this file (for convinience I think). So it is hard to identify the multi purpose macros. Perhabs I will find out later, what is important. Here the important one used very often: pin(<module_named_pin>, <processer_named_pin>) With this macros the pin name, with is used in a module is assigned to a pin of the processor or mcu. It is some kind of wiring - here on the level of the software. ==== pinning/controllers/<mcuname>.m4 ==== Here connections of special functions like SPI or I2C are connected to ports, because this ports are often fixed and cannot be switched to another port. Furtheron some mcu features are defined like number ADC_CHANNELS and other defines for special characteristics of the mcu, which need extra handling. ==== pinning/internals/hackery_<mcuname>.m4 ==== ???? ==== pinning/hardware/<boardname>.m4 ==== Here you find the connections between processor an onboard hardware like the network module. Also you find pin configuration of modules that need connected hardware, i.e. the DCF77 module. So you see, this is the place, where all connections to external devices are defined. I think, when connect your own hardware or want to use other ports as defined here, make a copy of the default m4 file and work with your version of the board file. [[Category:Development]] b1b2f895013ad34c62d206a7e0bd98c11e1662b1 641 640 2012-05-18T19:43:03Z Tkaltenbrunner 475 /* pinning/hardware/.m4 */ wikitext text/x-wiki {{i18n|Configuration of Boards and Pins}} == Intro == This page will explain some of the details behind menuconfig. It is meant for developers who want to look behind the curtain or if someone wants to debug a modul which does not work or compile any more .... == make menuconfig == Integration of modules into menuconfig is described on this page [[Own module#Menuconfig]] - here a look at the results and the output of menuconfig. The configuration is saved in two different formats: * file .config for the menuconfig itself - ** it is used for including it into the makefile ** it influences also the build process of the binary file ** definition auf makefile variables * file autoconfig.h - ** it is for including it in the compilation ** definition of C preprocessor macros and defines I thing the details of the configuration should become clear after doing the menuconfig and reading about the modules. May be I can explain some "core" configuration later. == make == The first steps in the build process are to get all the configuration information and build some source files which put it all together. Besides some usual unix tools like sed the m4 macro processor plays an important role. Even if it is not in the scope of this wiki, I added a very short intro here: [[m4 - very short intro]] === meta.m4 === If you have a look at the different source codes of the modules, you find at the bottom of the main c-file a comment section starting with "-- Ethersex META --". You find there m4 macros which are used to integrate the modul into the main program of ethersex. Details here: [[Concept of meta]]. meta.m4 is the extraction and collection of these sections. The files which are used, are defined by the makefile of each "module". Each C source files has to be added to the make var "y_SRC". A nice trick is used there by the use of ".config", where all the used and configured feature are assigned a "y" to make vars. i.e. MODULX_GENERAL_SUPPORT=y Then in the makefile of ModuleX: $(MODULX_GENERAL_SUPPORT)_SRC += file1.c file2.c ... If the module is not activated the files added to _SRC instead of y_SRC. === meta.c === Is generated by m4 macros. The inputs are: (controlled centrally in the Makefile!) * autoconfig.h *: is converted and each define line results into one m4 command line parameter of the form -Dconf_<parname> * scripts/meta_magic.m4 *: contains the framework for meta.c * protocols/ecmd/ecmd_magic.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * protocols/soap/soap_magic.m4 *: only if SOAP support is activated - make var $(SOAP_SUPPORT) must be set to "y" * meta.m4 *: see above * protocols/ecmd/ecmd_defs.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced by the make var ${named_pin_simple_files} *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced by the make var $(y_NP_SIMPLE_META_SRC) *: unconditional ... but contain the following files, if ECMD parser or SOAP support is activated: ** protocols/ecmd/ecmd_defs.m4 ** ${named_pin_simple_files} *: so I think it could be a small bug - if ECMD parser support is on, the files are added twice - may be this does not matter. ==== What is in ${named_pin_simple_files}? ==== That should be a chapter for itself - containing how the internals of defining pins works. In the default case that are probably the following files: * core/portio/np_simple.m4 * protocols/ecmd/np_simple_glue.m4 === meta.h === is also generated from m4 macros. Files used: * scripts/meta_header_magic.m4 *: framework of meta.h and macros. * meta.m4 meta.m4 is part of meta.c and meta.h - how is it possible, may someone ask. The answer: macros, which are not defined, eval to empty string. So it depends on the defined macros to what meta.m4 is expanded. More about the interesting [[concept of meta]]. === pinning.c === The detailied concept of pinning will be descriped in a chapter by its own. At the moment is important to know that each processor has several ports which can have different functions and are connected sometimes to devices on the board already. If you connect your own hardware to the board which should be supported by an ethersex module you must configure the port(s) which connects the hardware with the processor. Files from which pinning.c is build: * pinning/internals/header.m4 * pinning/controllers/<mcuname>.m4 *: mcuname is defined by the make var MCU * pinning/internals/hackery_<mcuname>.m4 * pinning/hardware/<boardname>.m4 *: <boardname> is definned by make var HARDWARE * pinning/internals/footer.m4 * autoconfig.h *: is converted and each define line results into one m4 command line parameter of the form -Dconf_<parname> What you should realize is, the pinning.c file is independent from any module, so the connection of module and pinning must be defined in one of the mentioned files! ==== pinning/internals/header.m4 ==== Is difficult to understand at the first look. Looks like to much module specific stuff (macros) is placed in this file (for convinience I think). So it is hard to identify the multi purpose macros. Perhabs I will find out later, what is important. Here the important one used very often: pin(<module_named_pin>, <processer_named_pin>) With this macros the pin name, with is used in a module is assigned to a pin of the processor or mcu. It is some kind of wiring - here on the level of the software. ==== pinning/controllers/<mcuname>.m4 ==== Here connections of special functions like SPI or I2C are connected to ports, because this ports are often fixed and cannot be switched to another port. Furtheron some mcu features are defined like number ADC_CHANNELS and other defines for special characteristics of the mcu, which need extra handling. ==== pinning/internals/hackery_<mcuname>.m4 ==== ???? ==== pinning/hardware/<boardname>.m4 ==== Here you find the connections between processor an onboard hardware like the network module. Also you find pin configuration of modules that need connected hardware, i.e. the DCF77 module. So you see, this is the place, where all connections to external devices are defined. I think, when connect your own hardware or want to use other ports as defined here, make a copy of the default m4 file and work with your version of the board file. ==== pinning/internals/footer.m4 ==== Just some final defines ... needed some where. === processor named pins === If you read carefully you have notices 2 place holder in the pin macro. If you want to know what processor named pin stands for, you have go into the details of avr-libc. Because the processor named pins are defined there already. Also the lib contains the details of how to adress these PINs. The naming schema is like this: PA0 - pin 0 at port A PA1 - pin 1 at port A ... PA7 - pin 7 at port A PB0 - pin 0 at port B ... PC0 - pin 0 at port C ... Besides these neutral names some pins have also predefined functions like SPI. This pins have sometimes also a secondary names. [[Category:Development]] 9361491b61b5ada05da7604796144dac441d7d07 642 641 2012-05-18T19:45:21Z Tkaltenbrunner 475 /* processor named pins */ wikitext text/x-wiki {{i18n|Configuration of Boards and Pins}} == Intro == This page will explain some of the details behind menuconfig. It is meant for developers who want to look behind the curtain or if someone wants to debug a modul which does not work or compile any more .... == make menuconfig == Integration of modules into menuconfig is described on this page [[Own module#Menuconfig]] - here a look at the results and the output of menuconfig. The configuration is saved in two different formats: * file .config for the menuconfig itself - ** it is used for including it into the makefile ** it influences also the build process of the binary file ** definition auf makefile variables * file autoconfig.h - ** it is for including it in the compilation ** definition of C preprocessor macros and defines I thing the details of the configuration should become clear after doing the menuconfig and reading about the modules. May be I can explain some "core" configuration later. == make == The first steps in the build process are to get all the configuration information and build some source files which put it all together. Besides some usual unix tools like sed the m4 macro processor plays an important role. Even if it is not in the scope of this wiki, I added a very short intro here: [[m4 - very short intro]] === meta.m4 === If you have a look at the different source codes of the modules, you find at the bottom of the main c-file a comment section starting with "-- Ethersex META --". You find there m4 macros which are used to integrate the modul into the main program of ethersex. Details here: [[Concept of meta]]. meta.m4 is the extraction and collection of these sections. The files which are used, are defined by the makefile of each "module". Each C source files has to be added to the make var "y_SRC". A nice trick is used there by the use of ".config", where all the used and configured feature are assigned a "y" to make vars. i.e. MODULX_GENERAL_SUPPORT=y Then in the makefile of ModuleX: $(MODULX_GENERAL_SUPPORT)_SRC += file1.c file2.c ... If the module is not activated the files added to _SRC instead of y_SRC. === meta.c === Is generated by m4 macros. The inputs are: (controlled centrally in the Makefile!) * autoconfig.h *: is converted and each define line results into one m4 command line parameter of the form -Dconf_<parname> * scripts/meta_magic.m4 *: contains the framework for meta.c * protocols/ecmd/ecmd_magic.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * protocols/soap/soap_magic.m4 *: only if SOAP support is activated - make var $(SOAP_SUPPORT) must be set to "y" * meta.m4 *: see above * protocols/ecmd/ecmd_defs.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced by the make var ${named_pin_simple_files} *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced by the make var $(y_NP_SIMPLE_META_SRC) *: unconditional ... but contain the following files, if ECMD parser or SOAP support is activated: ** protocols/ecmd/ecmd_defs.m4 ** ${named_pin_simple_files} *: so I think it could be a small bug - if ECMD parser support is on, the files are added twice - may be this does not matter. ==== What is in ${named_pin_simple_files}? ==== That should be a chapter for itself - containing how the internals of defining pins works. In the default case that are probably the following files: * core/portio/np_simple.m4 * protocols/ecmd/np_simple_glue.m4 === meta.h === is also generated from m4 macros. Files used: * scripts/meta_header_magic.m4 *: framework of meta.h and macros. * meta.m4 meta.m4 is part of meta.c and meta.h - how is it possible, may someone ask. The answer: macros, which are not defined, eval to empty string. So it depends on the defined macros to what meta.m4 is expanded. More about the interesting [[concept of meta]]. === pinning.c === The detailied concept of pinning will be descriped in a chapter by its own. At the moment is important to know that each processor has several ports which can have different functions and are connected sometimes to devices on the board already. If you connect your own hardware to the board which should be supported by an ethersex module you must configure the port(s) which connects the hardware with the processor. Files from which pinning.c is build: * pinning/internals/header.m4 * pinning/controllers/<mcuname>.m4 *: mcuname is defined by the make var MCU * pinning/internals/hackery_<mcuname>.m4 * pinning/hardware/<boardname>.m4 *: <boardname> is definned by make var HARDWARE * pinning/internals/footer.m4 * autoconfig.h *: is converted and each define line results into one m4 command line parameter of the form -Dconf_<parname> What you should realize is, the pinning.c file is independent from any module, so the connection of module and pinning must be defined in one of the mentioned files! ==== pinning/internals/header.m4 ==== Is difficult to understand at the first look. Looks like to much module specific stuff (macros) is placed in this file (for convinience I think). So it is hard to identify the multi purpose macros. Perhabs I will find out later, what is important. Here the important one used very often: pin(<module_named_pin>, <processer_named_pin>) With this macros the pin name, with is used in a module is assigned to a pin of the processor or mcu. It is some kind of wiring - here on the level of the software. ==== pinning/controllers/<mcuname>.m4 ==== Here connections of special functions like SPI or I2C are connected to ports, because this ports are often fixed and cannot be switched to another port. Furtheron some mcu features are defined like number ADC_CHANNELS and other defines for special characteristics of the mcu, which need extra handling. ==== pinning/internals/hackery_<mcuname>.m4 ==== ???? ==== pinning/hardware/<boardname>.m4 ==== Here you find the connections between processor an onboard hardware like the network module. Also you find pin configuration of modules that need connected hardware, i.e. the DCF77 module. So you see, this is the place, where all connections to external devices are defined. I think, when connect your own hardware or want to use other ports as defined here, make a copy of the default m4 file and work with your version of the board file. ==== pinning/internals/footer.m4 ==== Just some final defines ... needed some where. === processor named pins === If you read carefully you have notices 2 place holder in the pin macro. If you want to know what processor named pin stands for, you have go into the details of avr-libc. Because the processor named pins are defined there already. Also the lib contains the details of how to adress these PINs. The naming schema is like this: PA0 - pin 0 at port A PA1 - pin 1 at port A ... PA7 - pin 7 at port A PB0 - pin 0 at port B ... PC0 - pin 0 at port C ... Besides these neutral names some pins have also predefined functions like SPI. This pins have sometimes a secondary name. [[Category:Development]] bdefcf5233d5fc62dbf13bd23a60c79b584f6e1a 643 642 2012-05-18T19:53:27Z Tkaltenbrunner 475 /* pinning/hardware/.m4 */ wikitext text/x-wiki {{i18n|Configuration of Boards and Pins}} == Intro == This page will explain some of the details behind menuconfig. It is meant for developers who want to look behind the curtain or if someone wants to debug a modul which does not work or compile any more .... == make menuconfig == Integration of modules into menuconfig is described on this page [[Own module#Menuconfig]] - here a look at the results and the output of menuconfig. The configuration is saved in two different formats: * file .config for the menuconfig itself - ** it is used for including it into the makefile ** it influences also the build process of the binary file ** definition auf makefile variables * file autoconfig.h - ** it is for including it in the compilation ** definition of C preprocessor macros and defines I thing the details of the configuration should become clear after doing the menuconfig and reading about the modules. May be I can explain some "core" configuration later. == make == The first steps in the build process are to get all the configuration information and build some source files which put it all together. Besides some usual unix tools like sed the m4 macro processor plays an important role. Even if it is not in the scope of this wiki, I added a very short intro here: [[m4 - very short intro]] === meta.m4 === If you have a look at the different source codes of the modules, you find at the bottom of the main c-file a comment section starting with "-- Ethersex META --". You find there m4 macros which are used to integrate the modul into the main program of ethersex. Details here: [[Concept of meta]]. meta.m4 is the extraction and collection of these sections. The files which are used, are defined by the makefile of each "module". Each C source files has to be added to the make var "y_SRC". A nice trick is used there by the use of ".config", where all the used and configured feature are assigned a "y" to make vars. i.e. MODULX_GENERAL_SUPPORT=y Then in the makefile of ModuleX: $(MODULX_GENERAL_SUPPORT)_SRC += file1.c file2.c ... If the module is not activated the files added to _SRC instead of y_SRC. === meta.c === Is generated by m4 macros. The inputs are: (controlled centrally in the Makefile!) * autoconfig.h *: is converted and each define line results into one m4 command line parameter of the form -Dconf_<parname> * scripts/meta_magic.m4 *: contains the framework for meta.c * protocols/ecmd/ecmd_magic.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * protocols/soap/soap_magic.m4 *: only if SOAP support is activated - make var $(SOAP_SUPPORT) must be set to "y" * meta.m4 *: see above * protocols/ecmd/ecmd_defs.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced by the make var ${named_pin_simple_files} *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced by the make var $(y_NP_SIMPLE_META_SRC) *: unconditional ... but contain the following files, if ECMD parser or SOAP support is activated: ** protocols/ecmd/ecmd_defs.m4 ** ${named_pin_simple_files} *: so I think it could be a small bug - if ECMD parser support is on, the files are added twice - may be this does not matter. ==== What is in ${named_pin_simple_files}? ==== That should be a chapter for itself - containing how the internals of defining pins works. In the default case that are probably the following files: * core/portio/np_simple.m4 * protocols/ecmd/np_simple_glue.m4 === meta.h === is also generated from m4 macros. Files used: * scripts/meta_header_magic.m4 *: framework of meta.h and macros. * meta.m4 meta.m4 is part of meta.c and meta.h - how is it possible, may someone ask. The answer: macros, which are not defined, eval to empty string. So it depends on the defined macros to what meta.m4 is expanded. More about the interesting [[concept of meta]]. === pinning.c === The detailied concept of pinning will be descriped in a chapter by its own. At the moment is important to know that each processor has several ports which can have different functions and are connected sometimes to devices on the board already. If you connect your own hardware to the board which should be supported by an ethersex module you must configure the port(s) which connects the hardware with the processor. Files from which pinning.c is build: * pinning/internals/header.m4 * pinning/controllers/<mcuname>.m4 *: mcuname is defined by the make var MCU * pinning/internals/hackery_<mcuname>.m4 * pinning/hardware/<boardname>.m4 *: <boardname> is definned by make var HARDWARE * pinning/internals/footer.m4 * autoconfig.h *: is converted and each define line results into one m4 command line parameter of the form -Dconf_<parname> What you should realize is, the pinning.c file is independent from any module, so the connection of module and pinning must be defined in one of the mentioned files! ==== pinning/internals/header.m4 ==== Is difficult to understand at the first look. Looks like to much module specific stuff (macros) is placed in this file (for convinience I think). So it is hard to identify the multi purpose macros. Perhabs I will find out later, what is important. Here the important one used very often: pin(<module_named_pin>, <processer_named_pin>) With this macros the pin name, with is used in a module is assigned to a pin of the processor or mcu. It is some kind of wiring - here on the level of the software. ==== pinning/controllers/<mcuname>.m4 ==== Here connections of special functions like SPI or I2C are connected to ports, because this ports are often fixed and cannot be switched to another port. Furtheron some mcu features are defined like number ADC_CHANNELS and other defines for special characteristics of the mcu, which need extra handling. ==== pinning/internals/hackery_<mcuname>.m4 ==== ???? ==== pinning/hardware/<boardname>.m4 ==== Here you find the connections between processor an onboard hardware like the network module. Also you find pin configuration of modules that need connected hardware, i.e. the DCF77 module. So you see, this is the place, where all connections to external devices are defined. I think, when connect your own hardware or want to use other ports as defined here, make a copy of the default m4 file and work with your version of the board file. You can choose the new board when you call '''make menuconfig''' in the General Setup - Hardware/Periphery Class. ==== pinning/internals/footer.m4 ==== Just some final defines ... needed some where. === processor named pins === If you read carefully you have notices 2 place holder in the pin macro. If you want to know what processor named pin stands for, you have go into the details of avr-libc. Because the processor named pins are defined there already. Also the lib contains the details of how to adress these PINs. The naming schema is like this: PA0 - pin 0 at port A PA1 - pin 1 at port A ... PA7 - pin 7 at port A PB0 - pin 0 at port B ... PC0 - pin 0 at port C ... Besides these neutral names some pins have also predefined functions like SPI. This pins have sometimes a secondary name. [[Category:Development]] 9b658fca8ad54a8b57501ca6e0e8147b1879f65a 646 643 2012-05-20T14:43:22Z Tkaltenbrunner 475 /* pinning/internals/header.m4 */ wikitext text/x-wiki {{i18n|Configuration of Boards and Pins}} == Intro == This page will explain some of the details behind menuconfig. It is meant for developers who want to look behind the curtain or if someone wants to debug a modul which does not work or compile any more .... == make menuconfig == Integration of modules into menuconfig is described on this page [[Own module#Menuconfig]] - here a look at the results and the output of menuconfig. The configuration is saved in two different formats: * file .config for the menuconfig itself - ** it is used for including it into the makefile ** it influences also the build process of the binary file ** definition auf makefile variables * file autoconfig.h - ** it is for including it in the compilation ** definition of C preprocessor macros and defines I thing the details of the configuration should become clear after doing the menuconfig and reading about the modules. May be I can explain some "core" configuration later. == make == The first steps in the build process are to get all the configuration information and build some source files which put it all together. Besides some usual unix tools like sed the m4 macro processor plays an important role. Even if it is not in the scope of this wiki, I added a very short intro here: [[m4 - very short intro]] === meta.m4 === If you have a look at the different source codes of the modules, you find at the bottom of the main c-file a comment section starting with "-- Ethersex META --". You find there m4 macros which are used to integrate the modul into the main program of ethersex. Details here: [[Concept of meta]]. meta.m4 is the extraction and collection of these sections. The files which are used, are defined by the makefile of each "module". Each C source files has to be added to the make var "y_SRC". A nice trick is used there by the use of ".config", where all the used and configured feature are assigned a "y" to make vars. i.e. MODULX_GENERAL_SUPPORT=y Then in the makefile of ModuleX: $(MODULX_GENERAL_SUPPORT)_SRC += file1.c file2.c ... If the module is not activated the files added to _SRC instead of y_SRC. === meta.c === Is generated by m4 macros. The inputs are: (controlled centrally in the Makefile!) * autoconfig.h *: is converted and each define line results into one m4 command line parameter of the form -Dconf_<parname> * scripts/meta_magic.m4 *: contains the framework for meta.c * protocols/ecmd/ecmd_magic.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * protocols/soap/soap_magic.m4 *: only if SOAP support is activated - make var $(SOAP_SUPPORT) must be set to "y" * meta.m4 *: see above * protocols/ecmd/ecmd_defs.m4 *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced by the make var ${named_pin_simple_files} *: only if ECMD parser support is activated - make var $(ECMD_PARSER_SUPPORT) must be set to "y" * files referenced by the make var $(y_NP_SIMPLE_META_SRC) *: unconditional ... but contain the following files, if ECMD parser or SOAP support is activated: ** protocols/ecmd/ecmd_defs.m4 ** ${named_pin_simple_files} *: so I think it could be a small bug - if ECMD parser support is on, the files are added twice - may be this does not matter. ==== What is in ${named_pin_simple_files}? ==== That should be a chapter for itself - containing how the internals of defining pins works. In the default case that are probably the following files: * core/portio/np_simple.m4 * protocols/ecmd/np_simple_glue.m4 === meta.h === is also generated from m4 macros. Files used: * scripts/meta_header_magic.m4 *: framework of meta.h and macros. * meta.m4 meta.m4 is part of meta.c and meta.h - how is it possible, may someone ask. The answer: macros, which are not defined, eval to empty string. So it depends on the defined macros to what meta.m4 is expanded. More about the interesting [[concept of meta]]. === pinning.c === The detailied concept of pinning will be descriped in a chapter by its own. At the moment is important to know that each processor has several ports which can have different functions and are connected sometimes to devices on the board already. If you connect your own hardware to the board which should be supported by an ethersex module you must configure the port(s) which connects the hardware with the processor. Files from which pinning.c is build: * pinning/internals/header.m4 * pinning/controllers/<mcuname>.m4 *: mcuname is defined by the make var MCU * pinning/internals/hackery_<mcuname>.m4 * pinning/hardware/<boardname>.m4 *: <boardname> is definned by make var HARDWARE * pinning/internals/footer.m4 * autoconfig.h *: is converted and each define line results into one m4 command line parameter of the form -Dconf_<parname> What you should realize is, the pinning.c file is independent from any module, so the connection of module and pinning must be defined in one of the mentioned files! ==== pinning/internals/header.m4 ==== Is difficult to understand at the first look. Looks like to much module specific stuff (macros) is placed in this file (for convinience I think). So it is hard to identify the multi purpose macros. Perhabs I will find out later, what is important. Here the important one used very often: pin(<module_named_pin>, <processer_named_pin>[, OUTPUT]) With this macros the pin name, with is used in a module is assigned to a pin of the processor or mcu. It is some kind of wiring - here on the level of the software. With the optionnal parameter OUTPUT you define the direction of the connection: from mcu to the addon modul. Otherwise it is the oposite direction. ==== pinning/controllers/<mcuname>.m4 ==== Here connections of special functions like SPI or I2C are connected to ports, because this ports are often fixed and cannot be switched to another port. Furtheron some mcu features are defined like number ADC_CHANNELS and other defines for special characteristics of the mcu, which need extra handling. ==== pinning/internals/hackery_<mcuname>.m4 ==== ???? ==== pinning/hardware/<boardname>.m4 ==== Here you find the connections between processor an onboard hardware like the network module. Also you find pin configuration of modules that need connected hardware, i.e. the DCF77 module. So you see, this is the place, where all connections to external devices are defined. I think, when connect your own hardware or want to use other ports as defined here, make a copy of the default m4 file and work with your version of the board file. You can choose the new board when you call '''make menuconfig''' in the General Setup - Hardware/Periphery Class. ==== pinning/internals/footer.m4 ==== Just some final defines ... needed some where. === processor named pins === If you read carefully you have notices 2 place holder in the pin macro. If you want to know what processor named pin stands for, you have go into the details of avr-libc. Because the processor named pins are defined there already. Also the lib contains the details of how to adress these PINs. The naming schema is like this: PA0 - pin 0 at port A PA1 - pin 1 at port A ... PA7 - pin 7 at port A PB0 - pin 0 at port B ... PC0 - pin 0 at port C ... Besides these neutral names some pins have also predefined functions like SPI. This pins have sometimes a secondary name. [[Category:Development]] 4838ccf9cd5f463ba65f34482dc681a580de5aa3 0 248 647 2012-05-20T15:21:06Z Tkaltenbrunner 475 Created page with "{{i18n|PWM Generator}} {{Module |NAME=PWM |MENUCONFIG={{I/O}}->PWM Generator |STATUS={{unknown}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{???}} |DEPENDS=[[ECMD]] |REQUIRES= - …" wikitext text/x-wiki {{i18n|PWM Generator}} {{Module |NAME=PWM |MENUCONFIG={{I/O}}->PWM Generator |STATUS={{unknown}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{???}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/pwm https://github.com/ethersex/ethersex/tree/master/hardware/pwm] }} Pulse wide modulator generator with upto 3 channels. == Anschluss == c2d01723e6518f17b71b24db294ea9f7f343b926 648 647 2012-05-20T15:28:03Z Tkaltenbrunner 475 wikitext text/x-wiki {{i18n|PWM Generator}} {{Module |NAME=PWM Generator |MENUCONFIG={{I/O}}->PWM Generator |STATUS={Unstable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6= |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/pwm https://github.com/ethersex/ethersex/tree/master/hardware/pwm] }} Pulse wide modulator generator with up to 3 channels. == Connection == 24faf57b164b9bb7aa52b0957a608cd3b226b609 649 648 2012-05-20T15:29:15Z Tkaltenbrunner 475 wikitext text/x-wiki {{i18n|PWM Generator}} {{Module |NAME=PWM Generator |MENUCONFIG={{I/O}}->PWM Generator |STATUS={{Unstable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6= |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/pwm https://github.com/ethersex/ethersex/tree/master/hardware/pwm] }} Pulse wide modulator generator with up to 3 channels. == Connection == c0b21053ee08545b2353e952abdd387cd588782b 650 649 2012-05-20T15:40:35Z Tkaltenbrunner 475 /* Connection */ wikitext text/x-wiki {{i18n|PWM Generator}} {{Module |NAME=PWM Generator |MENUCONFIG={{I/O}}->PWM Generator |STATUS={{Unstable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6= |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/pwm https://github.com/ethersex/ethersex/tree/master/hardware/pwm] }} Pulse wide modulator generator with up to 3 channels. == Connection == Every channels needs a port. At the moment none of the standard boards has a pin configuration already implemented. It would not make much sense, because you would have to adapt it anyway. So here a example you can modify and copy to the configuration of the board used: ifdef(`conf_PWM', `dnl #ifdef CH_A_PWM_GENERAL_SUPPORT pin(CHANNEL_A_PWM, PC0) #endif /* CH_A_PWM_GENERAL_SUPPORT */ #ifdef CH_B_PWM_GENERAL_SUPPORT pin(CHANNEL_B_PWM, PC1) #endif /* CH_B_PWM_GENERAL_SUPPORT */ #ifdef CH_C_PWM_GENERAL_SUPPORT pin(CHANNEL_C_PWM, PC2) #endif /* CH_C_PWM_GENERAL_SUPPORT */ ') 6fce862a3608847c5e157032b77c21b5e3165d8c 651 650 2012-05-20T17:59:43Z Tkaltenbrunner 475 wikitext text/x-wiki {{i18n|PWM Generator}} {{Module |NAME=PWM Generator |MENUCONFIG={{I/O}}->PWM Generator |STATUS={{Unstable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6= |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/pwm https://github.com/ethersex/ethersex/tree/master/hardware/pwm] }} Pulse wide modulator generator with up to 3 channels. == Connection == Every channels needs a port. At the moment none of the standard boards has a pin configuration already implemented. It would not make much sense, because you would have to adapt it anyway. So here a example you can modify and copy to the configuration of the board used: ifdef(`conf_PWM', `dnl #ifdef CH_A_PWM_GENERAL_SUPPORT pin(CHANNEL_A_PWM, PC0, OUTPUT) #endif /* CH_A_PWM_GENERAL_SUPPORT */ #ifdef CH_B_PWM_GENERAL_SUPPORT pin(CHANNEL_B_PWM, PC1, OUTPUT) #endif /* CH_B_PWM_GENERAL_SUPPORT */ #ifdef CH_C_PWM_GENERAL_SUPPORT pin(CHANNEL_C_PWM, PC2, OUTPUT) #endif /* CH_C_PWM_GENERAL_SUPPORT */ ') d620326860176208856556fe938cbfa30fe88c8f 652 651 2012-05-20T18:04:50Z Tkaltenbrunner 475 /* Connection */ wikitext text/x-wiki {{i18n|PWM Generator}} {{Module |NAME=PWM Generator |MENUCONFIG={{I/O}}->PWM Generator |STATUS={{Unstable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6= |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/pwm https://github.com/ethersex/ethersex/tree/master/hardware/pwm] }} Pulse wide modulator generator with up to 3 channels. == Connection == Every channels requieres a port. At the moment none of the standard boards has a pin configuration already implemented. It would not make much sense, because you would have to adapt it anyway. So here a example you can modify and copy to the configuration of the board used: ifdef(`conf_PWM', `dnl #ifdef CH_A_PWM_GENERAL_SUPPORT pin(CHANNEL_A_PWM, PC0, OUTPUT) #endif /* CH_A_PWM_GENERAL_SUPPORT */ #ifdef CH_B_PWM_GENERAL_SUPPORT pin(CHANNEL_B_PWM, PC1, OUTPUT) #endif /* CH_B_PWM_GENERAL_SUPPORT */ #ifdef CH_C_PWM_GENERAL_SUPPORT pin(CHANNEL_C_PWM, PC2, OUTPUT) #endif /* CH_C_PWM_GENERAL_SUPPORT */ ') You can also use the script add-hardware (in folder scripts) to generate a board-layout for your current configuration. I don't know the current status of the script - so it is possible, that not every features is supported. dc44643f959e74b6cdc1cfc2ff9f7bf4768bafc1 655 652 2012-05-22T18:07:37Z Tkaltenbrunner 475 wikitext text/x-wiki {{i18n|PWM Generator}} {{Module |NAME=PWM Generator |MENUCONFIG={{I/O}}->PWM Generator |STATUS={{Unstable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6= |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/pwm https://github.com/ethersex/ethersex/tree/master/hardware/pwm] }} Pulse wide modulator generator with up to 3 channels. This module uses the avr timers to generate the pwm signals, so for every channel a timer is necessary. It depends on the hardware and other modules, if thre timers are available for the the three channels. To get background infos you can have a look at this tutorial (in german): [[http://www.mikrocontroller.net/articles/AVR-Tutorial:_PWM AVR-Tutorial: PWM]] == Connection == Every channels requieres a port. At the moment none of the standard boards has a pin configuration already implemented. It would not make much sense, because you would have to adapt it anyway. So here a example you can modify and copy to the configuration of the board used: ifdef(`conf_PWM', `dnl #ifdef CH_A_PWM_GENERAL_SUPPORT pin(CHANNEL_A_PWM, PC0, OUTPUT) #endif /* CH_A_PWM_GENERAL_SUPPORT */ #ifdef CH_B_PWM_GENERAL_SUPPORT pin(CHANNEL_B_PWM, PC1, OUTPUT) #endif /* CH_B_PWM_GENERAL_SUPPORT */ #ifdef CH_C_PWM_GENERAL_SUPPORT pin(CHANNEL_C_PWM, PC2, OUTPUT) #endif /* CH_C_PWM_GENERAL_SUPPORT */ ') You can also use the script add-hardware (in folder scripts) to generate a board-layout for your current configuration. I don't know the current status of the script - so it is possible, that not every features is supported. f645b0b5b2cfab7a5d7f5d53277f9ed1028e823e 656 655 2012-05-22T18:16:56Z Tkaltenbrunner 475 /* Connection */ wikitext text/x-wiki {{i18n|PWM Generator}} {{Module |NAME=PWM Generator |MENUCONFIG={{I/O}}->PWM Generator |STATUS={{Unstable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6= |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/pwm https://github.com/ethersex/ethersex/tree/master/hardware/pwm] }} Pulse wide modulator generator with up to 3 channels. This module uses the avr timers to generate the pwm signals, so for every channel a timer is necessary. It depends on the hardware and other modules, if thre timers are available for the the three channels. To get background infos you can have a look at this tutorial (in german): [[http://www.mikrocontroller.net/articles/AVR-Tutorial:_PWM AVR-Tutorial: PWM]] == Connection == Every channels requieres a port., but since the timers are used the ports are fix defined by the pins of the microcontroller. Nevertheless you have to do some pin definition. Here the version for the AtMega32: ifdef(`conf_PWM', `dnl #ifdef CH_A_PWM_GENERAL_SUPPORT pin(CHANNEL_A_PWM, PD5, OUTPUT) #endif /* CH_A_PWM_GENERAL_SUPPORT */ #ifdef CH_B_PWM_GENERAL_SUPPORT pin(CHANNEL_B_PWM, PD4, OUTPUT) #endif /* CH_B_PWM_GENERAL_SUPPORT */ #ifdef CH_C_PWM_GENERAL_SUPPORT #error 3 Channel pwm unsupported. #endif /* CH_C_PWM_GENERAL_SUPPORT */ ') You can also use the script add-hardware (in folder scripts) to generate a board-layout for your current configuration. I don't know the current status of the script - so it is possible, that not every features is supported. f5145caa6996d9f0f29eaaff27f52be5e9829aa1 657 656 2012-05-23T08:28:36Z Tkaltenbrunner 475 /* Connection */ wikitext text/x-wiki {{i18n|PWM Generator}} {{Module |NAME=PWM Generator |MENUCONFIG={{I/O}}->PWM Generator |STATUS={{Unstable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6= |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/pwm https://github.com/ethersex/ethersex/tree/master/hardware/pwm] }} Pulse wide modulator generator with up to 3 channels. This module uses the avr timers to generate the pwm signals, so for every channel a timer is necessary. It depends on the hardware and other modules, if thre timers are available for the the three channels. To get background infos you can have a look at this tutorial (in german): [[http://www.mikrocontroller.net/articles/AVR-Tutorial:_PWM AVR-Tutorial: PWM]] == Connection == Every channels requieres a port, but since the timers are used, the ports have a predefined assignment - depending on the mcrocontroller. Nevertheless you have to do some pin definition. Here the version for the AtMega32: ifdef(`conf_PWM', `dnl #ifdef CH_A_PWM_GENERAL_SUPPORT pin(CHANNEL_A_PWM, PD5, OUTPUT) #endif /* CH_A_PWM_GENERAL_SUPPORT */ #ifdef CH_B_PWM_GENERAL_SUPPORT pin(CHANNEL_B_PWM, PD4, OUTPUT) #endif /* CH_B_PWM_GENERAL_SUPPORT */ #ifdef CH_C_PWM_GENERAL_SUPPORT #error 3 Channel pwm unsupported. #endif /* CH_C_PWM_GENERAL_SUPPORT */ ') You can also use the script add-hardware (in folder scripts) to generate a board-layout for your current configuration. I don't know the current status of the script - so it is possible, that not every features is supported. fdbeabfca637da3ca9642a6ce49c6cca5c4112fc 668 657 2012-05-24T21:41:51Z Tkaltenbrunner 475 /* Connection */ wikitext text/x-wiki {{i18n|PWM Generator}} {{Module |NAME=PWM Generator |MENUCONFIG={{I/O}}->PWM Generator |STATUS={{Unstable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6= |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/pwm https://github.com/ethersex/ethersex/tree/master/hardware/pwm] }} Pulse wide modulator generator with up to 3 channels. This module uses the avr timers to generate the pwm signals, so for every channel a timer is necessary. It depends on the hardware and other modules, if thre timers are available for the the three channels. To get background infos you can have a look at this tutorial (in german): [[http://www.mikrocontroller.net/articles/AVR-Tutorial:_PWM AVR-Tutorial: PWM]] == Connection == Every channels requieres a port, but since the timers are used, the ports have a predefined assignment - depending on the mcrocontroller. Nevertheless you have to do some pin definition. Here the version for the AtMega32: ifdef(`conf_CH_A_PWM_GENERAL', `dnl pin(CHANNEL_A_PWM, PD5, OUTPUT) ') ifdef(`conf_CH_B_PWM_GENERAL', `dnl pin(CHANNEL_B_PWM, PD4, OUTPUT) ') ifdef(`conf_CH_C_PWM_GENERAL', `dnl # error 3 Channel pwm unsupported. ') You can also use the script add-hardware (in folder scripts) to generate a board-layout for your current configuration. I don't know the current status of the script - so it is possible, that not every features is supported. 1a1cb75869b30bfaa3eb39dc210c51849771babc 672 668 2012-05-25T16:57:52Z Tkaltenbrunner 475 wikitext text/x-wiki {{i18n|PWM Generator}} {{Module |NAME=PWM Generator |MENUCONFIG={{I/O}}->PWM Generator |STATUS={{Unstable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6= |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/pwm https://github.com/ethersex/ethersex/tree/master/hardware/pwm] }} Pulse wide modulator generator with up to 3 channels. This module uses the avr timers to generate the pwm signals, so for every channel a timer is necessary. It depends on the hardware and other modules, if three timers are available for the the three channels. To get background infos you can have a look at this tutorial (in german): [[http://www.mikrocontroller.net/articles/AVR-Tutorial:_PWM AVR-Tutorial: PWM]] Status: Basic modul works - tested and used 2012-05-25 == Connection == Every channels requieres a port, but since the timers are used, the ports have a predefined assignment - depending on the mcrocontroller. Nevertheless you have to do some pin definition. Here the version for the AtMega32: ifdef(`conf_CH_A_PWM_GENERAL', `dnl pin(CHANNEL_A_PWM, PD5, OUTPUT) ') ifdef(`conf_CH_B_PWM_GENERAL', `dnl pin(CHANNEL_B_PWM, PD4, OUTPUT) ') ifdef(`conf_CH_C_PWM_GENERAL', `dnl # error 3 Channel pwm unsupported. ') You can also use the script add-hardware (in folder scripts) to generate a board-layout for your current configuration. I don't know the current status of the script - so it is possible, that not every features is supported. == Optional components == === PWM Wave === Output of wave files === PWM Melody === Melody generator === PWM Servo === Control a servo motor bd4762f0b7ecf4466e88615a30095ca683e86843 2 275 684 2012-06-03T09:12:37Z Joe 146 email validation would be nice wikitext text/x-wiki I created the user "Fake" in order to test how hard it is for a spammer to create new accounts. I think email verification for new users should reduce spam significantly. Only Captchas is apparently not enough. It would be nice if somebody with wiki/root rights enables email validation for this mediawiki. the config required should look like this: <pre> $wgEnableEmail = true; // enable basic e-mail features $wgEmailAuthentication = true; // require email authentication for using any email function (except password reminder which works independently from this setting) $wgEmailConfirmToEdit = true; // requireas a confirmed address for editing $wgGroupPermissions ['*']['edit'] = false; $wgGroupPermissions ['emailconfirmed']['edit'] = true; $wgGroupPermissions ['sysop']['edit'] = true; $wgGroupPermissions['user']['edit'] = false; $wgGroupPermissions ['*']['createpage'] = false; $wgGroupPermissions['user']['createpage'] = false; $wgGroupPermissions ['emailconfirmed']['createpage'] = true; $wgGroupPermissions ['sysop']['createpage'] = true; </pre> 2d6c637684e65f249a1665222088c9a99bc076bb 3 221 685 585 2012-06-03T09:16:38Z Joe 146 im blushing :-) wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 276 686 2012-06-04T15:20:18Z Thrawnhex 540 transfered Page from old wiki wikitext text/x-wiki == Webserver auf dem ethersex == Der Webserver der in ethersex eingebaut ist kann von verschiedenen Orten die Daten lesen, die er ausliefern soll: * Aus einem externen Dataflash * Dateien die im Flash des Controllers nach der Firmware abgelegt sind * ECMD Befehle absetzen und die Resultate erhalten ( fuer Ajax ) Jede dieser Quellen fuer Daten kann unabhaenig von den anderen eingeschaltet werden. Die einfachste Variante ist wohl zu Beginn die Dateien im internen Flash zu halten und dynamische Inhalte ueber das Http ECMD Interface abzurufen. === Konfiguration === <pre> General Setup ---&gt; [*] VFS (Virtual File System) support ---&gt; | | [ ] Atmel SPI Dataflash | | | [*] VFS File Inlining | | | [ ] SD/MMC-Card Access | | | [ ] EEPROM (24cxx) Raw Access | | | [-] DC3840 Camera | Applications ---&gt; | | [*] HTTP Server | | | [ ] Basic Authentication | Applications ---&gt; Etherrape Control Interface (ECMD) ---&gt; | | [*] ECMD support | </pre> === Dateien einbinden === Falls die Option ''Supply Inline Files'' aktiviert ist, werden alle Dateien, die unter ''vfs/embed/'' abgelegt sind, automatisch beim Erstellen des Images mit gzip gepackt und an das Ende der Firmware angehängt. Die Dateinamen bleiben dabei unverändert, jedoch muss beachtet werden, dass die maximale Länge der Dateinamen 6 Zeichen beträgt. === Dateien mit dem C Preprocessor oder m4 vorverarbeiten === Um Dateien abhängig von den Konfigurationsoptionen einzubinden (oder nicht) bzw. nur Teile mit einzubauen, wenn eine gewisse Option aktiviert ist, kann man diese durch cpp oder m4 vorverarbeiten lassen, bevor die Ausgabe gepackt und an die Firmware angefügt wird. Dazu muss die Datei auf .cpp bzw auf .m4 enden. Bei cpp sind alle defines aus der config.h/autoconf.h erreichbar (z. B. ~np~ONEWIRE_SUPPORT~/np~). Bei m4 wird aus ~np~ONEWIRE_SUPPORT conf_ONEWIRE ~/np~. === Content Type der Dateien === Da der Webserver den Content-Type nicht dynamisch erkennen kann, muss man ihm diese Informationen etwas vorkauen. Der Content-Type wird am ersten Buchstaben des Dateinamens festgemacht: * S (z.B Sty.c): text/css * X (z.B Xow.ht): application/xhtml+xml; * Ansonsten wird alles mit text/html ausgeliefert === Dateien von SD-Card Aufrufen === Damit Datein von einer SD-Card ausgeliefert werden, kopiert man diese einfach auf die SD-Card. Sie können dann im Browser über folgende URL aufgerufen werden.(die IP, der Dateiname müssen natürlich geändert werden) <pre>http://192.168.23.244/Dateiname</pre> Wen die Datei in einem Ordner auf der SD-Card liegt ist kann sie über folgende URL aufgerufen werden.<pre>http://192.168.23.244/Ordnername/Dateiname</pre> Die Länge des Dateinamens ist bei der SD-Card nicht auf 6 Zeichen begrenzt. === ECMD-Befehle per Hand auslösen (über http) === Um die IP per ecmd abzufragen, kann man die folgende URL (die IP muss natürlich geändert werden) im Browser eingeben und man bekommt die Ausgabe per http zurück. <pre>http://192.168.23.244/ecmd?ip</pre> Möchte man Befehle verwenden, welche ein Leerzeichen beinhalten, wie z.B. "1w list", dann muss das Leerzeichen durch ein "+" bzw. "%20" ersetzt werden. Folgender Befehl listet angeschlossene 1-wire Sensoren auf, falls vorhanden. <pre>http://192.168.23.244/ecmd?1w+list</pre> oder <pre>http://192.168.23.244/ecmd?1w%20list</pre> === Startseite von Ethersex === Ist der Webserver einkompiliert sollte beim Aufruf von <nowiki>http://YOUR_ETHERSEX_IP/</nowiki> im Browser so eine Seite erscheinen: [[Bild:Ethersex-screen-startseite.png|600px]] === Dataflash === '''TODO''' [[Category:Ethersex]] [[Category:StepByStep]] [[Category:Network]] a072fe15dc3d74837354c9be26b2c15c5433d13c 687 686 2012-06-04T15:26:33Z Thrawnhex 540 Replaced content with "{{i18n|HTTPD}}" wikitext text/x-wiki {{i18n|HTTPD}} deff8b839c450fe0e7db235b76007dd3c86969d3 0 40 688 595 2012-06-04T15:33:18Z Mgue 312 typo fixes wikitext text/x-wiki {{i18n|Wiki Guidelines}} == Languages == This is in a sense an international wiki. Please include this on top of every page you create: {{Codeline|<nowiki>{{i18n|TITLE}}</nowiki>}} Replace TITLE with the title of the page you are editing. This will insert a language bar like the one you can see above. If you want to translate a page, simply click on the language and start editing. Make sure that you include the language template as well. *Categories are not internationalized == Modules == If you want to document a module, please make use of the [[Template:Module | Module Template]]. A well documented module should look similar to [[IRMP | this ]]. For the title, please use the name of the module in menuconfig or how it is called in the code (e.g. the folder name). Please do not chose a title that doesn't match with either one of these. == More rules == * Refrain from putting all information related to a module into one single page. Create subpages for examples and specific setups. 0cf157e13a97a5282fe26bbc6a2c3f8cc4b8136d 0 277 689 2012-06-04T15:39:27Z Thrawnhex 540 Created page with "{{i18n|HTTPD}} {{Module |NAME=HTTPD |MENUCONFIG={{Applications}}->{{HTTP Server}}->HTTPD |STATUS={{stable}} |PINNING=? |ECMD=? |CONTROL6=? |DEPENDS=? |REQUIRES=? |CODE=? }} == …" wikitext text/x-wiki {{i18n|HTTPD}} {{Module |NAME=HTTPD |MENUCONFIG={{Applications}}->{{HTTP Server}}->HTTPD |STATUS={{stable}} |PINNING=? |ECMD=? |CONTROL6=? |DEPENDS=? |REQUIRES=? |CODE=? }} == Webserver auf dem ethersex == Der Webserver der in ethersex eingebaut ist kann von verschiedenen Orten die Daten lesen, die er ausliefern soll: * Aus einem externen Dataflash * Dateien die im Flash des Controllers nach der Firmware abgelegt sind * ECMD Befehle absetzen und die Resultate erhalten ( fuer Ajax ) Jede dieser Quellen fuer Daten kann unabhaenig von den anderen eingeschaltet werden. Die einfachste Variante ist wohl zu Beginn die Dateien im internen Flash zu halten und dynamische Inhalte ueber das Http ECMD Interface abzurufen. === Konfiguration === General Setup ---&gt; [*] VFS (Virtual File System) support ---&gt; | | [ ] Atmel SPI Dataflash | | | [*] VFS File Inlining | | | [ ] SD/MMC-Card Access | | | [ ] EEPROM (24cxx) Raw Access | | | [-] DC3840 Camera | ... Applications ---&gt; | | [*] HTTP Server | | | [ ] Basic Authentication | ... Applications ---&gt; Etherrape Control Interface (ECMD) ---&gt; | | [*] ECMD support | === Dateien einbinden === Falls die Option ''Supply Inline Files'' aktiviert ist, werden alle Dateien, die unter ''vfs/embed/'' abgelegt sind, automatisch beim Erstellen des Images mit gzip gepackt und an das Ende der Firmware angehängt. Die Dateinamen bleiben dabei unverändert, jedoch muss beachtet werden, dass die maximale Länge der Dateinamen 6 Zeichen beträgt. === Dateien mit dem C Preprocessor oder m4 vorverarbeiten === Um Dateien abhängig von den Konfigurationsoptionen einzubinden (oder nicht) bzw. nur Teile mit einzubauen, wenn eine gewisse Option aktiviert ist, kann man diese durch cpp oder m4 vorverarbeiten lassen, bevor die Ausgabe gepackt und an die Firmware angefügt wird. Dazu muss die Datei auf .cpp bzw auf .m4 enden. Bei cpp sind alle defines aus der config.h/autoconf.h erreichbar (z. B. ~np~ONEWIRE_SUPPORT~/np~). Bei m4 wird aus ~np~ONEWIRE_SUPPORT conf_ONEWIRE ~/np~. === Content Type der Dateien === Da der Webserver den Content-Type nicht dynamisch erkennen kann, muss man ihm diese Informationen etwas vorkauen. Der Content-Type wird am ersten Buchstaben des Dateinamens festgemacht: * S (z.B Sty.c): text/css * X (z.B Xow.ht): application/xhtml+xml; * Ansonsten wird alles mit text/html ausgeliefert === Dateien von SD-Card Aufrufen === Damit Datein von einer SD-Card ausgeliefert werden, kopiert man diese einfach auf die SD-Card. Sie können dann im Browser über folgende URL aufgerufen werden.(die IP, der Dateiname müssen natürlich geändert werden) <pre>http://192.168.23.244/Dateiname</pre> Wen die Datei in einem Ordner auf der SD-Card liegt ist kann sie über folgende URL aufgerufen werden.<pre>http://192.168.23.244/Ordnername/Dateiname</pre> Die Länge des Dateinamens ist bei der SD-Card nicht auf 6 Zeichen begrenzt. === ECMD-Befehle per Hand auslösen (über http) === Um die IP per ecmd abzufragen, kann man die folgende URL (die IP muss natürlich geändert werden) im Browser eingeben und man bekommt die Ausgabe per http zurück. <pre>http://192.168.23.244/ecmd?ip</pre> Möchte man Befehle verwenden, welche ein Leerzeichen beinhalten, wie z.B. "1w list", dann muss das Leerzeichen durch ein "+" bzw. "%20" ersetzt werden. Folgender Befehl listet angeschlossene 1-wire Sensoren auf, falls vorhanden. <pre>http://192.168.23.244/ecmd?1w+list</pre> oder <pre>http://192.168.23.244/ecmd?1w%20list</pre> === Startseite von Ethersex === Ist der Webserver einkompiliert sollte beim Aufruf von <nowiki>http://YOUR_ETHERSEX_IP/</nowiki> im Browser so eine Seite erscheinen: [[Bild:Ethersex-screen-startseite.png|600px]] === Dataflash === '''TODO''' [[Category:Ethersex]] [[Category:StepByStep]] [[Category:Network]] 9cba1e6e042182ab4a1d88e9ea7672ec3fa2ffc7 690 689 2012-06-04T15:41:00Z Thrawnhex 540 wikitext text/x-wiki {{i18n|HTTPD}} {{Module |NAME=HTTPD |MENUCONFIG={{Applications}}->HTTP Server->HTTPD |STATUS={{stable}} |PINNING=? |ECMD=? |CONTROL6=? |DEPENDS=? |REQUIRES=? |CODE=? }} == Webserver auf dem ethersex == Der Webserver der in ethersex eingebaut ist kann von verschiedenen Orten die Daten lesen, die er ausliefern soll: * Aus einem externen Dataflash * Dateien die im Flash des Controllers nach der Firmware abgelegt sind * ECMD Befehle absetzen und die Resultate erhalten ( fuer Ajax ) Jede dieser Quellen fuer Daten kann unabhaenig von den anderen eingeschaltet werden. Die einfachste Variante ist wohl zu Beginn die Dateien im internen Flash zu halten und dynamische Inhalte ueber das Http ECMD Interface abzurufen. === Konfiguration === <pre> General Setup ---&gt; [*] VFS (Virtual File System) support ---&gt; | | [ ] Atmel SPI Dataflash | | | [*] VFS File Inlining | | | [ ] SD/MMC-Card Access | | | [ ] EEPROM (24cxx) Raw Access | | | [-] DC3840 Camera | ... Applications ---&gt; | | [*] HTTP Server | | | [ ] Basic Authentication | ... Applications ---&gt; Etherrape Control Interface (ECMD) ---&gt; | | [*] ECMD support | </pre> === Dateien einbinden === Falls die Option ''Supply Inline Files'' aktiviert ist, werden alle Dateien, die unter ''vfs/embed/'' abgelegt sind, automatisch beim Erstellen des Images mit gzip gepackt und an das Ende der Firmware angehängt. Die Dateinamen bleiben dabei unverändert, jedoch muss beachtet werden, dass die maximale Länge der Dateinamen 6 Zeichen beträgt. === Dateien mit dem C Preprocessor oder m4 vorverarbeiten === Um Dateien abhängig von den Konfigurationsoptionen einzubinden (oder nicht) bzw. nur Teile mit einzubauen, wenn eine gewisse Option aktiviert ist, kann man diese durch cpp oder m4 vorverarbeiten lassen, bevor die Ausgabe gepackt und an die Firmware angefügt wird. Dazu muss die Datei auf .cpp bzw auf .m4 enden. Bei cpp sind alle defines aus der config.h/autoconf.h erreichbar (z. B. ~np~ONEWIRE_SUPPORT~/np~). Bei m4 wird aus ~np~ONEWIRE_SUPPORT conf_ONEWIRE ~/np~. === Content Type der Dateien === Da der Webserver den Content-Type nicht dynamisch erkennen kann, muss man ihm diese Informationen etwas vorkauen. Der Content-Type wird am ersten Buchstaben des Dateinamens festgemacht: * S (z.B Sty.c): text/css * X (z.B Xow.ht): application/xhtml+xml; * Ansonsten wird alles mit text/html ausgeliefert === Dateien von SD-Card Aufrufen === Damit Datein von einer SD-Card ausgeliefert werden, kopiert man diese einfach auf die SD-Card. Sie können dann im Browser über folgende URL aufgerufen werden.(die IP, der Dateiname müssen natürlich geändert werden) <pre>http://192.168.23.244/Dateiname</pre> Wen die Datei in einem Ordner auf der SD-Card liegt ist kann sie über folgende URL aufgerufen werden.<pre>http://192.168.23.244/Ordnername/Dateiname</pre> Die Länge des Dateinamens ist bei der SD-Card nicht auf 6 Zeichen begrenzt. === ECMD-Befehle per Hand auslösen (über http) === Um die IP per ecmd abzufragen, kann man die folgende URL (die IP muss natürlich geändert werden) im Browser eingeben und man bekommt die Ausgabe per http zurück. <pre>http://192.168.23.244/ecmd?ip</pre> Möchte man Befehle verwenden, welche ein Leerzeichen beinhalten, wie z.B. "1w list", dann muss das Leerzeichen durch ein "+" bzw. "%20" ersetzt werden. Folgender Befehl listet angeschlossene 1-wire Sensoren auf, falls vorhanden. <pre>http://192.168.23.244/ecmd?1w+list</pre> oder <pre>http://192.168.23.244/ecmd?1w%20list</pre> === Startseite von Ethersex === Ist der Webserver einkompiliert sollte beim Aufruf von <nowiki>http://YOUR_ETHERSEX_IP/</nowiki> im Browser so eine Seite erscheinen: [[Bild:Ethersex-screen-startseite.png|600px]] === Dataflash === '''TODO''' [[Category:Ethersex]] [[Category:StepByStep]] [[Category:Network]] 7be1db2e066cd0d3c1a7d55c037cef9c95284b63 0 278 691 2012-06-04T17:10:52Z Thrawnhex 540 Created page with "{{i18n|Flashing}} = AVR Net-IO mit dem ATMEL Evaluations-Board von Pollin flashen= Als Einsteiger hat man es immer wieder schwer alle Information zu finden. Ich habe lange gesu…" wikitext text/x-wiki {{i18n|Flashing}} = AVR Net-IO mit dem ATMEL Evaluations-Board von Pollin flashen= Als Einsteiger hat man es immer wieder schwer alle Information zu finden. Ich habe lange gesucht bis ich das mit dem Flashen kapiert habe. == Benötigt wird: == * AVR Net-IO * ATMEL Evaluations-Board * ein 1:1 Kabel für den [[ISP]]-Port (10-poliger Pfostenstecker). === Andere ISP-Programmer === Wer über einen ISP-Programmer mit 6-poligem Ausgang verfügt, kann sich ein Adapterkabel bauen. Zu den Pinbelegungen siehe Figure 4-1 auf Seite 5 von [http://www.atmel.com/dyn/resources/prod_documents/doc2521.pdf AVR042: AVR Hardware Design Considerations]. Achtung, Pin 4 des 10-poligen Steckers ist auf dem AVR Net-IO nicht belegt! GND muss daher an einen der anderen Pins (6, 8 oder 10) angeschlossen werden. == Flashen unter Linux == Das 10-polige Kabel in die ISP-Buchse stecken. Nun das AVR Net-IO Board mit Strom versorgen. Wenn das ISP-Kabel richtig gesteckt ist, leuchtet auf dem Evalutions-Board die (gelbe) LED Nach dem Erzeugen der [[:Kategorie:StepByStep#Firmware_kompilieren|ethersex.hex]] kann man mit avrdude das Ganze flashen. Das nachfolgende Kommando ist bei einigen Parametern vom ISP-Programmer abhängig. Das nachfolgende Beispiel gilt für einen ISP-Programmer der über die serielle Schnittstelle arbeitet: avrdude -v -p m32 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex Für eine USB-ISP-Programmer wäre statt dessen der folgende Befehl zu verwenden: avrdude -v -p m32 -c stk500v2 -P /dev/ttyACM0 -U flash:w:ethersex.hex Für ein paralleles ISP-Kabel: avrdude -p m32 -e -c stk200 -U flash:w:ethersex.hex Nach dem Flashen das ISP-Kabel entfernen und kurz die Stromversorgung unterbrechen um das Board zu rebooten. * -p m32 steht für den ATMega32; -p m644 wäre der ATMega644 * -v erweiterte Ausgaben * -c ponyser ist das Verfahren wie das Evalutions-Board die Daten flasht * -P ist die Serielle Schnittstelle an dem das Evalutions-Board angeschlossen ist (bei USB /dev/ttyUSB0) * -U was man machen möchte. In unserem Fall wollen wir das File ethersex.hex flashen (-U flash:w:ethersex.hex) Es kann sein das man für den ATMega32 die FUSE Bits setzen muss. avrdude -p m32 -c ponyser -P /dev/ttyS0 -U lfuse:w:0xCF:m -U hfuse:w:0xDC:m Um die korrekte Fuse-Einstellung rauszufinden, ist es sinnvoll http://www.engbedded.com/fusecalc/ zu benutzen. Die Parameter für MyAVR mySmartusb light (Insbesondere das -e war nötig): avrdude -p m32 -e -c stk500v2 -P /dev/ttyUSB0 -U flash:w:ethersex.hex == Umbau von einem ATMega32 auf den ATMega644 / ATMega644p == Der Vorteil von ATMega644 und ATMega644p ist vor allem der doppelt so große Speicher gegenüber dem serienmäßigen ATMega32. === Mikrocontroller tauschen === * Stromversorgung abschalten und ISP-Stecker abziehen. * Den ATMega32 aus seinem Sockel auf dem AVR Net-IO ziehen. * Den ATMega644 oder ATMega644p einbauen. (ACHTUNG: Kerbe im Sockel muss mit Kerbe in der CPU übereinstimmen) === Fuse-Bits setzen === * ISP wieder einstecken und Stromversorgung einschalten. * Fuse-Bits setzen * '''Wichtig:''' im Auslieferungszustand ist der ATMega644 programmiert auf 8MHz interner RC-Oszillator '''und''' der Takt wird durch 8 geteilt; also 1MHz Takt. Wenn ein externer Quarz verwendet wir, muss das Bit CKDIV8 (Takt geteilt durch 8) auf null gesetzt werden. * (Übernommen von dinus) Der ATMega wird dabei mit 1Mhz getaktet, kein JTAG. avrdude -p m644 -c ponyser -P /dev/ttyS0 -U lfuse:w:0xE7:m -U hfuse:w:0xDC:m -U efuse:w:0xFF:m * bzw. avrdude -p m644p -c ponyser -P /dev/ttyS0 -U lfuse:w:0xE7:m -U hfuse:w:0xDC:m -U efuse:w:0xFF:m Fuse-Bits wie sie "DiDi" einsetzt. Der JTAG ist eingeschaltet. * -U lfuse:w:0xf7:m -U hfuse:w:0x99:m -U efuse:w:0xfc:m Fuse-Bits wie "loddel" sie einsetzt. Der JTAG ist ausgeschaltet. * -U lfuse:w:0xf7:m -U hfuse:w:0xd9:m -U efuse:w:0xff:m * -U lfuse:w:0xe7:m -U hfuse:w:0xd9:m -U efuse:w:0xff:m Fuse-Bits wie "gregor" sie einsetzt. "Damit läuft der 644 auf 16MHz Quarz und der Takt wird nicht durch 8 geteilt." Der JTAG ist eingeschaltet. * -U lfuse:w:0xef:m -U hfuse:w:0x99:m -U efuse:w:0xff:m === Ethersex reinflashen=== * in der Config von Ethersex (make menuconfig) von ATmega32 auf ATMega644 umstellen * Flashen mit avrdude -p m644 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex -v * bzw. avrdude -p m644p -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex -v === Unterschiede zwischen ATMega32, ATMega644, ATMega644p und ATMega1284p=== {| border=1 cellspacing=0 padding=4 class=wikitable " ! !! ATMega32 !! ATMega644 !! ATMega644p !! ATMega1284p |- | Gehäuse || DIL-40 || DIL-40 || DIL-40 || DIL-40 |- | MHz || max. 16 || max. 20 || max. 20 || max. 20 |- | Flash || 32 KB || 64 KB || 64 KB || 128 KB |- | EEProm || 1 KB || 2 KB || 2 KB || 4 KB |- | RAM || 2 KB || 4 KB || 4 KB || 16 KB |- | I/O || 32 || 32 || 32 || 32 |- | PWM || 4 || 6 || 6 || 6 |- | ext. INT || 3 || 32 || 32 || 32 |- | Ser-Port || 1 || 1 || 2 || 2 |} ====Datenblätter==== * AtMega32 * ATMega644 * ATMega644p * [http://www.atmel.com/dyn/resources/prod_documents/8059S.pdf ATMega1284p] == Flashen unter Windows == Es gibt mindestens zwei Möglichkeiten: #Flashen mit avrdude #Flashen mit AVR Studio Wer keines der beiden Programme auf seine Festplatte legen möchte, weil er sein Windows-System nicht ändern möchte, kann auch die [[Live CD]] verwenden. ===Flashen mit avrdude=== Das Flashen mit avrdude erfolgt prinzipiell genauso wie unter Linux (siehe oben). Ein Windows-Binary von avrdude erhält man am einfachsten als Bestandteil von [http://sourceforge.net/projects/winavr/ WinAVR]. (Ansonsten findet man ein Windows-Binary von avrdude auch auf [http://yuki-lab.jp/hw/avrdude-GUI/index.html dieser japanischen Seite], wo man auch eine GUI für avrdude bekommen kann. Google-Translate hilft den japanischen Text zu verstehen.) In der Kommandozeile muss natürlich die Bezeichnung des seriellen Ports angepasst werden, also "COMx" anstelle von "/dev/ttyS0", z.B. avrdude -v -p m32 -c ponyser -P com3 -U flash:w:ethersex.hex Sofern der Programmer per USB angeschlossen ist, benötigt man * bei echten USB-Programmern die libusb0.dll (bei WinAVR enthalten), * bei Verwendung eines USB-nach-seriell-Adapters mit FTDI-Chip (dieser kann auch manchmal bereits in den Programmer mit USB-Anschluss eingebaut sein!) einen passenden Treiber, siehe http://www.ftdichip.com/Drivers/VCP.htm. ===Flashen mit AVR Studio=== Das [[AVR Studio]] von Atmel bietet eine grafische Oberfläche zur Bedienung von ISPs. Beim AVR Studio werden USB-Treiber für USB-Programmer mitgeliefert, die optional zusammen mit dem AVR Studio installiert werden können. Für USB-nach-seriell-Adapter mit FTDI-Chip benötigt man einen passenden Treiber, siehe http://www.ftdichip.com/Drivers/VCP.htm. === Links zu Erfahrungsberichten === *http://www.saschakimmel.de/2010/02/ethersex-auf-avr-net-io-installieren-mittels-pollin-atmel-evaluationsboard-2-0-und-windows/ , jedoch nicht mit ISP-Kabel sondern mit Umstecken des Controllers. == Live-CD == Diese hat den Vorteil, dass man sein vorhandenes System nicht ändern muss. * http://www.ethersex.de/index.php?title=Live_CD * apt-get install libncurses5-dev * update und installier software fuer ethersex wie beschrieben http://www.ethersex.de/index.php/Download * wenn help in menuconfig nicht geht: apt-get install dialog * weiter wie in "Flashen unter Linux" beschrieben. [[Category:Ethersex]] [[Category:StepByStep]] [[Category:AVR Net-IO]] a9084a03d4eee86328046148fa6e0fff31a13aec 694 691 2012-06-04T18:10:00Z Thrawnhex 540 wikitext text/x-wiki {{i18n|Flashing}} = Flash AVR Net-IO with "ATMEL Evaluations-Board" made by Pollin= As a beginner it's difficult to understand everything in terms of flashing. And it's also difficult to find all information. == What's needed? == * AVR Net-IO * ATMEL Evaluation-Board * a 1 on 1 Cable for the [[ISP]]-Port (10-pin Connector). === Other ISP Programmers === If you have a ISP-Programmer with 6-pin port you can create an adaptor. You can see the pin configuration in figure 4-1 at page 5 [http://www.atmel.com/dyn/resources/prod_documents/doc2521.pdf AVR042: AVR Hardware Design Considerations]. Warning: Pin 4 of the 10-pin connector is not used on the Net-IO. GND has to be connected to one of the other Pins (6, 8 or 10) == Flashing with Linux == *Connect the 10-pin Cable to the ISP-Connector. *Plug in the power adaptor of the AVR Net-IO. *If everything is connected right, the yellow LED of the Evaluation-Board is shining. After compiling the ethersex.hex you can flash it with avrdude. The following commands depend on your ISP-Programmer. This example is for a serial connection: avrdude -v -p m32 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex For a USB-ISP-Programmer this command should be used: avrdude -v -p m32 -c stk500v2 -P /dev/ttyACM0 -U flash:w:ethersex.hex For a parallel ISP-Cable: avrdude -p m32 -e -c stk200 -U flash:w:ethersex.hex After flashing remove the ISP-Cable and interrupt the power connection for a short time to reboot the board. * -p m32: ATMega32; -p m644: ATMega644 * -v: display debug messages * -c ponyser: the way avrdude speaks with the Evaluation Board; -c stkk500v2 for the Atmel board * -P /dev/tty.serial the serial port your programmer is connected to; -P COM1 for windows machines * -U the command you want to execute. In our case we want to flash: -U flash:w:ethersex.hex In some cases you have to set the FUSE Bits, which is possible with this command: * -U lfuse:w:0xCF:m -U hfuse:w:0xDC:m To get the correct FUSE-Settings you should visit http://www.engbedded.com/fusecalc/ Parameters for MyAVR mySmartusb light (the -e is important): avrdude -p m32 -e -c stk500v2 -P /dev/ttyUSB0 -U flash:w:ethersex.hex == Replace ATMega32 with an ATMega644, ATMega644p or ATMega1284p == ATMega644, ATMega644p and ATMega1284p have got a bigger flash then the ATMega32. This gives the possibility to add more modules to your Image. === Swapping the Microcontroller === * Disconnect power and ISP-Connector. * Remove the old processor from your board. * Insert the new processor while the slot is at the same position as in the socket. === Setting the FUSE-Bits === * Reconnect the ISP and the power. * Set the FUSE-Bits. * '''Important: ''' in the condition as supplied the 644 is programmed to 8 MHz internal RC-Oscillator '''and''' the clock is divided by 8 -> 1 MHz clock speed. If an external Quarz is used, the Bit CKDIV8 has to be set to 0. * (taken from dinus) The ATMega has a clock speed of 1 MHz, no JTAG. avrdude -p m644 -c ponyser -P /dev/ttyS0 -U lfuse:w:0xE7:m -U hfuse:w:0xDC:m -U efuse:w:0xFF:m Fuse-Bits from "DiDi". JTAG is turned ON. * -U lfuse:w:0xf7:m -U hfuse:w:0x99:m -U efuse:w:0xfc:m Fuse-Bits from "loddel". JTAG is turned OFF. * -U lfuse:w:0xf7:m -U hfuse:w:0xd9:m -U efuse:w:0xff:m * -U lfuse:w:0xe7:m -U hfuse:w:0xd9:m -U efuse:w:0xff:m Fuse-Bits from "Gregor". "The 644 runs at 16 MHz Quartz and is not divided by 8." JTAG is turned ON. * -U lfuse:w:0xef:m -U hfuse:w:0x99:m -U efuse:w:0xff:m === flash Ethersex === * change Config of Ethersex (make menuconfig) to ATMega644 and build (make) * flash with avrdude -p m644 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex -v === Differentes bettween ATMega32, ATMega644, ATMega644p and ATMega1284p=== {| border=1 cellspacing=0 padding=4 class=wikitable " ! !! ATMega32 !! ATMega644 !! ATMega644p !! ATMega1284p |- | Housing || DIL-40 || DIL-40 || DIL-40 || DIL-40 |- | MHz || max. 16 || max. 20 || max. 20 || max. 20 |- | Flash || 32 KB || 64 KB || 64 KB || 128 KB |- | EEProm || 1 KB || 2 KB || 2 KB || 4 KB |- | RAM || 2 KB || 4 KB || 4 KB || 16 KB |- | I/O || 32 || 32 || 32 || 32 |- | PWM || 4 || 6 || 6 || 6 |- | ext. INT || 3 || 32 || 32 || 32 |- | Ser-Port || 1 || 1 || 2 || 2 |} ====Datenblätter==== * AtMega32 * ATMega644 * ATMega644p * [http://www.atmel.com/dyn/resources/prod_documents/8059S.pdf ATMega1284p] == Flashing with Windows == There a two main possibilities: #Flash with avrdude #Flash with AVR Studio If you don't want to install one of those programs, there is a [[Live CD]] to use. ===Flashing with avrdude=== The flashing with avrdude is just like in Linux. You can get the Windows-Binary as a part of [http://sourceforge.net/projects/winavr/ WinAVR] In the command line you have to adjust the name of the serial Ports. (COMx instead of /dev/ttyxx) avrdude -v -p m32 -c ponyser -P com3 -U flash:w:ethersex.hex If the programmer is connected via USB you need: * for real USB-Programmers: libusb0.dll (Part of WinAVR) * USB-to-Serial Converter a matching Driver: [http://www.ftdichip.com/Drivers/VCP.htm] ===Flashing with AVR Studio=== [[AVR Studio]] from Atmel offers a GUI to Controll the ISPs. AVR Studio also brings USB-Drivers for the Programmers with it, which can be installed together with it. For USB-to-Serial converters you need a matching Driver: [http://www.ftdichip.com/Drivers/VCP.htm] == Live-CD == You don't have to worry about your System if you use a Live CD to flash your build. * Download and burn the CD: [http://www.ethersex.de/index.php?title=Live_CD] * Get the libncurses5 Package: apt-get install libncurses5-dev * Update and install the software for ethersex just like described here: [http://ethersex.de/index.php/Quick_Start_Guide/Preparation] * If menuconfig fails try this command: apt-get install dialog * Flash like described in the "Flashing with Linux" section is described. 8029d8c1358d626e75e223ecc3b9d7633d4ec47f 695 694 2012-06-04T18:52:30Z Thrawnhex 540 Replaced the copy of "Flashing" with a short summary. wikitext text/x-wiki {{i18n|Flashing}} = Requirements = * AVR NET-IO * ISP-Programmer (we're using a Evaluation-Board made by Pollin) * 10-pin connector cable (from Evaluation-Board to the NET-IO) = Flashing with avrdude = Avrdude offers several options. We will look on the most important, to make basic flashing of ethersex possible. * The chip you use, should be m32 for the ATMega32 in most cases: -p m32 * Debug messages: -v * The protocol spoken with the programmer, for the Evaluation-Board: -c ponyser * The serial port the programmer is connected to: -P /dev/ttyS0 * The command you want to execute: -U flash:w:ethersex.hex After you checked all options and adjusted them to your settings you should have a command like this: avrdude -v -p m32 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex = Writing the Bytes = * Disconnect the power from the NET-IO * Connect your ISP cable to the programmer and the Net-IO * Reconnect the power and connect your programmer to the PC * Execute the command you assembled earlier * Congratulations! If avrdude finished without any error you successfully flashed ethersex to your Net-IO! * Disconnect the power and the programmer from the Net-IO * Reconnect the power, your Net-IO should boot up with ethersex 06e908c5cc48fd6af28b56263ce05b2ff1b958e4 696 695 2012-06-04T18:56:20Z Thrawnhex 540 Design changes wikitext text/x-wiki {{i18n|Flashing}} = Requirements = * AVR NET-IO * ISP-Programmer (we're using a Evaluation-Board made by Pollin) * 10-pin connector cable (from Evaluation-Board to the NET-IO) = Flashing with avrdude = Avrdude offers several options. We will look on the most important, to make basic flashing of ethersex possible. * The chip you use, should be m32 for the ATMega32 in most cases: -p m32 * Debug messages: -v * The protocol spoken with the programmer, for the Evaluation-Board: -c ponyser * The serial port the programmer is connected to: -P /dev/ttyS0 * The command you want to execute: -U flash:w:ethersex.hex After you checked all options and adjusted them to your settings you should have a command like this: avrdude -v -p m32 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex = Writing the Bytes = * Disconnect the power from the NET-IO * Connect your ISP cable to the programmer and the Net-IO * Reconnect the power and connect your programmer to the PC * Execute the command you assembled earlier * Congratulations! If avrdude finished without any error you successfully flashed ethersex to your Net-IO! * Disconnect the power and the programmer from the Net-IO * Reconnect the power, your Net-IO should boot up with ethersex f41d7dd707117ec2de89a6e614d20ce657f8709d 697 696 2012-06-04T19:52:45Z Mgue 312 i18n wikitext text/x-wiki {{i18n|Quick Start Guide/Flashing}} = Requirements = * AVR NET-IO * ISP-Programmer (we're using a Evaluation-Board made by Pollin) * 10-pin connector cable (from Evaluation-Board to the NET-IO) = Flashing with avrdude = Avrdude offers several options. We will look on the most important, to make basic flashing of ethersex possible. * The chip you use, should be m32 for the ATMega32 in most cases: -p m32 * Debug messages: -v * The protocol spoken with the programmer, for the Evaluation-Board: -c ponyser * The serial port the programmer is connected to: -P /dev/ttyS0 * The command you want to execute: -U flash:w:ethersex.hex After you checked all options and adjusted them to your settings you should have a command like this: avrdude -v -p m32 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex = Writing the Bytes = * Disconnect the power from the NET-IO * Connect your ISP cable to the programmer and the Net-IO * Reconnect the power and connect your programmer to the PC * Execute the command you assembled earlier * Congratulations! If avrdude finished without any error you successfully flashed ethersex to your Net-IO! * Disconnect the power and the programmer from the Net-IO * Reconnect the power, your Net-IO should boot up with ethersex cc0ef53b9c86c896c9ae257afcb657a9585c742f 698 697 2012-06-04T19:54:04Z Mgue 312 Menu wikitext text/x-wiki {{i18n|Quick Start Guide/Flashing}} = Requirements = * AVR NET-IO * ISP-Programmer (we're using a Evaluation-Board made by Pollin) * 10-pin connector cable (from Evaluation-Board to the NET-IO) = Flashing with avrdude = Avrdude offers several options. We will look on the most important, to make basic flashing of ethersex possible. * The chip you use, should be m32 for the ATMega32 in most cases: -p m32 * Debug messages: -v * The protocol spoken with the programmer, for the Evaluation-Board: -c ponyser * The serial port the programmer is connected to: -P /dev/ttyS0 * The command you want to execute: -U flash:w:ethersex.hex After you checked all options and adjusted them to your settings you should have a command like this: avrdude -v -p m32 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex = Writing the Bytes = * Disconnect the power from the NET-IO * Connect your ISP cable to the programmer and the Net-IO * Reconnect the power and connect your programmer to the PC * Execute the command you assembled earlier * Congratulations! If avrdude finished without any error you successfully flashed ethersex to your Net-IO! * Disconnect the power and the programmer from the Net-IO * Reconnect the power, your Net-IO should boot up with ethersex [[Quick_Start_Guide/Configuration | previous step]] | d058fbfbac4e713979d5a470e79349d4c334f40d 0 279 692 2012-06-04T17:11:22Z Thrawnhex 540 Created page with "{{i18n|Flashing}} = AVR Net-IO mit dem ATMEL Evaluations-Board von Pollin flashen= Als Einsteiger hat man es immer wieder schwer alle Information zu finden. Ich habe lange gesu…" wikitext text/x-wiki {{i18n|Flashing}} = AVR Net-IO mit dem ATMEL Evaluations-Board von Pollin flashen= Als Einsteiger hat man es immer wieder schwer alle Information zu finden. Ich habe lange gesucht bis ich das mit dem Flashen kapiert habe. == Benötigt wird: == * AVR Net-IO * ATMEL Evaluations-Board * ein 1:1 Kabel für den [[ISP]]-Port (10-poliger Pfostenstecker). === Andere ISP-Programmer === Wer über einen ISP-Programmer mit 6-poligem Ausgang verfügt, kann sich ein Adapterkabel bauen. Zu den Pinbelegungen siehe Figure 4-1 auf Seite 5 von [http://www.atmel.com/dyn/resources/prod_documents/doc2521.pdf AVR042: AVR Hardware Design Considerations]. Achtung, Pin 4 des 10-poligen Steckers ist auf dem AVR Net-IO nicht belegt! GND muss daher an einen der anderen Pins (6, 8 oder 10) angeschlossen werden. == Flashen unter Linux == Das 10-polige Kabel in die ISP-Buchse stecken. Nun das AVR Net-IO Board mit Strom versorgen. Wenn das ISP-Kabel richtig gesteckt ist, leuchtet auf dem Evalutions-Board die (gelbe) LED Nach dem Erzeugen der [[:Kategorie:StepByStep#Firmware_kompilieren|ethersex.hex]] kann man mit avrdude das Ganze flashen. Das nachfolgende Kommando ist bei einigen Parametern vom ISP-Programmer abhängig. Das nachfolgende Beispiel gilt für einen ISP-Programmer der über die serielle Schnittstelle arbeitet: avrdude -v -p m32 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex Für eine USB-ISP-Programmer wäre statt dessen der folgende Befehl zu verwenden: avrdude -v -p m32 -c stk500v2 -P /dev/ttyACM0 -U flash:w:ethersex.hex Für ein paralleles ISP-Kabel: avrdude -p m32 -e -c stk200 -U flash:w:ethersex.hex Nach dem Flashen das ISP-Kabel entfernen und kurz die Stromversorgung unterbrechen um das Board zu rebooten. * -p m32 steht für den ATMega32; -p m644 wäre der ATMega644 * -v erweiterte Ausgaben * -c ponyser ist das Verfahren wie das Evalutions-Board die Daten flasht * -P ist die Serielle Schnittstelle an dem das Evalutions-Board angeschlossen ist (bei USB /dev/ttyUSB0) * -U was man machen möchte. In unserem Fall wollen wir das File ethersex.hex flashen (-U flash:w:ethersex.hex) Es kann sein das man für den ATMega32 die FUSE Bits setzen muss. avrdude -p m32 -c ponyser -P /dev/ttyS0 -U lfuse:w:0xCF:m -U hfuse:w:0xDC:m Um die korrekte Fuse-Einstellung rauszufinden, ist es sinnvoll http://www.engbedded.com/fusecalc/ zu benutzen. Die Parameter für MyAVR mySmartusb light (Insbesondere das -e war nötig): avrdude -p m32 -e -c stk500v2 -P /dev/ttyUSB0 -U flash:w:ethersex.hex == Umbau von einem ATMega32 auf den ATMega644 / ATMega644p == Der Vorteil von ATMega644 und ATMega644p ist vor allem der doppelt so große Speicher gegenüber dem serienmäßigen ATMega32. === Mikrocontroller tauschen === * Stromversorgung abschalten und ISP-Stecker abziehen. * Den ATMega32 aus seinem Sockel auf dem AVR Net-IO ziehen. * Den ATMega644 oder ATMega644p einbauen. (ACHTUNG: Kerbe im Sockel muss mit Kerbe in der CPU übereinstimmen) === Fuse-Bits setzen === * ISP wieder einstecken und Stromversorgung einschalten. * Fuse-Bits setzen * '''Wichtig:''' im Auslieferungszustand ist der ATMega644 programmiert auf 8MHz interner RC-Oszillator '''und''' der Takt wird durch 8 geteilt; also 1MHz Takt. Wenn ein externer Quarz verwendet wir, muss das Bit CKDIV8 (Takt geteilt durch 8) auf null gesetzt werden. * (Übernommen von dinus) Der ATMega wird dabei mit 1Mhz getaktet, kein JTAG. avrdude -p m644 -c ponyser -P /dev/ttyS0 -U lfuse:w:0xE7:m -U hfuse:w:0xDC:m -U efuse:w:0xFF:m * bzw. avrdude -p m644p -c ponyser -P /dev/ttyS0 -U lfuse:w:0xE7:m -U hfuse:w:0xDC:m -U efuse:w:0xFF:m Fuse-Bits wie sie "DiDi" einsetzt. Der JTAG ist eingeschaltet. * -U lfuse:w:0xf7:m -U hfuse:w:0x99:m -U efuse:w:0xfc:m Fuse-Bits wie "loddel" sie einsetzt. Der JTAG ist ausgeschaltet. * -U lfuse:w:0xf7:m -U hfuse:w:0xd9:m -U efuse:w:0xff:m * -U lfuse:w:0xe7:m -U hfuse:w:0xd9:m -U efuse:w:0xff:m Fuse-Bits wie "gregor" sie einsetzt. "Damit läuft der 644 auf 16MHz Quarz und der Takt wird nicht durch 8 geteilt." Der JTAG ist eingeschaltet. * -U lfuse:w:0xef:m -U hfuse:w:0x99:m -U efuse:w:0xff:m === Ethersex reinflashen=== * in der Config von Ethersex (make menuconfig) von ATmega32 auf ATMega644 umstellen * Flashen mit avrdude -p m644 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex -v * bzw. avrdude -p m644p -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex -v === Unterschiede zwischen ATMega32, ATMega644, ATMega644p und ATMega1284p=== {| border=1 cellspacing=0 padding=4 class=wikitable " ! !! ATMega32 !! ATMega644 !! ATMega644p !! ATMega1284p |- | Gehäuse || DIL-40 || DIL-40 || DIL-40 || DIL-40 |- | MHz || max. 16 || max. 20 || max. 20 || max. 20 |- | Flash || 32 KB || 64 KB || 64 KB || 128 KB |- | EEProm || 1 KB || 2 KB || 2 KB || 4 KB |- | RAM || 2 KB || 4 KB || 4 KB || 16 KB |- | I/O || 32 || 32 || 32 || 32 |- | PWM || 4 || 6 || 6 || 6 |- | ext. INT || 3 || 32 || 32 || 32 |- | Ser-Port || 1 || 1 || 2 || 2 |} ====Datenblätter==== * AtMega32 * ATMega644 * ATMega644p * [http://www.atmel.com/dyn/resources/prod_documents/8059S.pdf ATMega1284p] == Flashen unter Windows == Es gibt mindestens zwei Möglichkeiten: #Flashen mit avrdude #Flashen mit AVR Studio Wer keines der beiden Programme auf seine Festplatte legen möchte, weil er sein Windows-System nicht ändern möchte, kann auch die [[Live CD]] verwenden. ===Flashen mit avrdude=== Das Flashen mit avrdude erfolgt prinzipiell genauso wie unter Linux (siehe oben). Ein Windows-Binary von avrdude erhält man am einfachsten als Bestandteil von [http://sourceforge.net/projects/winavr/ WinAVR]. (Ansonsten findet man ein Windows-Binary von avrdude auch auf [http://yuki-lab.jp/hw/avrdude-GUI/index.html dieser japanischen Seite], wo man auch eine GUI für avrdude bekommen kann. Google-Translate hilft den japanischen Text zu verstehen.) In der Kommandozeile muss natürlich die Bezeichnung des seriellen Ports angepasst werden, also "COMx" anstelle von "/dev/ttyS0", z.B. avrdude -v -p m32 -c ponyser -P com3 -U flash:w:ethersex.hex Sofern der Programmer per USB angeschlossen ist, benötigt man * bei echten USB-Programmern die libusb0.dll (bei WinAVR enthalten), * bei Verwendung eines USB-nach-seriell-Adapters mit FTDI-Chip (dieser kann auch manchmal bereits in den Programmer mit USB-Anschluss eingebaut sein!) einen passenden Treiber, siehe http://www.ftdichip.com/Drivers/VCP.htm. ===Flashen mit AVR Studio=== Das [[AVR Studio]] von Atmel bietet eine grafische Oberfläche zur Bedienung von ISPs. Beim AVR Studio werden USB-Treiber für USB-Programmer mitgeliefert, die optional zusammen mit dem AVR Studio installiert werden können. Für USB-nach-seriell-Adapter mit FTDI-Chip benötigt man einen passenden Treiber, siehe http://www.ftdichip.com/Drivers/VCP.htm. === Links zu Erfahrungsberichten === *http://www.saschakimmel.de/2010/02/ethersex-auf-avr-net-io-installieren-mittels-pollin-atmel-evaluationsboard-2-0-und-windows/ , jedoch nicht mit ISP-Kabel sondern mit Umstecken des Controllers. == Live-CD == Diese hat den Vorteil, dass man sein vorhandenes System nicht ändern muss. * http://www.ethersex.de/index.php?title=Live_CD * apt-get install libncurses5-dev * update und installier software fuer ethersex wie beschrieben http://www.ethersex.de/index.php/Download * wenn help in menuconfig nicht geht: apt-get install dialog * weiter wie in "Flashen unter Linux" beschrieben. [[Category:Ethersex]] [[Category:StepByStep]] [[Category:AVR Net-IO]] a9084a03d4eee86328046148fa6e0fff31a13aec 0 280 693 2012-06-04T18:05:23Z Thrawnhex 540 Translated the German version to english wikitext text/x-wiki {{i18n|Flashing}} = Flash AVR Net-IO with "ATMEL Evaluations-Board" made by Pollin= As a beginner it's difficult to understand everything in terms of flashing. And it's also difficult to find all information. == What's needed? == * AVR Net-IO * ATMEL Evaluation-Board * a 1 on 1 Cable for the [[ISP]]-Port (10-pin Connector). === Other ISP Programmers === If you have a ISP-Programmer with 6-pin port you can create an adaptor. You can see the pin configuration in figure 4-1 at page 5 [http://www.atmel.com/dyn/resources/prod_documents/doc2521.pdf AVR042: AVR Hardware Design Considerations]. Warning: Pin 4 of the 10-pin connector is not used on the Net-IO. GND has to be connected to one of the other Pins (6, 8 or 10) == Flashing with Linux == *Connect the 10-pin Cable to the ISP-Connector. *Plug in the power adaptor of the AVR Net-IO. *If everything is connected right, the yellow LED of the Evaluation-Board is shining. After compiling the ethersex.hex you can flash it with avrdude. The following commands depend on your ISP-Programmer. This example is for a serial connection: avrdude -v -p m32 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex For a USB-ISP-Programmer this command should be used: avrdude -v -p m32 -c stk500v2 -P /dev/ttyACM0 -U flash:w:ethersex.hex For a parallel ISP-Cable: avrdude -p m32 -e -c stk200 -U flash:w:ethersex.hex After flashing remove the ISP-Cable and interrupt the power connection for a short time to reboot the board. * -p m32: ATMega32; -p m644: ATMega644 * -v: display debug messages * -c ponyser: the way avrdude speaks with the Evaluation Board; -c stkk500v2 for the Atmel board * -P /dev/tty.serial the serial port your programmer is connected to; -P COM1 for windows machines * -U the command you want to execute. In our case we want to flash: -U flash:w:ethersex.hex In some cases you have to set the FUSE Bits, which is possible with this command: * -U lfuse:w:0xCF:m -U hfuse:w:0xDC:m To get the correct FUSE-Settings you should visit http://www.engbedded.com/fusecalc/ Parameters for MyAVR mySmartusb light (the -e is important): avrdude -p m32 -e -c stk500v2 -P /dev/ttyUSB0 -U flash:w:ethersex.hex == Replace ATMega32 with an ATMega644, ATMega644p or ATMega1284p == ATMega644, ATMega644p and ATMega1284p have got a bigger flash then the ATMega32. This gives the possibility to add more modules to your Image. === Swapping the Microcontroller === * Disconnect power and ISP-Connector. * Remove the old processor from your board. * Insert the new processor while the slot is at the same position as in the socket. === Setting the FUSE-Bits === * Reconnect the ISP and the power. * Set the FUSE-Bits. * '''Important: ''' in the condition as supplied the 644 is programmed to 8 MHz internal RC-Oscillator '''and''' the clock is divided by 8 -> 1 MHz clock speed. If an external Quarz is used, the Bit CKDIV8 has to be set to 0. * (taken from dinus) The ATMega has a clock speed of 1 MHz, no JTAG. avrdude -p m644 -c ponyser -P /dev/ttyS0 -U lfuse:w:0xE7:m -U hfuse:w:0xDC:m -U efuse:w:0xFF:m Fuse-Bits from "DiDi". JTAG is turned ON. * -U lfuse:w:0xf7:m -U hfuse:w:0x99:m -U efuse:w:0xfc:m Fuse-Bits from "loddel". JTAG is turned OFF. * -U lfuse:w:0xf7:m -U hfuse:w:0xd9:m -U efuse:w:0xff:m * -U lfuse:w:0xe7:m -U hfuse:w:0xd9:m -U efuse:w:0xff:m Fuse-Bits from "Gregor". "The 644 runs at 16 MHz Quartz and is not divided by 8." JTAG is turned ON. * -U lfuse:w:0xef:m -U hfuse:w:0x99:m -U efuse:w:0xff:m === flash Ethersex === * change Config of Ethersex (make menuconfig) to ATMega644 and build (make) * flash with avrdude -p m644 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex -v === Differentes bettween ATMega32, ATMega644, ATMega644p and ATMega1284p=== {| border=1 cellspacing=0 padding=4 class=wikitable " ! !! ATMega32 !! ATMega644 !! ATMega644p !! ATMega1284p |- | Housing || DIL-40 || DIL-40 || DIL-40 || DIL-40 |- | MHz || max. 16 || max. 20 || max. 20 || max. 20 |- | Flash || 32 KB || 64 KB || 64 KB || 128 KB |- | EEProm || 1 KB || 2 KB || 2 KB || 4 KB |- | RAM || 2 KB || 4 KB || 4 KB || 16 KB |- | I/O || 32 || 32 || 32 || 32 |- | PWM || 4 || 6 || 6 || 6 |- | ext. INT || 3 || 32 || 32 || 32 |- | Ser-Port || 1 || 1 || 2 || 2 |} ====Datenblätter==== * AtMega32 * ATMega644 * ATMega644p * [http://www.atmel.com/dyn/resources/prod_documents/8059S.pdf ATMega1284p] == Flashing with Windows == There a two main possibilities: #Flash with avrdude #Flash with AVR Studio If you don't want to install one of those programs, there is a [[Live CD]] to use. ===Flashing with avrdude=== The flashing with avrdude is just like in Linux. You can get the Windows-Binary as a part of [http://sourceforge.net/projects/winavr/ WinAVR] In the command line you have to adjust the name of the serial Ports. (COMx instead of /dev/ttyxx) avrdude -v -p m32 -c ponyser -P com3 -U flash:w:ethersex.hex If the programmer is connected via USB you need: * for real USB-Programmers: libusb0.dll (Part of WinAVR) * USB-to-Serial Converter a matching Driver: [http://www.ftdichip.com/Drivers/VCP.htm] ===Flashing with AVR Studio=== [[AVR Studio]] from Atmel offers a GUI to Controll the ISPs. AVR Studio also brings USB-Drivers for the Programmers with it, which can be installed together with it. For USB-to-Serial converters you need a matching Driver: [http://www.ftdichip.com/Drivers/VCP.htm] == Live-CD == You don't have to worry about your System if you use a Live CD to flash your build. * Download and burn the CD: [http://www.ethersex.de/index.php?title=Live_CD] * Get the libncurses5 Package: apt-get install libncurses5-dev * Update and install the software for ethersex just like described here: [http://ethersex.de/index.php/Quick_Start_Guide/Preparation] * If menuconfig fails try this command: apt-get install dialog * Flash like described in the "Flashing with Linux" section is described. 8029d8c1358d626e75e223ecc3b9d7633d4ec47f 3 310 728 2012-06-22T08:55:00Z Claudilog 562 Created page with "Moin, ich bin eine echte deutsche Ehefrau die in ihrer freizeit mit Vergnügen vor der webcam chillt. ich versuche dabei so unkompliziert wie möglich zu bleiben, auch wenn ihr m…" wikitext text/x-wiki Moin, ich bin eine echte deutsche Ehefrau die in ihrer freizeit mit Vergnügen vor der webcam chillt. ich versuche dabei so unkompliziert wie möglich zu bleiben, auch wenn ihr mir dauernd wieder geile outfits zum anziehen sendet. manche Sachen davon sind ja schon krasser rollenspiel Nippes. ich habe ausserdem noch vor diese woche jede menge festivals mit zu nehemen. vielleicht sieht man sich ja auf dem hurrican? My page: [http://livestrip.spittingandvomitting.com/ hardcore sex bilder] f719aa4161d1897957e9115f9e7a5615e90fbc92 0 43 743 406 2012-07-02T15:28:23Z VickieDickerson 572 wikitext text/x-wiki <div class="errorbox"> This page is automatically generated from the files in the Ethersex source code repository. Do not edit this page but send [[patches]] for those files! </div> __NOTOC__ == Analog/Digital Conversion ([[ADC]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | adc get [CHANNEL] | Get the ADC value in hex of CHANNEL or if no channel set of all channels. |- | hr20 temp | Read HR20 temperature sensor. |- |} == DNS Resolver == {| border='1' | ''Command syntax'' | ''Short description'' |- | dns server [IPADDR] | Display/Set the IP address of the DNS server to use to IPADDR. |- | nslookup HOSTNAME | Do DNS lookup for HOSTNAME (call twice). |- |} == Digital/Analog Conversion ([[DAC]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ltc1257_delay `[VALUE] | Set (if VALUE given) or get (no VALUE) delay for LTC1257 output bit changes in µs' |- | ltc1257_set `[VALUE0] [VALUE1] ... | Set output to value (value: 0-4095)' |- | tlc5620 `[CHANNEL] [VALUE] | Set Output to value (Value: 0-0xff)' |- |} == Fnordlicht == {| border='1' | ''Command syntax'' | ''Short description'' |- | fnordlicht "ADDRESS RED | GREEN,BLUE",fnordlicht command to set RGB color |- | fnordlicht_init | fnordlicht init |- |} == HD44780 [[LCD]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | hr20 hourbar START STOP | Update hourbar to show ticks between START and STOP (range 0..23) |- | hr20 toggle SEG | Toggle segment SEG (a number, not a symbolic name!) |- | lcd backlight STATE | switch back light STATE to ON or OFF |- | lcd char N D1 D2 D3 D4 D5 D6 D7 D8 | Define use-definable char N with data D1..D8 (provide DATA in hex) |- | lcd clear [LINE] | Clear line LINE (0..3) or the whole display (if parameter is omitted) |- | lcd goto LINE COL | Move cursor to LINE and column COL (origin is 0/0) |- | lcd reinit CURSOR BLINK | Reinitialize the display, set whether to show the cursor (CURSOR, 0 or 1) and whether the cursor shall BLINK |- | lcd shift DIR | Shift the display to DIR (either ''left'' or ''right'') |- | lcd write TEXT | Write TEXT to the current cursor location |- |} == Infrared Send/Receive ([[IR-TRX]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ir receive | receive an IR command |- | ir send DEVICE COMMAND | send COMMAND to DEVICE |- |} == Infrared Send/Receive ([[IRMP]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | irmp receive | receive an IR command |- | irmp send PROTOCOL DEVICE COMMAND REPEAT | send COMMAND with REPEAT flag to DEVICE using PROTOCOL |- |} == NTP Client == {| border='1' | ''Command syntax'' | ''Short description'' |- | ntp query | Query the NTP server to get an NTP update. |- | ntp server [IPADDR] | Display/Set the IP address of the NTP server to use to IPADDR. |- | ntp status | Display NTP server status |- |} == Network configuration == {| border='1' | ''Command syntax'' | ''Short description'' |- | enc dump | Dump the internal state of the enc to serial |- | gw [IP] | Display/Set the address of the default router. |- | ip [IP] | Display/Set the IP address. |- | mac [xx:xx:xx:xx:xx:xx] | Display/Set the MAC address. |- | netmask [IP] | Display/Set the network mask. |- |} == Port I/O == {| border='1' | ''Command syntax'' | ''Short description'' |- | io get ddr PORTNUM | Display the current value of the DDR PORTNUM. |- | io get mask PORTNUM | Display the mask of the port PORTNUM. |- | io get pin PORTNUM | Display the current value of the PIN-register of the port PORTNUM. |- | io get port NUM | Display the current value of the PORT NUM. |- | io set ddr PORTNUM HEXVALUE [MASK] | Set the DDR of port PORTNUM to VALUE (possibly using the provided MASK). |- | io set port NUM HEXVALUE [MASK] | Set the PORT NUM to VALUE (possibly using the provided MASK). |- |} == Reading and Writing EEPROM Space on Device == {| border='1' | ''Command syntax'' | ''Short description'' |- | eer eer <ADDR> <LENGTH> | Read n bytes from address after the config in eeprom. |- | eew eew <ADDR> <HEXBYTES> | Write Hexbytes at address after the config in epprom. |- | fuse | Display current fuse settings |- | hostname | Display hostname. |- |} == Resetting the controller == {| border='1' | ''Command syntax'' | ''Short description'' |- | bootloader | Call the bootloader. |- | reset | Reset the Ethersex. |- | wdreset | Go into endless loop to trigger a watchdog timeout. |- |} == [[ADS]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | adc get | Get the ADC value in hex. |- | adc mean [COUNT] | Get the mean of power of 2 COUNT ADC values in hex. |- |} == [[Am_Puls_der_Zeit|Clock]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | date | Print the current date. |- | lastdcf | Print when last valid DCF signal was received. |- | time [UNIXTIME] | Display/Set the current time in seconds since January 1st 1970. |- | uptime | Display ethersex uptime in unix format. |- | whm | Display ethersex uptime. |- |} == [[Application_Sample]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sample | Manually call application sample commands |- | sample_init | Manually call application sample init method |- | sample_periodic | Manually call application sample periodic method |- |} == [[Blinkenlights_MCUF|MCUF]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | mcuf modul N | Select module N |- | mcuf modul list | List all modules |- | mcuf showclock | Show digital clock |- | mcuf showstring MESSAGE | Show scrolling MESSAGE on the display |- |} == [[CRC]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | crc calc | "read the ethersex program code and calc a crc16 of it" |- | crc read | "read out the crc16 value at the end of the program space" |- |} == [[CRON-Dienst]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | cron_add MIN HOUR DAY MONTH DOW ECMD | Add ECMD to cron to be executed at given time |- | cron_list | Show all cron entries |- | cron_make_persistent | Mark a Job as persistent |- | cron_rm POSITION | Remove one cron entry |- | cron_save | Saves all persistent jobs |- |} == [[DALI]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dali cmd [TARGET] [COMMAND] [!][?] | "send the given command (decimal) to targets (all, g00 to g15, s00 to s63), auto repeat with !, read reply with ?" |- | dali dim [TARGET] [LEVEL] | "dim targets (all, g00 to g15, s00 to s63) to given level (0-254)" |- | dali raw [BYTE1] [BYTE2] | "send a raw frame (two bytes, given in hex) over the DALI bus" |- | dali scmd [SPECIAL COMMAND] [DATA] [!][?] | "send special command (256-287) with data, auto repeat with !, read reply with ?" |- |} == [[DMX_FXSlot]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx fxslot devices | set the device settings |- | dmx fxslot effect | set the effect settings |- | dmx fxslot reset | reset all fxslots and clear saved ones in EEPROM |- | dmx fxslot restore | restore the settings from EEPROM |- | dmx fxslot save | save the current fxslots to EEPROM |- |} == [[DMX_Storage]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx channels | Get channels per universe |- | dmx get | Return channel value |- | dmx set | Set channel values |- | dmx universe | Get a whole universe |- | dmx universes | Get universes |- |} == [[Dallas_1-wire_Bus]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | 1w convert [DEVICE] | Trigger temperature conversion of either DEVICE or all connected devices |- | 1w ds2450 convert [DEVICE] | `start conversion (with optional input mask and read out control)' |- | 1w ds2450 get [DEVICE] | `get conversion result (one or all channels)' |- | 1w ds2450 oc [DEVICE] | `get/set output control (per channel)' |- | 1w ds2450 oe [DEVICE] | `get/set output enable (per channel)' |- | 1w ds2450 por [DEVICE] | `get/set power on reset (per channel)' |- | 1w ds2450 power [DEVICE] | `get/set power supply of device (global)' |- | 1w ds2450 range [DEVICE] | `get/set input voltage range (per channel)' |- | 1w ds2450 res [DEVICE] | `get/set bit resolution of AD convert (per channel)' |- | 1w get DEVICE | Return temperature value of onewire DEVICE (provide 64-bit ID as 16-hex-digits) |- | 1w list | Return a list of the connected onewire devices |- |} == [[DataFlash]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | df status | Display internal status. |- | fs format | Format the filesystem. |- | fs inspect inode INODE | Inspect INODE (and associated page). |- | fs inspect node NODE | Inspect NODE and dump to serial. |- | fs list | List the directory. |- | fs mkfile NAME | Create a new file NAME. |- | fs remove NAME | Delete the file NAME. |- | fs truncate NAME LEN | Truncate the file NAME to LEN bytes. |- |} == [[Dc3840_camera|DC3840 mobil camera support]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dc3840 capture | Take a picture. Access 'dc3840' via VFS afterwards. See [[DC3840 Camera]] for details. |- | dc3840 light | Light level of camera |- | dc3840 send A B C D E | Send provided command bytes to the camera. |- | dc3840 sync | Re-sync to the camera |- | dc3840 zoom | Enable zoom of camera |- |} == [[ECMDScript]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | call FILENAME | Start script named FILENAME |- | cat FILENAME | cat file content (with debug only) |- | dec VAR | Decrement variable VAR (a number) |- | echo <any> | Print out all arguments of echo |- | exit | Exit currently running script |- | get VAR | Get value of variable VAR |- | goto N | Goto line N in currently running script |- | if ( CMD/VAR == CONST ) then CMD2 | If condition matches execute CMD2 |- | inc VAR | Increment variable VAR (a number) |- | rem <any> | Remark for anything |- | set VAR VALUE | Set variable VAR to VALUE |- | wait I | Wait I milliseconds |- |} == [[FS20]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fht send HOUSECODE ADDR CMD [CMD2] | Send FHT command. See [[FS20]] for details. |- | fs20 receive | Receive FS20/FHT sequence and display it. |- | fs20 send HOUSECODE ADDR CMD [CMD2] | Send FS20 command. All my fellows order american literature essays at the [http://essaysexperts.com college papers] service. Probably, I should buy essays papers as well. See [[FS20]] for details. |- | fs20 ws300 | Receive FS20 sequence from WS300 weather station and decode it. |- |} == [[Frequency Counter]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fc %duty [CHANNEL] | "returns last on duty cycle in percent for given channel" |- | fc duty [CHANNEL] | "returns last on duty cycle (0-255) for given channel" |- | fc freq [CHANNEL] | "returns last frequency in Hz for given channel" |- | fc off [CHANNEL] | "switch off frequency counting on given channel" |- | fc on [CHANNEL] | "switch on frequency counting on given channel" |- | fc ticks [CHANNEL] | "returns last frequency in CPU ticks for given channel" |- |} == [[GLCD_Menu]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | glcdmenu key VALUE | Send a keypress to the menu |- | glcdmenu update | Update the menu |- |} == [[GPS]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | nmea get | Get latitude and longitude data |- | nmea satellites | Get satellites |- |} == [[H-Bridge]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | hbridge [action] [enable_l] [enable_r] | Set H-Bridge command |- | hbridge pwm int | Set H-Bridge enable line valueeg. speed |- |} == [[I2C]] (TWI) == {| border='1' | ''Command syntax'' | ''Short description'' |- | bmp085 apress | Get absolute pressure in Pa |- | bmp085 height PRESSNN | Get height in cm, pressure at N0 needed |- | bmp085 pressnn HEIGHT | Get pressure at N0, height in cm needed |- | bmp085 temp | Get temperature in 0.1°C |- | ds1631 convert ADDR VALUE | Initiate temperature conversions (0: stop, 1: convert) |- | ds1631 temp ADDR | Read last converted temperature |- | i2c detect | list detected I2C Chips |- | i2c rbb ADDR | read byte from I2C chip |- | i2c rbd CHIPADDR REGADDR | read byte from register address at I2C chip |- | i2c rwd CHIPADDR REGADDR | read word from register address at I2C chip |- | i2c wbb ADDR HEXVALUE | write byte to I2C chip |- | i2c wbd CHIPADDR REGADDR HEXVALUE | write byte to register address on I2C chip |- | i2c wwd CHIPADDR REGADDR HEXVALUE | write word to register address on I2C chip |- | lm75 ADDR | Get temperature |- | max7311 getDDRw ADDR | Get Direction-Register DDR |- | max7311 getINw ADDR | Get Input-Register IN |- | max7311 getOUTw ADDR | Get Output-Register OUT |- | max7311 pulse ADDR BIT TIME | Toggle Output-BIT for TIME (in ms) |- | max7311 set ADDR BIT VALUE | Set Output-BIT to VALUE (bool) |- | max7311 setDDRw ADDR VALUE | Set Direction-Register DDR (VALUE as hex) |- | max7311 setOUTw ADDR VALUE | Set Output-Register OUT (VALUE as hex) |- | pca9531 ADDR PERIODPWM1 DUTYPWM1 PERIODPWM2 DUTYPWM2 LED0..3 LED4..7 | set PWM1 and PWM2 and LED states |- | pca9685m ADDR | OUTDRV, IVRT, PRESCALE |- | pca9685s ADDR | LED, ON, OFF |- | pcf8574x read ADDR CHIP | Get bits |- | pcf8574x set ADDR CHIP HEXVALUE | Set bits |- | tsl2550 lux | Show light level by reading adc registers and computing level |- | tsl2550 mode VALUE | Set the TSL2550s operating mode (0: standard range, 1: extended range) |- | tsl2550 power VALUE | Set the TSL2550s power state (0: down, 1:up) |- |} == [[Jabber]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | jabber_host [HOSTNAME] | JABBER hostname |- | jabber_pass [PASSWORD] | JABBER password |- | jabber_resrc [RESOURCE] | JABBER resource |- | jabber_user [USERNAME] | JABBER username |- |} == [[KTY]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | kty autocalibrate CHANNEL | Calibrate to 1000 Ohm precision Resistor. |- | kty cal get | Return the calibration difference to 2k2 Resistor. |- | kty get [CHANNEL] | Get the temperature in xxx.x °C of CHANNEL or if no channel set of all channels. |- |} == [[MotorCurtain]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | curtain VALUE | Set value of curtain. 0=closed..7=open. If you use fewer sensors, use the corrent value instead of 7. |- | curtainlast | Return last known position |- | curtainmax | Return maximum position |- | curtainoff | Switch motor off |- |} == [[Named_PIN]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | pin get NAME | Read and display the status of pin NAME. |- | pin list | List all known named-pins. |- | pin set NAME STATUS | Set the status of pin NAME to STATUS. |- | pin toggle NAME | Toggle the status of pin NAME. |- |} == [[PWM]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dtmf CHARS | send CHARS as DTMF |- | freq set FREQUENCY DELAY | Set frequency for DELAY ms |- | pwm fade [channel +-diff startvalue] | Set fading at channel with startvalue and change each stepp to diff (must be signed 3 digit) |- | pwm set [channel value] | Set channel to value |- |} == [[RFM12]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | rfm12 reinit | Re-initialize RFM12 module. |- | rfm12 setbandwidth BW | Set RX bandwidth to BW. |- | rfm12 setbaud BAUD | Set baudrate to BAUD. |- | rfm12 setdrssi DRSSI | Set the drssi to DRSSI. |- | rfm12 setgain GAIN | Set preamplifier gain to GAIN. |- | rfm12 setmod MOD | Set modulation to MOD. |- | rfm12 status | Display internal status. |- |} == [[RFM12_ASK]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | rfm12 1527 | housecodeCommand delay cnt |- | rfm12 2272 | housecodeCommand delay cnt |- | rfm12 ask sense | Trigger (Tevion) ASK sensing. Enable ext. filter pin before! |- | rfm12 external filter [1] | Enable ext. filter pin if argument is present (disable otherwise) |- | rfm12 intertechno | family group device command |- | rfm12 tevion | housecode command delay cnt |- |} == [[RFM12_FS20]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fht send | housecode addr command data |- | fs20 send | housecode addr command data |- |} == [[SD-Karte]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sd dir | List contents of current SD directory. |- | sd mkdir PATH | Create directory hierarchy PATH. |- |} == [[SHT]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sht humid | Return humidity of SHT sensor |- | sht raw | Return raw hex temp (first line) and humidity value (second line) of SHT sensor |- | sht temp | Return temperature of SHT sensor |- |} == [[SMS77]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sms77 MESSAGE | Send MESSAGE to compiled in sms77 service |- | sms77_pass [PASSWORD] | SMS77 password |- | sms77_recv [RECEIVER] | SMS receiver |- | sms77_type [TYPE] | SMS type |- | sms77_user [USERNAME] | SMS77 username |- |} == [[Servo_Ansteuerung|PWM Servo Control]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | pwm servo_dec SERVONR | Decrement position of servo SERVONR |- | pwm servo_inc SERVONR | Increment position of servo SERVONR |- | pwm servo_set SERVONR POSITION | Set servo with SERVONR to POSITION |- |} == [[Sound]]/WAV support == {| border='1' | ''Command syntax'' | ''Short description'' |- | pwm stop | Stop wav |- | pwm wav <FILENAME> | Play wave file. Use VFS if compiled in. More details at [[Sound]] |- |} == [[Stella_Light]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | channel CHANNEL VALUE FUNCTION | Get/Set stella channel to value. Second and third parameters are optional. Function: You may use 's' for instant set, 'f' for fade and 'y' for flashy fade. |- | channels | Return stella channel size |- | fadestep FADESTEP | Get/Set stella fade step |- | stella load | Load values from eeprom |- | stella store | Store values in eeprom |- |} == [[USB]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | keyboard MESSAGE | Send MESSAGE as HID keyboard |- | mouse BUTTON DELTAX DELTAY | Send data as HID mouse |- |} == [[ZACwire]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | zac 306 PORT BIT | Return temperature of TSic 306 at BIT of PORT |- | zac 506 PORT BIT | Return temperature of TSic 506 at BIT of PORT |- | zac raw PORT BIT | Return raw hex temperature value of zacwire at BIT of PORT |- |} == lome6 == {| border='1' | ''Command syntax'' | ''Short description'' |- | lome6 get_t TYPE | get temperature command |- | lome6 power TYPE | press power command |- | lome6 reset | press reset command |- | lome6 set_t TYPE TEMPERATURE | set temperature command |- | lome6 state | get state command |- | lome6 uptime UPTIME | set/get uptime command |- |} == Miscelleanous == {| border='1' | ''Command syntax'' | ''Short description'' |- | alias list | List all available aliases |- | artnet test | artnet test |- | cw send MESSAGE | Send MESSAGE in Morce Code |- | d ADDR | Dump the memory at ADDR (16 bytes). |- | eeprom reinit | Force reinitialization of the EEPROM config area |- | free | Display free space. |- | help | List which commands are available. |- | ht MESSAGE | Send MESSAGE to compiled in httplog service |- | ipstats | Display IP statistics. |- | mb recv | Receive data from modbus |- | moodlight CHANNEL ONOFF | Set CHANNEL moodlight on=1 or off=0. If no channel is given return on if channel CHANNEL is moodlighted |- | motd [MESSAGE] | Save MESSAGE as new message of the day, otherwise just show current message |- | msr1 get | Get data |- | mysql query QUERY | Send specified MySQL query to the configured server |- | ns | update net statistic for public anouncment of currently running ethersex |- | pam USER PASSWORD | Use pam for user and password |- | push NUMBER | Push button identified by NUMBER |- | pwm melody [NUMBER] | Play melody |- | sanyoz700 CMD | Send command to projector |- | sll get | Request the logged data |- | sram memtest | Perform a memory test |- | srf05 | Read SRF05 measurement |- | to1 get | Request data from sensor |- | tw MESSAGE | Send MESSAGE to compiled in twitter service |- | upnp send | Manually send UPnP broadcast packet |- | usart baud BAUD | Set the USART baudrate to BAUD. |- | version | Display the version number. |- | wol MAC | Send WAKE-ON-LAN command to MAC |- | yport stats | Report statistic counters |- | zbus stats | Report statistic counters |- |} [[Category:Ethersex]] [[Category:ECMD]] 01c8d1bf62f1af641efa6f5d78b10de5f4e3f336 744 743 2012-07-02T18:21:15Z GooPie4o 265 Reverted edits by [[Special:Contributions/VickieDickerson|VickieDickerson]] ([[User talk:VickieDickerson|Talk]]) to last revision by [[User:Unclestefan|Unclestefan]] wikitext text/x-wiki <div class="errorbox"> This page is automatically generated from the files in the Ethersex source code repository. Do not edit this page but send [[patches]] for those files! </div> __NOTOC__ == Analog/Digital Conversion ([[ADC]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | adc get [CHANNEL] | Get the ADC value in hex of CHANNEL or if no channel set of all channels. |- | hr20 temp | Read HR20 temperature sensor. |- |} == DNS Resolver == {| border='1' | ''Command syntax'' | ''Short description'' |- | dns server [IPADDR] | Display/Set the IP address of the DNS server to use to IPADDR. |- | nslookup HOSTNAME | Do DNS lookup for HOSTNAME (call twice). |- |} == Digital/Analog Conversion ([[DAC]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ltc1257_delay `[VALUE] | Set (if VALUE given) or get (no VALUE) delay for LTC1257 output bit changes in µs' |- | ltc1257_set `[VALUE0] [VALUE1] ... | Set output to value (value: 0-4095)' |- | tlc5620 `[CHANNEL] [VALUE] | Set Output to value (Value: 0-0xff)' |- |} == Fnordlicht == {| border='1' | ''Command syntax'' | ''Short description'' |- | fnordlicht "ADDRESS RED | GREEN,BLUE",fnordlicht command to set RGB color |- | fnordlicht_init | fnordlicht init |- |} == HD44780 [[LCD]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | hr20 hourbar START STOP | Update hourbar to show ticks between START and STOP (range 0..23) |- | hr20 toggle SEG | Toggle segment SEG (a number, not a symbolic name!) |- | lcd backlight STATE | switch back light STATE to ON or OFF |- | lcd char N D1 D2 D3 D4 D5 D6 D7 D8 | Define use-definable char N with data D1..D8 (provide DATA in hex) |- | lcd clear [LINE] | Clear line LINE (0..3) or the whole display (if parameter is omitted) |- | lcd goto LINE COL | Move cursor to LINE and column COL (origin is 0/0) |- | lcd reinit CURSOR BLINK | Reinitialize the display, set whether to show the cursor (CURSOR, 0 or 1) and whether the cursor shall BLINK |- | lcd shift DIR | Shift the display to DIR (either ''left'' or ''right'') |- | lcd write TEXT | Write TEXT to the current cursor location |- |} == Infrared Send/Receive ([[IR-TRX]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ir receive | receive an IR command |- | ir send DEVICE COMMAND | send COMMAND to DEVICE |- |} == Infrared Send/Receive ([[IRMP]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | irmp receive | receive an IR command |- | irmp send PROTOCOL DEVICE COMMAND REPEAT | send COMMAND with REPEAT flag to DEVICE using PROTOCOL |- |} == NTP Client == {| border='1' | ''Command syntax'' | ''Short description'' |- | ntp query | Query the NTP server to get an NTP update. |- | ntp server [IPADDR] | Display/Set the IP address of the NTP server to use to IPADDR. |- | ntp status | Display NTP server status |- |} == Network configuration == {| border='1' | ''Command syntax'' | ''Short description'' |- | enc dump | Dump the internal state of the enc to serial |- | gw [IP] | Display/Set the address of the default router. |- | ip [IP] | Display/Set the IP address. |- | mac [xx:xx:xx:xx:xx:xx] | Display/Set the MAC address. |- | netmask [IP] | Display/Set the network mask. |- |} == Port I/O == {| border='1' | ''Command syntax'' | ''Short description'' |- | io get ddr PORTNUM | Display the current value of the DDR PORTNUM. |- | io get mask PORTNUM | Display the mask of the port PORTNUM. |- | io get pin PORTNUM | Display the current value of the PIN-register of the port PORTNUM. |- | io get port NUM | Display the current value of the PORT NUM. |- | io set ddr PORTNUM HEXVALUE [MASK] | Set the DDR of port PORTNUM to VALUE (possibly using the provided MASK). |- | io set port NUM HEXVALUE [MASK] | Set the PORT NUM to VALUE (possibly using the provided MASK). |- |} == Reading and Writing EEPROM Space on Device == {| border='1' | ''Command syntax'' | ''Short description'' |- | eer eer <ADDR> <LENGTH> | Read n bytes from address after the config in eeprom. |- | eew eew <ADDR> <HEXBYTES> | Write Hexbytes at address after the config in epprom. |- | fuse | Display current fuse settings |- | hostname | Display hostname. |- |} == Resetting the controller == {| border='1' | ''Command syntax'' | ''Short description'' |- | bootloader | Call the bootloader. |- | reset | Reset the Ethersex. |- | wdreset | Go into endless loop to trigger a watchdog timeout. |- |} == [[ADS]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | adc get | Get the ADC value in hex. |- | adc mean [COUNT] | Get the mean of power of 2 COUNT ADC values in hex. |- |} == [[Am_Puls_der_Zeit|Clock]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | date | Print the current date. |- | lastdcf | Print when last valid DCF signal was received. |- | time [UNIXTIME] | Display/Set the current time in seconds since January 1st 1970. |- | uptime | Display ethersex uptime in unix format. |- | whm | Display ethersex uptime. |- |} == [[Application_Sample]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sample | Manually call application sample commands |- | sample_init | Manually call application sample init method |- | sample_periodic | Manually call application sample periodic method |- |} == [[Blinkenlights_MCUF|MCUF]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | mcuf modul N | Select module N |- | mcuf modul list | List all modules |- | mcuf showclock | Show digital clock |- | mcuf showstring MESSAGE | Show scrolling MESSAGE on the display |- |} == [[CRC]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | crc calc | "read the ethersex program code and calc a crc16 of it" |- | crc read | "read out the crc16 value at the end of the program space" |- |} == [[CRON-Dienst]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | cron_add MIN HOUR DAY MONTH DOW ECMD | Add ECMD to cron to be executed at given time |- | cron_list | Show all cron entries |- | cron_make_persistent | Mark a Job as persistent |- | cron_rm POSITION | Remove one cron entry |- | cron_save | Saves all persistent jobs |- |} == [[DALI]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dali cmd [TARGET] [COMMAND] [!][?] | "send the given command (decimal) to targets (all, g00 to g15, s00 to s63), auto repeat with !, read reply with ?" |- | dali dim [TARGET] [LEVEL] | "dim targets (all, g00 to g15, s00 to s63) to given level (0-254)" |- | dali raw [BYTE1] [BYTE2] | "send a raw frame (two bytes, given in hex) over the DALI bus" |- | dali scmd [SPECIAL COMMAND] [DATA] [!][?] | "send special command (256-287) with data, auto repeat with !, read reply with ?" |- |} == [[DMX_FXSlot]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx fxslot devices | set the device settings |- | dmx fxslot effect | set the effect settings |- | dmx fxslot reset | reset all fxslots and clear saved ones in EEPROM |- | dmx fxslot restore | restore the settings from EEPROM |- | dmx fxslot save | save the current fxslots to EEPROM |- |} == [[DMX_Storage]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx channels | Get channels per universe |- | dmx get | Return channel value |- | dmx set | Set channel values |- | dmx universe | Get a whole universe |- | dmx universes | Get universes |- |} == [[Dallas_1-wire_Bus]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | 1w convert [DEVICE] | Trigger temperature conversion of either DEVICE or all connected devices |- | 1w ds2450 convert [DEVICE] | `start conversion (with optional input mask and read out control)' |- | 1w ds2450 get [DEVICE] | `get conversion result (one or all channels)' |- | 1w ds2450 oc [DEVICE] | `get/set output control (per channel)' |- | 1w ds2450 oe [DEVICE] | `get/set output enable (per channel)' |- | 1w ds2450 por [DEVICE] | `get/set power on reset (per channel)' |- | 1w ds2450 power [DEVICE] | `get/set power supply of device (global)' |- | 1w ds2450 range [DEVICE] | `get/set input voltage range (per channel)' |- | 1w ds2450 res [DEVICE] | `get/set bit resolution of AD convert (per channel)' |- | 1w get DEVICE | Return temperature value of onewire DEVICE (provide 64-bit ID as 16-hex-digits) |- | 1w list | Return a list of the connected onewire devices |- |} == [[DataFlash]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | df status | Display internal status. |- | fs format | Format the filesystem. |- | fs inspect inode INODE | Inspect INODE (and associated page). |- | fs inspect node NODE | Inspect NODE and dump to serial. |- | fs list | List the directory. |- | fs mkfile NAME | Create a new file NAME. |- | fs remove NAME | Delete the file NAME. |- | fs truncate NAME LEN | Truncate the file NAME to LEN bytes. |- |} == [[Dc3840_camera|DC3840 mobil camera support]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dc3840 capture | Take a picture. Access 'dc3840' via VFS afterwards. See [[DC3840 Camera]] for details. |- | dc3840 light | Light level of camera |- | dc3840 send A B C D E | Send provided command bytes to the camera. |- | dc3840 sync | Re-sync to the camera |- | dc3840 zoom | Enable zoom of camera |- |} == [[ECMDScript]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | call FILENAME | Start script named FILENAME |- | cat FILENAME | cat file content (with debug only) |- | dec VAR | Decrement variable VAR (a number) |- | echo <any> | Print out all arguments of echo |- | exit | Exit currently running script |- | get VAR | Get value of variable VAR |- | goto N | Goto line N in currently running script |- | if ( CMD/VAR == CONST ) then CMD2 | If condition matches execute CMD2 |- | inc VAR | Increment variable VAR (a number) |- | rem <any> | Remark for anything |- | set VAR VALUE | Set variable VAR to VALUE |- | wait I | Wait I milliseconds |- |} == [[FS20]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fht send HOUSECODE ADDR CMD [CMD2] | Send FHT command. See [[FS20]] for details. |- | fs20 receive | Receive FS20/FHT sequence and display it. |- | fs20 send HOUSECODE ADDR CMD [CMD2] | Send FS20 command. See [[FS20]] for details. |- | fs20 ws300 | Receive FS20 sequence from WS300 weather station and decode it. |- |} == [[Frequency Counter]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fc %duty [CHANNEL] | "returns last on duty cycle in percent for given channel" |- | fc duty [CHANNEL] | "returns last on duty cycle (0-255) for given channel" |- | fc freq [CHANNEL] | "returns last frequency in Hz for given channel" |- | fc off [CHANNEL] | "switch off frequency counting on given channel" |- | fc on [CHANNEL] | "switch on frequency counting on given channel" |- | fc ticks [CHANNEL] | "returns last frequency in CPU ticks for given channel" |- |} == [[GLCD_Menu]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | glcdmenu key VALUE | Send a keypress to the menu |- | glcdmenu update | Update the menu |- |} == [[GPS]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | nmea get | Get latitude and longitude data |- | nmea satellites | Get satellites |- |} == [[H-Bridge]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | hbridge [action] [enable_l] [enable_r] | Set H-Bridge command |- | hbridge pwm int | Set H-Bridge enable line valueeg. speed |- |} == [[I2C]] (TWI) == {| border='1' | ''Command syntax'' | ''Short description'' |- | bmp085 apress | Get absolute pressure in Pa |- | bmp085 height PRESSNN | Get height in cm, pressure at N0 needed |- | bmp085 pressnn HEIGHT | Get pressure at N0, height in cm needed |- | bmp085 temp | Get temperature in 0.1°C |- | ds1631 convert ADDR VALUE | Initiate temperature conversions (0: stop, 1: convert) |- | ds1631 temp ADDR | Read last converted temperature |- | i2c detect | list detected I2C Chips |- | i2c rbb ADDR | read byte from I2C chip |- | i2c rbd CHIPADDR REGADDR | read byte from register address at I2C chip |- | i2c rwd CHIPADDR REGADDR | read word from register address at I2C chip |- | i2c wbb ADDR HEXVALUE | write byte to I2C chip |- | i2c wbd CHIPADDR REGADDR HEXVALUE | write byte to register address on I2C chip |- | i2c wwd CHIPADDR REGADDR HEXVALUE | write word to register address on I2C chip |- | lm75 ADDR | Get temperature |- | max7311 getDDRw ADDR | Get Direction-Register DDR |- | max7311 getINw ADDR | Get Input-Register IN |- | max7311 getOUTw ADDR | Get Output-Register OUT |- | max7311 pulse ADDR BIT TIME | Toggle Output-BIT for TIME (in ms) |- | max7311 set ADDR BIT VALUE | Set Output-BIT to VALUE (bool) |- | max7311 setDDRw ADDR VALUE | Set Direction-Register DDR (VALUE as hex) |- | max7311 setOUTw ADDR VALUE | Set Output-Register OUT (VALUE as hex) |- | pca9531 ADDR PERIODPWM1 DUTYPWM1 PERIODPWM2 DUTYPWM2 LED0..3 LED4..7 | set PWM1 and PWM2 and LED states |- | pca9685m ADDR | OUTDRV, IVRT, PRESCALE |- | pca9685s ADDR | LED, ON, OFF |- | pcf8574x read ADDR CHIP | Get bits |- | pcf8574x set ADDR CHIP HEXVALUE | Set bits |- | tsl2550 lux | Show light level by reading adc registers and computing level |- | tsl2550 mode VALUE | Set the TSL2550s operating mode (0: standard range, 1: extended range) |- | tsl2550 power VALUE | Set the TSL2550s power state (0: down, 1:up) |- |} == [[Jabber]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | jabber_host [HOSTNAME] | JABBER hostname |- | jabber_pass [PASSWORD] | JABBER password |- | jabber_resrc [RESOURCE] | JABBER resource |- | jabber_user [USERNAME] | JABBER username |- |} == [[KTY]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | kty autocalibrate CHANNEL | Calibrate to 1000 Ohm precision Resistor. |- | kty cal get | Return the calibration difference to 2k2 Resistor. |- | kty get [CHANNEL] | Get the temperature in xxx.x °C of CHANNEL or if no channel set of all channels. |- |} == [[MotorCurtain]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | curtain VALUE | Set value of curtain. 0=closed..7=open. If you use fewer sensors, use the corrent value instead of 7. |- | curtainlast | Return last known position |- | curtainmax | Return maximum position |- | curtainoff | Switch motor off |- |} == [[Named_PIN]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | pin get NAME | Read and display the status of pin NAME. |- | pin list | List all known named-pins. |- | pin set NAME STATUS | Set the status of pin NAME to STATUS. |- | pin toggle NAME | Toggle the status of pin NAME. |- |} == [[PWM]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dtmf CHARS | send CHARS as DTMF |- | freq set FREQUENCY DELAY | Set frequency for DELAY ms |- | pwm fade [channel +-diff startvalue] | Set fading at channel with startvalue and change each stepp to diff (must be signed 3 digit) |- | pwm set [channel value] | Set channel to value |- |} == [[RFM12]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | rfm12 reinit | Re-initialize RFM12 module. |- | rfm12 setbandwidth BW | Set RX bandwidth to BW. |- | rfm12 setbaud BAUD | Set baudrate to BAUD. |- | rfm12 setdrssi DRSSI | Set the drssi to DRSSI. |- | rfm12 setgain GAIN | Set preamplifier gain to GAIN. |- | rfm12 setmod MOD | Set modulation to MOD. |- | rfm12 status | Display internal status. |- |} == [[RFM12_ASK]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | rfm12 1527 | housecodeCommand delay cnt |- | rfm12 2272 | housecodeCommand delay cnt |- | rfm12 ask sense | Trigger (Tevion) ASK sensing. Enable ext. filter pin before! |- | rfm12 external filter [1] | Enable ext. filter pin if argument is present (disable otherwise) |- | rfm12 intertechno | family group device command |- | rfm12 tevion | housecode command delay cnt |- |} == [[RFM12_FS20]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fht send | housecode addr command data |- | fs20 send | housecode addr command data |- |} == [[SD-Karte]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sd dir | List contents of current SD directory. |- | sd mkdir PATH | Create directory hierarchy PATH. |- |} == [[SHT]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sht humid | Return humidity of SHT sensor |- | sht raw | Return raw hex temp (first line) and humidity value (second line) of SHT sensor |- | sht temp | Return temperature of SHT sensor |- |} == [[SMS77]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sms77 MESSAGE | Send MESSAGE to compiled in sms77 service |- | sms77_pass [PASSWORD] | SMS77 password |- | sms77_recv [RECEIVER] | SMS receiver |- | sms77_type [TYPE] | SMS type |- | sms77_user [USERNAME] | SMS77 username |- |} == [[Servo_Ansteuerung|PWM Servo Control]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | pwm servo_dec SERVONR | Decrement position of servo SERVONR |- | pwm servo_inc SERVONR | Increment position of servo SERVONR |- | pwm servo_set SERVONR POSITION | Set servo with SERVONR to POSITION |- |} == [[Sound]]/WAV support == {| border='1' | ''Command syntax'' | ''Short description'' |- | pwm stop | Stop wav |- | pwm wav <FILENAME> | Play wave file. Use VFS if compiled in. More details at [[Sound]] |- |} == [[Stella_Light]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | channel CHANNEL VALUE FUNCTION | Get/Set stella channel to value. Second and third parameters are optional. Function: You may use 's' for instant set, 'f' for fade and 'y' for flashy fade. |- | channels | Return stella channel size |- | fadestep FADESTEP | Get/Set stella fade step |- | stella load | Load values from eeprom |- | stella store | Store values in eeprom |- |} == [[USB]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | keyboard MESSAGE | Send MESSAGE as HID keyboard |- | mouse BUTTON DELTAX DELTAY | Send data as HID mouse |- |} == [[ZACwire]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | zac 306 PORT BIT | Return temperature of TSic 306 at BIT of PORT |- | zac 506 PORT BIT | Return temperature of TSic 506 at BIT of PORT |- | zac raw PORT BIT | Return raw hex temperature value of zacwire at BIT of PORT |- |} == lome6 == {| border='1' | ''Command syntax'' | ''Short description'' |- | lome6 get_t TYPE | get temperature command |- | lome6 power TYPE | press power command |- | lome6 reset | press reset command |- | lome6 set_t TYPE TEMPERATURE | set temperature command |- | lome6 state | get state command |- | lome6 uptime UPTIME | set/get uptime command |- |} == Miscelleanous == {| border='1' | ''Command syntax'' | ''Short description'' |- | alias list | List all available aliases |- | artnet test | artnet test |- | cw send MESSAGE | Send MESSAGE in Morce Code |- | d ADDR | Dump the memory at ADDR (16 bytes). |- | eeprom reinit | Force reinitialization of the EEPROM config area |- | free | Display free space. |- | help | List which commands are available. |- | ht MESSAGE | Send MESSAGE to compiled in httplog service |- | ipstats | Display IP statistics. |- | mb recv | Receive data from modbus |- | moodlight CHANNEL ONOFF | Set CHANNEL moodlight on=1 or off=0. If no channel is given return on if channel CHANNEL is moodlighted |- | motd [MESSAGE] | Save MESSAGE as new message of the day, otherwise just show current message |- | msr1 get | Get data |- | mysql query QUERY | Send specified MySQL query to the configured server |- | ns | update net statistic for public anouncment of currently running ethersex |- | pam USER PASSWORD | Use pam for user and password |- | push NUMBER | Push button identified by NUMBER |- | pwm melody [NUMBER] | Play melody |- | sanyoz700 CMD | Send command to projector |- | sll get | Request the logged data |- | sram memtest | Perform a memory test |- | srf05 | Read SRF05 measurement |- | to1 get | Request data from sensor |- | tw MESSAGE | Send MESSAGE to compiled in twitter service |- | upnp send | Manually send UPnP broadcast packet |- | usart baud BAUD | Set the USART baudrate to BAUD. |- | version | Display the version number. |- | wol MAC | Send WAKE-ON-LAN command to MAC |- | yport stats | Report statistic counters |- | zbus stats | Report statistic counters |- |} [[Category:Ethersex]] [[Category:ECMD]] 638714522a0e66d5350109173d81a4572a552fc0 806 744 2012-08-02T08:50:59Z CarolMcneil 703 wikitext text/x-wiki <div class="errorbox"> This page is automatically generated from the files in the Ethersex source code repository. Do not edit this page but send [[patches]] for those files! </div> __NOTOC__ == Analog/Digital Conversion ([[ADC]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | adc get [CHANNEL] | Get the ADC value in hex of CHANNEL or if no channel set of all channels. |- | hr20 temp | Read HR20 temperature sensor. |- |} == DNS Resolver == {| border='1' | ''Command syntax'' | ''Short description'' |- | dns server [IPADDR] | Display/Set the IP address of the DNS server to use to IPADDR. |- | nslookup HOSTNAME | Do DNS lookup for HOSTNAME (call twice). |- |} == Digital/Analog Conversion ([[DAC]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ltc1257_delay `[VALUE] | Set (if VALUE given) or get (no VALUE) delay for LTC1257 output bit changes in µs' |- | ltc1257_set `[VALUE0] [VALUE1] ... | Set output to value (value: 0-4095)' |- | tlc5620 `[CHANNEL] [VALUE] | Set Output to value (Value: 0-0xff)' |- |} == Fnordlicht == {| border='1' | ''Command syntax'' | ''Short description'' |- | fnordlicht "ADDRESS RED | GREEN,BLUE",fnordlicht command to set RGB color |- | fnordlicht_init | fnordlicht init |- |} == HD44780 [[LCD]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | hr20 hourbar START STOP | Update hourbar to show ticks between START and STOP (range 0..23) |- | hr20 toggle SEG | Toggle segment SEG (a number, not a symbolic name!) |- | lcd backlight STATE | switch back light STATE to ON or OFF |- | lcd char N D1 D2 D3 D4 D5 D6 D7 D8 | Define use-definable char N with data D1..D8 (provide DATA in hex) |- | lcd clear [LINE] | Clear line LINE (0..3) or the whole display (if parameter is omitted) |- | lcd goto LINE COL | Move cursor to LINE and column COL (origin is 0/0) |- | lcd reinit CURSOR BLINK | Reinitialize the display, set whether to show the cursor (CURSOR, 0 or 1) and whether the cursor shall BLINK |- | lcd shift DIR | Shift the display to DIR (either ''left'' or ''right'') |- | lcd write TEXT | Write TEXT to the current cursor location |- |} == Infrared Send/Receive ([[IR-TRX]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ir receive | receive an IR command |- | ir send DEVICE COMMAND | send COMMAND to DEVICE |- |} == Infrared Send/Receive ([[IRMP]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | irmp receive | receive an IR command |- | irmp send PROTOCOL DEVICE COMMAND REPEAT | send COMMAND with REPEAT flag to DEVICE using PROTOCOL |- |} == NTP Client == {| border='1' | ''Command syntax'' | ''Short description'' |- | ntp query | Query the NTP server to get an NTP update. |- | ntp server [IPADDR] | Display/Set the IP address of the NTP server to use to IPADDR. |- | ntp status | Display NTP server status |- |} == Network configuration == {| border='1' | ''Command syntax'' | ''Short description'' |- | enc dump | Dump the internal state of the enc to serial |- | gw [IP] | Display/Set the address of the default router. |- | ip [IP] | Display/Set the IP address. |- | mac [xx:xx:xx:xx:xx:xx] | Display/Set the MAC address. |- | netmask [IP] | Display/Set the network mask. |- |} == Port I/O == {| border='1' | ''Command syntax'' | ''Short description'' |- | io get ddr PORTNUM | Display the current value of the DDR PORTNUM. |- | io get mask PORTNUM | Display the mask of the port PORTNUM. |- | io get pin PORTNUM | Display the current value of the PIN-register of the port PORTNUM. |- | io get port NUM | Display the current value of the PORT NUM. |- | io set ddr PORTNUM HEXVALUE [MASK] | Set the DDR of port PORTNUM to VALUE (possibly using the provided MASK). |- | io set port NUM HEXVALUE [MASK] | Set the PORT NUM to VALUE (possibly using the provided MASK). |- |} == Reading and Writing EEPROM Space on Device == {| border='1' | ''Command syntax'' | ''Short description'' |- | eer eer <ADDR> <LENGTH> | Read n bytes from address after the config in eeprom. |- | eew eew <ADDR> <HEXBYTES> | Write Hexbytes at address after the config in epprom. |- | fuse | Display current fuse settings |- | hostname | Display hostname. |- |} == Resetting the controller == {| border='1' | ''Command syntax'' | ''Short description'' |- | bootloader | Call the bootloader. |- | reset | Reset the Ethersex. |- | wdreset | Go into endless loop to trigger a watchdog timeout. |- |} == [[ADS]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | adc get | Get the ADC value in hex. |- | adc mean [COUNT] | Get the mean of power of 2 COUNT ADC values in hex. |- |} == [[Am_Puls_der_Zeit|Clock]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | date | Print the current date. |- | lastdcf | Print when last valid DCF signal was received. |- | time [UNIXTIME] | Display/Set the current time in seconds since January 1st 1970. |- | uptime | Display ethersex uptime in unix format. |- | whm | Display ethersex uptime. |- |} == [[Application_Sample]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sample | Manually call application sample commands |- | sample_init | Manually call application sample init method |- | sample_periodic | Manually call application sample periodic method |- |} == [[Blinkenlights_MCUF|MCUF]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | mcuf modul N | Select module N |- | mcuf modul list | List all modules |- | mcuf showclock | Show digital clock |- | mcuf showstring MESSAGE | Show scrolling MESSAGE on the display |- |} == [[CRC]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | crc calc | "read the ethersex program code and calc a crc16 of it" |- | crc read | "read out the crc16 value at the end of the program space" |- |} == [[CRON-Dienst]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | cron_add MIN HOUR DAY MONTH DOW ECMD | Add ECMD to cron to be executed at given time |- | cron_list | Show all cron entries |- | cron_make_persistent | Mark a Job as persistent |- | cron_rm POSITION | Remove one cron entry |- | cron_save | Saves all persistent jobs |- |} == [[DALI]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dali cmd [TARGET] [COMMAND] [!][?] | "send the given command (decimal) to targets (all, g00 to g15, s00 to s63), auto repeat with !, read reply with ?" |- | dali dim [TARGET] [LEVEL] | "dim targets (all, g00 to g15, s00 to s63) to given level (0-254)" |- | dali raw [BYTE1] [BYTE2] | "send a raw frame (two bytes, given in hex) over the DALI bus" |- | dali scmd [SPECIAL COMMAND] [DATA] [!][?] | "send special command (256-287) with data, auto repeat with !, read reply with ?" |- |} == [[DMX_FXSlot]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx fxslot devices | set the device settings |- | dmx fxslot effect | set the effect settings |- | dmx fxslot reset | reset all fxslots and clear saved ones in EEPROM |- | dmx fxslot restore | restore the settings from EEPROM |- | dmx fxslot save | save the current fxslots to EEPROM |- |} == [[DMX_Storage]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx channels | Get channels per universe |- | dmx get | Return channel value |- | dmx set | Set channel values |- | dmx universe | Get a whole universe |- | dmx universes | Get universes |- |} == [[Dallas_1-wire_Bus]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | 1w convert [DEVICE] | Trigger temperature conversion of either DEVICE or all connected devices |- | 1w ds2450 convert [DEVICE] | `start conversion (with optional input mask and read out control)' |- | 1w ds2450 get [DEVICE] | `get conversion result (one or all channels)' |- | 1w ds2450 oc [DEVICE] | `get/set output control (per channel)' |- | 1w ds2450 oe [DEVICE] | `get/set output enable (per channel)' |- | 1w ds2450 por [DEVICE] | `get/set power on reset (per channel)' |- | 1w ds2450 power [DEVICE] | `get/set power supply of device (global)' |- | 1w ds2450 range [DEVICE] | `get/set input voltage range (per channel)' |- | 1w ds2450 res [DEVICE] | `get/set bit resolution of AD convert (per channel)' |- | 1w get DEVICE | Return temperature value of onewire DEVICE (provide 64-bit ID as 16-hex-digits) |- | 1w list | Return a list of the connected onewire devices |- |} == [[DataFlash]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | df status | Display internal status. |- | fs format | Format the filesystem. |- | fs inspect inode INODE | Inspect INODE (and associated page). |- | fs inspect node NODE | Inspect NODE and dump to serial. |- | fs list | List the directory. |- | fs mkfile NAME | Create a new file NAME. |- | fs remove NAME | Delete the file NAME. |- | fs truncate NAME LEN | Truncate the file NAME to LEN bytes. |- |} == [[Dc3840_camera|DC3840 mobil camera support]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dc3840 capture | Take a picture. Access 'dc3840' via VFS afterwards. See [[DC3840 Camera]] for details. |- | dc3840 light | Light level of camera |- | dc3840 send A B C D E | Send provided command bytes to the camera. |- | dc3840 sync | Re-sync to the camera |- | dc3840 zoom | Enable zoom of camera |- |} == [[ECMDScript]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | call FILENAME | Start script named FILENAME |- | cat FILENAME | cat file content (with debug only) |- | dec VAR | Decrement variable VAR (a number) |- | echo <any> | Print out all arguments of echo |- | exit | Exit currently running script |- | get VAR | Get value of variable VAR |- | goto N | Goto line N in currently running script |- | if ( CMD/VAR == CONST ) then CMD2 | If condition matches execute CMD2 |- | inc VAR | Increment variable VAR (a number) |- | rem <any> | Remark for anything |- | set VAR VALUE | Set variable VAR to VALUE |- | wait I | Wait I milliseconds |- |} == [[FS20]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fht send HOUSECODE ADDR CMD [CMD2] | Send FHT command. See [[FS20]] for details. |- | fs20 receive | Receive FS20/FHT sequence and display it. |- | fs20 send HOUSECODE ADDR CMD [CMD2] | Send FS20 command. Paper written by the experienced [http://supremeessays.com essay writer] could give students a possibility to reach highest grades. See [[FS20]] for details. |- | fs20 ws300 | Receive FS20 sequence from WS300 weather station and decode it. |- |} == [[Frequency Counter]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fc %duty [CHANNEL] | "returns last on duty cycle in percent for given channel" |- | fc duty [CHANNEL] | "returns last on duty cycle (0-255) for given channel" |- | fc freq [CHANNEL] | "returns last frequency in Hz for given channel" |- | fc off [CHANNEL] | "switch off frequency counting on given channel" |- | fc on [CHANNEL] | "switch on frequency counting on given channel" |- | fc ticks [CHANNEL] | "returns last frequency in CPU ticks for given channel" |- |} == [[GLCD_Menu]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | glcdmenu key VALUE | Send a keypress to the menu |- | glcdmenu update | Update the menu |- |} == [[GPS]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | nmea get | Get latitude and longitude data |- | nmea satellites | Get satellites |- |} == [[H-Bridge]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | hbridge [action] [enable_l] [enable_r] | Set H-Bridge command |- | hbridge pwm int | Set H-Bridge enable line valueeg. speed |- |} == [[I2C]] (TWI) == {| border='1' | ''Command syntax'' | ''Short description'' |- | bmp085 apress | Get absolute pressure in Pa |- | bmp085 height PRESSNN | Get height in cm, pressure at N0 needed |- | bmp085 pressnn HEIGHT | Get pressure at N0, height in cm needed |- | bmp085 temp | Get temperature in 0.1°C |- | ds1631 convert ADDR VALUE | Initiate temperature conversions (0: stop, 1: convert) |- | ds1631 temp ADDR | Read last converted temperature |- | i2c detect | list detected I2C Chips |- | i2c rbb ADDR | read byte from I2C chip |- | i2c rbd CHIPADDR REGADDR | read byte from register address at I2C chip |- | i2c rwd CHIPADDR REGADDR | read word from register address at I2C chip |- | i2c wbb ADDR HEXVALUE | write byte to I2C chip |- | i2c wbd CHIPADDR REGADDR HEXVALUE | write byte to register address on I2C chip |- | i2c wwd CHIPADDR REGADDR HEXVALUE | write word to register address on I2C chip |- | lm75 ADDR | Get temperature |- | max7311 getDDRw ADDR | Get Direction-Register DDR |- | max7311 getINw ADDR | Get Input-Register IN |- | max7311 getOUTw ADDR | Get Output-Register OUT |- | max7311 pulse ADDR BIT TIME | Toggle Output-BIT for TIME (in ms) |- | max7311 set ADDR BIT VALUE | Set Output-BIT to VALUE (bool) |- | max7311 setDDRw ADDR VALUE | Set Direction-Register DDR (VALUE as hex) |- | max7311 setOUTw ADDR VALUE | Set Output-Register OUT (VALUE as hex) |- | pca9531 ADDR PERIODPWM1 DUTYPWM1 PERIODPWM2 DUTYPWM2 LED0..3 LED4..7 | set PWM1 and PWM2 and LED states |- | pca9685m ADDR | OUTDRV, IVRT, PRESCALE |- | pca9685s ADDR | LED, ON, OFF |- | pcf8574x read ADDR CHIP | Get bits |- | pcf8574x set ADDR CHIP HEXVALUE | Set bits |- | tsl2550 lux | Show light level by reading adc registers and computing level |- | tsl2550 mode VALUE | Set the TSL2550s operating mode (0: standard range, 1: extended range) |- | tsl2550 power VALUE | Set the TSL2550s power state (0: down, 1:up) |- |} == [[Jabber]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | jabber_host [HOSTNAME] | JABBER hostname |- | jabber_pass [PASSWORD] | JABBER password |- | jabber_resrc [RESOURCE] | JABBER resource |- | jabber_user [USERNAME] | JABBER username |- |} == [[KTY]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | kty autocalibrate CHANNEL | Calibrate to 1000 Ohm precision Resistor. |- | kty cal get | Return the calibration difference to 2k2 Resistor. |- | kty get [CHANNEL] | Get the temperature in xxx.x °C of CHANNEL or if no channel set of all channels. |- |} == [[MotorCurtain]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | curtain VALUE | Set value of curtain. 0=closed..7=open. If you use fewer sensors, use the corrent value instead of 7. |- | curtainlast | Return last known position |- | curtainmax | Return maximum position |- | curtainoff | Switch motor off |- |} == [[Named_PIN]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | pin get NAME | Read and display the status of pin NAME. |- | pin list | List all known named-pins. |- | pin set NAME STATUS | Set the status of pin NAME to STATUS. |- | pin toggle NAME | Toggle the status of pin NAME. |- |} == [[PWM]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dtmf CHARS | send CHARS as DTMF |- | freq set FREQUENCY DELAY | Set frequency for DELAY ms |- | pwm fade [channel +-diff startvalue] | Set fading at channel with startvalue and change each stepp to diff (must be signed 3 digit) |- | pwm set [channel value] | Set channel to value |- |} == [[RFM12]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | rfm12 reinit | Re-initialize RFM12 module. |- | rfm12 setbandwidth BW | Set RX bandwidth to BW. |- | rfm12 setbaud BAUD | Set baudrate to BAUD. |- | rfm12 setdrssi DRSSI | Set the drssi to DRSSI. |- | rfm12 setgain GAIN | Set preamplifier gain to GAIN. |- | rfm12 setmod MOD | Set modulation to MOD. |- | rfm12 status | Display internal status. |- |} == [[RFM12_ASK]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | rfm12 1527 | housecodeCommand delay cnt |- | rfm12 2272 | housecodeCommand delay cnt |- | rfm12 ask sense | Trigger (Tevion) ASK sensing. Enable ext. filter pin before! |- | rfm12 external filter [1] | Enable ext. filter pin if argument is present (disable otherwise) |- | rfm12 intertechno | family group device command |- | rfm12 tevion | housecode command delay cnt |- |} == [[RFM12_FS20]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fht send | housecode addr command data |- | fs20 send | housecode addr command data |- |} == [[SD-Karte]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sd dir | List contents of current SD directory. |- | sd mkdir PATH | Create directory hierarchy PATH. |- |} == [[SHT]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sht humid | Return humidity of SHT sensor |- | sht raw | Return raw hex temp (first line) and humidity value (second line) of SHT sensor |- | sht temp | Return temperature of SHT sensor |- |} == [[SMS77]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sms77 MESSAGE | Send MESSAGE to compiled in sms77 service |- | sms77_pass [PASSWORD] | SMS77 password |- | sms77_recv [RECEIVER] | SMS receiver |- | sms77_type [TYPE] | SMS type |- | sms77_user [USERNAME] | SMS77 username |- |} == [[Servo_Ansteuerung|PWM Servo Control]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | pwm servo_dec SERVONR | Decrement position of servo SERVONR |- | pwm servo_inc SERVONR | Increment position of servo SERVONR |- | pwm servo_set SERVONR POSITION | Set servo with SERVONR to POSITION |- |} == [[Sound]]/WAV support == {| border='1' | ''Command syntax'' | ''Short description'' |- | pwm stop | Stop wav |- | pwm wav <FILENAME> | Play wave file. Use VFS if compiled in. More details at [[Sound]] |- |} == [[Stella_Light]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | channel CHANNEL VALUE FUNCTION | Get/Set stella channel to value. Second and third parameters are optional. Function: You may use 's' for instant set, 'f' for fade and 'y' for flashy fade. |- | channels | Return stella channel size |- | fadestep FADESTEP | Get/Set stella fade step |- | stella load | Load values from eeprom |- | stella store | Store values in eeprom |- |} == [[USB]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | keyboard MESSAGE | Send MESSAGE as HID keyboard |- | mouse BUTTON DELTAX DELTAY | Send data as HID mouse |- |} == [[ZACwire]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | zac 306 PORT BIT | Return temperature of TSic 306 at BIT of PORT |- | zac 506 PORT BIT | Return temperature of TSic 506 at BIT of PORT |- | zac raw PORT BIT | Return raw hex temperature value of zacwire at BIT of PORT |- |} == lome6 == {| border='1' | ''Command syntax'' | ''Short description'' |- | lome6 get_t TYPE | get temperature command |- | lome6 power TYPE | press power command |- | lome6 reset | press reset command |- | lome6 set_t TYPE TEMPERATURE | set temperature command |- | lome6 state | get state command |- | lome6 uptime UPTIME | set/get uptime command |- |} == Miscelleanous == {| border='1' | ''Command syntax'' | ''Short description'' |- | alias list | List all available aliases |- | artnet test | artnet test |- | cw send MESSAGE | Send MESSAGE in Morce Code |- | d ADDR | Dump the memory at ADDR (16 bytes). |- | eeprom reinit | Force reinitialization of the EEPROM config area |- | free | Display free space. |- | help | List which commands are available. |- | ht MESSAGE | Send MESSAGE to compiled in httplog service |- | ipstats | Display IP statistics. |- | mb recv | Receive data from modbus |- | moodlight CHANNEL ONOFF | Set CHANNEL moodlight on=1 or off=0. If no channel is given return on if channel CHANNEL is moodlighted |- | motd [MESSAGE] | Save MESSAGE as new message of the day, otherwise just show current message |- | msr1 get | Get data |- | mysql query QUERY | Send specified MySQL query to the configured server |- | ns | update net statistic for public anouncment of currently running ethersex |- | pam USER PASSWORD | Use pam for user and password |- | push NUMBER | Push button identified by NUMBER |- | pwm melody [NUMBER] | Play melody |- | sanyoz700 CMD | Send command to projector |- | sll get | Request the logged data |- | sram memtest | Perform a memory test |- | srf05 | Read SRF05 measurement |- | to1 get | Request data from sensor |- | tw MESSAGE | Send MESSAGE to compiled in twitter service |- | upnp send | Manually send UPnP broadcast packet |- | usart baud BAUD | Set the USART baudrate to BAUD. |- | version | Display the version number. |- | wol MAC | Send WAKE-ON-LAN command to MAC |- | yport stats | Report statistic counters |- | zbus stats | Report statistic counters |- |} [[Category:Ethersex]] [[Category:ECMD]] 987bc8ab689b8d3d0ec2046ce3a13a7e6e263ecb 807 806 2012-08-02T15:42:02Z Mgue 312 Undo revision 806 by [[Special:Contributions/CarolMcneil|CarolMcneil]] ([[User talk:CarolMcneil|Talk]]) wikitext text/x-wiki <div class="errorbox"> This page is automatically generated from the files in the Ethersex source code repository. Do not edit this page but send [[patches]] for those files! </div> __NOTOC__ == Analog/Digital Conversion ([[ADC]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | adc get [CHANNEL] | Get the ADC value in hex of CHANNEL or if no channel set of all channels. |- | hr20 temp | Read HR20 temperature sensor. |- |} == DNS Resolver == {| border='1' | ''Command syntax'' | ''Short description'' |- | dns server [IPADDR] | Display/Set the IP address of the DNS server to use to IPADDR. |- | nslookup HOSTNAME | Do DNS lookup for HOSTNAME (call twice). |- |} == Digital/Analog Conversion ([[DAC]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ltc1257_delay `[VALUE] | Set (if VALUE given) or get (no VALUE) delay for LTC1257 output bit changes in µs' |- | ltc1257_set `[VALUE0] [VALUE1] ... | Set output to value (value: 0-4095)' |- | tlc5620 `[CHANNEL] [VALUE] | Set Output to value (Value: 0-0xff)' |- |} == Fnordlicht == {| border='1' | ''Command syntax'' | ''Short description'' |- | fnordlicht "ADDRESS RED | GREEN,BLUE",fnordlicht command to set RGB color |- | fnordlicht_init | fnordlicht init |- |} == HD44780 [[LCD]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | hr20 hourbar START STOP | Update hourbar to show ticks between START and STOP (range 0..23) |- | hr20 toggle SEG | Toggle segment SEG (a number, not a symbolic name!) |- | lcd backlight STATE | switch back light STATE to ON or OFF |- | lcd char N D1 D2 D3 D4 D5 D6 D7 D8 | Define use-definable char N with data D1..D8 (provide DATA in hex) |- | lcd clear [LINE] | Clear line LINE (0..3) or the whole display (if parameter is omitted) |- | lcd goto LINE COL | Move cursor to LINE and column COL (origin is 0/0) |- | lcd reinit CURSOR BLINK | Reinitialize the display, set whether to show the cursor (CURSOR, 0 or 1) and whether the cursor shall BLINK |- | lcd shift DIR | Shift the display to DIR (either ''left'' or ''right'') |- | lcd write TEXT | Write TEXT to the current cursor location |- |} == Infrared Send/Receive ([[IR-TRX]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ir receive | receive an IR command |- | ir send DEVICE COMMAND | send COMMAND to DEVICE |- |} == Infrared Send/Receive ([[IRMP]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | irmp receive | receive an IR command |- | irmp send PROTOCOL DEVICE COMMAND REPEAT | send COMMAND with REPEAT flag to DEVICE using PROTOCOL |- |} == NTP Client == {| border='1' | ''Command syntax'' | ''Short description'' |- | ntp query | Query the NTP server to get an NTP update. |- | ntp server [IPADDR] | Display/Set the IP address of the NTP server to use to IPADDR. |- | ntp status | Display NTP server status |- |} == Network configuration == {| border='1' | ''Command syntax'' | ''Short description'' |- | enc dump | Dump the internal state of the enc to serial |- | gw [IP] | Display/Set the address of the default router. |- | ip [IP] | Display/Set the IP address. |- | mac [xx:xx:xx:xx:xx:xx] | Display/Set the MAC address. |- | netmask [IP] | Display/Set the network mask. |- |} == Port I/O == {| border='1' | ''Command syntax'' | ''Short description'' |- | io get ddr PORTNUM | Display the current value of the DDR PORTNUM. |- | io get mask PORTNUM | Display the mask of the port PORTNUM. |- | io get pin PORTNUM | Display the current value of the PIN-register of the port PORTNUM. |- | io get port NUM | Display the current value of the PORT NUM. |- | io set ddr PORTNUM HEXVALUE [MASK] | Set the DDR of port PORTNUM to VALUE (possibly using the provided MASK). |- | io set port NUM HEXVALUE [MASK] | Set the PORT NUM to VALUE (possibly using the provided MASK). |- |} == Reading and Writing EEPROM Space on Device == {| border='1' | ''Command syntax'' | ''Short description'' |- | eer eer <ADDR> <LENGTH> | Read n bytes from address after the config in eeprom. |- | eew eew <ADDR> <HEXBYTES> | Write Hexbytes at address after the config in epprom. |- | fuse | Display current fuse settings |- | hostname | Display hostname. |- |} == Resetting the controller == {| border='1' | ''Command syntax'' | ''Short description'' |- | bootloader | Call the bootloader. |- | reset | Reset the Ethersex. |- | wdreset | Go into endless loop to trigger a watchdog timeout. |- |} == [[ADS]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | adc get | Get the ADC value in hex. |- | adc mean [COUNT] | Get the mean of power of 2 COUNT ADC values in hex. |- |} == [[Am_Puls_der_Zeit|Clock]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | date | Print the current date. |- | lastdcf | Print when last valid DCF signal was received. |- | time [UNIXTIME] | Display/Set the current time in seconds since January 1st 1970. |- | uptime | Display ethersex uptime in unix format. |- | whm | Display ethersex uptime. |- |} == [[Application_Sample]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sample | Manually call application sample commands |- | sample_init | Manually call application sample init method |- | sample_periodic | Manually call application sample periodic method |- |} == [[Blinkenlights_MCUF|MCUF]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | mcuf modul N | Select module N |- | mcuf modul list | List all modules |- | mcuf showclock | Show digital clock |- | mcuf showstring MESSAGE | Show scrolling MESSAGE on the display |- |} == [[CRC]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | crc calc | "read the ethersex program code and calc a crc16 of it" |- | crc read | "read out the crc16 value at the end of the program space" |- |} == [[CRON-Dienst]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | cron_add MIN HOUR DAY MONTH DOW ECMD | Add ECMD to cron to be executed at given time |- | cron_list | Show all cron entries |- | cron_make_persistent | Mark a Job as persistent |- | cron_rm POSITION | Remove one cron entry |- | cron_save | Saves all persistent jobs |- |} == [[DALI]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dali cmd [TARGET] [COMMAND] [!][?] | "send the given command (decimal) to targets (all, g00 to g15, s00 to s63), auto repeat with !, read reply with ?" |- | dali dim [TARGET] [LEVEL] | "dim targets (all, g00 to g15, s00 to s63) to given level (0-254)" |- | dali raw [BYTE1] [BYTE2] | "send a raw frame (two bytes, given in hex) over the DALI bus" |- | dali scmd [SPECIAL COMMAND] [DATA] [!][?] | "send special command (256-287) with data, auto repeat with !, read reply with ?" |- |} == [[DMX_FXSlot]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx fxslot devices | set the device settings |- | dmx fxslot effect | set the effect settings |- | dmx fxslot reset | reset all fxslots and clear saved ones in EEPROM |- | dmx fxslot restore | restore the settings from EEPROM |- | dmx fxslot save | save the current fxslots to EEPROM |- |} == [[DMX_Storage]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx channels | Get channels per universe |- | dmx get | Return channel value |- | dmx set | Set channel values |- | dmx universe | Get a whole universe |- | dmx universes | Get universes |- |} == [[Dallas_1-wire_Bus]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | 1w convert [DEVICE] | Trigger temperature conversion of either DEVICE or all connected devices |- | 1w ds2450 convert [DEVICE] | `start conversion (with optional input mask and read out control)' |- | 1w ds2450 get [DEVICE] | `get conversion result (one or all channels)' |- | 1w ds2450 oc [DEVICE] | `get/set output control (per channel)' |- | 1w ds2450 oe [DEVICE] | `get/set output enable (per channel)' |- | 1w ds2450 por [DEVICE] | `get/set power on reset (per channel)' |- | 1w ds2450 power [DEVICE] | `get/set power supply of device (global)' |- | 1w ds2450 range [DEVICE] | `get/set input voltage range (per channel)' |- | 1w ds2450 res [DEVICE] | `get/set bit resolution of AD convert (per channel)' |- | 1w get DEVICE | Return temperature value of onewire DEVICE (provide 64-bit ID as 16-hex-digits) |- | 1w list | Return a list of the connected onewire devices |- |} == [[DataFlash]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | df status | Display internal status. |- | fs format | Format the filesystem. |- | fs inspect inode INODE | Inspect INODE (and associated page). |- | fs inspect node NODE | Inspect NODE and dump to serial. |- | fs list | List the directory. |- | fs mkfile NAME | Create a new file NAME. |- | fs remove NAME | Delete the file NAME. |- | fs truncate NAME LEN | Truncate the file NAME to LEN bytes. |- |} == [[Dc3840_camera|DC3840 mobil camera support]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dc3840 capture | Take a picture. Access 'dc3840' via VFS afterwards. See [[DC3840 Camera]] for details. |- | dc3840 light | Light level of camera |- | dc3840 send A B C D E | Send provided command bytes to the camera. |- | dc3840 sync | Re-sync to the camera |- | dc3840 zoom | Enable zoom of camera |- |} == [[ECMDScript]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | call FILENAME | Start script named FILENAME |- | cat FILENAME | cat file content (with debug only) |- | dec VAR | Decrement variable VAR (a number) |- | echo <any> | Print out all arguments of echo |- | exit | Exit currently running script |- | get VAR | Get value of variable VAR |- | goto N | Goto line N in currently running script |- | if ( CMD/VAR == CONST ) then CMD2 | If condition matches execute CMD2 |- | inc VAR | Increment variable VAR (a number) |- | rem <any> | Remark for anything |- | set VAR VALUE | Set variable VAR to VALUE |- | wait I | Wait I milliseconds |- |} == [[FS20]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fht send HOUSECODE ADDR CMD [CMD2] | Send FHT command. See [[FS20]] for details. |- | fs20 receive | Receive FS20/FHT sequence and display it. |- | fs20 send HOUSECODE ADDR CMD [CMD2] | Send FS20 command. See [[FS20]] for details. |- | fs20 ws300 | Receive FS20 sequence from WS300 weather station and decode it. |- |} == [[Frequency Counter]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fc %duty [CHANNEL] | "returns last on duty cycle in percent for given channel" |- | fc duty [CHANNEL] | "returns last on duty cycle (0-255) for given channel" |- | fc freq [CHANNEL] | "returns last frequency in Hz for given channel" |- | fc off [CHANNEL] | "switch off frequency counting on given channel" |- | fc on [CHANNEL] | "switch on frequency counting on given channel" |- | fc ticks [CHANNEL] | "returns last frequency in CPU ticks for given channel" |- |} == [[GLCD_Menu]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | glcdmenu key VALUE | Send a keypress to the menu |- | glcdmenu update | Update the menu |- |} == [[GPS]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | nmea get | Get latitude and longitude data |- | nmea satellites | Get satellites |- |} == [[H-Bridge]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | hbridge [action] [enable_l] [enable_r] | Set H-Bridge command |- | hbridge pwm int | Set H-Bridge enable line valueeg. speed |- |} == [[I2C]] (TWI) == {| border='1' | ''Command syntax'' | ''Short description'' |- | bmp085 apress | Get absolute pressure in Pa |- | bmp085 height PRESSNN | Get height in cm, pressure at N0 needed |- | bmp085 pressnn HEIGHT | Get pressure at N0, height in cm needed |- | bmp085 temp | Get temperature in 0.1°C |- | ds1631 convert ADDR VALUE | Initiate temperature conversions (0: stop, 1: convert) |- | ds1631 temp ADDR | Read last converted temperature |- | i2c detect | list detected I2C Chips |- | i2c rbb ADDR | read byte from I2C chip |- | i2c rbd CHIPADDR REGADDR | read byte from register address at I2C chip |- | i2c rwd CHIPADDR REGADDR | read word from register address at I2C chip |- | i2c wbb ADDR HEXVALUE | write byte to I2C chip |- | i2c wbd CHIPADDR REGADDR HEXVALUE | write byte to register address on I2C chip |- | i2c wwd CHIPADDR REGADDR HEXVALUE | write word to register address on I2C chip |- | lm75 ADDR | Get temperature |- | max7311 getDDRw ADDR | Get Direction-Register DDR |- | max7311 getINw ADDR | Get Input-Register IN |- | max7311 getOUTw ADDR | Get Output-Register OUT |- | max7311 pulse ADDR BIT TIME | Toggle Output-BIT for TIME (in ms) |- | max7311 set ADDR BIT VALUE | Set Output-BIT to VALUE (bool) |- | max7311 setDDRw ADDR VALUE | Set Direction-Register DDR (VALUE as hex) |- | max7311 setOUTw ADDR VALUE | Set Output-Register OUT (VALUE as hex) |- | pca9531 ADDR PERIODPWM1 DUTYPWM1 PERIODPWM2 DUTYPWM2 LED0..3 LED4..7 | set PWM1 and PWM2 and LED states |- | pca9685m ADDR | OUTDRV, IVRT, PRESCALE |- | pca9685s ADDR | LED, ON, OFF |- | pcf8574x read ADDR CHIP | Get bits |- | pcf8574x set ADDR CHIP HEXVALUE | Set bits |- | tsl2550 lux | Show light level by reading adc registers and computing level |- | tsl2550 mode VALUE | Set the TSL2550s operating mode (0: standard range, 1: extended range) |- | tsl2550 power VALUE | Set the TSL2550s power state (0: down, 1:up) |- |} == [[Jabber]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | jabber_host [HOSTNAME] | JABBER hostname |- | jabber_pass [PASSWORD] | JABBER password |- | jabber_resrc [RESOURCE] | JABBER resource |- | jabber_user [USERNAME] | JABBER username |- |} == [[KTY]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | kty autocalibrate CHANNEL | Calibrate to 1000 Ohm precision Resistor. |- | kty cal get | Return the calibration difference to 2k2 Resistor. |- | kty get [CHANNEL] | Get the temperature in xxx.x °C of CHANNEL or if no channel set of all channels. |- |} == [[MotorCurtain]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | curtain VALUE | Set value of curtain. 0=closed..7=open. If you use fewer sensors, use the corrent value instead of 7. |- | curtainlast | Return last known position |- | curtainmax | Return maximum position |- | curtainoff | Switch motor off |- |} == [[Named_PIN]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | pin get NAME | Read and display the status of pin NAME. |- | pin list | List all known named-pins. |- | pin set NAME STATUS | Set the status of pin NAME to STATUS. |- | pin toggle NAME | Toggle the status of pin NAME. |- |} == [[PWM]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dtmf CHARS | send CHARS as DTMF |- | freq set FREQUENCY DELAY | Set frequency for DELAY ms |- | pwm fade [channel +-diff startvalue] | Set fading at channel with startvalue and change each stepp to diff (must be signed 3 digit) |- | pwm set [channel value] | Set channel to value |- |} == [[RFM12]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | rfm12 reinit | Re-initialize RFM12 module. |- | rfm12 setbandwidth BW | Set RX bandwidth to BW. |- | rfm12 setbaud BAUD | Set baudrate to BAUD. |- | rfm12 setdrssi DRSSI | Set the drssi to DRSSI. |- | rfm12 setgain GAIN | Set preamplifier gain to GAIN. |- | rfm12 setmod MOD | Set modulation to MOD. |- | rfm12 status | Display internal status. |- |} == [[RFM12_ASK]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | rfm12 1527 | housecodeCommand delay cnt |- | rfm12 2272 | housecodeCommand delay cnt |- | rfm12 ask sense | Trigger (Tevion) ASK sensing. Enable ext. filter pin before! |- | rfm12 external filter [1] | Enable ext. filter pin if argument is present (disable otherwise) |- | rfm12 intertechno | family group device command |- | rfm12 tevion | housecode command delay cnt |- |} == [[RFM12_FS20]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fht send | housecode addr command data |- | fs20 send | housecode addr command data |- |} == [[SD-Karte]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sd dir | List contents of current SD directory. |- | sd mkdir PATH | Create directory hierarchy PATH. |- |} == [[SHT]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sht humid | Return humidity of SHT sensor |- | sht raw | Return raw hex temp (first line) and humidity value (second line) of SHT sensor |- | sht temp | Return temperature of SHT sensor |- |} == [[SMS77]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sms77 MESSAGE | Send MESSAGE to compiled in sms77 service |- | sms77_pass [PASSWORD] | SMS77 password |- | sms77_recv [RECEIVER] | SMS receiver |- | sms77_type [TYPE] | SMS type |- | sms77_user [USERNAME] | SMS77 username |- |} == [[Servo_Ansteuerung|PWM Servo Control]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | pwm servo_dec SERVONR | Decrement position of servo SERVONR |- | pwm servo_inc SERVONR | Increment position of servo SERVONR |- | pwm servo_set SERVONR POSITION | Set servo with SERVONR to POSITION |- |} == [[Sound]]/WAV support == {| border='1' | ''Command syntax'' | ''Short description'' |- | pwm stop | Stop wav |- | pwm wav <FILENAME> | Play wave file. Use VFS if compiled in. More details at [[Sound]] |- |} == [[Stella_Light]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | channel CHANNEL VALUE FUNCTION | Get/Set stella channel to value. Second and third parameters are optional. Function: You may use 's' for instant set, 'f' for fade and 'y' for flashy fade. |- | channels | Return stella channel size |- | fadestep FADESTEP | Get/Set stella fade step |- | stella load | Load values from eeprom |- | stella store | Store values in eeprom |- |} == [[USB]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | keyboard MESSAGE | Send MESSAGE as HID keyboard |- | mouse BUTTON DELTAX DELTAY | Send data as HID mouse |- |} == [[ZACwire]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | zac 306 PORT BIT | Return temperature of TSic 306 at BIT of PORT |- | zac 506 PORT BIT | Return temperature of TSic 506 at BIT of PORT |- | zac raw PORT BIT | Return raw hex temperature value of zacwire at BIT of PORT |- |} == lome6 == {| border='1' | ''Command syntax'' | ''Short description'' |- | lome6 get_t TYPE | get temperature command |- | lome6 power TYPE | press power command |- | lome6 reset | press reset command |- | lome6 set_t TYPE TEMPERATURE | set temperature command |- | lome6 state | get state command |- | lome6 uptime UPTIME | set/get uptime command |- |} == Miscelleanous == {| border='1' | ''Command syntax'' | ''Short description'' |- | alias list | List all available aliases |- | artnet test | artnet test |- | cw send MESSAGE | Send MESSAGE in Morce Code |- | d ADDR | Dump the memory at ADDR (16 bytes). |- | eeprom reinit | Force reinitialization of the EEPROM config area |- | free | Display free space. |- | help | List which commands are available. |- | ht MESSAGE | Send MESSAGE to compiled in httplog service |- | ipstats | Display IP statistics. |- | mb recv | Receive data from modbus |- | moodlight CHANNEL ONOFF | Set CHANNEL moodlight on=1 or off=0. If no channel is given return on if channel CHANNEL is moodlighted |- | motd [MESSAGE] | Save MESSAGE as new message of the day, otherwise just show current message |- | msr1 get | Get data |- | mysql query QUERY | Send specified MySQL query to the configured server |- | ns | update net statistic for public anouncment of currently running ethersex |- | pam USER PASSWORD | Use pam for user and password |- | push NUMBER | Push button identified by NUMBER |- | pwm melody [NUMBER] | Play melody |- | sanyoz700 CMD | Send command to projector |- | sll get | Request the logged data |- | sram memtest | Perform a memory test |- | srf05 | Read SRF05 measurement |- | to1 get | Request data from sensor |- | tw MESSAGE | Send MESSAGE to compiled in twitter service |- | upnp send | Manually send UPnP broadcast packet |- | usart baud BAUD | Set the USART baudrate to BAUD. |- | version | Display the version number. |- | wol MAC | Send WAKE-ON-LAN command to MAC |- | yport stats | Report statistic counters |- | zbus stats | Report statistic counters |- |} [[Category:Ethersex]] [[Category:ECMD]] 638714522a0e66d5350109173d81a4572a552fc0 0 174 768 437 2012-07-14T12:31:16Z Sittner 461 /* SNMP support */ wikitext text/x-wiki {{i18n|Tanklevel}} {{Module |NAME=Tank level meter |MENUCONFIG={{Applications}}->Tank level meter |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]], [[Clock]], [[ADC]], [[Cron]] (optional) |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/services/tanklevel https://github.com/ethersex/ethersex/tree/master/services/tanklevel] }} Tanklevel provides an application for measurement of tank levels by hydrostatic pressure. == Internals == You need an aquarium air pump, some kind of pipe/tube, a Freescale MPX5050DP pressure sensor and an relay for the pump. Parameters are configurable by ECMD and stored in EEPROM. == Configuration == │ │ (0) ADC channel │ │ │ │ [ ] Measure on system startup │ │ │ │ [ ] Measure at 12 am and 12 pm │ │ │ │ [ ] Inverted pump output │ │ │ │ [ ] Check lock input │ │ │ │ [ ] Inverted lock input │ │ │ │ [ ] Inline tank level │ │ * ADC channel - ADC channel that is connected to the MPX5050DP pressure sensor. * Measure on system startup - Start initial measurement at system startup. * Measure at 12 am and 12 pm - Start measurement at fixed time. Can be changed in services/cron/cron_static.c. * Inverted pump output - Output pin for pump is inverted. * Check lock input - Check lock pin before measurement and wait if needed. This is used to delay the measurement e.g. if the oil burner is running. * Inverted lock input - Lock input pin is inverted. * Inline tank level - Inline a page to query the tank level. == Pinning == Example pinning from pinning/hardware/netio.m4: ifdef(`conf_TANKLEVEL', ` pin(TANKLEVEL_PUMP, PC3, OUTPUT) ') ifdef(`conf_TANKLEVEL_LOCK', ` pin(TANKLEVEL_LOCK, PA2, INPUT) ') Meaning: * TANKLEVEL_PUMP - output pin for driving the pump relay * TANKLEVEL_LOCK - optional pin for external lock signal (see Configuration) == Mechanical setup == +-------+ |Sensor | +---+---+ | +--------+ +---------------+-+ Pump | | +--------+ +------+------+ | | | | | | |------|------| | | | | | | | | | +-------------+ Tank See the following example: [[File:Tanklevel_pump_assy.jpg|Pump assembly|177px]] [[File:Tanklevel_tank_assy.jpg|Tank assembly|100px]] == Electrical setup == Electrical setup is quite simple. Connect the TANK_PUMP port with an relay (usually via an Transistor as current amp) and the output of the Sensor with the selected ADC channel (have a look at the datasheet for power supply decoupling and output filtering). Select a optimal Vref for the ADC if possible. Schematic could look like this: [[File:Tanklevel_schem.png|Electrical setup]] == Parameters == Parameters can be viewed/set by ECMD commands: * sensor_offset - zero offset of the pressure sensor in mV * med_density - medium density in g/ltr (default of 840 for fuel oil) * ltr_per_m - Ltr per meter tank level * ltr_full - Tank capacity in ltr * raise_time - Pump time (in 1/50 secs) * hold_time - Hold time before measurement (in 1/50 secs) == SNMP support == If SNMP is enabled the level can be queried by this OID's: * .1.3.6.1.4.1.39967.4.0 = INTEGER: current level in ltr * .1.3.6.1.4.1.39967.4.1 = INTEGER: tank capacity in ltr * .1.3.6.1.4.1.39967.4.2 = INTEGER: timestamp of last measurement (unix date) * .1.3.6.1.4.1.39967.4.3 = STRING: timestamp of last measurement (clear text) b406f77893c0c207ec469e01a3106c79126b150f 0 189 769 510 2012-07-14T12:32:16Z Sittner 461 /* Abfrage per SNMP */ wikitext text/x-wiki {{i18n|Onewire}} {{Module |NAME=Onewire |MENUCONFIG={{I/O}}->Onewire support |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] [[HTTPD]] (optional) [[SNMP]] (optional) |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} Ethersex kann 1-wire Temperatursensoren mit [[ECMD]] auflisten und abfragen. Es wird eine reine Softwareimplementierung des Protokolls benutzt, was keine weiteren Hardware erfordert, als die Temperatursensoren selbst. = Pinning = In der Standardkonfiguration liegt der Datapin des Buses auf PD6 (kann z.B. in der pinning/hardware/netio.m4 oder pinning/hardware/etherrape.m4 geändert werden). Die Definition der Pins erfolgt mit: <source lang=c> ONEWIRE_PORT_RANGE(PXn, PXm) </source> wobei PXn und PNm Pins auf PORTX sind. Jeder Pin zwischen und einschließlich PXn und PXm bildet einen eingenständigen Onewire Bus. Du kannst bis zu acht Busse auf einem PORT definieren (alle Busse müssen auf dem selben PORT liegen!) == Beispiele == Wenn Du nur einen einzigen Bus benötigst, definiere den Bereich wie folgt: '''PORTD: PIN2''' <source lang=c> ONEWIRE_PORT_RANGE(PD2, PD2) </source> Für drei Busse würde das ganze etwa so aussehen: '''PORTD: PIN2, PIN3, PIN4''' <source lang=c> ONEWIRE_PORT_RANGE(PD2, PD4) </source> = Polling Modus = │ │ [*] Onewire Polling │ │ │ │ (375) Time between discoveries in 0.8s steps │ │ │ │ (12) Time between polling in 0.8s steps │ │ │ │ [*] ECMD 1w list with values │ │ │ │ (10) Maximum sensor count │ │ Im Polling-Modus werden die Sensoren im Hintergrund abgefragt, so dass die Werte bei Bedarf direkt zur Verfügung stehen und nicht erst gewandelt bzw. eingelesen werden müssen. Der Intervall zwischen den Discoveries und zwischen den Abfragen der Werte kann getrennt eingestellt werden. Die Option '''ECMD 1w list with values''' bietet die Möglichkeit, die aktuellen Werte bei Aufruf von '''1w list''' mit ausgeben zu lassen. So können darauf folgende '''1w get''' Kommandos entfallen. Da zur Pufferung der Werte, ROM-Codes, etc. RAM-Speicher benötigt wird, muss per '''Maximum sensor count''' angegeben werden, für wie viele Sensoren Speicher reserviert wird. = Benennung von Sensoren = │ │ [*] Onewire naming support │ │ │ │ (10) Maximum sensor count │ │ Um den Sensoren sinnvolle Namen zu geben besteht die Möglichkeit im EEPROM eine entsprechende Zuweisungstabelle anzulegen (ROM-Code -> Name). Die Namen werden bei bei Aufruf von '''1w list''' mit ausgegeben. Dazu gibt es folgende ECMD Kommandos: 1w name list Auflistung der aktuellen Zuweisungen (Spalten: ID, ROM-Code, Name). Die ID bezeichnet die Position in der Zuweisungstabelle und kann u.a. dazu benutzt werden, Sensoren bei SNMP-Abfragen eindeutig zu referenzieren. 1w name set <ID> <ROM-Code> <Name> Erstellt einen entsprechenden Tabelleneintrag. 1w name clear <ID> Löscht die Felder eines Tabelleneintrags. 1w name save Speichert die aktuelle Tabelle im EEPROM = Unterstützte Hardware = Folgende 1-wire Hardware wird momentan durch Ethersex unterstützt: * DS1820 (Temperatursensor) * DS18B20 (Temperatursensor) * DS1822 (Temperatursensor) * DS2502 (EEPROM) * DS2450 (4 Kanal ADC) = Onewire Befehle = unter Linux als erstes netcat starten (hierbei natürlich die IP ggf modifizieren): netcat 192.168.0.15 2701 danach am prompt: 1w list Gibt eine Liste mit Hexcodes aller angeschlossenen und erkannten Onewire(tm) Sensoren aus. Bei aktiviertem Naming-Support wird (per TAB getrennt) zusätzlich der Name ausgegeben. Außerdem kann mit '''ECMD 1w list with values (ONEWIRE_ECMD_LIST_VALUE_SUPPORT)''' der aktuelle Temperaturwert mit ausgegeben werden. Dies erspart zusätzliche '''1w get''' Aufrufe, setzt allerding Polling-Support vorraus. 1w convert <hexcode> Veranlasst eine Temperaturmessung des addressierten Sensors, oder, wenn das Argument <hexcode> weggelassen wird, aller angeschlossener Sensoren. Im Polling-Modus wird dieses Kommando ignoriert. 1w get <hexcode> Gibt die gemessene Temperatur eines Sensors aus. = Einbindung in die [[HTTPD]]-Weboberfläche = Unter httpd/embed/ow.ht.m4, bzw httpd/embed/Xow.ht.m4 liegt eine Weboberflaeche, die alle Sensoren erkennt und ihre aktuelle Temperatur regelmässig per Ajax abfragt und anzeigt. Im Falle von Xow.ht.m4 wird sogar Graph der Temperatur mittels SVG gemalt. Um die Dateien einzubinden, muss man einfach bei aktiviertem Onewiresupport den Webserver und das Datei Inlining aktivieren. Die Dateien können dann unter ow.ht bzw. unter Xow.ht angezeigt werden. Das Beispiel zeigt die SVG-Version mit Naming-Support: [[File:onewire-svg.png]] = Anschluss AVR-NET-IO = Für das Pollin AVR-NET-IO Board können die Sensoren DS18S20+ , normal Betrieb [[File:netio-1wire_normal.png]] parasitären Modus [[File:netio-1wire.png]] Anmerkung: Wenn man beim Net-IO nicht alle Analogeingänge benötigt, lässt sich der 1-Wire-Bus auch an der Schraubklemme ADC1 ganz gut aufschalten. Vorteil ist, dass man gleich alle passenden Spannungen (GND, +5V) an den beiden nebenliegenden Schraubklemmen hat. Das Pinning muss dann entspechend in der kann in der Datei pinning/hardware/netio.m4 von PD6 auf PA4 geändert werden. Vorteil dieser Konfiguration ist, dass man den DB-25-Verbinder zum Anschluss der Relaisplatine K8IO von Pollin frei hat und den EXT Steckverbinder zum Anschluss eines LCD über ein 4bit-Interface nutzen kann, ohne die Erweiterungsplatine von Pollin zu benötigen. Pinbelegung: [[File:ds18s20-par-pinout.jpg]] = Anschluss Etherrape = Die Schaltung je nach parasitärem oder normalem Betriebsmodus kann aus der NetIO Skizze übernommen werden. Data liegt auf PORTD an Pin 7: PORTD +---+ |x x| |x X| <- Pin 7 |x x |x x| |x x| +---+ Direkt neben PORTD befinden sich 2 Pins mit GND und 5V als Beschriftung. GND kann als GND und 5V als Vcc genutzt werden. = Einbindung in [[Control6]] = Die Sensoren können mit '''ONEWIRE_GET''' einfach abgefragt werden. Die Funktion führt automatisch ein ''convert'' aus, es sind also keine zwei Schritte erforderlich wie bei dem Zugriff über [[ECMD]]. Die Rückgabe erfolgt (analog der Funktion '''KTY_GET''') in Centigrad, also Temperatur * 10. Hier vielleicht ein kleines Beispiel, das die Daten per [[SYSLOG]] ausgibt sobald sich die Temperatur um mehr als ein Grad zur letzten Messung verändert hat. <pre> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO div_t res = div(Temperatur,10); SYSLOG("temperature changed %d.%d",res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> = Abfrage per [[SNMP]] = Falls Polling-Support aktiviert wurde können die Sensorwerte per SNMP abgefragt werden. Mit Naming-Support stehen auch die Namen per SNMP zur Verfügung und die Index-Nummern sind fix auf die Position in der Namenstabelle festgelegt. Dies ist sehr hilfreich, um bestimmte Sensoren über den SNMP-Index anzusprechen. Es gibt folgende OIDs: * .1.3.6.1.4.1.39967.3.1.<idx> : ROM-Code des Sensors * .1.3.6.1.4.1.39967.3.2.<idx> : Sensor-Name (nur mit Naming-Support) * .1.3.6.1.4.1.39967.3.3.<idx> : Temperaturwert in Centigrad * .1.3.6.1.4.1.39967.3.4.<idx> : 0 = Sensor nicht vorhanden, 1 = Sensor vorhanden Hier ein Beispiel: <pre> # snmpwalk -Osn -c public -v 1 192.168.255.90 1.3.6.1.4.1.39967.3 .1.3.6.1.4.1.39967.3.1.0 = STRING: "1080cff6010800f9" .1.3.6.1.4.1.39967.3.1.1 = STRING: "10c8cff60108002d" .1.3.6.1.4.1.39967.3.1.2 = STRING: "1029f6dc0108002f" .1.3.6.1.4.1.39967.3.1.3 = STRING: "10f2d0f60108001c" .1.3.6.1.4.1.39967.3.1.4 = STRING: "105a17f70108001d" .1.3.6.1.4.1.39967.3.1.5 = STRING: "10b8d8f601080098" .1.3.6.1.4.1.39967.3.1.6 = STRING: "104dedf601080057" .1.3.6.1.4.1.39967.3.1.7 = STRING: "10011af701080027" .1.3.6.1.4.1.39967.3.1.8 = STRING: "0000000000000000" .1.3.6.1.4.1.39967.3.1.9 = STRING: "0000000000000000" .1.3.6.1.4.1.39967.3.2.0 = STRING: "kessel" .1.3.6.1.4.1.39967.3.2.1 = STRING: "warmwasser" .1.3.6.1.4.1.39967.3.2.2 = STRING: "aussen" .1.3.6.1.4.1.39967.3.2.3 = STRING: "speicher" .1.3.6.1.4.1.39967.3.2.4 = STRING: "heizung vl" .1.3.6.1.4.1.39967.3.2.5 = STRING: "heizung rl" .1.3.6.1.4.1.39967.3.2.6 = STRING: "boiler vl" .1.3.6.1.4.1.39967.3.2.7 = STRING: "boiler rl" .1.3.6.1.4.1.39967.3.2.8 = "" .1.3.6.1.4.1.39967.3.2.9 = "" .1.3.6.1.4.1.39967.3.3.0 = INTEGER: 334 .1.3.6.1.4.1.39967.3.3.1 = INTEGER: 467 .1.3.6.1.4.1.39967.3.3.2 = INTEGER: 127 .1.3.6.1.4.1.39967.3.3.3 = INTEGER: 185 .1.3.6.1.4.1.39967.3.3.4 = INTEGER: 318 .1.3.6.1.4.1.39967.3.3.5 = INTEGER: 269 .1.3.6.1.4.1.39967.3.3.6 = INTEGER: 366 .1.3.6.1.4.1.39967.3.3.7 = INTEGER: 291 .1.3.6.1.4.1.39967.3.3.8 = INTEGER: 0 .1.3.6.1.4.1.39967.3.3.9 = INTEGER: 0 .1.3.6.1.4.1.39967.3.4.0 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.1 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.2 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.3 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.4 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.5 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.6 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.7 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.8 = INTEGER: 0 .1.3.6.1.4.1.39967.3.4.9 = INTEGER: 0 </pre> = Codebeispiele = * [[Onewire/Example/PHP (Deutsch) | PHP]] * [[Onewire/Example/Perl (Deutsch) | Perl]] * [[Onewire/Example/Python | Python]] * [[Onewire/Example/Shell | sh/bash]] [[Category:Ethersex]] [[Category:StepByStep]] [[Category:Onewire]] = Bezugsquellen = * Laut Michael Schultz (k1w1) hat er immer DS1820 auf Lager und kann sie sehr günstig weiterverkaufen. Auch Mindermengen. Mail: ethersex [AT] keyb [DOT] de be836acf100b87c832e0fed6778142f5bea50603 789 769 2012-07-26T02:37:34Z Atos 604 /* Bezugsquellen */ wikitext text/x-wiki {{i18n|Onewire}} {{Module |NAME=Onewire |MENUCONFIG={{I/O}}->Onewire support |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] [[HTTPD]] (optional) [[SNMP]] (optional) |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} Ethersex kann 1-wire Temperatursensoren mit [[ECMD]] auflisten und abfragen. Es wird eine reine Softwareimplementierung des Protokolls benutzt, was keine weiteren Hardware erfordert, als die Temperatursensoren selbst. = Pinning = In der Standardkonfiguration liegt der Datapin des Buses auf PD6 (kann z.B. in der pinning/hardware/netio.m4 oder pinning/hardware/etherrape.m4 geändert werden). Die Definition der Pins erfolgt mit: <source lang=c> ONEWIRE_PORT_RANGE(PXn, PXm) </source> wobei PXn und PNm Pins auf PORTX sind. Jeder Pin zwischen und einschließlich PXn und PXm bildet einen eingenständigen Onewire Bus. Du kannst bis zu acht Busse auf einem PORT definieren (alle Busse müssen auf dem selben PORT liegen!) == Beispiele == Wenn Du nur einen einzigen Bus benötigst, definiere den Bereich wie folgt: '''PORTD: PIN2''' <source lang=c> ONEWIRE_PORT_RANGE(PD2, PD2) </source> Für drei Busse würde das ganze etwa so aussehen: '''PORTD: PIN2, PIN3, PIN4''' <source lang=c> ONEWIRE_PORT_RANGE(PD2, PD4) </source> = Polling Modus = │ │ [*] Onewire Polling │ │ │ │ (375) Time between discoveries in 0.8s steps │ │ │ │ (12) Time between polling in 0.8s steps │ │ │ │ [*] ECMD 1w list with values │ │ │ │ (10) Maximum sensor count │ │ Im Polling-Modus werden die Sensoren im Hintergrund abgefragt, so dass die Werte bei Bedarf direkt zur Verfügung stehen und nicht erst gewandelt bzw. eingelesen werden müssen. Der Intervall zwischen den Discoveries und zwischen den Abfragen der Werte kann getrennt eingestellt werden. Die Option '''ECMD 1w list with values''' bietet die Möglichkeit, die aktuellen Werte bei Aufruf von '''1w list''' mit ausgeben zu lassen. So können darauf folgende '''1w get''' Kommandos entfallen. Da zur Pufferung der Werte, ROM-Codes, etc. RAM-Speicher benötigt wird, muss per '''Maximum sensor count''' angegeben werden, für wie viele Sensoren Speicher reserviert wird. = Benennung von Sensoren = │ │ [*] Onewire naming support │ │ │ │ (10) Maximum sensor count │ │ Um den Sensoren sinnvolle Namen zu geben besteht die Möglichkeit im EEPROM eine entsprechende Zuweisungstabelle anzulegen (ROM-Code -> Name). Die Namen werden bei bei Aufruf von '''1w list''' mit ausgegeben. Dazu gibt es folgende ECMD Kommandos: 1w name list Auflistung der aktuellen Zuweisungen (Spalten: ID, ROM-Code, Name). Die ID bezeichnet die Position in der Zuweisungstabelle und kann u.a. dazu benutzt werden, Sensoren bei SNMP-Abfragen eindeutig zu referenzieren. 1w name set <ID> <ROM-Code> <Name> Erstellt einen entsprechenden Tabelleneintrag. 1w name clear <ID> Löscht die Felder eines Tabelleneintrags. 1w name save Speichert die aktuelle Tabelle im EEPROM = Unterstützte Hardware = Folgende 1-wire Hardware wird momentan durch Ethersex unterstützt: * DS1820 (Temperatursensor) * DS18B20 (Temperatursensor) * DS1822 (Temperatursensor) * DS2502 (EEPROM) * DS2450 (4 Kanal ADC) = Onewire Befehle = unter Linux als erstes netcat starten (hierbei natürlich die IP ggf modifizieren): netcat 192.168.0.15 2701 danach am prompt: 1w list Gibt eine Liste mit Hexcodes aller angeschlossenen und erkannten Onewire(tm) Sensoren aus. Bei aktiviertem Naming-Support wird (per TAB getrennt) zusätzlich der Name ausgegeben. Außerdem kann mit '''ECMD 1w list with values (ONEWIRE_ECMD_LIST_VALUE_SUPPORT)''' der aktuelle Temperaturwert mit ausgegeben werden. Dies erspart zusätzliche '''1w get''' Aufrufe, setzt allerding Polling-Support vorraus. 1w convert <hexcode> Veranlasst eine Temperaturmessung des addressierten Sensors, oder, wenn das Argument <hexcode> weggelassen wird, aller angeschlossener Sensoren. Im Polling-Modus wird dieses Kommando ignoriert. 1w get <hexcode> Gibt die gemessene Temperatur eines Sensors aus. = Einbindung in die [[HTTPD]]-Weboberfläche = Unter httpd/embed/ow.ht.m4, bzw httpd/embed/Xow.ht.m4 liegt eine Weboberflaeche, die alle Sensoren erkennt und ihre aktuelle Temperatur regelmässig per Ajax abfragt und anzeigt. Im Falle von Xow.ht.m4 wird sogar Graph der Temperatur mittels SVG gemalt. Um die Dateien einzubinden, muss man einfach bei aktiviertem Onewiresupport den Webserver und das Datei Inlining aktivieren. Die Dateien können dann unter ow.ht bzw. unter Xow.ht angezeigt werden. Das Beispiel zeigt die SVG-Version mit Naming-Support: [[File:onewire-svg.png]] = Anschluss AVR-NET-IO = Für das Pollin AVR-NET-IO Board können die Sensoren DS18S20+ , normal Betrieb [[File:netio-1wire_normal.png]] parasitären Modus [[File:netio-1wire.png]] Anmerkung: Wenn man beim Net-IO nicht alle Analogeingänge benötigt, lässt sich der 1-Wire-Bus auch an der Schraubklemme ADC1 ganz gut aufschalten. Vorteil ist, dass man gleich alle passenden Spannungen (GND, +5V) an den beiden nebenliegenden Schraubklemmen hat. Das Pinning muss dann entspechend in der kann in der Datei pinning/hardware/netio.m4 von PD6 auf PA4 geändert werden. Vorteil dieser Konfiguration ist, dass man den DB-25-Verbinder zum Anschluss der Relaisplatine K8IO von Pollin frei hat und den EXT Steckverbinder zum Anschluss eines LCD über ein 4bit-Interface nutzen kann, ohne die Erweiterungsplatine von Pollin zu benötigen. Pinbelegung: [[File:ds18s20-par-pinout.jpg]] = Anschluss Etherrape = Die Schaltung je nach parasitärem oder normalem Betriebsmodus kann aus der NetIO Skizze übernommen werden. Data liegt auf PORTD an Pin 7: PORTD +---+ |x x| |x X| <- Pin 7 |x x |x x| |x x| +---+ Direkt neben PORTD befinden sich 2 Pins mit GND und 5V als Beschriftung. GND kann als GND und 5V als Vcc genutzt werden. = Einbindung in [[Control6]] = Die Sensoren können mit '''ONEWIRE_GET''' einfach abgefragt werden. Die Funktion führt automatisch ein ''convert'' aus, es sind also keine zwei Schritte erforderlich wie bei dem Zugriff über [[ECMD]]. Die Rückgabe erfolgt (analog der Funktion '''KTY_GET''') in Centigrad, also Temperatur * 10. Hier vielleicht ein kleines Beispiel, das die Daten per [[SYSLOG]] ausgibt sobald sich die Temperatur um mehr als ein Grad zur letzten Messung verändert hat. <pre> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO div_t res = div(Temperatur,10); SYSLOG("temperature changed %d.%d",res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> = Abfrage per [[SNMP]] = Falls Polling-Support aktiviert wurde können die Sensorwerte per SNMP abgefragt werden. Mit Naming-Support stehen auch die Namen per SNMP zur Verfügung und die Index-Nummern sind fix auf die Position in der Namenstabelle festgelegt. Dies ist sehr hilfreich, um bestimmte Sensoren über den SNMP-Index anzusprechen. Es gibt folgende OIDs: * .1.3.6.1.4.1.39967.3.1.<idx> : ROM-Code des Sensors * .1.3.6.1.4.1.39967.3.2.<idx> : Sensor-Name (nur mit Naming-Support) * .1.3.6.1.4.1.39967.3.3.<idx> : Temperaturwert in Centigrad * .1.3.6.1.4.1.39967.3.4.<idx> : 0 = Sensor nicht vorhanden, 1 = Sensor vorhanden Hier ein Beispiel: <pre> # snmpwalk -Osn -c public -v 1 192.168.255.90 1.3.6.1.4.1.39967.3 .1.3.6.1.4.1.39967.3.1.0 = STRING: "1080cff6010800f9" .1.3.6.1.4.1.39967.3.1.1 = STRING: "10c8cff60108002d" .1.3.6.1.4.1.39967.3.1.2 = STRING: "1029f6dc0108002f" .1.3.6.1.4.1.39967.3.1.3 = STRING: "10f2d0f60108001c" .1.3.6.1.4.1.39967.3.1.4 = STRING: "105a17f70108001d" .1.3.6.1.4.1.39967.3.1.5 = STRING: "10b8d8f601080098" .1.3.6.1.4.1.39967.3.1.6 = STRING: "104dedf601080057" .1.3.6.1.4.1.39967.3.1.7 = STRING: "10011af701080027" .1.3.6.1.4.1.39967.3.1.8 = STRING: "0000000000000000" .1.3.6.1.4.1.39967.3.1.9 = STRING: "0000000000000000" .1.3.6.1.4.1.39967.3.2.0 = STRING: "kessel" .1.3.6.1.4.1.39967.3.2.1 = STRING: "warmwasser" .1.3.6.1.4.1.39967.3.2.2 = STRING: "aussen" .1.3.6.1.4.1.39967.3.2.3 = STRING: "speicher" .1.3.6.1.4.1.39967.3.2.4 = STRING: "heizung vl" .1.3.6.1.4.1.39967.3.2.5 = STRING: "heizung rl" .1.3.6.1.4.1.39967.3.2.6 = STRING: "boiler vl" .1.3.6.1.4.1.39967.3.2.7 = STRING: "boiler rl" .1.3.6.1.4.1.39967.3.2.8 = "" .1.3.6.1.4.1.39967.3.2.9 = "" .1.3.6.1.4.1.39967.3.3.0 = INTEGER: 334 .1.3.6.1.4.1.39967.3.3.1 = INTEGER: 467 .1.3.6.1.4.1.39967.3.3.2 = INTEGER: 127 .1.3.6.1.4.1.39967.3.3.3 = INTEGER: 185 .1.3.6.1.4.1.39967.3.3.4 = INTEGER: 318 .1.3.6.1.4.1.39967.3.3.5 = INTEGER: 269 .1.3.6.1.4.1.39967.3.3.6 = INTEGER: 366 .1.3.6.1.4.1.39967.3.3.7 = INTEGER: 291 .1.3.6.1.4.1.39967.3.3.8 = INTEGER: 0 .1.3.6.1.4.1.39967.3.3.9 = INTEGER: 0 .1.3.6.1.4.1.39967.3.4.0 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.1 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.2 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.3 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.4 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.5 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.6 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.7 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.8 = INTEGER: 0 .1.3.6.1.4.1.39967.3.4.9 = INTEGER: 0 </pre> = Codebeispiele = * [[Onewire/Example/PHP (Deutsch) | PHP]] * [[Onewire/Example/Perl (Deutsch) | Perl]] * [[Onewire/Example/Python | Python]] * [[Onewire/Example/Shell | sh/bash]] [[Category:Ethersex]] [[Category:StepByStep]] [[Category:Onewire]] = Bezugsquellen = * Laut Michael Schultz (k1w1) hat er immer DS1820 auf Lager und kann sie sehr günstig weiterverkaufen. Auch Mindermengen. Mail: ethersex [AT] keyb [DOT] de * und natürlich bei den üblichen Verdächtigen: Reichelt, Segor, Conrad 164d31a3890b278acaf29ad39c2911b551afe857 821 789 2012-09-23T15:15:57Z Djmaster 255 wikitext text/x-wiki {{i18n|Onewire}} {{Module |NAME=Onewire |MENUCONFIG={{I/O}}->Onewire support |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] [[HTTPD]] (optional) [[SNMP]] (optional) |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} Ethersex kann 1-wire Temperatursensoren mit [[ECMD]] auflisten und abfragen. Es wird eine reine Softwareimplementierung des Protokolls benutzt, was keine weiteren Hardware erfordert, als die Temperatursensoren selbst. = Pinning = In der Standardkonfiguration liegt der Datapin des Buses auf PD6 (kann z.B. in der pinning/hardware/netio.m4 oder pinning/hardware/etherrape.m4 geändert werden). Die Definition der Pins erfolgt mit: <source lang=c> ONEWIRE_PORT_RANGE(PXn, PXm) </source> wobei PXn und PNm Pins auf PORTX sind. Jeder Pin zwischen und einschließlich PXn und PXm bildet einen eingenständigen Onewire Bus. Du kannst bis zu acht Busse auf einem PORT definieren (alle Busse müssen auf dem selben PORT liegen!) == Beispiele == Wenn Du nur einen einzigen Bus benötigst, definiere den Bereich wie folgt: '''PORTD: PIN2''' <source lang=c> ONEWIRE_PORT_RANGE(PD2, PD2) </source> Für drei Busse würde das ganze etwa so aussehen: '''PORTD: PIN2, PIN3, PIN4''' <source lang=c> ONEWIRE_PORT_RANGE(PD2, PD4) </source> = Polling Modus = │ │ [*] Onewire Polling │ │ │ │ (375) Time between discoveries in 0.8s steps │ │ │ │ (12) Time between polling in 0.8s steps │ │ │ │ [*] ECMD 1w list with values │ │ │ │ (10) Maximum sensor count │ │ Im Polling-Modus werden die Sensoren im Hintergrund abgefragt, so dass die Werte bei Bedarf direkt zur Verfügung stehen und nicht erst gewandelt bzw. eingelesen werden müssen. Der Intervall zwischen den Discoveries und zwischen den Abfragen der Werte kann getrennt eingestellt werden. Die Option '''ECMD 1w list with values''' bietet die Möglichkeit, die aktuellen Werte bei Aufruf von '''1w list''' mit ausgeben zu lassen. So können darauf folgende '''1w get''' Kommandos entfallen. Da zur Pufferung der Werte, ROM-Codes, etc. RAM-Speicher benötigt wird, muss per '''Maximum sensor count''' angegeben werden, für wie viele Sensoren Speicher reserviert wird. = Benennung von Sensoren = │ │ [*] Onewire naming support │ │ │ │ (10) Maximum sensor count │ │ Um den Sensoren sinnvolle Namen zu geben besteht die Möglichkeit im EEPROM eine entsprechende Zuweisungstabelle anzulegen (ROM-Code -> Name). Die Namen werden bei bei Aufruf von '''1w list''' mit ausgegeben. Dazu gibt es folgende ECMD Kommandos: 1w name list Auflistung der aktuellen Zuweisungen (Spalten: ID, ROM-Code, Name). Die ID bezeichnet die Position in der Zuweisungstabelle und kann u.a. dazu benutzt werden, Sensoren bei SNMP-Abfragen eindeutig zu referenzieren. 1w name set <ID> <ROM-Code> <Name> Erstellt einen entsprechenden Tabelleneintrag. 1w name clear <ID> Löscht die Felder eines Tabelleneintrags. 1w name save Speichert die aktuelle Tabelle im EEPROM = Unterstützte Hardware = Folgende 1-wire Hardware wird momentan durch Ethersex unterstützt: * DS1820 (Temperatursensor) * DS18B20 (Temperatursensor) * DS1822 (Temperatursensor) * DS2502 (EEPROM) * [http://www.ethersex.de/index.php/Onewire_DS2450_%28Deutsch%29 DS2450 (4 Kanal ADC)] = Onewire Befehle = unter Linux als erstes netcat starten (hierbei natürlich die IP ggf modifizieren): netcat 192.168.0.15 2701 danach am prompt: 1w list Gibt eine Liste mit Hexcodes aller angeschlossenen und erkannten Onewire(tm) Sensoren aus. Bei aktiviertem Naming-Support wird (per TAB getrennt) zusätzlich der Name ausgegeben. Außerdem kann mit '''ECMD 1w list with values (ONEWIRE_ECMD_LIST_VALUE_SUPPORT)''' der aktuelle Temperaturwert mit ausgegeben werden. Dies erspart zusätzliche '''1w get''' Aufrufe, setzt allerding Polling-Support vorraus. 1w convert <hexcode> Veranlasst eine Temperaturmessung des addressierten Sensors, oder, wenn das Argument <hexcode> weggelassen wird, aller angeschlossener Sensoren. Im Polling-Modus wird dieses Kommando ignoriert. 1w get <hexcode> Gibt die gemessene Temperatur eines Sensors aus. = Einbindung in die [[HTTPD]]-Weboberfläche = Unter httpd/embed/ow.ht.m4, bzw httpd/embed/Xow.ht.m4 liegt eine Weboberflaeche, die alle Sensoren erkennt und ihre aktuelle Temperatur regelmässig per Ajax abfragt und anzeigt. Im Falle von Xow.ht.m4 wird sogar Graph der Temperatur mittels SVG gemalt. Um die Dateien einzubinden, muss man einfach bei aktiviertem Onewiresupport den Webserver und das Datei Inlining aktivieren. Die Dateien können dann unter ow.ht bzw. unter Xow.ht angezeigt werden. Das Beispiel zeigt die SVG-Version mit Naming-Support: [[File:onewire-svg.png]] = Anschluss AVR-NET-IO = Für das Pollin AVR-NET-IO Board können die Sensoren DS18S20+ , normal Betrieb [[File:netio-1wire_normal.png]] parasitären Modus [[File:netio-1wire.png]] Anmerkung: Wenn man beim Net-IO nicht alle Analogeingänge benötigt, lässt sich der 1-Wire-Bus auch an der Schraubklemme ADC1 ganz gut aufschalten. Vorteil ist, dass man gleich alle passenden Spannungen (GND, +5V) an den beiden nebenliegenden Schraubklemmen hat. Das Pinning muss dann entspechend in der kann in der Datei pinning/hardware/netio.m4 von PD6 auf PA4 geändert werden. Vorteil dieser Konfiguration ist, dass man den DB-25-Verbinder zum Anschluss der Relaisplatine K8IO von Pollin frei hat und den EXT Steckverbinder zum Anschluss eines LCD über ein 4bit-Interface nutzen kann, ohne die Erweiterungsplatine von Pollin zu benötigen. Pinbelegung: [[File:ds18s20-par-pinout.jpg]] = Anschluss Etherrape = Die Schaltung je nach parasitärem oder normalem Betriebsmodus kann aus der NetIO Skizze übernommen werden. Data liegt auf PORTD an Pin 7: PORTD +---+ |x x| |x X| <- Pin 7 |x x |x x| |x x| +---+ Direkt neben PORTD befinden sich 2 Pins mit GND und 5V als Beschriftung. GND kann als GND und 5V als Vcc genutzt werden. = Einbindung in [[Control6]] = Die Sensoren können mit '''ONEWIRE_GET''' einfach abgefragt werden. Die Funktion führt automatisch ein ''convert'' aus, es sind also keine zwei Schritte erforderlich wie bei dem Zugriff über [[ECMD]]. Die Rückgabe erfolgt (analog der Funktion '''KTY_GET''') in Centigrad, also Temperatur * 10. Hier vielleicht ein kleines Beispiel, das die Daten per [[SYSLOG]] ausgibt sobald sich die Temperatur um mehr als ein Grad zur letzten Messung verändert hat. <pre> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO div_t res = div(Temperatur,10); SYSLOG("temperature changed %d.%d",res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> = Abfrage per [[SNMP]] = Falls Polling-Support aktiviert wurde können die Sensorwerte per SNMP abgefragt werden. Mit Naming-Support stehen auch die Namen per SNMP zur Verfügung und die Index-Nummern sind fix auf die Position in der Namenstabelle festgelegt. Dies ist sehr hilfreich, um bestimmte Sensoren über den SNMP-Index anzusprechen. Es gibt folgende OIDs: * .1.3.6.1.4.1.39967.3.1.<idx> : ROM-Code des Sensors * .1.3.6.1.4.1.39967.3.2.<idx> : Sensor-Name (nur mit Naming-Support) * .1.3.6.1.4.1.39967.3.3.<idx> : Temperaturwert in Centigrad * .1.3.6.1.4.1.39967.3.4.<idx> : 0 = Sensor nicht vorhanden, 1 = Sensor vorhanden Hier ein Beispiel: <pre> # snmpwalk -Osn -c public -v 1 192.168.255.90 1.3.6.1.4.1.39967.3 .1.3.6.1.4.1.39967.3.1.0 = STRING: "1080cff6010800f9" .1.3.6.1.4.1.39967.3.1.1 = STRING: "10c8cff60108002d" .1.3.6.1.4.1.39967.3.1.2 = STRING: "1029f6dc0108002f" .1.3.6.1.4.1.39967.3.1.3 = STRING: "10f2d0f60108001c" .1.3.6.1.4.1.39967.3.1.4 = STRING: "105a17f70108001d" .1.3.6.1.4.1.39967.3.1.5 = STRING: "10b8d8f601080098" .1.3.6.1.4.1.39967.3.1.6 = STRING: "104dedf601080057" .1.3.6.1.4.1.39967.3.1.7 = STRING: "10011af701080027" .1.3.6.1.4.1.39967.3.1.8 = STRING: "0000000000000000" .1.3.6.1.4.1.39967.3.1.9 = STRING: "0000000000000000" .1.3.6.1.4.1.39967.3.2.0 = STRING: "kessel" .1.3.6.1.4.1.39967.3.2.1 = STRING: "warmwasser" .1.3.6.1.4.1.39967.3.2.2 = STRING: "aussen" .1.3.6.1.4.1.39967.3.2.3 = STRING: "speicher" .1.3.6.1.4.1.39967.3.2.4 = STRING: "heizung vl" .1.3.6.1.4.1.39967.3.2.5 = STRING: "heizung rl" .1.3.6.1.4.1.39967.3.2.6 = STRING: "boiler vl" .1.3.6.1.4.1.39967.3.2.7 = STRING: "boiler rl" .1.3.6.1.4.1.39967.3.2.8 = "" .1.3.6.1.4.1.39967.3.2.9 = "" .1.3.6.1.4.1.39967.3.3.0 = INTEGER: 334 .1.3.6.1.4.1.39967.3.3.1 = INTEGER: 467 .1.3.6.1.4.1.39967.3.3.2 = INTEGER: 127 .1.3.6.1.4.1.39967.3.3.3 = INTEGER: 185 .1.3.6.1.4.1.39967.3.3.4 = INTEGER: 318 .1.3.6.1.4.1.39967.3.3.5 = INTEGER: 269 .1.3.6.1.4.1.39967.3.3.6 = INTEGER: 366 .1.3.6.1.4.1.39967.3.3.7 = INTEGER: 291 .1.3.6.1.4.1.39967.3.3.8 = INTEGER: 0 .1.3.6.1.4.1.39967.3.3.9 = INTEGER: 0 .1.3.6.1.4.1.39967.3.4.0 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.1 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.2 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.3 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.4 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.5 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.6 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.7 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.8 = INTEGER: 0 .1.3.6.1.4.1.39967.3.4.9 = INTEGER: 0 </pre> = Codebeispiele = * [[Onewire/Example/PHP (Deutsch) | PHP]] * [[Onewire/Example/Perl (Deutsch) | Perl]] * [[Onewire/Example/Python | Python]] * [[Onewire/Example/Shell | sh/bash]] [[Category:Ethersex]] [[Category:StepByStep]] [[Category:Onewire]] = Bezugsquellen = * Laut Michael Schultz (k1w1) hat er immer DS1820 auf Lager und kann sie sehr günstig weiterverkaufen. Auch Mindermengen. Mail: ethersex [AT] keyb [DOT] de * und natürlich bei den üblichen Verdächtigen: Reichelt, Segor, Conrad cdf6ba19161fee133ad14c56d7f6b36ad91f90c1 828 821 2012-09-23T15:21:06Z Mgue 312 changed DS2450 link wikitext text/x-wiki {{i18n|Onewire}} {{Module |NAME=Onewire |MENUCONFIG={{I/O}}->Onewire support |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] [[HTTPD]] (optional) [[SNMP]] (optional) |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} Ethersex kann 1-wire Temperatursensoren mit [[ECMD]] auflisten und abfragen. Es wird eine reine Softwareimplementierung des Protokolls benutzt, was keine weiteren Hardware erfordert, als die Temperatursensoren selbst. = Pinning = In der Standardkonfiguration liegt der Datapin des Buses auf PD6 (kann z.B. in der pinning/hardware/netio.m4 oder pinning/hardware/etherrape.m4 geändert werden). Die Definition der Pins erfolgt mit: <source lang=c> ONEWIRE_PORT_RANGE(PXn, PXm) </source> wobei PXn und PNm Pins auf PORTX sind. Jeder Pin zwischen und einschließlich PXn und PXm bildet einen eingenständigen Onewire Bus. Du kannst bis zu acht Busse auf einem PORT definieren (alle Busse müssen auf dem selben PORT liegen!) == Beispiele == Wenn Du nur einen einzigen Bus benötigst, definiere den Bereich wie folgt: '''PORTD: PIN2''' <source lang=c> ONEWIRE_PORT_RANGE(PD2, PD2) </source> Für drei Busse würde das ganze etwa so aussehen: '''PORTD: PIN2, PIN3, PIN4''' <source lang=c> ONEWIRE_PORT_RANGE(PD2, PD4) </source> = Polling Modus = │ │ [*] Onewire Polling │ │ │ │ (375) Time between discoveries in 0.8s steps │ │ │ │ (12) Time between polling in 0.8s steps │ │ │ │ [*] ECMD 1w list with values │ │ │ │ (10) Maximum sensor count │ │ Im Polling-Modus werden die Sensoren im Hintergrund abgefragt, so dass die Werte bei Bedarf direkt zur Verfügung stehen und nicht erst gewandelt bzw. eingelesen werden müssen. Der Intervall zwischen den Discoveries und zwischen den Abfragen der Werte kann getrennt eingestellt werden. Die Option '''ECMD 1w list with values''' bietet die Möglichkeit, die aktuellen Werte bei Aufruf von '''1w list''' mit ausgeben zu lassen. So können darauf folgende '''1w get''' Kommandos entfallen. Da zur Pufferung der Werte, ROM-Codes, etc. RAM-Speicher benötigt wird, muss per '''Maximum sensor count''' angegeben werden, für wie viele Sensoren Speicher reserviert wird. = Benennung von Sensoren = │ │ [*] Onewire naming support │ │ │ │ (10) Maximum sensor count │ │ Um den Sensoren sinnvolle Namen zu geben besteht die Möglichkeit im EEPROM eine entsprechende Zuweisungstabelle anzulegen (ROM-Code -> Name). Die Namen werden bei bei Aufruf von '''1w list''' mit ausgegeben. Dazu gibt es folgende ECMD Kommandos: 1w name list Auflistung der aktuellen Zuweisungen (Spalten: ID, ROM-Code, Name). Die ID bezeichnet die Position in der Zuweisungstabelle und kann u.a. dazu benutzt werden, Sensoren bei SNMP-Abfragen eindeutig zu referenzieren. 1w name set <ID> <ROM-Code> <Name> Erstellt einen entsprechenden Tabelleneintrag. 1w name clear <ID> Löscht die Felder eines Tabelleneintrags. 1w name save Speichert die aktuelle Tabelle im EEPROM = Unterstützte Hardware = Folgende 1-wire Hardware wird momentan durch Ethersex unterstützt: * DS1820 (Temperatursensor) * DS18B20 (Temperatursensor) * DS1822 (Temperatursensor) * DS2502 (EEPROM) * [[Onewire/DS2450 (Deutsch) | DS2450 (4 Kanal ADC)]] = Onewire Befehle = unter Linux als erstes netcat starten (hierbei natürlich die IP ggf modifizieren): netcat 192.168.0.15 2701 danach am prompt: 1w list Gibt eine Liste mit Hexcodes aller angeschlossenen und erkannten Onewire(tm) Sensoren aus. Bei aktiviertem Naming-Support wird (per TAB getrennt) zusätzlich der Name ausgegeben. Außerdem kann mit '''ECMD 1w list with values (ONEWIRE_ECMD_LIST_VALUE_SUPPORT)''' der aktuelle Temperaturwert mit ausgegeben werden. Dies erspart zusätzliche '''1w get''' Aufrufe, setzt allerding Polling-Support vorraus. 1w convert <hexcode> Veranlasst eine Temperaturmessung des addressierten Sensors, oder, wenn das Argument <hexcode> weggelassen wird, aller angeschlossener Sensoren. Im Polling-Modus wird dieses Kommando ignoriert. 1w get <hexcode> Gibt die gemessene Temperatur eines Sensors aus. = Einbindung in die [[HTTPD]]-Weboberfläche = Unter httpd/embed/ow.ht.m4, bzw httpd/embed/Xow.ht.m4 liegt eine Weboberflaeche, die alle Sensoren erkennt und ihre aktuelle Temperatur regelmässig per Ajax abfragt und anzeigt. Im Falle von Xow.ht.m4 wird sogar Graph der Temperatur mittels SVG gemalt. Um die Dateien einzubinden, muss man einfach bei aktiviertem Onewiresupport den Webserver und das Datei Inlining aktivieren. Die Dateien können dann unter ow.ht bzw. unter Xow.ht angezeigt werden. Das Beispiel zeigt die SVG-Version mit Naming-Support: [[File:onewire-svg.png]] = Anschluss AVR-NET-IO = Für das Pollin AVR-NET-IO Board können die Sensoren DS18S20+ , normal Betrieb [[File:netio-1wire_normal.png]] parasitären Modus [[File:netio-1wire.png]] Anmerkung: Wenn man beim Net-IO nicht alle Analogeingänge benötigt, lässt sich der 1-Wire-Bus auch an der Schraubklemme ADC1 ganz gut aufschalten. Vorteil ist, dass man gleich alle passenden Spannungen (GND, +5V) an den beiden nebenliegenden Schraubklemmen hat. Das Pinning muss dann entspechend in der kann in der Datei pinning/hardware/netio.m4 von PD6 auf PA4 geändert werden. Vorteil dieser Konfiguration ist, dass man den DB-25-Verbinder zum Anschluss der Relaisplatine K8IO von Pollin frei hat und den EXT Steckverbinder zum Anschluss eines LCD über ein 4bit-Interface nutzen kann, ohne die Erweiterungsplatine von Pollin zu benötigen. Pinbelegung: [[File:ds18s20-par-pinout.jpg]] = Anschluss Etherrape = Die Schaltung je nach parasitärem oder normalem Betriebsmodus kann aus der NetIO Skizze übernommen werden. Data liegt auf PORTD an Pin 7: PORTD +---+ |x x| |x X| <- Pin 7 |x x |x x| |x x| +---+ Direkt neben PORTD befinden sich 2 Pins mit GND und 5V als Beschriftung. GND kann als GND und 5V als Vcc genutzt werden. = Einbindung in [[Control6]] = Die Sensoren können mit '''ONEWIRE_GET''' einfach abgefragt werden. Die Funktion führt automatisch ein ''convert'' aus, es sind also keine zwei Schritte erforderlich wie bei dem Zugriff über [[ECMD]]. Die Rückgabe erfolgt (analog der Funktion '''KTY_GET''') in Centigrad, also Temperatur * 10. Hier vielleicht ein kleines Beispiel, das die Daten per [[SYSLOG]] ausgibt sobald sich die Temperatur um mehr als ein Grad zur letzten Messung verändert hat. <pre> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO div_t res = div(Temperatur,10); SYSLOG("temperature changed %d.%d",res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> = Abfrage per [[SNMP]] = Falls Polling-Support aktiviert wurde können die Sensorwerte per SNMP abgefragt werden. Mit Naming-Support stehen auch die Namen per SNMP zur Verfügung und die Index-Nummern sind fix auf die Position in der Namenstabelle festgelegt. Dies ist sehr hilfreich, um bestimmte Sensoren über den SNMP-Index anzusprechen. Es gibt folgende OIDs: * .1.3.6.1.4.1.39967.3.1.<idx> : ROM-Code des Sensors * .1.3.6.1.4.1.39967.3.2.<idx> : Sensor-Name (nur mit Naming-Support) * .1.3.6.1.4.1.39967.3.3.<idx> : Temperaturwert in Centigrad * .1.3.6.1.4.1.39967.3.4.<idx> : 0 = Sensor nicht vorhanden, 1 = Sensor vorhanden Hier ein Beispiel: <pre> # snmpwalk -Osn -c public -v 1 192.168.255.90 1.3.6.1.4.1.39967.3 .1.3.6.1.4.1.39967.3.1.0 = STRING: "1080cff6010800f9" .1.3.6.1.4.1.39967.3.1.1 = STRING: "10c8cff60108002d" .1.3.6.1.4.1.39967.3.1.2 = STRING: "1029f6dc0108002f" .1.3.6.1.4.1.39967.3.1.3 = STRING: "10f2d0f60108001c" .1.3.6.1.4.1.39967.3.1.4 = STRING: "105a17f70108001d" .1.3.6.1.4.1.39967.3.1.5 = STRING: "10b8d8f601080098" .1.3.6.1.4.1.39967.3.1.6 = STRING: "104dedf601080057" .1.3.6.1.4.1.39967.3.1.7 = STRING: "10011af701080027" .1.3.6.1.4.1.39967.3.1.8 = STRING: "0000000000000000" .1.3.6.1.4.1.39967.3.1.9 = STRING: "0000000000000000" .1.3.6.1.4.1.39967.3.2.0 = STRING: "kessel" .1.3.6.1.4.1.39967.3.2.1 = STRING: "warmwasser" .1.3.6.1.4.1.39967.3.2.2 = STRING: "aussen" .1.3.6.1.4.1.39967.3.2.3 = STRING: "speicher" .1.3.6.1.4.1.39967.3.2.4 = STRING: "heizung vl" .1.3.6.1.4.1.39967.3.2.5 = STRING: "heizung rl" .1.3.6.1.4.1.39967.3.2.6 = STRING: "boiler vl" .1.3.6.1.4.1.39967.3.2.7 = STRING: "boiler rl" .1.3.6.1.4.1.39967.3.2.8 = "" .1.3.6.1.4.1.39967.3.2.9 = "" .1.3.6.1.4.1.39967.3.3.0 = INTEGER: 334 .1.3.6.1.4.1.39967.3.3.1 = INTEGER: 467 .1.3.6.1.4.1.39967.3.3.2 = INTEGER: 127 .1.3.6.1.4.1.39967.3.3.3 = INTEGER: 185 .1.3.6.1.4.1.39967.3.3.4 = INTEGER: 318 .1.3.6.1.4.1.39967.3.3.5 = INTEGER: 269 .1.3.6.1.4.1.39967.3.3.6 = INTEGER: 366 .1.3.6.1.4.1.39967.3.3.7 = INTEGER: 291 .1.3.6.1.4.1.39967.3.3.8 = INTEGER: 0 .1.3.6.1.4.1.39967.3.3.9 = INTEGER: 0 .1.3.6.1.4.1.39967.3.4.0 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.1 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.2 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.3 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.4 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.5 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.6 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.7 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.8 = INTEGER: 0 .1.3.6.1.4.1.39967.3.4.9 = INTEGER: 0 </pre> = Codebeispiele = * [[Onewire/Example/PHP (Deutsch) | PHP]] * [[Onewire/Example/Perl (Deutsch) | Perl]] * [[Onewire/Example/Python | Python]] * [[Onewire/Example/Shell | sh/bash]] [[Category:Ethersex]] [[Category:StepByStep]] [[Category:Onewire]] = Bezugsquellen = * Laut Michael Schultz (k1w1) hat er immer DS1820 auf Lager und kann sie sehr günstig weiterverkaufen. Auch Mindermengen. Mail: ethersex [AT] keyb [DOT] de * und natürlich bei den üblichen Verdächtigen: Reichelt, Segor, Conrad 8f514ed8e0d63d5a1d66d1057e116883614d1985 0 168 790 410 2012-07-26T03:33:26Z Atos 604 /* Parameters */ wikitext text/x-wiki {{i18n|Development/ECMD}} For general information on ECMD, see [[ECMD]]. The following variables will be used on this page. Replace them for your module. * '''COMMAND''' - how the command will be invoked * '''ARGUMENT1'''...'''ARGUMENTN''' - the arguments that will be passed together with '''COMMAND''' * '''FUNCTIONNAME''' - the name of the function which will handle the command * '''MODULENAME''' - the name of the module = Preparations = * Create a new file inside the folder of the module '''MODULENAME_ecmd.c''' * Add this file to the [[Development/Makefile | Makefile]] of the module. * Open the file and "#include "protocols/ecmd/ecmd-base.h" and other necessary headers. * Add the header of the module, <string.h> etc. = Create a new command = Start with the following template: <source lang="c"> int16_t parse_cmd_FUNCTIONNAME (char *cmd, char *output, uint16_t len) { /* Your Code here */ return ECMD_FINAL_OK; } </source> Whenever '''COMMAND''' is invoked, this function will be called to handle it. == Parameters == * *cmd holds '''ARGUMENT1'''...'''ARGUMENTN''' which have been passed along with the command. The command text you specified with ecmd_feature macro has already been stripped off, *cmd points to the arguments only. The length of the commandbuffer varies, and may not be zero-terminated properly. * <strike>len is the length of the command (*cmd). Use this for securely parsing *cmd.</strike> len is the length of the output buffer. Do NOT write beyond this limit. Always check the remaining buffersize, or use snprintf_P with proper len param2. The output buffersize depends on the module that called the parser routine: UDP uses the remainder of the UIP buffer (first part of uip_buf holds the command), which is quite large. I2C uses ECMD_I2C_BUFFER_LEN, U(S)ART uses ECMD_SERIAL_USART_BUFFER_LEN and TCP uses ECMD_INPUTBUF_LENGTH (which is wrong, should be ECMD_OUTPUTBUF_LENGTH but both are equal and only 50 chars by default). If you have more text, use the ECMD_AGAIN return value: your routine will get called again in the next cycle. If your text should be continued on the same line, TCP has an ECMD_NO_NEWLINE mechanism at least for the first call, but other channels have not. * *output is the output buffer <strike>which can hold 50 bytes/characters</strike> == Return values == {| border="1" | ECMD_FINAL_OK | the command has been executed without any errors. "OK" will be written to the caller's output. |- | ECMD_FINAL('''len''') | the command has been executed. '''len''' bytes of *output will be written to the caller's output |- | ECMD_AGAIN('''len''') | the command has been executed but needs to be called again. '''len''' bytes of *output will be written to the caller's output |- | ECMD_ERR_PARSE_ERROR | the command couldn't be executed (missing/wrong arguments etc.) |- | ECMD_ERR_READ_ERROR | the command couldn't be executed (not able to read from device/hardware) |- | ECMD_ERR_WRITE_ERROR | the command couldn't be executed (not able to write to device/hardware) |} == Announce the command == Append this to the bottom of '''MODULENAME_ecmd.c''' to let the ECMD parser know about the new command. <source lang="c"> /* -- Ethersex META -- block(MODULENAME) ecmd_feature(FUNCTIONNAME, "COMMAND", ARGUMENT1...ARGUMENTN , DESCRIPTION) */ </source> The '''COMMAND''' along with the arguments and the description will show up [[ECMD_Reference | here]] = Tips and best practice = == Recursive calling a command handler function == If you need to output a lot of data (>50 bytes) , you need to recursivly call the command handler function using '''ECMD_AGAIN()'''. Instead of using unsafe ''static'' variables to keep track of the current progress you can use the following code: <source lang="c"> /* trick: use bytes on cmd as "connection specific static variables" */ if (cmd[0] != 23) { /* indicator flag: real invocation: 0 */ cmd[0] = 23; /* continuing call: 23 */ cmd[1] = 0; /* local variable 1 */ } </source> [https://github.com/ethersex/ethersex/blob/master/protocols/ecmd/parser.c#L193 source] [https://github.com/ethersex/ethersex/blob/master/services/dmx-storage/dmx_storage_ecmd.c#L105 example] [[Category:Development]] 8998a1f050f982493054ba08d6e5919f71029e6c 0 154 791 518 2012-07-26T04:46:07Z Atos 604 wikitext text/x-wiki {{i18n|Protokolle duplizieren}} = Protokolle duplizieren = Es kommt immer mal wider vor, das man das gleiche Protokoll zweimal benötigt. == Lösung 1 == Bei mir war der Fall, das ich ein Net-IO mit einem ATMega 644p ausgestattet habe, der zwei UART besitz. Diese zwei Schnittstellen wollte ich zum auslesen meiner Wechselrichter nutzen. Das Protokoll der Wahl war bei mir sll (serial_line_log) Leider muste ich feststellen, das ich immer nur ein Protokoll auf ein UART binden kann. Da es bist jetzt noch keine gute Idee gibt, wie man so etwas besser lösen kann, hier ein kleiner Trick. Das Protokoll serial_line_log wird einfach dupliziert. Ich habe jedes "seria_" in ein "serialzwei_" gewandelt. * Kopieren des Ordners (cp -a ethersex/protocols/serial_line_log ethersex/protocols/serialzwei_line_log) * alle Dateien im Ordner umbenannt (auser Makefile und config.in) (cd ethersex/protocols/serialzwei_line_log; mv serial_<...>.c serialzwei_<...>.c * mit einem Editor Alle Variabeln und Symbolenamen geändert <code> vim serialzwei_line_log.c :%s/SERIAL_/SERIALZWEI_/g :%s/serial_/serialzwei_/g :%s/sll_/sllzwei_/g </code> * in der serialzwei_line_log_ecmd.c muss noch der ecmd Befehl angepasst werden (ganz am Schluss der META abschnitt) <code> vim serialzwei_line_log_ecmd.c :%s/sll get/sll2 get :%s/sll_/sllzwei_/g </code> * in der protocols/serialzwei_line_log/config.in die Namen anpassen <code> vim config.in :%s/LINE_/LINE2_/g :%s/Line/Line2/g </code> * die ethersex/config.in und das MAKEFILE an die neuen Namen anpassen Zum Schluss müssen noch zwei zentrale Dateien angepasst werden. <code> cd ethersex/ vim Makefile SUBDIRS += protocols/serialzwei_line_log </code> <code> vim config.in source protocols/serialzwei_line_log/config.in </code> Danach sollte <code> make menuconfig </code> Jetzt sollte unter Protokolle das Serial Line Log zweimal vorhanden sein. Anmerkung: Das gleiche Verfahren funktioniert auch mit dem yport-Protokoll. Wenn man z.B. einen ATMega644p besitzt und beide UARTs "gleichzeitig" benutzen will, kann man das yport-Protokoll mit dem hier vorgestellten Verfahren duplizieren. nc <ip> 7970 bzw nc <ip> 7971 liefert dann die Ausgabe der beiden Ports. == Lösung 2 == Speziell für den U(S)ART gibt es eine elegantere Möglichkeit: Die AVR-LIBC unterstützt inzwischen bis zu zwei U(S)ARTs durch verschiedene Makros. In den Dateien core/usart.h und scripts/usart-config.sh finden sich weitere hilfreiche Makros. Man geht wie folgt vor: In config.in läßt man via menuconfig einen U(S)ART auswählen, indem man das Makro usart_choice() benutzt. Außerdem im Spiel sind die Makros get_usart_count und usart_count_used. Als Ergebnis sollten zwei Variable definiert sein: <mymodulename>_USE_USART und <mymodulename>_BAUDRATE, welche für die U(S)ART-Nummer bzw. die Baudrate stehen. Als Beispiel siehe YPort. Im C-Quelltext benötigt man folgende Anweisungen: * #define USE_USART <mymodulename>_USE_USART Die Variable <mymodulename>_USE_USART muß in config.in auf eine Zahl 0 oder 1 für den ausgewählten U(S)ART gesetzt worden sein. Mit der Zuweisung an USE_USART versorgt man die folgenden universellen Makroaufrufe mit der richtigen U(S)ART-Nummer. * #define BAUD <mymodulensme>_BAUDRATE Gleiches Spiel für die Baudrate * #include "core/usart.h" Hier stehen Makros * generate_usart_init() Dieser Makroaufruf irgendwo im folgenden C-Quelltext generiert eine Routine usart_init() für den ausgewählten U(S)ART, setzt das Datenformat auf 8N1 und die Baudratenvorteiler auf den korrekten Wert. Außerdem werden die RXC und TX Interrupts freigegeben. Andere Datenformate als 8N1 sind (noch) nicht als Makro definiert, und wenn das Freigeben der Interrupts stört, dann sollte man anstelle des generate_usart_init() Makros die Intialisierung aller Register mit Hilfe der unten beschriebenen Makros selbst durchführen. * ISR(usart(USART,_RX_vect)) bzw. ISR(usart(USART,_TX_vect)) etc. So werden die Interrupthandler universell definiert, sie verwenden dann automatisch die richtige U(S)ART-Nummer. * Die U(S)ART-Register sowie die Bit-Definitionen der Register werden ersetzt durch Makroaufrufe usart(<vordererTeil>[,<hintererTeil>]). Das Makro fügt die U(S)ART-Nummer ein. [[Category:Development]] 06017e0cd4244ed20a148477062b769d5b63d21e 0 311 808 2012-09-14T10:06:44Z GooPie4o 265 Created page with "{{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->RFM12 ASK->868MHz |STATUS={{experimental}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]][[RFM1…" wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->RFM12 ASK->868MHz |STATUS={{experimental}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]][[RFM12 ASK]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} fd1ca27b711475c1b679d892bb15be9229ebe2fa 809 808 2012-09-14T10:07:31Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->RFM12 ASK->868MHz |STATUS={{experimental}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} 9a467b1ee06c45b5cd260ca4dfec8077c213cedf 814 809 2012-09-23T12:41:05Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} 60fa0fa1c8cd53287a9345a7d15aa8a63b00d666 0 312 810 2012-09-14T10:08:04Z GooPie4o 265 Created page with "{{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->RFM12 ASK->868MHz |STATUS={{experimental}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]] [[RFM…" wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->RFM12 ASK->868MHz |STATUS={{experimental}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} 9a467b1ee06c45b5cd260ca4dfec8077c213cedf 813 810 2012-09-23T12:40:30Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} 60fa0fa1c8cd53287a9345a7d15aa8a63b00d666 0 173 811 425 2012-09-22T23:43:45Z Mgue 312 input is not implemented yet wikitext text/x-wiki {{i18n|Ethersex Lighting Architecture}} = Design = {| style="width:100%" | colspan="2" | {| cellpadding="4" cellspacing="0" style="margin-top:5px; background:#F7F7F7; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | style="background-color: #93FF05; text-align: center; border-bottom:1px solid #aaaaaa;" | '''Display''' PWM/Servo Control Modules for Lighting Devices directly attached to ethersex |- | * [[StellaLight]] * [[Starburst]] * [[DMX_Storage#ECMD_commands | ECMD]] |} |- | colspan="2" style="background-color: #FF8C00; text-align: center; border-bottom:1px solid #aaaaaa; height:50px;" | '''[[DMX Storage | Storage]]''' provides an API for higher and lower layers (access and store) |- | style="width:50%" | {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#F7F7F7; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | style="background-color: #B9BCFF; text-align: center; border-bottom:1px solid #aaaaaa; " | '''Input/Modifiers''' receivers and modifiers for DMX data |- | * [[DMX]] (not yet implemented) * [[Artnet]] * [[DMX_Storage#ECMD_commands | ECMD]] * [[DMX_Storage#Web_GUI | HTTP]] * [[DMX FXSlot]] |} | style="width:50%" | {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#F7F7F7; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | style="background-color: #B9BCFF; text-align: center; border-bottom:1px solid #aaaaaa; " | '''Output''' DMX/Universe Routing (e.g. [[Artnet]] in => [[DMX]] RS485 out) |- | * [[DMX]] * [[Artnet]] * [[DMX_Storage#ECMD_commands | ECMD]] |} |} [[Category:e6la]] d1064531c8715b89db4eacf01ebb07bfeaa3d6c2 8 313 812 2012-09-23T01:17:04Z Mgue 312 sourcecode + bug wikitext text/x-wiki * navigation ** mainpage|mainpage-description ** https://github.com/ethersex/ethersex|Sourcecode ** http://bugs.ethersex.de/|Report a Bug ** currentevents-url|currentevents ** recentchanges-url|recentchanges ** randompage-url|randompage ** helppage|help * SEARCH * TOOLBOX * LANGUAGES 442e11ac634013ce1f6b9c2681984f68fa2a49f0 10 210 815 558 2012-09-23T13:18:00Z Mgue 312 changed color to orange wikitext text/x-wiki <div style="text-align:center;background-color: #FF7B00;color: #ffffff;font-weight: bold;">Experimental</div> [[Category:Experimental Module| ]] bb1eb68378f75384dc83369b83d56c48b900d627 10 39 816 423 2012-09-23T13:43:38Z Mgue 312 added more links wikitext text/x-wiki <noinclude>{{i18n|Template:Documentation}}</noinclude> {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | style="background-color: #FFFFFF; text-align: center; border-bottom:1px solid #aaaaaa;" | '''Documentation''' |- | [[Wiki Guidelines]] ---- * [[:Category:Hardware|Hardware Drivers]] * [[:Category:Protocol|Protocol Support]] * [[:Category:Application|Services and Applications]] * [[ECMD Reference]] ---- * [[Flashing|Flashing Ethersex]] ---- [[:Category:Development|'''For Developers''']] * [[Concept of meta]] * [[Own module]] * [[Config.mk]] * [[Development/ECMD|Writing ECMD Commands]] * [[Configuration of Boards and Pins]] |} bd8c6880cb1663b4c6467e84336ad59767eb5ee8 6 314 817 2012-09-23T14:48:42Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 315 818 2012-09-23T14:50:29Z Djmaster 255 Created page with "{{i18n|Onewire_DS2450}} {{Module |NAME=Onewire_DS2450 |MENUCONFIG={{I/O}}->Onewire support |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} …" wikitext text/x-wiki {{i18n|Onewire_DS2450}} {{Module |NAME=Onewire_DS2450 |MENUCONFIG={{I/O}}->Onewire support |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} *Beitrag am 23.09.2012 erneuert. == Dallas 1-wire DS2450 4 Kanal ADC == Der DS2450 ist ein 4 Kanal ADC mit einer maximalen Auflösung von 16 Bit (vgl. [http://datasheets.maxim-ic.com/en/ds/DS2450.pdf Datenblatt]). Die analog-digital Umwandlung erfolgt durch einen internen four-to-one multiplexer. Kanäle, die nicht als Eingänge genutzt werden, können als Ausgänge (open drain) geschaltet werden (max. 4mA und 6V). === ECMD Interface === Über ECMD sind folgende Befehle für den DS2450 bekannt: *<code>1w ds2450 power</code> *<code>1w ds2450 res</code> *<code>1w ds2450 oc</code> *<code>1w ds2450 oe</code> *<code>1w ds2450 range</code> *<code>1w ds2450 por</code> *<code>1w ds2450 convert</code> *<code>1w ds2450 get</code> ==== Grundsätzliches ==== Grundsätzlich gilt für alle Befehle: * als erstes Argument kann optional die 64 Bit ROM Id des DS2450 angegeben werden, der angesprochen werden soll (match rom). Wird die ROM Id <b>nicht</b> angeben, so werden alle im Bus befindlichen 1-wire Devices (egal welchen Typs) angesprochen (skip rom). Dies macht <b>nur</b> Sinn, wenn sich <b>genau</b> ein Device im 1-wire Bus befindet (skip rom führt bei mehreren Devices unweigerlich dazu, dass mehrere Devices gleichzeitig antworten werden, was zu Bit-Salat beim bus master (d.h. Ethersex) führt, das Datenblatt spricht von "a wired-AND result"). * wird ein Kanal angeben, so ist dieser mit einem Buchstaben (entsprechend Datenblatt) zu bezeichnen (case-insensitiv). * wird mit einem Befehl ein Wert gesetzt, so kann mit dem gleichen Befehl der Wert gelesen werden, in dem man kein Werte-Argument angibt. ==== <code>1w ds2450 power</code> ==== Hierüber wird die Art der Spannungsversorgung des DS2450 gesetzt (global). Dieser Parameter wird durch den Anschluss an der 1-wire Bus bestimmt, vgl. die [[Dallas_1-wire_Bus#Anschluss_AVR-NET-IO | Erklärung der Anschlussmöglichkeiten]]. Wird der 1-wire Bus "normal" (drei-adrig) betrieben, so muss der Wert auf 1 gesetzt werden. Wird der Bus "parasitär" (zwei-adrig) betrieben, muss der Wert auf 0 gesetzt werden. Default-Wert: 0 Beispiel: 1w ds2450 power 1 (der DS250 wird auf "normale" Spannungsversorgung konfiguriert) ==== <code>1w ds2450 res</code> ==== Hierüber wird die Auflösung der analog-digital Umwandlung gesetzt (pro Kanal). Die Auflösung kann zw. 1 und 16 Bit eingestellt werden. Die Eingabe erfolgt als 8 Bit Hexadezimalwert, wobei eine Auflösung von 16 Bit durch den Wert 0x00 oder alternativ 0x10 erreicht wird. Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0x08 Beispiel: 1w ds2450 res c 08 (setzt die Auflösung für Kanal C auf 0x08, d.h. 8 Bit) ==== <code>1w ds2450 oc</code> ==== Hierüber kann der Ausgang ein- oder ausgeschaltet werden (pro Kanal). Voraussetzung ist, dass über [[DS2450#1w_ds2450_oe | 1w ds2450 oe]] der Kanal als Ausgang geschaltet wurde (ansonsten wird das OC-Bit ignoriert). Die Eingabe erfolgt als bool über 0 (Ausgangstransistor leitend) bzw. 1 (Ausgangstransistor nicht-leitend). Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0 Beispiel: 1w ds2450 oc a 1 (der Ausgangstransistor des Kanal A wird leitend) ==== <code>1w ds2450 oe</code> ==== Hierüber kann der Kanal als Ein- oder Ausgang gesetzt werden (pro Kanal). Eine analog-digital Umwandlung ist <b>nur</b> möglich, wenn das OE-Bit auf 0 gesetzt ist. In diesem Fall wird das OC-Bit ignoriert. Ist das OE-Bit auf 1 gesetzt, kann der Ausgang über [[DS2450#1w_ds2450_oc | 1w ds2450 oc]] ein- bzw. ausgeschaltet werden. Die Eingabe erfolgt als bool über 0 (Eingang für ADC) bzw. 1 (Ausgang open drain). Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0 Beispiel: 1w ds2450 oe d 1 (Kanal A wird als Ausgang gesetzt) ==== <code>1w ds2450 range</code> ==== Hierüber kann der Spannungs-Bereich angegeben werden, in dem die analog-digital Umwandlung stattfinden soll. Die Eingabe erfolgt als bool über 0 (Spannungsbereich 0 bis 2,55V) bzw. 1 (Spannungsbereich 0 bis 5,10V). Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0 Beispiel: 1w ds2450 range b 1 (für Kanal B wird bei der analog-digital Umwandlung der Spannungsbereich 0 bis 5,10V genutzt) ==== <code>1w ds2450 por</code> ==== Hierüber kann das power on reset Bit gelesen bzw. gesetzt werden. Nach einem power-on reset cycle setzt der DS2450 das Bit auf 1. Das Bit beeinflusst die conditional search, welche in Ethersex (noch) nicht implementiert ist. Setzt der bus master das Bit auf 0, so nimmt der DS2450 nicht mehr an der conditional search teil Die Eingabe erfolgt als bool über 0 bzw. 1. Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 1 (nach power-on reset cycle) Beispiel: 1w ds2450 por c 0 (für Kanal C wird das power on reset Bit auf 0 gesetzt) FixMe: Es sieht so aus, als kann das Bit nur global gesetzt werden, d.h. wird es für einen Kanal verändert, haben danach alle anderen Kanäle den gleich POR-Bit Wert. Außerdem kann man das Bit nicht mehr auf 1 setzen, wenn es vorher schon auf 0 gesetzt wurde (das widerspricht aber dem Datenblatt!). ==== <code>1w ds2450 convert</code> ==== Hierüber wird die analog-digital Umwandlung ausgelöst (analog den 1-wire Temperatursensoren). Werden keine weiteren Argumente angegeben, so wird die Umwandlung für alle 4 Kanäle des DS2450 durchgeführt (FixMe: vermutlich werden die Kanäle, bei denen das OE-Bit auf 1 steht ausgelassen, dass ist aber nicht durch Dallas dokumentiert). Optional können zwei Argumente angegeben werden (werden Argumente angegeben, <b>müssen beide</b> Argumente angegeben werden!): * input select mask * read-out control ===== input select mask ===== Mit der input select mask kann angegeben werden, für welche Kanäle die analog-digital Umwandlung durchgeführt werden soll. Die input select mask ist ein 8 Bit Hexadezimalwert: {| border=1 cellspacing=0 padding=4 class=wikitable ! bit7 !! bit6 !! bit5 !! bit4 !! bit3 !! bit2 !! bit1 !! bit0 |- | ignore || ignore || ignore || ignore || Kanal D || Kanal C || Kanal B || Kanal A |} Eine input select mask von 0x0f bedeutet also, dass für alle 4 Kanäle die analog-digital Umwandlung durchgeführt werden soll. Eine mask von 0x00 ist (offensichtlich) sinnlos. Eine ungültige input select mask (d.h. input select mask == 0x00 oder > 0x0f) wird erkannt und führt zu einer ECMD-Fehlermeldung. Die analog-digital Umwandlung erfolgt in der Reihenfolge von Kanal A zu Kanal D, wobei die nicht gewünschte Kanäle (sprich jene, wo das input select mask Bit auf 0 steht) übersprungen werden. Der DS2450 braucht für jedes Bit Auflösung ca. 60 bis 80µs. Außerdem braucht das Umwandlung-Kommando generell 160µs (offset) Dies bedeutet, dass eine Umwandlung aller 4 Kanäle bei maximaler 16 Bit Auflösung also nicht länger als 4*16*80+160µs = 5280µs = 5,28ms dauern wird. ===== read out control ===== Mit dem read out control kann angegeben werden, ob und wie das Register für die Ergebnisse der analog-digital Umwandlung vorbelegt werden soll. Das macht nur dann Sinn, wenn die Umwandlungsergebnisse schon gelesen werden sollen, während der DS2450 im Hintergrund noch die analog-digital Umwandlung durchführt (was möglich ist). Das read out control ist ein 8 Bit Hexadezimalwert: {| border=1 cellspacing=0 padding=4 class=wikitable ! bit7 !! bit6 !! bit5 !! bit4 !! bit3 !! bit2 !! bit1 !! bit0 |- | Set D || Clear D || Set C || Clear C || Set B || Clear B || Set A || Clear A |} Set bzw. Clear verhalten sich wie folgt: {| border=1 cellspacing=0 padding=4 class=wikitable ! Set !! Clear !! Ergebnis |- | 0 || 0 || keine Veränderung am Umwandlung-Register |- | 0 || 1 || alle Bits des Umwandlung-Register werden auf 0 gesetzt |- | 1 || 0 || alle Bits des Umwandlung-Register werden auf 1 gesetzt |- | 1 || 1 || invalid |} Ungültige Kombinationen im read out control (d.h. Set = 1 und Clear = 1) werden erkannt und führen zu einer ECMD-Fehlermeldung. Default-Werte: * input select mask: 0x04 * read out control: 0x00 Beispiel: 1w ds2450 convert (für alle Kanäle wird die analog-digital Umwandlung durchgeführt) ==== <code>1w ds2450 get</code> ==== Hierüber wird das Ergebnis der analog-digital Umwandlung ausgelesen (analog den 1-wire Temperatursensoren). Werden keine weiteren Argumente angegeben, so werden die Umwandlungsergebnisse für alle 4 Kanäle des DS2450 ausgegeben. Optional kann ein Kanal angegeben werden, dann wird nur das Umwandlungsergebniss dieses Kanals ausgegeben. Wurde seit dem letzten power-on reset cycle keine Umwandlung durchgeführt, stehen alle Bits der Register auf 0. Die Ausgabe erfolgt als raw (unsigned integer 16 Bit - <code>uint16_t</code>). Die eingelesene Spannung errechnet sich wie folgt (VAL ist die Ausgabe von <code>1w ds2450 get</code>): * für range = 0 (0..2,55V) VAL ------- * 2,55V 2**16-1 * für range = 1 (0..5,10V) VAL ------- * 5,10V 2**16-1 Default-Werte: - Beispiel: 1w ds2450 get (die Umwandlungsergebnisse für alle 4 Kanäle werden ausgegeben) === Beispielschaltung === Hier ein Beispielschaltung für den DS2450. Kanal A wird als Eingabe genutzt (range = 1). Kanal D wird als Ausgabe genutzt, über den Optokoppler kann die LED geschaltet werden. Der Widerstand R1 muss <b>unbedingt</b> entsprechend dem Optokoppler dimensioniert werden. Beim 4N35 sind 1k3 ausreichend, dann fließt ein Strom von ca. 2,8mA. [[File:DS2450 Beispiel 01.gif|600px|Beispielschaltung DS2450]] 682433a219fb79a44460c563e5e8e3502357cf55 820 818 2012-09-23T15:03:20Z Djmaster 255 wikitext text/x-wiki {{i18n|Onewire_DS2450}} {{Module |NAME=Onewire_DS2450 |MENUCONFIG={{I/O}}->Onewire support |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} *Beitrag am 23.09.2012 erneuert. == Dallas 1-wire DS2450 4 Kanal ADC == Der DS2450 ist ein 4 Kanal ADC mit einer maximalen Auflösung von 16 Bit (vgl. [http://datasheets.maxim-ic.com/en/ds/DS2450.pdf Datenblatt]). Die analog-digital Umwandlung erfolgt durch einen internen four-to-one multiplexer. Kanäle, die nicht als Eingänge genutzt werden, können als Ausgänge (open drain) geschaltet werden (max. 4mA und 6V). === ECMD Interface === Über ECMD sind folgende Befehle für den DS2450 bekannt: *<code>1w ds2450 power</code> *<code>1w ds2450 res</code> *<code>1w ds2450 oc</code> *<code>1w ds2450 oe</code> *<code>1w ds2450 range</code> *<code>1w ds2450 por</code> *<code>1w ds2450 convert</code> *<code>1w ds2450 get</code> ==== Grundsätzliches ==== Grundsätzlich gilt für alle Befehle: * als erstes Argument kann optional die 64 Bit ROM Id des DS2450 angegeben werden, der angesprochen werden soll (match rom). Wird die ROM Id <b>nicht</b> angeben, so werden alle im Bus befindlichen 1-wire Devices (egal welchen Typs) angesprochen (skip rom). Dies macht <b>nur</b> Sinn, wenn sich <b>genau</b> ein Device im 1-wire Bus befindet (skip rom führt bei mehreren Devices unweigerlich dazu, dass mehrere Devices gleichzeitig antworten werden, was zu Bit-Salat beim bus master (d.h. Ethersex) führt, das Datenblatt spricht von "a wired-AND result"). * wird ein Kanal angeben, so ist dieser mit einem Buchstaben (entsprechend Datenblatt) zu bezeichnen (case-insensitiv). * wird mit einem Befehl ein Wert gesetzt, so kann mit dem gleichen Befehl der Wert gelesen werden, in dem man kein Werte-Argument angibt. ==== <code>1w ds2450 power</code> ==== Hierüber wird die Art der Spannungsversorgung des DS2450 gesetzt (global). Dieser Parameter wird durch den Anschluss an der 1-wire Bus bestimmt, vgl. die [[Dallas_1-wire_Bus#Anschluss_AVR-NET-IO | Erklärung der Anschlussmöglichkeiten]]. Wird der 1-wire Bus "normal" (drei-adrig) betrieben, so muss der Wert auf 1 gesetzt werden. Wird der Bus "parasitär" (zwei-adrig) betrieben, muss der Wert auf 0 gesetzt werden. Default-Wert: 0 Beispiel: 1w ds2450 power 1 (der DS250 wird auf "normale" Spannungsversorgung konfiguriert) ==== <code>1w ds2450 res</code> ==== Hierüber wird die Auflösung der analog-digital Umwandlung gesetzt (pro Kanal). Die Auflösung kann zw. 1 und 16 Bit eingestellt werden. Die Eingabe erfolgt als 8 Bit Hexadezimalwert, wobei eine Auflösung von 16 Bit durch den Wert 0x00 oder alternativ 0x10 erreicht wird. Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0x08 Beispiel: 1w ds2450 res c 08 (setzt die Auflösung für Kanal C auf 0x08, d.h. 8 Bit) ==== <code>1w ds2450 oc</code> ==== Hierüber kann der Ausgang ein- oder ausgeschaltet werden (pro Kanal). Voraussetzung ist, dass über [[DS2450#1w_ds2450_oe | 1w ds2450 oe]] der Kanal als Ausgang geschaltet wurde (ansonsten wird das OC-Bit ignoriert). Die Eingabe erfolgt als bool über 0 (Ausgangstransistor leitend) bzw. 1 (Ausgangstransistor nicht-leitend). Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0 Beispiel: 1w ds2450 oc a 1 (der Ausgangstransistor des Kanal A wird leitend) ==== <code>1w ds2450 oe</code> ==== Hierüber kann der Kanal als Ein- oder Ausgang gesetzt werden (pro Kanal). Eine analog-digital Umwandlung ist <b>nur</b> möglich, wenn das OE-Bit auf 0 gesetzt ist. In diesem Fall wird das OC-Bit ignoriert. Ist das OE-Bit auf 1 gesetzt, kann der Ausgang über [[DS2450#1w_ds2450_oc | 1w ds2450 oc]] ein- bzw. ausgeschaltet werden. Die Eingabe erfolgt als bool über 0 (Eingang für ADC) bzw. 1 (Ausgang open drain). Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0 Beispiel: 1w ds2450 oe d 1 (Kanal A wird als Ausgang gesetzt) ==== <code>1w ds2450 range</code> ==== Hierüber kann der Spannungs-Bereich angegeben werden, in dem die analog-digital Umwandlung stattfinden soll. Die Eingabe erfolgt als bool über 0 (Spannungsbereich 0 bis 2,55V) bzw. 1 (Spannungsbereich 0 bis 5,10V). Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0 Beispiel: 1w ds2450 range b 1 (für Kanal B wird bei der analog-digital Umwandlung der Spannungsbereich 0 bis 5,10V genutzt) ==== <code>1w ds2450 por</code> ==== Hierüber kann das power on reset Bit gelesen bzw. gesetzt werden. Nach einem power-on reset cycle setzt der DS2450 das Bit auf 1. Das Bit beeinflusst die conditional search, welche in Ethersex (noch) nicht implementiert ist. Setzt der bus master das Bit auf 0, so nimmt der DS2450 nicht mehr an der conditional search teil Die Eingabe erfolgt als bool über 0 bzw. 1. Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 1 (nach power-on reset cycle) Beispiel: 1w ds2450 por c 0 (für Kanal C wird das power on reset Bit auf 0 gesetzt) FixMe: Es sieht so aus, als kann das Bit nur global gesetzt werden, d.h. wird es für einen Kanal verändert, haben danach alle anderen Kanäle den gleich POR-Bit Wert. Außerdem kann man das Bit nicht mehr auf 1 setzen, wenn es vorher schon auf 0 gesetzt wurde (das widerspricht aber dem Datenblatt!). ==== <code>1w ds2450 convert</code> ==== Hierüber wird die analog-digital Umwandlung ausgelöst (analog den 1-wire Temperatursensoren). Werden keine weiteren Argumente angegeben, so wird die Umwandlung für alle 4 Kanäle des DS2450 durchgeführt (FixMe: vermutlich werden die Kanäle, bei denen das OE-Bit auf 1 steht ausgelassen, dass ist aber nicht durch Dallas dokumentiert). Optional können zwei Argumente angegeben werden (werden Argumente angegeben, <b>müssen beide</b> Argumente angegeben werden!): * input select mask * read-out control ===== input select mask ===== Mit der input select mask kann angegeben werden, für welche Kanäle die analog-digital Umwandlung durchgeführt werden soll. Die input select mask ist ein 8 Bit Hexadezimalwert: {| border=1 cellspacing=0 padding=4 class=wikitable ! bit7 !! bit6 !! bit5 !! bit4 !! bit3 !! bit2 !! bit1 !! bit0 |- | ignore || ignore || ignore || ignore || Kanal D || Kanal C || Kanal B || Kanal A |} Eine input select mask von 0x0f bedeutet also, dass für alle 4 Kanäle die analog-digital Umwandlung durchgeführt werden soll. Eine mask von 0x00 ist (offensichtlich) sinnlos. Eine ungültige input select mask (d.h. input select mask == 0x00 oder > 0x0f) wird erkannt und führt zu einer ECMD-Fehlermeldung. Die analog-digital Umwandlung erfolgt in der Reihenfolge von Kanal A zu Kanal D, wobei die nicht gewünschte Kanäle (sprich jene, wo das input select mask Bit auf 0 steht) übersprungen werden. Der DS2450 braucht für jedes Bit Auflösung ca. 60 bis 80µs. Außerdem braucht das Umwandlung-Kommando generell 160µs (offset) Dies bedeutet, dass eine Umwandlung aller 4 Kanäle bei maximaler 16 Bit Auflösung also nicht länger als 4*16*80+160µs = 5280µs = 5,28ms dauern wird. ===== read out control ===== Mit dem read out control kann angegeben werden, ob und wie das Register für die Ergebnisse der analog-digital Umwandlung vorbelegt werden soll. Das macht nur dann Sinn, wenn die Umwandlungsergebnisse schon gelesen werden sollen, während der DS2450 im Hintergrund noch die analog-digital Umwandlung durchführt (was möglich ist). Das read out control ist ein 8 Bit Hexadezimalwert: {| border=1 cellspacing=0 padding=4 class=wikitable ! bit7 !! bit6 !! bit5 !! bit4 !! bit3 !! bit2 !! bit1 !! bit0 |- | Set D || Clear D || Set C || Clear C || Set B || Clear B || Set A || Clear A |} Set bzw. Clear verhalten sich wie folgt: {| border=1 cellspacing=0 padding=4 class=wikitable ! Set !! Clear !! Ergebnis |- | 0 || 0 || keine Veränderung am Umwandlung-Register |- | 0 || 1 || alle Bits des Umwandlung-Register werden auf 0 gesetzt |- | 1 || 0 || alle Bits des Umwandlung-Register werden auf 1 gesetzt |- | 1 || 1 || invalid |} Ungültige Kombinationen im read out control (d.h. Set = 1 und Clear = 1) werden erkannt und führen zu einer ECMD-Fehlermeldung. Default-Werte: * input select mask: 0x04 * read out control: 0x00 Beispiel: 1w ds2450 convert (für alle Kanäle wird die analog-digital Umwandlung durchgeführt) ==== <code>1w ds2450 get</code> ==== Hierüber wird das Ergebnis der analog-digital Umwandlung ausgelesen (analog den 1-wire Temperatursensoren). Werden keine weiteren Argumente angegeben, so werden die Umwandlungsergebnisse für alle 4 Kanäle des DS2450 ausgegeben. Optional kann ein Kanal angegeben werden, dann wird nur das Umwandlungsergebniss dieses Kanals ausgegeben. Wurde seit dem letzten power-on reset cycle keine Umwandlung durchgeführt, stehen alle Bits der Register auf 0. Die Ausgabe erfolgt als raw (unsigned integer 16 Bit - <code>uint16_t</code>). Die eingelesene Spannung errechnet sich wie folgt (VAL ist die Ausgabe von <code>1w ds2450 get</code>): * für range = 0 (0..2,55V) VAL ------- * 2,55V 2**16-1 * für range = 1 (0..5,10V) VAL ------- * 5,10V 2**16-1 Default-Werte: - Beispiel: 1w ds2450 get (die Umwandlungsergebnisse für alle 4 Kanäle werden ausgegeben) === Beispielschaltung === Hier ein Beispielschaltung für den DS2450. Kanal A wird als Eingabe genutzt (range = 1). Kanal D wird als Ausgabe genutzt, über den Optokoppler kann die LED geschaltet werden. Der Widerstand R1 muss <b>unbedingt</b> entsprechend dem Optokoppler dimensioniert werden. Beim 4N35 sind 1k3 ausreichend, dann fließt ein Strom von ca. 2,8mA. [[File:DS2450 Beispiel 01.gif|600px|Beispielschaltung DS2450]] == Einbindung in Control6 (tcp_send) == https://github.com/ethersex/ethersex/blob/master/hardware/onewire/ds2450.h<br> http://www.tutorials.at/c/03-dateneingabe-ausgabe.html<br> <br> '''"ecmd?1w list"''' ergibt den rom code '''20686414000000b5''' für den ds2450<br> <br> <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "hardware/onewire/ds2450.h" uint16_t counter1 = 0; uint16_t var1 = 0; CONTROL_START CLOCK_USED() THREAD(start) var1 = 1; WAIT(5) var1 = 0; WAIT(5) THREAD_END(start) TCP_HANDLER_PERSIST(message_handler); if (var1 == 1){ ow_rom_code_t rom_code; uint16_t result; rom_code.bytewise[0] = 0x20; rom_code.bytewise[1] = 0x68; rom_code.bytewise[2] = 0x64; rom_code.bytewise[3] = 0x14; rom_code.bytewise[4] = 0x00; rom_code.bytewise[5] = 0x00; rom_code.bytewise[6] = 0x00; rom_code.bytewise[7] = 0xb5; ow_ds2450_convert(&rom_code, 0x0f, 0x00); ow_ds2450_get(&rom_code, 2, 2, &result); TCP_SEND("%u", result); WAIT(15) } TCP_HANDLER_END(); ON STARTUP DO THREAD_START(start) TCP_CONNECT(192.168.123.106, 4445, message_handler); END CONTROL_END </source> 917bb8068ff3a7fa365a526da363e3f1655c207d 824 820 2012-09-23T15:18:51Z Mgue 312 moved [[Onewire DS2450 (Deutsch)]] to [[Onewire/DS2450 (Deutsch)]] wikitext text/x-wiki {{i18n|Onewire_DS2450}} {{Module |NAME=Onewire_DS2450 |MENUCONFIG={{I/O}}->Onewire support |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} *Beitrag am 23.09.2012 erneuert. == Dallas 1-wire DS2450 4 Kanal ADC == Der DS2450 ist ein 4 Kanal ADC mit einer maximalen Auflösung von 16 Bit (vgl. [http://datasheets.maxim-ic.com/en/ds/DS2450.pdf Datenblatt]). Die analog-digital Umwandlung erfolgt durch einen internen four-to-one multiplexer. Kanäle, die nicht als Eingänge genutzt werden, können als Ausgänge (open drain) geschaltet werden (max. 4mA und 6V). === ECMD Interface === Über ECMD sind folgende Befehle für den DS2450 bekannt: *<code>1w ds2450 power</code> *<code>1w ds2450 res</code> *<code>1w ds2450 oc</code> *<code>1w ds2450 oe</code> *<code>1w ds2450 range</code> *<code>1w ds2450 por</code> *<code>1w ds2450 convert</code> *<code>1w ds2450 get</code> ==== Grundsätzliches ==== Grundsätzlich gilt für alle Befehle: * als erstes Argument kann optional die 64 Bit ROM Id des DS2450 angegeben werden, der angesprochen werden soll (match rom). Wird die ROM Id <b>nicht</b> angeben, so werden alle im Bus befindlichen 1-wire Devices (egal welchen Typs) angesprochen (skip rom). Dies macht <b>nur</b> Sinn, wenn sich <b>genau</b> ein Device im 1-wire Bus befindet (skip rom führt bei mehreren Devices unweigerlich dazu, dass mehrere Devices gleichzeitig antworten werden, was zu Bit-Salat beim bus master (d.h. Ethersex) führt, das Datenblatt spricht von "a wired-AND result"). * wird ein Kanal angeben, so ist dieser mit einem Buchstaben (entsprechend Datenblatt) zu bezeichnen (case-insensitiv). * wird mit einem Befehl ein Wert gesetzt, so kann mit dem gleichen Befehl der Wert gelesen werden, in dem man kein Werte-Argument angibt. ==== <code>1w ds2450 power</code> ==== Hierüber wird die Art der Spannungsversorgung des DS2450 gesetzt (global). Dieser Parameter wird durch den Anschluss an der 1-wire Bus bestimmt, vgl. die [[Dallas_1-wire_Bus#Anschluss_AVR-NET-IO | Erklärung der Anschlussmöglichkeiten]]. Wird der 1-wire Bus "normal" (drei-adrig) betrieben, so muss der Wert auf 1 gesetzt werden. Wird der Bus "parasitär" (zwei-adrig) betrieben, muss der Wert auf 0 gesetzt werden. Default-Wert: 0 Beispiel: 1w ds2450 power 1 (der DS250 wird auf "normale" Spannungsversorgung konfiguriert) ==== <code>1w ds2450 res</code> ==== Hierüber wird die Auflösung der analog-digital Umwandlung gesetzt (pro Kanal). Die Auflösung kann zw. 1 und 16 Bit eingestellt werden. Die Eingabe erfolgt als 8 Bit Hexadezimalwert, wobei eine Auflösung von 16 Bit durch den Wert 0x00 oder alternativ 0x10 erreicht wird. Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0x08 Beispiel: 1w ds2450 res c 08 (setzt die Auflösung für Kanal C auf 0x08, d.h. 8 Bit) ==== <code>1w ds2450 oc</code> ==== Hierüber kann der Ausgang ein- oder ausgeschaltet werden (pro Kanal). Voraussetzung ist, dass über [[DS2450#1w_ds2450_oe | 1w ds2450 oe]] der Kanal als Ausgang geschaltet wurde (ansonsten wird das OC-Bit ignoriert). Die Eingabe erfolgt als bool über 0 (Ausgangstransistor leitend) bzw. 1 (Ausgangstransistor nicht-leitend). Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0 Beispiel: 1w ds2450 oc a 1 (der Ausgangstransistor des Kanal A wird leitend) ==== <code>1w ds2450 oe</code> ==== Hierüber kann der Kanal als Ein- oder Ausgang gesetzt werden (pro Kanal). Eine analog-digital Umwandlung ist <b>nur</b> möglich, wenn das OE-Bit auf 0 gesetzt ist. In diesem Fall wird das OC-Bit ignoriert. Ist das OE-Bit auf 1 gesetzt, kann der Ausgang über [[DS2450#1w_ds2450_oc | 1w ds2450 oc]] ein- bzw. ausgeschaltet werden. Die Eingabe erfolgt als bool über 0 (Eingang für ADC) bzw. 1 (Ausgang open drain). Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0 Beispiel: 1w ds2450 oe d 1 (Kanal A wird als Ausgang gesetzt) ==== <code>1w ds2450 range</code> ==== Hierüber kann der Spannungs-Bereich angegeben werden, in dem die analog-digital Umwandlung stattfinden soll. Die Eingabe erfolgt als bool über 0 (Spannungsbereich 0 bis 2,55V) bzw. 1 (Spannungsbereich 0 bis 5,10V). Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0 Beispiel: 1w ds2450 range b 1 (für Kanal B wird bei der analog-digital Umwandlung der Spannungsbereich 0 bis 5,10V genutzt) ==== <code>1w ds2450 por</code> ==== Hierüber kann das power on reset Bit gelesen bzw. gesetzt werden. Nach einem power-on reset cycle setzt der DS2450 das Bit auf 1. Das Bit beeinflusst die conditional search, welche in Ethersex (noch) nicht implementiert ist. Setzt der bus master das Bit auf 0, so nimmt der DS2450 nicht mehr an der conditional search teil Die Eingabe erfolgt als bool über 0 bzw. 1. Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 1 (nach power-on reset cycle) Beispiel: 1w ds2450 por c 0 (für Kanal C wird das power on reset Bit auf 0 gesetzt) FixMe: Es sieht so aus, als kann das Bit nur global gesetzt werden, d.h. wird es für einen Kanal verändert, haben danach alle anderen Kanäle den gleich POR-Bit Wert. Außerdem kann man das Bit nicht mehr auf 1 setzen, wenn es vorher schon auf 0 gesetzt wurde (das widerspricht aber dem Datenblatt!). ==== <code>1w ds2450 convert</code> ==== Hierüber wird die analog-digital Umwandlung ausgelöst (analog den 1-wire Temperatursensoren). Werden keine weiteren Argumente angegeben, so wird die Umwandlung für alle 4 Kanäle des DS2450 durchgeführt (FixMe: vermutlich werden die Kanäle, bei denen das OE-Bit auf 1 steht ausgelassen, dass ist aber nicht durch Dallas dokumentiert). Optional können zwei Argumente angegeben werden (werden Argumente angegeben, <b>müssen beide</b> Argumente angegeben werden!): * input select mask * read-out control ===== input select mask ===== Mit der input select mask kann angegeben werden, für welche Kanäle die analog-digital Umwandlung durchgeführt werden soll. Die input select mask ist ein 8 Bit Hexadezimalwert: {| border=1 cellspacing=0 padding=4 class=wikitable ! bit7 !! bit6 !! bit5 !! bit4 !! bit3 !! bit2 !! bit1 !! bit0 |- | ignore || ignore || ignore || ignore || Kanal D || Kanal C || Kanal B || Kanal A |} Eine input select mask von 0x0f bedeutet also, dass für alle 4 Kanäle die analog-digital Umwandlung durchgeführt werden soll. Eine mask von 0x00 ist (offensichtlich) sinnlos. Eine ungültige input select mask (d.h. input select mask == 0x00 oder > 0x0f) wird erkannt und führt zu einer ECMD-Fehlermeldung. Die analog-digital Umwandlung erfolgt in der Reihenfolge von Kanal A zu Kanal D, wobei die nicht gewünschte Kanäle (sprich jene, wo das input select mask Bit auf 0 steht) übersprungen werden. Der DS2450 braucht für jedes Bit Auflösung ca. 60 bis 80µs. Außerdem braucht das Umwandlung-Kommando generell 160µs (offset) Dies bedeutet, dass eine Umwandlung aller 4 Kanäle bei maximaler 16 Bit Auflösung also nicht länger als 4*16*80+160µs = 5280µs = 5,28ms dauern wird. ===== read out control ===== Mit dem read out control kann angegeben werden, ob und wie das Register für die Ergebnisse der analog-digital Umwandlung vorbelegt werden soll. Das macht nur dann Sinn, wenn die Umwandlungsergebnisse schon gelesen werden sollen, während der DS2450 im Hintergrund noch die analog-digital Umwandlung durchführt (was möglich ist). Das read out control ist ein 8 Bit Hexadezimalwert: {| border=1 cellspacing=0 padding=4 class=wikitable ! bit7 !! bit6 !! bit5 !! bit4 !! bit3 !! bit2 !! bit1 !! bit0 |- | Set D || Clear D || Set C || Clear C || Set B || Clear B || Set A || Clear A |} Set bzw. Clear verhalten sich wie folgt: {| border=1 cellspacing=0 padding=4 class=wikitable ! Set !! Clear !! Ergebnis |- | 0 || 0 || keine Veränderung am Umwandlung-Register |- | 0 || 1 || alle Bits des Umwandlung-Register werden auf 0 gesetzt |- | 1 || 0 || alle Bits des Umwandlung-Register werden auf 1 gesetzt |- | 1 || 1 || invalid |} Ungültige Kombinationen im read out control (d.h. Set = 1 und Clear = 1) werden erkannt und führen zu einer ECMD-Fehlermeldung. Default-Werte: * input select mask: 0x04 * read out control: 0x00 Beispiel: 1w ds2450 convert (für alle Kanäle wird die analog-digital Umwandlung durchgeführt) ==== <code>1w ds2450 get</code> ==== Hierüber wird das Ergebnis der analog-digital Umwandlung ausgelesen (analog den 1-wire Temperatursensoren). Werden keine weiteren Argumente angegeben, so werden die Umwandlungsergebnisse für alle 4 Kanäle des DS2450 ausgegeben. Optional kann ein Kanal angegeben werden, dann wird nur das Umwandlungsergebniss dieses Kanals ausgegeben. Wurde seit dem letzten power-on reset cycle keine Umwandlung durchgeführt, stehen alle Bits der Register auf 0. Die Ausgabe erfolgt als raw (unsigned integer 16 Bit - <code>uint16_t</code>). Die eingelesene Spannung errechnet sich wie folgt (VAL ist die Ausgabe von <code>1w ds2450 get</code>): * für range = 0 (0..2,55V) VAL ------- * 2,55V 2**16-1 * für range = 1 (0..5,10V) VAL ------- * 5,10V 2**16-1 Default-Werte: - Beispiel: 1w ds2450 get (die Umwandlungsergebnisse für alle 4 Kanäle werden ausgegeben) === Beispielschaltung === Hier ein Beispielschaltung für den DS2450. Kanal A wird als Eingabe genutzt (range = 1). Kanal D wird als Ausgabe genutzt, über den Optokoppler kann die LED geschaltet werden. Der Widerstand R1 muss <b>unbedingt</b> entsprechend dem Optokoppler dimensioniert werden. Beim 4N35 sind 1k3 ausreichend, dann fließt ein Strom von ca. 2,8mA. [[File:DS2450 Beispiel 01.gif|600px|Beispielschaltung DS2450]] == Einbindung in Control6 (tcp_send) == https://github.com/ethersex/ethersex/blob/master/hardware/onewire/ds2450.h<br> http://www.tutorials.at/c/03-dateneingabe-ausgabe.html<br> <br> '''"ecmd?1w list"''' ergibt den rom code '''20686414000000b5''' für den ds2450<br> <br> <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "hardware/onewire/ds2450.h" uint16_t counter1 = 0; uint16_t var1 = 0; CONTROL_START CLOCK_USED() THREAD(start) var1 = 1; WAIT(5) var1 = 0; WAIT(5) THREAD_END(start) TCP_HANDLER_PERSIST(message_handler); if (var1 == 1){ ow_rom_code_t rom_code; uint16_t result; rom_code.bytewise[0] = 0x20; rom_code.bytewise[1] = 0x68; rom_code.bytewise[2] = 0x64; rom_code.bytewise[3] = 0x14; rom_code.bytewise[4] = 0x00; rom_code.bytewise[5] = 0x00; rom_code.bytewise[6] = 0x00; rom_code.bytewise[7] = 0xb5; ow_ds2450_convert(&rom_code, 0x0f, 0x00); ow_ds2450_get(&rom_code, 2, 2, &result); TCP_SEND("%u", result); WAIT(15) } TCP_HANDLER_END(); ON STARTUP DO THREAD_START(start) TCP_CONNECT(192.168.123.106, 4445, message_handler); END CONTROL_END </source> 917bb8068ff3a7fa365a526da363e3f1655c207d 826 824 2012-09-23T15:19:31Z Mgue 312 Change Title wikitext text/x-wiki {{i18n|Onewire/DS2450}} {{Module |NAME=Onewire DS2450 |MENUCONFIG={{I/O}}->Onewire support |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} *Beitrag am 23.09.2012 erneuert. == Dallas 1-wire DS2450 4 Kanal ADC == Der DS2450 ist ein 4 Kanal ADC mit einer maximalen Auflösung von 16 Bit (vgl. [http://datasheets.maxim-ic.com/en/ds/DS2450.pdf Datenblatt]). Die analog-digital Umwandlung erfolgt durch einen internen four-to-one multiplexer. Kanäle, die nicht als Eingänge genutzt werden, können als Ausgänge (open drain) geschaltet werden (max. 4mA und 6V). === ECMD Interface === Über ECMD sind folgende Befehle für den DS2450 bekannt: *<code>1w ds2450 power</code> *<code>1w ds2450 res</code> *<code>1w ds2450 oc</code> *<code>1w ds2450 oe</code> *<code>1w ds2450 range</code> *<code>1w ds2450 por</code> *<code>1w ds2450 convert</code> *<code>1w ds2450 get</code> ==== Grundsätzliches ==== Grundsätzlich gilt für alle Befehle: * als erstes Argument kann optional die 64 Bit ROM Id des DS2450 angegeben werden, der angesprochen werden soll (match rom). Wird die ROM Id <b>nicht</b> angeben, so werden alle im Bus befindlichen 1-wire Devices (egal welchen Typs) angesprochen (skip rom). Dies macht <b>nur</b> Sinn, wenn sich <b>genau</b> ein Device im 1-wire Bus befindet (skip rom führt bei mehreren Devices unweigerlich dazu, dass mehrere Devices gleichzeitig antworten werden, was zu Bit-Salat beim bus master (d.h. Ethersex) führt, das Datenblatt spricht von "a wired-AND result"). * wird ein Kanal angeben, so ist dieser mit einem Buchstaben (entsprechend Datenblatt) zu bezeichnen (case-insensitiv). * wird mit einem Befehl ein Wert gesetzt, so kann mit dem gleichen Befehl der Wert gelesen werden, in dem man kein Werte-Argument angibt. ==== <code>1w ds2450 power</code> ==== Hierüber wird die Art der Spannungsversorgung des DS2450 gesetzt (global). Dieser Parameter wird durch den Anschluss an der 1-wire Bus bestimmt, vgl. die [[Dallas_1-wire_Bus#Anschluss_AVR-NET-IO | Erklärung der Anschlussmöglichkeiten]]. Wird der 1-wire Bus "normal" (drei-adrig) betrieben, so muss der Wert auf 1 gesetzt werden. Wird der Bus "parasitär" (zwei-adrig) betrieben, muss der Wert auf 0 gesetzt werden. Default-Wert: 0 Beispiel: 1w ds2450 power 1 (der DS250 wird auf "normale" Spannungsversorgung konfiguriert) ==== <code>1w ds2450 res</code> ==== Hierüber wird die Auflösung der analog-digital Umwandlung gesetzt (pro Kanal). Die Auflösung kann zw. 1 und 16 Bit eingestellt werden. Die Eingabe erfolgt als 8 Bit Hexadezimalwert, wobei eine Auflösung von 16 Bit durch den Wert 0x00 oder alternativ 0x10 erreicht wird. Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0x08 Beispiel: 1w ds2450 res c 08 (setzt die Auflösung für Kanal C auf 0x08, d.h. 8 Bit) ==== <code>1w ds2450 oc</code> ==== Hierüber kann der Ausgang ein- oder ausgeschaltet werden (pro Kanal). Voraussetzung ist, dass über [[DS2450#1w_ds2450_oe | 1w ds2450 oe]] der Kanal als Ausgang geschaltet wurde (ansonsten wird das OC-Bit ignoriert). Die Eingabe erfolgt als bool über 0 (Ausgangstransistor leitend) bzw. 1 (Ausgangstransistor nicht-leitend). Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0 Beispiel: 1w ds2450 oc a 1 (der Ausgangstransistor des Kanal A wird leitend) ==== <code>1w ds2450 oe</code> ==== Hierüber kann der Kanal als Ein- oder Ausgang gesetzt werden (pro Kanal). Eine analog-digital Umwandlung ist <b>nur</b> möglich, wenn das OE-Bit auf 0 gesetzt ist. In diesem Fall wird das OC-Bit ignoriert. Ist das OE-Bit auf 1 gesetzt, kann der Ausgang über [[DS2450#1w_ds2450_oc | 1w ds2450 oc]] ein- bzw. ausgeschaltet werden. Die Eingabe erfolgt als bool über 0 (Eingang für ADC) bzw. 1 (Ausgang open drain). Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0 Beispiel: 1w ds2450 oe d 1 (Kanal A wird als Ausgang gesetzt) ==== <code>1w ds2450 range</code> ==== Hierüber kann der Spannungs-Bereich angegeben werden, in dem die analog-digital Umwandlung stattfinden soll. Die Eingabe erfolgt als bool über 0 (Spannungsbereich 0 bis 2,55V) bzw. 1 (Spannungsbereich 0 bis 5,10V). Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0 Beispiel: 1w ds2450 range b 1 (für Kanal B wird bei der analog-digital Umwandlung der Spannungsbereich 0 bis 5,10V genutzt) ==== <code>1w ds2450 por</code> ==== Hierüber kann das power on reset Bit gelesen bzw. gesetzt werden. Nach einem power-on reset cycle setzt der DS2450 das Bit auf 1. Das Bit beeinflusst die conditional search, welche in Ethersex (noch) nicht implementiert ist. Setzt der bus master das Bit auf 0, so nimmt der DS2450 nicht mehr an der conditional search teil Die Eingabe erfolgt als bool über 0 bzw. 1. Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 1 (nach power-on reset cycle) Beispiel: 1w ds2450 por c 0 (für Kanal C wird das power on reset Bit auf 0 gesetzt) FixMe: Es sieht so aus, als kann das Bit nur global gesetzt werden, d.h. wird es für einen Kanal verändert, haben danach alle anderen Kanäle den gleich POR-Bit Wert. Außerdem kann man das Bit nicht mehr auf 1 setzen, wenn es vorher schon auf 0 gesetzt wurde (das widerspricht aber dem Datenblatt!). ==== <code>1w ds2450 convert</code> ==== Hierüber wird die analog-digital Umwandlung ausgelöst (analog den 1-wire Temperatursensoren). Werden keine weiteren Argumente angegeben, so wird die Umwandlung für alle 4 Kanäle des DS2450 durchgeführt (FixMe: vermutlich werden die Kanäle, bei denen das OE-Bit auf 1 steht ausgelassen, dass ist aber nicht durch Dallas dokumentiert). Optional können zwei Argumente angegeben werden (werden Argumente angegeben, <b>müssen beide</b> Argumente angegeben werden!): * input select mask * read-out control ===== input select mask ===== Mit der input select mask kann angegeben werden, für welche Kanäle die analog-digital Umwandlung durchgeführt werden soll. Die input select mask ist ein 8 Bit Hexadezimalwert: {| border=1 cellspacing=0 padding=4 class=wikitable ! bit7 !! bit6 !! bit5 !! bit4 !! bit3 !! bit2 !! bit1 !! bit0 |- | ignore || ignore || ignore || ignore || Kanal D || Kanal C || Kanal B || Kanal A |} Eine input select mask von 0x0f bedeutet also, dass für alle 4 Kanäle die analog-digital Umwandlung durchgeführt werden soll. Eine mask von 0x00 ist (offensichtlich) sinnlos. Eine ungültige input select mask (d.h. input select mask == 0x00 oder > 0x0f) wird erkannt und führt zu einer ECMD-Fehlermeldung. Die analog-digital Umwandlung erfolgt in der Reihenfolge von Kanal A zu Kanal D, wobei die nicht gewünschte Kanäle (sprich jene, wo das input select mask Bit auf 0 steht) übersprungen werden. Der DS2450 braucht für jedes Bit Auflösung ca. 60 bis 80µs. Außerdem braucht das Umwandlung-Kommando generell 160µs (offset) Dies bedeutet, dass eine Umwandlung aller 4 Kanäle bei maximaler 16 Bit Auflösung also nicht länger als 4*16*80+160µs = 5280µs = 5,28ms dauern wird. ===== read out control ===== Mit dem read out control kann angegeben werden, ob und wie das Register für die Ergebnisse der analog-digital Umwandlung vorbelegt werden soll. Das macht nur dann Sinn, wenn die Umwandlungsergebnisse schon gelesen werden sollen, während der DS2450 im Hintergrund noch die analog-digital Umwandlung durchführt (was möglich ist). Das read out control ist ein 8 Bit Hexadezimalwert: {| border=1 cellspacing=0 padding=4 class=wikitable ! bit7 !! bit6 !! bit5 !! bit4 !! bit3 !! bit2 !! bit1 !! bit0 |- | Set D || Clear D || Set C || Clear C || Set B || Clear B || Set A || Clear A |} Set bzw. Clear verhalten sich wie folgt: {| border=1 cellspacing=0 padding=4 class=wikitable ! Set !! Clear !! Ergebnis |- | 0 || 0 || keine Veränderung am Umwandlung-Register |- | 0 || 1 || alle Bits des Umwandlung-Register werden auf 0 gesetzt |- | 1 || 0 || alle Bits des Umwandlung-Register werden auf 1 gesetzt |- | 1 || 1 || invalid |} Ungültige Kombinationen im read out control (d.h. Set = 1 und Clear = 1) werden erkannt und führen zu einer ECMD-Fehlermeldung. Default-Werte: * input select mask: 0x04 * read out control: 0x00 Beispiel: 1w ds2450 convert (für alle Kanäle wird die analog-digital Umwandlung durchgeführt) ==== <code>1w ds2450 get</code> ==== Hierüber wird das Ergebnis der analog-digital Umwandlung ausgelesen (analog den 1-wire Temperatursensoren). Werden keine weiteren Argumente angegeben, so werden die Umwandlungsergebnisse für alle 4 Kanäle des DS2450 ausgegeben. Optional kann ein Kanal angegeben werden, dann wird nur das Umwandlungsergebniss dieses Kanals ausgegeben. Wurde seit dem letzten power-on reset cycle keine Umwandlung durchgeführt, stehen alle Bits der Register auf 0. Die Ausgabe erfolgt als raw (unsigned integer 16 Bit - <code>uint16_t</code>). Die eingelesene Spannung errechnet sich wie folgt (VAL ist die Ausgabe von <code>1w ds2450 get</code>): * für range = 0 (0..2,55V) VAL ------- * 2,55V 2**16-1 * für range = 1 (0..5,10V) VAL ------- * 5,10V 2**16-1 Default-Werte: - Beispiel: 1w ds2450 get (die Umwandlungsergebnisse für alle 4 Kanäle werden ausgegeben) === Beispielschaltung === Hier ein Beispielschaltung für den DS2450. Kanal A wird als Eingabe genutzt (range = 1). Kanal D wird als Ausgabe genutzt, über den Optokoppler kann die LED geschaltet werden. Der Widerstand R1 muss <b>unbedingt</b> entsprechend dem Optokoppler dimensioniert werden. Beim 4N35 sind 1k3 ausreichend, dann fließt ein Strom von ca. 2,8mA. [[File:DS2450 Beispiel 01.gif|600px|Beispielschaltung DS2450]] == Einbindung in Control6 (tcp_send) == https://github.com/ethersex/ethersex/blob/master/hardware/onewire/ds2450.h<br> http://www.tutorials.at/c/03-dateneingabe-ausgabe.html<br> <br> '''"ecmd?1w list"''' ergibt den rom code '''20686414000000b5''' für den ds2450<br> <br> <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "hardware/onewire/ds2450.h" uint16_t counter1 = 0; uint16_t var1 = 0; CONTROL_START CLOCK_USED() THREAD(start) var1 = 1; WAIT(5) var1 = 0; WAIT(5) THREAD_END(start) TCP_HANDLER_PERSIST(message_handler); if (var1 == 1){ ow_rom_code_t rom_code; uint16_t result; rom_code.bytewise[0] = 0x20; rom_code.bytewise[1] = 0x68; rom_code.bytewise[2] = 0x64; rom_code.bytewise[3] = 0x14; rom_code.bytewise[4] = 0x00; rom_code.bytewise[5] = 0x00; rom_code.bytewise[6] = 0x00; rom_code.bytewise[7] = 0xb5; ow_ds2450_convert(&rom_code, 0x0f, 0x00); ow_ds2450_get(&rom_code, 2, 2, &result); TCP_SEND("%u", result); WAIT(15) } TCP_HANDLER_END(); ON STARTUP DO THREAD_START(start) TCP_CONNECT(192.168.123.106, 4445, message_handler); END CONTROL_END </source> 794812717e105939ae89fc5802223fb88295a969 831 826 2012-09-23T21:03:42Z Djmaster 255 /* Einbindung in Control6 (tcp_send) */ wikitext text/x-wiki {{i18n|Onewire/DS2450}} {{Module |NAME=Onewire DS2450 |MENUCONFIG={{I/O}}->Onewire support |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} *Beitrag am 23.09.2012 erneuert. == Dallas 1-wire DS2450 4 Kanal ADC == Der DS2450 ist ein 4 Kanal ADC mit einer maximalen Auflösung von 16 Bit (vgl. [http://datasheets.maxim-ic.com/en/ds/DS2450.pdf Datenblatt]). Die analog-digital Umwandlung erfolgt durch einen internen four-to-one multiplexer. Kanäle, die nicht als Eingänge genutzt werden, können als Ausgänge (open drain) geschaltet werden (max. 4mA und 6V). === ECMD Interface === Über ECMD sind folgende Befehle für den DS2450 bekannt: *<code>1w ds2450 power</code> *<code>1w ds2450 res</code> *<code>1w ds2450 oc</code> *<code>1w ds2450 oe</code> *<code>1w ds2450 range</code> *<code>1w ds2450 por</code> *<code>1w ds2450 convert</code> *<code>1w ds2450 get</code> ==== Grundsätzliches ==== Grundsätzlich gilt für alle Befehle: * als erstes Argument kann optional die 64 Bit ROM Id des DS2450 angegeben werden, der angesprochen werden soll (match rom). Wird die ROM Id <b>nicht</b> angeben, so werden alle im Bus befindlichen 1-wire Devices (egal welchen Typs) angesprochen (skip rom). Dies macht <b>nur</b> Sinn, wenn sich <b>genau</b> ein Device im 1-wire Bus befindet (skip rom führt bei mehreren Devices unweigerlich dazu, dass mehrere Devices gleichzeitig antworten werden, was zu Bit-Salat beim bus master (d.h. Ethersex) führt, das Datenblatt spricht von "a wired-AND result"). * wird ein Kanal angeben, so ist dieser mit einem Buchstaben (entsprechend Datenblatt) zu bezeichnen (case-insensitiv). * wird mit einem Befehl ein Wert gesetzt, so kann mit dem gleichen Befehl der Wert gelesen werden, in dem man kein Werte-Argument angibt. ==== <code>1w ds2450 power</code> ==== Hierüber wird die Art der Spannungsversorgung des DS2450 gesetzt (global). Dieser Parameter wird durch den Anschluss an der 1-wire Bus bestimmt, vgl. die [[Dallas_1-wire_Bus#Anschluss_AVR-NET-IO | Erklärung der Anschlussmöglichkeiten]]. Wird der 1-wire Bus "normal" (drei-adrig) betrieben, so muss der Wert auf 1 gesetzt werden. Wird der Bus "parasitär" (zwei-adrig) betrieben, muss der Wert auf 0 gesetzt werden. Default-Wert: 0 Beispiel: 1w ds2450 power 1 (der DS250 wird auf "normale" Spannungsversorgung konfiguriert) ==== <code>1w ds2450 res</code> ==== Hierüber wird die Auflösung der analog-digital Umwandlung gesetzt (pro Kanal). Die Auflösung kann zw. 1 und 16 Bit eingestellt werden. Die Eingabe erfolgt als 8 Bit Hexadezimalwert, wobei eine Auflösung von 16 Bit durch den Wert 0x00 oder alternativ 0x10 erreicht wird. Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0x08 Beispiel: 1w ds2450 res c 08 (setzt die Auflösung für Kanal C auf 0x08, d.h. 8 Bit) ==== <code>1w ds2450 oc</code> ==== Hierüber kann der Ausgang ein- oder ausgeschaltet werden (pro Kanal). Voraussetzung ist, dass über [[DS2450#1w_ds2450_oe | 1w ds2450 oe]] der Kanal als Ausgang geschaltet wurde (ansonsten wird das OC-Bit ignoriert). Die Eingabe erfolgt als bool über 0 (Ausgangstransistor leitend) bzw. 1 (Ausgangstransistor nicht-leitend). Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0 Beispiel: 1w ds2450 oc a 1 (der Ausgangstransistor des Kanal A wird leitend) ==== <code>1w ds2450 oe</code> ==== Hierüber kann der Kanal als Ein- oder Ausgang gesetzt werden (pro Kanal). Eine analog-digital Umwandlung ist <b>nur</b> möglich, wenn das OE-Bit auf 0 gesetzt ist. In diesem Fall wird das OC-Bit ignoriert. Ist das OE-Bit auf 1 gesetzt, kann der Ausgang über [[DS2450#1w_ds2450_oc | 1w ds2450 oc]] ein- bzw. ausgeschaltet werden. Die Eingabe erfolgt als bool über 0 (Eingang für ADC) bzw. 1 (Ausgang open drain). Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0 Beispiel: 1w ds2450 oe d 1 (Kanal A wird als Ausgang gesetzt) ==== <code>1w ds2450 range</code> ==== Hierüber kann der Spannungs-Bereich angegeben werden, in dem die analog-digital Umwandlung stattfinden soll. Die Eingabe erfolgt als bool über 0 (Spannungsbereich 0 bis 2,55V) bzw. 1 (Spannungsbereich 0 bis 5,10V). Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0 Beispiel: 1w ds2450 range b 1 (für Kanal B wird bei der analog-digital Umwandlung der Spannungsbereich 0 bis 5,10V genutzt) ==== <code>1w ds2450 por</code> ==== Hierüber kann das power on reset Bit gelesen bzw. gesetzt werden. Nach einem power-on reset cycle setzt der DS2450 das Bit auf 1. Das Bit beeinflusst die conditional search, welche in Ethersex (noch) nicht implementiert ist. Setzt der bus master das Bit auf 0, so nimmt der DS2450 nicht mehr an der conditional search teil Die Eingabe erfolgt als bool über 0 bzw. 1. Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 1 (nach power-on reset cycle) Beispiel: 1w ds2450 por c 0 (für Kanal C wird das power on reset Bit auf 0 gesetzt) FixMe: Es sieht so aus, als kann das Bit nur global gesetzt werden, d.h. wird es für einen Kanal verändert, haben danach alle anderen Kanäle den gleich POR-Bit Wert. Außerdem kann man das Bit nicht mehr auf 1 setzen, wenn es vorher schon auf 0 gesetzt wurde (das widerspricht aber dem Datenblatt!). ==== <code>1w ds2450 convert</code> ==== Hierüber wird die analog-digital Umwandlung ausgelöst (analog den 1-wire Temperatursensoren). Werden keine weiteren Argumente angegeben, so wird die Umwandlung für alle 4 Kanäle des DS2450 durchgeführt (FixMe: vermutlich werden die Kanäle, bei denen das OE-Bit auf 1 steht ausgelassen, dass ist aber nicht durch Dallas dokumentiert). Optional können zwei Argumente angegeben werden (werden Argumente angegeben, <b>müssen beide</b> Argumente angegeben werden!): * input select mask * read-out control ===== input select mask ===== Mit der input select mask kann angegeben werden, für welche Kanäle die analog-digital Umwandlung durchgeführt werden soll. Die input select mask ist ein 8 Bit Hexadezimalwert: {| border=1 cellspacing=0 padding=4 class=wikitable ! bit7 !! bit6 !! bit5 !! bit4 !! bit3 !! bit2 !! bit1 !! bit0 |- | ignore || ignore || ignore || ignore || Kanal D || Kanal C || Kanal B || Kanal A |} Eine input select mask von 0x0f bedeutet also, dass für alle 4 Kanäle die analog-digital Umwandlung durchgeführt werden soll. Eine mask von 0x00 ist (offensichtlich) sinnlos. Eine ungültige input select mask (d.h. input select mask == 0x00 oder > 0x0f) wird erkannt und führt zu einer ECMD-Fehlermeldung. Die analog-digital Umwandlung erfolgt in der Reihenfolge von Kanal A zu Kanal D, wobei die nicht gewünschte Kanäle (sprich jene, wo das input select mask Bit auf 0 steht) übersprungen werden. Der DS2450 braucht für jedes Bit Auflösung ca. 60 bis 80µs. Außerdem braucht das Umwandlung-Kommando generell 160µs (offset) Dies bedeutet, dass eine Umwandlung aller 4 Kanäle bei maximaler 16 Bit Auflösung also nicht länger als 4*16*80+160µs = 5280µs = 5,28ms dauern wird. ===== read out control ===== Mit dem read out control kann angegeben werden, ob und wie das Register für die Ergebnisse der analog-digital Umwandlung vorbelegt werden soll. Das macht nur dann Sinn, wenn die Umwandlungsergebnisse schon gelesen werden sollen, während der DS2450 im Hintergrund noch die analog-digital Umwandlung durchführt (was möglich ist). Das read out control ist ein 8 Bit Hexadezimalwert: {| border=1 cellspacing=0 padding=4 class=wikitable ! bit7 !! bit6 !! bit5 !! bit4 !! bit3 !! bit2 !! bit1 !! bit0 |- | Set D || Clear D || Set C || Clear C || Set B || Clear B || Set A || Clear A |} Set bzw. Clear verhalten sich wie folgt: {| border=1 cellspacing=0 padding=4 class=wikitable ! Set !! Clear !! Ergebnis |- | 0 || 0 || keine Veränderung am Umwandlung-Register |- | 0 || 1 || alle Bits des Umwandlung-Register werden auf 0 gesetzt |- | 1 || 0 || alle Bits des Umwandlung-Register werden auf 1 gesetzt |- | 1 || 1 || invalid |} Ungültige Kombinationen im read out control (d.h. Set = 1 und Clear = 1) werden erkannt und führen zu einer ECMD-Fehlermeldung. Default-Werte: * input select mask: 0x04 * read out control: 0x00 Beispiel: 1w ds2450 convert (für alle Kanäle wird die analog-digital Umwandlung durchgeführt) ==== <code>1w ds2450 get</code> ==== Hierüber wird das Ergebnis der analog-digital Umwandlung ausgelesen (analog den 1-wire Temperatursensoren). Werden keine weiteren Argumente angegeben, so werden die Umwandlungsergebnisse für alle 4 Kanäle des DS2450 ausgegeben. Optional kann ein Kanal angegeben werden, dann wird nur das Umwandlungsergebniss dieses Kanals ausgegeben. Wurde seit dem letzten power-on reset cycle keine Umwandlung durchgeführt, stehen alle Bits der Register auf 0. Die Ausgabe erfolgt als raw (unsigned integer 16 Bit - <code>uint16_t</code>). Die eingelesene Spannung errechnet sich wie folgt (VAL ist die Ausgabe von <code>1w ds2450 get</code>): * für range = 0 (0..2,55V) VAL ------- * 2,55V 2**16-1 * für range = 1 (0..5,10V) VAL ------- * 5,10V 2**16-1 Default-Werte: - Beispiel: 1w ds2450 get (die Umwandlungsergebnisse für alle 4 Kanäle werden ausgegeben) === Beispielschaltung === Hier ein Beispielschaltung für den DS2450. Kanal A wird als Eingabe genutzt (range = 1). Kanal D wird als Ausgabe genutzt, über den Optokoppler kann die LED geschaltet werden. Der Widerstand R1 muss <b>unbedingt</b> entsprechend dem Optokoppler dimensioniert werden. Beim 4N35 sind 1k3 ausreichend, dann fließt ein Strom von ca. 2,8mA. [[File:DS2450 Beispiel 01.gif|600px|Beispielschaltung DS2450]] == Einbindung in Control6 (tcp_send) == https://github.com/ethersex/ethersex/blob/master/hardware/onewire/ds2450.h<br> http://www.tutorials.at/c/03-dateneingabe-ausgabe.html<br> <br> '''"ecmd?1w list"''' ergibt den rom code '''20686414000000b5''' für den ds2450<br> <br> <pre><nowiki> C6_HEADER(`/* This will be in control6.h */') #include "hardware/onewire/ds2450.h" uint16_t counter1 = 0; uint16_t var1 = 0; CONTROL_START CLOCK_USED() THREAD(start) var1 = 1; WAIT(5) var1 = 0; WAIT(5) THREAD_END(start) TCP_HANDLER_PERSIST(message_handler); if (var1 == 1){ ow_rom_code_t rom_code; uint16_t result; rom_code.bytewise[0] = 0x20; rom_code.bytewise[1] = 0x68; rom_code.bytewise[2] = 0x64; rom_code.bytewise[3] = 0x14; rom_code.bytewise[4] = 0x00; rom_code.bytewise[5] = 0x00; rom_code.bytewise[6] = 0x00; rom_code.bytewise[7] = 0xb5; ow_ds2450_convert(&rom_code, 0x0f, 0x00); ow_ds2450_get(&rom_code, 2, 2, &result); TCP_SEND("%u", result); WAIT(15) } TCP_HANDLER_END(); ON STARTUP DO THREAD_START(start) TCP_CONNECT(192.168.123.106, 4445, message_handler); END CONTROL_END </nowiki></pre> a72033905a2d456c7e744ed228df646da3da6733 832 831 2012-09-24T06:44:05Z Djmaster 255 /* 1w ds2450 oe */ wikitext text/x-wiki {{i18n|Onewire/DS2450}} {{Module |NAME=Onewire DS2450 |MENUCONFIG={{I/O}}->Onewire support |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} *Beitrag am 23.09.2012 erneuert. == Dallas 1-wire DS2450 4 Kanal ADC == Der DS2450 ist ein 4 Kanal ADC mit einer maximalen Auflösung von 16 Bit (vgl. [http://datasheets.maxim-ic.com/en/ds/DS2450.pdf Datenblatt]). Die analog-digital Umwandlung erfolgt durch einen internen four-to-one multiplexer. Kanäle, die nicht als Eingänge genutzt werden, können als Ausgänge (open drain) geschaltet werden (max. 4mA und 6V). === ECMD Interface === Über ECMD sind folgende Befehle für den DS2450 bekannt: *<code>1w ds2450 power</code> *<code>1w ds2450 res</code> *<code>1w ds2450 oc</code> *<code>1w ds2450 oe</code> *<code>1w ds2450 range</code> *<code>1w ds2450 por</code> *<code>1w ds2450 convert</code> *<code>1w ds2450 get</code> ==== Grundsätzliches ==== Grundsätzlich gilt für alle Befehle: * als erstes Argument kann optional die 64 Bit ROM Id des DS2450 angegeben werden, der angesprochen werden soll (match rom). Wird die ROM Id <b>nicht</b> angeben, so werden alle im Bus befindlichen 1-wire Devices (egal welchen Typs) angesprochen (skip rom). Dies macht <b>nur</b> Sinn, wenn sich <b>genau</b> ein Device im 1-wire Bus befindet (skip rom führt bei mehreren Devices unweigerlich dazu, dass mehrere Devices gleichzeitig antworten werden, was zu Bit-Salat beim bus master (d.h. Ethersex) führt, das Datenblatt spricht von "a wired-AND result"). * wird ein Kanal angeben, so ist dieser mit einem Buchstaben (entsprechend Datenblatt) zu bezeichnen (case-insensitiv). * wird mit einem Befehl ein Wert gesetzt, so kann mit dem gleichen Befehl der Wert gelesen werden, in dem man kein Werte-Argument angibt. ==== <code>1w ds2450 power</code> ==== Hierüber wird die Art der Spannungsversorgung des DS2450 gesetzt (global). Dieser Parameter wird durch den Anschluss an der 1-wire Bus bestimmt, vgl. die [[Dallas_1-wire_Bus#Anschluss_AVR-NET-IO | Erklärung der Anschlussmöglichkeiten]]. Wird der 1-wire Bus "normal" (drei-adrig) betrieben, so muss der Wert auf 1 gesetzt werden. Wird der Bus "parasitär" (zwei-adrig) betrieben, muss der Wert auf 0 gesetzt werden. Default-Wert: 0 Beispiel: 1w ds2450 power 1 (der DS250 wird auf "normale" Spannungsversorgung konfiguriert) ==== <code>1w ds2450 res</code> ==== Hierüber wird die Auflösung der analog-digital Umwandlung gesetzt (pro Kanal). Die Auflösung kann zw. 1 und 16 Bit eingestellt werden. Die Eingabe erfolgt als 8 Bit Hexadezimalwert, wobei eine Auflösung von 16 Bit durch den Wert 0x00 oder alternativ 0x10 erreicht wird. Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0x08 Beispiel: 1w ds2450 res c 08 (setzt die Auflösung für Kanal C auf 0x08, d.h. 8 Bit) ==== <code>1w ds2450 oc</code> ==== Hierüber kann der Ausgang ein- oder ausgeschaltet werden (pro Kanal). Voraussetzung ist, dass über [[DS2450#1w_ds2450_oe | 1w ds2450 oe]] der Kanal als Ausgang geschaltet wurde (ansonsten wird das OC-Bit ignoriert). Die Eingabe erfolgt als bool über 0 (Ausgangstransistor leitend) bzw. 1 (Ausgangstransistor nicht-leitend). Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0 Beispiel: 1w ds2450 oc a 1 (der Ausgangstransistor des Kanal A wird leitend) ==== <code>1w ds2450 oe</code> ==== Hierüber kann der Kanal als Ein- oder Ausgang gesetzt werden (pro Kanal). Eine analog-digital Umwandlung ist <b>nur</b> möglich, wenn das OE-Bit auf 0 gesetzt ist. In diesem Fall wird das OC-Bit ignoriert. Ist das OE-Bit auf 1 gesetzt, kann der Ausgang über 1w ds2450 oc ein- bzw. ausgeschaltet werden. Die Eingabe erfolgt als bool über 0 (Eingang für ADC) bzw. 1 (Ausgang open drain). Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0 Beispiel: 1w ds2450 oe d 1 (Kanal A wird als Ausgang gesetzt) ==== <code>1w ds2450 range</code> ==== Hierüber kann der Spannungs-Bereich angegeben werden, in dem die analog-digital Umwandlung stattfinden soll. Die Eingabe erfolgt als bool über 0 (Spannungsbereich 0 bis 2,55V) bzw. 1 (Spannungsbereich 0 bis 5,10V). Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0 Beispiel: 1w ds2450 range b 1 (für Kanal B wird bei der analog-digital Umwandlung der Spannungsbereich 0 bis 5,10V genutzt) ==== <code>1w ds2450 por</code> ==== Hierüber kann das power on reset Bit gelesen bzw. gesetzt werden. Nach einem power-on reset cycle setzt der DS2450 das Bit auf 1. Das Bit beeinflusst die conditional search, welche in Ethersex (noch) nicht implementiert ist. Setzt der bus master das Bit auf 0, so nimmt der DS2450 nicht mehr an der conditional search teil Die Eingabe erfolgt als bool über 0 bzw. 1. Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 1 (nach power-on reset cycle) Beispiel: 1w ds2450 por c 0 (für Kanal C wird das power on reset Bit auf 0 gesetzt) FixMe: Es sieht so aus, als kann das Bit nur global gesetzt werden, d.h. wird es für einen Kanal verändert, haben danach alle anderen Kanäle den gleich POR-Bit Wert. Außerdem kann man das Bit nicht mehr auf 1 setzen, wenn es vorher schon auf 0 gesetzt wurde (das widerspricht aber dem Datenblatt!). ==== <code>1w ds2450 convert</code> ==== Hierüber wird die analog-digital Umwandlung ausgelöst (analog den 1-wire Temperatursensoren). Werden keine weiteren Argumente angegeben, so wird die Umwandlung für alle 4 Kanäle des DS2450 durchgeführt (FixMe: vermutlich werden die Kanäle, bei denen das OE-Bit auf 1 steht ausgelassen, dass ist aber nicht durch Dallas dokumentiert). Optional können zwei Argumente angegeben werden (werden Argumente angegeben, <b>müssen beide</b> Argumente angegeben werden!): * input select mask * read-out control ===== input select mask ===== Mit der input select mask kann angegeben werden, für welche Kanäle die analog-digital Umwandlung durchgeführt werden soll. Die input select mask ist ein 8 Bit Hexadezimalwert: {| border=1 cellspacing=0 padding=4 class=wikitable ! bit7 !! bit6 !! bit5 !! bit4 !! bit3 !! bit2 !! bit1 !! bit0 |- | ignore || ignore || ignore || ignore || Kanal D || Kanal C || Kanal B || Kanal A |} Eine input select mask von 0x0f bedeutet also, dass für alle 4 Kanäle die analog-digital Umwandlung durchgeführt werden soll. Eine mask von 0x00 ist (offensichtlich) sinnlos. Eine ungültige input select mask (d.h. input select mask == 0x00 oder > 0x0f) wird erkannt und führt zu einer ECMD-Fehlermeldung. Die analog-digital Umwandlung erfolgt in der Reihenfolge von Kanal A zu Kanal D, wobei die nicht gewünschte Kanäle (sprich jene, wo das input select mask Bit auf 0 steht) übersprungen werden. Der DS2450 braucht für jedes Bit Auflösung ca. 60 bis 80µs. Außerdem braucht das Umwandlung-Kommando generell 160µs (offset) Dies bedeutet, dass eine Umwandlung aller 4 Kanäle bei maximaler 16 Bit Auflösung also nicht länger als 4*16*80+160µs = 5280µs = 5,28ms dauern wird. ===== read out control ===== Mit dem read out control kann angegeben werden, ob und wie das Register für die Ergebnisse der analog-digital Umwandlung vorbelegt werden soll. Das macht nur dann Sinn, wenn die Umwandlungsergebnisse schon gelesen werden sollen, während der DS2450 im Hintergrund noch die analog-digital Umwandlung durchführt (was möglich ist). Das read out control ist ein 8 Bit Hexadezimalwert: {| border=1 cellspacing=0 padding=4 class=wikitable ! bit7 !! bit6 !! bit5 !! bit4 !! bit3 !! bit2 !! bit1 !! bit0 |- | Set D || Clear D || Set C || Clear C || Set B || Clear B || Set A || Clear A |} Set bzw. Clear verhalten sich wie folgt: {| border=1 cellspacing=0 padding=4 class=wikitable ! Set !! Clear !! Ergebnis |- | 0 || 0 || keine Veränderung am Umwandlung-Register |- | 0 || 1 || alle Bits des Umwandlung-Register werden auf 0 gesetzt |- | 1 || 0 || alle Bits des Umwandlung-Register werden auf 1 gesetzt |- | 1 || 1 || invalid |} Ungültige Kombinationen im read out control (d.h. Set = 1 und Clear = 1) werden erkannt und führen zu einer ECMD-Fehlermeldung. Default-Werte: * input select mask: 0x04 * read out control: 0x00 Beispiel: 1w ds2450 convert (für alle Kanäle wird die analog-digital Umwandlung durchgeführt) ==== <code>1w ds2450 get</code> ==== Hierüber wird das Ergebnis der analog-digital Umwandlung ausgelesen (analog den 1-wire Temperatursensoren). Werden keine weiteren Argumente angegeben, so werden die Umwandlungsergebnisse für alle 4 Kanäle des DS2450 ausgegeben. Optional kann ein Kanal angegeben werden, dann wird nur das Umwandlungsergebniss dieses Kanals ausgegeben. Wurde seit dem letzten power-on reset cycle keine Umwandlung durchgeführt, stehen alle Bits der Register auf 0. Die Ausgabe erfolgt als raw (unsigned integer 16 Bit - <code>uint16_t</code>). Die eingelesene Spannung errechnet sich wie folgt (VAL ist die Ausgabe von <code>1w ds2450 get</code>): * für range = 0 (0..2,55V) VAL ------- * 2,55V 2**16-1 * für range = 1 (0..5,10V) VAL ------- * 5,10V 2**16-1 Default-Werte: - Beispiel: 1w ds2450 get (die Umwandlungsergebnisse für alle 4 Kanäle werden ausgegeben) === Beispielschaltung === Hier ein Beispielschaltung für den DS2450. Kanal A wird als Eingabe genutzt (range = 1). Kanal D wird als Ausgabe genutzt, über den Optokoppler kann die LED geschaltet werden. Der Widerstand R1 muss <b>unbedingt</b> entsprechend dem Optokoppler dimensioniert werden. Beim 4N35 sind 1k3 ausreichend, dann fließt ein Strom von ca. 2,8mA. [[File:DS2450 Beispiel 01.gif|600px|Beispielschaltung DS2450]] == Einbindung in Control6 (tcp_send) == https://github.com/ethersex/ethersex/blob/master/hardware/onewire/ds2450.h<br> http://www.tutorials.at/c/03-dateneingabe-ausgabe.html<br> <br> '''"ecmd?1w list"''' ergibt den rom code '''20686414000000b5''' für den ds2450<br> <br> <pre><nowiki> C6_HEADER(`/* This will be in control6.h */') #include "hardware/onewire/ds2450.h" uint16_t counter1 = 0; uint16_t var1 = 0; CONTROL_START CLOCK_USED() THREAD(start) var1 = 1; WAIT(5) var1 = 0; WAIT(5) THREAD_END(start) TCP_HANDLER_PERSIST(message_handler); if (var1 == 1){ ow_rom_code_t rom_code; uint16_t result; rom_code.bytewise[0] = 0x20; rom_code.bytewise[1] = 0x68; rom_code.bytewise[2] = 0x64; rom_code.bytewise[3] = 0x14; rom_code.bytewise[4] = 0x00; rom_code.bytewise[5] = 0x00; rom_code.bytewise[6] = 0x00; rom_code.bytewise[7] = 0xb5; ow_ds2450_convert(&rom_code, 0x0f, 0x00); ow_ds2450_get(&rom_code, 2, 2, &result); TCP_SEND("%u", result); WAIT(15) } TCP_HANDLER_END(); ON STARTUP DO THREAD_START(start) TCP_CONNECT(192.168.123.106, 4445, message_handler); END CONTROL_END </nowiki></pre> 85c07ed72fa1199ee4e117e4586ecf80d03a4970 836 832 2012-09-24T07:46:50Z Djmaster 255 /* Beispielschaltung */ wikitext text/x-wiki {{i18n|Onewire/DS2450}} {{Module |NAME=Onewire DS2450 |MENUCONFIG={{I/O}}->Onewire support |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} *Beitrag am 23.09.2012 erneuert. == Dallas 1-wire DS2450 4 Kanal ADC == Der DS2450 ist ein 4 Kanal ADC mit einer maximalen Auflösung von 16 Bit (vgl. [http://datasheets.maxim-ic.com/en/ds/DS2450.pdf Datenblatt]). Die analog-digital Umwandlung erfolgt durch einen internen four-to-one multiplexer. Kanäle, die nicht als Eingänge genutzt werden, können als Ausgänge (open drain) geschaltet werden (max. 4mA und 6V). === ECMD Interface === Über ECMD sind folgende Befehle für den DS2450 bekannt: *<code>1w ds2450 power</code> *<code>1w ds2450 res</code> *<code>1w ds2450 oc</code> *<code>1w ds2450 oe</code> *<code>1w ds2450 range</code> *<code>1w ds2450 por</code> *<code>1w ds2450 convert</code> *<code>1w ds2450 get</code> ==== Grundsätzliches ==== Grundsätzlich gilt für alle Befehle: * als erstes Argument kann optional die 64 Bit ROM Id des DS2450 angegeben werden, der angesprochen werden soll (match rom). Wird die ROM Id <b>nicht</b> angeben, so werden alle im Bus befindlichen 1-wire Devices (egal welchen Typs) angesprochen (skip rom). Dies macht <b>nur</b> Sinn, wenn sich <b>genau</b> ein Device im 1-wire Bus befindet (skip rom führt bei mehreren Devices unweigerlich dazu, dass mehrere Devices gleichzeitig antworten werden, was zu Bit-Salat beim bus master (d.h. Ethersex) führt, das Datenblatt spricht von "a wired-AND result"). * wird ein Kanal angeben, so ist dieser mit einem Buchstaben (entsprechend Datenblatt) zu bezeichnen (case-insensitiv). * wird mit einem Befehl ein Wert gesetzt, so kann mit dem gleichen Befehl der Wert gelesen werden, in dem man kein Werte-Argument angibt. ==== <code>1w ds2450 power</code> ==== Hierüber wird die Art der Spannungsversorgung des DS2450 gesetzt (global). Dieser Parameter wird durch den Anschluss an der 1-wire Bus bestimmt, vgl. die [[Dallas_1-wire_Bus#Anschluss_AVR-NET-IO | Erklärung der Anschlussmöglichkeiten]]. Wird der 1-wire Bus "normal" (drei-adrig) betrieben, so muss der Wert auf 1 gesetzt werden. Wird der Bus "parasitär" (zwei-adrig) betrieben, muss der Wert auf 0 gesetzt werden. Default-Wert: 0 Beispiel: 1w ds2450 power 1 (der DS250 wird auf "normale" Spannungsversorgung konfiguriert) ==== <code>1w ds2450 res</code> ==== Hierüber wird die Auflösung der analog-digital Umwandlung gesetzt (pro Kanal). Die Auflösung kann zw. 1 und 16 Bit eingestellt werden. Die Eingabe erfolgt als 8 Bit Hexadezimalwert, wobei eine Auflösung von 16 Bit durch den Wert 0x00 oder alternativ 0x10 erreicht wird. Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0x08 Beispiel: 1w ds2450 res c 08 (setzt die Auflösung für Kanal C auf 0x08, d.h. 8 Bit) ==== <code>1w ds2450 oc</code> ==== Hierüber kann der Ausgang ein- oder ausgeschaltet werden (pro Kanal). Voraussetzung ist, dass über [[DS2450#1w_ds2450_oe | 1w ds2450 oe]] der Kanal als Ausgang geschaltet wurde (ansonsten wird das OC-Bit ignoriert). Die Eingabe erfolgt als bool über 0 (Ausgangstransistor leitend) bzw. 1 (Ausgangstransistor nicht-leitend). Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0 Beispiel: 1w ds2450 oc a 1 (der Ausgangstransistor des Kanal A wird leitend) ==== <code>1w ds2450 oe</code> ==== Hierüber kann der Kanal als Ein- oder Ausgang gesetzt werden (pro Kanal). Eine analog-digital Umwandlung ist <b>nur</b> möglich, wenn das OE-Bit auf 0 gesetzt ist. In diesem Fall wird das OC-Bit ignoriert. Ist das OE-Bit auf 1 gesetzt, kann der Ausgang über 1w ds2450 oc ein- bzw. ausgeschaltet werden. Die Eingabe erfolgt als bool über 0 (Eingang für ADC) bzw. 1 (Ausgang open drain). Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0 Beispiel: 1w ds2450 oe d 1 (Kanal A wird als Ausgang gesetzt) ==== <code>1w ds2450 range</code> ==== Hierüber kann der Spannungs-Bereich angegeben werden, in dem die analog-digital Umwandlung stattfinden soll. Die Eingabe erfolgt als bool über 0 (Spannungsbereich 0 bis 2,55V) bzw. 1 (Spannungsbereich 0 bis 5,10V). Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0 Beispiel: 1w ds2450 range b 1 (für Kanal B wird bei der analog-digital Umwandlung der Spannungsbereich 0 bis 5,10V genutzt) ==== <code>1w ds2450 por</code> ==== Hierüber kann das power on reset Bit gelesen bzw. gesetzt werden. Nach einem power-on reset cycle setzt der DS2450 das Bit auf 1. Das Bit beeinflusst die conditional search, welche in Ethersex (noch) nicht implementiert ist. Setzt der bus master das Bit auf 0, so nimmt der DS2450 nicht mehr an der conditional search teil Die Eingabe erfolgt als bool über 0 bzw. 1. Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 1 (nach power-on reset cycle) Beispiel: 1w ds2450 por c 0 (für Kanal C wird das power on reset Bit auf 0 gesetzt) FixMe: Es sieht so aus, als kann das Bit nur global gesetzt werden, d.h. wird es für einen Kanal verändert, haben danach alle anderen Kanäle den gleich POR-Bit Wert. Außerdem kann man das Bit nicht mehr auf 1 setzen, wenn es vorher schon auf 0 gesetzt wurde (das widerspricht aber dem Datenblatt!). ==== <code>1w ds2450 convert</code> ==== Hierüber wird die analog-digital Umwandlung ausgelöst (analog den 1-wire Temperatursensoren). Werden keine weiteren Argumente angegeben, so wird die Umwandlung für alle 4 Kanäle des DS2450 durchgeführt (FixMe: vermutlich werden die Kanäle, bei denen das OE-Bit auf 1 steht ausgelassen, dass ist aber nicht durch Dallas dokumentiert). Optional können zwei Argumente angegeben werden (werden Argumente angegeben, <b>müssen beide</b> Argumente angegeben werden!): * input select mask * read-out control ===== input select mask ===== Mit der input select mask kann angegeben werden, für welche Kanäle die analog-digital Umwandlung durchgeführt werden soll. Die input select mask ist ein 8 Bit Hexadezimalwert: {| border=1 cellspacing=0 padding=4 class=wikitable ! bit7 !! bit6 !! bit5 !! bit4 !! bit3 !! bit2 !! bit1 !! bit0 |- | ignore || ignore || ignore || ignore || Kanal D || Kanal C || Kanal B || Kanal A |} Eine input select mask von 0x0f bedeutet also, dass für alle 4 Kanäle die analog-digital Umwandlung durchgeführt werden soll. Eine mask von 0x00 ist (offensichtlich) sinnlos. Eine ungültige input select mask (d.h. input select mask == 0x00 oder > 0x0f) wird erkannt und führt zu einer ECMD-Fehlermeldung. Die analog-digital Umwandlung erfolgt in der Reihenfolge von Kanal A zu Kanal D, wobei die nicht gewünschte Kanäle (sprich jene, wo das input select mask Bit auf 0 steht) übersprungen werden. Der DS2450 braucht für jedes Bit Auflösung ca. 60 bis 80µs. Außerdem braucht das Umwandlung-Kommando generell 160µs (offset) Dies bedeutet, dass eine Umwandlung aller 4 Kanäle bei maximaler 16 Bit Auflösung also nicht länger als 4*16*80+160µs = 5280µs = 5,28ms dauern wird. ===== read out control ===== Mit dem read out control kann angegeben werden, ob und wie das Register für die Ergebnisse der analog-digital Umwandlung vorbelegt werden soll. Das macht nur dann Sinn, wenn die Umwandlungsergebnisse schon gelesen werden sollen, während der DS2450 im Hintergrund noch die analog-digital Umwandlung durchführt (was möglich ist). Das read out control ist ein 8 Bit Hexadezimalwert: {| border=1 cellspacing=0 padding=4 class=wikitable ! bit7 !! bit6 !! bit5 !! bit4 !! bit3 !! bit2 !! bit1 !! bit0 |- | Set D || Clear D || Set C || Clear C || Set B || Clear B || Set A || Clear A |} Set bzw. Clear verhalten sich wie folgt: {| border=1 cellspacing=0 padding=4 class=wikitable ! Set !! Clear !! Ergebnis |- | 0 || 0 || keine Veränderung am Umwandlung-Register |- | 0 || 1 || alle Bits des Umwandlung-Register werden auf 0 gesetzt |- | 1 || 0 || alle Bits des Umwandlung-Register werden auf 1 gesetzt |- | 1 || 1 || invalid |} Ungültige Kombinationen im read out control (d.h. Set = 1 und Clear = 1) werden erkannt und führen zu einer ECMD-Fehlermeldung. Default-Werte: * input select mask: 0x04 * read out control: 0x00 Beispiel: 1w ds2450 convert (für alle Kanäle wird die analog-digital Umwandlung durchgeführt) ==== <code>1w ds2450 get</code> ==== Hierüber wird das Ergebnis der analog-digital Umwandlung ausgelesen (analog den 1-wire Temperatursensoren). Werden keine weiteren Argumente angegeben, so werden die Umwandlungsergebnisse für alle 4 Kanäle des DS2450 ausgegeben. Optional kann ein Kanal angegeben werden, dann wird nur das Umwandlungsergebniss dieses Kanals ausgegeben. Wurde seit dem letzten power-on reset cycle keine Umwandlung durchgeführt, stehen alle Bits der Register auf 0. Die Ausgabe erfolgt als raw (unsigned integer 16 Bit - <code>uint16_t</code>). Die eingelesene Spannung errechnet sich wie folgt (VAL ist die Ausgabe von <code>1w ds2450 get</code>): * für range = 0 (0..2,55V) VAL ------- * 2,55V 2**16-1 * für range = 1 (0..5,10V) VAL ------- * 5,10V 2**16-1 Default-Werte: - Beispiel: 1w ds2450 get (die Umwandlungsergebnisse für alle 4 Kanäle werden ausgegeben) === Beispielschaltung 1=== Hier ein Beispielschaltung für den DS2450. Kanal A wird als Eingabe genutzt (range = 1). Kanal D wird als Ausgabe genutzt, über den Optokoppler kann die LED geschaltet werden. Der Widerstand R1 muss <b>unbedingt</b> entsprechend dem Optokoppler dimensioniert werden. Beim 4N35 sind 1k3 ausreichend, dann fließt ein Strom von ca. 2,8mA. [[File:DS2450 Beispiel 01.gif|600px|Beispielschaltung DS2450]] === Beispielschaltung 2=== Hier die Beispielschaltung 2 für den DS2450. Kanal A/B/C/D wird als Eingang genutzt (Range = 1). * I/O-A wird zb. als Tür oder Fenster Detektor genutzt. * I/O-B wird als Eingang für den Luftfeuchtesensor genutzt. * I/O-C wird als Eingang für den Luftdrucksensor genutzt. * I/O-D wird genutzt um die Versorgungsspannung zu messen welche bei der Berechnung des Luftdrucksensor benötigt wird. <br> Weiters hängt ein DS2450 und ein DS1820 parallel am Bus um noch eine Temperatur über den Bus zu bekommen. * [http://www.ethersex.de/images/5/5c/1W_MPX6115_HIH4000.pdf Schaltung als PDF downloaden] [[File:1W MPX6115 HIH4000.png|600px|Beispielschaltung DS2450]] * Zum Initialisieren verwende ich folgende Kommandos via ecmd zb.: <pre><nowiki> 1w ds2450 power 1 (drei adrig) 1w ds2450 res c 08 (00 / 10 = 16bit, 08 8bit) 1w ds2450 oe c 0 (als eingang stetzen) 1w ds2450 range c 1 (Range 0-5,10V) 1w ds2450 convert 1w ds2450 get </nowiki></pre> == Probleme == === Berechnung des Luftdrucksensor === // lt. Datenblatt: // OFFSET 0.958062V bei 0%RH // SLOPE: 30.680 mV/%RH $Srh = ($Vad - 0.958062) * 30.680; hmm oder $Srh = ($Vad - 0.958062) * 34.558; //Werte nach Kalibrierung (Ist bei mir genauer als 30.680) === Werte des ADC schwanken beim auslesen === Lege doch mal die Versorgungsspannung direkt auf einen Eingang und schaue mal ob der Wert immer noch schwankt. === Nach einer Stunde funktioniert die GET ausgabe nicht === Vielleicht ist das nur bei mir so aber nach einem wdreset funktioniert es wieder. (Der ds2450 wird alle 30 sekunden abgefragt) == Einbindung in Control6 (tcp_send) == https://github.com/ethersex/ethersex/blob/master/hardware/onewire/ds2450.h<br> http://www.tutorials.at/c/03-dateneingabe-ausgabe.html<br> <br> '''"ecmd?1w list"''' ergibt den rom code '''20686414000000b5''' für den ds2450<br> <br> <pre><nowiki> C6_HEADER(`/* This will be in control6.h */') #include "hardware/onewire/ds2450.h" uint16_t counter1 = 0; uint16_t var1 = 0; CONTROL_START CLOCK_USED() THREAD(start) var1 = 1; WAIT(5) var1 = 0; WAIT(5) THREAD_END(start) TCP_HANDLER_PERSIST(message_handler); if (var1 == 1){ ow_rom_code_t rom_code; uint16_t result; rom_code.bytewise[0] = 0x20; rom_code.bytewise[1] = 0x68; rom_code.bytewise[2] = 0x64; rom_code.bytewise[3] = 0x14; rom_code.bytewise[4] = 0x00; rom_code.bytewise[5] = 0x00; rom_code.bytewise[6] = 0x00; rom_code.bytewise[7] = 0xb5; ow_ds2450_convert(&rom_code, 0x0f, 0x00); ow_ds2450_get(&rom_code, 2, 2, &result); TCP_SEND("%u", result); WAIT(15) } TCP_HANDLER_END(); ON STARTUP DO THREAD_START(start) TCP_CONNECT(192.168.123.106, 4445, message_handler); END CONTROL_END </nowiki></pre> 5fa0523c99fc8210e7f466d17b761876ae8d65d7 837 836 2012-09-24T07:50:19Z Djmaster 255 /* Beispielschaltung 2 */ wikitext text/x-wiki {{i18n|Onewire/DS2450}} {{Module |NAME=Onewire DS2450 |MENUCONFIG={{I/O}}->Onewire support |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} *Beitrag am 23.09.2012 erneuert. == Dallas 1-wire DS2450 4 Kanal ADC == Der DS2450 ist ein 4 Kanal ADC mit einer maximalen Auflösung von 16 Bit (vgl. [http://datasheets.maxim-ic.com/en/ds/DS2450.pdf Datenblatt]). Die analog-digital Umwandlung erfolgt durch einen internen four-to-one multiplexer. Kanäle, die nicht als Eingänge genutzt werden, können als Ausgänge (open drain) geschaltet werden (max. 4mA und 6V). === ECMD Interface === Über ECMD sind folgende Befehle für den DS2450 bekannt: *<code>1w ds2450 power</code> *<code>1w ds2450 res</code> *<code>1w ds2450 oc</code> *<code>1w ds2450 oe</code> *<code>1w ds2450 range</code> *<code>1w ds2450 por</code> *<code>1w ds2450 convert</code> *<code>1w ds2450 get</code> ==== Grundsätzliches ==== Grundsätzlich gilt für alle Befehle: * als erstes Argument kann optional die 64 Bit ROM Id des DS2450 angegeben werden, der angesprochen werden soll (match rom). Wird die ROM Id <b>nicht</b> angeben, so werden alle im Bus befindlichen 1-wire Devices (egal welchen Typs) angesprochen (skip rom). Dies macht <b>nur</b> Sinn, wenn sich <b>genau</b> ein Device im 1-wire Bus befindet (skip rom führt bei mehreren Devices unweigerlich dazu, dass mehrere Devices gleichzeitig antworten werden, was zu Bit-Salat beim bus master (d.h. Ethersex) führt, das Datenblatt spricht von "a wired-AND result"). * wird ein Kanal angeben, so ist dieser mit einem Buchstaben (entsprechend Datenblatt) zu bezeichnen (case-insensitiv). * wird mit einem Befehl ein Wert gesetzt, so kann mit dem gleichen Befehl der Wert gelesen werden, in dem man kein Werte-Argument angibt. ==== <code>1w ds2450 power</code> ==== Hierüber wird die Art der Spannungsversorgung des DS2450 gesetzt (global). Dieser Parameter wird durch den Anschluss an der 1-wire Bus bestimmt, vgl. die [[Dallas_1-wire_Bus#Anschluss_AVR-NET-IO | Erklärung der Anschlussmöglichkeiten]]. Wird der 1-wire Bus "normal" (drei-adrig) betrieben, so muss der Wert auf 1 gesetzt werden. Wird der Bus "parasitär" (zwei-adrig) betrieben, muss der Wert auf 0 gesetzt werden. Default-Wert: 0 Beispiel: 1w ds2450 power 1 (der DS250 wird auf "normale" Spannungsversorgung konfiguriert) ==== <code>1w ds2450 res</code> ==== Hierüber wird die Auflösung der analog-digital Umwandlung gesetzt (pro Kanal). Die Auflösung kann zw. 1 und 16 Bit eingestellt werden. Die Eingabe erfolgt als 8 Bit Hexadezimalwert, wobei eine Auflösung von 16 Bit durch den Wert 0x00 oder alternativ 0x10 erreicht wird. Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0x08 Beispiel: 1w ds2450 res c 08 (setzt die Auflösung für Kanal C auf 0x08, d.h. 8 Bit) ==== <code>1w ds2450 oc</code> ==== Hierüber kann der Ausgang ein- oder ausgeschaltet werden (pro Kanal). Voraussetzung ist, dass über [[DS2450#1w_ds2450_oe | 1w ds2450 oe]] der Kanal als Ausgang geschaltet wurde (ansonsten wird das OC-Bit ignoriert). Die Eingabe erfolgt als bool über 0 (Ausgangstransistor leitend) bzw. 1 (Ausgangstransistor nicht-leitend). Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0 Beispiel: 1w ds2450 oc a 1 (der Ausgangstransistor des Kanal A wird leitend) ==== <code>1w ds2450 oe</code> ==== Hierüber kann der Kanal als Ein- oder Ausgang gesetzt werden (pro Kanal). Eine analog-digital Umwandlung ist <b>nur</b> möglich, wenn das OE-Bit auf 0 gesetzt ist. In diesem Fall wird das OC-Bit ignoriert. Ist das OE-Bit auf 1 gesetzt, kann der Ausgang über 1w ds2450 oc ein- bzw. ausgeschaltet werden. Die Eingabe erfolgt als bool über 0 (Eingang für ADC) bzw. 1 (Ausgang open drain). Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0 Beispiel: 1w ds2450 oe d 1 (Kanal A wird als Ausgang gesetzt) ==== <code>1w ds2450 range</code> ==== Hierüber kann der Spannungs-Bereich angegeben werden, in dem die analog-digital Umwandlung stattfinden soll. Die Eingabe erfolgt als bool über 0 (Spannungsbereich 0 bis 2,55V) bzw. 1 (Spannungsbereich 0 bis 5,10V). Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0 Beispiel: 1w ds2450 range b 1 (für Kanal B wird bei der analog-digital Umwandlung der Spannungsbereich 0 bis 5,10V genutzt) ==== <code>1w ds2450 por</code> ==== Hierüber kann das power on reset Bit gelesen bzw. gesetzt werden. Nach einem power-on reset cycle setzt der DS2450 das Bit auf 1. Das Bit beeinflusst die conditional search, welche in Ethersex (noch) nicht implementiert ist. Setzt der bus master das Bit auf 0, so nimmt der DS2450 nicht mehr an der conditional search teil Die Eingabe erfolgt als bool über 0 bzw. 1. Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 1 (nach power-on reset cycle) Beispiel: 1w ds2450 por c 0 (für Kanal C wird das power on reset Bit auf 0 gesetzt) FixMe: Es sieht so aus, als kann das Bit nur global gesetzt werden, d.h. wird es für einen Kanal verändert, haben danach alle anderen Kanäle den gleich POR-Bit Wert. Außerdem kann man das Bit nicht mehr auf 1 setzen, wenn es vorher schon auf 0 gesetzt wurde (das widerspricht aber dem Datenblatt!). ==== <code>1w ds2450 convert</code> ==== Hierüber wird die analog-digital Umwandlung ausgelöst (analog den 1-wire Temperatursensoren). Werden keine weiteren Argumente angegeben, so wird die Umwandlung für alle 4 Kanäle des DS2450 durchgeführt (FixMe: vermutlich werden die Kanäle, bei denen das OE-Bit auf 1 steht ausgelassen, dass ist aber nicht durch Dallas dokumentiert). Optional können zwei Argumente angegeben werden (werden Argumente angegeben, <b>müssen beide</b> Argumente angegeben werden!): * input select mask * read-out control ===== input select mask ===== Mit der input select mask kann angegeben werden, für welche Kanäle die analog-digital Umwandlung durchgeführt werden soll. Die input select mask ist ein 8 Bit Hexadezimalwert: {| border=1 cellspacing=0 padding=4 class=wikitable ! bit7 !! bit6 !! bit5 !! bit4 !! bit3 !! bit2 !! bit1 !! bit0 |- | ignore || ignore || ignore || ignore || Kanal D || Kanal C || Kanal B || Kanal A |} Eine input select mask von 0x0f bedeutet also, dass für alle 4 Kanäle die analog-digital Umwandlung durchgeführt werden soll. Eine mask von 0x00 ist (offensichtlich) sinnlos. Eine ungültige input select mask (d.h. input select mask == 0x00 oder > 0x0f) wird erkannt und führt zu einer ECMD-Fehlermeldung. Die analog-digital Umwandlung erfolgt in der Reihenfolge von Kanal A zu Kanal D, wobei die nicht gewünschte Kanäle (sprich jene, wo das input select mask Bit auf 0 steht) übersprungen werden. Der DS2450 braucht für jedes Bit Auflösung ca. 60 bis 80µs. Außerdem braucht das Umwandlung-Kommando generell 160µs (offset) Dies bedeutet, dass eine Umwandlung aller 4 Kanäle bei maximaler 16 Bit Auflösung also nicht länger als 4*16*80+160µs = 5280µs = 5,28ms dauern wird. ===== read out control ===== Mit dem read out control kann angegeben werden, ob und wie das Register für die Ergebnisse der analog-digital Umwandlung vorbelegt werden soll. Das macht nur dann Sinn, wenn die Umwandlungsergebnisse schon gelesen werden sollen, während der DS2450 im Hintergrund noch die analog-digital Umwandlung durchführt (was möglich ist). Das read out control ist ein 8 Bit Hexadezimalwert: {| border=1 cellspacing=0 padding=4 class=wikitable ! bit7 !! bit6 !! bit5 !! bit4 !! bit3 !! bit2 !! bit1 !! bit0 |- | Set D || Clear D || Set C || Clear C || Set B || Clear B || Set A || Clear A |} Set bzw. Clear verhalten sich wie folgt: {| border=1 cellspacing=0 padding=4 class=wikitable ! Set !! Clear !! Ergebnis |- | 0 || 0 || keine Veränderung am Umwandlung-Register |- | 0 || 1 || alle Bits des Umwandlung-Register werden auf 0 gesetzt |- | 1 || 0 || alle Bits des Umwandlung-Register werden auf 1 gesetzt |- | 1 || 1 || invalid |} Ungültige Kombinationen im read out control (d.h. Set = 1 und Clear = 1) werden erkannt und führen zu einer ECMD-Fehlermeldung. Default-Werte: * input select mask: 0x04 * read out control: 0x00 Beispiel: 1w ds2450 convert (für alle Kanäle wird die analog-digital Umwandlung durchgeführt) ==== <code>1w ds2450 get</code> ==== Hierüber wird das Ergebnis der analog-digital Umwandlung ausgelesen (analog den 1-wire Temperatursensoren). Werden keine weiteren Argumente angegeben, so werden die Umwandlungsergebnisse für alle 4 Kanäle des DS2450 ausgegeben. Optional kann ein Kanal angegeben werden, dann wird nur das Umwandlungsergebniss dieses Kanals ausgegeben. Wurde seit dem letzten power-on reset cycle keine Umwandlung durchgeführt, stehen alle Bits der Register auf 0. Die Ausgabe erfolgt als raw (unsigned integer 16 Bit - <code>uint16_t</code>). Die eingelesene Spannung errechnet sich wie folgt (VAL ist die Ausgabe von <code>1w ds2450 get</code>): * für range = 0 (0..2,55V) VAL ------- * 2,55V 2**16-1 * für range = 1 (0..5,10V) VAL ------- * 5,10V 2**16-1 Default-Werte: - Beispiel: 1w ds2450 get (die Umwandlungsergebnisse für alle 4 Kanäle werden ausgegeben) === Beispielschaltung 1=== Hier ein Beispielschaltung für den DS2450. Kanal A wird als Eingabe genutzt (range = 1). Kanal D wird als Ausgabe genutzt, über den Optokoppler kann die LED geschaltet werden. Der Widerstand R1 muss <b>unbedingt</b> entsprechend dem Optokoppler dimensioniert werden. Beim 4N35 sind 1k3 ausreichend, dann fließt ein Strom von ca. 2,8mA. [[File:DS2450 Beispiel 01.gif|600px|Beispielschaltung DS2450]] === Beispielschaltung 2=== Hier die Beispielschaltung 2 für den DS2450. Kanal A/B/C/D wird als Eingang genutzt (Range = 1). * I/O-A wird zb. als Tür oder Fenster Detektor genutzt. * I/O-B wird als Eingang für den Luftfeuchtesensor genutzt. * I/O-C wird als Eingang für den Luftdrucksensor genutzt. * I/O-D wird genutzt um die Versorgungsspannung zu messen welche bei der Berechnung des Luftdrucksensor benötigt wird. <br> Weiters hängt ein DS2450 und ein DS1820 parallel am Bus um noch eine Temperatur über den Bus zu bekommen. * [http://www.ethersex.de/images/5/5c/1W_MPX6115_HIH4000.pdf Schaltung als PDF downloaden] [[File:1W MPX6115 HIH4000.png|600px|Beispielschaltung DS2450]] * Zum Initialisieren verwende ich folgende Kommandos via ecmd zb.: <pre><nowiki> 1w ds2450 power 1 //(drei adrig) 1w ds2450 res c 08 //(00 / 10 = 16bit, 08 8bit) 1w ds2450 oe c 0 //(als eingang stetzen) 1w ds2450 range c 1 //(Range 0-5,10V) 1w ds2450 convert 1w ds2450 get </nowiki></pre> == Probleme == === Berechnung des Luftdrucksensor === // lt. Datenblatt: // OFFSET 0.958062V bei 0%RH // SLOPE: 30.680 mV/%RH $Srh = ($Vad - 0.958062) * 30.680; hmm oder $Srh = ($Vad - 0.958062) * 34.558; //Werte nach Kalibrierung (Ist bei mir genauer als 30.680) === Werte des ADC schwanken beim auslesen === Lege doch mal die Versorgungsspannung direkt auf einen Eingang und schaue mal ob der Wert immer noch schwankt. === Nach einer Stunde funktioniert die GET ausgabe nicht === Vielleicht ist das nur bei mir so aber nach einem wdreset funktioniert es wieder. (Der ds2450 wird alle 30 sekunden abgefragt) == Einbindung in Control6 (tcp_send) == https://github.com/ethersex/ethersex/blob/master/hardware/onewire/ds2450.h<br> http://www.tutorials.at/c/03-dateneingabe-ausgabe.html<br> <br> '''"ecmd?1w list"''' ergibt den rom code '''20686414000000b5''' für den ds2450<br> <br> <pre><nowiki> C6_HEADER(`/* This will be in control6.h */') #include "hardware/onewire/ds2450.h" uint16_t counter1 = 0; uint16_t var1 = 0; CONTROL_START CLOCK_USED() THREAD(start) var1 = 1; WAIT(5) var1 = 0; WAIT(5) THREAD_END(start) TCP_HANDLER_PERSIST(message_handler); if (var1 == 1){ ow_rom_code_t rom_code; uint16_t result; rom_code.bytewise[0] = 0x20; rom_code.bytewise[1] = 0x68; rom_code.bytewise[2] = 0x64; rom_code.bytewise[3] = 0x14; rom_code.bytewise[4] = 0x00; rom_code.bytewise[5] = 0x00; rom_code.bytewise[6] = 0x00; rom_code.bytewise[7] = 0xb5; ow_ds2450_convert(&rom_code, 0x0f, 0x00); ow_ds2450_get(&rom_code, 2, 2, &result); TCP_SEND("%u", result); WAIT(15) } TCP_HANDLER_END(); ON STARTUP DO THREAD_START(start) TCP_CONNECT(192.168.123.106, 4445, message_handler); END CONTROL_END </nowiki></pre> 12b6fbc8e10e8081d4ed1e8bf9a5f368639d6ba0 838 837 2012-09-24T07:57:03Z Djmaster 255 /* Berechnung des Luftdrucksensor */ wikitext text/x-wiki {{i18n|Onewire/DS2450}} {{Module |NAME=Onewire DS2450 |MENUCONFIG={{I/O}}->Onewire support |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} *Beitrag am 23.09.2012 erneuert. == Dallas 1-wire DS2450 4 Kanal ADC == Der DS2450 ist ein 4 Kanal ADC mit einer maximalen Auflösung von 16 Bit (vgl. [http://datasheets.maxim-ic.com/en/ds/DS2450.pdf Datenblatt]). Die analog-digital Umwandlung erfolgt durch einen internen four-to-one multiplexer. Kanäle, die nicht als Eingänge genutzt werden, können als Ausgänge (open drain) geschaltet werden (max. 4mA und 6V). === ECMD Interface === Über ECMD sind folgende Befehle für den DS2450 bekannt: *<code>1w ds2450 power</code> *<code>1w ds2450 res</code> *<code>1w ds2450 oc</code> *<code>1w ds2450 oe</code> *<code>1w ds2450 range</code> *<code>1w ds2450 por</code> *<code>1w ds2450 convert</code> *<code>1w ds2450 get</code> ==== Grundsätzliches ==== Grundsätzlich gilt für alle Befehle: * als erstes Argument kann optional die 64 Bit ROM Id des DS2450 angegeben werden, der angesprochen werden soll (match rom). Wird die ROM Id <b>nicht</b> angeben, so werden alle im Bus befindlichen 1-wire Devices (egal welchen Typs) angesprochen (skip rom). Dies macht <b>nur</b> Sinn, wenn sich <b>genau</b> ein Device im 1-wire Bus befindet (skip rom führt bei mehreren Devices unweigerlich dazu, dass mehrere Devices gleichzeitig antworten werden, was zu Bit-Salat beim bus master (d.h. Ethersex) führt, das Datenblatt spricht von "a wired-AND result"). * wird ein Kanal angeben, so ist dieser mit einem Buchstaben (entsprechend Datenblatt) zu bezeichnen (case-insensitiv). * wird mit einem Befehl ein Wert gesetzt, so kann mit dem gleichen Befehl der Wert gelesen werden, in dem man kein Werte-Argument angibt. ==== <code>1w ds2450 power</code> ==== Hierüber wird die Art der Spannungsversorgung des DS2450 gesetzt (global). Dieser Parameter wird durch den Anschluss an der 1-wire Bus bestimmt, vgl. die [[Dallas_1-wire_Bus#Anschluss_AVR-NET-IO | Erklärung der Anschlussmöglichkeiten]]. Wird der 1-wire Bus "normal" (drei-adrig) betrieben, so muss der Wert auf 1 gesetzt werden. Wird der Bus "parasitär" (zwei-adrig) betrieben, muss der Wert auf 0 gesetzt werden. Default-Wert: 0 Beispiel: 1w ds2450 power 1 (der DS250 wird auf "normale" Spannungsversorgung konfiguriert) ==== <code>1w ds2450 res</code> ==== Hierüber wird die Auflösung der analog-digital Umwandlung gesetzt (pro Kanal). Die Auflösung kann zw. 1 und 16 Bit eingestellt werden. Die Eingabe erfolgt als 8 Bit Hexadezimalwert, wobei eine Auflösung von 16 Bit durch den Wert 0x00 oder alternativ 0x10 erreicht wird. Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0x08 Beispiel: 1w ds2450 res c 08 (setzt die Auflösung für Kanal C auf 0x08, d.h. 8 Bit) ==== <code>1w ds2450 oc</code> ==== Hierüber kann der Ausgang ein- oder ausgeschaltet werden (pro Kanal). Voraussetzung ist, dass über [[DS2450#1w_ds2450_oe | 1w ds2450 oe]] der Kanal als Ausgang geschaltet wurde (ansonsten wird das OC-Bit ignoriert). Die Eingabe erfolgt als bool über 0 (Ausgangstransistor leitend) bzw. 1 (Ausgangstransistor nicht-leitend). Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0 Beispiel: 1w ds2450 oc a 1 (der Ausgangstransistor des Kanal A wird leitend) ==== <code>1w ds2450 oe</code> ==== Hierüber kann der Kanal als Ein- oder Ausgang gesetzt werden (pro Kanal). Eine analog-digital Umwandlung ist <b>nur</b> möglich, wenn das OE-Bit auf 0 gesetzt ist. In diesem Fall wird das OC-Bit ignoriert. Ist das OE-Bit auf 1 gesetzt, kann der Ausgang über 1w ds2450 oc ein- bzw. ausgeschaltet werden. Die Eingabe erfolgt als bool über 0 (Eingang für ADC) bzw. 1 (Ausgang open drain). Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0 Beispiel: 1w ds2450 oe d 1 (Kanal A wird als Ausgang gesetzt) ==== <code>1w ds2450 range</code> ==== Hierüber kann der Spannungs-Bereich angegeben werden, in dem die analog-digital Umwandlung stattfinden soll. Die Eingabe erfolgt als bool über 0 (Spannungsbereich 0 bis 2,55V) bzw. 1 (Spannungsbereich 0 bis 5,10V). Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0 Beispiel: 1w ds2450 range b 1 (für Kanal B wird bei der analog-digital Umwandlung der Spannungsbereich 0 bis 5,10V genutzt) ==== <code>1w ds2450 por</code> ==== Hierüber kann das power on reset Bit gelesen bzw. gesetzt werden. Nach einem power-on reset cycle setzt der DS2450 das Bit auf 1. Das Bit beeinflusst die conditional search, welche in Ethersex (noch) nicht implementiert ist. Setzt der bus master das Bit auf 0, so nimmt der DS2450 nicht mehr an der conditional search teil Die Eingabe erfolgt als bool über 0 bzw. 1. Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 1 (nach power-on reset cycle) Beispiel: 1w ds2450 por c 0 (für Kanal C wird das power on reset Bit auf 0 gesetzt) FixMe: Es sieht so aus, als kann das Bit nur global gesetzt werden, d.h. wird es für einen Kanal verändert, haben danach alle anderen Kanäle den gleich POR-Bit Wert. Außerdem kann man das Bit nicht mehr auf 1 setzen, wenn es vorher schon auf 0 gesetzt wurde (das widerspricht aber dem Datenblatt!). ==== <code>1w ds2450 convert</code> ==== Hierüber wird die analog-digital Umwandlung ausgelöst (analog den 1-wire Temperatursensoren). Werden keine weiteren Argumente angegeben, so wird die Umwandlung für alle 4 Kanäle des DS2450 durchgeführt (FixMe: vermutlich werden die Kanäle, bei denen das OE-Bit auf 1 steht ausgelassen, dass ist aber nicht durch Dallas dokumentiert). Optional können zwei Argumente angegeben werden (werden Argumente angegeben, <b>müssen beide</b> Argumente angegeben werden!): * input select mask * read-out control ===== input select mask ===== Mit der input select mask kann angegeben werden, für welche Kanäle die analog-digital Umwandlung durchgeführt werden soll. Die input select mask ist ein 8 Bit Hexadezimalwert: {| border=1 cellspacing=0 padding=4 class=wikitable ! bit7 !! bit6 !! bit5 !! bit4 !! bit3 !! bit2 !! bit1 !! bit0 |- | ignore || ignore || ignore || ignore || Kanal D || Kanal C || Kanal B || Kanal A |} Eine input select mask von 0x0f bedeutet also, dass für alle 4 Kanäle die analog-digital Umwandlung durchgeführt werden soll. Eine mask von 0x00 ist (offensichtlich) sinnlos. Eine ungültige input select mask (d.h. input select mask == 0x00 oder > 0x0f) wird erkannt und führt zu einer ECMD-Fehlermeldung. Die analog-digital Umwandlung erfolgt in der Reihenfolge von Kanal A zu Kanal D, wobei die nicht gewünschte Kanäle (sprich jene, wo das input select mask Bit auf 0 steht) übersprungen werden. Der DS2450 braucht für jedes Bit Auflösung ca. 60 bis 80µs. Außerdem braucht das Umwandlung-Kommando generell 160µs (offset) Dies bedeutet, dass eine Umwandlung aller 4 Kanäle bei maximaler 16 Bit Auflösung also nicht länger als 4*16*80+160µs = 5280µs = 5,28ms dauern wird. ===== read out control ===== Mit dem read out control kann angegeben werden, ob und wie das Register für die Ergebnisse der analog-digital Umwandlung vorbelegt werden soll. Das macht nur dann Sinn, wenn die Umwandlungsergebnisse schon gelesen werden sollen, während der DS2450 im Hintergrund noch die analog-digital Umwandlung durchführt (was möglich ist). Das read out control ist ein 8 Bit Hexadezimalwert: {| border=1 cellspacing=0 padding=4 class=wikitable ! bit7 !! bit6 !! bit5 !! bit4 !! bit3 !! bit2 !! bit1 !! bit0 |- | Set D || Clear D || Set C || Clear C || Set B || Clear B || Set A || Clear A |} Set bzw. Clear verhalten sich wie folgt: {| border=1 cellspacing=0 padding=4 class=wikitable ! Set !! Clear !! Ergebnis |- | 0 || 0 || keine Veränderung am Umwandlung-Register |- | 0 || 1 || alle Bits des Umwandlung-Register werden auf 0 gesetzt |- | 1 || 0 || alle Bits des Umwandlung-Register werden auf 1 gesetzt |- | 1 || 1 || invalid |} Ungültige Kombinationen im read out control (d.h. Set = 1 und Clear = 1) werden erkannt und führen zu einer ECMD-Fehlermeldung. Default-Werte: * input select mask: 0x04 * read out control: 0x00 Beispiel: 1w ds2450 convert (für alle Kanäle wird die analog-digital Umwandlung durchgeführt) ==== <code>1w ds2450 get</code> ==== Hierüber wird das Ergebnis der analog-digital Umwandlung ausgelesen (analog den 1-wire Temperatursensoren). Werden keine weiteren Argumente angegeben, so werden die Umwandlungsergebnisse für alle 4 Kanäle des DS2450 ausgegeben. Optional kann ein Kanal angegeben werden, dann wird nur das Umwandlungsergebniss dieses Kanals ausgegeben. Wurde seit dem letzten power-on reset cycle keine Umwandlung durchgeführt, stehen alle Bits der Register auf 0. Die Ausgabe erfolgt als raw (unsigned integer 16 Bit - <code>uint16_t</code>). Die eingelesene Spannung errechnet sich wie folgt (VAL ist die Ausgabe von <code>1w ds2450 get</code>): * für range = 0 (0..2,55V) VAL ------- * 2,55V 2**16-1 * für range = 1 (0..5,10V) VAL ------- * 5,10V 2**16-1 Default-Werte: - Beispiel: 1w ds2450 get (die Umwandlungsergebnisse für alle 4 Kanäle werden ausgegeben) === Beispielschaltung 1=== Hier ein Beispielschaltung für den DS2450. Kanal A wird als Eingabe genutzt (range = 1). Kanal D wird als Ausgabe genutzt, über den Optokoppler kann die LED geschaltet werden. Der Widerstand R1 muss <b>unbedingt</b> entsprechend dem Optokoppler dimensioniert werden. Beim 4N35 sind 1k3 ausreichend, dann fließt ein Strom von ca. 2,8mA. [[File:DS2450 Beispiel 01.gif|600px|Beispielschaltung DS2450]] === Beispielschaltung 2=== Hier die Beispielschaltung 2 für den DS2450. Kanal A/B/C/D wird als Eingang genutzt (Range = 1). * I/O-A wird zb. als Tür oder Fenster Detektor genutzt. * I/O-B wird als Eingang für den Luftfeuchtesensor genutzt. * I/O-C wird als Eingang für den Luftdrucksensor genutzt. * I/O-D wird genutzt um die Versorgungsspannung zu messen welche bei der Berechnung des Luftdrucksensor benötigt wird. <br> Weiters hängt ein DS2450 und ein DS1820 parallel am Bus um noch eine Temperatur über den Bus zu bekommen. * [http://www.ethersex.de/images/5/5c/1W_MPX6115_HIH4000.pdf Schaltung als PDF downloaden] [[File:1W MPX6115 HIH4000.png|600px|Beispielschaltung DS2450]] * Zum Initialisieren verwende ich folgende Kommandos via ecmd zb.: <pre><nowiki> 1w ds2450 power 1 //(drei adrig) 1w ds2450 res c 08 //(00 / 10 = 16bit, 08 8bit) 1w ds2450 oe c 0 //(als eingang stetzen) 1w ds2450 range c 1 //(Range 0-5,10V) 1w ds2450 convert 1w ds2450 get </nowiki></pre> == Probleme == === Berechnungen des Feuchtesensor === // lt. Datenblatt: // OFFSET 0.958062V bei 0%RH // SLOPE: 30.680 mV/%RH $V_Feuchte = ($Humid/65535)*5.17; $RH_Feuchte = ($V_Feuchte - 0.958062) * 34.558; //Werte nach Kalibrierung ( 34.558 Ist bei mir genauer als 30.680) $RHR = $RH_Feuchte / ((1.0305 + (0.000044 * 25) - (0.0000011 * pow(22.6,2)))); echo $RHR; === Berechnungen des Drucksensor === $ADCwert = ($Druck/65535)*5.10; $ADCVBuswert= ($Vdd/65535)*5.10; $kpawert = $ADCwert/($ADCVBuswert*0.009)+10.55; echo $kpawert*10; === Werte des ADC schwanken beim auslesen === Lege doch mal die Versorgungsspannung direkt auf einen Eingang und schaue mal ob der Wert immer noch schwankt. === Nach einer Stunde funktioniert die GET ausgabe nicht === Vielleicht ist das nur bei mir so aber nach einem wdreset funktioniert es wieder. (Der ds2450 wird alle 30 sekunden abgefragt) == Einbindung in Control6 (tcp_send) == https://github.com/ethersex/ethersex/blob/master/hardware/onewire/ds2450.h<br> http://www.tutorials.at/c/03-dateneingabe-ausgabe.html<br> <br> '''"ecmd?1w list"''' ergibt den rom code '''20686414000000b5''' für den ds2450<br> <br> <pre><nowiki> C6_HEADER(`/* This will be in control6.h */') #include "hardware/onewire/ds2450.h" uint16_t counter1 = 0; uint16_t var1 = 0; CONTROL_START CLOCK_USED() THREAD(start) var1 = 1; WAIT(5) var1 = 0; WAIT(5) THREAD_END(start) TCP_HANDLER_PERSIST(message_handler); if (var1 == 1){ ow_rom_code_t rom_code; uint16_t result; rom_code.bytewise[0] = 0x20; rom_code.bytewise[1] = 0x68; rom_code.bytewise[2] = 0x64; rom_code.bytewise[3] = 0x14; rom_code.bytewise[4] = 0x00; rom_code.bytewise[5] = 0x00; rom_code.bytewise[6] = 0x00; rom_code.bytewise[7] = 0xb5; ow_ds2450_convert(&rom_code, 0x0f, 0x00); ow_ds2450_get(&rom_code, 2, 2, &result); TCP_SEND("%u", result); WAIT(15) } TCP_HANDLER_END(); ON STARTUP DO THREAD_START(start) TCP_CONNECT(192.168.123.106, 4445, message_handler); END CONTROL_END </nowiki></pre> dbf424bcfb9eb22428f69ddc7a85504fc78e6814 839 838 2012-09-24T07:59:28Z Djmaster 255 /* Nach einer Stunde funktioniert die GET ausgabe nicht */ wikitext text/x-wiki {{i18n|Onewire/DS2450}} {{Module |NAME=Onewire DS2450 |MENUCONFIG={{I/O}}->Onewire support |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} *Beitrag am 23.09.2012 erneuert. == Dallas 1-wire DS2450 4 Kanal ADC == Der DS2450 ist ein 4 Kanal ADC mit einer maximalen Auflösung von 16 Bit (vgl. [http://datasheets.maxim-ic.com/en/ds/DS2450.pdf Datenblatt]). Die analog-digital Umwandlung erfolgt durch einen internen four-to-one multiplexer. Kanäle, die nicht als Eingänge genutzt werden, können als Ausgänge (open drain) geschaltet werden (max. 4mA und 6V). === ECMD Interface === Über ECMD sind folgende Befehle für den DS2450 bekannt: *<code>1w ds2450 power</code> *<code>1w ds2450 res</code> *<code>1w ds2450 oc</code> *<code>1w ds2450 oe</code> *<code>1w ds2450 range</code> *<code>1w ds2450 por</code> *<code>1w ds2450 convert</code> *<code>1w ds2450 get</code> ==== Grundsätzliches ==== Grundsätzlich gilt für alle Befehle: * als erstes Argument kann optional die 64 Bit ROM Id des DS2450 angegeben werden, der angesprochen werden soll (match rom). Wird die ROM Id <b>nicht</b> angeben, so werden alle im Bus befindlichen 1-wire Devices (egal welchen Typs) angesprochen (skip rom). Dies macht <b>nur</b> Sinn, wenn sich <b>genau</b> ein Device im 1-wire Bus befindet (skip rom führt bei mehreren Devices unweigerlich dazu, dass mehrere Devices gleichzeitig antworten werden, was zu Bit-Salat beim bus master (d.h. Ethersex) führt, das Datenblatt spricht von "a wired-AND result"). * wird ein Kanal angeben, so ist dieser mit einem Buchstaben (entsprechend Datenblatt) zu bezeichnen (case-insensitiv). * wird mit einem Befehl ein Wert gesetzt, so kann mit dem gleichen Befehl der Wert gelesen werden, in dem man kein Werte-Argument angibt. ==== <code>1w ds2450 power</code> ==== Hierüber wird die Art der Spannungsversorgung des DS2450 gesetzt (global). Dieser Parameter wird durch den Anschluss an der 1-wire Bus bestimmt, vgl. die [[Dallas_1-wire_Bus#Anschluss_AVR-NET-IO | Erklärung der Anschlussmöglichkeiten]]. Wird der 1-wire Bus "normal" (drei-adrig) betrieben, so muss der Wert auf 1 gesetzt werden. Wird der Bus "parasitär" (zwei-adrig) betrieben, muss der Wert auf 0 gesetzt werden. Default-Wert: 0 Beispiel: 1w ds2450 power 1 (der DS250 wird auf "normale" Spannungsversorgung konfiguriert) ==== <code>1w ds2450 res</code> ==== Hierüber wird die Auflösung der analog-digital Umwandlung gesetzt (pro Kanal). Die Auflösung kann zw. 1 und 16 Bit eingestellt werden. Die Eingabe erfolgt als 8 Bit Hexadezimalwert, wobei eine Auflösung von 16 Bit durch den Wert 0x00 oder alternativ 0x10 erreicht wird. Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0x08 Beispiel: 1w ds2450 res c 08 (setzt die Auflösung für Kanal C auf 0x08, d.h. 8 Bit) ==== <code>1w ds2450 oc</code> ==== Hierüber kann der Ausgang ein- oder ausgeschaltet werden (pro Kanal). Voraussetzung ist, dass über [[DS2450#1w_ds2450_oe | 1w ds2450 oe]] der Kanal als Ausgang geschaltet wurde (ansonsten wird das OC-Bit ignoriert). Die Eingabe erfolgt als bool über 0 (Ausgangstransistor leitend) bzw. 1 (Ausgangstransistor nicht-leitend). Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0 Beispiel: 1w ds2450 oc a 1 (der Ausgangstransistor des Kanal A wird leitend) ==== <code>1w ds2450 oe</code> ==== Hierüber kann der Kanal als Ein- oder Ausgang gesetzt werden (pro Kanal). Eine analog-digital Umwandlung ist <b>nur</b> möglich, wenn das OE-Bit auf 0 gesetzt ist. In diesem Fall wird das OC-Bit ignoriert. Ist das OE-Bit auf 1 gesetzt, kann der Ausgang über 1w ds2450 oc ein- bzw. ausgeschaltet werden. Die Eingabe erfolgt als bool über 0 (Eingang für ADC) bzw. 1 (Ausgang open drain). Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0 Beispiel: 1w ds2450 oe d 1 (Kanal A wird als Ausgang gesetzt) ==== <code>1w ds2450 range</code> ==== Hierüber kann der Spannungs-Bereich angegeben werden, in dem die analog-digital Umwandlung stattfinden soll. Die Eingabe erfolgt als bool über 0 (Spannungsbereich 0 bis 2,55V) bzw. 1 (Spannungsbereich 0 bis 5,10V). Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0 Beispiel: 1w ds2450 range b 1 (für Kanal B wird bei der analog-digital Umwandlung der Spannungsbereich 0 bis 5,10V genutzt) ==== <code>1w ds2450 por</code> ==== Hierüber kann das power on reset Bit gelesen bzw. gesetzt werden. Nach einem power-on reset cycle setzt der DS2450 das Bit auf 1. Das Bit beeinflusst die conditional search, welche in Ethersex (noch) nicht implementiert ist. Setzt der bus master das Bit auf 0, so nimmt der DS2450 nicht mehr an der conditional search teil Die Eingabe erfolgt als bool über 0 bzw. 1. Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 1 (nach power-on reset cycle) Beispiel: 1w ds2450 por c 0 (für Kanal C wird das power on reset Bit auf 0 gesetzt) FixMe: Es sieht so aus, als kann das Bit nur global gesetzt werden, d.h. wird es für einen Kanal verändert, haben danach alle anderen Kanäle den gleich POR-Bit Wert. Außerdem kann man das Bit nicht mehr auf 1 setzen, wenn es vorher schon auf 0 gesetzt wurde (das widerspricht aber dem Datenblatt!). ==== <code>1w ds2450 convert</code> ==== Hierüber wird die analog-digital Umwandlung ausgelöst (analog den 1-wire Temperatursensoren). Werden keine weiteren Argumente angegeben, so wird die Umwandlung für alle 4 Kanäle des DS2450 durchgeführt (FixMe: vermutlich werden die Kanäle, bei denen das OE-Bit auf 1 steht ausgelassen, dass ist aber nicht durch Dallas dokumentiert). Optional können zwei Argumente angegeben werden (werden Argumente angegeben, <b>müssen beide</b> Argumente angegeben werden!): * input select mask * read-out control ===== input select mask ===== Mit der input select mask kann angegeben werden, für welche Kanäle die analog-digital Umwandlung durchgeführt werden soll. Die input select mask ist ein 8 Bit Hexadezimalwert: {| border=1 cellspacing=0 padding=4 class=wikitable ! bit7 !! bit6 !! bit5 !! bit4 !! bit3 !! bit2 !! bit1 !! bit0 |- | ignore || ignore || ignore || ignore || Kanal D || Kanal C || Kanal B || Kanal A |} Eine input select mask von 0x0f bedeutet also, dass für alle 4 Kanäle die analog-digital Umwandlung durchgeführt werden soll. Eine mask von 0x00 ist (offensichtlich) sinnlos. Eine ungültige input select mask (d.h. input select mask == 0x00 oder > 0x0f) wird erkannt und führt zu einer ECMD-Fehlermeldung. Die analog-digital Umwandlung erfolgt in der Reihenfolge von Kanal A zu Kanal D, wobei die nicht gewünschte Kanäle (sprich jene, wo das input select mask Bit auf 0 steht) übersprungen werden. Der DS2450 braucht für jedes Bit Auflösung ca. 60 bis 80µs. Außerdem braucht das Umwandlung-Kommando generell 160µs (offset) Dies bedeutet, dass eine Umwandlung aller 4 Kanäle bei maximaler 16 Bit Auflösung also nicht länger als 4*16*80+160µs = 5280µs = 5,28ms dauern wird. ===== read out control ===== Mit dem read out control kann angegeben werden, ob und wie das Register für die Ergebnisse der analog-digital Umwandlung vorbelegt werden soll. Das macht nur dann Sinn, wenn die Umwandlungsergebnisse schon gelesen werden sollen, während der DS2450 im Hintergrund noch die analog-digital Umwandlung durchführt (was möglich ist). Das read out control ist ein 8 Bit Hexadezimalwert: {| border=1 cellspacing=0 padding=4 class=wikitable ! bit7 !! bit6 !! bit5 !! bit4 !! bit3 !! bit2 !! bit1 !! bit0 |- | Set D || Clear D || Set C || Clear C || Set B || Clear B || Set A || Clear A |} Set bzw. Clear verhalten sich wie folgt: {| border=1 cellspacing=0 padding=4 class=wikitable ! Set !! Clear !! Ergebnis |- | 0 || 0 || keine Veränderung am Umwandlung-Register |- | 0 || 1 || alle Bits des Umwandlung-Register werden auf 0 gesetzt |- | 1 || 0 || alle Bits des Umwandlung-Register werden auf 1 gesetzt |- | 1 || 1 || invalid |} Ungültige Kombinationen im read out control (d.h. Set = 1 und Clear = 1) werden erkannt und führen zu einer ECMD-Fehlermeldung. Default-Werte: * input select mask: 0x04 * read out control: 0x00 Beispiel: 1w ds2450 convert (für alle Kanäle wird die analog-digital Umwandlung durchgeführt) ==== <code>1w ds2450 get</code> ==== Hierüber wird das Ergebnis der analog-digital Umwandlung ausgelesen (analog den 1-wire Temperatursensoren). Werden keine weiteren Argumente angegeben, so werden die Umwandlungsergebnisse für alle 4 Kanäle des DS2450 ausgegeben. Optional kann ein Kanal angegeben werden, dann wird nur das Umwandlungsergebniss dieses Kanals ausgegeben. Wurde seit dem letzten power-on reset cycle keine Umwandlung durchgeführt, stehen alle Bits der Register auf 0. Die Ausgabe erfolgt als raw (unsigned integer 16 Bit - <code>uint16_t</code>). Die eingelesene Spannung errechnet sich wie folgt (VAL ist die Ausgabe von <code>1w ds2450 get</code>): * für range = 0 (0..2,55V) VAL ------- * 2,55V 2**16-1 * für range = 1 (0..5,10V) VAL ------- * 5,10V 2**16-1 Default-Werte: - Beispiel: 1w ds2450 get (die Umwandlungsergebnisse für alle 4 Kanäle werden ausgegeben) === Beispielschaltung 1=== Hier ein Beispielschaltung für den DS2450. Kanal A wird als Eingabe genutzt (range = 1). Kanal D wird als Ausgabe genutzt, über den Optokoppler kann die LED geschaltet werden. Der Widerstand R1 muss <b>unbedingt</b> entsprechend dem Optokoppler dimensioniert werden. Beim 4N35 sind 1k3 ausreichend, dann fließt ein Strom von ca. 2,8mA. [[File:DS2450 Beispiel 01.gif|600px|Beispielschaltung DS2450]] === Beispielschaltung 2=== Hier die Beispielschaltung 2 für den DS2450. Kanal A/B/C/D wird als Eingang genutzt (Range = 1). * I/O-A wird zb. als Tür oder Fenster Detektor genutzt. * I/O-B wird als Eingang für den Luftfeuchtesensor genutzt. * I/O-C wird als Eingang für den Luftdrucksensor genutzt. * I/O-D wird genutzt um die Versorgungsspannung zu messen welche bei der Berechnung des Luftdrucksensor benötigt wird. <br> Weiters hängt ein DS2450 und ein DS1820 parallel am Bus um noch eine Temperatur über den Bus zu bekommen. * [http://www.ethersex.de/images/5/5c/1W_MPX6115_HIH4000.pdf Schaltung als PDF downloaden] [[File:1W MPX6115 HIH4000.png|600px|Beispielschaltung DS2450]] * Zum Initialisieren verwende ich folgende Kommandos via ecmd zb.: <pre><nowiki> 1w ds2450 power 1 //(drei adrig) 1w ds2450 res c 08 //(00 / 10 = 16bit, 08 8bit) 1w ds2450 oe c 0 //(als eingang stetzen) 1w ds2450 range c 1 //(Range 0-5,10V) 1w ds2450 convert 1w ds2450 get </nowiki></pre> == Probleme == === Berechnungen des Feuchtesensor === // lt. Datenblatt: // OFFSET 0.958062V bei 0%RH // SLOPE: 30.680 mV/%RH $V_Feuchte = ($Humid/65535)*5.17; $RH_Feuchte = ($V_Feuchte - 0.958062) * 34.558; //Werte nach Kalibrierung ( 34.558 Ist bei mir genauer als 30.680) $RHR = $RH_Feuchte / ((1.0305 + (0.000044 * 25) - (0.0000011 * pow(22.6,2)))); echo $RHR; === Berechnungen des Drucksensor === $ADCwert = ($Druck/65535)*5.10; $ADCVBuswert= ($Vdd/65535)*5.10; $kpawert = $ADCwert/($ADCVBuswert*0.009)+10.55; echo $kpawert*10; === Werte des ADC schwanken beim auslesen === Lege doch mal die Versorgungsspannung direkt auf einen Eingang und schaue mal ob der Wert immer noch schwankt. === Nach einer Stunde funktioniert die GET ausgabe nicht === Es folgt eine leere weiße Seite im http via ecmd. Vielleicht ist das nur bei mir so aber nach einem wdreset funktioniert es wieder. (Der ds2450 wird alle 30 sekunden abgefragt) == Einbindung in Control6 (tcp_send) == https://github.com/ethersex/ethersex/blob/master/hardware/onewire/ds2450.h<br> http://www.tutorials.at/c/03-dateneingabe-ausgabe.html<br> <br> '''"ecmd?1w list"''' ergibt den rom code '''20686414000000b5''' für den ds2450<br> <br> <pre><nowiki> C6_HEADER(`/* This will be in control6.h */') #include "hardware/onewire/ds2450.h" uint16_t counter1 = 0; uint16_t var1 = 0; CONTROL_START CLOCK_USED() THREAD(start) var1 = 1; WAIT(5) var1 = 0; WAIT(5) THREAD_END(start) TCP_HANDLER_PERSIST(message_handler); if (var1 == 1){ ow_rom_code_t rom_code; uint16_t result; rom_code.bytewise[0] = 0x20; rom_code.bytewise[1] = 0x68; rom_code.bytewise[2] = 0x64; rom_code.bytewise[3] = 0x14; rom_code.bytewise[4] = 0x00; rom_code.bytewise[5] = 0x00; rom_code.bytewise[6] = 0x00; rom_code.bytewise[7] = 0xb5; ow_ds2450_convert(&rom_code, 0x0f, 0x00); ow_ds2450_get(&rom_code, 2, 2, &result); TCP_SEND("%u", result); WAIT(15) } TCP_HANDLER_END(); ON STARTUP DO THREAD_START(start) TCP_CONNECT(192.168.123.106, 4445, message_handler); END CONTROL_END </nowiki></pre> f688213a0efddfcdd5beefdd2fd954173c736576 840 839 2012-09-24T08:03:29Z Djmaster 255 /* 1w ds2450 power */ wikitext text/x-wiki {{i18n|Onewire/DS2450}} {{Module |NAME=Onewire DS2450 |MENUCONFIG={{I/O}}->Onewire support |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} *Beitrag am 23.09.2012 erneuert. == Dallas 1-wire DS2450 4 Kanal ADC == Der DS2450 ist ein 4 Kanal ADC mit einer maximalen Auflösung von 16 Bit (vgl. [http://datasheets.maxim-ic.com/en/ds/DS2450.pdf Datenblatt]). Die analog-digital Umwandlung erfolgt durch einen internen four-to-one multiplexer. Kanäle, die nicht als Eingänge genutzt werden, können als Ausgänge (open drain) geschaltet werden (max. 4mA und 6V). === ECMD Interface === Über ECMD sind folgende Befehle für den DS2450 bekannt: *<code>1w ds2450 power</code> *<code>1w ds2450 res</code> *<code>1w ds2450 oc</code> *<code>1w ds2450 oe</code> *<code>1w ds2450 range</code> *<code>1w ds2450 por</code> *<code>1w ds2450 convert</code> *<code>1w ds2450 get</code> ==== Grundsätzliches ==== Grundsätzlich gilt für alle Befehle: * als erstes Argument kann optional die 64 Bit ROM Id des DS2450 angegeben werden, der angesprochen werden soll (match rom). Wird die ROM Id <b>nicht</b> angeben, so werden alle im Bus befindlichen 1-wire Devices (egal welchen Typs) angesprochen (skip rom). Dies macht <b>nur</b> Sinn, wenn sich <b>genau</b> ein Device im 1-wire Bus befindet (skip rom führt bei mehreren Devices unweigerlich dazu, dass mehrere Devices gleichzeitig antworten werden, was zu Bit-Salat beim bus master (d.h. Ethersex) führt, das Datenblatt spricht von "a wired-AND result"). * wird ein Kanal angeben, so ist dieser mit einem Buchstaben (entsprechend Datenblatt) zu bezeichnen (case-insensitiv). * wird mit einem Befehl ein Wert gesetzt, so kann mit dem gleichen Befehl der Wert gelesen werden, in dem man kein Werte-Argument angibt. ==== <code>1w ds2450 power</code> ==== Hierüber wird die Art der Spannungsversorgung des DS2450 gesetzt (global). Dieser Parameter wird durch den Anschluss an der 1-wire Bus bestimmt, vgl. die [[Onewire_(Deutsch)#Anschluss_AVR-NET-IO | Erklärung der Anschlussmöglichkeiten]]. Wird der 1-wire Bus "normal" (drei-adrig) betrieben, so muss der Wert auf 1 gesetzt werden. Wird der Bus "parasitär" (zwei-adrig) betrieben, muss der Wert auf 0 gesetzt werden. Default-Wert: 0 Beispiel: 1w ds2450 power 1 (der DS250 wird auf "normale" Spannungsversorgung konfiguriert) ==== <code>1w ds2450 res</code> ==== Hierüber wird die Auflösung der analog-digital Umwandlung gesetzt (pro Kanal). Die Auflösung kann zw. 1 und 16 Bit eingestellt werden. Die Eingabe erfolgt als 8 Bit Hexadezimalwert, wobei eine Auflösung von 16 Bit durch den Wert 0x00 oder alternativ 0x10 erreicht wird. Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0x08 Beispiel: 1w ds2450 res c 08 (setzt die Auflösung für Kanal C auf 0x08, d.h. 8 Bit) ==== <code>1w ds2450 oc</code> ==== Hierüber kann der Ausgang ein- oder ausgeschaltet werden (pro Kanal). Voraussetzung ist, dass über [[DS2450#1w_ds2450_oe | 1w ds2450 oe]] der Kanal als Ausgang geschaltet wurde (ansonsten wird das OC-Bit ignoriert). Die Eingabe erfolgt als bool über 0 (Ausgangstransistor leitend) bzw. 1 (Ausgangstransistor nicht-leitend). Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0 Beispiel: 1w ds2450 oc a 1 (der Ausgangstransistor des Kanal A wird leitend) ==== <code>1w ds2450 oe</code> ==== Hierüber kann der Kanal als Ein- oder Ausgang gesetzt werden (pro Kanal). Eine analog-digital Umwandlung ist <b>nur</b> möglich, wenn das OE-Bit auf 0 gesetzt ist. In diesem Fall wird das OC-Bit ignoriert. Ist das OE-Bit auf 1 gesetzt, kann der Ausgang über 1w ds2450 oc ein- bzw. ausgeschaltet werden. Die Eingabe erfolgt als bool über 0 (Eingang für ADC) bzw. 1 (Ausgang open drain). Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0 Beispiel: 1w ds2450 oe d 1 (Kanal A wird als Ausgang gesetzt) ==== <code>1w ds2450 range</code> ==== Hierüber kann der Spannungs-Bereich angegeben werden, in dem die analog-digital Umwandlung stattfinden soll. Die Eingabe erfolgt als bool über 0 (Spannungsbereich 0 bis 2,55V) bzw. 1 (Spannungsbereich 0 bis 5,10V). Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0 Beispiel: 1w ds2450 range b 1 (für Kanal B wird bei der analog-digital Umwandlung der Spannungsbereich 0 bis 5,10V genutzt) ==== <code>1w ds2450 por</code> ==== Hierüber kann das power on reset Bit gelesen bzw. gesetzt werden. Nach einem power-on reset cycle setzt der DS2450 das Bit auf 1. Das Bit beeinflusst die conditional search, welche in Ethersex (noch) nicht implementiert ist. Setzt der bus master das Bit auf 0, so nimmt der DS2450 nicht mehr an der conditional search teil Die Eingabe erfolgt als bool über 0 bzw. 1. Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 1 (nach power-on reset cycle) Beispiel: 1w ds2450 por c 0 (für Kanal C wird das power on reset Bit auf 0 gesetzt) FixMe: Es sieht so aus, als kann das Bit nur global gesetzt werden, d.h. wird es für einen Kanal verändert, haben danach alle anderen Kanäle den gleich POR-Bit Wert. Außerdem kann man das Bit nicht mehr auf 1 setzen, wenn es vorher schon auf 0 gesetzt wurde (das widerspricht aber dem Datenblatt!). ==== <code>1w ds2450 convert</code> ==== Hierüber wird die analog-digital Umwandlung ausgelöst (analog den 1-wire Temperatursensoren). Werden keine weiteren Argumente angegeben, so wird die Umwandlung für alle 4 Kanäle des DS2450 durchgeführt (FixMe: vermutlich werden die Kanäle, bei denen das OE-Bit auf 1 steht ausgelassen, dass ist aber nicht durch Dallas dokumentiert). Optional können zwei Argumente angegeben werden (werden Argumente angegeben, <b>müssen beide</b> Argumente angegeben werden!): * input select mask * read-out control ===== input select mask ===== Mit der input select mask kann angegeben werden, für welche Kanäle die analog-digital Umwandlung durchgeführt werden soll. Die input select mask ist ein 8 Bit Hexadezimalwert: {| border=1 cellspacing=0 padding=4 class=wikitable ! bit7 !! bit6 !! bit5 !! bit4 !! bit3 !! bit2 !! bit1 !! bit0 |- | ignore || ignore || ignore || ignore || Kanal D || Kanal C || Kanal B || Kanal A |} Eine input select mask von 0x0f bedeutet also, dass für alle 4 Kanäle die analog-digital Umwandlung durchgeführt werden soll. Eine mask von 0x00 ist (offensichtlich) sinnlos. Eine ungültige input select mask (d.h. input select mask == 0x00 oder > 0x0f) wird erkannt und führt zu einer ECMD-Fehlermeldung. Die analog-digital Umwandlung erfolgt in der Reihenfolge von Kanal A zu Kanal D, wobei die nicht gewünschte Kanäle (sprich jene, wo das input select mask Bit auf 0 steht) übersprungen werden. Der DS2450 braucht für jedes Bit Auflösung ca. 60 bis 80µs. Außerdem braucht das Umwandlung-Kommando generell 160µs (offset) Dies bedeutet, dass eine Umwandlung aller 4 Kanäle bei maximaler 16 Bit Auflösung also nicht länger als 4*16*80+160µs = 5280µs = 5,28ms dauern wird. ===== read out control ===== Mit dem read out control kann angegeben werden, ob und wie das Register für die Ergebnisse der analog-digital Umwandlung vorbelegt werden soll. Das macht nur dann Sinn, wenn die Umwandlungsergebnisse schon gelesen werden sollen, während der DS2450 im Hintergrund noch die analog-digital Umwandlung durchführt (was möglich ist). Das read out control ist ein 8 Bit Hexadezimalwert: {| border=1 cellspacing=0 padding=4 class=wikitable ! bit7 !! bit6 !! bit5 !! bit4 !! bit3 !! bit2 !! bit1 !! bit0 |- | Set D || Clear D || Set C || Clear C || Set B || Clear B || Set A || Clear A |} Set bzw. Clear verhalten sich wie folgt: {| border=1 cellspacing=0 padding=4 class=wikitable ! Set !! Clear !! Ergebnis |- | 0 || 0 || keine Veränderung am Umwandlung-Register |- | 0 || 1 || alle Bits des Umwandlung-Register werden auf 0 gesetzt |- | 1 || 0 || alle Bits des Umwandlung-Register werden auf 1 gesetzt |- | 1 || 1 || invalid |} Ungültige Kombinationen im read out control (d.h. Set = 1 und Clear = 1) werden erkannt und führen zu einer ECMD-Fehlermeldung. Default-Werte: * input select mask: 0x04 * read out control: 0x00 Beispiel: 1w ds2450 convert (für alle Kanäle wird die analog-digital Umwandlung durchgeführt) ==== <code>1w ds2450 get</code> ==== Hierüber wird das Ergebnis der analog-digital Umwandlung ausgelesen (analog den 1-wire Temperatursensoren). Werden keine weiteren Argumente angegeben, so werden die Umwandlungsergebnisse für alle 4 Kanäle des DS2450 ausgegeben. Optional kann ein Kanal angegeben werden, dann wird nur das Umwandlungsergebniss dieses Kanals ausgegeben. Wurde seit dem letzten power-on reset cycle keine Umwandlung durchgeführt, stehen alle Bits der Register auf 0. Die Ausgabe erfolgt als raw (unsigned integer 16 Bit - <code>uint16_t</code>). Die eingelesene Spannung errechnet sich wie folgt (VAL ist die Ausgabe von <code>1w ds2450 get</code>): * für range = 0 (0..2,55V) VAL ------- * 2,55V 2**16-1 * für range = 1 (0..5,10V) VAL ------- * 5,10V 2**16-1 Default-Werte: - Beispiel: 1w ds2450 get (die Umwandlungsergebnisse für alle 4 Kanäle werden ausgegeben) === Beispielschaltung 1=== Hier ein Beispielschaltung für den DS2450. Kanal A wird als Eingabe genutzt (range = 1). Kanal D wird als Ausgabe genutzt, über den Optokoppler kann die LED geschaltet werden. Der Widerstand R1 muss <b>unbedingt</b> entsprechend dem Optokoppler dimensioniert werden. Beim 4N35 sind 1k3 ausreichend, dann fließt ein Strom von ca. 2,8mA. [[File:DS2450 Beispiel 01.gif|600px|Beispielschaltung DS2450]] === Beispielschaltung 2=== Hier die Beispielschaltung 2 für den DS2450. Kanal A/B/C/D wird als Eingang genutzt (Range = 1). * I/O-A wird zb. als Tür oder Fenster Detektor genutzt. * I/O-B wird als Eingang für den Luftfeuchtesensor genutzt. * I/O-C wird als Eingang für den Luftdrucksensor genutzt. * I/O-D wird genutzt um die Versorgungsspannung zu messen welche bei der Berechnung des Luftdrucksensor benötigt wird. <br> Weiters hängt ein DS2450 und ein DS1820 parallel am Bus um noch eine Temperatur über den Bus zu bekommen. * [http://www.ethersex.de/images/5/5c/1W_MPX6115_HIH4000.pdf Schaltung als PDF downloaden] [[File:1W MPX6115 HIH4000.png|600px|Beispielschaltung DS2450]] * Zum Initialisieren verwende ich folgende Kommandos via ecmd zb.: <pre><nowiki> 1w ds2450 power 1 //(drei adrig) 1w ds2450 res c 08 //(00 / 10 = 16bit, 08 8bit) 1w ds2450 oe c 0 //(als eingang stetzen) 1w ds2450 range c 1 //(Range 0-5,10V) 1w ds2450 convert 1w ds2450 get </nowiki></pre> == Probleme == === Berechnungen des Feuchtesensor === // lt. Datenblatt: // OFFSET 0.958062V bei 0%RH // SLOPE: 30.680 mV/%RH $V_Feuchte = ($Humid/65535)*5.17; $RH_Feuchte = ($V_Feuchte - 0.958062) * 34.558; //Werte nach Kalibrierung ( 34.558 Ist bei mir genauer als 30.680) $RHR = $RH_Feuchte / ((1.0305 + (0.000044 * 25) - (0.0000011 * pow(22.6,2)))); echo $RHR; === Berechnungen des Drucksensor === $ADCwert = ($Druck/65535)*5.10; $ADCVBuswert= ($Vdd/65535)*5.10; $kpawert = $ADCwert/($ADCVBuswert*0.009)+10.55; echo $kpawert*10; === Werte des ADC schwanken beim auslesen === Lege doch mal die Versorgungsspannung direkt auf einen Eingang und schaue mal ob der Wert immer noch schwankt. === Nach einer Stunde funktioniert die GET ausgabe nicht === Es folgt eine leere weiße Seite im http via ecmd. Vielleicht ist das nur bei mir so aber nach einem wdreset funktioniert es wieder. (Der ds2450 wird alle 30 sekunden abgefragt) == Einbindung in Control6 (tcp_send) == https://github.com/ethersex/ethersex/blob/master/hardware/onewire/ds2450.h<br> http://www.tutorials.at/c/03-dateneingabe-ausgabe.html<br> <br> '''"ecmd?1w list"''' ergibt den rom code '''20686414000000b5''' für den ds2450<br> <br> <pre><nowiki> C6_HEADER(`/* This will be in control6.h */') #include "hardware/onewire/ds2450.h" uint16_t counter1 = 0; uint16_t var1 = 0; CONTROL_START CLOCK_USED() THREAD(start) var1 = 1; WAIT(5) var1 = 0; WAIT(5) THREAD_END(start) TCP_HANDLER_PERSIST(message_handler); if (var1 == 1){ ow_rom_code_t rom_code; uint16_t result; rom_code.bytewise[0] = 0x20; rom_code.bytewise[1] = 0x68; rom_code.bytewise[2] = 0x64; rom_code.bytewise[3] = 0x14; rom_code.bytewise[4] = 0x00; rom_code.bytewise[5] = 0x00; rom_code.bytewise[6] = 0x00; rom_code.bytewise[7] = 0xb5; ow_ds2450_convert(&rom_code, 0x0f, 0x00); ow_ds2450_get(&rom_code, 2, 2, &result); TCP_SEND("%u", result); WAIT(15) } TCP_HANDLER_END(); ON STARTUP DO THREAD_START(start) TCP_CONNECT(192.168.123.106, 4445, message_handler); END CONTROL_END </nowiki></pre> b9f90173feb3b162f0b4e23c7fa6dfad852ba0d0 0 316 819 2012-09-23T14:54:30Z Djmaster 255 Created page with "{{i18n|Onewire_DS2450}} {{Module |NAME=Onewire_DS2450 |MENUCONFIG={{I/O}}->Onewire support |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} …" wikitext text/x-wiki {{i18n|Onewire_DS2450}} {{Module |NAME=Onewire_DS2450 |MENUCONFIG={{I/O}}->Onewire support |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} * For the moment follow the German Link --> [http://www.ethersex.de/index.php/Onewire_DS2450_(Deutsch) http://www.ethersex.de/index.php/Onewire_DS2450_(Deutsch)] 7d9228061944dd98ed66ee41ecdeafa6965c1976 822 819 2012-09-23T15:18:30Z Mgue 312 moved [[Onewire DS2450]] to [[Onewire/DS2450]] wikitext text/x-wiki {{i18n|Onewire_DS2450}} {{Module |NAME=Onewire_DS2450 |MENUCONFIG={{I/O}}->Onewire support |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} * For the moment follow the German Link --> [http://www.ethersex.de/index.php/Onewire_DS2450_(Deutsch) http://www.ethersex.de/index.php/Onewire_DS2450_(Deutsch)] 7d9228061944dd98ed66ee41ecdeafa6965c1976 827 822 2012-09-23T15:19:51Z Mgue 312 change Title wikitext text/x-wiki {{i18n|Onewire/DS2450}} {{Module |NAME=Onewire DS2450 |MENUCONFIG={{I/O}}->Onewire support |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} * For the moment follow the German Link --> [http://www.ethersex.de/index.php/Onewire_DS2450_(Deutsch) http://www.ethersex.de/index.php/Onewire_DS2450_(Deutsch)] 345d695f6a2874f4d20afa0bfdffae064ec189dc 0 317 823 2012-09-23T15:18:30Z Mgue 312 moved [[Onewire DS2450]] to [[Onewire/DS2450]] wikitext text/x-wiki #REDIRECT [[Onewire/DS2450]] 4331bd8c850e680bd4fa2df0d5453f768294a596 0 318 825 2012-09-23T15:18:51Z Mgue 312 moved [[Onewire DS2450 (Deutsch)]] to [[Onewire/DS2450 (Deutsch)]] wikitext text/x-wiki #REDIRECT [[Onewire/DS2450 (Deutsch)]] 234a29cd8c4eb289873fdf22e368336d4375d05d 0 29 829 334 2012-09-23T15:29:44Z Mgue 312 /* Control of Stella/Pins by IR commands */ wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR Receivers->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP is a port of the [http://www.mikrocontroller.net/articles/IRMP infrared multi-protocol decoder] for [[Ethersex]]. == Connection == The reception of IR signals is performed by a receiver TSOP1736 type (or similar). This may be connected to any pin. The interrogation of the pins and the decoding of the IR protocol is done in an ISR, which occupies one 8-bit timer of the ATmegas. When sending the signal with the carrier frequency of the respective IR Protocol is [[PWM]] modulated. This is another 8-bit timer of the ATmegas (OC0/OC2) is demonstrated. On the [[Etherrape]] board takes a [[NE555]] this function, ie the option ''Use external modulator for the transmitter'' is activated. It saves a timer on the [[AVR]] is set at a carrier frequency. Example of a ATMega32 from: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Meaning: * IRMP_RX - pin the IR receiver is connected to * IRMP_USE_TIMER2 - use Timer2 for receiver, Timer0 for sender (undef = reversed) * IRMP_RX_LOW_ACTIVE - the IR receiver is low-active (undef = high-active) * IRMP_RX_LED_LOW_ACTIVE - the control LED of the receiver is switched to USS (undef = switched to GND) * IRMP_TX - pin the IR sender is connected to (=output of Timer0 or Timer2, see IRMP_USE_TIMER2)<br>'''Caution: 0A to 2A if MCU with A / B channel''' * IRMP_TX_LED_LOW_ACTIVE - the control LED of the sender is switched to USS (undef = switched to GND) == Configuration == Each supported IR protocol occupies memory of code. Therefore, one should select only the required protocols. A detailed overview of the protocols are the [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail article in the mikrocontroller forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ --- Debugging Flags │ │ [ ] IRMP Debug IRMP also decodes the RC5 protocol, so that the separately [[Ethersex]] contained [[RC5]] decoder is not needed any longer. == [[ECMD]] == IRMP implements a [[ECMD]] interface for reading received and decoded IR commands and send IR commands. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == === Output received characters via [[SYSLOG|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> IRMP_READ checks for received IR code and stores it in the variables IRMP_PROTOCOL, IRMP_ADDRESS, and IRMP_COMMAND IRMP_FLAGS. Return values ​​greater than zero indicate the validity of the variables. If IRMP_FLAGS = 1 it is a repetition. === Control of [[StellaLight|Stella]]/Pins by IR commands === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> The script switches the Stella channel 0 to 255 or 0, the remote control is a Denon (Protocol 8). With ''include'' access to the Stella sources granted.<br> Instead of ''"stella_setValue (STELLA_SET_IMMEDIATELY, 0, 255);"'' ''"PIN_SET (LED)"'' and ''"PIN_CLEAR (LED)"'' can be used ([[Named_PIN|named pin]]). |Named PIN]]). === Send IR commands === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 * no tx support yet dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON * no tx support yet IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Command 5678 to device 1234 will be send with one repetition using the NEC protocol. 01c3a6255db98534442e93b6c12873101677e627 0 319 830 2012-09-23T15:35:40Z Mgue 312 Added some features wikitext text/x-wiki {{i18n|Features}} == Supported Network Hardware == * Ethernet [[ENC28J60 | Microchip's ENC28J60]] with IEEE 802.1q VLAN tagging * [[USB]] * [[RFM12]] * [[ZBUS]] == Network Protocols == * IPv4, IPv4 * TCP/IP, UDP/IP and ICMP * DNS * mDNS (Avahi) * [[BOOTP]] * [[DHCP]] * TFTP (can be used in combination with the [[Ethernet Loader]]) * SYSLOG * [[SNMP]] * SMTP * [[NTP]] (Client and Server) * DynDNS * MySQL (Client) * IRC (Client) * [[XMPP | XMPP / Jabber Client]] * MPD (Music Player Daemon) * [[SOAP]]/XMLRPC * [[UPnP]] * [[Artnet]] == Hardware Drivers == * [[Onewire]] * [[I2C]] Master / Slave * [[ADC input]] * [[PWM Generator]] * [[RFM12 FS20]] * [[RFM12 ASK]] * [[USB]] * [[PS/2 Keyboard]] * [[Button Input]] * [[HC595]] * [[HC165]] * [[IRMP | IR Receivers]] * [[SRAM]] == Software Modules == * [[Ethersex Lighting Architecture]] ** [[Starburst]] ** [[StellaLight]] ** [[DMX Storage]] ** [[DMX FXSlot]] * [[Cron Daemon]] * [[System Clock | Clock ]] * [[VNC Server]] * [[lome6]] * [[Frequency Counter]] 5b2d1fcc89a0a89fdf2113a49234f9d20a3e2d0f 6 320 833 2012-09-24T07:26:51Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 834 833 2012-09-24T07:27:39Z Djmaster 255 uploaded a new version of "[[File:1W MPX6115 HIH4000.pdf]]" wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 321 835 2012-09-24T07:28:00Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 322 841 2012-09-24T08:10:44Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 323 842 2012-09-24T08:11:54Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 324 843 2012-09-24T08:12:15Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 325 844 2012-09-24T08:12:25Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 326 845 2012-09-24T08:12:48Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 327 846 2012-09-24T08:13:05Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 328 847 2012-09-24T08:13:20Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 2 329 848 2012-09-24T08:13:57Z Djmaster 255 Created page with "==Person== Nick im IRC: djmaster oder djmaster2 ==Die Software== ===TFTP-Bootloader & Fuses=== Menuconfig: │ │ Load a Default Configuration ---> │ │ …" wikitext text/x-wiki ==Person== Nick im IRC: djmaster oder djmaster2 ==Die Software== ===TFTP-Bootloader & Fuses=== Menuconfig: │ │ Load a Default Configuration ---> │ │ [*] Ethernet Bootloader │ │ Network ---> │ │ [*] Ethernet (ENC28J60) support ---> │ │ Etherrape IP address: "192.168.12.220" │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ Applications ---> │ │ [*] TFTP support ---> │ │ Bootloader configuration ---> │ │ [*] TFTP-o-matic │ │ --- TFTP-o-matic configuration │ │ TFTP IP address: "192.168.12.120" │ │ TFTP image to load: "ethersex.bin" make clean && make --> ethersex.hex =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 6064/65536 bytes (9.25%) [==----------------------------] Program (.text + .data) : 6064 bytes Data (.data + .bss) : 826 bytes =================================== sudo avrdude -cusbasp -pm644 -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m sudo avrdude -cusbasp -pm644 -U flash:w:ethersex.hex sudo avrdude -cusbasp -pm644 -U lock:w:0x0F:m Achtung bei den SMD Typen vom mega644, ich habe mega644P bekommen, wobei ich jetzt nicht weiß ob die SMD immer P Typen sind. Egal das Problem ist man sollte avrdude genau lesen und auch "-p m644p" anhängen da der P Type eine andere Signatur aufweist. Hat mich ne Stunde gekostet. ;) ==Bilder== ===Testsystem=== <gallery perrow=7> File:1_stella_all_off.jpg File:2_stella_all_on.jpg File:3_mosfets.jpg File:4_schaltung_fet.png </gallery><br> ===Messstation=== <gallery perrow=7> File:IMG_5286.JPG File:IMG_6592.JPG File:IMG_6594.JPG </gallery><br> ==Probleme== 25.1.2011 - ethersex mit m644 und 32khz uhrenquarz.<br> datenblatt mega644 seite 101 - http://www.atmel.com/dyn/resources/prod_documents/doc2593.pdf<br> services/clock/clock.c - zeile 64<br> <obiflix> du könntest https://github.com/ethersex/ethersex/commit/da511f074940423e8e8ef7ee67ca20e6d91f608c rückgängig machen <obiflix> möglicherweise bekommst du dann probleme mit dcf77, falls du das nutzen möchtest, aber einen versuch ist es wert ;) Notiz: Hat funktioniert für den MEGA644<br> Update#1<br> 26.1.2011 - Problem sollte nun behoben sein, Danke an eku! master Erik Kunze * ae3ef98 (2 files in 1 dirs): use timer makros for prescaler 64 (32768Hz/256/64=2Hz) - http://bit.ly/eG2d4c --- DCF muss noch getestet werden 460e541b0b4910683c836fa66aef78979df8193f 2 329 849 848 2012-09-24T08:14:44Z Djmaster 255 /* Person */ wikitext text/x-wiki ==Person== Nick im IRC: djmaster oder djmaster2<br> Web: http://wiki.senseye.org/ ==Die Software== ===TFTP-Bootloader & Fuses=== Menuconfig: │ │ Load a Default Configuration ---> │ │ [*] Ethernet Bootloader │ │ Network ---> │ │ [*] Ethernet (ENC28J60) support ---> │ │ Etherrape IP address: "192.168.12.220" │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ Applications ---> │ │ [*] TFTP support ---> │ │ Bootloader configuration ---> │ │ [*] TFTP-o-matic │ │ --- TFTP-o-matic configuration │ │ TFTP IP address: "192.168.12.120" │ │ TFTP image to load: "ethersex.bin" make clean && make --> ethersex.hex =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 6064/65536 bytes (9.25%) [==----------------------------] Program (.text + .data) : 6064 bytes Data (.data + .bss) : 826 bytes =================================== sudo avrdude -cusbasp -pm644 -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m sudo avrdude -cusbasp -pm644 -U flash:w:ethersex.hex sudo avrdude -cusbasp -pm644 -U lock:w:0x0F:m Achtung bei den SMD Typen vom mega644, ich habe mega644P bekommen, wobei ich jetzt nicht weiß ob die SMD immer P Typen sind. Egal das Problem ist man sollte avrdude genau lesen und auch "-p m644p" anhängen da der P Type eine andere Signatur aufweist. Hat mich ne Stunde gekostet. ;) ==Bilder== ===Testsystem=== <gallery perrow=7> File:1_stella_all_off.jpg File:2_stella_all_on.jpg File:3_mosfets.jpg File:4_schaltung_fet.png </gallery><br> ===Messstation=== <gallery perrow=7> File:IMG_5286.JPG File:IMG_6592.JPG File:IMG_6594.JPG </gallery><br> ==Probleme== 25.1.2011 - ethersex mit m644 und 32khz uhrenquarz.<br> datenblatt mega644 seite 101 - http://www.atmel.com/dyn/resources/prod_documents/doc2593.pdf<br> services/clock/clock.c - zeile 64<br> <obiflix> du könntest https://github.com/ethersex/ethersex/commit/da511f074940423e8e8ef7ee67ca20e6d91f608c rückgängig machen <obiflix> möglicherweise bekommst du dann probleme mit dcf77, falls du das nutzen möchtest, aber einen versuch ist es wert ;) Notiz: Hat funktioniert für den MEGA644<br> Update#1<br> 26.1.2011 - Problem sollte nun behoben sein, Danke an eku! master Erik Kunze * ae3ef98 (2 files in 1 dirs): use timer makros for prescaler 64 (32768Hz/256/64=2Hz) - http://bit.ly/eG2d4c --- DCF muss noch getestet werden 779623a236768b024eafecf6237c21292fbe954c 851 849 2012-09-24T08:20:55Z Djmaster 255 wikitext text/x-wiki [[File:RJ45Buchse_Pinout.png|400px|thumb|RJ45 Buchse]] ==Person== Nick im IRC: djmaster oder djmaster2<br> Web: http://wiki.senseye.org/ ==Bauteile== Für [http://www.lochraster.org/etherrape/ Etherrape] Module {| | {| class="wikitable" |- class="vordergrund" ! Bauteil !! Hersteller !! HerstellerNr !! Lieferant !! Bestellnummer !! Dokumente !! Sonstiges |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/products/en?q=6605424-1 6605424-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154361/ 615-4361] || [http://www.te.com/catalog/pn/en/6605424-1?RQPN=6605424-1 Link] || Netzwerkbuchse ohne LED, Verriegelung Unten |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/pn/en/5-6605308-1 5-6605308-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154383/ 615-4383] || [http://www.te.com/catalog/pn/en/5-6605308-1?RQPN=5-6605308-1 Link] || Netzwerkbuchse mit LED, Verriegelung Unten |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/products/en?q=6605759-1 6605759-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154399/ 615-4399] || [http://www.te.com/catalog/pn/en/6605759-1?RQPN=6605759-1 Link] || Netzwerkbuchse ohne LED, Verriegelung Oben |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/products/en?q=5-6605758-1 5-6605758-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154412/ 615-4412] || [http://www.te.com/catalog/pn/en/5-6605758-1?RQPN=5-6605758-1 Link] || Netzwerkbuchse mit LED, Verriegelung Oben |- align="right" | Hutschienen Gehäuse || Axxatronic || [http://www.axxatronic.de/serie-cnmb.html CNMB-4-KIT-CON] || Conrad || [http://www.conrad.at/ce/de/product/531443/Axxatronic-Hutschienen-Gehaeuse-CNMB-4-KIT-CON-Polycarbonat-L-x-B-x-H-90-x-710-x-58-mm 531443 - 62] || [http://www.axxatronic.de/serie-cnmb.html Link] || (L x B x H) 90 x 71.0 x 58 mm |} ==Die Software== ===TFTP-Bootloader & Fuses=== Menuconfig: │ │ Load a Default Configuration ---> │ │ [*] Ethernet Bootloader │ │ Network ---> │ │ [*] Ethernet (ENC28J60) support ---> │ │ Etherrape IP address: "192.168.12.220" │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ Applications ---> │ │ [*] TFTP support ---> │ │ Bootloader configuration ---> │ │ [*] TFTP-o-matic │ │ --- TFTP-o-matic configuration │ │ TFTP IP address: "192.168.12.120" │ │ TFTP image to load: "ethersex.bin" make clean && make --> ethersex.hex =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 6064/65536 bytes (9.25%) [==----------------------------] Program (.text + .data) : 6064 bytes Data (.data + .bss) : 826 bytes =================================== sudo avrdude -cusbasp -pm644 -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m sudo avrdude -cusbasp -pm644 -U flash:w:ethersex.hex sudo avrdude -cusbasp -pm644 -U lock:w:0x0F:m Achtung bei den SMD Typen vom mega644, ich habe mega644P bekommen, wobei ich jetzt nicht weiß ob die SMD immer P Typen sind. Egal das Problem ist man sollte avrdude genau lesen und auch "-p m644p" anhängen da der P Type eine andere Signatur aufweist. Hat mich ne Stunde gekostet. ;) ==Bilder== ===Testsystem=== <gallery perrow=7> File:1_stella_all_off.jpg File:2_stella_all_on.jpg File:3_mosfets.jpg File:4_schaltung_fet.png </gallery><br> ===Messstation=== <gallery perrow=7> File:IMG_5286.JPG File:IMG_6592.JPG File:IMG_6594.JPG </gallery><br> ==Probleme== 25.1.2011 - ethersex mit m644 und 32khz uhrenquarz.<br> datenblatt mega644 seite 101 - http://www.atmel.com/dyn/resources/prod_documents/doc2593.pdf<br> services/clock/clock.c - zeile 64<br> <obiflix> du könntest https://github.com/ethersex/ethersex/commit/da511f074940423e8e8ef7ee67ca20e6d91f608c rückgängig machen <obiflix> möglicherweise bekommst du dann probleme mit dcf77, falls du das nutzen möchtest, aber einen versuch ist es wert ;) Notiz: Hat funktioniert für den MEGA644<br> Update#1<br> 26.1.2011 - Problem sollte nun behoben sein, Danke an eku! master Erik Kunze * ae3ef98 (2 files in 1 dirs): use timer makros for prescaler 64 (32768Hz/256/64=2Hz) - http://bit.ly/eG2d4c --- DCF muss noch getestet werden 01f1a29e4f5c7e03d6fa5f73eda067540d4532d3 852 851 2012-09-24T08:32:56Z Djmaster 255 wikitext text/x-wiki [[File:RJ45Buchse_Pinout.png|400px|thumb|RJ45 Buchse]] ==Person== Nick im IRC: djmaster oder djmaster2<br> Web: http://wiki.senseye.org/ ==Bauteile== Für [http://www.lochraster.org/etherrape/ Etherrape] Module {| | {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%;" |- ! Bauteil !! Hersteller !! HerstellerNr !! Lieferant !! Bestellnummer !! Dokumente !! Sonstiges |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/products/en?q=6605424-1 6605424-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154361/ 615-4361] || [http://www.te.com/catalog/pn/en/6605424-1?RQPN=6605424-1 Link] || Netzwerkbuchse ohne LED, Verriegelung Unten |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/pn/en/5-6605308-1 5-6605308-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154383/ 615-4383] || [http://www.te.com/catalog/pn/en/5-6605308-1?RQPN=5-6605308-1 Link] || Netzwerkbuchse mit LED, Verriegelung Unten |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/products/en?q=6605759-1 6605759-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154399/ 615-4399] || [http://www.te.com/catalog/pn/en/6605759-1?RQPN=6605759-1 Link] || Netzwerkbuchse ohne LED, Verriegelung Oben |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/products/en?q=5-6605758-1 5-6605758-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154412/ 615-4412] || [http://www.te.com/catalog/pn/en/5-6605758-1?RQPN=5-6605758-1 Link] || Netzwerkbuchse mit LED, Verriegelung Oben |- align="right" | Hutschienen Gehäuse || Axxatronic || [http://www.axxatronic.de/serie-cnmb.html CNMB-4-KIT-CON] || Conrad || [http://www.conrad.at/ce/de/product/531443/Axxatronic-Hutschienen-Gehaeuse-CNMB-4-KIT-CON-Polycarbonat-L-x-B-x-H-90-x-710-x-58-mm 531443 - 62] || [http://www.axxatronic.de/serie-cnmb.html Link] || (L x B x H) 90 x 71.0 x 58 mm |} ==Die Software== ===TFTP-Bootloader & Fuses=== Menuconfig: │ │ Load a Default Configuration ---> │ │ [*] Ethernet Bootloader │ │ Network ---> │ │ [*] Ethernet (ENC28J60) support ---> │ │ Etherrape IP address: "192.168.12.220" │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ Applications ---> │ │ [*] TFTP support ---> │ │ Bootloader configuration ---> │ │ [*] TFTP-o-matic │ │ --- TFTP-o-matic configuration │ │ TFTP IP address: "192.168.12.120" │ │ TFTP image to load: "ethersex.bin" make clean && make --> ethersex.hex =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 6064/65536 bytes (9.25%) [==----------------------------] Program (.text + .data) : 6064 bytes Data (.data + .bss) : 826 bytes =================================== sudo avrdude -cusbasp -pm644 -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m sudo avrdude -cusbasp -pm644 -U flash:w:ethersex.hex sudo avrdude -cusbasp -pm644 -U lock:w:0x0F:m Achtung bei den SMD Typen vom mega644, ich habe mega644P bekommen, wobei ich jetzt nicht weiß ob die SMD immer P Typen sind. Egal das Problem ist man sollte avrdude genau lesen und auch "-p m644p" anhängen da der P Type eine andere Signatur aufweist. Hat mich ne Stunde gekostet. ;) ==Bilder== ===Testsystem=== <gallery perrow=7> File:1_stella_all_off.jpg File:2_stella_all_on.jpg File:3_mosfets.jpg File:4_schaltung_fet.png </gallery><br> ===Messstation=== <gallery perrow=7> File:IMG_5286.JPG File:IMG_6592.JPG File:IMG_6594.JPG </gallery><br> ==Probleme== 25.1.2011 - ethersex mit m644 und 32khz uhrenquarz.<br> datenblatt mega644 seite 101 - http://www.atmel.com/dyn/resources/prod_documents/doc2593.pdf<br> services/clock/clock.c - zeile 64<br> <obiflix> du könntest https://github.com/ethersex/ethersex/commit/da511f074940423e8e8ef7ee67ca20e6d91f608c rückgängig machen <obiflix> möglicherweise bekommst du dann probleme mit dcf77, falls du das nutzen möchtest, aber einen versuch ist es wert ;) Notiz: Hat funktioniert für den MEGA644<br> Update#1<br> 26.1.2011 - Problem sollte nun behoben sein, Danke an eku! master Erik Kunze * ae3ef98 (2 files in 1 dirs): use timer makros for prescaler 64 (32768Hz/256/64=2Hz) - http://bit.ly/eG2d4c --- DCF muss noch getestet werden 736995e7d68a60018927088d6a60d39e10371fb9 854 852 2012-09-24T08:47:52Z Djmaster 255 wikitext text/x-wiki [[File:RJ45Buchse_Pinout.png|400px|thumb|RJ45 Buchse]] [[File:File:Ethersex det ssr.png|400px|thumb|die Theorie]] ==Person== Nick im IRC: djmaster oder djmaster2<br> Web: http://wiki.senseye.org/ ==Bauteile== Für [http://www.lochraster.org/etherrape/ Etherrape] Module {| | {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%;" |- ! Bauteil !! Hersteller !! HerstellerNr !! Lieferant !! Bestellnummer !! Dokumente !! Sonstiges |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/products/en?q=6605424-1 6605424-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154361/ 615-4361] || [http://www.te.com/catalog/pn/en/6605424-1?RQPN=6605424-1 Link] || Netzwerkbuchse ohne LED, Verriegelung Unten |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/pn/en/5-6605308-1 5-6605308-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154383/ 615-4383] || [http://www.te.com/catalog/pn/en/5-6605308-1?RQPN=5-6605308-1 Link] || Netzwerkbuchse mit LED, Verriegelung Unten |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/products/en?q=6605759-1 6605759-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154399/ 615-4399] || [http://www.te.com/catalog/pn/en/6605759-1?RQPN=6605759-1 Link] || Netzwerkbuchse ohne LED, Verriegelung Oben |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/products/en?q=5-6605758-1 5-6605758-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154412/ 615-4412] || [http://www.te.com/catalog/pn/en/5-6605758-1?RQPN=5-6605758-1 Link] || Netzwerkbuchse mit LED, Verriegelung Oben |- align="right" | Hutschienen Gehäuse || Axxatronic || [http://www.axxatronic.de/serie-cnmb.html CNMB-4-KIT-CON] || Conrad || [http://www.conrad.at/ce/de/product/531443/Axxatronic-Hutschienen-Gehaeuse-CNMB-4-KIT-CON-Polycarbonat-L-x-B-x-H-90-x-710-x-58-mm 531443 - 62] || [http://www.axxatronic.de/serie-cnmb.html Link] || (L x B x H) 90 x 71.0 x 58 mm |} ==Die Software== ===TFTP-Bootloader & Fuses=== Menuconfig: │ │ Load a Default Configuration ---> │ │ [*] Ethernet Bootloader │ │ Network ---> │ │ [*] Ethernet (ENC28J60) support ---> │ │ Etherrape IP address: "192.168.12.220" │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ Applications ---> │ │ [*] TFTP support ---> │ │ Bootloader configuration ---> │ │ [*] TFTP-o-matic │ │ --- TFTP-o-matic configuration │ │ TFTP IP address: "192.168.12.120" │ │ TFTP image to load: "ethersex.bin" make clean && make --> ethersex.hex =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 6064/65536 bytes (9.25%) [==----------------------------] Program (.text + .data) : 6064 bytes Data (.data + .bss) : 826 bytes =================================== sudo avrdude -cusbasp -pm644 -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m sudo avrdude -cusbasp -pm644 -U flash:w:ethersex.hex sudo avrdude -cusbasp -pm644 -U lock:w:0x0F:m Achtung bei den SMD Typen vom mega644, ich habe mega644P bekommen, wobei ich jetzt nicht weiß ob die SMD immer P Typen sind. Egal das Problem ist man sollte avrdude genau lesen und auch "-p m644p" anhängen da der P Type eine andere Signatur aufweist. Hat mich ne Stunde gekostet. ;) ==Bilder== ===Testsystem=== <gallery perrow=7> File:1_stella_all_off.jpg File:2_stella_all_on.jpg File:3_mosfets.jpg File:4_schaltung_fet.png </gallery><br> ===Messstation=== <gallery perrow=7> File:IMG_5286.JPG File:IMG_6592.JPG File:IMG_6594.JPG </gallery><br> ==Probleme== 25.1.2011 - ethersex mit m644 und 32khz uhrenquarz.<br> datenblatt mega644 seite 101 - http://www.atmel.com/dyn/resources/prod_documents/doc2593.pdf<br> services/clock/clock.c - zeile 64<br> <obiflix> du könntest https://github.com/ethersex/ethersex/commit/da511f074940423e8e8ef7ee67ca20e6d91f608c rückgängig machen <obiflix> möglicherweise bekommst du dann probleme mit dcf77, falls du das nutzen möchtest, aber einen versuch ist es wert ;) Notiz: Hat funktioniert für den MEGA644<br> Update#1<br> 26.1.2011 - Problem sollte nun behoben sein, Danke an eku! master Erik Kunze * ae3ef98 (2 files in 1 dirs): use timer makros for prescaler 64 (32768Hz/256/64=2Hz) - http://bit.ly/eG2d4c --- DCF muss noch getestet werden adaae1fc8285ca355ccfce04d3716a6781bcb079 855 854 2012-09-24T08:48:38Z Djmaster 255 wikitext text/x-wiki [[File:RJ45Buchse_Pinout.png|400px|thumb|RJ45 Buchse]] [[File:Ethersex det ssr.png|400px|thumb|die Theorie]] ==Person== Nick im IRC: djmaster oder djmaster2<br> Web: http://wiki.senseye.org/ ==Bauteile== Für [http://www.lochraster.org/etherrape/ Etherrape] Module {| | {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%;" |- ! Bauteil !! Hersteller !! HerstellerNr !! Lieferant !! Bestellnummer !! Dokumente !! Sonstiges |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/products/en?q=6605424-1 6605424-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154361/ 615-4361] || [http://www.te.com/catalog/pn/en/6605424-1?RQPN=6605424-1 Link] || Netzwerkbuchse ohne LED, Verriegelung Unten |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/pn/en/5-6605308-1 5-6605308-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154383/ 615-4383] || [http://www.te.com/catalog/pn/en/5-6605308-1?RQPN=5-6605308-1 Link] || Netzwerkbuchse mit LED, Verriegelung Unten |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/products/en?q=6605759-1 6605759-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154399/ 615-4399] || [http://www.te.com/catalog/pn/en/6605759-1?RQPN=6605759-1 Link] || Netzwerkbuchse ohne LED, Verriegelung Oben |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/products/en?q=5-6605758-1 5-6605758-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154412/ 615-4412] || [http://www.te.com/catalog/pn/en/5-6605758-1?RQPN=5-6605758-1 Link] || Netzwerkbuchse mit LED, Verriegelung Oben |- align="right" | Hutschienen Gehäuse || Axxatronic || [http://www.axxatronic.de/serie-cnmb.html CNMB-4-KIT-CON] || Conrad || [http://www.conrad.at/ce/de/product/531443/Axxatronic-Hutschienen-Gehaeuse-CNMB-4-KIT-CON-Polycarbonat-L-x-B-x-H-90-x-710-x-58-mm 531443 - 62] || [http://www.axxatronic.de/serie-cnmb.html Link] || (L x B x H) 90 x 71.0 x 58 mm |} ==Die Software== ===TFTP-Bootloader & Fuses=== Menuconfig: │ │ Load a Default Configuration ---> │ │ [*] Ethernet Bootloader │ │ Network ---> │ │ [*] Ethernet (ENC28J60) support ---> │ │ Etherrape IP address: "192.168.12.220" │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ Applications ---> │ │ [*] TFTP support ---> │ │ Bootloader configuration ---> │ │ [*] TFTP-o-matic │ │ --- TFTP-o-matic configuration │ │ TFTP IP address: "192.168.12.120" │ │ TFTP image to load: "ethersex.bin" make clean && make --> ethersex.hex =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 6064/65536 bytes (9.25%) [==----------------------------] Program (.text + .data) : 6064 bytes Data (.data + .bss) : 826 bytes =================================== sudo avrdude -cusbasp -pm644 -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m sudo avrdude -cusbasp -pm644 -U flash:w:ethersex.hex sudo avrdude -cusbasp -pm644 -U lock:w:0x0F:m Achtung bei den SMD Typen vom mega644, ich habe mega644P bekommen, wobei ich jetzt nicht weiß ob die SMD immer P Typen sind. Egal das Problem ist man sollte avrdude genau lesen und auch "-p m644p" anhängen da der P Type eine andere Signatur aufweist. Hat mich ne Stunde gekostet. ;) ==Bilder== ===Testsystem=== <gallery perrow=7> File:1_stella_all_off.jpg File:2_stella_all_on.jpg File:3_mosfets.jpg File:4_schaltung_fet.png </gallery><br> ===Messstation=== <gallery perrow=7> File:IMG_5286.JPG File:IMG_6592.JPG File:IMG_6594.JPG </gallery><br> ==Probleme== 25.1.2011 - ethersex mit m644 und 32khz uhrenquarz.<br> datenblatt mega644 seite 101 - http://www.atmel.com/dyn/resources/prod_documents/doc2593.pdf<br> services/clock/clock.c - zeile 64<br> <obiflix> du könntest https://github.com/ethersex/ethersex/commit/da511f074940423e8e8ef7ee67ca20e6d91f608c rückgängig machen <obiflix> möglicherweise bekommst du dann probleme mit dcf77, falls du das nutzen möchtest, aber einen versuch ist es wert ;) Notiz: Hat funktioniert für den MEGA644<br> Update#1<br> 26.1.2011 - Problem sollte nun behoben sein, Danke an eku! master Erik Kunze * ae3ef98 (2 files in 1 dirs): use timer makros for prescaler 64 (32768Hz/256/64=2Hz) - http://bit.ly/eG2d4c --- DCF muss noch getestet werden 0ae3f7661c6728e67f4b5da8d81189c38034df55 857 855 2012-09-24T09:04:48Z Djmaster 255 /* Messstation */ wikitext text/x-wiki [[File:RJ45Buchse_Pinout.png|400px|thumb|RJ45 Buchse]] [[File:Ethersex det ssr.png|400px|thumb|die Theorie]] ==Person== Nick im IRC: djmaster oder djmaster2<br> Web: http://wiki.senseye.org/ ==Bauteile== Für [http://www.lochraster.org/etherrape/ Etherrape] Module {| | {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%;" |- ! Bauteil !! Hersteller !! HerstellerNr !! Lieferant !! Bestellnummer !! Dokumente !! Sonstiges |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/products/en?q=6605424-1 6605424-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154361/ 615-4361] || [http://www.te.com/catalog/pn/en/6605424-1?RQPN=6605424-1 Link] || Netzwerkbuchse ohne LED, Verriegelung Unten |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/pn/en/5-6605308-1 5-6605308-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154383/ 615-4383] || [http://www.te.com/catalog/pn/en/5-6605308-1?RQPN=5-6605308-1 Link] || Netzwerkbuchse mit LED, Verriegelung Unten |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/products/en?q=6605759-1 6605759-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154399/ 615-4399] || [http://www.te.com/catalog/pn/en/6605759-1?RQPN=6605759-1 Link] || Netzwerkbuchse ohne LED, Verriegelung Oben |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/products/en?q=5-6605758-1 5-6605758-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154412/ 615-4412] || [http://www.te.com/catalog/pn/en/5-6605758-1?RQPN=5-6605758-1 Link] || Netzwerkbuchse mit LED, Verriegelung Oben |- align="right" | Hutschienen Gehäuse || Axxatronic || [http://www.axxatronic.de/serie-cnmb.html CNMB-4-KIT-CON] || Conrad || [http://www.conrad.at/ce/de/product/531443/Axxatronic-Hutschienen-Gehaeuse-CNMB-4-KIT-CON-Polycarbonat-L-x-B-x-H-90-x-710-x-58-mm 531443 - 62] || [http://www.axxatronic.de/serie-cnmb.html Link] || (L x B x H) 90 x 71.0 x 58 mm |} ==Die Software== ===TFTP-Bootloader & Fuses=== Menuconfig: │ │ Load a Default Configuration ---> │ │ [*] Ethernet Bootloader │ │ Network ---> │ │ [*] Ethernet (ENC28J60) support ---> │ │ Etherrape IP address: "192.168.12.220" │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ Applications ---> │ │ [*] TFTP support ---> │ │ Bootloader configuration ---> │ │ [*] TFTP-o-matic │ │ --- TFTP-o-matic configuration │ │ TFTP IP address: "192.168.12.120" │ │ TFTP image to load: "ethersex.bin" make clean && make --> ethersex.hex =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 6064/65536 bytes (9.25%) [==----------------------------] Program (.text + .data) : 6064 bytes Data (.data + .bss) : 826 bytes =================================== sudo avrdude -cusbasp -pm644 -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m sudo avrdude -cusbasp -pm644 -U flash:w:ethersex.hex sudo avrdude -cusbasp -pm644 -U lock:w:0x0F:m Achtung bei den SMD Typen vom mega644, ich habe mega644P bekommen, wobei ich jetzt nicht weiß ob die SMD immer P Typen sind. Egal das Problem ist man sollte avrdude genau lesen und auch "-p m644p" anhängen da der P Type eine andere Signatur aufweist. Hat mich ne Stunde gekostet. ;) ==Bilder== ===Testsystem=== <gallery perrow=7> File:1_stella_all_off.jpg File:2_stella_all_on.jpg File:3_mosfets.jpg File:4_schaltung_fet.png </gallery><br> ===Messstation=== <gallery perrow=7> File:IMG_5286.JPG File:IMG_6592.JPG File:IMG_6594.JPG File:S0-zaehler_img.JPG </gallery><br> ==Probleme== 25.1.2011 - ethersex mit m644 und 32khz uhrenquarz.<br> datenblatt mega644 seite 101 - http://www.atmel.com/dyn/resources/prod_documents/doc2593.pdf<br> services/clock/clock.c - zeile 64<br> <obiflix> du könntest https://github.com/ethersex/ethersex/commit/da511f074940423e8e8ef7ee67ca20e6d91f608c rückgängig machen <obiflix> möglicherweise bekommst du dann probleme mit dcf77, falls du das nutzen möchtest, aber einen versuch ist es wert ;) Notiz: Hat funktioniert für den MEGA644<br> Update#1<br> 26.1.2011 - Problem sollte nun behoben sein, Danke an eku! master Erik Kunze * ae3ef98 (2 files in 1 dirs): use timer makros for prescaler 64 (32768Hz/256/64=2Hz) - http://bit.ly/eG2d4c --- DCF muss noch getestet werden 93bf5a34f47003c078020596672f40f54da14b76 858 857 2012-09-24T13:17:42Z Djmaster 255 wikitext text/x-wiki [[File:RJ45Buchse_Pinout.png|400px|thumb|RJ45 Buchse]] [[File:Ethersex det ssr.png|400px|thumb|die Theorie]] ==Person== Nick im IRC: djmaster oder djmaster2<br> Web: http://wiki.senseye.org/ ==Bauteile== Für [http://www.lochraster.org/etherrape/ Etherrape] Module {| | {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%;" |- ! Bauteil !! Hersteller !! HerstellerNr !! Lieferant !! Bestellnummer !! Dokumente !! Sonstiges |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/products/en?q=6605424-1 6605424-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154361/ 615-4361] || [http://www.te.com/catalog/pn/en/6605424-1?RQPN=6605424-1 Link] || Netzwerkbuchse ohne LED, Verriegelung Unten |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/pn/en/5-6605308-1 5-6605308-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154383/ 615-4383] || [http://www.te.com/catalog/pn/en/5-6605308-1?RQPN=5-6605308-1 Link] || Netzwerkbuchse mit LED, Verriegelung Unten |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/products/en?q=6605759-1 6605759-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154399/ 615-4399] || [http://www.te.com/catalog/pn/en/6605759-1?RQPN=6605759-1 Link] || Netzwerkbuchse ohne LED, Verriegelung Oben |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/products/en?q=5-6605758-1 5-6605758-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154412/ 615-4412] || [http://www.te.com/catalog/pn/en/5-6605758-1?RQPN=5-6605758-1 Link] || Netzwerkbuchse mit LED, Verriegelung Oben |- align="right" | Hutschienen Gehäuse || Axxatronic || [http://www.axxatronic.de/serie-cnmb.html CNMB-4-KIT-CON] || Conrad || [http://www.conrad.at/ce/de/product/531443/Axxatronic-Hutschienen-Gehaeuse-CNMB-4-KIT-CON-Polycarbonat-L-x-B-x-H-90-x-710-x-58-mm 531443 - 62] || [http://www.axxatronic.de/serie-cnmb.html Link] || (L x B x H) 90 x 71.0 x 58 mm |- align="right" | DS2450 || Maxim || [http://www.maximintegrated.com/datasheet/index.mvp/id/2921 DS2450] || RS-Components || [http://at.rs-online.com/web/p/products/07327557/ 732-7557] || [http://datasheets.maximintegrated.com/en/ds/DS2450.pdf Link] || Onewire quad AD Converter |- align="right" | HIH4000-001 || Honeywell || [http://sensing.honeywell.com/product%20page?pr_id=53944 HIH4000-001] || RS-Components || [http://at.rs-online.com/web/p/products/05283171/ 528-3171] || [http://sensing.honeywell.com/product%20page?pr_id=53944 Link] || Luftfeuchte Sensor von Honeywell |- align="right" | MPXH6115AC6U || Freescale || xx || RS-Components || [http://at.rs-online.com/web/p/products/07176536/ 717-6536] || [http://www.freescale.com/files/sensors/doc/data_sheet/MPXA6115A.pdf Link] || Luftdruck Sensor von Freescale |} ==Die Software== ===TFTP-Bootloader & Fuses=== Menuconfig: │ │ Load a Default Configuration ---> │ │ [*] Ethernet Bootloader │ │ Network ---> │ │ [*] Ethernet (ENC28J60) support ---> │ │ Etherrape IP address: "192.168.12.220" │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ Applications ---> │ │ [*] TFTP support ---> │ │ Bootloader configuration ---> │ │ [*] TFTP-o-matic │ │ --- TFTP-o-matic configuration │ │ TFTP IP address: "192.168.12.120" │ │ TFTP image to load: "ethersex.bin" make clean && make --> ethersex.hex =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 6064/65536 bytes (9.25%) [==----------------------------] Program (.text + .data) : 6064 bytes Data (.data + .bss) : 826 bytes =================================== sudo avrdude -cusbasp -pm644 -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m sudo avrdude -cusbasp -pm644 -U flash:w:ethersex.hex sudo avrdude -cusbasp -pm644 -U lock:w:0x0F:m Achtung bei den SMD Typen vom mega644, ich habe mega644P bekommen, wobei ich jetzt nicht weiß ob die SMD immer P Typen sind. Egal das Problem ist man sollte avrdude genau lesen und auch "-p m644p" anhängen da der P Type eine andere Signatur aufweist. Hat mich ne Stunde gekostet. ;) ==Bilder== ===Testsystem=== <gallery perrow=7> File:1_stella_all_off.jpg File:2_stella_all_on.jpg File:3_mosfets.jpg File:4_schaltung_fet.png </gallery><br> ===Messstation=== <gallery perrow=7> File:IMG_5286.JPG File:IMG_6592.JPG File:IMG_6594.JPG File:S0-zaehler_img.JPG </gallery><br> ==Probleme== 25.1.2011 - ethersex mit m644 und 32khz uhrenquarz.<br> datenblatt mega644 seite 101 - http://www.atmel.com/dyn/resources/prod_documents/doc2593.pdf<br> services/clock/clock.c - zeile 64<br> <obiflix> du könntest https://github.com/ethersex/ethersex/commit/da511f074940423e8e8ef7ee67ca20e6d91f608c rückgängig machen <obiflix> möglicherweise bekommst du dann probleme mit dcf77, falls du das nutzen möchtest, aber einen versuch ist es wert ;) Notiz: Hat funktioniert für den MEGA644<br> Update#1<br> 26.1.2011 - Problem sollte nun behoben sein, Danke an eku! master Erik Kunze * ae3ef98 (2 files in 1 dirs): use timer makros for prescaler 64 (32768Hz/256/64=2Hz) - http://bit.ly/eG2d4c --- DCF muss noch getestet werden 18a59f31e660a11cfc0332298679582e3b9f7d4e 861 858 2012-09-26T05:46:56Z Djmaster 255 wikitext text/x-wiki [[File:RJ45Buchse_Pinout.png|400px|thumb|RJ45 Buchse]] ==Person== Nick im IRC: djmaster oder djmaster2<br> Web: http://wiki.senseye.org/ ==Bauteile== Für [http://www.lochraster.org/etherrape/ Etherrape] Module {| | {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%;" |- ! Bauteil !! Hersteller !! HerstellerNr !! Lieferant !! Bestellnummer !! Dokumente !! Sonstiges |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/products/en?q=6605424-1 6605424-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154361/ 615-4361] || [http://www.te.com/catalog/pn/en/6605424-1?RQPN=6605424-1 Link] || Netzwerkbuchse ohne LED, Verriegelung Unten |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/pn/en/5-6605308-1 5-6605308-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154383/ 615-4383] || [http://www.te.com/catalog/pn/en/5-6605308-1?RQPN=5-6605308-1 Link] || Netzwerkbuchse mit LED, Verriegelung Unten |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/products/en?q=6605759-1 6605759-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154399/ 615-4399] || [http://www.te.com/catalog/pn/en/6605759-1?RQPN=6605759-1 Link] || Netzwerkbuchse ohne LED, Verriegelung Oben |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/products/en?q=5-6605758-1 5-6605758-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154412/ 615-4412] || [http://www.te.com/catalog/pn/en/5-6605758-1?RQPN=5-6605758-1 Link] || Netzwerkbuchse mit LED, Verriegelung Oben |- align="right" | Hutschienen Gehäuse || Axxatronic || [http://www.axxatronic.de/serie-cnmb.html CNMB-4-KIT-CON] || Conrad || [http://www.conrad.at/ce/de/product/531443/Axxatronic-Hutschienen-Gehaeuse-CNMB-4-KIT-CON-Polycarbonat-L-x-B-x-H-90-x-710-x-58-mm 531443 - 62] || [http://www.axxatronic.de/serie-cnmb.html Link] || (L x B x H) 90 x 71.0 x 58 mm |- align="right" | DS2450 || Maxim || [http://www.maximintegrated.com/datasheet/index.mvp/id/2921 DS2450] || RS-Components || [http://at.rs-online.com/web/p/products/07327557/ 732-7557] || [http://datasheets.maximintegrated.com/en/ds/DS2450.pdf Link] || Onewire quad AD Converter |- align="right" | HIH4000-001 || Honeywell || [http://sensing.honeywell.com/product%20page?pr_id=53944 HIH4000-001] || RS-Components || [http://at.rs-online.com/web/p/products/05283171/ 528-3171] || [http://sensing.honeywell.com/product%20page?pr_id=53944 Link] || Luftfeuchte Sensor von Honeywell |- align="right" | MPXH6115AC6U || Freescale || xx || RS-Components || [http://at.rs-online.com/web/p/products/07176536/ 717-6536] || [http://www.freescale.com/files/sensors/doc/data_sheet/MPXA6115A.pdf Link] || Luftdruck Sensor von Freescale |} ==Die Software== [[File:Ethersex det ssr.png|400px|thumb|die Theorie]] [[File:Hausbus v1.JPG|400px|thumb|die Praxis]] ===TFTP-Bootloader & Fuses=== Menuconfig: │ │ Load a Default Configuration ---> │ │ [*] Ethernet Bootloader │ │ Network ---> │ │ [*] Ethernet (ENC28J60) support ---> │ │ Etherrape IP address: "192.168.12.220" │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ Applications ---> │ │ [*] TFTP support ---> │ │ Bootloader configuration ---> │ │ [*] TFTP-o-matic │ │ --- TFTP-o-matic configuration │ │ TFTP IP address: "192.168.12.120" │ │ TFTP image to load: "ethersex.bin" make clean && make --> ethersex.hex =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 6064/65536 bytes (9.25%) [==----------------------------] Program (.text + .data) : 6064 bytes Data (.data + .bss) : 826 bytes =================================== sudo avrdude -cusbasp -pm644 -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m sudo avrdude -cusbasp -pm644 -U flash:w:ethersex.hex sudo avrdude -cusbasp -pm644 -U lock:w:0x0F:m Achtung bei den SMD Typen vom mega644, ich habe mega644P bekommen, wobei ich jetzt nicht weiß ob die SMD immer P Typen sind. Egal das Problem ist man sollte avrdude genau lesen und auch "-p m644p" anhängen da der P Type eine andere Signatur aufweist. Hat mich ne Stunde gekostet. ;) ==Bilder== ===Testsystem=== <gallery perrow=7> File:1_stella_all_off.jpg File:2_stella_all_on.jpg File:3_mosfets.jpg File:4_schaltung_fet.png File:IMG_5286.JPG File:IMG_6592.JPG File:IMG_6594.JPG File:S0-zaehler_img.JPG File:Esex sensor1.JPG </gallery><br> ==Probleme== 25.1.2011 - ethersex mit m644 und 32khz uhrenquarz.<br> datenblatt mega644 seite 101 - http://www.atmel.com/dyn/resources/prod_documents/doc2593.pdf<br> services/clock/clock.c - zeile 64<br> <obiflix> du könntest https://github.com/ethersex/ethersex/commit/da511f074940423e8e8ef7ee67ca20e6d91f608c rückgängig machen <obiflix> möglicherweise bekommst du dann probleme mit dcf77, falls du das nutzen möchtest, aber einen versuch ist es wert ;) Notiz: Hat funktioniert für den MEGA644<br> Update#1<br> 26.1.2011 - Problem sollte nun behoben sein, Danke an eku! master Erik Kunze * ae3ef98 (2 files in 1 dirs): use timer makros for prescaler 64 (32768Hz/256/64=2Hz) - http://bit.ly/eG2d4c --- DCF muss noch getestet werden dfc6be5152dfb3a9d638576a6a320d294e68fee7 6 330 850 2012-09-24T08:18:56Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 331 853 2012-09-24T08:47:05Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 332 856 2012-09-24T08:55:18Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 333 859 2012-09-26T05:42:17Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 334 860 2012-09-26T05:44:59Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 30 862 335 2012-09-30T09:28:27Z GooPie4o 265 /* Steuern von Stella/Pins durch IR-Zeichen */ wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR Receivers->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP ist eine Portierung des [http://www.mikrocontroller.net/articles/IRMP Infrarot-Multiprotokoll-Decoders] nach [[Ethersex]]. == Anschluss == Der Empfang der IR-Signale erfolgt durch einen Empfänger vom Typ TSOP1736 (oder ähnlich). Dieser kann an einem beliebigen Pin angeschlossen werden. Die Abfrage des Pins und die Dekodierung des IR-Protokolls erfolgt in einer ISR, die einen 8-Bit-Timer des ATMEGAs belegt. Beim Senden wird das Signal mit der Trägerfrequenz des jeweiligen IR-Protokolls über [[PWM_(Deutsch)|PWM]] moduliert. Dazu wird ein weiterer 8-Bit Timer des ATMEGAs (OC0/OC2) belegt. Auf dem '''[[Etherape_(Deutsch)|Etherrape]]'''-Board übernimmt ein [[NE555_(Deutsch)|NE555]] diese Funktion, d.h. die Option ''Use external modulator for sender'' ist zu aktivieren. Man spart einen Timer des [[AVR_(Deutsch)|AVR]] und ist auf eine Trägerfrequenz festgelegt. Beispiel für einen ATMega32 aus: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Bedeutung: * IRMP_RX - Pin an dem der IR-Empfänger angeschlossen ist * IRMP_USE_TIMER2 - benutze Timer2 für den Empfang, Timer0 für das Senden (undef = umgekehrt) * IRMP_RX_LOW_ACTIVE - der IR-Empfänger ist Low-Aktiv (undef = High-aktiv) * IRMP_RX_LED_LOW_ACTIVE - die Kontroll-LED des Empfängers ist gegen USS geschaltet (undef = gegen GND geschaltet) * IRMP_TX - Pin an dem der IR-Sender angschlossen ist (=Ausgang des Timer0 oder Timer2, vgl. IRMP_USE_TIMER2)<br>'''Achtung: 0A bzw 2A bei MCU mit A/B Kanal''' * IRMP_TX_LED_LOW_ACTIVE - die Kontroll-LED des Senders ist gegen USS geschaltet (undef = gegen GND geschaltet) == Konfiguration == Jedes unterstützte IR-Protokoll "verbrät" Speicher an Code. Deshalb sollte man nur die benötigten Protokolle auswählen. Eine detailierte Übersicht über die Protokolle gibt der [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail Artikel im Mikrocontroller Forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ --- Debugging Flags │ │ [ ] IRMP Debug IRMP dekodiert auch das RC5-Protokoll, so dass der separat in [[Ethersex_(Deutsch)|Ethersex]] enthaltene [[RC5_(Deutsch)|RC5]]-Dekoder nicht länger benötigt wird. == [[ECMD_(Deutsch)|ECMD]] == IRMP implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle zum Auslesen empfangener und dekodierter IR-Kommandos und zum Senden von IR-Kommandos. Siehe [[ECMD_Reference|ECMD Referenz]]. == [[Control6_(Deutsch)|Control6]] == === Ausgabe empfangener IR-Zeichen via [[SYSLOG_(Deutsch)|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> Mit IRMP_READ wird auf empfangenen IR-Code geprüft und dieser in die Variablen IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND und IRMP_FLAGS gespeichert. Rückgabewerte größer Null signalisieren die Gültigkeit der Variablen. Bei IRMP_FLAGS=1 handelt es sich um eine Wiederholung. === Steuern von [[StellaLight_(Deutsch)|Stella]]/Pins durch IR-Zeichen === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> Das Script schaltet den Stella Channel 0 auf 255 oder auf 0, die Fernbedienung ist hier eine Denon (Protocol 8). Mit ''include'' wurde dem Script der Zugriff auf die Stellasourcen gestattet.<br> Statt ''"stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255);"'' kann auch ''"PIN_SET(LED)"'' und ''"PIN_CLEAR(LED)"'' verwendet werden ([[Named_PIN_(Deutsch)|Named PIN]]). === Senden von IR-Zeichen === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 * no tx support yet dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON * no tx support yet IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Kommando 5678 an Gerät 1234 wird mit einer Wiederholung im NEC-Protokoll gesendet. e2168c931e0877b0c2287a7ccccd30a9bf501d8a 0 280 863 693 2012-11-11T00:29:08Z Schronk 341 /* Datenblätter */ wikitext text/x-wiki {{i18n|Flashing}} = Flash AVR Net-IO with "ATMEL Evaluations-Board" made by Pollin= As a beginner it's difficult to understand everything in terms of flashing. And it's also difficult to find all information. == What's needed? == * AVR Net-IO * ATMEL Evaluation-Board * a 1 on 1 Cable for the [[ISP]]-Port (10-pin Connector). === Other ISP Programmers === If you have a ISP-Programmer with 6-pin port you can create an adaptor. You can see the pin configuration in figure 4-1 at page 5 [http://www.atmel.com/dyn/resources/prod_documents/doc2521.pdf AVR042: AVR Hardware Design Considerations]. Warning: Pin 4 of the 10-pin connector is not used on the Net-IO. GND has to be connected to one of the other Pins (6, 8 or 10) == Flashing with Linux == *Connect the 10-pin Cable to the ISP-Connector. *Plug in the power adaptor of the AVR Net-IO. *If everything is connected right, the yellow LED of the Evaluation-Board is shining. After compiling the ethersex.hex you can flash it with avrdude. The following commands depend on your ISP-Programmer. This example is for a serial connection: avrdude -v -p m32 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex For a USB-ISP-Programmer this command should be used: avrdude -v -p m32 -c stk500v2 -P /dev/ttyACM0 -U flash:w:ethersex.hex For a parallel ISP-Cable: avrdude -p m32 -e -c stk200 -U flash:w:ethersex.hex After flashing remove the ISP-Cable and interrupt the power connection for a short time to reboot the board. * -p m32: ATMega32; -p m644: ATMega644 * -v: display debug messages * -c ponyser: the way avrdude speaks with the Evaluation Board; -c stkk500v2 for the Atmel board * -P /dev/tty.serial the serial port your programmer is connected to; -P COM1 for windows machines * -U the command you want to execute. In our case we want to flash: -U flash:w:ethersex.hex In some cases you have to set the FUSE Bits, which is possible with this command: * -U lfuse:w:0xCF:m -U hfuse:w:0xDC:m To get the correct FUSE-Settings you should visit http://www.engbedded.com/fusecalc/ Parameters for MyAVR mySmartusb light (the -e is important): avrdude -p m32 -e -c stk500v2 -P /dev/ttyUSB0 -U flash:w:ethersex.hex == Replace ATMega32 with an ATMega644, ATMega644p or ATMega1284p == ATMega644, ATMega644p and ATMega1284p have got a bigger flash then the ATMega32. This gives the possibility to add more modules to your Image. === Swapping the Microcontroller === * Disconnect power and ISP-Connector. * Remove the old processor from your board. * Insert the new processor while the slot is at the same position as in the socket. === Setting the FUSE-Bits === * Reconnect the ISP and the power. * Set the FUSE-Bits. * '''Important: ''' in the condition as supplied the 644 is programmed to 8 MHz internal RC-Oscillator '''and''' the clock is divided by 8 -> 1 MHz clock speed. If an external Quarz is used, the Bit CKDIV8 has to be set to 0. * (taken from dinus) The ATMega has a clock speed of 1 MHz, no JTAG. avrdude -p m644 -c ponyser -P /dev/ttyS0 -U lfuse:w:0xE7:m -U hfuse:w:0xDC:m -U efuse:w:0xFF:m Fuse-Bits from "DiDi". JTAG is turned ON. * -U lfuse:w:0xf7:m -U hfuse:w:0x99:m -U efuse:w:0xfc:m Fuse-Bits from "loddel". JTAG is turned OFF. * -U lfuse:w:0xf7:m -U hfuse:w:0xd9:m -U efuse:w:0xff:m * -U lfuse:w:0xe7:m -U hfuse:w:0xd9:m -U efuse:w:0xff:m Fuse-Bits from "Gregor". "The 644 runs at 16 MHz Quartz and is not divided by 8." JTAG is turned ON. * -U lfuse:w:0xef:m -U hfuse:w:0x99:m -U efuse:w:0xff:m === flash Ethersex === * change Config of Ethersex (make menuconfig) to ATMega644 and build (make) * flash with avrdude -p m644 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex -v === Differentes bettween ATMega32, ATMega644, ATMega644p and ATMega1284p=== {| border=1 cellspacing=0 padding=4 class=wikitable " ! !! ATMega32 !! ATMega644 !! ATMega644p !! ATMega1284p |- | Housing || DIL-40 || DIL-40 || DIL-40 || DIL-40 |- | MHz || max. 16 || max. 20 || max. 20 || max. 20 |- | Flash || 32 KB || 64 KB || 64 KB || 128 KB |- | EEProm || 1 KB || 2 KB || 2 KB || 4 KB |- | RAM || 2 KB || 4 KB || 4 KB || 16 KB |- | I/O || 32 || 32 || 32 || 32 |- | PWM || 4 || 6 || 6 || 6 |- | ext. INT || 3 || 32 || 32 || 32 |- | Ser-Port || 1 || 1 || 2 || 2 |} ====Datasheets==== * [http://www.atmel.com/Images/doc2503.pdf AtMega32] * [http://www.atmel.com/Images/doc2593.pdf ATMega644] * [http://www.atmel.com/images/doc8011.pdf ATMega644p] * [http://www.atmel.com/dyn/resources/prod_documents/8059S.pdf ATMega1284p] == Flashing with Windows == There a two main possibilities: #Flash with avrdude #Flash with AVR Studio If you don't want to install one of those programs, there is a [[Live CD]] to use. ===Flashing with avrdude=== The flashing with avrdude is just like in Linux. You can get the Windows-Binary as a part of [http://sourceforge.net/projects/winavr/ WinAVR] In the command line you have to adjust the name of the serial Ports. (COMx instead of /dev/ttyxx) avrdude -v -p m32 -c ponyser -P com3 -U flash:w:ethersex.hex If the programmer is connected via USB you need: * for real USB-Programmers: libusb0.dll (Part of WinAVR) * USB-to-Serial Converter a matching Driver: [http://www.ftdichip.com/Drivers/VCP.htm] ===Flashing with AVR Studio=== [[AVR Studio]] from Atmel offers a GUI to Controll the ISPs. AVR Studio also brings USB-Drivers for the Programmers with it, which can be installed together with it. For USB-to-Serial converters you need a matching Driver: [http://www.ftdichip.com/Drivers/VCP.htm] == Live-CD == You don't have to worry about your System if you use a Live CD to flash your build. * Download and burn the CD: [http://www.ethersex.de/index.php?title=Live_CD] * Get the libncurses5 Package: apt-get install libncurses5-dev * Update and install the software for ethersex just like described here: [http://ethersex.de/index.php/Quick_Start_Guide/Preparation] * If menuconfig fails try this command: apt-get install dialog * Flash like described in the "Flashing with Linux" section is described. ff408ff16b9f3e347f40dc61587ffb8e8bb513c7 0 279 864 692 2012-11-11T00:30:35Z Schronk 341 /* Datenblätter */ wikitext text/x-wiki {{i18n|Flashing}} = AVR Net-IO mit dem ATMEL Evaluations-Board von Pollin flashen= Als Einsteiger hat man es immer wieder schwer alle Information zu finden. Ich habe lange gesucht bis ich das mit dem Flashen kapiert habe. == Benötigt wird: == * AVR Net-IO * ATMEL Evaluations-Board * ein 1:1 Kabel für den [[ISP]]-Port (10-poliger Pfostenstecker). === Andere ISP-Programmer === Wer über einen ISP-Programmer mit 6-poligem Ausgang verfügt, kann sich ein Adapterkabel bauen. Zu den Pinbelegungen siehe Figure 4-1 auf Seite 5 von [http://www.atmel.com/dyn/resources/prod_documents/doc2521.pdf AVR042: AVR Hardware Design Considerations]. Achtung, Pin 4 des 10-poligen Steckers ist auf dem AVR Net-IO nicht belegt! GND muss daher an einen der anderen Pins (6, 8 oder 10) angeschlossen werden. == Flashen unter Linux == Das 10-polige Kabel in die ISP-Buchse stecken. Nun das AVR Net-IO Board mit Strom versorgen. Wenn das ISP-Kabel richtig gesteckt ist, leuchtet auf dem Evalutions-Board die (gelbe) LED Nach dem Erzeugen der [[:Kategorie:StepByStep#Firmware_kompilieren|ethersex.hex]] kann man mit avrdude das Ganze flashen. Das nachfolgende Kommando ist bei einigen Parametern vom ISP-Programmer abhängig. Das nachfolgende Beispiel gilt für einen ISP-Programmer der über die serielle Schnittstelle arbeitet: avrdude -v -p m32 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex Für eine USB-ISP-Programmer wäre statt dessen der folgende Befehl zu verwenden: avrdude -v -p m32 -c stk500v2 -P /dev/ttyACM0 -U flash:w:ethersex.hex Für ein paralleles ISP-Kabel: avrdude -p m32 -e -c stk200 -U flash:w:ethersex.hex Nach dem Flashen das ISP-Kabel entfernen und kurz die Stromversorgung unterbrechen um das Board zu rebooten. * -p m32 steht für den ATMega32; -p m644 wäre der ATMega644 * -v erweiterte Ausgaben * -c ponyser ist das Verfahren wie das Evalutions-Board die Daten flasht * -P ist die Serielle Schnittstelle an dem das Evalutions-Board angeschlossen ist (bei USB /dev/ttyUSB0) * -U was man machen möchte. In unserem Fall wollen wir das File ethersex.hex flashen (-U flash:w:ethersex.hex) Es kann sein das man für den ATMega32 die FUSE Bits setzen muss. avrdude -p m32 -c ponyser -P /dev/ttyS0 -U lfuse:w:0xCF:m -U hfuse:w:0xDC:m Um die korrekte Fuse-Einstellung rauszufinden, ist es sinnvoll http://www.engbedded.com/fusecalc/ zu benutzen. Die Parameter für MyAVR mySmartusb light (Insbesondere das -e war nötig): avrdude -p m32 -e -c stk500v2 -P /dev/ttyUSB0 -U flash:w:ethersex.hex == Umbau von einem ATMega32 auf den ATMega644 / ATMega644p == Der Vorteil von ATMega644 und ATMega644p ist vor allem der doppelt so große Speicher gegenüber dem serienmäßigen ATMega32. === Mikrocontroller tauschen === * Stromversorgung abschalten und ISP-Stecker abziehen. * Den ATMega32 aus seinem Sockel auf dem AVR Net-IO ziehen. * Den ATMega644 oder ATMega644p einbauen. (ACHTUNG: Kerbe im Sockel muss mit Kerbe in der CPU übereinstimmen) === Fuse-Bits setzen === * ISP wieder einstecken und Stromversorgung einschalten. * Fuse-Bits setzen * '''Wichtig:''' im Auslieferungszustand ist der ATMega644 programmiert auf 8MHz interner RC-Oszillator '''und''' der Takt wird durch 8 geteilt; also 1MHz Takt. Wenn ein externer Quarz verwendet wir, muss das Bit CKDIV8 (Takt geteilt durch 8) auf null gesetzt werden. * (Übernommen von dinus) Der ATMega wird dabei mit 1Mhz getaktet, kein JTAG. avrdude -p m644 -c ponyser -P /dev/ttyS0 -U lfuse:w:0xE7:m -U hfuse:w:0xDC:m -U efuse:w:0xFF:m * bzw. avrdude -p m644p -c ponyser -P /dev/ttyS0 -U lfuse:w:0xE7:m -U hfuse:w:0xDC:m -U efuse:w:0xFF:m Fuse-Bits wie sie "DiDi" einsetzt. Der JTAG ist eingeschaltet. * -U lfuse:w:0xf7:m -U hfuse:w:0x99:m -U efuse:w:0xfc:m Fuse-Bits wie "loddel" sie einsetzt. Der JTAG ist ausgeschaltet. * -U lfuse:w:0xf7:m -U hfuse:w:0xd9:m -U efuse:w:0xff:m * -U lfuse:w:0xe7:m -U hfuse:w:0xd9:m -U efuse:w:0xff:m Fuse-Bits wie "gregor" sie einsetzt. "Damit läuft der 644 auf 16MHz Quarz und der Takt wird nicht durch 8 geteilt." Der JTAG ist eingeschaltet. * -U lfuse:w:0xef:m -U hfuse:w:0x99:m -U efuse:w:0xff:m === Ethersex reinflashen=== * in der Config von Ethersex (make menuconfig) von ATmega32 auf ATMega644 umstellen * Flashen mit avrdude -p m644 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex -v * bzw. avrdude -p m644p -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex -v === Unterschiede zwischen ATMega32, ATMega644, ATMega644p und ATMega1284p=== {| border=1 cellspacing=0 padding=4 class=wikitable " ! !! ATMega32 !! ATMega644 !! ATMega644p !! ATMega1284p |- | Gehäuse || DIL-40 || DIL-40 || DIL-40 || DIL-40 |- | MHz || max. 16 || max. 20 || max. 20 || max. 20 |- | Flash || 32 KB || 64 KB || 64 KB || 128 KB |- | EEProm || 1 KB || 2 KB || 2 KB || 4 KB |- | RAM || 2 KB || 4 KB || 4 KB || 16 KB |- | I/O || 32 || 32 || 32 || 32 |- | PWM || 4 || 6 || 6 || 6 |- | ext. INT || 3 || 32 || 32 || 32 |- | Ser-Port || 1 || 1 || 2 || 2 |} ====Datenblätter==== * [http://www.atmel.com/Images/doc2503.pdf AtMega32] * [http://www.atmel.com/Images/doc2593.pdf ATMega644] * [http://www.atmel.com/images/doc8011.pdf ATMega644p] * [http://www.atmel.com/dyn/resources/prod_documents/8059S.pdf ATMega1284p] == Flashen unter Windows == Es gibt mindestens zwei Möglichkeiten: #Flashen mit avrdude #Flashen mit AVR Studio Wer keines der beiden Programme auf seine Festplatte legen möchte, weil er sein Windows-System nicht ändern möchte, kann auch die [[Live CD]] verwenden. ===Flashen mit avrdude=== Das Flashen mit avrdude erfolgt prinzipiell genauso wie unter Linux (siehe oben). Ein Windows-Binary von avrdude erhält man am einfachsten als Bestandteil von [http://sourceforge.net/projects/winavr/ WinAVR]. (Ansonsten findet man ein Windows-Binary von avrdude auch auf [http://yuki-lab.jp/hw/avrdude-GUI/index.html dieser japanischen Seite], wo man auch eine GUI für avrdude bekommen kann. Google-Translate hilft den japanischen Text zu verstehen.) In der Kommandozeile muss natürlich die Bezeichnung des seriellen Ports angepasst werden, also "COMx" anstelle von "/dev/ttyS0", z.B. avrdude -v -p m32 -c ponyser -P com3 -U flash:w:ethersex.hex Sofern der Programmer per USB angeschlossen ist, benötigt man * bei echten USB-Programmern die libusb0.dll (bei WinAVR enthalten), * bei Verwendung eines USB-nach-seriell-Adapters mit FTDI-Chip (dieser kann auch manchmal bereits in den Programmer mit USB-Anschluss eingebaut sein!) einen passenden Treiber, siehe http://www.ftdichip.com/Drivers/VCP.htm. ===Flashen mit AVR Studio=== Das [[AVR Studio]] von Atmel bietet eine grafische Oberfläche zur Bedienung von ISPs. Beim AVR Studio werden USB-Treiber für USB-Programmer mitgeliefert, die optional zusammen mit dem AVR Studio installiert werden können. Für USB-nach-seriell-Adapter mit FTDI-Chip benötigt man einen passenden Treiber, siehe http://www.ftdichip.com/Drivers/VCP.htm. === Links zu Erfahrungsberichten === *http://www.saschakimmel.de/2010/02/ethersex-auf-avr-net-io-installieren-mittels-pollin-atmel-evaluationsboard-2-0-und-windows/ , jedoch nicht mit ISP-Kabel sondern mit Umstecken des Controllers. == Live-CD == Diese hat den Vorteil, dass man sein vorhandenes System nicht ändern muss. * http://www.ethersex.de/index.php?title=Live_CD * apt-get install libncurses5-dev * update und installier software fuer ethersex wie beschrieben http://www.ethersex.de/index.php/Download * wenn help in menuconfig nicht geht: apt-get install dialog * weiter wie in "Flashen unter Linux" beschrieben. [[Category:Ethersex]] [[Category:StepByStep]] [[Category:AVR Net-IO]] e30ce74dca196a6f2feffe66c690bee912772968 10 55 865 428 2012-11-11T00:34:49Z Schronk 341 wikitext text/x-wiki <noinclude>{{i18n|Template:Documentation}}</noinclude> {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | style="background-color: #FFFFFF; text-align: center; border-bottom:1px solid #aaaaaa;" | '''Dokumentation''' |- | [[Wiki Guidelines (Deutsch)|Wiki Richtlinien]] ---- * [[:Category:Hardware|Hardware Treiber]] * [[:Category:Protocol|Protokoll Support]] * [[:Category:Application|Dienste und Applikationen]] * [[ECMD Reference|ECMD Befehlssatz]] ---- * [[Flashing|Flashing Ethersex (Deutsch)]] ---- |} 07f8d540ea472b0b7a10b700f7c4e6ee1cbb0eed 867 865 2012-11-11T00:48:18Z Schronk 341 wikitext text/x-wiki <noinclude>{{i18n|Template:Documentation}}</noinclude> {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | style="background-color: #FFFFFF; text-align: center; border-bottom:1px solid #aaaaaa;" | '''Dokumentation''' |- | [[Wiki Guidelines (Deutsch)|Wiki Richtlinien]] ---- * [[:Category:Hardware|Hardware Treiber]] * [[:Category:Protocol|Protokoll Support]] * [[:Category:Application|Dienste und Applikationen]] * [[ECMD Reference|ECMD Befehlssatz]] ---- * [[Flashing (Deutsch)|Ethersex flashen]] ---- [[:Category:Development|'''Für Entwickler''']] * [[Concept of meta (Deutsch)|Entwurf von Meta-Informationen]] * [[Own module (Deutsch)|Eigene Module]] * [[Config.mk (Deutsch)|Config.mk]] * [[Development/ECMD (Deutsch)|ECMD Befehle schreiben]] * [[Configuration of Boards and Pins (Deutsch)|Konfiguration von Boards und Pins]] |} 11aa252c873490e81e0d58b79176b9c4b8bf8cfd 0 209 866 632 2012-11-11T00:46:30Z Schronk 341 /* Examlpe meta section */ wikitext text/x-wiki {{i18n|Concept of meta}} == Intro == With meta information in each module the main program is set up depending on the configuration. At the end there will be a short example of such meta information. If you continue to read, you should understand this concept: [[M4 - very short intro (Deutsch)#divert]] Also have a look at the files explained while reading - that will help. == meta.c / meta_magic.m4 == The creation of this file is mainly controlled by the file "meta_magic.m4". What is in the file meta_magic.m4? === framework for the file meta.c === The framework consists of several divert sections, in which code of the used modules is injected. Only the idea of the injection is explained with the first injection point. The second section starts with "divert(initearly_divert)dnl" and contains the function "ethersex_meta_init", but the final closing brace of the function is missing. So if you define further divert sections with the index "initearly_divert", then it will be in the output before the closing brace and so part of "ethersex_meta_init". Therefore later in in the file some macros are defined - in this case it is named "initearly". This macros and some others are all defined the same way: define(`initearly',`dnl divert(initearly_divert) $1 (); divert(-1)') So if the meta macro initearly(<module-initearly-functionname>) is used, the module initearly function will be called from the function ethersex_meta_init, because the function call will be in the output directly after the section. The closing brace of the function is part of the next section "divert(net_init_divert)". === structure of meta.c === meta.c itself contains several functions, which are called at important points in the firmware: * ethersex_meta_init *: is called in the startup before the pins are initialized * ethersex_meta_startup *: is called before the main loop starts * ethersex_meta_mainloop *: is called in the main loop - injected functions should do only short processings or reset the watchdog by thereselfs ... * periodic_process *: is the last function called in ethersex_meta_mainloop - after all the injected modules function *: does some network and console reading (ECMD support and other) - at the moment I don't know the backgrounds of this operations. *: further operations can be injected here - by use of the "timer" macro see below. * ethersex_meta_exit *: is called when a sigint is detected ... * ethersex_meta_netinit *: is called in network.c in the function network_init - after the initialization of the network stack *: remark: network.c has is own meta section which, is used to include the network functionality. === m4 macros === * header *: define include file for meta.c * initearly *: define a call at the start of ethersex_meta_init * init *: define a normal call in ethersex_meta_init * atexit *: define a call on shutdown - in ethersex_meta_exit * net_init *: define a call in ethersex_meta_netinit * startup *: define a call in ethersex_meta_startup * mainloop *: define a call in ethersex_meta_mainloop *: this call is done unconditional every time ethersex_meta_mainloop is called. After that the watchdog timer is resetted. *: I think, it is only for important fuctions - use timer instead. * timer *: takes two parameters, the first one says in which run of periodic_process function the second paramater will be executed (every nth run). == meta.h / meta_header_magic.m4 == Contains the structures * uip_udp_connection_state and * uip_tcp_conenction state which can be extended with the macros * state_udp * state_tcp If a module wants to save a network relevant state as part of it's functionality, it has to be part of the connection_state structure. Since it is a union, I think, it is neccessary for passing the structure to the network functions. I.e. the module dyndns puts the dyndns connection state structure there. But look into the details by yourself - if you like. === Macro state_header === By use if this macro it is possible to include additional ".h" files into meta.h. Usage: state_header(<path_and_filename>) Expands to #include "<path_and_filename>" == Example meta section == From tanklevel.c -- Ethersex META -- header(services/tanklevel/tanklevel.h) init(tanklevel_init) timer(1, tanklevel_periodic()) * header ** include file for meta.c * init ** call of tanklevel_init() in meta_init * timer ** call of tanklevel_periodic() in every time (1) the main_loop function is called. == Closing == After all this explained I want to mention that some modules are not only in that structured way integrated into the project. There are also direct compiler directives for them in the framework itself ... this looks like needed "hacks". [[Category:Development]] 7b69e11dd8ac0c963df11a7cdae6babec18d5f34 0 154 868 791 2012-11-11T00:49:36Z Schronk 341 /* Protokolle duplizieren */ wikitext text/x-wiki {{i18n|Protokolle duplizieren}} = Protokolle duplizieren = Es kommt immer mal wieder vor, das man das gleiche Protokoll zweimal benötigt. == Lösung 1 == Bei mir war der Fall, das ich ein Net-IO mit einem ATMega 644p ausgestattet habe, der zwei UART besitz. Diese zwei Schnittstellen wollte ich zum auslesen meiner Wechselrichter nutzen. Das Protokoll der Wahl war bei mir sll (serial_line_log) Leider muste ich feststellen, das ich immer nur ein Protokoll auf ein UART binden kann. Da es bist jetzt noch keine gute Idee gibt, wie man so etwas besser lösen kann, hier ein kleiner Trick. Das Protokoll serial_line_log wird einfach dupliziert. Ich habe jedes "seria_" in ein "serialzwei_" gewandelt. * Kopieren des Ordners (cp -a ethersex/protocols/serial_line_log ethersex/protocols/serialzwei_line_log) * alle Dateien im Ordner umbenannt (auser Makefile und config.in) (cd ethersex/protocols/serialzwei_line_log; mv serial_<...>.c serialzwei_<...>.c * mit einem Editor Alle Variabeln und Symbolenamen geändert <code> vim serialzwei_line_log.c :%s/SERIAL_/SERIALZWEI_/g :%s/serial_/serialzwei_/g :%s/sll_/sllzwei_/g </code> * in der serialzwei_line_log_ecmd.c muss noch der ecmd Befehl angepasst werden (ganz am Schluss der META abschnitt) <code> vim serialzwei_line_log_ecmd.c :%s/sll get/sll2 get :%s/sll_/sllzwei_/g </code> * in der protocols/serialzwei_line_log/config.in die Namen anpassen <code> vim config.in :%s/LINE_/LINE2_/g :%s/Line/Line2/g </code> * die ethersex/config.in und das MAKEFILE an die neuen Namen anpassen Zum Schluss müssen noch zwei zentrale Dateien angepasst werden. <code> cd ethersex/ vim Makefile SUBDIRS += protocols/serialzwei_line_log </code> <code> vim config.in source protocols/serialzwei_line_log/config.in </code> Danach sollte <code> make menuconfig </code> Jetzt sollte unter Protokolle das Serial Line Log zweimal vorhanden sein. Anmerkung: Das gleiche Verfahren funktioniert auch mit dem yport-Protokoll. Wenn man z.B. einen ATMega644p besitzt und beide UARTs "gleichzeitig" benutzen will, kann man das yport-Protokoll mit dem hier vorgestellten Verfahren duplizieren. nc <ip> 7970 bzw nc <ip> 7971 liefert dann die Ausgabe der beiden Ports. == Lösung 2 == Speziell für den U(S)ART gibt es eine elegantere Möglichkeit: Die AVR-LIBC unterstützt inzwischen bis zu zwei U(S)ARTs durch verschiedene Makros. In den Dateien core/usart.h und scripts/usart-config.sh finden sich weitere hilfreiche Makros. Man geht wie folgt vor: In config.in läßt man via menuconfig einen U(S)ART auswählen, indem man das Makro usart_choice() benutzt. Außerdem im Spiel sind die Makros get_usart_count und usart_count_used. Als Ergebnis sollten zwei Variable definiert sein: <mymodulename>_USE_USART und <mymodulename>_BAUDRATE, welche für die U(S)ART-Nummer bzw. die Baudrate stehen. Als Beispiel siehe YPort. Im C-Quelltext benötigt man folgende Anweisungen: * #define USE_USART <mymodulename>_USE_USART Die Variable <mymodulename>_USE_USART muß in config.in auf eine Zahl 0 oder 1 für den ausgewählten U(S)ART gesetzt worden sein. Mit der Zuweisung an USE_USART versorgt man die folgenden universellen Makroaufrufe mit der richtigen U(S)ART-Nummer. * #define BAUD <mymodulensme>_BAUDRATE Gleiches Spiel für die Baudrate * #include "core/usart.h" Hier stehen Makros * generate_usart_init() Dieser Makroaufruf irgendwo im folgenden C-Quelltext generiert eine Routine usart_init() für den ausgewählten U(S)ART, setzt das Datenformat auf 8N1 und die Baudratenvorteiler auf den korrekten Wert. Außerdem werden die RXC und TX Interrupts freigegeben. Andere Datenformate als 8N1 sind (noch) nicht als Makro definiert, und wenn das Freigeben der Interrupts stört, dann sollte man anstelle des generate_usart_init() Makros die Intialisierung aller Register mit Hilfe der unten beschriebenen Makros selbst durchführen. * ISR(usart(USART,_RX_vect)) bzw. ISR(usart(USART,_TX_vect)) etc. So werden die Interrupthandler universell definiert, sie verwenden dann automatisch die richtige U(S)ART-Nummer. * Die U(S)ART-Register sowie die Bit-Definitionen der Register werden ersetzt durch Makroaufrufe usart(<vordererTeil>[,<hintererTeil>]). Das Makro fügt die U(S)ART-Nummer ein. [[Category:Development]] 0e62d847f9a828ceebeaea21a32e7ad1690d9e22 0 189 869 828 2012-12-21T11:12:40Z GooPie4o 265 handle negative temperatures wikitext text/x-wiki {{i18n|Onewire}} {{Module |NAME=Onewire |MENUCONFIG={{I/O}}->Onewire support |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] [[HTTPD]] (optional) [[SNMP]] (optional) |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} Ethersex kann 1-wire Temperatursensoren mit [[ECMD]] auflisten und abfragen. Es wird eine reine Softwareimplementierung des Protokolls benutzt, was keine weiteren Hardware erfordert, als die Temperatursensoren selbst. = Pinning = In der Standardkonfiguration liegt der Datapin des Buses auf PD6 (kann z.B. in der pinning/hardware/netio.m4 oder pinning/hardware/etherrape.m4 geändert werden). Die Definition der Pins erfolgt mit: <source lang=c> ONEWIRE_PORT_RANGE(PXn, PXm) </source> wobei PXn und PNm Pins auf PORTX sind. Jeder Pin zwischen und einschließlich PXn und PXm bildet einen eingenständigen Onewire Bus. Du kannst bis zu acht Busse auf einem PORT definieren (alle Busse müssen auf dem selben PORT liegen!) == Beispiele == Wenn Du nur einen einzigen Bus benötigst, definiere den Bereich wie folgt: '''PORTD: PIN2''' <source lang=c> ONEWIRE_PORT_RANGE(PD2, PD2) </source> Für drei Busse würde das ganze etwa so aussehen: '''PORTD: PIN2, PIN3, PIN4''' <source lang=c> ONEWIRE_PORT_RANGE(PD2, PD4) </source> = Polling Modus = │ │ [*] Onewire Polling │ │ │ │ (375) Time between discoveries in 0.8s steps │ │ │ │ (12) Time between polling in 0.8s steps │ │ │ │ [*] ECMD 1w list with values │ │ │ │ (10) Maximum sensor count │ │ Im Polling-Modus werden die Sensoren im Hintergrund abgefragt, so dass die Werte bei Bedarf direkt zur Verfügung stehen und nicht erst gewandelt bzw. eingelesen werden müssen. Der Intervall zwischen den Discoveries und zwischen den Abfragen der Werte kann getrennt eingestellt werden. Die Option '''ECMD 1w list with values''' bietet die Möglichkeit, die aktuellen Werte bei Aufruf von '''1w list''' mit ausgeben zu lassen. So können darauf folgende '''1w get''' Kommandos entfallen. Da zur Pufferung der Werte, ROM-Codes, etc. RAM-Speicher benötigt wird, muss per '''Maximum sensor count''' angegeben werden, für wie viele Sensoren Speicher reserviert wird. = Benennung von Sensoren = │ │ [*] Onewire naming support │ │ │ │ (10) Maximum sensor count │ │ Um den Sensoren sinnvolle Namen zu geben besteht die Möglichkeit im EEPROM eine entsprechende Zuweisungstabelle anzulegen (ROM-Code -> Name). Die Namen werden bei bei Aufruf von '''1w list''' mit ausgegeben. Dazu gibt es folgende ECMD Kommandos: 1w name list Auflistung der aktuellen Zuweisungen (Spalten: ID, ROM-Code, Name). Die ID bezeichnet die Position in der Zuweisungstabelle und kann u.a. dazu benutzt werden, Sensoren bei SNMP-Abfragen eindeutig zu referenzieren. 1w name set <ID> <ROM-Code> <Name> Erstellt einen entsprechenden Tabelleneintrag. 1w name clear <ID> Löscht die Felder eines Tabelleneintrags. 1w name save Speichert die aktuelle Tabelle im EEPROM = Unterstützte Hardware = Folgende 1-wire Hardware wird momentan durch Ethersex unterstützt: * DS1820 (Temperatursensor) * DS18B20 (Temperatursensor) * DS1822 (Temperatursensor) * DS2502 (EEPROM) * [[Onewire/DS2450 (Deutsch) | DS2450 (4 Kanal ADC)]] = Onewire Befehle = unter Linux als erstes netcat starten (hierbei natürlich die IP ggf modifizieren): netcat 192.168.0.15 2701 danach am prompt: 1w list Gibt eine Liste mit Hexcodes aller angeschlossenen und erkannten Onewire(tm) Sensoren aus. Bei aktiviertem Naming-Support wird (per TAB getrennt) zusätzlich der Name ausgegeben. Außerdem kann mit '''ECMD 1w list with values (ONEWIRE_ECMD_LIST_VALUE_SUPPORT)''' der aktuelle Temperaturwert mit ausgegeben werden. Dies erspart zusätzliche '''1w get''' Aufrufe, setzt allerding Polling-Support vorraus. 1w convert <hexcode> Veranlasst eine Temperaturmessung des addressierten Sensors, oder, wenn das Argument <hexcode> weggelassen wird, aller angeschlossener Sensoren. Im Polling-Modus wird dieses Kommando ignoriert. 1w get <hexcode> Gibt die gemessene Temperatur eines Sensors aus. = Einbindung in die [[HTTPD]]-Weboberfläche = Unter httpd/embed/ow.ht.m4, bzw httpd/embed/Xow.ht.m4 liegt eine Weboberflaeche, die alle Sensoren erkennt und ihre aktuelle Temperatur regelmässig per Ajax abfragt und anzeigt. Im Falle von Xow.ht.m4 wird sogar Graph der Temperatur mittels SVG gemalt. Um die Dateien einzubinden, muss man einfach bei aktiviertem Onewiresupport den Webserver und das Datei Inlining aktivieren. Die Dateien können dann unter ow.ht bzw. unter Xow.ht angezeigt werden. Das Beispiel zeigt die SVG-Version mit Naming-Support: [[File:onewire-svg.png]] = Anschluss AVR-NET-IO = Für das Pollin AVR-NET-IO Board können die Sensoren DS18S20+ , normal Betrieb [[File:netio-1wire_normal.png]] parasitären Modus [[File:netio-1wire.png]] Anmerkung: Wenn man beim Net-IO nicht alle Analogeingänge benötigt, lässt sich der 1-Wire-Bus auch an der Schraubklemme ADC1 ganz gut aufschalten. Vorteil ist, dass man gleich alle passenden Spannungen (GND, +5V) an den beiden nebenliegenden Schraubklemmen hat. Das Pinning muss dann entspechend in der kann in der Datei pinning/hardware/netio.m4 von PD6 auf PA4 geändert werden. Vorteil dieser Konfiguration ist, dass man den DB-25-Verbinder zum Anschluss der Relaisplatine K8IO von Pollin frei hat und den EXT Steckverbinder zum Anschluss eines LCD über ein 4bit-Interface nutzen kann, ohne die Erweiterungsplatine von Pollin zu benötigen. Pinbelegung: [[File:ds18s20-par-pinout.jpg]] = Anschluss Etherrape = Die Schaltung je nach parasitärem oder normalem Betriebsmodus kann aus der NetIO Skizze übernommen werden. Data liegt auf PORTD an Pin 7: PORTD +---+ |x x| |x X| <- Pin 7 |x x |x x| |x x| +---+ Direkt neben PORTD befinden sich 2 Pins mit GND und 5V als Beschriftung. GND kann als GND und 5V als Vcc genutzt werden. = Einbindung in [[Control6]] = Die Sensoren können mit '''ONEWIRE_GET''' einfach abgefragt werden. Die Funktion führt automatisch ein ''convert'' aus, es sind also keine zwei Schritte erforderlich wie bei dem Zugriff über [[ECMD]]. Die Rückgabe erfolgt (analog der Funktion '''KTY_GET''') in Centigrad, also Temperatur * 10. Hier vielleicht ein kleines Beispiel, das die Daten per [[SYSLOG]] ausgibt sobald sich die Temperatur um mehr als ein Grad zur letzten Messung verändert hat. <pre> #include <stdlib.h> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO uint8_t sign = Temperatur<0; div_t res = div(abs(Temperatur),10); SYSLOG("temperature changed %S%d.%d",sign?PSTR("-"):PSTR(""),res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> = Abfrage per [[SNMP]] = Falls Polling-Support aktiviert wurde können die Sensorwerte per SNMP abgefragt werden. Mit Naming-Support stehen auch die Namen per SNMP zur Verfügung und die Index-Nummern sind fix auf die Position in der Namenstabelle festgelegt. Dies ist sehr hilfreich, um bestimmte Sensoren über den SNMP-Index anzusprechen. Es gibt folgende OIDs: * .1.3.6.1.4.1.39967.3.1.<idx> : ROM-Code des Sensors * .1.3.6.1.4.1.39967.3.2.<idx> : Sensor-Name (nur mit Naming-Support) * .1.3.6.1.4.1.39967.3.3.<idx> : Temperaturwert in Centigrad * .1.3.6.1.4.1.39967.3.4.<idx> : 0 = Sensor nicht vorhanden, 1 = Sensor vorhanden Hier ein Beispiel: <pre> # snmpwalk -Osn -c public -v 1 192.168.255.90 1.3.6.1.4.1.39967.3 .1.3.6.1.4.1.39967.3.1.0 = STRING: "1080cff6010800f9" .1.3.6.1.4.1.39967.3.1.1 = STRING: "10c8cff60108002d" .1.3.6.1.4.1.39967.3.1.2 = STRING: "1029f6dc0108002f" .1.3.6.1.4.1.39967.3.1.3 = STRING: "10f2d0f60108001c" .1.3.6.1.4.1.39967.3.1.4 = STRING: "105a17f70108001d" .1.3.6.1.4.1.39967.3.1.5 = STRING: "10b8d8f601080098" .1.3.6.1.4.1.39967.3.1.6 = STRING: "104dedf601080057" .1.3.6.1.4.1.39967.3.1.7 = STRING: "10011af701080027" .1.3.6.1.4.1.39967.3.1.8 = STRING: "0000000000000000" .1.3.6.1.4.1.39967.3.1.9 = STRING: "0000000000000000" .1.3.6.1.4.1.39967.3.2.0 = STRING: "kessel" .1.3.6.1.4.1.39967.3.2.1 = STRING: "warmwasser" .1.3.6.1.4.1.39967.3.2.2 = STRING: "aussen" .1.3.6.1.4.1.39967.3.2.3 = STRING: "speicher" .1.3.6.1.4.1.39967.3.2.4 = STRING: "heizung vl" .1.3.6.1.4.1.39967.3.2.5 = STRING: "heizung rl" .1.3.6.1.4.1.39967.3.2.6 = STRING: "boiler vl" .1.3.6.1.4.1.39967.3.2.7 = STRING: "boiler rl" .1.3.6.1.4.1.39967.3.2.8 = "" .1.3.6.1.4.1.39967.3.2.9 = "" .1.3.6.1.4.1.39967.3.3.0 = INTEGER: 334 .1.3.6.1.4.1.39967.3.3.1 = INTEGER: 467 .1.3.6.1.4.1.39967.3.3.2 = INTEGER: 127 .1.3.6.1.4.1.39967.3.3.3 = INTEGER: 185 .1.3.6.1.4.1.39967.3.3.4 = INTEGER: 318 .1.3.6.1.4.1.39967.3.3.5 = INTEGER: 269 .1.3.6.1.4.1.39967.3.3.6 = INTEGER: 366 .1.3.6.1.4.1.39967.3.3.7 = INTEGER: 291 .1.3.6.1.4.1.39967.3.3.8 = INTEGER: 0 .1.3.6.1.4.1.39967.3.3.9 = INTEGER: 0 .1.3.6.1.4.1.39967.3.4.0 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.1 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.2 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.3 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.4 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.5 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.6 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.7 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.8 = INTEGER: 0 .1.3.6.1.4.1.39967.3.4.9 = INTEGER: 0 </pre> = Codebeispiele = * [[Onewire/Example/PHP (Deutsch) | PHP]] * [[Onewire/Example/Perl (Deutsch) | Perl]] * [[Onewire/Example/Python | Python]] * [[Onewire/Example/Shell | sh/bash]] [[Category:Ethersex]] [[Category:StepByStep]] [[Category:Onewire]] = Bezugsquellen = * Laut Michael Schultz (k1w1) hat er immer DS1820 auf Lager und kann sie sehr günstig weiterverkaufen. Auch Mindermengen. Mail: ethersex [AT] keyb [DOT] de * und natürlich bei den üblichen Verdächtigen: Reichelt, Segor, Conrad 15cc35db7510b5ac0011c9cf8ae7c80fe5f4517f 871 869 2012-12-27T11:56:01Z GooPie4o 265 /* Einbindung in Control6 */ wikitext text/x-wiki {{i18n|Onewire}} {{Module |NAME=Onewire |MENUCONFIG={{I/O}}->Onewire support |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] [[HTTPD]] (optional) [[SNMP]] (optional) |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} Ethersex kann 1-wire Temperatursensoren mit [[ECMD]] auflisten und abfragen. Es wird eine reine Softwareimplementierung des Protokolls benutzt, was keine weiteren Hardware erfordert, als die Temperatursensoren selbst. = Pinning = In der Standardkonfiguration liegt der Datapin des Buses auf PD6 (kann z.B. in der pinning/hardware/netio.m4 oder pinning/hardware/etherrape.m4 geändert werden). Die Definition der Pins erfolgt mit: <source lang=c> ONEWIRE_PORT_RANGE(PXn, PXm) </source> wobei PXn und PNm Pins auf PORTX sind. Jeder Pin zwischen und einschließlich PXn und PXm bildet einen eingenständigen Onewire Bus. Du kannst bis zu acht Busse auf einem PORT definieren (alle Busse müssen auf dem selben PORT liegen!) == Beispiele == Wenn Du nur einen einzigen Bus benötigst, definiere den Bereich wie folgt: '''PORTD: PIN2''' <source lang=c> ONEWIRE_PORT_RANGE(PD2, PD2) </source> Für drei Busse würde das ganze etwa so aussehen: '''PORTD: PIN2, PIN3, PIN4''' <source lang=c> ONEWIRE_PORT_RANGE(PD2, PD4) </source> = Polling Modus = │ │ [*] Onewire Polling │ │ │ │ (375) Time between discoveries in 0.8s steps │ │ │ │ (12) Time between polling in 0.8s steps │ │ │ │ [*] ECMD 1w list with values │ │ │ │ (10) Maximum sensor count │ │ Im Polling-Modus werden die Sensoren im Hintergrund abgefragt, so dass die Werte bei Bedarf direkt zur Verfügung stehen und nicht erst gewandelt bzw. eingelesen werden müssen. Der Intervall zwischen den Discoveries und zwischen den Abfragen der Werte kann getrennt eingestellt werden. Die Option '''ECMD 1w list with values''' bietet die Möglichkeit, die aktuellen Werte bei Aufruf von '''1w list''' mit ausgeben zu lassen. So können darauf folgende '''1w get''' Kommandos entfallen. Da zur Pufferung der Werte, ROM-Codes, etc. RAM-Speicher benötigt wird, muss per '''Maximum sensor count''' angegeben werden, für wie viele Sensoren Speicher reserviert wird. = Benennung von Sensoren = │ │ [*] Onewire naming support │ │ │ │ (10) Maximum sensor count │ │ Um den Sensoren sinnvolle Namen zu geben besteht die Möglichkeit im EEPROM eine entsprechende Zuweisungstabelle anzulegen (ROM-Code -> Name). Die Namen werden bei bei Aufruf von '''1w list''' mit ausgegeben. Dazu gibt es folgende ECMD Kommandos: 1w name list Auflistung der aktuellen Zuweisungen (Spalten: ID, ROM-Code, Name). Die ID bezeichnet die Position in der Zuweisungstabelle und kann u.a. dazu benutzt werden, Sensoren bei SNMP-Abfragen eindeutig zu referenzieren. 1w name set <ID> <ROM-Code> <Name> Erstellt einen entsprechenden Tabelleneintrag. 1w name clear <ID> Löscht die Felder eines Tabelleneintrags. 1w name save Speichert die aktuelle Tabelle im EEPROM = Unterstützte Hardware = Folgende 1-wire Hardware wird momentan durch Ethersex unterstützt: * DS1820 (Temperatursensor) * DS18B20 (Temperatursensor) * DS1822 (Temperatursensor) * DS2502 (EEPROM) * [[Onewire/DS2450 (Deutsch) | DS2450 (4 Kanal ADC)]] = Onewire Befehle = unter Linux als erstes netcat starten (hierbei natürlich die IP ggf modifizieren): netcat 192.168.0.15 2701 danach am prompt: 1w list Gibt eine Liste mit Hexcodes aller angeschlossenen und erkannten Onewire(tm) Sensoren aus. Bei aktiviertem Naming-Support wird (per TAB getrennt) zusätzlich der Name ausgegeben. Außerdem kann mit '''ECMD 1w list with values (ONEWIRE_ECMD_LIST_VALUE_SUPPORT)''' der aktuelle Temperaturwert mit ausgegeben werden. Dies erspart zusätzliche '''1w get''' Aufrufe, setzt allerding Polling-Support vorraus. 1w convert <hexcode> Veranlasst eine Temperaturmessung des addressierten Sensors, oder, wenn das Argument <hexcode> weggelassen wird, aller angeschlossener Sensoren. Im Polling-Modus wird dieses Kommando ignoriert. 1w get <hexcode> Gibt die gemessene Temperatur eines Sensors aus. = Einbindung in die [[HTTPD]]-Weboberfläche = Unter httpd/embed/ow.ht.m4, bzw httpd/embed/Xow.ht.m4 liegt eine Weboberflaeche, die alle Sensoren erkennt und ihre aktuelle Temperatur regelmässig per Ajax abfragt und anzeigt. Im Falle von Xow.ht.m4 wird sogar Graph der Temperatur mittels SVG gemalt. Um die Dateien einzubinden, muss man einfach bei aktiviertem Onewiresupport den Webserver und das Datei Inlining aktivieren. Die Dateien können dann unter ow.ht bzw. unter Xow.ht angezeigt werden. Das Beispiel zeigt die SVG-Version mit Naming-Support: [[File:onewire-svg.png]] = Anschluss AVR-NET-IO = Für das Pollin AVR-NET-IO Board können die Sensoren DS18S20+ , normal Betrieb [[File:netio-1wire_normal.png]] parasitären Modus [[File:netio-1wire.png]] Anmerkung: Wenn man beim Net-IO nicht alle Analogeingänge benötigt, lässt sich der 1-Wire-Bus auch an der Schraubklemme ADC1 ganz gut aufschalten. Vorteil ist, dass man gleich alle passenden Spannungen (GND, +5V) an den beiden nebenliegenden Schraubklemmen hat. Das Pinning muss dann entspechend in der kann in der Datei pinning/hardware/netio.m4 von PD6 auf PA4 geändert werden. Vorteil dieser Konfiguration ist, dass man den DB-25-Verbinder zum Anschluss der Relaisplatine K8IO von Pollin frei hat und den EXT Steckverbinder zum Anschluss eines LCD über ein 4bit-Interface nutzen kann, ohne die Erweiterungsplatine von Pollin zu benötigen. Pinbelegung: [[File:ds18s20-par-pinout.jpg]] = Anschluss Etherrape = Die Schaltung je nach parasitärem oder normalem Betriebsmodus kann aus der NetIO Skizze übernommen werden. Data liegt auf PORTD an Pin 7: PORTD +---+ |x x| |x X| <- Pin 7 |x x |x x| |x x| +---+ Direkt neben PORTD befinden sich 2 Pins mit GND und 5V als Beschriftung. GND kann als GND und 5V als Vcc genutzt werden. = Einbindung in [[Control6]] = Die Sensoren können mit '''ONEWIRE_GET(sensor-id)''' oder '''ONEWIRE_GET_BY_NAME(sensor-name)''' einfach abgefragt werden. Die Funktion führt automatisch ein ''convert'' aus, es sind also keine zwei Schritte erforderlich wie bei dem Zugriff über [[ECMD]]. Die Rückgabe erfolgt (analog der Funktion '''KTY_GET''') in Centigrad, also Temperatur * 10. Hier vielleicht ein kleines Beispiel, das die Daten per [[SYSLOG]] ausgibt sobald sich die Temperatur um mehr als ein Grad zur letzten Messung verändert hat. <pre> #include <stdlib.h> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO uint8_t sign = Temperatur<0; div_t res = div(abs(Temperatur),10); SYSLOG("temperature changed %S%d.%d",sign?PSTR("-"):PSTR(""),res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> = Abfrage per [[SNMP]] = Falls Polling-Support aktiviert wurde können die Sensorwerte per SNMP abgefragt werden. Mit Naming-Support stehen auch die Namen per SNMP zur Verfügung und die Index-Nummern sind fix auf die Position in der Namenstabelle festgelegt. Dies ist sehr hilfreich, um bestimmte Sensoren über den SNMP-Index anzusprechen. Es gibt folgende OIDs: * .1.3.6.1.4.1.39967.3.1.<idx> : ROM-Code des Sensors * .1.3.6.1.4.1.39967.3.2.<idx> : Sensor-Name (nur mit Naming-Support) * .1.3.6.1.4.1.39967.3.3.<idx> : Temperaturwert in Centigrad * .1.3.6.1.4.1.39967.3.4.<idx> : 0 = Sensor nicht vorhanden, 1 = Sensor vorhanden Hier ein Beispiel: <pre> # snmpwalk -Osn -c public -v 1 192.168.255.90 1.3.6.1.4.1.39967.3 .1.3.6.1.4.1.39967.3.1.0 = STRING: "1080cff6010800f9" .1.3.6.1.4.1.39967.3.1.1 = STRING: "10c8cff60108002d" .1.3.6.1.4.1.39967.3.1.2 = STRING: "1029f6dc0108002f" .1.3.6.1.4.1.39967.3.1.3 = STRING: "10f2d0f60108001c" .1.3.6.1.4.1.39967.3.1.4 = STRING: "105a17f70108001d" .1.3.6.1.4.1.39967.3.1.5 = STRING: "10b8d8f601080098" .1.3.6.1.4.1.39967.3.1.6 = STRING: "104dedf601080057" .1.3.6.1.4.1.39967.3.1.7 = STRING: "10011af701080027" .1.3.6.1.4.1.39967.3.1.8 = STRING: "0000000000000000" .1.3.6.1.4.1.39967.3.1.9 = STRING: "0000000000000000" .1.3.6.1.4.1.39967.3.2.0 = STRING: "kessel" .1.3.6.1.4.1.39967.3.2.1 = STRING: "warmwasser" .1.3.6.1.4.1.39967.3.2.2 = STRING: "aussen" .1.3.6.1.4.1.39967.3.2.3 = STRING: "speicher" .1.3.6.1.4.1.39967.3.2.4 = STRING: "heizung vl" .1.3.6.1.4.1.39967.3.2.5 = STRING: "heizung rl" .1.3.6.1.4.1.39967.3.2.6 = STRING: "boiler vl" .1.3.6.1.4.1.39967.3.2.7 = STRING: "boiler rl" .1.3.6.1.4.1.39967.3.2.8 = "" .1.3.6.1.4.1.39967.3.2.9 = "" .1.3.6.1.4.1.39967.3.3.0 = INTEGER: 334 .1.3.6.1.4.1.39967.3.3.1 = INTEGER: 467 .1.3.6.1.4.1.39967.3.3.2 = INTEGER: 127 .1.3.6.1.4.1.39967.3.3.3 = INTEGER: 185 .1.3.6.1.4.1.39967.3.3.4 = INTEGER: 318 .1.3.6.1.4.1.39967.3.3.5 = INTEGER: 269 .1.3.6.1.4.1.39967.3.3.6 = INTEGER: 366 .1.3.6.1.4.1.39967.3.3.7 = INTEGER: 291 .1.3.6.1.4.1.39967.3.3.8 = INTEGER: 0 .1.3.6.1.4.1.39967.3.3.9 = INTEGER: 0 .1.3.6.1.4.1.39967.3.4.0 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.1 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.2 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.3 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.4 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.5 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.6 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.7 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.8 = INTEGER: 0 .1.3.6.1.4.1.39967.3.4.9 = INTEGER: 0 </pre> = Codebeispiele = * [[Onewire/Example/PHP (Deutsch) | PHP]] * [[Onewire/Example/Perl (Deutsch) | Perl]] * [[Onewire/Example/Python | Python]] * [[Onewire/Example/Shell | sh/bash]] [[Category:Ethersex]] [[Category:StepByStep]] [[Category:Onewire]] = Bezugsquellen = * Laut Michael Schultz (k1w1) hat er immer DS1820 auf Lager und kann sie sehr günstig weiterverkaufen. Auch Mindermengen. Mail: ethersex [AT] keyb [DOT] de * und natürlich bei den üblichen Verdächtigen: Reichelt, Segor, Conrad f398a26e526bb381d958269284c66dfd81c28526 0 29 870 829 2012-12-21T13:45:01Z GooPie4o 265 wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR Receivers->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP is a port of the [http://www.mikrocontroller.net/articles/IRMP infrared multi-protocol decoder] for [[Ethersex]]. == Connection == The reception of IR signals is performed by a receiver TSOP1736 type (or similar). This may be connected to any pin. The interrogation of the pins and the decoding of the IR protocol is done in an ISR, which occupies one 8-bit timer of the ATmegas. When sending the signal with the carrier frequency of the respective IR Protocol is [[PWM]] modulated. This is another 8-bit timer of the ATmegas (OC0/OC2) is demonstrated. On the [[Etherrape]] board takes a [[NE555]] this function, ie the option ''Use external modulator for the transmitter'' is activated. It saves a timer on the [[AVR]] is set at a carrier frequency. Example of a ATMega32 from: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Meaning: * IRMP_RX - pin the IR receiver is connected to * IRMP_USE_TIMER2 - use Timer2 for receiver, Timer0 for sender (undef = reversed) * IRMP_RX_LOW_ACTIVE - the IR receiver is low-active (undef = high-active) * IRMP_RX_LED_LOW_ACTIVE - the control LED of the receiver is switched to USS (undef = switched to GND) * IRMP_TX - pin the IR sender is connected to (=output of Timer0 or Timer2, see IRMP_USE_TIMER2)<br>'''Caution: 0A to 2A if MCU with A / B channel''' * IRMP_TX_LED_LOW_ACTIVE - the control LED of the sender is switched to USS (undef = switched to GND) == Configuration == Each supported IR protocol occupies memory of code. Therefore, one should select only the required protocols. A detailed overview of the protocols are the [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail article in the mikrocontroller forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ --- Debugging Flags │ │ [ ] IRMP Debug IRMP also decodes the RC5 protocol, so that the separately [[Ethersex]] contained [[RC5]] decoder is not needed any longer. == [[ECMD]] == IRMP implements a [[ECMD]] interface for reading received and decoded IR commands and send IR commands. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == === Output received characters via [[SYSLOG|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> IRMP_READ checks for received IR code and stores it in the variables IRMP_PROTOCOL, IRMP_ADDRESS, and IRMP_COMMAND IRMP_FLAGS. Return values ​​greater than zero indicate the validity of the variables. If IRMP_FLAGS = 1 it is a repetition. === Control of [[StellaLight|Stella]]/Pins by IR commands === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> The script switches the Stella channel 0 to 255 or 0, the remote control is a Denon (Protocol 8). With ''include'' access to the Stella sources granted.<br> Instead of ''"stella_setValue (STELLA_SET_IMMEDIATELY, 0, 255);"'' ''"PIN_SET (LED)"'' and ''"PIN_CLEAR (LED)"'' can be used ([[Named_PIN|named pin]]). |Named PIN]]). === Send IR commands === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON dnl 31 = BOSE dnl 32 = A1TVBOX IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Command 5678 to device 1234 will be send with one repetition using the NEC protocol. 8f8a6bdb834174b6da77a332ca9f8b7f36db09a9 0 156 872 398 2012-12-28T10:32:10Z GooPie4o 265 /* unterstützte Systeme */ wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{I/O}}->RFM12 ASK |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6= |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} RFM12 ASK schaltet Funksteckdosen von verschiedenen Hersteller. == Unterstützte Systeme == ===Tevion=== Funksteckdosen mit einer 'Anlern-Taste' können mit Hilfe des LERN-Buttons auf der embeded Website des etherrapes */rf.ht auf den gesendeten Hauscode programmiert werden. Erstaunlicherweise können mit diesem Modul auch die Codes der X10 Fernbedienung von Pollin gesendet werden. Eine Code-Sammlung gibts [[X10-codes|hier]]. Getestet: * Tevion * MMANDOLYN LIBRA GmbH, Model No. WRC001 * X10 Pollin Best.Nr. 721 379 ===Intertechno (ITS-150)=== Bei Sender vom Typ Intertechno ITS-150 wird über einen Drehschalter auf der Rückseite der Familiencode eingestellt. Auf der Vorderseite gibt es einen Schieberegler für die Auswahl von Gruppe 1-4 sowie Ein/Aus Knöpfe für die Geräte 1-4 (siehe Bild). Die zusätzlich vorhandenen Gruppentaste funktioniert mit den Empfängern Intertechno CMR-500 nicht (deshalb nicht implementiert). ===2272=== Diese Steckdosen werden üblicherweise über einen Block von 10 DIP-Switches konfiguriert. Dabei wird mit den ersten fünf Schaltern der Hauscode gesetzt. Es ergeben sich also 32 mögliche Einstellungen. Die übrigen fünf Schalter geben die Adresse der Steckdose an. Bei Verwendung des mitgelieferten Senders wird jeweils einer der Adressschalter auf "1" gesetzt: In Dose A setzt man Dip 6 auf '1'; in Dose B Dip 7 auf '1'... Bei Ansteuerung mit dem Ethersex-System besteht diese Einschränkung nicht, so dass hier 32 verschiedene Adressen möglich sind. Getestet: {|class=wikitable |[[]] |[[Bild:düwiaktor.jpg|100px]] |[[Bild:Globusaktoren.jpg|100px]] |[[Bild:Kangtai2605.jpg|100px]] |[[Bild:Kangtai6899s.jpg|100px]] |- |valign=top|ELRO AB440R |valign=top|Düwi Modell 0369-3 |valign=top|Kangtai<br>v. Globus |valign=top|Kangtai<br>Model 2605 |valign=top|Kangtai<br>Model 6899s<br>[[Warnung vor Kangtai 6899s|'''Warnung!''']] |- |Delay 100 |Delay 60 |Delay 72 |Delay 72 |Delay 72 |} == 1527 == Anlernbare Unterputz-Dimmer (zB. Pollin Funkdimmerset FD-UP003) mit Fernbedienung. Die mitgelieferte Fernbedienung besitzt einen HS1527 Encoder (baugleich RT1527/ EV1527/FP1527/SC1527). Der gesendete Code bestehtaus 24 Bits, welche per ASK gesendet werden. Davon sind die ersten 20 Bits fest programmiert - der Hauscode sozusagen. Die letzten 4 Bits sind der eigentliche Schalt-Befehl. Getestet: {|class=wikitable |[[Bild:FD-UP003.jpg|Pollin Electronic FD-UP003|100px]] |- |valign=top|Pollin FD-UP003<br>[[Hinweis FD-UP003|'''Hinweis!''']] |} a4bf417d0c562e2a516a3900524fd969163007bc 873 872 2012-12-28T10:32:38Z GooPie4o 265 /* 1527 */ wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{I/O}}->RFM12 ASK |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6= |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} RFM12 ASK schaltet Funksteckdosen von verschiedenen Hersteller. == Unterstützte Systeme == ===Tevion=== Funksteckdosen mit einer 'Anlern-Taste' können mit Hilfe des LERN-Buttons auf der embeded Website des etherrapes */rf.ht auf den gesendeten Hauscode programmiert werden. Erstaunlicherweise können mit diesem Modul auch die Codes der X10 Fernbedienung von Pollin gesendet werden. Eine Code-Sammlung gibts [[X10-codes|hier]]. Getestet: * Tevion * MMANDOLYN LIBRA GmbH, Model No. WRC001 * X10 Pollin Best.Nr. 721 379 ===Intertechno (ITS-150)=== Bei Sender vom Typ Intertechno ITS-150 wird über einen Drehschalter auf der Rückseite der Familiencode eingestellt. Auf der Vorderseite gibt es einen Schieberegler für die Auswahl von Gruppe 1-4 sowie Ein/Aus Knöpfe für die Geräte 1-4 (siehe Bild). Die zusätzlich vorhandenen Gruppentaste funktioniert mit den Empfängern Intertechno CMR-500 nicht (deshalb nicht implementiert). ===2272=== Diese Steckdosen werden üblicherweise über einen Block von 10 DIP-Switches konfiguriert. Dabei wird mit den ersten fünf Schaltern der Hauscode gesetzt. Es ergeben sich also 32 mögliche Einstellungen. Die übrigen fünf Schalter geben die Adresse der Steckdose an. Bei Verwendung des mitgelieferten Senders wird jeweils einer der Adressschalter auf "1" gesetzt: In Dose A setzt man Dip 6 auf '1'; in Dose B Dip 7 auf '1'... Bei Ansteuerung mit dem Ethersex-System besteht diese Einschränkung nicht, so dass hier 32 verschiedene Adressen möglich sind. Getestet: {|class=wikitable |[[]] |[[Bild:düwiaktor.jpg|100px]] |[[Bild:Globusaktoren.jpg|100px]] |[[Bild:Kangtai2605.jpg|100px]] |[[Bild:Kangtai6899s.jpg|100px]] |- |valign=top|ELRO AB440R |valign=top|Düwi Modell 0369-3 |valign=top|Kangtai<br>v. Globus |valign=top|Kangtai<br>Model 2605 |valign=top|Kangtai<br>Model 6899s<br>[[Warnung vor Kangtai 6899s|'''Warnung!''']] |- |Delay 100 |Delay 60 |Delay 72 |Delay 72 |Delay 72 |} === 1527 === Anlernbare Unterputz-Dimmer (zB. Pollin Funkdimmerset FD-UP003) mit Fernbedienung. Die mitgelieferte Fernbedienung besitzt einen HS1527 Encoder (baugleich RT1527/ EV1527/FP1527/SC1527). Der gesendete Code bestehtaus 24 Bits, welche per ASK gesendet werden. Davon sind die ersten 20 Bits fest programmiert - der Hauscode sozusagen. Die letzten 4 Bits sind der eigentliche Schalt-Befehl. Getestet: {|class=wikitable |[[Bild:FD-UP003.jpg|Pollin Electronic FD-UP003|100px]] |- |valign=top|Pollin FD-UP003<br>[[Hinweis FD-UP003|'''Hinweis!''']] |} 9784b2689593f53e21e701f24bc0acac11c4c02f 892 873 2012-12-28T11:07:19Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{I/O}}->RFM12 ASK->433MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} RFM12 ASK schaltet Funksteckdosen von verschiedenen Hersteller. == Unterstützte Systeme == ===Tevion=== Funksteckdosen mit einer 'Anlern-Taste' können mit Hilfe des LERN-Buttons auf der embeded Website des etherrapes */rf.ht auf den gesendeten Hauscode programmiert werden. Erstaunlicherweise können mit diesem Modul auch die Codes der X10 Fernbedienung von Pollin gesendet werden. Eine Code-Sammlung gibts [[X10-codes|hier]]. Getestet: * Tevion * MMANDOLYN LIBRA GmbH, Model No. WRC001 * X10 Pollin Best.Nr. 721 379 ===Intertechno (ITS-150)=== Bei Sender vom Typ Intertechno ITS-150 wird über einen Drehschalter auf der Rückseite der Familiencode eingestellt. Auf der Vorderseite gibt es einen Schieberegler für die Auswahl von Gruppe 1-4 sowie Ein/Aus Knöpfe für die Geräte 1-4 (siehe Bild). Die zusätzlich vorhandenen Gruppentaste funktioniert mit den Empfängern Intertechno CMR-500 nicht (deshalb nicht implementiert). ===2272=== Diese Steckdosen werden üblicherweise über einen Block von 10 DIP-Switches konfiguriert. Dabei wird mit den ersten fünf Schaltern der Hauscode gesetzt. Es ergeben sich also 32 mögliche Einstellungen. Die übrigen fünf Schalter geben die Adresse der Steckdose an. Bei Verwendung des mitgelieferten Senders wird jeweils einer der Adressschalter auf "1" gesetzt: In Dose A setzt man Dip 6 auf '1'; in Dose B Dip 7 auf '1'... Bei Ansteuerung mit dem Ethersex-System besteht diese Einschränkung nicht, so dass hier 32 verschiedene Adressen möglich sind. Getestet: {|class=wikitable |[[]] |[[Bild:düwiaktor.jpg|100px]] |[[Bild:Globusaktoren.jpg|100px]] |[[Bild:Kangtai2605.jpg|100px]] |[[Bild:Kangtai6899s.jpg|100px]] |- |valign=top|ELRO AB440R |valign=top|Düwi Modell 0369-3 |valign=top|Kangtai<br>v. Globus |valign=top|Kangtai<br>Model 2605 |valign=top|Kangtai<br>Model 6899s<br>[[Warnung vor Kangtai 6899s|'''Warnung!''']] |- |Delay 100 |Delay 60 |Delay 72 |Delay 72 |Delay 72 |} === 1527 === Anlernbare Unterputz-Dimmer (zB. Pollin Funkdimmerset FD-UP003) mit Fernbedienung. Die mitgelieferte Fernbedienung besitzt einen HS1527 Encoder (baugleich RT1527/ EV1527/FP1527/SC1527). Der gesendete Code bestehtaus 24 Bits, welche per ASK gesendet werden. Davon sind die ersten 20 Bits fest programmiert - der Hauscode sozusagen. Die letzten 4 Bits sind der eigentliche Schalt-Befehl. Getestet: {|class=wikitable |[[Bild:FD-UP003.jpg|Pollin Electronic FD-UP003|100px]] |- |valign=top|Pollin FD-UP003<br>[[Hinweis FD-UP003|'''Hinweis!''']] |} a13988c042b099b3aa3356657c550b02838ddc62 0 335 874 2012-12-28T10:34:02Z GooPie4o 265 Created page with "{{i18n|RFM12}}" wikitext text/x-wiki {{i18n|RFM12}} f96ac552d09993f002768d7dae8bb0c6e371c17e 878 874 2012-12-28T10:38:27Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12}} [[File:Rfm12-chip.jpg]] 7c35b8f6fc27c2c64635f4fa279111c5123d9ec2 879 878 2012-12-28T10:39:44Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12}} [[Image:Rfm12-chip.jpg]] ee9d29efc976e5c545066dbf25d6ed9071aef184 896 879 2012-12-29T09:55:28Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12}} == Connection == [[Image:Rfm12-chip.jpg]] Detailed information can be found in the [http://http://www.mikrocontroller.net/articles/RFM12 Miktrocontroller Forum] (German). == Working Mode == For the working modes of the RFM12 Ethersex provides the modules FSK, ASK and FS20. [[Category:RFM12]] f61d4971aa24ad5e029e17b1a27086453343c82d 897 896 2012-12-29T09:56:43Z GooPie4o 265 /* Working Mode */ wikitext text/x-wiki {{i18n|RFM12}} == Connection == [[Image:Rfm12-chip.jpg]] Detailed information can be found in the [http://http://www.mikrocontroller.net/articles/RFM12 Miktrocontroller Forum] (German). == Working Mode == For the working modes of the RFM12 Ethersex provides the modules [[RFM12_FSK|FSK]], [[RFM12_ASK|ASK]], and [[RFM12_FS20|FS20]]. [[Category:RFM12]] a2e13ee6f072aa4e49f686e0041eb33e684f70c3 0 336 875 2012-12-28T10:34:40Z GooPie4o 265 Created page with "{{i18n|RFM12}}" wikitext text/x-wiki {{i18n|RFM12}} f96ac552d09993f002768d7dae8bb0c6e371c17e 877 875 2012-12-28T10:38:00Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12}} [[File:Rfm12-chip.jpg]] 7c35b8f6fc27c2c64635f4fa279111c5123d9ec2 880 877 2012-12-28T10:40:03Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12}} [[Image:Rfm12-chip.jpg]] ee9d29efc976e5c545066dbf25d6ed9071aef184 882 880 2012-12-28T10:52:08Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12}} [[Image:Rfm12-chip.jpg]] == Betriebsmodi == Für die Betriebsmodi des RFM12 sind in Ethersex die Module [[RFM12_FSK_(Deutsch)|FSK (IP)]], [[RFM12_ASK_(Deutsch)|ASK]] und [[RFM12_FS20_(Deutsch)|FS20]] zuständig. 138a55ee199d63f1f91433e81816bd18644b0ccb 883 882 2012-12-28T10:53:39Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12}} [[Image:Rfm12-chip.jpg]] Detailierte Informationen findet man im [http://http://www.mikrocontroller.net/articles/RFM12 Miktrocontroller Forum]. == Betriebsmodi == Für die Betriebsmodi des RFM12 sind in Ethersex die Module [[RFM12_FSK_(Deutsch)|FSK (IP)]], [[RFM12_ASK_(Deutsch)|ASK]] und [[RFM12_FS20_(Deutsch)|FS20]] zuständig. f52f5e1344fb9e5ca3f4c4a0be82a971ea3c74c6 884 883 2012-12-28T10:54:30Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12}} [[Image:Rfm12-chip.jpg]] Detailierte Informationen findet man im [http://http://www.mikrocontroller.net/articles/RFM12 Miktrocontroller Forum]. == Betriebsmodi == Für die Betriebsmodi des RFM12 sind in Ethersex die Module [[RFM12_FSK_(Deutsch)|FSK]], [[RFM12_ASK_(Deutsch)|ASK]] und [[RFM12_FS20_(Deutsch)|FS20]] zuständig. 4a3219c547f14e6b009fdac3362306d3fd1a4863 894 884 2012-12-28T18:56:32Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12}} == Anschluss == [[Image:Rfm12-chip.jpg]] Detailierte Informationen findet man im [http://http://www.mikrocontroller.net/articles/RFM12 Miktrocontroller Forum]. == Betriebsmodi == Für die Betriebsmodi des RFM12 sind in Ethersex die Module [[RFM12_FSK_(Deutsch)|FSK]], [[RFM12_ASK_(Deutsch)|ASK]] und [[RFM12_FS20_(Deutsch)|FS20]] zuständig. d895f4b0df7b52972834838858b036ab75aaf111 895 894 2012-12-29T09:51:44Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12}} == Anschluss == [[Image:Rfm12-chip.jpg]] Detailierte Informationen findet man im [http://http://www.mikrocontroller.net/articles/RFM12 Miktrocontroller Forum]. == Betriebsmodi == Für die Betriebsmodi des RFM12 sind in Ethersex die Module [[RFM12_FSK_(Deutsch)|FSK]], [[RFM12_ASK_(Deutsch)|ASK]] und [[RFM12_FS20_(Deutsch)|FS20]] zuständig. [[Category:RFM12]] 32fb542503355e1792aa10fc0587ff1a3cbc45f8 6 337 876 2012-12-28T10:36:30Z GooPie4o 265 RFM12 Chip Draufsicht (Kopiert aus altem Ethersex-Wiki) wikitext text/x-wiki RFM12 Chip Draufsicht (Kopiert aus altem Ethersex-Wiki) 7fb24c0bc63b9e5dcab7172e95d70696ba8a4d02 0 338 881 2012-12-28T10:49:03Z GooPie4o 265 Created page with "{{i18n|RFM12 ASK}}" wikitext text/x-wiki {{i18n|RFM12 ASK}} 0eb808a0b726bbc1afadbc96e294899e0fdfd0c9 890 881 2012-12-28T11:05:29Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{I/O}}->RFM12 ASK |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6= |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} 487f02562ce7811a7d7e0dcae1459d8d253fa04f 891 890 2012-12-28T11:06:12Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{I/O}}->RFM12 ASK->433MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6= |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} 3bd2805098dd1b2a9c2378cff7322b2ea1ef5052 893 891 2012-12-28T11:08:05Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{I/O}}->RFM12 ASK->433MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} ba88672999135f8f96992247d4edb3c4b2849680 0 339 885 2012-12-28T11:01:13Z GooPie4o 265 Created page with "{{i18n|RFM12 FSK}} {{Module |NAME=RFM12 FSK |MENUCONFIG={{Network}}->IP over RFM12 (FSK transmitter) support |STATUS={{In_Development}} |PINNING=yes |ECMD=no |CONTROL6=no |DEPEND…" wikitext text/x-wiki {{i18n|RFM12 FSK}} {{Module |NAME=RFM12 FSK |MENUCONFIG={{Network}}->IP over RFM12 (FSK transmitter) support |STATUS={{In_Development}} |PINNING=yes |ECMD=no |CONTROL6=no |DEPENDS= |REQUIRES=UIP_SUPPORT |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} 002f667445f3f0f5fa558dea82c1c4cc1e18ff05 889 885 2012-12-28T11:04:03Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 FSK}} {{Module |NAME=RFM12 FSK |MENUCONFIG=Network->IP over RFM12 (FSK transmitter) support |STATUS={{Stable}} |PINNING=yes |ECMD=no |CONTROL6=no |DEPENDS= |REQUIRES=UIP_SUPPORT |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} 7092b07ea052e2902f0c5c1fb47022073923ef18 0 340 886 2012-12-28T11:01:36Z GooPie4o 265 Created page with "{{i18n|RFM12 FSK}} {{Module |NAME=RFM12 FSK |MENUCONFIG={{Network}}->IP over RFM12 (FSK transmitter) support |STATUS={{In_Development}} |PINNING=yes |ECMD=no |CONTROL6=no |DEPEND…" wikitext text/x-wiki {{i18n|RFM12 FSK}} {{Module |NAME=RFM12 FSK |MENUCONFIG={{Network}}->IP over RFM12 (FSK transmitter) support |STATUS={{In_Development}} |PINNING=yes |ECMD=no |CONTROL6=no |DEPENDS= |REQUIRES=UIP_SUPPORT |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} 002f667445f3f0f5fa558dea82c1c4cc1e18ff05 887 886 2012-12-28T11:02:24Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 FSK}} {{Module |NAME=RFM12 FSK |MENUCONFIG={{Network}}->IP over RFM12 (FSK transmitter) support |STATUS={{Stable}} |PINNING=yes |ECMD=no |CONTROL6=no |DEPENDS= |REQUIRES=UIP_SUPPORT |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} 52bd591b9614f76e494f43b10098c98dc5ec8355 888 887 2012-12-28T11:03:18Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 FSK}} {{Module |NAME=RFM12 FSK |MENUCONFIG=Network->IP over RFM12 (FSK transmitter) support |STATUS={{Stable}} |PINNING=yes |ECMD=no |CONTROL6=no |DEPENDS= |REQUIRES=UIP_SUPPORT |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} 7092b07ea052e2902f0c5c1fb47022073923ef18 898 888 2012-12-29T09:59:26Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 FSK}} {{Module |NAME=RFM12 FSK |MENUCONFIG=Network->IP over RFM12 (FSK transmitter) support |STATUS={{Stable}} |PINNING=yes |ECMD=no |CONTROL6=no |DEPENDS= |REQUIRES=UIP_SUPPORT |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} [[Category:RFM12]] aa92f76967da01789ad773eacdbe45059157a4dc 0 339 899 889 2012-12-29T10:00:14Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 FSK}} {{Module |NAME=RFM12 FSK |MENUCONFIG=Network->IP over RFM12 (FSK transmitter) support |STATUS={{Stable}} |PINNING=yes |ECMD=no |CONTROL6=no |DEPENDS= |REQUIRES=UIP_SUPPORT |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} [[Category:RFM12]] 08d414c186d3762f3b685ba20a77f1f20cdaa679 0 338 900 893 2012-12-29T10:00:42Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{I/O}}->RFM12 ASK->433MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} [[Category:RFM12]] bd943b26196c916482b72ebe32383f8aed10acad 937 900 2013-03-06T09:51:22Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{I/O}}->RFM12 ASK->433MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} In ASK mode the RFM12 module ist used to switch radio outlets. Alternatively you can also receive the radio transmission between the transmitter and radio socket outlet. Currently, the following systems are supported: * Self-learning systems (drive "tevion") * Systems based on the chips or PT2262/PT2272 HX2262/2272 (driver "2272") * Concealed remote dimmer with the transmitter located HS1527 chip (driver "1527") * Transmitter type Intertechno ITS-150 [[Category:RFM12]] 74a0a8b74b7c2e81bda1c7df70fc66926aff2a79 0 156 901 892 2012-12-29T10:00:58Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{I/O}}->RFM12 ASK->433MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} RFM12 ASK schaltet Funksteckdosen von verschiedenen Hersteller. == Unterstützte Systeme == ===Tevion=== Funksteckdosen mit einer 'Anlern-Taste' können mit Hilfe des LERN-Buttons auf der embeded Website des etherrapes */rf.ht auf den gesendeten Hauscode programmiert werden. Erstaunlicherweise können mit diesem Modul auch die Codes der X10 Fernbedienung von Pollin gesendet werden. Eine Code-Sammlung gibts [[X10-codes|hier]]. [[Category:RFM12]] Getestet: * Tevion * MMANDOLYN LIBRA GmbH, Model No. WRC001 * X10 Pollin Best.Nr. 721 379 ===Intertechno (ITS-150)=== Bei Sender vom Typ Intertechno ITS-150 wird über einen Drehschalter auf der Rückseite der Familiencode eingestellt. Auf der Vorderseite gibt es einen Schieberegler für die Auswahl von Gruppe 1-4 sowie Ein/Aus Knöpfe für die Geräte 1-4 (siehe Bild). Die zusätzlich vorhandenen Gruppentaste funktioniert mit den Empfängern Intertechno CMR-500 nicht (deshalb nicht implementiert). ===2272=== Diese Steckdosen werden üblicherweise über einen Block von 10 DIP-Switches konfiguriert. Dabei wird mit den ersten fünf Schaltern der Hauscode gesetzt. Es ergeben sich also 32 mögliche Einstellungen. Die übrigen fünf Schalter geben die Adresse der Steckdose an. Bei Verwendung des mitgelieferten Senders wird jeweils einer der Adressschalter auf "1" gesetzt: In Dose A setzt man Dip 6 auf '1'; in Dose B Dip 7 auf '1'... Bei Ansteuerung mit dem Ethersex-System besteht diese Einschränkung nicht, so dass hier 32 verschiedene Adressen möglich sind. Getestet: {|class=wikitable |[[]] |[[Bild:düwiaktor.jpg|100px]] |[[Bild:Globusaktoren.jpg|100px]] |[[Bild:Kangtai2605.jpg|100px]] |[[Bild:Kangtai6899s.jpg|100px]] |- |valign=top|ELRO AB440R |valign=top|Düwi Modell 0369-3 |valign=top|Kangtai<br>v. Globus |valign=top|Kangtai<br>Model 2605 |valign=top|Kangtai<br>Model 6899s<br>[[Warnung vor Kangtai 6899s|'''Warnung!''']] |- |Delay 100 |Delay 60 |Delay 72 |Delay 72 |Delay 72 |} === 1527 === Anlernbare Unterputz-Dimmer (zB. Pollin Funkdimmerset FD-UP003) mit Fernbedienung. Die mitgelieferte Fernbedienung besitzt einen HS1527 Encoder (baugleich RT1527/ EV1527/FP1527/SC1527). Der gesendete Code bestehtaus 24 Bits, welche per ASK gesendet werden. Davon sind die ersten 20 Bits fest programmiert - der Hauscode sozusagen. Die letzten 4 Bits sind der eigentliche Schalt-Befehl. Getestet: {|class=wikitable |[[Bild:FD-UP003.jpg|Pollin Electronic FD-UP003|100px]] |- |valign=top|Pollin FD-UP003<br>[[Hinweis FD-UP003|'''Hinweis!''']] |} 2c6a9da3b14128ef0e1a2c1a160cd137ffbe47a1 939 901 2013-03-06T10:12:45Z GooPie4o 265 /* Intertechno (ITS-150) */ wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{I/O}}->RFM12 ASK->433MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} RFM12 ASK schaltet Funksteckdosen von verschiedenen Hersteller. == Unterstützte Systeme == ===Tevion=== Funksteckdosen mit einer 'Anlern-Taste' können mit Hilfe des LERN-Buttons auf der embeded Website des etherrapes */rf.ht auf den gesendeten Hauscode programmiert werden. Erstaunlicherweise können mit diesem Modul auch die Codes der X10 Fernbedienung von Pollin gesendet werden. Eine Code-Sammlung gibts [[X10-codes|hier]]. [[Category:RFM12]] Getestet: * Tevion * MMANDOLYN LIBRA GmbH, Model No. WRC001 * X10 Pollin Best.Nr. 721 379 ===Intertechno (ITS-150)=== [[File:Intertechno-its150.jpg|right|100px]] Bei Sender vom Typ Intertechno ITS-150 wird über einen Drehschalter auf der Rückseite der Familiencode eingestellt. Auf der Vorderseite gibt es einen Schieberegler für die Auswahl von Gruppe 1-4 sowie Ein/Aus Knöpfe für die Geräte 1-4 (siehe Bild). Die zusätzlich vorhandenen Gruppentaste funktioniert mit den Empfängern Intertechno CMR-500 nicht (deshalb nicht implementiert). ===2272=== Diese Steckdosen werden üblicherweise über einen Block von 10 DIP-Switches konfiguriert. Dabei wird mit den ersten fünf Schaltern der Hauscode gesetzt. Es ergeben sich also 32 mögliche Einstellungen. Die übrigen fünf Schalter geben die Adresse der Steckdose an. Bei Verwendung des mitgelieferten Senders wird jeweils einer der Adressschalter auf "1" gesetzt: In Dose A setzt man Dip 6 auf '1'; in Dose B Dip 7 auf '1'... Bei Ansteuerung mit dem Ethersex-System besteht diese Einschränkung nicht, so dass hier 32 verschiedene Adressen möglich sind. Getestet: {|class=wikitable |[[]] |[[Bild:düwiaktor.jpg|100px]] |[[Bild:Globusaktoren.jpg|100px]] |[[Bild:Kangtai2605.jpg|100px]] |[[Bild:Kangtai6899s.jpg|100px]] |- |valign=top|ELRO AB440R |valign=top|Düwi Modell 0369-3 |valign=top|Kangtai<br>v. Globus |valign=top|Kangtai<br>Model 2605 |valign=top|Kangtai<br>Model 6899s<br>[[Warnung vor Kangtai 6899s|'''Warnung!''']] |- |Delay 100 |Delay 60 |Delay 72 |Delay 72 |Delay 72 |} === 1527 === Anlernbare Unterputz-Dimmer (zB. Pollin Funkdimmerset FD-UP003) mit Fernbedienung. Die mitgelieferte Fernbedienung besitzt einen HS1527 Encoder (baugleich RT1527/ EV1527/FP1527/SC1527). Der gesendete Code bestehtaus 24 Bits, welche per ASK gesendet werden. Davon sind die ersten 20 Bits fest programmiert - der Hauscode sozusagen. Die letzten 4 Bits sind der eigentliche Schalt-Befehl. Getestet: {|class=wikitable |[[Bild:FD-UP003.jpg|Pollin Electronic FD-UP003|100px]] |- |valign=top|Pollin FD-UP003<br>[[Hinweis FD-UP003|'''Hinweis!''']] |} ea8701f045c8bd9b7c8a0e4a17b4cac3017d29dd 941 939 2013-03-06T10:15:03Z GooPie4o 265 /* 1527 */ wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{I/O}}->RFM12 ASK->433MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} RFM12 ASK schaltet Funksteckdosen von verschiedenen Hersteller. == Unterstützte Systeme == ===Tevion=== Funksteckdosen mit einer 'Anlern-Taste' können mit Hilfe des LERN-Buttons auf der embeded Website des etherrapes */rf.ht auf den gesendeten Hauscode programmiert werden. Erstaunlicherweise können mit diesem Modul auch die Codes der X10 Fernbedienung von Pollin gesendet werden. Eine Code-Sammlung gibts [[X10-codes|hier]]. [[Category:RFM12]] Getestet: * Tevion * MMANDOLYN LIBRA GmbH, Model No. WRC001 * X10 Pollin Best.Nr. 721 379 ===Intertechno (ITS-150)=== [[File:Intertechno-its150.jpg|right|100px]] Bei Sender vom Typ Intertechno ITS-150 wird über einen Drehschalter auf der Rückseite der Familiencode eingestellt. Auf der Vorderseite gibt es einen Schieberegler für die Auswahl von Gruppe 1-4 sowie Ein/Aus Knöpfe für die Geräte 1-4 (siehe Bild). Die zusätzlich vorhandenen Gruppentaste funktioniert mit den Empfängern Intertechno CMR-500 nicht (deshalb nicht implementiert). ===2272=== Diese Steckdosen werden üblicherweise über einen Block von 10 DIP-Switches konfiguriert. Dabei wird mit den ersten fünf Schaltern der Hauscode gesetzt. Es ergeben sich also 32 mögliche Einstellungen. Die übrigen fünf Schalter geben die Adresse der Steckdose an. Bei Verwendung des mitgelieferten Senders wird jeweils einer der Adressschalter auf "1" gesetzt: In Dose A setzt man Dip 6 auf '1'; in Dose B Dip 7 auf '1'... Bei Ansteuerung mit dem Ethersex-System besteht diese Einschränkung nicht, so dass hier 32 verschiedene Adressen möglich sind. Getestet: {|class=wikitable |[[]] |[[Bild:düwiaktor.jpg|100px]] |[[Bild:Globusaktoren.jpg|100px]] |[[Bild:Kangtai2605.jpg|100px]] |[[Bild:Kangtai6899s.jpg|100px]] |- |valign=top|ELRO AB440R |valign=top|Düwi Modell 0369-3 |valign=top|Kangtai<br>v. Globus |valign=top|Kangtai<br>Model 2605 |valign=top|Kangtai<br>Model 6899s<br>[[Warnung vor Kangtai 6899s|'''Warnung!''']] |- |Delay 100 |Delay 60 |Delay 72 |Delay 72 |Delay 72 |} === 1527 === Anlernbare Unterputz-Dimmer (zB. Pollin Funkdimmerset FD-UP003) mit Fernbedienung. Die mitgelieferte Fernbedienung besitzt einen HS1527 Encoder (baugleich RT1527/ EV1527/FP1527/SC1527). Der gesendete Code bestehtaus 24 Bits, welche per ASK gesendet werden. Davon sind die ersten 20 Bits fest programmiert - der Hauscode sozusagen. Die letzten 4 Bits sind der eigentliche Schalt-Befehl. Getestet: {|class=wikitable |[[Image:FD-UP003.jpg‎|Pollin Electronic FD-UP003|right|100px]] |- |valign=top|Pollin FD-UP003<br>[[Hinweis FD-UP003|'''Hinweis!''']] |} 5a7e641f4c6098234af78fe27569e6c27c8500eb 942 941 2013-03-06T10:15:58Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{I/O}}->RFM12 ASK->433MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} RFM12 ASK schaltet Funksteckdosen von verschiedenen Hersteller. == Unterstützte Systeme == ===Tevion=== Funksteckdosen mit einer 'Anlern-Taste' können mit Hilfe des LERN-Buttons auf der embeded Website des etherrapes */rf.ht auf den gesendeten Hauscode programmiert werden. Erstaunlicherweise können mit diesem Modul auch die Codes der X10 Fernbedienung von Pollin gesendet werden. Eine Code-Sammlung gibts [[X10-codes|hier]]. [[Category:RFM12]] Getestet: * Tevion * MMANDOLYN LIBRA GmbH, Model No. WRC001 * X10 Pollin Best.Nr. 721 379 ===Intertechno (ITS-150)=== [[Image:Intertechno-its150.jpg|right|100px]] Bei Sender vom Typ Intertechno ITS-150 wird über einen Drehschalter auf der Rückseite der Familiencode eingestellt. Auf der Vorderseite gibt es einen Schieberegler für die Auswahl von Gruppe 1-4 sowie Ein/Aus Knöpfe für die Geräte 1-4 (siehe Bild). Die zusätzlich vorhandenen Gruppentaste funktioniert mit den Empfängern Intertechno CMR-500 nicht (deshalb nicht implementiert). ===2272=== Diese Steckdosen werden üblicherweise über einen Block von 10 DIP-Switches konfiguriert. Dabei wird mit den ersten fünf Schaltern der Hauscode gesetzt. Es ergeben sich also 32 mögliche Einstellungen. Die übrigen fünf Schalter geben die Adresse der Steckdose an. Bei Verwendung des mitgelieferten Senders wird jeweils einer der Adressschalter auf "1" gesetzt: In Dose A setzt man Dip 6 auf '1'; in Dose B Dip 7 auf '1'... Bei Ansteuerung mit dem Ethersex-System besteht diese Einschränkung nicht, so dass hier 32 verschiedene Adressen möglich sind. Getestet: {|class=wikitable |[[]] |[[Bild:düwiaktor.jpg|100px]] |[[Bild:Globusaktoren.jpg|100px]] |[[Bild:Kangtai2605.jpg|100px]] |[[Bild:Kangtai6899s.jpg|100px]] |- |valign=top|ELRO AB440R |valign=top|Düwi Modell 0369-3 |valign=top|Kangtai<br>v. Globus |valign=top|Kangtai<br>Model 2605 |valign=top|Kangtai<br>Model 6899s<br>[[Warnung vor Kangtai 6899s|'''Warnung!''']] |- |Delay 100 |Delay 60 |Delay 72 |Delay 72 |Delay 72 |} === 1527 === Anlernbare Unterputz-Dimmer (zB. Pollin Funkdimmerset FD-UP003) mit Fernbedienung. Die mitgelieferte Fernbedienung besitzt einen HS1527 Encoder (baugleich RT1527/ EV1527/FP1527/SC1527). Der gesendete Code bestehtaus 24 Bits, welche per ASK gesendet werden. Davon sind die ersten 20 Bits fest programmiert - der Hauscode sozusagen. Die letzten 4 Bits sind der eigentliche Schalt-Befehl. Getestet: {|class=wikitable |[[Image:FD-UP003.jpg‎|150px|Pollin Electronic FD-UP003]] |- |valign=top|Pollin FD-UP003<br>[[Hinweis FD-UP003|'''Hinweis!''']] |} 94a5cb87e1e2d85b9d30768dcbc90fb4bbbe3bc5 945 942 2013-03-06T10:19:37Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{I/O}}->RFM12 ASK->433MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} RFM12 ASK schaltet Funksteckdosen von verschiedenen Hersteller. == Unterstützte Systeme == ===Tevion=== Funksteckdosen mit einer 'Anlern-Taste' können mit Hilfe des LERN-Buttons auf der embeded Website des etherrapes */rf.ht auf den gesendeten Hauscode programmiert werden. Erstaunlicherweise können mit diesem Modul auch die Codes der X10 Fernbedienung von Pollin gesendet werden. Eine Code-Sammlung gibts [[X10-codes|hier]]. [[Category:RFM12]] Getestet: * Tevion * MMANDOLYN LIBRA GmbH, Model No. WRC001 * X10 Pollin Best.Nr. 721 379 ===Intertechno (ITS-150)=== [[Image:Intertechno-its150.jpg|right|100px]] Bei Sender vom Typ Intertechno ITS-150 wird über einen Drehschalter auf der Rückseite der Familiencode eingestellt. Auf der Vorderseite gibt es einen Schieberegler für die Auswahl von Gruppe 1-4 sowie Ein/Aus Knöpfe für die Geräte 1-4 (siehe Bild). Die zusätzlich vorhandenen Gruppentaste funktioniert mit den Empfängern Intertechno CMR-500 nicht (deshalb nicht implementiert). ===2272=== Diese Steckdosen werden üblicherweise über einen Block von 10 DIP-Switches konfiguriert. Dabei wird mit den ersten fünf Schaltern der Hauscode gesetzt. Es ergeben sich also 32 mögliche Einstellungen. Die übrigen fünf Schalter geben die Adresse der Steckdose an. Bei Verwendung des mitgelieferten Senders wird jeweils einer der Adressschalter auf "1" gesetzt: In Dose A setzt man Dip 6 auf '1'; in Dose B Dip 7 auf '1'... Bei Ansteuerung mit dem Ethersex-System besteht diese Einschränkung nicht, so dass hier 32 verschiedene Adressen möglich sind. Getestet: {|class=wikitable |[[]] |[[Image:Duewiaktor.jpg|100px]] |[[Image:Globusaktoren.jpg|100px]] |[[Image:Kangtai2605.jpg|100px]] |[[Image:Kangtai6899s.jpg|100px]] |- |valign=top|ELRO AB440R |valign=top|Düwi Modell 0369-3 |valign=top|Kangtai<br>v. Globus |valign=top|Kangtai<br>Model 2605 |valign=top|Kangtai<br>Model 6899s<br>[[Warnung vor Kangtai 6899s|'''Warnung!''']] |- |Delay 100 |Delay 60 |Delay 72 |Delay 72 |Delay 72 |} === 1527 === Anlernbare Unterputz-Dimmer (zB. Pollin Funkdimmerset FD-UP003) mit Fernbedienung. Die mitgelieferte Fernbedienung besitzt einen HS1527 Encoder (baugleich RT1527/ EV1527/FP1527/SC1527). Der gesendete Code bestehtaus 24 Bits, welche per ASK gesendet werden. Davon sind die ersten 20 Bits fest programmiert - der Hauscode sozusagen. Die letzten 4 Bits sind der eigentliche Schalt-Befehl. Getestet: {|class=wikitable |[[Image:FD-UP003.jpg‎|150px|Pollin Electronic FD-UP003]] |- |valign=top|Pollin FD-UP003<br>[[Hinweis FD-UP003|'''Hinweis!''']] |} 660261a909fbed40465abf4c4b386a6b1ccf0d16 948 945 2013-03-06T10:21:30Z GooPie4o 265 /* Intertechno (ITS-150) */ wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{I/O}}->RFM12 ASK->433MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} RFM12 ASK schaltet Funksteckdosen von verschiedenen Hersteller. == Unterstützte Systeme == ===Tevion=== Funksteckdosen mit einer 'Anlern-Taste' können mit Hilfe des LERN-Buttons auf der embeded Website des etherrapes */rf.ht auf den gesendeten Hauscode programmiert werden. Erstaunlicherweise können mit diesem Modul auch die Codes der X10 Fernbedienung von Pollin gesendet werden. Eine Code-Sammlung gibts [[X10-codes|hier]]. [[Category:RFM12]] Getestet: * Tevion * MMANDOLYN LIBRA GmbH, Model No. WRC001 * X10 Pollin Best.Nr. 721 379 ===Intertechno (ITS-150)=== [[Image:Intertechno-its150.jpg|150px]] Bei Sender vom Typ Intertechno ITS-150 wird über einen Drehschalter auf der Rückseite der Familiencode eingestellt. Auf der Vorderseite gibt es einen Schieberegler für die Auswahl von Gruppe 1-4 sowie Ein/Aus Knöpfe für die Geräte 1-4 (siehe Bild). Die zusätzlich vorhandenen Gruppentaste funktioniert mit den Empfängern Intertechno CMR-500 nicht (deshalb nicht implementiert). ===2272=== Diese Steckdosen werden üblicherweise über einen Block von 10 DIP-Switches konfiguriert. Dabei wird mit den ersten fünf Schaltern der Hauscode gesetzt. Es ergeben sich also 32 mögliche Einstellungen. Die übrigen fünf Schalter geben die Adresse der Steckdose an. Bei Verwendung des mitgelieferten Senders wird jeweils einer der Adressschalter auf "1" gesetzt: In Dose A setzt man Dip 6 auf '1'; in Dose B Dip 7 auf '1'... Bei Ansteuerung mit dem Ethersex-System besteht diese Einschränkung nicht, so dass hier 32 verschiedene Adressen möglich sind. Getestet: {|class=wikitable |[[]] |[[Image:Duewiaktor.jpg|100px]] |[[Image:Globusaktoren.jpg|100px]] |[[Image:Kangtai2605.jpg|100px]] |[[Image:Kangtai6899s.jpg|100px]] |- |valign=top|ELRO AB440R |valign=top|Düwi Modell 0369-3 |valign=top|Kangtai<br>v. Globus |valign=top|Kangtai<br>Model 2605 |valign=top|Kangtai<br>Model 6899s<br>[[Warnung vor Kangtai 6899s|'''Warnung!''']] |- |Delay 100 |Delay 60 |Delay 72 |Delay 72 |Delay 72 |} === 1527 === Anlernbare Unterputz-Dimmer (zB. Pollin Funkdimmerset FD-UP003) mit Fernbedienung. Die mitgelieferte Fernbedienung besitzt einen HS1527 Encoder (baugleich RT1527/ EV1527/FP1527/SC1527). Der gesendete Code bestehtaus 24 Bits, welche per ASK gesendet werden. Davon sind die ersten 20 Bits fest programmiert - der Hauscode sozusagen. Die letzten 4 Bits sind der eigentliche Schalt-Befehl. Getestet: {|class=wikitable |[[Image:FD-UP003.jpg‎|150px|Pollin Electronic FD-UP003]] |- |valign=top|Pollin FD-UP003<br>[[Hinweis FD-UP003|'''Hinweis!''']] |} fb3d6fb1658155fafbb93edd14313a94d4306b60 949 948 2013-03-06T10:22:05Z GooPie4o 265 /* Intertechno (ITS-150) */ wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{I/O}}->RFM12 ASK->433MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} RFM12 ASK schaltet Funksteckdosen von verschiedenen Hersteller. == Unterstützte Systeme == ===Tevion=== Funksteckdosen mit einer 'Anlern-Taste' können mit Hilfe des LERN-Buttons auf der embeded Website des etherrapes */rf.ht auf den gesendeten Hauscode programmiert werden. Erstaunlicherweise können mit diesem Modul auch die Codes der X10 Fernbedienung von Pollin gesendet werden. Eine Code-Sammlung gibts [[X10-codes|hier]]. [[Category:RFM12]] Getestet: * Tevion * MMANDOLYN LIBRA GmbH, Model No. WRC001 * X10 Pollin Best.Nr. 721 379 ===Intertechno (ITS-150)=== Bei Sender vom Typ Intertechno ITS-150 wird über einen Drehschalter auf der Rückseite der Familiencode eingestellt. Auf der Vorderseite gibt es einen Schieberegler für die Auswahl von Gruppe 1-4 sowie Ein/Aus Knöpfe für die Geräte 1-4 (siehe Bild). Die zusätzlich vorhandenen Gruppentaste funktioniert mit den Empfängern Intertechno CMR-500 nicht (deshalb nicht implementiert). [[Image:Intertechno-its150.jpg|150px]] ===2272=== Diese Steckdosen werden üblicherweise über einen Block von 10 DIP-Switches konfiguriert. Dabei wird mit den ersten fünf Schaltern der Hauscode gesetzt. Es ergeben sich also 32 mögliche Einstellungen. Die übrigen fünf Schalter geben die Adresse der Steckdose an. Bei Verwendung des mitgelieferten Senders wird jeweils einer der Adressschalter auf "1" gesetzt: In Dose A setzt man Dip 6 auf '1'; in Dose B Dip 7 auf '1'... Bei Ansteuerung mit dem Ethersex-System besteht diese Einschränkung nicht, so dass hier 32 verschiedene Adressen möglich sind. Getestet: {|class=wikitable |[[]] |[[Image:Duewiaktor.jpg|100px]] |[[Image:Globusaktoren.jpg|100px]] |[[Image:Kangtai2605.jpg|100px]] |[[Image:Kangtai6899s.jpg|100px]] |- |valign=top|ELRO AB440R |valign=top|Düwi Modell 0369-3 |valign=top|Kangtai<br>v. Globus |valign=top|Kangtai<br>Model 2605 |valign=top|Kangtai<br>Model 6899s<br>[[Warnung vor Kangtai 6899s|'''Warnung!''']] |- |Delay 100 |Delay 60 |Delay 72 |Delay 72 |Delay 72 |} === 1527 === Anlernbare Unterputz-Dimmer (zB. Pollin Funkdimmerset FD-UP003) mit Fernbedienung. Die mitgelieferte Fernbedienung besitzt einen HS1527 Encoder (baugleich RT1527/ EV1527/FP1527/SC1527). Der gesendete Code bestehtaus 24 Bits, welche per ASK gesendet werden. Davon sind die ersten 20 Bits fest programmiert - der Hauscode sozusagen. Die letzten 4 Bits sind der eigentliche Schalt-Befehl. Getestet: {|class=wikitable |[[Image:FD-UP003.jpg‎|150px|Pollin Electronic FD-UP003]] |- |valign=top|Pollin FD-UP003<br>[[Hinweis FD-UP003|'''Hinweis!''']] |} 3d99c71fa9604421e38f52d0ae3fad3aa62c1c46 0 312 902 813 2012-12-29T10:01:28Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} [[Category:RFM12]] 9d9f44479fd204a1c8aa2f53d675453de2e37801 0 311 903 814 2012-12-29T10:01:47Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} [[Category:RFM12]] 9d9f44479fd204a1c8aa2f53d675453de2e37801 0 335 904 897 2013-01-05T21:14:14Z GooPie4o 265 typo wikitext text/x-wiki {{i18n|RFM12}} == Connection == [[Image:Rfm12-chip.jpg]] Detailed information can be found in the [http://www.mikrocontroller.net/articles/RFM12 Miktrocontroller Forum] (German). == Working Mode == For the working modes of the RFM12 Ethersex provides the modules [[RFM12_FSK|FSK]], [[RFM12_ASK|ASK]], and [[RFM12_FS20|FS20]]. [[Category:RFM12]] e5fbad76762b06bc9007b3a9563a3ac38ec8ceb5 926 904 2013-03-06T06:39:37Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12}} RFM12 is a low costing ISM band FSK transceiver module implemented with unique PLL. It works signal ranges from 315/433/868/915MHZ bands. The SPI interface is used to communicate with microcontroller for parameter setting. Features as listed on the [http://www.hoperf.com/ manufactures] site: * low costing, high performance and price ratio * tuning free during production * PLL and zero IF technology * fast PLL lock time * high resolution PLL with 2.5KHz step * high data rate (up to 115.2 kbps with internal demodulator) * differential antenna input * automatic antenna tuning * Programmable TX frequency deviation (15 to 240 KHz) * programmable receiver bandwidth (67 - 400 kHz) * analog and digital signal strength indicater(ARSSI/DRSSI) * AFC * DQD * Internal data filtering and clock recovery * RX synchron pattern recognition * SPI interface * clock and reset signal output for external MCU use * 16 bit RX Data FIFO * Two 8 bit TX data registers * 10MHz crystal for PLL timing * wakeup timer * 2.2V - 5.4V power supply * low power consumption * stand by current less than 0.3µA == Connection == [[Image:Rfm12-chip.jpg]] Detailed information can be found in the [http://www.mikrocontroller.net/articles/RFM12 Miktrocontroller Forum] (German). == Working Mode == For the working modes of the RFM12 Ethersex provides the modules [[RFM12_FSK|FSK]], [[RFM12_ASK|ASK]], and [[RFM12_FS20|FS20]]. [[Category:RFM12]] ace055e7dda19ab70e9c109648b8bd868dc03584 0 336 905 895 2013-01-05T21:14:56Z GooPie4o 265 typo wikitext text/x-wiki {{i18n|RFM12}} == Anschluss == [[Image:Rfm12-chip.jpg]] Detailierte Informationen findet man im [http://www.mikrocontroller.net/articles/RFM12 Miktrocontroller Forum]. == Betriebsmodi == Für die Betriebsmodi des RFM12 sind in Ethersex die Module [[RFM12_FSK_(Deutsch)|FSK]], [[RFM12_ASK_(Deutsch)|ASK]] und [[RFM12_FS20_(Deutsch)|FS20]] zuständig. [[Category:RFM12]] 7de91c9b04d33f044deca7766a39030161c18269 0 341 906 2013-03-04T18:26:54Z GooPie4o 265 Created page with "{{i18n|DHT}} {{Module |NAME=DHT |MENUCONFIG=I/O->Humidity & temperature sensors->DHT 11/22 |STATUS={{Experimental}} |PINNING=yes |ECMD=yes |CONTROL6=no |DEPENDS= |REQUIRES= |CODE…" wikitext text/x-wiki {{i18n|DHT}} {{Module |NAME=DHT |MENUCONFIG=I/O->Humidity & temperature sensors->DHT 11/22 |STATUS={{Experimental}} |PINNING=yes |ECMD=yes |CONTROL6=no |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/dht https://github.com/ethersex/ethersex/tree/master/hardware/dht] }} [[Category:Sensors]] fbf5f5aab06bd61816a2fb9c036d32b89897df37 909 906 2013-03-04T18:35:28Z GooPie4o 265 wikitext text/x-wiki {{i18n|DHT}} {{Module |NAME=DHT |MENUCONFIG={{I/O}}->Humidity & temperature sensors->DHT 11/22 |STATUS={{Experimental}} |PINNING=yes |ECMD=yes |CONTROL6=no |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/dht https://github.com/ethersex/ethersex/tree/master/hardware/dht] }} [[Category:Sensors]] c10d9b753e519a0db58a2aa30149e63ad0725d00 911 909 2013-03-04T18:38:35Z GooPie4o 265 wikitext text/x-wiki {{i18n|DHT}} {{Module |NAME=DHT |MENUCONFIG={{I/O}}->Humidity & temperature sensors->DHT 11/22 |STATUS={{Experimental}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/dht https://github.com/ethersex/ethersex/tree/master/hardware/dht] }} [[Category:Sensors]] fa6376752e3f1aea7115edb7b830171a214a965d 916 911 2013-03-05T06:40:16Z GooPie4o 265 wikitext text/x-wiki {{i18n|DHT}} {{Module |NAME=DHT |MENUCONFIG={{I/O}}->Humidity & temperature sensors->DHT 11/22 |STATUS={{Experimental}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/dht https://github.com/ethersex/ethersex/tree/master/hardware/dht] }} ==== DHT11/DHT21/DHT22 etc. Temperature & Humidity sensors ==== These sensors are very basic and slow, but are great for hobbyists who want to do some basic data logging. The DHT sensors are made of two parts, a capacitive humidity sensor and a thermistor. There is also a very basic chip inside that does some analog to digital conversion and spits out a digital signal with the temperature and humidity. ==== DHT11 vs DHT22 ==== There are two versions of the DHT sensor available, they look a bit similar and have the same pinout, but have different characteristics. Here are the specs: DHT11 * Ultra low cost * 3 to 5V power and I/O * 2.5mA max current use during conversion (while requesting data) * Good for 20-80% humidity readings with 5% accuracy * Good for 0-50°C temperature readings ±2°C accuracy * No more than 1 Hz sampling rate (once every second) * Body size 15.5mm x 12mm x 5.5mm * 4 pins with 0.1" spacing DHT22 * Low cost * 3 to 5V power and I/O * 2.5mA max current use during conversion (while requesting data) * Good for 0-100% humidity readings with 2-5% accuracy * Good for -40 to 125°C temperature readings ±0.5°C accuracy * No more than 0.5 Hz sampling rate (once every 2 seconds) * Body size 15.1mm x 25mm x 7.7mm * 4 pins with 0.1" spacing == Connection == Likewise, it is fairly easy to connect up to the DHT sensors. They have four pins # VCC (3 to 5V power) # Data out # Not connected # Ground Simply ignore pin 3, it is not used. You will want to place a 10K resistor between VCC and the data pin, to act as a medium-strength pull up on the data line. The data out can be connected to any port pin of the ATmega, i.e. PA0 as listed in the pinning example: ifdef(`conf_DHT', `dnl pin(DHT, PA0, INPUT) ') == Configuration == Ethersex polls the sensors every n seconds. The advantage of this feature is that the reading opererates without any noticeable lags. Also it is easier to have multiple applications requesting sensor information since more request will not increase traffic. | | I/O ---> ... [*] Humidity & temperature sensors ---> ... [*] DHT 11/22 ---> | | (DHT11) Sensor type | | (30) Time between polling in 1s steps | | --- Debugging Flags | | [*] DHT == [[ECMD]] == IRMP implements an [[ECMD]] interface for reading humidity and temperature values. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == [[Category:Sensors]] 63da912234168ad41b2018745fcf1c1b9e1f0086 917 916 2013-03-05T06:40:58Z GooPie4o 265 wikitext text/x-wiki {{i18n|DHT}} {{Module |NAME=DHT |MENUCONFIG={{I/O}}->Humidity & temperature sensors->DHT 11/22 |STATUS={{Experimental}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/dht https://github.com/ethersex/ethersex/tree/master/hardware/dht] }} ==== DHT11/DHT21/DHT22 etc. Temperature & Humidity sensors ==== These sensors are very basic and slow, but are great for hobbyists who want to do some basic data logging. The DHT sensors are made of two parts, a capacitive humidity sensor and a thermistor. There is also a very basic chip inside that does some analog to digital conversion and spits out a digital signal with the temperature and humidity. ==== DHT11 vs DHT22 ==== There are two versions of the DHT sensor available, they look a bit similar and have the same pinout, but have different characteristics. Here are the specs: DHT11 * Ultra low cost * 3 to 5V power and I/O * 2.5mA max current use during conversion (while requesting data) * Good for 20-80% humidity readings with 5% accuracy * Good for 0-50°C temperature readings ±2°C accuracy * No more than 1 Hz sampling rate (once every second) * Body size 15.5mm x 12mm x 5.5mm * 4 pins with 0.1" spacing DHT22 * Low cost * 3 to 5V power and I/O * 2.5mA max current use during conversion (while requesting data) * Good for 0-100% humidity readings with 2-5% accuracy * Good for -40 to 125°C temperature readings ±0.5°C accuracy * No more than 0.5 Hz sampling rate (once every 2 seconds) * Body size 15.1mm x 25mm x 7.7mm * 4 pins with 0.1" spacing == Connection == Likewise, it is fairly easy to connect up to the DHT sensors. They have four pins # VCC (3 to 5V power) # Data out # Not connected # Ground Simply ignore pin 3, it is not used. You will want to place a 10K resistor between VCC and the data pin, to act as a medium-strength pull up on the data line. The data out can be connected to any port pin of the ATmega, i.e. PA0 as listed in the pinning example: ifdef(`conf_DHT', `dnl pin(DHT, PA0, INPUT) ') == Configuration == Ethersex polls the sensors every n seconds. The advantage of this feature is that the reading opererates without any noticeable lags. Also it is easier to have multiple applications requesting sensor information since more request will not increase traffic. | | I/O ---> ... [*] Humidity & temperature sensors ---> ... [*] DHT 11/22 ---> | | (DHT11) Sensor type | | (30) Time between polling in 1s steps | | --- Debugging Flags | | [*] DHT == [[ECMD]] == DHT implements an [[ECMD]] interface for reading humidity and temperature values. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == [[Category:Sensors]] 2f0e3e2a52f02f9cf26e84634a792edd3899f98a 920 917 2013-03-05T09:36:52Z GooPie4o 265 wikitext text/x-wiki {{i18n|DHT}} {{Module |NAME=DHT |MENUCONFIG={{I/O}}->Humidity & temperature sensors->DHT 11/22 |STATUS={{Experimental}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/dht https://github.com/ethersex/ethersex/tree/master/hardware/dht] }} ==== DHT11/DHT21/DHT22 etc. Temperature & Humidity sensors ==== These sensors are very basic and slow, but are great for hobbyists who want to do some basic data logging. The DHT sensors are made of two parts, a capacitive humidity sensor and a thermistor. There is also a very basic chip inside that does some analog to digital conversion and spits out a digital signal with the temperature and humidity. ==== DHT11 vs DHT22 ==== There are two versions of the DHT sensor available, they look a bit similar and have the same pinout, but have different characteristics. Here are the specs: DHT11 * Ultra low cost * 3 to 5V power and I/O * 2.5mA max current use during conversion (while requesting data) * Good for 20-80% humidity readings with 5% accuracy * Good for 0-50°C temperature readings ±2°C accuracy * No more than 1 Hz sampling rate (once every second) * Body size 15.5mm x 12mm x 5.5mm * 4 pins with 0.1" spacing DHT22 * Low cost * 3 to 5V power and I/O * 2.5mA max current use during conversion (while requesting data) * Good for 0-100% humidity readings with 2-5% accuracy * Good for -40 to 125°C temperature readings ±0.5°C accuracy * No more than 0.5 Hz sampling rate (once every 2 seconds) * Body size 15.1mm x 25mm x 7.7mm * 4 pins with 0.1" spacing == Connection == Likewise, it is fairly easy to connect up to the DHT sensors. They have four pins # VCC (3 to 5V power) # Data out # Not connected # Ground Simply ignore pin 3, it is not used. You will want to place a 10K resistor between VCC and the data pin, to act as a medium-strength pull up on the data line. The data out can be connected to any port pin of the ATmega, i.e. PA0 as listed in the pinning example: ifdef(`conf_DHT', `dnl pin(DHT, PA0, INPUT) ') == Configuration == Ethersex polls the sensors every n seconds. The advantage of this feature is that the reading opererates without any noticeable lags. Also it is easier to have multiple applications requesting sensor information since more request will not increase traffic. | | I/O ---> ... [*] Humidity & temperature sensors ---> ... [*] DHT 11/22 ---> | | (DHT11) Sensor type | | (30) Time between polling in 1s steps | | --- Debugging Flags | | [*] DHT == [[ECMD]] == DHT implements an [[ECMD]] interface for reading humidity and temperature values. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == Humidity and temperature can be accessed on [[Controi6]] scripts via DHT_HUMIDITY and DHT_TEMPERATURE keywords. The values returnd are fixed point integers including one decimal. The following example calculates and outputs the dew point on a LCD one every minute. <source lang="text"> #include <math.h> CONTROL_START THREAD(read_dht) ON ONCE CLOCK_MIN == 0 DO float a = 17.271; float b = 237.7; float temperatur = (a * DHT_TEMPERATURE) / (b + DHT_TEMPERATURE) + log(DHT_HUMIDITY/100); float taupunkt = (b * temperatur) / (a - temperatur); hd44780_clear(); hd44780_home(); hd44780_printf_P("Taupunkt: %f", taupunkt); END THREAD_END(read_dht) ON STARTUP DO THREAD_START(read_dht); END CONTROL_END </source> [[Category:Sensors]] b3b11a25893004c7dc1daec609c92c36870428a0 921 920 2013-03-05T09:37:37Z GooPie4o 265 wikitext text/x-wiki {{i18n|DHT}} {{Module |NAME=DHT |MENUCONFIG={{I/O}}->Humidity & temperature sensors->DHT 11/22 |STATUS={{Experimental}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/dht https://github.com/ethersex/ethersex/tree/master/hardware/dht] }} ==== DHT11/DHT21/DHT22 etc. Temperature & Humidity sensors ==== These sensors are very basic and slow, but are great for hobbyists who want to do some basic data logging. The DHT sensors are made of two parts, a capacitive humidity sensor and a thermistor. There is also a very basic chip inside that does some analog to digital conversion and spits out a digital signal with the temperature and humidity. ==== DHT11 vs DHT22 ==== There are two versions of the DHT sensor available, they look a bit similar and have the same pinout, but have different characteristics. Here are the specs: DHT11 * Ultra low cost * 3 to 5V power and I/O * 2.5mA max current use during conversion (while requesting data) * Good for 20-80% humidity readings with 5% accuracy * Good for 0-50°C temperature readings ±2°C accuracy * No more than 1 Hz sampling rate (once every second) * Body size 15.5mm x 12mm x 5.5mm * 4 pins with 0.1" spacing DHT22 * Low cost * 3 to 5V power and I/O * 2.5mA max current use during conversion (while requesting data) * Good for 0-100% humidity readings with 2-5% accuracy * Good for -40 to 125°C temperature readings ±0.5°C accuracy * No more than 0.5 Hz sampling rate (once every 2 seconds) * Body size 15.1mm x 25mm x 7.7mm * 4 pins with 0.1" spacing == Connection == Likewise, it is fairly easy to connect up to the DHT sensors. They have four pins # VCC (3 to 5V power) # Data out # Not connected # Ground Simply ignore pin 3, it is not used. You will want to place a 10K resistor between VCC and the data pin, to act as a medium-strength pull up on the data line. The data out can be connected to any port pin of the ATmega, i.e. PA0 as listed in the pinning example: ifdef(`conf_DHT', `dnl pin(DHT, PA0, INPUT) ') == Configuration == Ethersex polls the sensors every n seconds. The advantage of this feature is that the reading opererates without any noticeable lags. Also it is easier to have multiple applications requesting sensor information since more request will not increase traffic. | | I/O ---> ... [*] Humidity & temperature sensors ---> ... [*] DHT 11/22 ---> | | (DHT11) Sensor type | | (30) Time between polling in 1s steps | | --- Debugging Flags | | [*] DHT == [[ECMD]] == DHT implements an [[ECMD]] interface for reading humidity and temperature values. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == Humidity and temperature can be accessed on [[Controi6]] scripts via DHT_HUMIDITY and DHT_TEMPERATURE keywords. The values returnd are fixed point integers including one decimal. The following example calculates and outputs the dew point on a LCD one every minute. <source lang="text"> #include <math.h> CONTROL_START THREAD(read_dht) ON ONCE CLOCK_MIN == 0 DO float a = 17.271; float b = 237.7; float temperatur = (a * DHT_TEMPERATURE) / (b + DHT_TEMPERATURE) + log(DHT_HUMIDITY/100); float taupunkt = (b * temperatur) / (a - temperatur); hd44780_clear(); hd44780_home(); hd44780_printf_P("Taupunkt: %f", taupunkt); END THREAD_END(read_dht) ON STARTUP DO THREAD_START(read_dht); END CONTROL_END </source> [[Category:Sensors]] ddb10d71a32f1828c05c179d1f0cacf917310d1b 922 921 2013-03-05T09:38:29Z GooPie4o 265 /* Control6 */ wikitext text/x-wiki {{i18n|DHT}} {{Module |NAME=DHT |MENUCONFIG={{I/O}}->Humidity & temperature sensors->DHT 11/22 |STATUS={{Experimental}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/dht https://github.com/ethersex/ethersex/tree/master/hardware/dht] }} ==== DHT11/DHT21/DHT22 etc. Temperature & Humidity sensors ==== These sensors are very basic and slow, but are great for hobbyists who want to do some basic data logging. The DHT sensors are made of two parts, a capacitive humidity sensor and a thermistor. There is also a very basic chip inside that does some analog to digital conversion and spits out a digital signal with the temperature and humidity. ==== DHT11 vs DHT22 ==== There are two versions of the DHT sensor available, they look a bit similar and have the same pinout, but have different characteristics. Here are the specs: DHT11 * Ultra low cost * 3 to 5V power and I/O * 2.5mA max current use during conversion (while requesting data) * Good for 20-80% humidity readings with 5% accuracy * Good for 0-50°C temperature readings ±2°C accuracy * No more than 1 Hz sampling rate (once every second) * Body size 15.5mm x 12mm x 5.5mm * 4 pins with 0.1" spacing DHT22 * Low cost * 3 to 5V power and I/O * 2.5mA max current use during conversion (while requesting data) * Good for 0-100% humidity readings with 2-5% accuracy * Good for -40 to 125°C temperature readings ±0.5°C accuracy * No more than 0.5 Hz sampling rate (once every 2 seconds) * Body size 15.1mm x 25mm x 7.7mm * 4 pins with 0.1" spacing == Connection == Likewise, it is fairly easy to connect up to the DHT sensors. They have four pins # VCC (3 to 5V power) # Data out # Not connected # Ground Simply ignore pin 3, it is not used. You will want to place a 10K resistor between VCC and the data pin, to act as a medium-strength pull up on the data line. The data out can be connected to any port pin of the ATmega, i.e. PA0 as listed in the pinning example: ifdef(`conf_DHT', `dnl pin(DHT, PA0, INPUT) ') == Configuration == Ethersex polls the sensors every n seconds. The advantage of this feature is that the reading opererates without any noticeable lags. Also it is easier to have multiple applications requesting sensor information since more request will not increase traffic. | | I/O ---> ... [*] Humidity & temperature sensors ---> ... [*] DHT 11/22 ---> | | (DHT11) Sensor type | | (30) Time between polling in 1s steps | | --- Debugging Flags | | [*] DHT == [[ECMD]] == DHT implements an [[ECMD]] interface for reading humidity and temperature values. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == Humidity and temperature can be accessed on [[Control6]] scripts via DHT_HUMIDITY and DHT_TEMPERATURE keywords. The values returnd are fixed point integers including one decimal. The following example calculates and outputs the dew point on a LCD one every minute. <source lang="text"> #include <math.h> CONTROL_START THREAD(read_dht) ON ONCE CLOCK_MIN == 0 DO float a = 17.271; float b = 237.7; float temperatur = (a * DHT_TEMPERATURE) / (b + DHT_TEMPERATURE) + log(DHT_HUMIDITY/100); float taupunkt = (b * temperatur) / (a - temperatur); hd44780_clear(); hd44780_home(); hd44780_printf_P("Taupunkt: %f", taupunkt); END THREAD_END(read_dht) ON STARTUP DO THREAD_START(read_dht); END CONTROL_END </source> [[Category:Sensors]] 27d486ea8dc2daddb73d5a559bf93c8b05913a87 923 922 2013-03-05T09:39:02Z GooPie4o 265 /* Control6 */ wikitext text/x-wiki {{i18n|DHT}} {{Module |NAME=DHT |MENUCONFIG={{I/O}}->Humidity & temperature sensors->DHT 11/22 |STATUS={{Experimental}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/dht https://github.com/ethersex/ethersex/tree/master/hardware/dht] }} ==== DHT11/DHT21/DHT22 etc. Temperature & Humidity sensors ==== These sensors are very basic and slow, but are great for hobbyists who want to do some basic data logging. The DHT sensors are made of two parts, a capacitive humidity sensor and a thermistor. There is also a very basic chip inside that does some analog to digital conversion and spits out a digital signal with the temperature and humidity. ==== DHT11 vs DHT22 ==== There are two versions of the DHT sensor available, they look a bit similar and have the same pinout, but have different characteristics. Here are the specs: DHT11 * Ultra low cost * 3 to 5V power and I/O * 2.5mA max current use during conversion (while requesting data) * Good for 20-80% humidity readings with 5% accuracy * Good for 0-50°C temperature readings ±2°C accuracy * No more than 1 Hz sampling rate (once every second) * Body size 15.5mm x 12mm x 5.5mm * 4 pins with 0.1" spacing DHT22 * Low cost * 3 to 5V power and I/O * 2.5mA max current use during conversion (while requesting data) * Good for 0-100% humidity readings with 2-5% accuracy * Good for -40 to 125°C temperature readings ±0.5°C accuracy * No more than 0.5 Hz sampling rate (once every 2 seconds) * Body size 15.1mm x 25mm x 7.7mm * 4 pins with 0.1" spacing == Connection == Likewise, it is fairly easy to connect up to the DHT sensors. They have four pins # VCC (3 to 5V power) # Data out # Not connected # Ground Simply ignore pin 3, it is not used. You will want to place a 10K resistor between VCC and the data pin, to act as a medium-strength pull up on the data line. The data out can be connected to any port pin of the ATmega, i.e. PA0 as listed in the pinning example: ifdef(`conf_DHT', `dnl pin(DHT, PA0, INPUT) ') == Configuration == Ethersex polls the sensors every n seconds. The advantage of this feature is that the reading opererates without any noticeable lags. Also it is easier to have multiple applications requesting sensor information since more request will not increase traffic. | | I/O ---> ... [*] Humidity & temperature sensors ---> ... [*] DHT 11/22 ---> | | (DHT11) Sensor type | | (30) Time between polling in 1s steps | | --- Debugging Flags | | [*] DHT == [[ECMD]] == DHT implements an [[ECMD]] interface for reading humidity and temperature values. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == Humidity and temperature can be accessed in [[Control6]] scripts through the DHT_HUMIDITY and DHT_TEMPERATURE keywords. The values returnd are fixed point integers including one decimal. The following example calculates and outputs the dew point on a LCD one every minute. <source lang="text"> #include <math.h> CONTROL_START THREAD(read_dht) ON ONCE CLOCK_MIN == 0 DO float a = 17.271; float b = 237.7; float temperatur = (a * DHT_TEMPERATURE) / (b + DHT_TEMPERATURE) + log(DHT_HUMIDITY/100); float taupunkt = (b * temperatur) / (a - temperatur); hd44780_clear(); hd44780_home(); hd44780_printf_P("Taupunkt: %f", taupunkt); END THREAD_END(read_dht) ON STARTUP DO THREAD_START(read_dht); END CONTROL_END </source> [[Category:Sensors]] 38cc07bdd689782f73035b5d613c73a55c296390 924 923 2013-03-05T09:39:41Z GooPie4o 265 /* Control6 */ wikitext text/x-wiki {{i18n|DHT}} {{Module |NAME=DHT |MENUCONFIG={{I/O}}->Humidity & temperature sensors->DHT 11/22 |STATUS={{Experimental}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/dht https://github.com/ethersex/ethersex/tree/master/hardware/dht] }} ==== DHT11/DHT21/DHT22 etc. Temperature & Humidity sensors ==== These sensors are very basic and slow, but are great for hobbyists who want to do some basic data logging. The DHT sensors are made of two parts, a capacitive humidity sensor and a thermistor. There is also a very basic chip inside that does some analog to digital conversion and spits out a digital signal with the temperature and humidity. ==== DHT11 vs DHT22 ==== There are two versions of the DHT sensor available, they look a bit similar and have the same pinout, but have different characteristics. Here are the specs: DHT11 * Ultra low cost * 3 to 5V power and I/O * 2.5mA max current use during conversion (while requesting data) * Good for 20-80% humidity readings with 5% accuracy * Good for 0-50°C temperature readings ±2°C accuracy * No more than 1 Hz sampling rate (once every second) * Body size 15.5mm x 12mm x 5.5mm * 4 pins with 0.1" spacing DHT22 * Low cost * 3 to 5V power and I/O * 2.5mA max current use during conversion (while requesting data) * Good for 0-100% humidity readings with 2-5% accuracy * Good for -40 to 125°C temperature readings ±0.5°C accuracy * No more than 0.5 Hz sampling rate (once every 2 seconds) * Body size 15.1mm x 25mm x 7.7mm * 4 pins with 0.1" spacing == Connection == Likewise, it is fairly easy to connect up to the DHT sensors. They have four pins # VCC (3 to 5V power) # Data out # Not connected # Ground Simply ignore pin 3, it is not used. You will want to place a 10K resistor between VCC and the data pin, to act as a medium-strength pull up on the data line. The data out can be connected to any port pin of the ATmega, i.e. PA0 as listed in the pinning example: ifdef(`conf_DHT', `dnl pin(DHT, PA0, INPUT) ') == Configuration == Ethersex polls the sensors every n seconds. The advantage of this feature is that the reading opererates without any noticeable lags. Also it is easier to have multiple applications requesting sensor information since more request will not increase traffic. | | I/O ---> ... [*] Humidity & temperature sensors ---> ... [*] DHT 11/22 ---> | | (DHT11) Sensor type | | (30) Time between polling in 1s steps | | --- Debugging Flags | | [*] DHT == [[ECMD]] == DHT implements an [[ECMD]] interface for reading humidity and temperature values. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == Humidity and temperature can be accessed in [[Control6]] scripts through the DHT_HUMIDITY and DHT_TEMPERATURE keywords. The values returnd are fixed point integers including one decimal. The following example calculates and outputs the dew point on a LCD once every minute. <source lang="text"> #include <math.h> CONTROL_START THREAD(read_dht) ON ONCE CLOCK_MIN == 0 DO float a = 17.271; float b = 237.7; float temperatur = (a * DHT_TEMPERATURE) / (b + DHT_TEMPERATURE) + log(DHT_HUMIDITY/100); float taupunkt = (b * temperatur) / (a - temperatur); hd44780_clear(); hd44780_home(); hd44780_printf_P("Taupunkt: %f", taupunkt); END THREAD_END(read_dht) ON STARTUP DO THREAD_START(read_dht); END CONTROL_END </source> [[Category:Sensors]] 72652af19f0ce2cd9dea14c57771c237edc7f131 925 924 2013-03-05T15:14:03Z GooPie4o 265 /* Control6 */ wikitext text/x-wiki {{i18n|DHT}} {{Module |NAME=DHT |MENUCONFIG={{I/O}}->Humidity & temperature sensors->DHT 11/22 |STATUS={{Experimental}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/dht https://github.com/ethersex/ethersex/tree/master/hardware/dht] }} ==== DHT11/DHT21/DHT22 etc. Temperature & Humidity sensors ==== These sensors are very basic and slow, but are great for hobbyists who want to do some basic data logging. The DHT sensors are made of two parts, a capacitive humidity sensor and a thermistor. There is also a very basic chip inside that does some analog to digital conversion and spits out a digital signal with the temperature and humidity. ==== DHT11 vs DHT22 ==== There are two versions of the DHT sensor available, they look a bit similar and have the same pinout, but have different characteristics. Here are the specs: DHT11 * Ultra low cost * 3 to 5V power and I/O * 2.5mA max current use during conversion (while requesting data) * Good for 20-80% humidity readings with 5% accuracy * Good for 0-50°C temperature readings ±2°C accuracy * No more than 1 Hz sampling rate (once every second) * Body size 15.5mm x 12mm x 5.5mm * 4 pins with 0.1" spacing DHT22 * Low cost * 3 to 5V power and I/O * 2.5mA max current use during conversion (while requesting data) * Good for 0-100% humidity readings with 2-5% accuracy * Good for -40 to 125°C temperature readings ±0.5°C accuracy * No more than 0.5 Hz sampling rate (once every 2 seconds) * Body size 15.1mm x 25mm x 7.7mm * 4 pins with 0.1" spacing == Connection == Likewise, it is fairly easy to connect up to the DHT sensors. They have four pins # VCC (3 to 5V power) # Data out # Not connected # Ground Simply ignore pin 3, it is not used. You will want to place a 10K resistor between VCC and the data pin, to act as a medium-strength pull up on the data line. The data out can be connected to any port pin of the ATmega, i.e. PA0 as listed in the pinning example: ifdef(`conf_DHT', `dnl pin(DHT, PA0, INPUT) ') == Configuration == Ethersex polls the sensors every n seconds. The advantage of this feature is that the reading opererates without any noticeable lags. Also it is easier to have multiple applications requesting sensor information since more request will not increase traffic. | | I/O ---> ... [*] Humidity & temperature sensors ---> ... [*] DHT 11/22 ---> | | (DHT11) Sensor type | | (30) Time between polling in 1s steps | | --- Debugging Flags | | [*] DHT == [[ECMD]] == DHT implements an [[ECMD]] interface for reading humidity and temperature values. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == Humidity and temperature can be accessed in [[Control6]] scripts through the DHT_HUMIDITY and DHT_TEMPERATURE keywords. The values returnd are fixed point integers including one decimal. The following example calculates and outputs the dew point on a LCD once every minute. <source lang="text"> #include <math.h> CONTROL_START THREAD(read_dht) ON ONCE CLOCK_SEC == 0 DO float a = 17.271; float b = 237.7; float temperatur = (a * DHT_TEMPERATURE) / (b + DHT_TEMPERATURE) + log(DHT_HUMIDITY/100); float taupunkt = (b * temperatur) / (a - temperatur); hd44780_clear(); hd44780_home(); hd44780_printf_P("Taupunkt: %f", taupunkt); END THREAD_END(read_dht) ON STARTUP DO THREAD_START(read_dht); END CONTROL_END </source> [[Category:Sensors]] ab95347acf2fc23334da4c02016d7a519ce78e03 0 342 907 2013-03-04T18:28:50Z GooPie4o 265 Created page with "{{i18n|SHT}} {{Module |NAME=DHT |MENUCONFIG=I/O->Humidity & temperature sensors->SHT 1x/7x |STATUS={{Stable}} |PINNING=yes |ECMD=yes |CONTROL6=no |DEPENDS= |REQUIRES= |CODE=[http…" wikitext text/x-wiki {{i18n|SHT}} {{Module |NAME=DHT |MENUCONFIG=I/O->Humidity & temperature sensors->SHT 1x/7x |STATUS={{Stable}} |PINNING=yes |ECMD=yes |CONTROL6=no |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/sht https://github.com/ethersex/ethersex/tree/master/hardware/sht] }} [[Category:Sensors]] a84552abfac9f6eaad55d3a333ad12db71c5e2c6 908 907 2013-03-04T18:34:47Z GooPie4o 265 wikitext text/x-wiki {{i18n|SHT}} {{Module |NAME=DHT |MENUCONFIG={{I/O}}->Humidity & temperature sensors->SHT 1x/7x |STATUS={{Stable}} |PINNING=yes |ECMD=yes |CONTROL6=no |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/sht https://github.com/ethersex/ethersex/tree/master/hardware/sht] }} [[Category:Sensors]] 38b675b5394b5cb7c92bc0639cfa5a92ce3253e5 912 908 2013-03-04T18:39:15Z GooPie4o 265 wikitext text/x-wiki {{i18n|SHT}} {{Module |NAME=DHT |MENUCONFIG={{I/O}}->Humidity & temperature sensors->SHT 1x/7x |STATUS={{Stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/sht https://github.com/ethersex/ethersex/tree/master/hardware/sht] }} [[Category:Sensors]] 71c41e45560b33daa9975049e556c5507804a629 0 32 910 84 2013-03-04T18:37:35Z GooPie4o 265 wikitext text/x-wiki {{i18n|RC5}} {{Module |NAME=RC5 |MENUCONFIG={{I/O}}->IR Receivers->RC5 |STATUS={{deprecated}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/rc5 https://github.com/ethersex/ethersex/tree/master/hardware/ir/rc5] }} RC5 is a code for infrared remote controlsdeveloped by Philips. An [[Ethersex]] system can receive and decode RC5 signals and transmit RC5 signals. The module is not maintained anymore. Please use [[IRMP]] instead. 81562bf1f5069867d8c5c8e02d67c0fc5bdbafa7 0 30 913 862 2013-03-04T18:45:26Z GooPie4o 265 wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR Receivers->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP ist eine Portierung des [http://www.mikrocontroller.net/articles/IRMP Infrarot-Multiprotokoll-Decoders] nach [[Ethersex]]. == Anschluss == Der Empfang der IR-Signale erfolgt durch einen Empfänger vom Typ TSOP1736 (oder ähnlich). Dieser kann an einem beliebigen Pin angeschlossen werden. Die Abfrage des Pins und die Dekodierung des IR-Protokolls erfolgt in einer ISR, die einen 8-Bit-Timer des ATMEGAs belegt. Beim Senden wird das Signal mit der Trägerfrequenz des jeweiligen IR-Protokolls über [[PWM_(Deutsch)|PWM]] moduliert. Dazu wird ein weiterer 8-Bit Timer des ATMEGAs (OC0/OC2) belegt. Auf dem '''[[Etherape_(Deutsch)|Etherrape]]'''-Board übernimmt ein [[NE555_(Deutsch)|NE555]] diese Funktion, d.h. die Option ''Use external modulator for sender'' ist zu aktivieren. Man spart einen Timer des [[AVR_(Deutsch)|AVR]] und ist auf eine Trägerfrequenz festgelegt. Beispiel für einen ATMega32 aus: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Bedeutung: * IRMP_RX - Pin an dem der IR-Empfänger angeschlossen ist * IRMP_USE_TIMER2 - benutze Timer2 für den Empfang, Timer0 für das Senden (undef = umgekehrt) * IRMP_RX_LOW_ACTIVE - der IR-Empfänger ist Low-Aktiv (undef = High-aktiv) * IRMP_RX_LED_LOW_ACTIVE - die Kontroll-LED des Empfängers ist gegen USS geschaltet (undef = gegen GND geschaltet) * IRMP_TX - Pin an dem der IR-Sender angschlossen ist (=Ausgang des Timer0 oder Timer2, vgl. IRMP_USE_TIMER2)<br>'''Achtung: 0A bzw 2A bei MCU mit A/B Kanal''' * IRMP_TX_LED_LOW_ACTIVE - die Kontroll-LED des Senders ist gegen USS geschaltet (undef = gegen GND geschaltet) == Konfiguration == Jedes unterstützte IR-Protokoll "verbrät" Speicher an Code. Deshalb sollte man nur die benötigten Protokolle auswählen. Eine detailierte Übersicht über die Protokolle gibt der [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail Artikel im Mikrocontroller Forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ --- Debugging Flags │ │ [ ] IRMP IRMP dekodiert auch das RC5-Protokoll, so dass der separat in [[Ethersex_(Deutsch)|Ethersex]] enthaltene [[RC5_(Deutsch)|RC5]]-Dekoder nicht länger benötigt wird. == [[ECMD_(Deutsch)|ECMD]] == IRMP implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle zum Auslesen empfangener und dekodierter IR-Kommandos und zum Senden von IR-Kommandos. Siehe [[ECMD_Reference|ECMD Referenz]]. == [[Control6_(Deutsch)|Control6]] == === Ausgabe empfangener IR-Zeichen via [[SYSLOG_(Deutsch)|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> Mit IRMP_READ wird auf empfangenen IR-Code geprüft und dieser in die Variablen IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND und IRMP_FLAGS gespeichert. Rückgabewerte größer Null signalisieren die Gültigkeit der Variablen. Bei IRMP_FLAGS=1 handelt es sich um eine Wiederholung. === Steuern von [[StellaLight_(Deutsch)|Stella]]/Pins durch IR-Zeichen === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> Das Script schaltet den Stella Channel 0 auf 255 oder auf 0, die Fernbedienung ist hier eine Denon (Protocol 8). Mit ''include'' wurde dem Script der Zugriff auf die Stellasourcen gestattet.<br> Statt ''"stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255);"'' kann auch ''"PIN_SET(LED)"'' und ''"PIN_CLEAR(LED)"'' verwendet werden ([[Named_PIN_(Deutsch)|Named PIN]]). === Senden von IR-Zeichen === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 * no tx support yet dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON * no tx support yet dnl 31 = BOSE dnl 32 = A1TVBOX IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Kommando 5678 an Gerät 1234 wird mit einer Wiederholung im NEC-Protokoll gesendet. 5c55705acd2fdb9ed6978c0747f70eeee877d98a 0 29 914 870 2013-03-04T18:46:39Z GooPie4o 265 wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR Receivers->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP is a port of the [http://www.mikrocontroller.net/articles/IRMP infrared multi-protocol decoder] for [[Ethersex]]. == Connection == The reception of IR signals is performed by a receiver TSOP1736 type (or similar). This may be connected to any pin. The interrogation of the pins and the decoding of the IR protocol is done in an ISR, which occupies one 8-bit timer of the ATmegas. When sending the signal with the carrier frequency of the respective IR Protocol is [[PWM]] modulated. This is another 8-bit timer of the ATmegas (OC0/OC2) is demonstrated. On the [[Etherrape]] board takes a [[NE555]] this function, ie the option ''Use external modulator for the transmitter'' is activated. It saves a timer on the [[AVR]] is set at a carrier frequency. Example of a ATMega32 from: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Meaning: * IRMP_RX - pin the IR receiver is connected to * IRMP_USE_TIMER2 - use Timer2 for receiver, Timer0 for sender (undef = reversed) * IRMP_RX_LOW_ACTIVE - the IR receiver is low-active (undef = high-active) * IRMP_RX_LED_LOW_ACTIVE - the control LED of the receiver is switched to USS (undef = switched to GND) * IRMP_TX - pin the IR sender is connected to (=output of Timer0 or Timer2, see IRMP_USE_TIMER2)<br>'''Caution: 0A to 2A if MCU with A / B channel''' * IRMP_TX_LED_LOW_ACTIVE - the control LED of the sender is switched to USS (undef = switched to GND) == Configuration == Each supported IR protocol occupies memory of code. Therefore, one should select only the required protocols. A detailed overview of the protocols are the [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail article in the mikrocontroller forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ --- Debugging Flags │ │ [ ] IRMP IRMP also decodes the RC5 protocol, so that the separately [[Ethersex]] contained [[RC5]] decoder is not needed any longer. == [[ECMD]] == IRMP implements a [[ECMD]] interface for reading received and decoded IR commands and send IR commands. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == === Output received characters via [[SYSLOG|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> IRMP_READ checks for received IR code and stores it in the variables IRMP_PROTOCOL, IRMP_ADDRESS, and IRMP_COMMAND IRMP_FLAGS. Return values ​​greater than zero indicate the validity of the variables. If IRMP_FLAGS = 1 it is a repetition. === Control of [[StellaLight|Stella]]/Pins by IR commands === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> The script switches the Stella channel 0 to 255 or 0, the remote control is a Denon (Protocol 8). With ''include'' access to the Stella sources granted.<br> Instead of ''"stella_setValue (STELLA_SET_IMMEDIATELY, 0, 255);"'' ''"PIN_SET (LED)"'' and ''"PIN_CLEAR (LED)"'' can be used ([[Named_PIN|named pin]]). |Named PIN]]). === Send IR commands === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON dnl 31 = BOSE dnl 32 = A1TVBOX IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Command 5678 to device 1234 will be send with one repetition using the NEC protocol. b95020eda43862fcd0870cca496b3a33398174a4 915 914 2013-03-05T06:30:07Z GooPie4o 265 wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR Receivers->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP is a port of the [http://www.mikrocontroller.net/articles/IRMP infrared multi-protocol decoder] for [[Ethersex]]. == Connection == The reception of IR signals is performed by a receiver TSOP1736 type (or similar). This may be connected to any pin. The interrogation of the pins and the decoding of the IR protocol is done in an ISR, which occupies one 8-bit timer of the ATmegas. When sending the signal with the carrier frequency of the respective IR Protocol is [[PWM]] modulated. This is another 8-bit timer of the ATmegas (OC0/OC2) is demonstrated. On the [[Etherrape]] board takes a [[NE555]] this function, ie the option ''Use external modulator for the transmitter'' is activated. It saves a timer on the [[AVR]] is set at a carrier frequency. Example of a ATMega32 from: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Meaning: * IRMP_RX - pin the IR receiver is connected to * IRMP_USE_TIMER2 - use Timer2 for receiver, Timer0 for sender (undef = reversed) * IRMP_RX_LOW_ACTIVE - the IR receiver is low-active (undef = high-active) * IRMP_RX_LED_LOW_ACTIVE - the control LED of the receiver is switched to USS (undef = switched to GND) * IRMP_TX - pin the IR sender is connected to (=output of Timer0 or Timer2, see IRMP_USE_TIMER2)<br>'''Caution: 0A to 2A if MCU with A / B channel''' * IRMP_TX_LED_LOW_ACTIVE - the control LED of the sender is switched to USS (undef = switched to GND) == Configuration == Each supported IR protocol occupies memory of code. Therefore, one should select only the required protocols. A detailed overview of the protocols are the [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail article in the mikrocontroller forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ --- Debugging Flags │ │ [ ] IRMP IRMP also decodes the RC5 protocol, so that the separately [[Ethersex]] contained [[RC5]] decoder is not needed any longer. == [[ECMD]] == IRMP implements an [[ECMD]] interface for reading received and decoded IR commands and send IR commands. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == === Output received characters via [[SYSLOG|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> IRMP_READ checks for received IR code and stores it in the variables IRMP_PROTOCOL, IRMP_ADDRESS, and IRMP_COMMAND IRMP_FLAGS. Return values ​​greater than zero indicate the validity of the variables. If IRMP_FLAGS = 1 it is a repetition. === Control of [[StellaLight|Stella]]/Pins by IR commands === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> The script switches the Stella channel 0 to 255 or 0, the remote control is a Denon (Protocol 8). With ''include'' access to the Stella sources granted.<br> Instead of ''"stella_setValue (STELLA_SET_IMMEDIATELY, 0, 255);"'' ''"PIN_SET (LED)"'' and ''"PIN_CLEAR (LED)"'' can be used ([[Named_PIN|named pin]]). |Named PIN]]). === Send IR commands === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON dnl 31 = BOSE dnl 32 = A1TVBOX IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Command 5678 to device 1234 will be send with one repetition using the NEC protocol. 36b8c3b3f568bae2dd94b7ef896146a62c29ef1a 0 189 918 871 2013-03-05T06:43:56Z GooPie4o 265 /* Polling Modus */ wikitext text/x-wiki {{i18n|Onewire}} {{Module |NAME=Onewire |MENUCONFIG={{I/O}}->Onewire support |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] [[HTTPD]] (optional) [[SNMP]] (optional) |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} Ethersex kann 1-wire Temperatursensoren mit [[ECMD]] auflisten und abfragen. Es wird eine reine Softwareimplementierung des Protokolls benutzt, was keine weiteren Hardware erfordert, als die Temperatursensoren selbst. = Pinning = In der Standardkonfiguration liegt der Datapin des Buses auf PD6 (kann z.B. in der pinning/hardware/netio.m4 oder pinning/hardware/etherrape.m4 geändert werden). Die Definition der Pins erfolgt mit: <source lang=c> ONEWIRE_PORT_RANGE(PXn, PXm) </source> wobei PXn und PNm Pins auf PORTX sind. Jeder Pin zwischen und einschließlich PXn und PXm bildet einen eingenständigen Onewire Bus. Du kannst bis zu acht Busse auf einem PORT definieren (alle Busse müssen auf dem selben PORT liegen!) == Beispiele == Wenn Du nur einen einzigen Bus benötigst, definiere den Bereich wie folgt: '''PORTD: PIN2''' <source lang=c> ONEWIRE_PORT_RANGE(PD2, PD2) </source> Für drei Busse würde das ganze etwa so aussehen: '''PORTD: PIN2, PIN3, PIN4''' <source lang=c> ONEWIRE_PORT_RANGE(PD2, PD4) </source> = Polling Modus = │ │ [*] Onewire Polling │ │ │ │ (375) Time between discoveries in 1s steps │ │ │ │ (12) Time between polling in 1s steps │ │ │ │ [*] ECMD 1w list with values │ │ │ │ (10) Maximum sensor count │ │ Im Polling-Modus werden die Sensoren im Hintergrund abgefragt, so dass die Werte bei Bedarf direkt zur Verfügung stehen und nicht erst gewandelt bzw. eingelesen werden müssen. Der Intervall zwischen den Discoveries und zwischen den Abfragen der Werte kann getrennt eingestellt werden. Die Option '''ECMD 1w list with values''' bietet die Möglichkeit, die aktuellen Werte bei Aufruf von '''1w list''' mit ausgeben zu lassen. So können darauf folgende '''1w get''' Kommandos entfallen. Da zur Pufferung der Werte, ROM-Codes, etc. RAM-Speicher benötigt wird, muss per '''Maximum sensor count''' angegeben werden, für wie viele Sensoren Speicher reserviert wird. = Benennung von Sensoren = │ │ [*] Onewire naming support │ │ │ │ (10) Maximum sensor count │ │ Um den Sensoren sinnvolle Namen zu geben besteht die Möglichkeit im EEPROM eine entsprechende Zuweisungstabelle anzulegen (ROM-Code -> Name). Die Namen werden bei bei Aufruf von '''1w list''' mit ausgegeben. Dazu gibt es folgende ECMD Kommandos: 1w name list Auflistung der aktuellen Zuweisungen (Spalten: ID, ROM-Code, Name). Die ID bezeichnet die Position in der Zuweisungstabelle und kann u.a. dazu benutzt werden, Sensoren bei SNMP-Abfragen eindeutig zu referenzieren. 1w name set <ID> <ROM-Code> <Name> Erstellt einen entsprechenden Tabelleneintrag. 1w name clear <ID> Löscht die Felder eines Tabelleneintrags. 1w name save Speichert die aktuelle Tabelle im EEPROM = Unterstützte Hardware = Folgende 1-wire Hardware wird momentan durch Ethersex unterstützt: * DS1820 (Temperatursensor) * DS18B20 (Temperatursensor) * DS1822 (Temperatursensor) * DS2502 (EEPROM) * [[Onewire/DS2450 (Deutsch) | DS2450 (4 Kanal ADC)]] = Onewire Befehle = unter Linux als erstes netcat starten (hierbei natürlich die IP ggf modifizieren): netcat 192.168.0.15 2701 danach am prompt: 1w list Gibt eine Liste mit Hexcodes aller angeschlossenen und erkannten Onewire(tm) Sensoren aus. Bei aktiviertem Naming-Support wird (per TAB getrennt) zusätzlich der Name ausgegeben. Außerdem kann mit '''ECMD 1w list with values (ONEWIRE_ECMD_LIST_VALUE_SUPPORT)''' der aktuelle Temperaturwert mit ausgegeben werden. Dies erspart zusätzliche '''1w get''' Aufrufe, setzt allerding Polling-Support vorraus. 1w convert <hexcode> Veranlasst eine Temperaturmessung des addressierten Sensors, oder, wenn das Argument <hexcode> weggelassen wird, aller angeschlossener Sensoren. Im Polling-Modus wird dieses Kommando ignoriert. 1w get <hexcode> Gibt die gemessene Temperatur eines Sensors aus. = Einbindung in die [[HTTPD]]-Weboberfläche = Unter httpd/embed/ow.ht.m4, bzw httpd/embed/Xow.ht.m4 liegt eine Weboberflaeche, die alle Sensoren erkennt und ihre aktuelle Temperatur regelmässig per Ajax abfragt und anzeigt. Im Falle von Xow.ht.m4 wird sogar Graph der Temperatur mittels SVG gemalt. Um die Dateien einzubinden, muss man einfach bei aktiviertem Onewiresupport den Webserver und das Datei Inlining aktivieren. Die Dateien können dann unter ow.ht bzw. unter Xow.ht angezeigt werden. Das Beispiel zeigt die SVG-Version mit Naming-Support: [[File:onewire-svg.png]] = Anschluss AVR-NET-IO = Für das Pollin AVR-NET-IO Board können die Sensoren DS18S20+ , normal Betrieb [[File:netio-1wire_normal.png]] parasitären Modus [[File:netio-1wire.png]] Anmerkung: Wenn man beim Net-IO nicht alle Analogeingänge benötigt, lässt sich der 1-Wire-Bus auch an der Schraubklemme ADC1 ganz gut aufschalten. Vorteil ist, dass man gleich alle passenden Spannungen (GND, +5V) an den beiden nebenliegenden Schraubklemmen hat. Das Pinning muss dann entspechend in der kann in der Datei pinning/hardware/netio.m4 von PD6 auf PA4 geändert werden. Vorteil dieser Konfiguration ist, dass man den DB-25-Verbinder zum Anschluss der Relaisplatine K8IO von Pollin frei hat und den EXT Steckverbinder zum Anschluss eines LCD über ein 4bit-Interface nutzen kann, ohne die Erweiterungsplatine von Pollin zu benötigen. Pinbelegung: [[File:ds18s20-par-pinout.jpg]] = Anschluss Etherrape = Die Schaltung je nach parasitärem oder normalem Betriebsmodus kann aus der NetIO Skizze übernommen werden. Data liegt auf PORTD an Pin 7: PORTD +---+ |x x| |x X| <- Pin 7 |x x |x x| |x x| +---+ Direkt neben PORTD befinden sich 2 Pins mit GND und 5V als Beschriftung. GND kann als GND und 5V als Vcc genutzt werden. = Einbindung in [[Control6]] = Die Sensoren können mit '''ONEWIRE_GET(sensor-id)''' oder '''ONEWIRE_GET_BY_NAME(sensor-name)''' einfach abgefragt werden. Die Funktion führt automatisch ein ''convert'' aus, es sind also keine zwei Schritte erforderlich wie bei dem Zugriff über [[ECMD]]. Die Rückgabe erfolgt (analog der Funktion '''KTY_GET''') in Centigrad, also Temperatur * 10. Hier vielleicht ein kleines Beispiel, das die Daten per [[SYSLOG]] ausgibt sobald sich die Temperatur um mehr als ein Grad zur letzten Messung verändert hat. <pre> #include <stdlib.h> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO uint8_t sign = Temperatur<0; div_t res = div(abs(Temperatur),10); SYSLOG("temperature changed %S%d.%d",sign?PSTR("-"):PSTR(""),res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> = Abfrage per [[SNMP]] = Falls Polling-Support aktiviert wurde können die Sensorwerte per SNMP abgefragt werden. Mit Naming-Support stehen auch die Namen per SNMP zur Verfügung und die Index-Nummern sind fix auf die Position in der Namenstabelle festgelegt. Dies ist sehr hilfreich, um bestimmte Sensoren über den SNMP-Index anzusprechen. Es gibt folgende OIDs: * .1.3.6.1.4.1.39967.3.1.<idx> : ROM-Code des Sensors * .1.3.6.1.4.1.39967.3.2.<idx> : Sensor-Name (nur mit Naming-Support) * .1.3.6.1.4.1.39967.3.3.<idx> : Temperaturwert in Centigrad * .1.3.6.1.4.1.39967.3.4.<idx> : 0 = Sensor nicht vorhanden, 1 = Sensor vorhanden Hier ein Beispiel: <pre> # snmpwalk -Osn -c public -v 1 192.168.255.90 1.3.6.1.4.1.39967.3 .1.3.6.1.4.1.39967.3.1.0 = STRING: "1080cff6010800f9" .1.3.6.1.4.1.39967.3.1.1 = STRING: "10c8cff60108002d" .1.3.6.1.4.1.39967.3.1.2 = STRING: "1029f6dc0108002f" .1.3.6.1.4.1.39967.3.1.3 = STRING: "10f2d0f60108001c" .1.3.6.1.4.1.39967.3.1.4 = STRING: "105a17f70108001d" .1.3.6.1.4.1.39967.3.1.5 = STRING: "10b8d8f601080098" .1.3.6.1.4.1.39967.3.1.6 = STRING: "104dedf601080057" .1.3.6.1.4.1.39967.3.1.7 = STRING: "10011af701080027" .1.3.6.1.4.1.39967.3.1.8 = STRING: "0000000000000000" .1.3.6.1.4.1.39967.3.1.9 = STRING: "0000000000000000" .1.3.6.1.4.1.39967.3.2.0 = STRING: "kessel" .1.3.6.1.4.1.39967.3.2.1 = STRING: "warmwasser" .1.3.6.1.4.1.39967.3.2.2 = STRING: "aussen" .1.3.6.1.4.1.39967.3.2.3 = STRING: "speicher" .1.3.6.1.4.1.39967.3.2.4 = STRING: "heizung vl" .1.3.6.1.4.1.39967.3.2.5 = STRING: "heizung rl" .1.3.6.1.4.1.39967.3.2.6 = STRING: "boiler vl" .1.3.6.1.4.1.39967.3.2.7 = STRING: "boiler rl" .1.3.6.1.4.1.39967.3.2.8 = "" .1.3.6.1.4.1.39967.3.2.9 = "" .1.3.6.1.4.1.39967.3.3.0 = INTEGER: 334 .1.3.6.1.4.1.39967.3.3.1 = INTEGER: 467 .1.3.6.1.4.1.39967.3.3.2 = INTEGER: 127 .1.3.6.1.4.1.39967.3.3.3 = INTEGER: 185 .1.3.6.1.4.1.39967.3.3.4 = INTEGER: 318 .1.3.6.1.4.1.39967.3.3.5 = INTEGER: 269 .1.3.6.1.4.1.39967.3.3.6 = INTEGER: 366 .1.3.6.1.4.1.39967.3.3.7 = INTEGER: 291 .1.3.6.1.4.1.39967.3.3.8 = INTEGER: 0 .1.3.6.1.4.1.39967.3.3.9 = INTEGER: 0 .1.3.6.1.4.1.39967.3.4.0 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.1 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.2 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.3 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.4 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.5 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.6 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.7 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.8 = INTEGER: 0 .1.3.6.1.4.1.39967.3.4.9 = INTEGER: 0 </pre> = Codebeispiele = * [[Onewire/Example/PHP (Deutsch) | PHP]] * [[Onewire/Example/Perl (Deutsch) | Perl]] * [[Onewire/Example/Python | Python]] * [[Onewire/Example/Shell | sh/bash]] [[Category:Ethersex]] [[Category:StepByStep]] [[Category:Onewire]] = Bezugsquellen = * Laut Michael Schultz (k1w1) hat er immer DS1820 auf Lager und kann sie sehr günstig weiterverkaufen. Auch Mindermengen. Mail: ethersex [AT] keyb [DOT] de * und natürlich bei den üblichen Verdächtigen: Reichelt, Segor, Conrad ca9166393e5600a6fa6513d13e6309250c72eb34 919 918 2013-03-05T06:45:51Z GooPie4o 265 /* Bezugsquellen */ wikitext text/x-wiki {{i18n|Onewire}} {{Module |NAME=Onewire |MENUCONFIG={{I/O}}->Onewire support |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] [[HTTPD]] (optional) [[SNMP]] (optional) |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} Ethersex kann 1-wire Temperatursensoren mit [[ECMD]] auflisten und abfragen. Es wird eine reine Softwareimplementierung des Protokolls benutzt, was keine weiteren Hardware erfordert, als die Temperatursensoren selbst. = Pinning = In der Standardkonfiguration liegt der Datapin des Buses auf PD6 (kann z.B. in der pinning/hardware/netio.m4 oder pinning/hardware/etherrape.m4 geändert werden). Die Definition der Pins erfolgt mit: <source lang=c> ONEWIRE_PORT_RANGE(PXn, PXm) </source> wobei PXn und PNm Pins auf PORTX sind. Jeder Pin zwischen und einschließlich PXn und PXm bildet einen eingenständigen Onewire Bus. Du kannst bis zu acht Busse auf einem PORT definieren (alle Busse müssen auf dem selben PORT liegen!) == Beispiele == Wenn Du nur einen einzigen Bus benötigst, definiere den Bereich wie folgt: '''PORTD: PIN2''' <source lang=c> ONEWIRE_PORT_RANGE(PD2, PD2) </source> Für drei Busse würde das ganze etwa so aussehen: '''PORTD: PIN2, PIN3, PIN4''' <source lang=c> ONEWIRE_PORT_RANGE(PD2, PD4) </source> = Polling Modus = │ │ [*] Onewire Polling │ │ │ │ (375) Time between discoveries in 1s steps │ │ │ │ (12) Time between polling in 1s steps │ │ │ │ [*] ECMD 1w list with values │ │ │ │ (10) Maximum sensor count │ │ Im Polling-Modus werden die Sensoren im Hintergrund abgefragt, so dass die Werte bei Bedarf direkt zur Verfügung stehen und nicht erst gewandelt bzw. eingelesen werden müssen. Der Intervall zwischen den Discoveries und zwischen den Abfragen der Werte kann getrennt eingestellt werden. Die Option '''ECMD 1w list with values''' bietet die Möglichkeit, die aktuellen Werte bei Aufruf von '''1w list''' mit ausgeben zu lassen. So können darauf folgende '''1w get''' Kommandos entfallen. Da zur Pufferung der Werte, ROM-Codes, etc. RAM-Speicher benötigt wird, muss per '''Maximum sensor count''' angegeben werden, für wie viele Sensoren Speicher reserviert wird. = Benennung von Sensoren = │ │ [*] Onewire naming support │ │ │ │ (10) Maximum sensor count │ │ Um den Sensoren sinnvolle Namen zu geben besteht die Möglichkeit im EEPROM eine entsprechende Zuweisungstabelle anzulegen (ROM-Code -> Name). Die Namen werden bei bei Aufruf von '''1w list''' mit ausgegeben. Dazu gibt es folgende ECMD Kommandos: 1w name list Auflistung der aktuellen Zuweisungen (Spalten: ID, ROM-Code, Name). Die ID bezeichnet die Position in der Zuweisungstabelle und kann u.a. dazu benutzt werden, Sensoren bei SNMP-Abfragen eindeutig zu referenzieren. 1w name set <ID> <ROM-Code> <Name> Erstellt einen entsprechenden Tabelleneintrag. 1w name clear <ID> Löscht die Felder eines Tabelleneintrags. 1w name save Speichert die aktuelle Tabelle im EEPROM = Unterstützte Hardware = Folgende 1-wire Hardware wird momentan durch Ethersex unterstützt: * DS1820 (Temperatursensor) * DS18B20 (Temperatursensor) * DS1822 (Temperatursensor) * DS2502 (EEPROM) * [[Onewire/DS2450 (Deutsch) | DS2450 (4 Kanal ADC)]] = Onewire Befehle = unter Linux als erstes netcat starten (hierbei natürlich die IP ggf modifizieren): netcat 192.168.0.15 2701 danach am prompt: 1w list Gibt eine Liste mit Hexcodes aller angeschlossenen und erkannten Onewire(tm) Sensoren aus. Bei aktiviertem Naming-Support wird (per TAB getrennt) zusätzlich der Name ausgegeben. Außerdem kann mit '''ECMD 1w list with values (ONEWIRE_ECMD_LIST_VALUE_SUPPORT)''' der aktuelle Temperaturwert mit ausgegeben werden. Dies erspart zusätzliche '''1w get''' Aufrufe, setzt allerding Polling-Support vorraus. 1w convert <hexcode> Veranlasst eine Temperaturmessung des addressierten Sensors, oder, wenn das Argument <hexcode> weggelassen wird, aller angeschlossener Sensoren. Im Polling-Modus wird dieses Kommando ignoriert. 1w get <hexcode> Gibt die gemessene Temperatur eines Sensors aus. = Einbindung in die [[HTTPD]]-Weboberfläche = Unter httpd/embed/ow.ht.m4, bzw httpd/embed/Xow.ht.m4 liegt eine Weboberflaeche, die alle Sensoren erkennt und ihre aktuelle Temperatur regelmässig per Ajax abfragt und anzeigt. Im Falle von Xow.ht.m4 wird sogar Graph der Temperatur mittels SVG gemalt. Um die Dateien einzubinden, muss man einfach bei aktiviertem Onewiresupport den Webserver und das Datei Inlining aktivieren. Die Dateien können dann unter ow.ht bzw. unter Xow.ht angezeigt werden. Das Beispiel zeigt die SVG-Version mit Naming-Support: [[File:onewire-svg.png]] = Anschluss AVR-NET-IO = Für das Pollin AVR-NET-IO Board können die Sensoren DS18S20+ , normal Betrieb [[File:netio-1wire_normal.png]] parasitären Modus [[File:netio-1wire.png]] Anmerkung: Wenn man beim Net-IO nicht alle Analogeingänge benötigt, lässt sich der 1-Wire-Bus auch an der Schraubklemme ADC1 ganz gut aufschalten. Vorteil ist, dass man gleich alle passenden Spannungen (GND, +5V) an den beiden nebenliegenden Schraubklemmen hat. Das Pinning muss dann entspechend in der kann in der Datei pinning/hardware/netio.m4 von PD6 auf PA4 geändert werden. Vorteil dieser Konfiguration ist, dass man den DB-25-Verbinder zum Anschluss der Relaisplatine K8IO von Pollin frei hat und den EXT Steckverbinder zum Anschluss eines LCD über ein 4bit-Interface nutzen kann, ohne die Erweiterungsplatine von Pollin zu benötigen. Pinbelegung: [[File:ds18s20-par-pinout.jpg]] = Anschluss Etherrape = Die Schaltung je nach parasitärem oder normalem Betriebsmodus kann aus der NetIO Skizze übernommen werden. Data liegt auf PORTD an Pin 7: PORTD +---+ |x x| |x X| <- Pin 7 |x x |x x| |x x| +---+ Direkt neben PORTD befinden sich 2 Pins mit GND und 5V als Beschriftung. GND kann als GND und 5V als Vcc genutzt werden. = Einbindung in [[Control6]] = Die Sensoren können mit '''ONEWIRE_GET(sensor-id)''' oder '''ONEWIRE_GET_BY_NAME(sensor-name)''' einfach abgefragt werden. Die Funktion führt automatisch ein ''convert'' aus, es sind also keine zwei Schritte erforderlich wie bei dem Zugriff über [[ECMD]]. Die Rückgabe erfolgt (analog der Funktion '''KTY_GET''') in Centigrad, also Temperatur * 10. Hier vielleicht ein kleines Beispiel, das die Daten per [[SYSLOG]] ausgibt sobald sich die Temperatur um mehr als ein Grad zur letzten Messung verändert hat. <pre> #include <stdlib.h> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO uint8_t sign = Temperatur<0; div_t res = div(abs(Temperatur),10); SYSLOG("temperature changed %S%d.%d",sign?PSTR("-"):PSTR(""),res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> = Abfrage per [[SNMP]] = Falls Polling-Support aktiviert wurde können die Sensorwerte per SNMP abgefragt werden. Mit Naming-Support stehen auch die Namen per SNMP zur Verfügung und die Index-Nummern sind fix auf die Position in der Namenstabelle festgelegt. Dies ist sehr hilfreich, um bestimmte Sensoren über den SNMP-Index anzusprechen. Es gibt folgende OIDs: * .1.3.6.1.4.1.39967.3.1.<idx> : ROM-Code des Sensors * .1.3.6.1.4.1.39967.3.2.<idx> : Sensor-Name (nur mit Naming-Support) * .1.3.6.1.4.1.39967.3.3.<idx> : Temperaturwert in Centigrad * .1.3.6.1.4.1.39967.3.4.<idx> : 0 = Sensor nicht vorhanden, 1 = Sensor vorhanden Hier ein Beispiel: <pre> # snmpwalk -Osn -c public -v 1 192.168.255.90 1.3.6.1.4.1.39967.3 .1.3.6.1.4.1.39967.3.1.0 = STRING: "1080cff6010800f9" .1.3.6.1.4.1.39967.3.1.1 = STRING: "10c8cff60108002d" .1.3.6.1.4.1.39967.3.1.2 = STRING: "1029f6dc0108002f" .1.3.6.1.4.1.39967.3.1.3 = STRING: "10f2d0f60108001c" .1.3.6.1.4.1.39967.3.1.4 = STRING: "105a17f70108001d" .1.3.6.1.4.1.39967.3.1.5 = STRING: "10b8d8f601080098" .1.3.6.1.4.1.39967.3.1.6 = STRING: "104dedf601080057" .1.3.6.1.4.1.39967.3.1.7 = STRING: "10011af701080027" .1.3.6.1.4.1.39967.3.1.8 = STRING: "0000000000000000" .1.3.6.1.4.1.39967.3.1.9 = STRING: "0000000000000000" .1.3.6.1.4.1.39967.3.2.0 = STRING: "kessel" .1.3.6.1.4.1.39967.3.2.1 = STRING: "warmwasser" .1.3.6.1.4.1.39967.3.2.2 = STRING: "aussen" .1.3.6.1.4.1.39967.3.2.3 = STRING: "speicher" .1.3.6.1.4.1.39967.3.2.4 = STRING: "heizung vl" .1.3.6.1.4.1.39967.3.2.5 = STRING: "heizung rl" .1.3.6.1.4.1.39967.3.2.6 = STRING: "boiler vl" .1.3.6.1.4.1.39967.3.2.7 = STRING: "boiler rl" .1.3.6.1.4.1.39967.3.2.8 = "" .1.3.6.1.4.1.39967.3.2.9 = "" .1.3.6.1.4.1.39967.3.3.0 = INTEGER: 334 .1.3.6.1.4.1.39967.3.3.1 = INTEGER: 467 .1.3.6.1.4.1.39967.3.3.2 = INTEGER: 127 .1.3.6.1.4.1.39967.3.3.3 = INTEGER: 185 .1.3.6.1.4.1.39967.3.3.4 = INTEGER: 318 .1.3.6.1.4.1.39967.3.3.5 = INTEGER: 269 .1.3.6.1.4.1.39967.3.3.6 = INTEGER: 366 .1.3.6.1.4.1.39967.3.3.7 = INTEGER: 291 .1.3.6.1.4.1.39967.3.3.8 = INTEGER: 0 .1.3.6.1.4.1.39967.3.3.9 = INTEGER: 0 .1.3.6.1.4.1.39967.3.4.0 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.1 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.2 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.3 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.4 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.5 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.6 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.7 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.8 = INTEGER: 0 .1.3.6.1.4.1.39967.3.4.9 = INTEGER: 0 </pre> = Codebeispiele = * [[Onewire/Example/PHP (Deutsch) | PHP]] * [[Onewire/Example/Perl (Deutsch) | Perl]] * [[Onewire/Example/Python | Python]] * [[Onewire/Example/Shell | sh/bash]] [[Category:Ethersex]] [[Category:StepByStep]] [[Category:Onewire]] = Bezugsquellen = Laut Michael Schultz (k1w1) hat er immer DS1820 auf Lager und kann sie sehr günstig weiterverkaufen. Auch Mindermengen. Mail: ethersex [AT] keyb [DOT] de und natürlich bei den üblichen Verdächtigen: Reichelt, Segor, Conrad. 1970f47b629e1c2e1728ffb85fa6145208b7d3bc 14 343 927 2013-03-06T08:16:19Z GooPie4o 265 Created page with "RFM12 is a low costing ISM band FSK transceiver module implemented with unique PLL. It works signal ranges from 315/433/868/915MHZ bands. The SPI interface is used to communicate…" wikitext text/x-wiki RFM12 is a low costing ISM band FSK transceiver module implemented with unique PLL. It works signal ranges from 315/433/868/915MHZ bands. The SPI interface is used to communicate with microcontroller for parameter setting. 9407beba0332a72dc0685935d2cd9e655e0c537f 928 927 2013-03-06T08:16:54Z GooPie4o 265 wikitext text/x-wiki RFM12 is a low costing ISM band FSK transceiver module implemented with unique PLL. It works signal ranges from 315/433/868/915MHZ bands. e515b7fa3255b5892a66d8c1e646ee8d7b4fee21 6 344 929 2013-03-06T08:19:45Z GooPie4o 265 Interfacing RFM12 with ATmega. Taken from old Ethersex WIKU. wikitext text/x-wiki Interfacing RFM12 with ATmega. Taken from old Ethersex WIKU. 2d2d7dc3d9a6bafe63c551edb9882c71619ef045 0 340 930 898 2013-03-06T08:53:09Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 FSK}} {{Module |NAME=RFM12 FSK |MENUCONFIG=Network->IP over RFM12 (FSK transmitter) support |STATUS={{Stable}} |PINNING=yes |ECMD=no |CONTROL6=no |DEPENDS= |REQUIRES=UIP_SUPPORT |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} == Connection == [[Image:Anschluss_rfm12.png]] [[Category:RFM12]] de646369439c1bb1342b82784d3b6cfa825eaac0 931 930 2013-03-06T08:54:10Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 FSK}} {{Module |NAME=RFM12 FSK |MENUCONFIG=Network->IP over RFM12 (FSK transmitter) support |STATUS={{Stable}} |PINNING=yes |ECMD=no |CONTROL6=no |DEPENDS= |REQUIRES=UIP_SUPPORT |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} == Connection == [[Image:Rfm12 connection.png]] [[Category:RFM12]] 58854d8b1b885a855e606aca848929ef6c7e4348 932 931 2013-03-06T09:20:57Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 FSK}} {{Module |NAME=RFM12 FSK |MENUCONFIG=Network->IP over RFM12 (FSK transmitter) support |STATUS={{Stable}} |PINNING=yes |ECMD=no |CONTROL6=no |DEPENDS= |REQUIRES=UIP_SUPPORT |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} The default operating mode of the RFM12 is FSK. This mode is used to treat several Ethersex systems connect by radio with each other. Here, one of the systems can act as a router to connect to a wired network. == Connection == If you are using hardware SPI, which is the default, connect the RFM12 to the AVR as follows: [[Image:Rfm12 connection.png|640px]] The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12, PB0, OUTPUT) /* port the LEDS for rfm12 txrx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_USE_INT(2) The RFM12_USE_INT defines whether nRQ is connected to INT0, INT1 or INT2 of the ATmega. [[Category:RFM12]] 4b13a585dd2221687f7a0e59f146b76940983dad 933 932 2013-03-06T09:21:27Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 FSK}} {{Module |NAME=RFM12 FSK |MENUCONFIG=Network->IP over RFM12 (FSK transmitter) support |STATUS={{Stable}} |PINNING=yes |ECMD=no |CONTROL6=no |DEPENDS= |REQUIRES=UIP_SUPPORT |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} The default operating mode of the RFM12 is FSK. This mode is used to treat several Ethersex systems connect by radio with each other. Here, one of the systems can act as a router to connect to a wired network. == Connection == If you are using hardware SPI, which is the default, connect the RFM12 to the AVR as follows: [[Image:Rfm12 connection.png|640px]] The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12, PB0, OUTPUT) /* port the LEDS for rfm12 txrx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_USE_INT(2) The RFM12_USE_INT defines whether nRQ is connected to INT0, INT1 or INT2 of the ATmega. [[Category:RFM12]] 89b7bc1ae8083b07e93707582ea4e18023dd09f8 934 933 2013-03-06T09:22:59Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 FSK}} {{Module |NAME=RFM12 FSK |MENUCONFIG=Network->IP over RFM12 (FSK transmitter) support |STATUS={{Stable}} |PINNING=yes |ECMD=no |CONTROL6=no |DEPENDS= |REQUIRES=UIP_SUPPORT |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} The default operating mode of the RFM12 is FSK. This mode is used to treat several Ethersex systems connect by radio with each other. Here, one of the systems can act as a router to connect to a wired network. == Connection == If you are using hardware SPI, which is the default, connect the RFM12 to the AVR as follows: [[Image:Rfm12 connection.png|640px]] The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12, PB0, OUTPUT) /* port the LEDS for rfm12 txrx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_USE_INT(2) The RFM12_USE_INT defines whether nRQ is connected to INT0, INT1 or INT2 of the ATmega. == Configuration == [[Category:RFM12]] 5211266c621518d201f9013f50882fdf88a588ad 935 934 2013-03-06T09:25:35Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 FSK}} {{Module |NAME=RFM12 FSK |MENUCONFIG=Network->IP over RFM12 (FSK transmitter) support |STATUS={{Stable}} |PINNING=yes |ECMD=no |CONTROL6=no |DEPENDS= |REQUIRES=UIP_SUPPORT |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} The default operating mode of the RFM12 is FSK. This mode is used to treat several Ethersex systems connect by radio with each other. Here, one of the systems can act as a router to connect to a wired network. == Connection == If you are using hardware SPI, which is the default, connect the RFM12 to the AVR as follows: [[Image:Rfm12 connection.png|640px]] The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_USE_INT(2) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines which number of your module. Each needs its own pinning. The RFM12_USE_INT defines whether nRQ is connected to INT0, INT1 or INT2 of the ATmega. == Configuration == [[Category:RFM12]] 69ea65c354ad9c67a82ab8b9ebed9a381cd548b5 936 935 2013-03-06T09:26:22Z GooPie4o 265 /* Connection */ wikitext text/x-wiki {{i18n|RFM12 FSK}} {{Module |NAME=RFM12 FSK |MENUCONFIG=Network->IP over RFM12 (FSK transmitter) support |STATUS={{Stable}} |PINNING=yes |ECMD=no |CONTROL6=no |DEPENDS= |REQUIRES=UIP_SUPPORT |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} The default operating mode of the RFM12 is FSK. This mode is used to treat several Ethersex systems connect by radio with each other. Here, one of the systems can act as a router to connect to a wired network. == Connection == If you are using hardware SPI, which is the default, connect the RFM12 to the AVR as follows: [[Image:Rfm12 connection.png|640px]] The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_USE_INT(2) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_USE_INT defines whether nRQ is connected to INT0, INT1 or INT2 of the ATmega. == Configuration == [[Category:RFM12]] f3b34f704dfb3f54b803623d6388510788b4a283 6 345 938 2013-03-06T10:10:02Z GooPie4o 265 Taken from old Ethersex WIKI wikitext text/x-wiki Taken from old Ethersex WIKI 721501724cb3bb9c934da2d291ec03ac175eaa36 6 346 940 2013-03-06T10:14:02Z GooPie4o 265 Taken from old Ethersex WIKI wikitext text/x-wiki Taken from old Ethersex WIKI 721501724cb3bb9c934da2d291ec03ac175eaa36 6 348 944 2013-03-06T10:18:54Z GooPie4o 265 Taken from old Ethersex WIKI wikitext text/x-wiki Taken from old Ethersex WIKI 721501724cb3bb9c934da2d291ec03ac175eaa36 6 349 946 2013-03-06T10:20:09Z GooPie4o 265 Taken from old Ethersex WIKI wikitext text/x-wiki Taken from old Ethersex WIKI 721501724cb3bb9c934da2d291ec03ac175eaa36 6 350 947 2013-03-06T10:20:59Z GooPie4o 265 Taken from old Ethersex WIKI wikitext text/x-wiki Taken from old Ethersex WIKI 721501724cb3bb9c934da2d291ec03ac175eaa36 6 351 950 2013-03-06T10:23:21Z GooPie4o 265 Taken from old Ethersex WIKI wikitext text/x-wiki Taken from old Ethersex WIKI 721501724cb3bb9c934da2d291ec03ac175eaa36 0 156 951 949 2013-03-06T10:24:38Z GooPie4o 265 /* 2272 */ wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{I/O}}->RFM12 ASK->433MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} RFM12 ASK schaltet Funksteckdosen von verschiedenen Hersteller. == Unterstützte Systeme == ===Tevion=== Funksteckdosen mit einer 'Anlern-Taste' können mit Hilfe des LERN-Buttons auf der embeded Website des etherrapes */rf.ht auf den gesendeten Hauscode programmiert werden. Erstaunlicherweise können mit diesem Modul auch die Codes der X10 Fernbedienung von Pollin gesendet werden. Eine Code-Sammlung gibts [[X10-codes|hier]]. [[Category:RFM12]] Getestet: * Tevion * MMANDOLYN LIBRA GmbH, Model No. WRC001 * X10 Pollin Best.Nr. 721 379 ===Intertechno (ITS-150)=== Bei Sender vom Typ Intertechno ITS-150 wird über einen Drehschalter auf der Rückseite der Familiencode eingestellt. Auf der Vorderseite gibt es einen Schieberegler für die Auswahl von Gruppe 1-4 sowie Ein/Aus Knöpfe für die Geräte 1-4 (siehe Bild). Die zusätzlich vorhandenen Gruppentaste funktioniert mit den Empfängern Intertechno CMR-500 nicht (deshalb nicht implementiert). [[Image:Intertechno-its150.jpg|150px]] ===2272=== Diese Steckdosen werden üblicherweise über einen Block von 10 DIP-Switches konfiguriert. Dabei wird mit den ersten fünf Schaltern der Hauscode gesetzt. Es ergeben sich also 32 mögliche Einstellungen. Die übrigen fünf Schalter geben die Adresse der Steckdose an. Bei Verwendung des mitgelieferten Senders wird jeweils einer der Adressschalter auf "1" gesetzt: In Dose A setzt man Dip 6 auf '1'; in Dose B Dip 7 auf '1'... Bei Ansteuerung mit dem Ethersex-System besteht diese Einschränkung nicht, so dass hier 32 verschiedene Adressen möglich sind. Getestet: {|class=wikitable |[[]] |[[Image:Duewiaktor.jpg|134px]] |[[Image:Globusaktoren.jpg|134px]] |[[Image:Kangtai2605.jpg|101px]] |[[Image:Kangtai6899s.jpg|100px]] |- |valign=top|ELRO AB440R |valign=top|Düwi Modell 0369-3 |valign=top|Kangtai<br>v. Globus |valign=top|Kangtai<br>Model 2605 |valign=top|Kangtai<br>Model 6899s<br>[[Warnung vor Kangtai 6899s|'''Warnung!''']] |- |Delay 100 |Delay 60 |Delay 72 |Delay 72 |Delay 72 |} === 1527 === Anlernbare Unterputz-Dimmer (zB. Pollin Funkdimmerset FD-UP003) mit Fernbedienung. Die mitgelieferte Fernbedienung besitzt einen HS1527 Encoder (baugleich RT1527/ EV1527/FP1527/SC1527). Der gesendete Code bestehtaus 24 Bits, welche per ASK gesendet werden. Davon sind die ersten 20 Bits fest programmiert - der Hauscode sozusagen. Die letzten 4 Bits sind der eigentliche Schalt-Befehl. Getestet: {|class=wikitable |[[Image:FD-UP003.jpg‎|150px|Pollin Electronic FD-UP003]] |- |valign=top|Pollin FD-UP003<br>[[Hinweis FD-UP003|'''Hinweis!''']] |} 2db0a688d717919a55cedd24d9021655a37effc5 952 951 2013-03-06T10:27:21Z GooPie4o 265 /* 2272 */ wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{I/O}}->RFM12 ASK->433MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} RFM12 ASK schaltet Funksteckdosen von verschiedenen Hersteller. == Unterstützte Systeme == ===Tevion=== Funksteckdosen mit einer 'Anlern-Taste' können mit Hilfe des LERN-Buttons auf der embeded Website des etherrapes */rf.ht auf den gesendeten Hauscode programmiert werden. Erstaunlicherweise können mit diesem Modul auch die Codes der X10 Fernbedienung von Pollin gesendet werden. Eine Code-Sammlung gibts [[X10-codes|hier]]. [[Category:RFM12]] Getestet: * Tevion * MMANDOLYN LIBRA GmbH, Model No. WRC001 * X10 Pollin Best.Nr. 721 379 ===Intertechno (ITS-150)=== Bei Sender vom Typ Intertechno ITS-150 wird über einen Drehschalter auf der Rückseite der Familiencode eingestellt. Auf der Vorderseite gibt es einen Schieberegler für die Auswahl von Gruppe 1-4 sowie Ein/Aus Knöpfe für die Geräte 1-4 (siehe Bild). Die zusätzlich vorhandenen Gruppentaste funktioniert mit den Empfängern Intertechno CMR-500 nicht (deshalb nicht implementiert). [[Image:Intertechno-its150.jpg|150px]] ===2272=== Diese Steckdosen werden üblicherweise über einen Block von 10 DIP-Switches konfiguriert. Dabei wird mit den ersten fünf Schaltern der Hauscode gesetzt. Es ergeben sich also 32 mögliche Einstellungen. Die übrigen fünf Schalter geben die Adresse der Steckdose an. Bei Verwendung des mitgelieferten Senders wird jeweils einer der Adressschalter auf "1" gesetzt: In Dose A setzt man Dip 6 auf '1'; in Dose B Dip 7 auf '1'... Bei Ansteuerung mit dem Ethersex-System besteht diese Einschränkung nicht, so dass hier 32 verschiedene Adressen möglich sind. Getestet: {|class=wikitable |[http://www.elro.eu/uploads/products/img/_w200/AB440RA_1.jpg] |[[Image:Duewiaktor.jpg|134px]] |[[Image:Globusaktoren.jpg|134px]] |[[Image:Kangtai2605.jpg|101px]] |[[Image:Kangtai6899s.jpg|100px]] |- |valign=top|ELRO AB440R |valign=top|Düwi Modell 0369-3 |valign=top|Kangtai<br>v. Globus |valign=top|Kangtai<br>Model 2605 |valign=top|Kangtai<br>Model 6899s<br>[[Warnung vor Kangtai 6899s|'''Warnung!''']] |- |Delay 100 |Delay 60 |Delay 72 |Delay 72 |Delay 72 |} === 1527 === Anlernbare Unterputz-Dimmer (zB. Pollin Funkdimmerset FD-UP003) mit Fernbedienung. Die mitgelieferte Fernbedienung besitzt einen HS1527 Encoder (baugleich RT1527/ EV1527/FP1527/SC1527). Der gesendete Code bestehtaus 24 Bits, welche per ASK gesendet werden. Davon sind die ersten 20 Bits fest programmiert - der Hauscode sozusagen. Die letzten 4 Bits sind der eigentliche Schalt-Befehl. Getestet: {|class=wikitable |[[Image:FD-UP003.jpg‎|150px|Pollin Electronic FD-UP003]] |- |valign=top|Pollin FD-UP003<br>[[Hinweis FD-UP003|'''Hinweis!''']] |} c24041d33263f585a6d3968ad1fc55e607f350eb 955 952 2013-03-11T06:12:29Z GooPie4o 265 /* 2272 */ wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{I/O}}->RFM12 ASK->433MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} RFM12 ASK schaltet Funksteckdosen von verschiedenen Hersteller. == Unterstützte Systeme == ===Tevion=== Funksteckdosen mit einer 'Anlern-Taste' können mit Hilfe des LERN-Buttons auf der embeded Website des etherrapes */rf.ht auf den gesendeten Hauscode programmiert werden. Erstaunlicherweise können mit diesem Modul auch die Codes der X10 Fernbedienung von Pollin gesendet werden. Eine Code-Sammlung gibts [[X10-codes|hier]]. [[Category:RFM12]] Getestet: * Tevion * MMANDOLYN LIBRA GmbH, Model No. WRC001 * X10 Pollin Best.Nr. 721 379 ===Intertechno (ITS-150)=== Bei Sender vom Typ Intertechno ITS-150 wird über einen Drehschalter auf der Rückseite der Familiencode eingestellt. Auf der Vorderseite gibt es einen Schieberegler für die Auswahl von Gruppe 1-4 sowie Ein/Aus Knöpfe für die Geräte 1-4 (siehe Bild). Die zusätzlich vorhandenen Gruppentaste funktioniert mit den Empfängern Intertechno CMR-500 nicht (deshalb nicht implementiert). [[Image:Intertechno-its150.jpg|150px]] ===2272=== Diese Steckdosen werden üblicherweise über einen Block von 10 DIP-Switches konfiguriert. Dabei wird mit den ersten fünf Schaltern der Hauscode gesetzt. Es ergeben sich also 32 mögliche Einstellungen. Die übrigen fünf Schalter geben die Adresse der Steckdose an. Bei Verwendung des mitgelieferten Senders wird jeweils einer der Adressschalter auf "1" gesetzt: In Dose A setzt man Dip 6 auf '1'; in Dose B Dip 7 auf '1'... Bei Ansteuerung mit dem Ethersex-System besteht diese Einschränkung nicht, so dass hier 32 verschiedene Adressen möglich sind. Getestet: {|class=wikitable |<nowiki><img src="http://www.elro.eu/uploads/products/img/_w200/AB440RA_1.jpg"/></nowiki> |[[Image:Duewiaktor.jpg|134px]] |[[Image:Globusaktoren.jpg|134px]] |[[Image:Kangtai2605.jpg|101px]] |[[Image:Kangtai6899s.jpg|100px]] |- |valign=top|ELRO AB440R |valign=top|Düwi Modell 0369-3 |valign=top|Kangtai<br>v. Globus |valign=top|Kangtai<br>Model 2605 |valign=top|Kangtai<br>Model 6899s<br>[[Warnung vor Kangtai 6899s|'''Warnung!''']] |- |Delay 100 |Delay 60 |Delay 72 |Delay 72 |Delay 72 |} === 1527 === Anlernbare Unterputz-Dimmer (zB. Pollin Funkdimmerset FD-UP003) mit Fernbedienung. Die mitgelieferte Fernbedienung besitzt einen HS1527 Encoder (baugleich RT1527/ EV1527/FP1527/SC1527). Der gesendete Code bestehtaus 24 Bits, welche per ASK gesendet werden. Davon sind die ersten 20 Bits fest programmiert - der Hauscode sozusagen. Die letzten 4 Bits sind der eigentliche Schalt-Befehl. Getestet: {|class=wikitable |[[Image:FD-UP003.jpg‎|150px|Pollin Electronic FD-UP003]] |- |valign=top|Pollin FD-UP003<br>[[Hinweis FD-UP003|'''Hinweis!''']] |} 8808cc9788cf4e32af78a2d5e0da8926ebdd24a3 956 955 2013-03-11T06:15:06Z GooPie4o 265 Undo revision 955 by [[Special:Contributions/GooPie4o|GooPie4o]] ([[User talk:GooPie4o|Talk]]) wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{I/O}}->RFM12 ASK->433MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} RFM12 ASK schaltet Funksteckdosen von verschiedenen Hersteller. == Unterstützte Systeme == ===Tevion=== Funksteckdosen mit einer 'Anlern-Taste' können mit Hilfe des LERN-Buttons auf der embeded Website des etherrapes */rf.ht auf den gesendeten Hauscode programmiert werden. Erstaunlicherweise können mit diesem Modul auch die Codes der X10 Fernbedienung von Pollin gesendet werden. Eine Code-Sammlung gibts [[X10-codes|hier]]. [[Category:RFM12]] Getestet: * Tevion * MMANDOLYN LIBRA GmbH, Model No. WRC001 * X10 Pollin Best.Nr. 721 379 ===Intertechno (ITS-150)=== Bei Sender vom Typ Intertechno ITS-150 wird über einen Drehschalter auf der Rückseite der Familiencode eingestellt. Auf der Vorderseite gibt es einen Schieberegler für die Auswahl von Gruppe 1-4 sowie Ein/Aus Knöpfe für die Geräte 1-4 (siehe Bild). Die zusätzlich vorhandenen Gruppentaste funktioniert mit den Empfängern Intertechno CMR-500 nicht (deshalb nicht implementiert). [[Image:Intertechno-its150.jpg|150px]] ===2272=== Diese Steckdosen werden üblicherweise über einen Block von 10 DIP-Switches konfiguriert. Dabei wird mit den ersten fünf Schaltern der Hauscode gesetzt. Es ergeben sich also 32 mögliche Einstellungen. Die übrigen fünf Schalter geben die Adresse der Steckdose an. Bei Verwendung des mitgelieferten Senders wird jeweils einer der Adressschalter auf "1" gesetzt: In Dose A setzt man Dip 6 auf '1'; in Dose B Dip 7 auf '1'... Bei Ansteuerung mit dem Ethersex-System besteht diese Einschränkung nicht, so dass hier 32 verschiedene Adressen möglich sind. Getestet: {|class=wikitable |[http://www.elro.eu/uploads/products/img/_w200/AB440RA_1.jpg] |[[Image:Duewiaktor.jpg|134px]] |[[Image:Globusaktoren.jpg|134px]] |[[Image:Kangtai2605.jpg|101px]] |[[Image:Kangtai6899s.jpg|100px]] |- |valign=top|ELRO AB440R |valign=top|Düwi Modell 0369-3 |valign=top|Kangtai<br>v. Globus |valign=top|Kangtai<br>Model 2605 |valign=top|Kangtai<br>Model 6899s<br>[[Warnung vor Kangtai 6899s|'''Warnung!''']] |- |Delay 100 |Delay 60 |Delay 72 |Delay 72 |Delay 72 |} === 1527 === Anlernbare Unterputz-Dimmer (zB. Pollin Funkdimmerset FD-UP003) mit Fernbedienung. Die mitgelieferte Fernbedienung besitzt einen HS1527 Encoder (baugleich RT1527/ EV1527/FP1527/SC1527). Der gesendete Code bestehtaus 24 Bits, welche per ASK gesendet werden. Davon sind die ersten 20 Bits fest programmiert - der Hauscode sozusagen. Die letzten 4 Bits sind der eigentliche Schalt-Befehl. Getestet: {|class=wikitable |[[Image:FD-UP003.jpg‎|150px|Pollin Electronic FD-UP003]] |- |valign=top|Pollin FD-UP003<br>[[Hinweis FD-UP003|'''Hinweis!''']] |} c24041d33263f585a6d3968ad1fc55e607f350eb 957 956 2013-03-11T06:19:28Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{I/O}}->RFM12 ASK->433MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} RFM12 ASK schaltet Funksteckdosen von verschiedenen Hersteller. == Unterstützte Systeme == ===Tevion=== Funksteckdosen mit einer 'Anlern-Taste' können mit Hilfe des LERN-Buttons auf der embeded Website des etherrapes */rf.ht auf den gesendeten Hauscode programmiert werden. Erstaunlicherweise können mit diesem Modul auch die Codes der X10 Fernbedienung von Pollin gesendet werden. Eine Code-Sammlung gibts [[X10-codes|hier]]. [[Category:RFM12]] Getestet: * Tevion * MMANDOLYN LIBRA GmbH, Model No. WRC001 * X10 Pollin Best.Nr. 721 379 ===Intertechno (ITS-150)=== Bei Sender vom Typ Intertechno ITS-150 wird über einen Drehschalter auf der Rückseite der Familiencode eingestellt. Auf der Vorderseite gibt es einen Schieberegler für die Auswahl von Gruppe 1-4 sowie Ein/Aus Knöpfe für die Geräte 1-4 (siehe Bild). Die zusätzlich vorhandenen Gruppentaste funktioniert mit den Empfängern Intertechno CMR-500 nicht (deshalb nicht implementiert). [[Image:Intertechno-its150.jpg|150px]] ===2272=== Diese Steckdosen werden üblicherweise über einen Block von 10 DIP-Switches konfiguriert. Dabei wird mit den ersten fünf Schaltern der Hauscode gesetzt. Es ergeben sich also 32 mögliche Einstellungen. Die übrigen fünf Schalter geben die Adresse der Steckdose an. Bei Verwendung des mitgelieferten Senders wird jeweils einer der Adressschalter auf "1" gesetzt: In Dose A setzt man Dip 6 auf '1'; in Dose B Dip 7 auf '1'... Bei Ansteuerung mit dem Ethersex-System besteht diese Einschränkung nicht, so dass hier 32 verschiedene Adressen möglich sind. Getestet: {|class=wikitable |[http://www.elro.eu/uploads/products/img/_w200/AB440RA_1.jpg] |[[Image:Duewiaktor.jpg|134px]] |[[Image:Globusaktoren.jpg|134px]] |[[Image:Kangtai2605.jpg|101px]] |[[Image:Kangtai6899s.jpg|100px]] |- |valign=top|ELRO AB440R |valign=top|Düwi Modell 0369-3 |valign=top|Kangtai<br>v. Globus |valign=top|Kangtai<br>Model 2605 |valign=top|Kangtai<br>Model 6899s<br>[[Warnung vor Kangtai 6899s|'''Warnung!''']] |- |Delay 100 |Delay 60 |Delay 72 |Delay 72 |Delay 72 |} === 1527 === Anlernbare Unterputz-Dimmer (zB. Pollin Funkdimmerset FD-UP003) mit Fernbedienung. Die mitgelieferte Fernbedienung besitzt einen HS1527 Encoder (baugleich RT1527/ EV1527/FP1527/SC1527). Der gesendete Code bestehtaus 24 Bits, welche per ASK gesendet werden. Davon sind die ersten 20 Bits fest programmiert - der Hauscode sozusagen. Die letzten 4 Bits sind der eigentliche Schalt-Befehl. Getestet: {|class=wikitable |[[Image:FD-UP003.jpg‎|150px|Pollin Electronic FD-UP003]] |- |valign=top|Pollin FD-UP003<br>[[Hinweis FD-UP003|'''Hinweis!''']] |} === Oase Inscenio FM Master === Das Baukastensystem für Gartensteckdosen der Serie [http://www.oase-livingwater.com/de_DE/wasser-garten/produkte/illumination-und-strom/strommanagement/inscenio.html InScenio] organisieren Sie die gesamte Garten- und Teichtechnik. 41c5e1c24ff01cb46be58bc2505bca6a5e86bb26 958 957 2013-03-11T06:20:03Z GooPie4o 265 /* Oase Inscenio FM Master */ wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{I/O}}->RFM12 ASK->433MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} RFM12 ASK schaltet Funksteckdosen von verschiedenen Hersteller. == Unterstützte Systeme == ===Tevion=== Funksteckdosen mit einer 'Anlern-Taste' können mit Hilfe des LERN-Buttons auf der embeded Website des etherrapes */rf.ht auf den gesendeten Hauscode programmiert werden. Erstaunlicherweise können mit diesem Modul auch die Codes der X10 Fernbedienung von Pollin gesendet werden. Eine Code-Sammlung gibts [[X10-codes|hier]]. [[Category:RFM12]] Getestet: * Tevion * MMANDOLYN LIBRA GmbH, Model No. WRC001 * X10 Pollin Best.Nr. 721 379 ===Intertechno (ITS-150)=== Bei Sender vom Typ Intertechno ITS-150 wird über einen Drehschalter auf der Rückseite der Familiencode eingestellt. Auf der Vorderseite gibt es einen Schieberegler für die Auswahl von Gruppe 1-4 sowie Ein/Aus Knöpfe für die Geräte 1-4 (siehe Bild). Die zusätzlich vorhandenen Gruppentaste funktioniert mit den Empfängern Intertechno CMR-500 nicht (deshalb nicht implementiert). [[Image:Intertechno-its150.jpg|150px]] ===2272=== Diese Steckdosen werden üblicherweise über einen Block von 10 DIP-Switches konfiguriert. Dabei wird mit den ersten fünf Schaltern der Hauscode gesetzt. Es ergeben sich also 32 mögliche Einstellungen. Die übrigen fünf Schalter geben die Adresse der Steckdose an. Bei Verwendung des mitgelieferten Senders wird jeweils einer der Adressschalter auf "1" gesetzt: In Dose A setzt man Dip 6 auf '1'; in Dose B Dip 7 auf '1'... Bei Ansteuerung mit dem Ethersex-System besteht diese Einschränkung nicht, so dass hier 32 verschiedene Adressen möglich sind. Getestet: {|class=wikitable |[http://www.elro.eu/uploads/products/img/_w200/AB440RA_1.jpg] |[[Image:Duewiaktor.jpg|134px]] |[[Image:Globusaktoren.jpg|134px]] |[[Image:Kangtai2605.jpg|101px]] |[[Image:Kangtai6899s.jpg|100px]] |- |valign=top|ELRO AB440R |valign=top|Düwi Modell 0369-3 |valign=top|Kangtai<br>v. Globus |valign=top|Kangtai<br>Model 2605 |valign=top|Kangtai<br>Model 6899s<br>[[Warnung vor Kangtai 6899s|'''Warnung!''']] |- |Delay 100 |Delay 60 |Delay 72 |Delay 72 |Delay 72 |} === 1527 === Anlernbare Unterputz-Dimmer (zB. Pollin Funkdimmerset FD-UP003) mit Fernbedienung. Die mitgelieferte Fernbedienung besitzt einen HS1527 Encoder (baugleich RT1527/ EV1527/FP1527/SC1527). Der gesendete Code bestehtaus 24 Bits, welche per ASK gesendet werden. Davon sind die ersten 20 Bits fest programmiert - der Hauscode sozusagen. Die letzten 4 Bits sind der eigentliche Schalt-Befehl. Getestet: {|class=wikitable |[[Image:FD-UP003.jpg‎|150px|Pollin Electronic FD-UP003]] |- |valign=top|Pollin FD-UP003<br>[[Hinweis FD-UP003|'''Hinweis!''']] |} === Oase Inscenio FM Master === Das Baukastensystem für Gartensteckdosen der Serie [http://www.oase-livingwater.com/de_DE/wasser-garten/produkte/illumination-und-strom/strommanagement/inscenio.html InScenio] organisiert die gesamte Garten- und Teichtechnik. 789ea933673208f40d4e2c23dab18a10a5b2391b 989 958 2013-03-12T06:14:29Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{I/O}}->RFM12 ASK->433MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} RFM12 ASK schaltet Funksteckdosen von verschiedenen Hersteller. == Unterstützte Systeme == ===Tevion=== Funksteckdosen mit einer 'Anlern-Taste' können mit Hilfe des LERN-Buttons auf der embeded Website des etherrapes */rf.ht auf den gesendeten Hauscode programmiert werden. Erstaunlicherweise können mit diesem Modul auch die Codes der X10 Fernbedienung von Pollin gesendet werden. Eine Code-Sammlung gibts [[X10-codes|hier]]. [[Category:RFM12]] Getestet: * Tevion * MMANDOLYN LIBRA GmbH, Model No. WRC001 * X10 Pollin Best.Nr. 721 379 ===Intertechno (ITS-150)=== Bei Sender vom Typ Intertechno ITS-150 wird über einen Drehschalter auf der Rückseite der Familiencode eingestellt. Auf der Vorderseite gibt es einen Schieberegler für die Auswahl von Gruppe 1-4 sowie Ein/Aus Knöpfe für die Geräte 1-4 (siehe Bild). Die zusätzlich vorhandenen Gruppentaste funktioniert mit den Empfängern Intertechno CMR-500 nicht (deshalb nicht implementiert). [[Image:Intertechno-its150.jpg|150px]] ===2272=== Diese Steckdosen werden üblicherweise über einen Block von 10 DIP-Switches konfiguriert. Dabei wird mit den ersten fünf Schaltern der Hauscode gesetzt. Es ergeben sich also 32 mögliche Einstellungen. Die übrigen fünf Schalter geben die Adresse der Steckdose an. Bei Verwendung des mitgelieferten Senders wird jeweils einer der Adressschalter auf "1" gesetzt: In Dose A setzt man Dip 6 auf '1'; in Dose B Dip 7 auf '1'... Bei Ansteuerung mit dem Ethersex-System besteht diese Einschränkung nicht, so dass hier 32 verschiedene Adressen möglich sind. Getestet: {|class=wikitable |[http://www.elro.eu/uploads/products/img/_w200/AB440RA_1.jpg] |[[Image:Duewiaktor.jpg|134px]] |[[Image:Globusaktoren.jpg|134px]] |[[Image:Kangtai2605.jpg|101px]] |[[Image:Kangtai6899s.jpg|100px]] |- |valign=top|ELRO AB440R |valign=top|Düwi Modell 0369-3 |valign=top|Kangtai<br>v. Globus |valign=top|Kangtai<br>Model 2605 |valign=top|Kangtai<br>Model 6899s<br>[[Warnung vor Kangtai 6899s|'''Warnung!''']] |- |Delay 100 |Delay 60 |Delay 72 |Delay 72 |Delay 72 |} === 1527 === Anlernbare Unterputz-Dimmer (zB. Pollin Funkdimmerset FD-UP003) mit Fernbedienung. Die mitgelieferte Fernbedienung besitzt einen HS1527 Encoder (baugleich RT1527/ EV1527/FP1527/SC1527). Der gesendete Code bestehtaus 24 Bits, welche per ASK gesendet werden. Davon sind die ersten 20 Bits fest programmiert - der Hauscode sozusagen. Die letzten 4 Bits sind der eigentliche Schalt-Befehl. Getestet: {|class=wikitable |[[Image:FD-UP003.jpg‎|150px|Pollin Electronic FD-UP003]] |- |valign=top|Pollin FD-UP003<br>[[Hinweis FD-UP003|'''Hinweis!''']] |} === Oase Inscenio FM Master === Das Baukastensystem für Gartensteckdosen der Serie [http://www.oase-livingwater.com/de_DE/wasser-garten/produkte/illumination-und-strom/strommanagement/inscenio.html InScenio] organisiert die gesamte Garten- und Teichtechnik. == Anschluss == == Konfiguration == == [[ECMD]] == 5f9e7986234d629aa1b2a3feb4eadb3517bc68db 990 989 2013-03-12T06:14:52Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{I/O}}->RFM12 ASK->433MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} RFM12 ASK schaltet Funksteckdosen verschiedener Hersteller. == Unterstützte Systeme == ===Tevion=== Funksteckdosen mit einer 'Anlern-Taste' können mit Hilfe des LERN-Buttons auf der embeded Website des etherrapes */rf.ht auf den gesendeten Hauscode programmiert werden. Erstaunlicherweise können mit diesem Modul auch die Codes der X10 Fernbedienung von Pollin gesendet werden. Eine Code-Sammlung gibts [[X10-codes|hier]]. [[Category:RFM12]] Getestet: * Tevion * MMANDOLYN LIBRA GmbH, Model No. WRC001 * X10 Pollin Best.Nr. 721 379 ===Intertechno (ITS-150)=== Bei Sender vom Typ Intertechno ITS-150 wird über einen Drehschalter auf der Rückseite der Familiencode eingestellt. Auf der Vorderseite gibt es einen Schieberegler für die Auswahl von Gruppe 1-4 sowie Ein/Aus Knöpfe für die Geräte 1-4 (siehe Bild). Die zusätzlich vorhandenen Gruppentaste funktioniert mit den Empfängern Intertechno CMR-500 nicht (deshalb nicht implementiert). [[Image:Intertechno-its150.jpg|150px]] ===2272=== Diese Steckdosen werden üblicherweise über einen Block von 10 DIP-Switches konfiguriert. Dabei wird mit den ersten fünf Schaltern der Hauscode gesetzt. Es ergeben sich also 32 mögliche Einstellungen. Die übrigen fünf Schalter geben die Adresse der Steckdose an. Bei Verwendung des mitgelieferten Senders wird jeweils einer der Adressschalter auf "1" gesetzt: In Dose A setzt man Dip 6 auf '1'; in Dose B Dip 7 auf '1'... Bei Ansteuerung mit dem Ethersex-System besteht diese Einschränkung nicht, so dass hier 32 verschiedene Adressen möglich sind. Getestet: {|class=wikitable |[http://www.elro.eu/uploads/products/img/_w200/AB440RA_1.jpg] |[[Image:Duewiaktor.jpg|134px]] |[[Image:Globusaktoren.jpg|134px]] |[[Image:Kangtai2605.jpg|101px]] |[[Image:Kangtai6899s.jpg|100px]] |- |valign=top|ELRO AB440R |valign=top|Düwi Modell 0369-3 |valign=top|Kangtai<br>v. Globus |valign=top|Kangtai<br>Model 2605 |valign=top|Kangtai<br>Model 6899s<br>[[Warnung vor Kangtai 6899s|'''Warnung!''']] |- |Delay 100 |Delay 60 |Delay 72 |Delay 72 |Delay 72 |} === 1527 === Anlernbare Unterputz-Dimmer (zB. Pollin Funkdimmerset FD-UP003) mit Fernbedienung. Die mitgelieferte Fernbedienung besitzt einen HS1527 Encoder (baugleich RT1527/ EV1527/FP1527/SC1527). Der gesendete Code bestehtaus 24 Bits, welche per ASK gesendet werden. Davon sind die ersten 20 Bits fest programmiert - der Hauscode sozusagen. Die letzten 4 Bits sind der eigentliche Schalt-Befehl. Getestet: {|class=wikitable |[[Image:FD-UP003.jpg‎|150px|Pollin Electronic FD-UP003]] |- |valign=top|Pollin FD-UP003<br>[[Hinweis FD-UP003|'''Hinweis!''']] |} === Oase Inscenio FM Master === Das Baukastensystem für Gartensteckdosen der Serie [http://www.oase-livingwater.com/de_DE/wasser-garten/produkte/illumination-und-strom/strommanagement/inscenio.html InScenio] organisiert die gesamte Garten- und Teichtechnik. == Anschluss == == Konfiguration == == [[ECMD]] == 2857ca1f9714668b83882bdf549ec298c8393eec 991 990 2013-03-12T06:17:07Z GooPie4o 265 /* ECMD */ wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{I/O}}->RFM12 ASK->433MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} RFM12 ASK schaltet Funksteckdosen verschiedener Hersteller. == Unterstützte Systeme == ===Tevion=== Funksteckdosen mit einer 'Anlern-Taste' können mit Hilfe des LERN-Buttons auf der embeded Website des etherrapes */rf.ht auf den gesendeten Hauscode programmiert werden. Erstaunlicherweise können mit diesem Modul auch die Codes der X10 Fernbedienung von Pollin gesendet werden. Eine Code-Sammlung gibts [[X10-codes|hier]]. [[Category:RFM12]] Getestet: * Tevion * MMANDOLYN LIBRA GmbH, Model No. WRC001 * X10 Pollin Best.Nr. 721 379 ===Intertechno (ITS-150)=== Bei Sender vom Typ Intertechno ITS-150 wird über einen Drehschalter auf der Rückseite der Familiencode eingestellt. Auf der Vorderseite gibt es einen Schieberegler für die Auswahl von Gruppe 1-4 sowie Ein/Aus Knöpfe für die Geräte 1-4 (siehe Bild). Die zusätzlich vorhandenen Gruppentaste funktioniert mit den Empfängern Intertechno CMR-500 nicht (deshalb nicht implementiert). [[Image:Intertechno-its150.jpg|150px]] ===2272=== Diese Steckdosen werden üblicherweise über einen Block von 10 DIP-Switches konfiguriert. Dabei wird mit den ersten fünf Schaltern der Hauscode gesetzt. Es ergeben sich also 32 mögliche Einstellungen. Die übrigen fünf Schalter geben die Adresse der Steckdose an. Bei Verwendung des mitgelieferten Senders wird jeweils einer der Adressschalter auf "1" gesetzt: In Dose A setzt man Dip 6 auf '1'; in Dose B Dip 7 auf '1'... Bei Ansteuerung mit dem Ethersex-System besteht diese Einschränkung nicht, so dass hier 32 verschiedene Adressen möglich sind. Getestet: {|class=wikitable |[http://www.elro.eu/uploads/products/img/_w200/AB440RA_1.jpg] |[[Image:Duewiaktor.jpg|134px]] |[[Image:Globusaktoren.jpg|134px]] |[[Image:Kangtai2605.jpg|101px]] |[[Image:Kangtai6899s.jpg|100px]] |- |valign=top|ELRO AB440R |valign=top|Düwi Modell 0369-3 |valign=top|Kangtai<br>v. Globus |valign=top|Kangtai<br>Model 2605 |valign=top|Kangtai<br>Model 6899s<br>[[Warnung vor Kangtai 6899s|'''Warnung!''']] |- |Delay 100 |Delay 60 |Delay 72 |Delay 72 |Delay 72 |} === 1527 === Anlernbare Unterputz-Dimmer (zB. Pollin Funkdimmerset FD-UP003) mit Fernbedienung. Die mitgelieferte Fernbedienung besitzt einen HS1527 Encoder (baugleich RT1527/ EV1527/FP1527/SC1527). Der gesendete Code bestehtaus 24 Bits, welche per ASK gesendet werden. Davon sind die ersten 20 Bits fest programmiert - der Hauscode sozusagen. Die letzten 4 Bits sind der eigentliche Schalt-Befehl. Getestet: {|class=wikitable |[[Image:FD-UP003.jpg‎|150px|Pollin Electronic FD-UP003]] |- |valign=top|Pollin FD-UP003<br>[[Hinweis FD-UP003|'''Hinweis!''']] |} === Oase Inscenio FM Master === Das Baukastensystem für Gartensteckdosen der Serie [http://www.oase-livingwater.com/de_DE/wasser-garten/produkte/illumination-und-strom/strommanagement/inscenio.html InScenio] organisiert die gesamte Garten- und Teichtechnik. == Anschluss == == Konfiguration == == [[ECMD]] == RFM12 ASK implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle zur Steuerung von Funksteckdosen. Siehe [[ECMD_Reference|ECMD Referenz]]. 7a59cb644e708d6aded551cfe9a979d3a9bcbe11 0 352 953 2013-03-06T10:28:11Z GooPie4o 265 Created page with "Das Funksteckdosenset Kangtai 6899s, das unter verschiedenen Namen in Deutschland vertrieben wurde, wurde von verschiedenen Institutionen getestet und für gefährlich befunden. …" wikitext text/x-wiki Das Funksteckdosenset Kangtai 6899s, das unter verschiedenen Namen in Deutschland vertrieben wurde, wurde von verschiedenen Institutionen getestet und für gefährlich befunden. Wer ein solches Funksteckdosenset dennoch betreiben möchte, sollte sich über die damit verbundenen Gefahren bewusst sein. ==Quellen== * http://www.baua.de/nn_69508/de/Publikationen/BAuA-AKTUELL/2007-3/pdf/ba3-07-s09.pdf * http://www.test.de/themen/haus-garten/meldung/-Funkschalter-von-Toom-Penny-und-Zack/1557104/1557104/ [[Category:Hardware]] 4862f306629cca5bc31143e3df3ec6e8f0e9c9f9 0 353 954 2013-03-06T10:28:59Z GooPie4o 265 Created page with "'''Achtung:''' Diese Dimmer arbeiten mit Phasenanschnittsteuerung. Es dürfen ausschließlich ohmsche Lasten (z.B. normale Glühlampen oder 230V-Halogenlampen) angeschlossen wer…" wikitext text/x-wiki '''Achtung:''' Diese Dimmer arbeiten mit Phasenanschnittsteuerung. Es dürfen ausschließlich ohmsche Lasten (z.B. normale Glühlampen oder 230V-Halogenlampen) angeschlossen werden! Sie sind '''nicht für induktive Lasten''' (z.B. 12V Halogentrafos oder Energiesparlamen) geeignet. Beim Anschluss von (elektronischen) Trafos besteht die Gefahr der Beschädigung des Dimmers und/oder des Trafos. Weiterhin sind die Dimmer nicht mit herkömmlichen Schalterprogrammen kompatibel, da der Rahmen fest verschraubt ist. Ein Einbau in bestehende UP-Dosen mit 2- oder 3-fach-Rahmen ist somit nicht ohne weiteres möglich. [[Category:Hardware]] ed0268f6fb9aff1108602908c339881fe47f408d 0 312 959 902 2013-03-11T06:45:41Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} The FS20 / FHT system by ELV is currently the most successful wireless home control system in the low cost sector. This arises from the large number of components and the continuous expansion of the system. But the relatively low price, the comprehensive home control systems far below the price of such EIB systems permits, plays a crucial role. The [[Ethersex]] software is based on [http://culfw.de CULFW by Rudolf Koenig] and supports a wide range of protocols: * FS20: send/receive<br>There are numerous FS20 devices, AFAIK. all of them are fully supported. * FHT: send/receivey<br>Communication to the FHT80b is supported. * S300: receive<br>Examples of such devices: S300TH, KS300-2 * EM1000: receive<br>Devices: EM1000FM, EM1000GZ, EM1000WZ * HMS: receive<br>Devices: There are numerous HMS devices, AFAIK. all of them are fully supported. * ESA2000: send and receive * Lacrosse TX2/TX3: receive == Connection == The RFM12 is connected to the MCU like in [[RFM12_ASK#Connection|FSK Mode]] with a small difference. Pin 3 DATA is connected to one of the INT pins of the MCU. The software uses the digital filter of the RFM12. In order to receive near and far sender as well the modul also needs a slight [http://jeelabs.net/projects/cafe/wiki/Receiving_OOKASK_with_a_modified_RFM12B hardware modification]. == Configuration == [[Category:RFM12]] 14781c38775343b6ae9d7af14087dce2120339a9 960 959 2013-03-11T06:50:45Z GooPie4o 265 /* Connection */ wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} The FS20 / FHT system by ELV is currently the most successful wireless home control system in the low cost sector. This arises from the large number of components and the continuous expansion of the system. But the relatively low price, the comprehensive home control systems far below the price of such EIB systems permits, plays a crucial role. The [[Ethersex]] software is based on [http://culfw.de CULFW by Rudolf Koenig] and supports a wide range of protocols: * FS20: send/receive<br>There are numerous FS20 devices, AFAIK. all of them are fully supported. * FHT: send/receivey<br>Communication to the FHT80b is supported. * S300: receive<br>Examples of such devices: S300TH, KS300-2 * EM1000: receive<br>Devices: EM1000FM, EM1000GZ, EM1000WZ * HMS: receive<br>Devices: There are numerous HMS devices, AFAIK. all of them are fully supported. * ESA2000: send and receive * Lacrosse TX2/TX3: receive == Connection == The RFM12 is connected to the MCU like in [[RFM12_ASK#Connection|FSK Mode]] with a small difference. The output FSK/DATA/nFSS signal (Pin 3) is connected to one of the INT pins of the MCU. The software uses the digital filter of the RFM12. In order to receive near and far sender as well. To improve sensitivity on short and long distances the [http://jeelabs.net/projects/cafe/wiki/Receiving_OOKASK_with_a_modified_RFM12B C_arssi capacitor needs to be replaced] with a value 150 pf. == Configuration == [[Category:RFM12]] c971fdac4a08145422d02b03111229305301b64f 961 960 2013-03-11T06:53:28Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} The FS20 / FHT system by ELV is currently the most successful wireless home control system in the low cost sector. This arises from the large number of components and the continuous expansion of the system. But the relatively low price, the comprehensive home control systems far below the price of such EIB systems permits, plays a crucial role. This FS20 modul is based on [http://culfw.de CULFW by Rudolf Koenig] and supports a wide range of protocols: * FS20: send/receive<br>There are numerous FS20 devices, AFAIK. all of them are fully supported. * FHT: send/receivey<br>Communication to the FHT80b is supported. * S300: receive<br>Examples of such devices: S300TH, KS300-2 * EM1000: receive<br>Devices: EM1000FM, EM1000GZ, EM1000WZ * HMS: receive<br>Devices: There are numerous HMS devices, AFAIK. all of them are fully supported. * ESA2000: send and receive * Lacrosse TX2/TX3: receive == Connection == The RFM12 is connected to the MCU like in [[RFM12_ASK#Connection|FSK Mode]] with a small difference. The output FSK/DATA/nFSS signal (Pin 3) is connected to one of the INT pins of the MCU. The software uses the digital filter of the RFM12. In order to receive near and far sender as well. To improve sensitivity on short and long distances the [http://jeelabs.net/projects/cafe/wiki/Receiving_OOKASK_with_a_modified_RFM12B C_arssi capacitor needs to be replaced] with a value 150 pf. == Configuration == [[Category:RFM12]] b60b802826facfdaffc53f0fd5f708096078a172 962 961 2013-03-11T06:54:07Z GooPie4o 265 /* Connection */ wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} The FS20 / FHT system by ELV is currently the most successful wireless home control system in the low cost sector. This arises from the large number of components and the continuous expansion of the system. But the relatively low price, the comprehensive home control systems far below the price of such EIB systems permits, plays a crucial role. This FS20 modul is based on [http://culfw.de CULFW by Rudolf Koenig] and supports a wide range of protocols: * FS20: send/receive<br>There are numerous FS20 devices, AFAIK. all of them are fully supported. * FHT: send/receivey<br>Communication to the FHT80b is supported. * S300: receive<br>Examples of such devices: S300TH, KS300-2 * EM1000: receive<br>Devices: EM1000FM, EM1000GZ, EM1000WZ * HMS: receive<br>Devices: There are numerous HMS devices, AFAIK. all of them are fully supported. * ESA2000: send and receive * Lacrosse TX2/TX3: receive == Connection == The RFM12 is connected to the MCU like in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FSK/DATA/nFSS signal (Pin 3) is connected to one of the INT pins of the MCU. The software uses the digital filter of the RFM12. In order to receive near and far sender as well. To improve sensitivity on short and long distances the [http://jeelabs.net/projects/cafe/wiki/Receiving_OOKASK_with_a_modified_RFM12B C_arssi capacitor needs to be replaced] with a value 150 pf. == Configuration == [[Category:RFM12]] ea994e8034b00ec66caa0f0eb0f5cbde43e341a2 966 962 2013-03-11T07:02:24Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} The FS20 / FHT system by ELV is currently the most successful wireless home control system in the low cost sector. This arises from the large number of components and the continuous expansion of the system. But the relatively low price, the comprehensive home control systems far below the price of such EIB systems permits, plays a crucial role. This FS20 modul is based on [http://culfw.de CULFW by Rudolf Koenig] and supports a wide range of protocols: * FS20: send/receive<br>There are numerous FS20 devices, AFAIK. all of them are fully supported. * FHT: send/receivey<br>Communication to the FHT80b is supported. * S300: receive<br>Examples of such devices: S300TH, KS300-2 * EM1000: receive<br>Devices: EM1000FM, EM1000GZ, EM1000WZ * HMS: receive<br>Devices: There are numerous HMS devices, AFAIK. all of them are fully supported. * ESA2000: receive * Lacrosse TX2/TX3: receive == Connection == The RFM12 is connected to the MCU like in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FSK/DATA/nFSS signal (Pin 3) is connected to one of the INT pins of the MCU. The software uses the digital filter of the RFM12. In order to receive near and far sender as well. To improve sensitivity on short and long distances the [http://jeelabs.net/projects/cafe/wiki/Receiving_OOKASK_with_a_modified_RFM12B C_arssi capacitor needs to be replaced] with a value 150 pf. == Configuration == [[Category:RFM12]] 6bdfc0c92bea2ad8aa564f336122e2dde30a514c 968 966 2013-03-11T07:05:14Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} The FS20 / FHT system by ELV is currently the most successful wireless home control system in the low cost sector. This arises from the large number of components and the continuous expansion of the system. But the relatively low price, the comprehensive home control systems far below the price of such EIB systems permits, plays a crucial role. This FS20 modul is based on [http://culfw.de CULFW by Rudolf Koenig] and supports a wide range of protocols: * FS20: send/receive<br>There are numerous FS20 devices, all of them are fully supported. * FHT: send/receivey<br>Communication to the FHT80b is supported. * S300: receive<br>Examples of such devices: S300TH, KS300-2 * EM1000: receive<br>Devices: EM1000FM, EM1000GZ, EM1000WZ * HMS: receive<br>Devices: There are numerous HMS devices, all of them are fully supported. * ESA2000: receive * Lacrosse TX2/TX3: receive == Connection == The RFM12 is connected to the MCU like in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FSK/DATA/nFSS signal (Pin 3) is connected to one of the INT pins of the MCU. The software uses the digital filter of the RFM12. In order to receive near and far sender as well. To improve sensitivity on short and long distances the [http://jeelabs.net/projects/cafe/wiki/Receiving_OOKASK_with_a_modified_RFM12B C_arssi capacitor needs to be replaced] with a value 150 pf. == Configuration == [[Category:RFM12]] dfabfc393cc800049c35ec222313c8963218846e 969 968 2013-03-11T07:30:09Z GooPie4o 265 /* Connection */ wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} The FS20 / FHT system by ELV is currently the most successful wireless home control system in the low cost sector. This arises from the large number of components and the continuous expansion of the system. But the relatively low price, the comprehensive home control systems far below the price of such EIB systems permits, plays a crucial role. This FS20 modul is based on [http://culfw.de CULFW by Rudolf Koenig] and supports a wide range of protocols: * FS20: send/receive<br>There are numerous FS20 devices, all of them are fully supported. * FHT: send/receivey<br>Communication to the FHT80b is supported. * S300: receive<br>Examples of such devices: S300TH, KS300-2 * EM1000: receive<br>Devices: EM1000FM, EM1000GZ, EM1000WZ * HMS: receive<br>Devices: There are numerous HMS devices, all of them are fully supported. * ESA2000: receive * Lacrosse TX2/TX3: receive == Connection == The RFM12 is connected to the MCU like in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FSK/DATA/nFSS signal (Pin 3) is connected to one of the INT pins of the MCU. The software uses the digital filter of the RFM12. To improve sensitivity on short and long distances the [http://jeelabs.net/projects/cafe/wiki/Receiving_OOKASK_with_a_modified_RFM12B C_arssi capacitor needs to be replaced] with a value 150 pf. == Configuration == [[Category:RFM12]] 357745b2ec222674432f902de4ff173810541456 970 969 2013-03-11T07:30:43Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} The FS20 / FHT system by ELV is currently the most successful wireless home control system in the low cost sector. This arises from the large number of components and the continuous expansion of the system. But the relatively low price, the comprehensive home control systems far below the price of such EIB systems permits, plays a crucial role. This FS20 modul is based on [http://culfw.de CULFW by Rudolf Koenig] and supports a wide range of protocols: * FS20: send/receive<br>There are numerous FS20 devices, all of them are fully supported. * FHT: send/receive<br>Communication to the FHT80b is supported. * S300: receive<br>Examples of such devices: S300TH, KS300-2 * EM1000: receive<br>Devices: EM1000FM, EM1000GZ, EM1000WZ * HMS: receive<br>Devices: There are numerous HMS devices, all of them are fully supported. * ESA2000: receive * Lacrosse TX2/TX3: receive == Connection == The RFM12 is connected to the MCU like in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FSK/DATA/nFSS signal (Pin 3) is connected to one of the INT pins of the MCU. The software uses the digital filter of the RFM12. To improve sensitivity on short and long distances the [http://jeelabs.net/projects/cafe/wiki/Receiving_OOKASK_with_a_modified_RFM12B C_arssi capacitor needs to be replaced] with a value 150 pf. == Configuration == [[Category:RFM12]] 1796422c9e2086083a766c33663391bf1a88a834 972 970 2013-03-11T09:40:13Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} The FS20 / FHT system by ELV is currently the most successful wireless home control system in the low cost sector. This arises from the large number of components and the continuous expansion of the system. But the relatively low price, the comprehensive home control systems far below the price of such EIB systems permits, plays a crucial role. This FS20 modul is based on [http://culfw.de CULFW by Rudolf Koenig] and supports a wide range of protocols: * FS20: send/receive<br>There are numerous FS20 devices, all of them are fully supported. * FHT: send/receive<br>Communication to the FHT80b is supported. * S300: receive<br>Examples of such devices: S300TH, KS300-2 * EM1000: receive<br>Devices: EM1000FM, EM1000GZ, EM1000WZ * HMS: receive<br>Devices: There are numerous HMS devices, all of them are fully supported. * ESA2000: receive * Lacrosse TX2/TX3: receive == Connection == The RFM12 is connected to the ATmegalike in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FSK/DATA/nFSS signal (Pin 3) is connected to one of the INT pins of the ATmega. The software uses the digital filter of the RFM12. To improve sensitivity on short and long distances the [http://jeelabs.net/projects/cafe/wiki/Receiving_OOKASK_with_a_modified_RFM12B C_arssi capacitor needs to be replaced] with a value 150 pf. == Configuration == The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_FS20_USE_INT(1) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_USE_INT defines whether FSK/DATA/nFSS is connected to INT0, INT1 or INT2 of the ATmega. [[Category:RFM12]] 5cbfff3485fcba247b0643b489c2e00350ee21f6 973 972 2013-03-11T09:40:48Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} The FS20 / FHT system by ELV is currently the most successful wireless home control system in the low cost sector. This arises from the large number of components and the continuous expansion of the system. But the relatively low price, the comprehensive home control systems far below the price of such EIB systems permits, plays a crucial role. This FS20 modul is based on [http://culfw.de CULFW by Rudolf Koenig] and supports a wide range of protocols: * FS20: send/receive<br>There are numerous FS20 devices, all of them are fully supported. * FHT: send/receive<br>Communication to the FHT80b is supported. * S300: receive<br>Examples of such devices: S300TH, KS300-2 * EM1000: receive<br>Devices: EM1000FM, EM1000GZ, EM1000WZ * HMS: receive<br>Devices: There are numerous HMS devices, all of them are fully supported. * ESA2000: receive * Lacrosse TX2/TX3: receive == Connection == The RFM12 is connected to the ATmegalike in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FSK/DATA/nFSS signal (Pin 3) is connected to one of the INT pins of the ATmega. The software uses the digital filter of the RFM12. To improve sensitivity on short and long distances the [http://jeelabs.net/projects/cafe/wiki/Receiving_OOKASK_with_a_modified_RFM12B C_arssi capacitor needs to be replaced] with a value 150 pf. The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_FS20_USE_INT(1) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_USE_INT defines whether FSK/DATA/nFSS is connected to INT0, INT1 or INT2 of the ATmega. == Configuration == [[Category:RFM12]] cc9b7c9e8ee7c68655e64a2f7332ea0eb76f1175 974 973 2013-03-11T09:41:35Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} The FS20 / FHT system by ELV is currently the most successful wireless home control system in the low cost sector. This arises from the large number of components and the continuous expansion of the system. But the relatively low price, the comprehensive home control systems far below the price of such EIB systems permits, plays a crucial role. This FS20 modul is based on [http://culfw.de CULFW by Rudolf Koenig] and supports a wide range of protocols: * FS20: send/receive<br>There are numerous FS20 devices, all of them are fully supported. * FHT: send/receive<br>Communication to the FHT80b is supported. * S300: receive<br>Examples of such devices: S300TH, KS300-2 * EM1000: receive<br>Devices: EM1000FM, EM1000GZ, EM1000WZ * HMS: receive<br>Devices: There are numerous HMS devices, all of them are fully supported. * ESA2000: receive * Lacrosse TX2/TX3: receive == Connection == The RFM12 is connected to the ATmegalike in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FSK/DATA/nFSS signal (Pin 3) is connected to one of the INT pins of the ATmega. The software uses the digital filter of the RFM12. To improve sensitivity on short and long distances the [http://jeelabs.net/projects/cafe/wiki/Receiving_OOKASK_with_a_modified_RFM12B C_arssi capacitor needs to be replaced] with a value 150 pf. The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_FS20_USE_INT(1) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_FS20_USE_INT defines whether FSK/DATA/nFSS is connected to INT0, INT1 or INT2 of the ATmega. == Configuration == [[Category:RFM12]] 1b91057df5d44fc1c8c44c8d0102223996f5e338 977 974 2013-03-11T13:52:47Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} The FS20 / FHT system by ELV is currently the most successful wireless home control system in the low cost sector. This arises from the large number of components and the continuous expansion of the system. But the relatively low price, the comprehensive home control systems far below the price of such EIB systems permits, plays a crucial role. This FS20 modul is based on [http://culfw.de CULFW by Rudolf Koenig] and supports a wide range of protocols: * FS20: send/receive<br>There are numerous FS20 devices, all of them are fully supported. * FHT: send/receive<br>Communication to the FHT80b is supported. * S300: receive<br>Examples of such devices: S300TH, KS300-2 * EM1000: receive<br>Devices: EM1000FM, EM1000GZ, EM1000WZ * HMS: receive<br>Devices: There are numerous HMS devices, all of them are fully supported. * ESA2000: receive * Lacrosse TX2/TX3: receive == Connection == The RFM12 is connected to the ATmega like in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FSK/DATA/nFSS signal (Pin 3) is connected to one of the INT pins of the ATmega. The software uses the digital filter of the RFM12. To improve sensitivity on short and long distances the [http://jeelabs.net/projects/cafe/wiki/Receiving_OOKASK_with_a_modified_RFM12B C_arssi capacitor needs to be replaced] with a value 150 pf. The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_FS20_USE_INT(1) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_FS20_USE_INT defines whether FSK/DATA/nFSS is connected to INT0, INT1 or INT2 of the ATmega. == Configuration == [[Category:RFM12]] 238070c17adad5fed735b606d5f70ca95bb2ff5a 978 977 2013-03-11T17:44:44Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} The FS20 / FHT system by ELV is currently the most successful wireless home control system in the low cost sector. This arises from the large number of components and the continuous expansion of the system. But the relatively low price, the comprehensive home control systems far below the price of such EIB systems permits, plays a crucial role. This FS20 modul is based on [http://culfw.de CULFW by Rudolf Koenig] and supports a wide range of protocols: * FS20: send/receive<br>There are numerous FS20 devices, all of them are fully supported. * FHT: send/receive<br>Communication to the FHT80b is supported. * S300: receive<br>Examples of such devices: S300TH, KS300-2 * EM1000: receive<br>Devices: EM1000FM, EM1000GZ, EM1000WZ * HMS: receive<br>Devices: There are numerous HMS devices, all of them are fully supported. * ESA2000: receive * Lacrosse TX2/TX3: receive == Connection == The RFM12 is connected to the ATmega like in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FSK/DATA/nFSS signal (Pin 3) is connected to one of the INT pins of the ATmega. The software uses the digital filter of the RFM12. To improve sensitivity on short and long distances the [http://jeelabs.net/projects/cafe/wiki/Receiving_OOKASK_with_a_modified_RFM12B C_arssi capacitor needs to be replaced] with a value 150 pf. The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_FS20_USE_INT(1) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_FS20_USE_INT defines whether FSK/DATA/nFSS is connected to INT0, INT1 or INT2 of the ATmega. == Configuration == The FS20 system sends on 868,35 MHz, so the 868MHz option is right one. | | I/O ---> | | ... | | [*] RFM12 ASK ---> | | ... | | [ ] 433MHz | | | | [-] Pollin/Kangtai Powerswitch (IC 2272) | | | | [-] Pollin Powerswitch buried (IC 1527) | | | | [-] Tevion Powerswitch | | | | [-] Intertechno ITS-150 | | | | [-] External filter | | | | [-] Sensing | | | | --- | | | | [*] 868MHz | | | | (0) RFM12 select | | | | [*] FS20 | | | | [*] FHT | | | | [*] ESA | | | | --- Debugging Flags | | | | [-] Sensing | | | | [ ] FS20 | | == [[ECMD]] == [[Category:RFM12]] f7e793bef8c7ee27d9f42fdbe63211aed4d1bcae 979 978 2013-03-11T17:45:19Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} The FS20 / FHT system by ELV is currently the most successful wireless home control system in the low cost sector. This arises from the large number of components and the continuous expansion of the system. But the relatively low price, the comprehensive home control systems far below the price of such EIB systems permits, plays a crucial role. This FS20 modul is based on [http://culfw.de CULFW by Rudolf Koenig] and supports a wide range of protocols: * FS20: send/receive<br>There are numerous FS20 devices, all of them are fully supported. * FHT: send/receive<br>Communication to the FHT80b is supported. * S300: receive<br>Examples of such devices: S300TH, KS300-2 * EM1000: receive<br>Devices: EM1000FM, EM1000GZ, EM1000WZ * HMS: receive<br>Devices: There are numerous HMS devices, all of them are fully supported. * ESA2000: receive * Lacrosse TX2/TX3: receive == Connection == The RFM12 is connected to the ATmega like in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FSK/DATA/nFSS signal (Pin 3) is connected to one of the INT pins of the ATmega. The software uses the digital filter of the RFM12. To improve sensitivity on short and long distances the [http://jeelabs.net/projects/cafe/wiki/Receiving_OOKASK_with_a_modified_RFM12B C_arssi capacitor needs to be replaced] with a value 150 pf. The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_FS20_USE_INT(1) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_FS20_USE_INT defines whether FSK/DATA/nFSS is connected to INT0, INT1 or INT2 of the ATmega. == Configuration == The FS20 system sends on 868,35 MHz, so the 868MHz option is right one. | | I/O ---> | | ... | | [*] RFM12 ASK ---> | | ... | | [ ] 433MHz | | | | [-] Pollin/Kangtai Powerswitch (IC 2272) | | | | [-] Pollin Powerswitch buried (IC 1527) | | | | [-] Tevion Powerswitch | | | | [-] Intertechno ITS-150 | | | | [-] External filter | | | | [-] Sensing | | | | --- | | | | [*] 868MHz | | | | (0) RFM12 select | | | | [*] FS20 | | | | [*] FHT | | | | [*] ESA | | | | --- Debugging Flags | | | | [-] Sensing | | | | [ ] FS20 | | == [[ECMD]] == [[Category:RFM12]] 1b3a7afee242605fad63a2638ceb40e7102ef4d5 980 979 2013-03-11T17:46:00Z GooPie4o 265 /* Configuration */ wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} The FS20 / FHT system by ELV is currently the most successful wireless home control system in the low cost sector. This arises from the large number of components and the continuous expansion of the system. But the relatively low price, the comprehensive home control systems far below the price of such EIB systems permits, plays a crucial role. This FS20 modul is based on [http://culfw.de CULFW by Rudolf Koenig] and supports a wide range of protocols: * FS20: send/receive<br>There are numerous FS20 devices, all of them are fully supported. * FHT: send/receive<br>Communication to the FHT80b is supported. * S300: receive<br>Examples of such devices: S300TH, KS300-2 * EM1000: receive<br>Devices: EM1000FM, EM1000GZ, EM1000WZ * HMS: receive<br>Devices: There are numerous HMS devices, all of them are fully supported. * ESA2000: receive * Lacrosse TX2/TX3: receive == Connection == The RFM12 is connected to the ATmega like in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FSK/DATA/nFSS signal (Pin 3) is connected to one of the INT pins of the ATmega. The software uses the digital filter of the RFM12. To improve sensitivity on short and long distances the [http://jeelabs.net/projects/cafe/wiki/Receiving_OOKASK_with_a_modified_RFM12B C_arssi capacitor needs to be replaced] with a value 150 pf. The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_FS20_USE_INT(1) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_FS20_USE_INT defines whether FSK/DATA/nFSS is connected to INT0, INT1 or INT2 of the ATmega. == Configuration == The FS20 system sends on 868,35 MHz, so the 868MHz option is the right one. | | I/O ---> | | ... | | [*] RFM12 ASK ---> | | ... | | [ ] 433MHz | | | | [-] Pollin/Kangtai Powerswitch (IC 2272) | | | | [-] Pollin Powerswitch buried (IC 1527) | | | | [-] Tevion Powerswitch | | | | [-] Intertechno ITS-150 | | | | [-] External filter | | | | [-] Sensing | | | | --- | | | | [*] 868MHz | | | | (0) RFM12 select | | | | [*] FS20 | | | | [*] FHT | | | | [*] ESA | | | | --- Debugging Flags | | | | [-] Sensing | | | | [ ] FS20 | | == [[ECMD]] == [[Category:RFM12]] e39668aae9134f55ff93ea6d5f8b0342871f2f5d 983 980 2013-03-12T06:05:42Z GooPie4o 265 /* ECMD */ wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} The FS20 / FHT system by ELV is currently the most successful wireless home control system in the low cost sector. This arises from the large number of components and the continuous expansion of the system. But the relatively low price, the comprehensive home control systems far below the price of such EIB systems permits, plays a crucial role. This FS20 modul is based on [http://culfw.de CULFW by Rudolf Koenig] and supports a wide range of protocols: * FS20: send/receive<br>There are numerous FS20 devices, all of them are fully supported. * FHT: send/receive<br>Communication to the FHT80b is supported. * S300: receive<br>Examples of such devices: S300TH, KS300-2 * EM1000: receive<br>Devices: EM1000FM, EM1000GZ, EM1000WZ * HMS: receive<br>Devices: There are numerous HMS devices, all of them are fully supported. * ESA2000: receive * Lacrosse TX2/TX3: receive == Connection == The RFM12 is connected to the ATmega like in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FSK/DATA/nFSS signal (Pin 3) is connected to one of the INT pins of the ATmega. The software uses the digital filter of the RFM12. To improve sensitivity on short and long distances the [http://jeelabs.net/projects/cafe/wiki/Receiving_OOKASK_with_a_modified_RFM12B C_arssi capacitor needs to be replaced] with a value 150 pf. The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_FS20_USE_INT(1) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_FS20_USE_INT defines whether FSK/DATA/nFSS is connected to INT0, INT1 or INT2 of the ATmega. == Configuration == The FS20 system sends on 868,35 MHz, so the 868MHz option is the right one. | | I/O ---> | | ... | | [*] RFM12 ASK ---> | | ... | | [ ] 433MHz | | | | [-] Pollin/Kangtai Powerswitch (IC 2272) | | | | [-] Pollin Powerswitch buried (IC 1527) | | | | [-] Tevion Powerswitch | | | | [-] Intertechno ITS-150 | | | | [-] External filter | | | | [-] Sensing | | | | --- | | | | [*] 868MHz | | | | (0) RFM12 select | | | | [*] FS20 | | | | [*] FHT | | | | [*] ESA | | | | --- Debugging Flags | | | | [-] Sensing | | | | [ ] FS20 | | == [[ECMD]] == RFM12 FS20 implements an ECMD interface for send FS20/FHT commands. See ECMD reference. [[Category:RFM12]] c92f21f74fb25f1b7515f66d9b34511838ef63bd 984 983 2013-03-12T06:06:09Z GooPie4o 265 /* ECMD */ wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} The FS20 / FHT system by ELV is currently the most successful wireless home control system in the low cost sector. This arises from the large number of components and the continuous expansion of the system. But the relatively low price, the comprehensive home control systems far below the price of such EIB systems permits, plays a crucial role. This FS20 modul is based on [http://culfw.de CULFW by Rudolf Koenig] and supports a wide range of protocols: * FS20: send/receive<br>There are numerous FS20 devices, all of them are fully supported. * FHT: send/receive<br>Communication to the FHT80b is supported. * S300: receive<br>Examples of such devices: S300TH, KS300-2 * EM1000: receive<br>Devices: EM1000FM, EM1000GZ, EM1000WZ * HMS: receive<br>Devices: There are numerous HMS devices, all of them are fully supported. * ESA2000: receive * Lacrosse TX2/TX3: receive == Connection == The RFM12 is connected to the ATmega like in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FSK/DATA/nFSS signal (Pin 3) is connected to one of the INT pins of the ATmega. The software uses the digital filter of the RFM12. To improve sensitivity on short and long distances the [http://jeelabs.net/projects/cafe/wiki/Receiving_OOKASK_with_a_modified_RFM12B C_arssi capacitor needs to be replaced] with a value 150 pf. The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_FS20_USE_INT(1) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_FS20_USE_INT defines whether FSK/DATA/nFSS is connected to INT0, INT1 or INT2 of the ATmega. == Configuration == The FS20 system sends on 868,35 MHz, so the 868MHz option is the right one. | | I/O ---> | | ... | | [*] RFM12 ASK ---> | | ... | | [ ] 433MHz | | | | [-] Pollin/Kangtai Powerswitch (IC 2272) | | | | [-] Pollin Powerswitch buried (IC 1527) | | | | [-] Tevion Powerswitch | | | | [-] Intertechno ITS-150 | | | | [-] External filter | | | | [-] Sensing | | | | --- | | | | [*] 868MHz | | | | (0) RFM12 select | | | | [*] FS20 | | | | [*] FHT | | | | [*] ESA | | | | --- Debugging Flags | | | | [-] Sensing | | | | [ ] FS20 | | == [[ECMD]] == RFM12 FS20 implements an ECMD interface for send FS20/FHT commands. See [[ECMD_Reference|ECMD reference]]. [[Category:RFM12]] 4399d1de21c3f42155978accf8d0a3aa404f37a5 986 984 2013-03-12T06:08:07Z GooPie4o 265 /* ECMD */ wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} The FS20 / FHT system by ELV is currently the most successful wireless home control system in the low cost sector. This arises from the large number of components and the continuous expansion of the system. But the relatively low price, the comprehensive home control systems far below the price of such EIB systems permits, plays a crucial role. This FS20 modul is based on [http://culfw.de CULFW by Rudolf Koenig] and supports a wide range of protocols: * FS20: send/receive<br>There are numerous FS20 devices, all of them are fully supported. * FHT: send/receive<br>Communication to the FHT80b is supported. * S300: receive<br>Examples of such devices: S300TH, KS300-2 * EM1000: receive<br>Devices: EM1000FM, EM1000GZ, EM1000WZ * HMS: receive<br>Devices: There are numerous HMS devices, all of them are fully supported. * ESA2000: receive * Lacrosse TX2/TX3: receive == Connection == The RFM12 is connected to the ATmega like in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FSK/DATA/nFSS signal (Pin 3) is connected to one of the INT pins of the ATmega. The software uses the digital filter of the RFM12. To improve sensitivity on short and long distances the [http://jeelabs.net/projects/cafe/wiki/Receiving_OOKASK_with_a_modified_RFM12B C_arssi capacitor needs to be replaced] with a value 150 pf. The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_FS20_USE_INT(1) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_FS20_USE_INT defines whether FSK/DATA/nFSS is connected to INT0, INT1 or INT2 of the ATmega. == Configuration == The FS20 system sends on 868,35 MHz, so the 868MHz option is the right one. | | I/O ---> | | ... | | [*] RFM12 ASK ---> | | ... | | [ ] 433MHz | | | | [-] Pollin/Kangtai Powerswitch (IC 2272) | | | | [-] Pollin Powerswitch buried (IC 1527) | | | | [-] Tevion Powerswitch | | | | [-] Intertechno ITS-150 | | | | [-] External filter | | | | [-] Sensing | | | | --- | | | | [*] 868MHz | | | | (0) RFM12 select | | | | [*] FS20 | | | | [*] FHT | | | | [*] ESA | | | | --- Debugging Flags | | | | [-] Sensing | | | | [ ] FS20 | | == [[ECMD]] == RFM12 FS20 implements an [[ECMD]] interface for send FS20/FHT commands. See [[ECMD_Reference|ECMD reference]]. [[Category:RFM12]] ad46ad6b1ca30350b2e643ad26b89a9fd1b0a2cc 987 986 2013-03-12T06:11:26Z GooPie4o 265 /* Connection */ wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} The FS20 / FHT system by ELV is currently the most successful wireless home control system in the low cost sector. This arises from the large number of components and the continuous expansion of the system. But the relatively low price, the comprehensive home control systems far below the price of such EIB systems permits, plays a crucial role. This FS20 modul is based on [http://culfw.de CULFW by Rudolf Koenig] and supports a wide range of protocols: * FS20: send/receive<br>There are numerous FS20 devices, all of them are fully supported. * FHT: send/receive<br>Communication to the FHT80b is supported. * S300: receive<br>Examples of such devices: S300TH, KS300-2 * EM1000: receive<br>Devices: EM1000FM, EM1000GZ, EM1000WZ * HMS: receive<br>Devices: There are numerous HMS devices, all of them are fully supported. * ESA2000: receive * Lacrosse TX2/TX3: receive == Connection == The RFM12 is connected to the AVRlike in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FSK/DATA/nFSS signal (Pin 3) is connected to one of the INT pins of the AVR. This modul does not work in interrupt mode, so the output nRQ signal (Pin 2) can be left unconnected. The software uses the digital filter of the RFM12. To improve sensitivity on short and long distances the [http://jeelabs.net/projects/cafe/wiki/Receiving_OOKASK_with_a_modified_RFM12B C_arssi capacitor needs to be replaced] with a value 150 pf. The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_FS20_USE_INT(1) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_FS20_USE_INT defines whether FSK/DATA/nFSS is connected to INT0, INT1 or INT2 of the AVR. == Configuration == The FS20 system sends on 868,35 MHz, so the 868MHz option is the right one. | | I/O ---> | | ... | | [*] RFM12 ASK ---> | | ... | | [ ] 433MHz | | | | [-] Pollin/Kangtai Powerswitch (IC 2272) | | | | [-] Pollin Powerswitch buried (IC 1527) | | | | [-] Tevion Powerswitch | | | | [-] Intertechno ITS-150 | | | | [-] External filter | | | | [-] Sensing | | | | --- | | | | [*] 868MHz | | | | (0) RFM12 select | | | | [*] FS20 | | | | [*] FHT | | | | [*] ESA | | | | --- Debugging Flags | | | | [-] Sensing | | | | [ ] FS20 | | == [[ECMD]] == RFM12 FS20 implements an [[ECMD]] interface for send FS20/FHT commands. See [[ECMD_Reference|ECMD reference]]. [[Category:RFM12]] 7d2a4eebada13939b24795a4540e95b342e8c657 994 987 2013-03-12T07:15:16Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} The FS20 / FHT system by ELV is currently the most successful wireless home control system in the low cost sector. This arises from the large number of components and the continuous expansion of the system. But the relatively low price, the comprehensive home control systems far below the price of such EIB systems permits, plays a crucial role. This modul is based on [http://culfw.de CULFW by Rudolf Koenig] and supports a wide range of protocols: * FS20: send/receive<br>There are numerous FS20 devices, all of them are fully supported. * FHT: send/receive<br>Communication to the FHT80b is supported. * S300: receive<br>Examples of such devices: S300TH, KS300-2 * EM1000: receive<br>Devices: EM1000FM, EM1000GZ, EM1000WZ * HMS: receive<br>Devices: There are numerous HMS devices, all of them are fully supported. * ESA2000: receive * Lacrosse TX2/TX3: receive == Connection == The RFM12 is connected to the AVRlike in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FSK/DATA/nFSS signal (Pin 3) is connected to one of the INT pins of the AVR. This modul does not work in interrupt mode, so the output nRQ signal (Pin 2) can be left unconnected. The software uses the digital filter of the RFM12. To improve sensitivity on short and long distances the [http://jeelabs.net/projects/cafe/wiki/Receiving_OOKASK_with_a_modified_RFM12B C_arssi capacitor needs to be replaced] with a value 150 pf. The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_FS20_USE_INT(1) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_FS20_USE_INT defines whether FSK/DATA/nFSS is connected to INT0, INT1 or INT2 of the AVR. == Configuration == The FS20 system sends on 868,35 MHz, so the 868MHz option is the right one. | | I/O ---> | | ... | | [*] RFM12 ASK ---> | | ... | | [ ] 433MHz | | | | [-] Pollin/Kangtai Powerswitch (IC 2272) | | | | [-] Pollin Powerswitch buried (IC 1527) | | | | [-] Tevion Powerswitch | | | | [-] Intertechno ITS-150 | | | | [-] External filter | | | | [-] Sensing | | | | --- | | | | [*] 868MHz | | | | (0) RFM12 select | | | | [*] FS20 | | | | [*] FHT | | | | [*] ESA | | | | --- Debugging Flags | | | | [-] Sensing | | | | [ ] FS20 | | == [[ECMD]] == RFM12 FS20 implements an [[ECMD]] interface for send FS20/FHT commands. See [[ECMD_Reference|ECMD reference]]. [[Category:RFM12]] 309f166dc7b42f7300f64db95b3d362a80ec98b7 996 994 2013-03-12T07:16:05Z GooPie4o 265 /* Connection */ wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} The FS20 / FHT system by ELV is currently the most successful wireless home control system in the low cost sector. This arises from the large number of components and the continuous expansion of the system. But the relatively low price, the comprehensive home control systems far below the price of such EIB systems permits, plays a crucial role. This modul is based on [http://culfw.de CULFW by Rudolf Koenig] and supports a wide range of protocols: * FS20: send/receive<br>There are numerous FS20 devices, all of them are fully supported. * FHT: send/receive<br>Communication to the FHT80b is supported. * S300: receive<br>Examples of such devices: S300TH, KS300-2 * EM1000: receive<br>Devices: EM1000FM, EM1000GZ, EM1000WZ * HMS: receive<br>Devices: There are numerous HMS devices, all of them are fully supported. * ESA2000: receive * Lacrosse TX2/TX3: receive == Connection == The RFM12 is connected to the AVR like in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FSK/DATA/nFSS signal (Pin 3) is connected to one of the INT pins of the AVR. This modul does not work in interrupt mode, so the output nRQ signal (Pin 2) can be left unconnected. The software uses the digital filter of the RFM12. To improve sensitivity on short and long distances the [http://jeelabs.net/projects/cafe/wiki/Receiving_OOKASK_with_a_modified_RFM12B C_arssi capacitor needs to be replaced] with a value 150 pf. The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_FS20_USE_INT(1) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_FS20_USE_INT defines whether FSK/DATA/nFSS is connected to INT0, INT1 or INT2 of the AVR. == Configuration == The FS20 system sends on 868,35 MHz, so the 868MHz option is the right one. | | I/O ---> | | ... | | [*] RFM12 ASK ---> | | ... | | [ ] 433MHz | | | | [-] Pollin/Kangtai Powerswitch (IC 2272) | | | | [-] Pollin Powerswitch buried (IC 1527) | | | | [-] Tevion Powerswitch | | | | [-] Intertechno ITS-150 | | | | [-] External filter | | | | [-] Sensing | | | | --- | | | | [*] 868MHz | | | | (0) RFM12 select | | | | [*] FS20 | | | | [*] FHT | | | | [*] ESA | | | | --- Debugging Flags | | | | [-] Sensing | | | | [ ] FS20 | | == [[ECMD]] == RFM12 FS20 implements an [[ECMD]] interface for send FS20/FHT commands. See [[ECMD_Reference|ECMD reference]]. [[Category:RFM12]] 12255c7aaee4e5d561ad6892de6703bdc0263305 999 996 2013-03-21T09:19:00Z GooPie4o 265 /* Configuration */ wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} The FS20 / FHT system by ELV is currently the most successful wireless home control system in the low cost sector. This arises from the large number of components and the continuous expansion of the system. But the relatively low price, the comprehensive home control systems far below the price of such EIB systems permits, plays a crucial role. This modul is based on [http://culfw.de CULFW by Rudolf Koenig] and supports a wide range of protocols: * FS20: send/receive<br>There are numerous FS20 devices, all of them are fully supported. * FHT: send/receive<br>Communication to the FHT80b is supported. * S300: receive<br>Examples of such devices: S300TH, KS300-2 * EM1000: receive<br>Devices: EM1000FM, EM1000GZ, EM1000WZ * HMS: receive<br>Devices: There are numerous HMS devices, all of them are fully supported. * ESA2000: receive * Lacrosse TX2/TX3: receive == Connection == The RFM12 is connected to the AVR like in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FSK/DATA/nFSS signal (Pin 3) is connected to one of the INT pins of the AVR. This modul does not work in interrupt mode, so the output nRQ signal (Pin 2) can be left unconnected. The software uses the digital filter of the RFM12. To improve sensitivity on short and long distances the [http://jeelabs.net/projects/cafe/wiki/Receiving_OOKASK_with_a_modified_RFM12B C_arssi capacitor needs to be replaced] with a value 150 pf. The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_FS20_USE_INT(1) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_FS20_USE_INT defines whether FSK/DATA/nFSS is connected to INT0, INT1 or INT2 of the AVR. == Configuration == The FS20 system sends on 868,35 MHz, so the 868MHz option is the right one. | | I/O ---> | | ... | | [*] RFM12 ASK ---> | | ... | | [ ] 433MHz | | | | [-] Pollin/Kangtai Powerswitch (IC 2272) | | | | [-] Pollin Powerswitch buried (IC 1527) | | | | [-] Tevion Powerswitch | | | | [-] Intertechno ITS-150 | | | | [-] External filter | | | | [-] Sensing | | | | --- | | | | [*] 868MHz | | | | (0) RFM12 select | | | | [*] FS20 | | | | [*] FHT | | | | [*] ESA | | | | [ ] TX3 | | | | --- Debugging Flags | | | | [-] Sensing | | | | [ ] FS20 | | == [[ECMD]] == RFM12 FS20 implements an [[ECMD]] interface for send FS20/FHT commands. See [[ECMD_Reference|ECMD reference]]. [[Category:RFM12]] a101c1b139fec2c36f0fc65b8abfe027931149f7 0 338 963 937 2013-03-11T06:56:00Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{I/O}}->RFM12 ASK->433MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} In ASK mode the RFM12 module ist used to switch radio outlets. Alternatively you can also receive the radio transmission between the transmitter and radio socket outlet. Currently, the following systems are supported: * Self-learning systems (drive "tevion") * Systems based on the chips or PT2262/PT2272 HX2262/2272 (driver "2272") * Concealed remote dimmer with the transmitter located HS1527 chip (driver "1527") * Transmitter type Intertechno ITS-150 * Oase Inscenio FM Master system [[Category:RFM12]] b0d982d1bce140c95a543518ffbcb90722ccd45f 975 963 2013-03-11T09:50:45Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{I/O}}->RFM12 ASK->433MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} In ASK mode the RFM12 module ist used to switch radio outlets. Alternatively you can also receive the radio transmission between the transmitter and radio socket outlet. Currently, the following systems are supported: * Self-learning systems (drive "tevion") * Systems based on the chips or PT2262/PT2272 HX2262/2272 (driver "2272") * Concealed remote dimmer with the transmitter located HS1527 chip (driver "1527") * Transmitter type Intertechno ITS-150 * Oase Inscenio FM Master system == Connection == The RFM12 is connected to the ATmegalike in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FFIT signal (Pin 4) is connected to one of the INT pins of the ATmega. The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_ASK_SENSE_USE_INT(0) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_ASK_SENSE_USE_INT defines whether FFIT is connected to INT0, INT1 or INT2 of the ATmega. == Configuration == [[Category:RFM12]] 4d825397712275b8cc6095545e62fa2af59c554d 976 975 2013-03-11T13:52:24Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{I/O}}->RFM12 ASK->433MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} In ASK mode the RFM12 module ist used to switch radio outlets. Alternatively you can also receive the radio transmission between the transmitter and radio socket outlet. Currently, the following systems are supported: * Self-learning systems (drive "tevion") * Systems based on the chips or PT2262/PT2272 HX2262/2272 (driver "2272") * Concealed remote dimmer with the transmitter located HS1527 chip (driver "1527") * Transmitter type Intertechno ITS-150 * Oase Inscenio FM Master system == Connection == The RFM12 is connected to the ATmega like in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FFIT signal (Pin 4) is connected to one of the INT pins of the ATmega. The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_ASK_SENSE_USE_INT(0) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_ASK_SENSE_USE_INT defines whether FFIT is connected to INT0, INT1 or INT2 of the ATmega. == Configuration == [[Category:RFM12]] b5c8fbc6ac83e394e5d7065abe5dafaacc572e99 981 976 2013-03-11T17:57:46Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{I/O}}->RFM12 ASK->433MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} In ASK mode the RFM12 module ist used to switch radio outlets. Alternatively you can also receive the radio transmission between the transmitter and radio socket outlet. Currently, the following systems are supported: * Self-learning systems (drive "tevion") * Systems based on the chips or PT2262/PT2272 HX2262/2272 (driver "2272") * Concealed remote dimmer with the transmitter located HS1527 chip (driver "1527") * Transmitter type Intertechno ITS-150 * Oase Inscenio FM Master system == Connection == The RFM12 is connected to the ATmega like in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FFIT signal (Pin 4) is connected to one of the INT pins of the ATmega. The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_ASK_SENSE_USE_INT(0) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_ASK_SENSE_USE_INT defines whether FFIT is connected to INT0, INT1 or INT2 of the ATmega. == Configuration == == [[ECMD]] == [[Category:RFM12]] 0afd3a41919d362503bc3eb499139aa137bbb1a9 985 981 2013-03-12T06:07:49Z GooPie4o 265 /* ECMD */ wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{I/O}}->RFM12 ASK->433MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} In ASK mode the RFM12 module ist used to switch radio outlets. Alternatively you can also receive the radio transmission between the transmitter and radio socket outlet. Currently, the following systems are supported: * Self-learning systems (drive "tevion") * Systems based on the chips or PT2262/PT2272 HX2262/2272 (driver "2272") * Concealed remote dimmer with the transmitter located HS1527 chip (driver "1527") * Transmitter type Intertechno ITS-150 * Oase Inscenio FM Master system == Connection == The RFM12 is connected to the ATmega like in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FFIT signal (Pin 4) is connected to one of the INT pins of the ATmega. The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_ASK_SENSE_USE_INT(0) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_ASK_SENSE_USE_INT defines whether FFIT is connected to INT0, INT1 or INT2 of the ATmega. == Configuration == == [[ECMD]] == RFM12 ASKimplements an [[ECMD]] interface to control to switch radio outlets. See [[ECMD_Reference|ECMD reference]]. [[Category:RFM12]] f56acd2db910e705f9a78c4cfb8045336807d0f8 988 985 2013-03-12T06:12:06Z GooPie4o 265 /* Connection */ wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{I/O}}->RFM12 ASK->433MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} In ASK mode the RFM12 module ist used to switch radio outlets. Alternatively you can also receive the radio transmission between the transmitter and radio socket outlet. Currently, the following systems are supported: * Self-learning systems (drive "tevion") * Systems based on the chips or PT2262/PT2272 HX2262/2272 (driver "2272") * Concealed remote dimmer with the transmitter located HS1527 chip (driver "1527") * Transmitter type Intertechno ITS-150 * Oase Inscenio FM Master system == Connection == The RFM12 is connected to the AVRlike in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FFIT signal (Pin 4) is connected to one of the INT pins of the AVR. This modul does not work in interrupt mode, so the output nRQ signal (Pin 2) can be left unconnected. The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_ASK_SENSE_USE_INT(0) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_ASK_SENSE_USE_INT defines whether FFIT is connected to INT0, INT1 or INT2 of the AVR. == Configuration == == [[ECMD]] == RFM12 ASKimplements an [[ECMD]] interface to control to switch radio outlets. See [[ECMD_Reference|ECMD reference]]. [[Category:RFM12]] d912e21a1b521a38de031173e9fc8c29325aec3d 0 335 964 926 2013-03-11T06:56:32Z GooPie4o 265 /* Working Mode */ wikitext text/x-wiki {{i18n|RFM12}} RFM12 is a low costing ISM band FSK transceiver module implemented with unique PLL. It works signal ranges from 315/433/868/915MHZ bands. The SPI interface is used to communicate with microcontroller for parameter setting. Features as listed on the [http://www.hoperf.com/ manufactures] site: * low costing, high performance and price ratio * tuning free during production * PLL and zero IF technology * fast PLL lock time * high resolution PLL with 2.5KHz step * high data rate (up to 115.2 kbps with internal demodulator) * differential antenna input * automatic antenna tuning * Programmable TX frequency deviation (15 to 240 KHz) * programmable receiver bandwidth (67 - 400 kHz) * analog and digital signal strength indicater(ARSSI/DRSSI) * AFC * DQD * Internal data filtering and clock recovery * RX synchron pattern recognition * SPI interface * clock and reset signal output for external MCU use * 16 bit RX Data FIFO * Two 8 bit TX data registers * 10MHz crystal for PLL timing * wakeup timer * 2.2V - 5.4V power supply * low power consumption * stand by current less than 0.3µA == Connection == [[Image:Rfm12-chip.jpg]] Detailed information can be found in the [http://www.mikrocontroller.net/articles/RFM12 Miktrocontroller Forum] (German). == Working Modes == For the working modes of the RFM12 Ethersex provides the modules [[RFM12_FSK|FSK]], [[RFM12_ASK|ASK]], and [[RFM12_FS20|FS20]]. [[Category:RFM12]] ec909294e6ded1cf2a26737c4e67f22fc02ed226 0 311 965 903 2013-03-11T07:02:01Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} Das FS20- / FHT-System von ELV ist derzeit das wohl erfolgreichste Funk-Haussteuerungssystem im Niedrigpreissektor. Dies ergibt sich aus der Vielzahl von Komponenten und der ständigen Erweiterung des Systems. Aber auch der relativ günstige Preis, der umfangreiche Haussteuerungen weit unter dem Preis von z.B. EIB-Systemen zulässt, spielt eine entscheidende Rolle. Das FS20 Modul basiert auf [http://culfw.de CULFW von Rudolf Koenig] und unterstützt folgende Protokolle: * FS20: senden/empfangen<br>Es gibt eine Vielzahl von FS20 Geräten, die alle unterstützt werden. * FHT: senden/empfangen<br>Die Kommunication mit FHT80b wird unterstützt. * S300: empfangen<br>Beispiele dieser Geräte: S300TH, KS300-2 * EM1000: empfangen<br>Geräte: EM1000FM, EM1000GZ, EM1000WZ * HMS: empfangen<br>Es gibt eine Vielzahl von FS20 Geräten, die alle unterstützt werden. * ESA2000: empfangen * Lacrosse TX2/TX3: empfangen [[Category:RFM12]] 4213eb8f28bc6c2934a4acd6e46c6bbc1aa58b78 967 965 2013-03-11T07:03:32Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} Das FS20- / FHT-System von ELV ist derzeit das wohl erfolgreichste Funk-Haussteuerungssystem im Niedrigpreissektor. Dies ergibt sich aus der Vielzahl von Komponenten und der ständigen Erweiterung des Systems. Aber auch der relativ günstige Preis, der umfangreiche Haussteuerungen weit unter dem Preis von z.B. EIB-Systemen zulässt, spielt eine entscheidende Rolle. Das FS20 Modul basiert auf [http://culfw.de CULFW von Rudolf Koenig] und unterstützt folgende Protokolle: * FS20: senden/empfangen<br>Es gibt eine Vielzahl von FS20 Geräten, die alle unterstützt werden. * FHT: senden/empfangen<br>Die Kommunication mit FHT80b wird unterstützt. * S300: empfangen<br>Beispiele dieser Geräte: S300TH, KS300-2 * EM1000: empfangen<br>Geräte: EM1000FM, EM1000GZ, EM1000WZ * HMS: empfangen<br>Es gibt eine Vielzahl von HMS Geräten, die alle unterstützt werden. * ESA2000: empfangen * Lacrosse TX2/TX3: empfangen [[Category:RFM12]] dc7f44f928fc6dc4804b2f21eff8f7246aeec9ca 971 967 2013-03-11T09:36:43Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} Das FS20- / FHT-System von ELV ist derzeit das wohl erfolgreichste Funk-Haussteuerungssystem im Niedrigpreissektor. Dies ergibt sich aus der Vielzahl von Komponenten und der ständigen Erweiterung des Systems. Aber auch der relativ günstige Preis, der umfangreiche Haussteuerungen weit unter dem Preis von z.B. EIB-Systemen zulässt, spielt eine entscheidende Rolle. Das FS20 Modul basiert auf [http://culfw.de CULFW von Rudolf Koenig] und unterstützt folgende Protokolle: * FS20: senden/empfangen<br>Es gibt eine Vielzahl von FS20 Geräten, die alle unterstützt werden. * FHT: senden/empfangen<br>Die Kommunikation mit FHT80b wird unterstützt. * S300: empfangen<br>Beispiele dieser Geräte: S300TH, KS300-2 * EM1000: empfangen<br>Geräte: EM1000FM, EM1000GZ, EM1000WZ * HMS: empfangen<br>Es gibt eine Vielzahl von HMS Geräten, die alle unterstützt werden. * ESA2000: empfangen * Lacrosse TX2/TX3: empfangen [[Category:RFM12]] 69dcba055a274fa42df3060e6e240280f3070606 995 971 2013-03-12T07:15:43Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} Das FS20- / FHT-System von ELV ist derzeit das wohl erfolgreichste Funk-Haussteuerungssystem im Niedrigpreissektor. Dies ergibt sich aus der Vielzahl von Komponenten und der ständigen Erweiterung des Systems. Aber auch der relativ günstige Preis, der umfangreiche Haussteuerungen weit unter dem Preis von z.B. EIB-Systemen zulässt, spielt eine entscheidende Rolle. Das Modul basiert auf [http://culfw.de CULFW von Rudolf Koenig] und unterstützt folgende Protokolle: * FS20: senden/empfangen<br>Es gibt eine Vielzahl von FS20 Geräten, die alle unterstützt werden. * FHT: senden/empfangen<br>Die Kommunikation mit FHT80b wird unterstützt. * S300: empfangen<br>Beispiele dieser Geräte: S300TH, KS300-2 * EM1000: empfangen<br>Geräte: EM1000FM, EM1000GZ, EM1000WZ * HMS: empfangen<br>Es gibt eine Vielzahl von HMS Geräten, die alle unterstützt werden. * ESA2000: empfangen * Lacrosse TX2/TX3: empfangen [[Category:RFM12]] 86f31ab91d32118a123c356f21f6204aeedac759 0 29 982 915 2013-03-12T06:04:47Z GooPie4o 265 /* Configuration */ wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR Receivers->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP is a port of the [http://www.mikrocontroller.net/articles/IRMP infrared multi-protocol decoder] for [[Ethersex]]. == Connection == The reception of IR signals is performed by a receiver TSOP1736 type (or similar). This may be connected to any pin. The interrogation of the pins and the decoding of the IR protocol is done in an ISR, which occupies one 8-bit timer of the ATmegas. When sending the signal with the carrier frequency of the respective IR Protocol is [[PWM]] modulated. This is another 8-bit timer of the ATmegas (OC0/OC2) is demonstrated. On the [[Etherrape]] board takes a [[NE555]] this function, ie the option ''Use external modulator for the transmitter'' is activated. It saves a timer on the [[AVR]] is set at a carrier frequency. Example of a ATMega32 from: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Meaning: * IRMP_RX - pin the IR receiver is connected to * IRMP_USE_TIMER2 - use Timer2 for receiver, Timer0 for sender (undef = reversed) * IRMP_RX_LOW_ACTIVE - the IR receiver is low-active (undef = high-active) * IRMP_RX_LED_LOW_ACTIVE - the control LED of the receiver is switched to USS (undef = switched to GND) * IRMP_TX - pin the IR sender is connected to (=output of Timer0 or Timer2, see IRMP_USE_TIMER2)<br>'''Caution: 0A to 2A if MCU with A / B channel''' * IRMP_TX_LED_LOW_ACTIVE - the control LED of the sender is switched to USS (undef = switched to GND) == Configuration == Each supported IR protocol occupies memory of code. Therefore, one should select only the required protocols. A detailed overview of the protocols are in [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail article in the mikrocontroller forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ --- Debugging Flags │ │ [ ] IRMP IRMP also decodes the RC5 protocol, so that the separately [[Ethersex]] contained [[RC5]] decoder is not needed any longer. == [[ECMD]] == IRMP implements an [[ECMD]] interface for reading received and decoded IR commands and send IR commands. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == === Output received characters via [[SYSLOG|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> IRMP_READ checks for received IR code and stores it in the variables IRMP_PROTOCOL, IRMP_ADDRESS, and IRMP_COMMAND IRMP_FLAGS. Return values ​​greater than zero indicate the validity of the variables. If IRMP_FLAGS = 1 it is a repetition. === Control of [[StellaLight|Stella]]/Pins by IR commands === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> The script switches the Stella channel 0 to 255 or 0, the remote control is a Denon (Protocol 8). With ''include'' access to the Stella sources granted.<br> Instead of ''"stella_setValue (STELLA_SET_IMMEDIATELY, 0, 255);"'' ''"PIN_SET (LED)"'' and ''"PIN_CLEAR (LED)"'' can be used ([[Named_PIN|named pin]]). |Named PIN]]). === Send IR commands === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON dnl 31 = BOSE dnl 32 = A1TVBOX IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Command 5678 to device 1234 will be send with one repetition using the NEC protocol. e97d417f3c4141e7e7841698d3ef5cdc9a574377 0 342 992 912 2013-03-12T07:12:40Z GooPie4o 265 wikitext text/x-wiki {{i18n|SHT}} {{Module |NAME=SHT |MENUCONFIG={{I/O}}->Humidity & temperature sensors->SHT 1x/7x |STATUS={{Stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/sht https://github.com/ethersex/ethersex/tree/master/hardware/sht] }} [[Category:Sensors]] 9a9752b08783846178a344ded902ac3888e17145 0 340 993 936 2013-03-12T07:13:43Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 FSK}} {{Module |NAME=RFM12 FSK |MENUCONFIG=Network->IP over RFM12 (FSK transmitter) support |STATUS={{Stable}} |PINNING=yes |ECMD=no |CONTROL6=no |DEPENDS= |REQUIRES=UIP_SUPPORT |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} The default operating mode of the RFM12 is FSK. This mode is used to treat several Ethersex systems connect by radio with each other. Here, one of the systems can act as a router to connect to a wired network. == Connection == If you are using hardware SPI, which is the default, connect the RFM12 to the AVR as follows: [[Image:Rfm12 connection.png|640px]] The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_USE_INT(2) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_USE_INT defines whether nRQ is connected to INT0, INT1 or INT2 of the AVR. == Configuration == [[Category:RFM12]] 6bdf578c5c2270ad316e09f4c249c1222ebb5dd6 0 208 997 626 2013-03-12T07:19:46Z GooPie4o 265 wikitext text/x-wiki {{i18n|M4 - very short intro}} == Einleitung == Die offizielle Doku gibt es hier: http://www.gnu.org/software/m4/manual/index.html Hier noch ein ganze kurze Einführung: Von der Idee her, ist es mit dem C-Präprocessor vergleichbar, der ebenfalls Macro-Ersetzungen durchführt und das Ergebnis an den C-Compiler weiterleitet. Bei m4 ist das Ergebnisse lediglich der Text, den die Macro-Ersetzungen ergeben. Wie es genau funktioniert, aber unbedingt nachlesen, da es manchmal auch auf die Feinheiten ankommt. Kommentare werden mit # wie in C gekennzeichnet. Es gibt keinen "Befehlsterminator" wie z.B. ein Semikolon. Ersetzungen werden aber ähnlich wie ein Funktionen in einer Programmiersprache aufgerufen. Wichtig ist auch die Quotierung mit ` und ' , die das Verhalten bei der Macro-Expandierung entscheidend beeinflusst. siehe hier und folgende http://www.gnu.org/software/m4/manual/m4.html#Quoting-Arguments == Macro definieren == Im Gegensatz zum C-Präprocessor wird hier ein sogenanntes "builtin" benutzt: define(name, [expansion]) Zu beachten: werden die Argumente nicht quotiert, kann hier schon die Macro-Erweiterung zuschlagen, was dann zu unerwünschten Ergebnissen führen kann. Mit den "Pseudo-Variablen" $1, $2, etc. kann man die Argumente des Macros in der Expansion referenzieren. Im Gegensatz zum C-Präprozessor, der überwiegend mit benannten Parametern arbeitet. * $* - alle Argumente * $@ - alle Argumente quotiert - Im Gegensatz zur vorhergehenden Variante werden die Argumente nicht weiter expandiert. * $# - Anzahl der Argumente == Kontrol-Strukturen == Hiermit sind bedingte Ausführung und Schleifen gemeint. * ifdef(name, string1, [string2]) *: - wenn name definiert ist, dann ist das Ergebnis string1, sonst string2 * ifelse(string1, string2, equal1, string3, string4, equal2, ..., [not_equal]) *: - wenn string1 = string2, dann equal1, sonst if string3 = string4, dann equal2, sonst ..., sonst not_equal * join oder joinall([separator], [args....]) *: - args zusammenfügen, Separator dazwischen setzen. Bei joinall wird immer der Separator gesetzt - auch wenn ein Argument leer ist. * Rekursive Macro-Definitionen sind auch möglich - hilfreich dabei die shift Funktion, die jeweils das erste Argument abschneidet. * forloop (iterator, start, end, text) *:- iterator muss ein gültiger Macroname sein, Start und Ende ganze Zahlen, der Text wird gemäß der Schleifendurchläufe ersetzt. * foreach (iterator, paren-list, text) / foreachq (iterator, paren-list, text) *: - jedes Argument der parent-list wird an den Iterator gebunden und dann eine Ersetzung für Text ausgeführt. == divert == Da dieses Konstrukt häufig in Ethersex eingesetzt wird, hier noch ein paar Extra-Bemerkungen: Mit divert(<ausgabeidx>) wird ein Text-Abschnitt begonnen, der an der durch <ausgabeindex> definierten Stelle in die Ausgabe-Text eingefügt wird. <ausgabeidx> ist eine ganze, positive Zahl. Abschnitt 1 wird vor 2, 2 wird vor 3, usw. ausgegeben. Dabei spielt es keine Rolle, in welcher Reiehnfolge die Abschnitt in der m4-Quelldatei definiert werden. Der Textabschnitt wird durch ein weiteres "divert" beendet, wobei "divert(-1)" dafür sorgt, dass kein neuer Abschnitt beginnt. Sind mehrer Abschnitte mit dem gleichen <ausgabeidx> definiert, so werden sie mit der Reihenfolge ihrer Defnition ausgegeben. === Beispiel: === divert(3)dnl Das ist Abschnitt 3 divert(2)dnl Das ist Abschnitt 2a divert(1)dnl Das ist Abschnitt 1 divert(2)dnl Das ist Abschnitt 2b divert(-1)dnl Die Ausgabe sind dann wie folgt aus: Das ist Abschnitt 1 Das ist Abschnitt 2a Das ist Abschnitt 2b Das ist Abschnitt 3 Bemerkung: die Sprache ist sehr mächtig und man kann "Wildes" konstruieren, dass man nach 2 Tagen selber nicht mehr versteht ;-) == Wichtiges == * dnl - "Discard to next line" - Schließt die Zeile ab - alles nachfolgende wird ignoriert. * changecom(<newcomment-start>) - ändert das Kommentarzeichen auf die angegebene Zeichenfolge (Default: #) 4aede20e12ac06aa01228a0630d8969af4c32c3c 0 207 998 537 2013-03-12T07:20:19Z GooPie4o 265 wikitext text/x-wiki {{i18n|M4 - very short intro}} 20c718934dde87cc5829259d63411a210626442f 0 341 1000 925 2013-03-25T15:32:41Z GooPie4o 265 /* Control6 */ wikitext text/x-wiki {{i18n|DHT}} {{Module |NAME=DHT |MENUCONFIG={{I/O}}->Humidity & temperature sensors->DHT 11/22 |STATUS={{Experimental}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/dht https://github.com/ethersex/ethersex/tree/master/hardware/dht] }} ==== DHT11/DHT21/DHT22 etc. Temperature & Humidity sensors ==== These sensors are very basic and slow, but are great for hobbyists who want to do some basic data logging. The DHT sensors are made of two parts, a capacitive humidity sensor and a thermistor. There is also a very basic chip inside that does some analog to digital conversion and spits out a digital signal with the temperature and humidity. ==== DHT11 vs DHT22 ==== There are two versions of the DHT sensor available, they look a bit similar and have the same pinout, but have different characteristics. Here are the specs: DHT11 * Ultra low cost * 3 to 5V power and I/O * 2.5mA max current use during conversion (while requesting data) * Good for 20-80% humidity readings with 5% accuracy * Good for 0-50°C temperature readings ±2°C accuracy * No more than 1 Hz sampling rate (once every second) * Body size 15.5mm x 12mm x 5.5mm * 4 pins with 0.1" spacing DHT22 * Low cost * 3 to 5V power and I/O * 2.5mA max current use during conversion (while requesting data) * Good for 0-100% humidity readings with 2-5% accuracy * Good for -40 to 125°C temperature readings ±0.5°C accuracy * No more than 0.5 Hz sampling rate (once every 2 seconds) * Body size 15.1mm x 25mm x 7.7mm * 4 pins with 0.1" spacing == Connection == Likewise, it is fairly easy to connect up to the DHT sensors. They have four pins # VCC (3 to 5V power) # Data out # Not connected # Ground Simply ignore pin 3, it is not used. You will want to place a 10K resistor between VCC and the data pin, to act as a medium-strength pull up on the data line. The data out can be connected to any port pin of the ATmega, i.e. PA0 as listed in the pinning example: ifdef(`conf_DHT', `dnl pin(DHT, PA0, INPUT) ') == Configuration == Ethersex polls the sensors every n seconds. The advantage of this feature is that the reading opererates without any noticeable lags. Also it is easier to have multiple applications requesting sensor information since more request will not increase traffic. | | I/O ---> ... [*] Humidity & temperature sensors ---> ... [*] DHT 11/22 ---> | | (DHT11) Sensor type | | (30) Time between polling in 1s steps | | --- Debugging Flags | | [*] DHT == [[ECMD]] == DHT implements an [[ECMD]] interface for reading humidity and temperature values. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == Humidity and temperature can be accessed in [[Control6]] scripts through the DHT_HUMIDITY and DHT_TEMPERATURE keywords. The values returnd are fixed point integers including one decimal. The following example calculates and outputs the dew point on a LCD once every minute. <source lang="text"> #include <stdio.h> #include <math.h> #include "hardware/lcd/hd44780.h" CONTROL_START THREAD(read_dht) ON ONCE CLOCK_SEC == 0 DO float a = 17.271; float b = 237.7; float temperatur = (a * DHT_TEMPERATURE) / (b + DHT_TEMPERATURE) + log(DHT_HUMIDITY/100); float taupunkt = (b * temperatur) / (a - temperatur); hd44780_clear(); hd44780_home(); fprintf_P(&lcd, PSTR("Taupunkt: %f"), taupunkt); END THREAD_END(read_dht) ON STARTUP DO THREAD_START(read_dht); END CONTROL_END </source> [[Category:Sensors]] 9c26c60af71e965c5da86d0757e70590704a1c8e 2 354 1001 2013-03-25T22:08:56Z Rayofhope 20 Created page with "sudo avrdude -P usb -c usbasp -p m644 -U flash:w:ethersex.hex" wikitext text/x-wiki sudo avrdude -P usb -c usbasp -p m644 -U flash:w:ethersex.hex c6a1b415f2739eed81aca52ae55a8d8cd6105a87 0 312 1002 999 2013-03-27T17:01:37Z GooPie4o 265 /* ECMD */ wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} The FS20 / FHT system by ELV is currently the most successful wireless home control system in the low cost sector. This arises from the large number of components and the continuous expansion of the system. But the relatively low price, the comprehensive home control systems far below the price of such EIB systems permits, plays a crucial role. This modul is based on [http://culfw.de CULFW by Rudolf Koenig] and supports a wide range of protocols: * FS20: send/receive<br>There are numerous FS20 devices, all of them are fully supported. * FHT: send/receive<br>Communication to the FHT80b is supported. * S300: receive<br>Examples of such devices: S300TH, KS300-2 * EM1000: receive<br>Devices: EM1000FM, EM1000GZ, EM1000WZ * HMS: receive<br>Devices: There are numerous HMS devices, all of them are fully supported. * ESA2000: receive * Lacrosse TX2/TX3: receive == Connection == The RFM12 is connected to the AVR like in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FSK/DATA/nFSS signal (Pin 3) is connected to one of the INT pins of the AVR. This modul does not work in interrupt mode, so the output nRQ signal (Pin 2) can be left unconnected. The software uses the digital filter of the RFM12. To improve sensitivity on short and long distances the [http://jeelabs.net/projects/cafe/wiki/Receiving_OOKASK_with_a_modified_RFM12B C_arssi capacitor needs to be replaced] with a value 150 pf. The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_FS20_USE_INT(1) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_FS20_USE_INT defines whether FSK/DATA/nFSS is connected to INT0, INT1 or INT2 of the AVR. == Configuration == The FS20 system sends on 868,35 MHz, so the 868MHz option is the right one. | | I/O ---> | | ... | | [*] RFM12 ASK ---> | | ... | | [ ] 433MHz | | | | [-] Pollin/Kangtai Powerswitch (IC 2272) | | | | [-] Pollin Powerswitch buried (IC 1527) | | | | [-] Tevion Powerswitch | | | | [-] Intertechno ITS-150 | | | | [-] External filter | | | | [-] Sensing | | | | --- | | | | [*] 868MHz | | | | (0) RFM12 select | | | | [*] FS20 | | | | [*] FHT | | | | [*] ESA | | | | [ ] TX3 | | | | --- Debugging Flags | | | | [-] Sensing | | | | [ ] FS20 | | == [[ECMD]] == RFM12 FS20 implements an [[ECMD]] interface for send and receive FS20/FHT commands. The received data is formatted as described in the [http://culfw.de/commandref.html#protocol2 CULFW reference]. See [[ECMD_Reference|ECMD reference]] for a command list. [[Category:RFM12]] a331b608735f198002bb62340b69fd698fc8af47 1003 1002 2013-03-27T17:02:35Z GooPie4o 265 /* Configuration */ wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} The FS20 / FHT system by ELV is currently the most successful wireless home control system in the low cost sector. This arises from the large number of components and the continuous expansion of the system. But the relatively low price, the comprehensive home control systems far below the price of such EIB systems permits, plays a crucial role. This modul is based on [http://culfw.de CULFW by Rudolf Koenig] and supports a wide range of protocols: * FS20: send/receive<br>There are numerous FS20 devices, all of them are fully supported. * FHT: send/receive<br>Communication to the FHT80b is supported. * S300: receive<br>Examples of such devices: S300TH, KS300-2 * EM1000: receive<br>Devices: EM1000FM, EM1000GZ, EM1000WZ * HMS: receive<br>Devices: There are numerous HMS devices, all of them are fully supported. * ESA2000: receive * Lacrosse TX2/TX3: receive == Connection == The RFM12 is connected to the AVR like in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FSK/DATA/nFSS signal (Pin 3) is connected to one of the INT pins of the AVR. This modul does not work in interrupt mode, so the output nRQ signal (Pin 2) can be left unconnected. The software uses the digital filter of the RFM12. To improve sensitivity on short and long distances the [http://jeelabs.net/projects/cafe/wiki/Receiving_OOKASK_with_a_modified_RFM12B C_arssi capacitor needs to be replaced] with a value 150 pf. The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_FS20_USE_INT(1) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_FS20_USE_INT defines whether FSK/DATA/nFSS is connected to INT0, INT1 or INT2 of the AVR. == Configuration == The FS20 system sends on 868,35 MHz, so the 868MHz option is the right one. | | I/O ---> | | ... | | [*] RFM12 ASK ---> | | ... | | [ ] 433MHz | | | | [-] Pollin/Kangtai Powerswitch (IC 2272) | | | | [-] Pollin Powerswitch buried (IC 1527) | | | | [-] Tevion Powerswitch | | | | [-] Intertechno ITS-150 | | | | [-] External filter | | | | [-] Sensing | | | | --- | | | | [*] 868MHz | | | | (0) RFM12 select | | | | [*] FS20 | | | | [*] FHT | | | | [*] ESA | | | | [ ] TX3 | | | | [ ] Send received data via syslog | | | | --- Debugging Flags | | | | [-] Sensing | | | | [ ] FS20 | | == [[ECMD]] == RFM12 FS20 implements an [[ECMD]] interface for send and receive FS20/FHT commands. The received data is formatted as described in the [http://culfw.de/commandref.html#protocol2 CULFW reference]. See [[ECMD_Reference|ECMD reference]] for a command list. [[Category:RFM12]] 370d0192a3e4bea30c7300d4f05364ac6a268a26 1004 1003 2013-03-27T17:03:59Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} The FS20 / FHT system by ELV is currently the most successful wireless home control system in the low cost sector. This arises from the large number of components and the continuous expansion of the system. But the relatively low price, the comprehensive home control systems far below the price of such EIB systems permits, plays a crucial role. This modul is based on [http://culfw.de CULFW by Rudolf Koenig] and supports a wide range of protocols: * FS20: send/receive<br>There are numerous FS20 devices, all of them are fully supported. * FHT: send/receive<br>Communication to the FHT80b is supported. * S300: receive<br>Examples of such devices: S300TH, KS300-2 * EM1000: receive<br>Devices: EM1000FM, EM1000GZ, EM1000WZ * HMS: receive<br>Devices: There are numerous HMS devices, all of them are fully supported. * ESA2000: receive * Lacrosse TX2/TX3: receive == Connection == The RFM12 is connected to the AVR like in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FSK/DATA/nFSS signal (Pin 3) is connected to one of the INT pins of the AVR. This modul does not work in interrupt mode, so the output nRQ signal (Pin 2) can be left unconnected. The software uses the digital filter of the RFM12. To improve sensitivity on short and long distances the [http://jeelabs.net/projects/cafe/wiki/Receiving_OOKASK_with_a_modified_RFM12B C_arssi capacitor needs to be replaced] with a value 150 pf. The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_FS20_USE_INT(1) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_FS20_USE_INT defines whether FSK/DATA/nFSS is connected to INT0, INT1 or INT2 of the AVR. == Configuration == The FS20 system sends on 868,35 MHz, so the 868MHz option is the right one. | | I/O ---> | | ... | | [*] RFM12 ASK ---> | | ... | | [ ] 433MHz | | | | [-] Pollin/Kangtai Powerswitch (IC 2272) | | | | [-] Pollin Powerswitch buried (IC 1527) | | | | [-] Tevion Powerswitch | | | | [-] Intertechno ITS-150 | | | | [-] External filter | | | | [-] Sensing | | | | --- | | | | [*] 868MHz | | | | (0) RFM12 select | | | | [*] FS20 | | | | [*] FHT | | | | [*] ESA | | | | [ ] TX3 | | | | [ ] Send received data via syslog | | | | --- Debugging Flags | | | | [-] Sensing | | | | [ ] FS20 | | == [[ECMD]] == RFM12 FS20 implements an [[ECMD]] interface for send and receive FS20/FHT commands. The received data is formatted as described in the [http://culfw.de/commandref.html#protocol2 CULFW reference]. See [[ECMD_Reference|ECMD reference]] for a command list. == [[Control6]] == work in progress [[Category:RFM12]] a84b3f9ba1d4e6525d594ab07741f6bd4b6b6ba4 1007 1004 2013-03-28T16:54:14Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} The FS20 / FHT system by ELV is currently the most successful wireless home control system in the low cost sector. This arises from the large number of components and the continuous expansion of the system. But the relatively low price, the comprehensive home control systems far below the price of such EIB systems permits, plays a crucial role. This modul is based on [http://culfw.de CULFW by Rudolf Koenig] and supports a wide range of protocols: * FS20: send/receive<br>There are numerous FS20 devices, all of them are fully supported. * FHT: send/receive<br>Communication to the FHT80b is supported. * S300: receive<br>Examples of such devices: S300TH, KS300-2 * EM1000: receive<br>Devices: EM1000FM, EM1000GZ, EM1000WZ * HMS: receive<br>Devices: There are numerous HMS devices, all of them are fully supported. * ESA2000: receive * Lacrosse TX2/TX3: receive == Connection == The RFM12 is connected to the AVR like in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FSK/DATA/nFSS signal (Pin 3) is connected to one of the INT pins of the AVR. This modul does not work in interrupt mode, so the output nRQ signal (Pin 2) can be left unconnected. The software uses the digital filter of the RFM12. To improve sensitivity on short and long distances the [http://jeelabs.net/projects/cafe/wiki/Receiving_OOKASK_with_a_modified_RFM12B C_arssi capacitor needs to be replaced] with a value 150 pf. The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_FS20_USE_INT(1) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_FS20_USE_INT defines whether FSK/DATA/nFSS is connected to INT0, INT1 or INT2 of the AVR. == Configuration == The FS20 system sends on 868,35 MHz, so the 868MHz option is the right one. | | I/O ---> | | ... | | [*] RFM12 ASK ---> | | ... | | [ ] 433MHz | | | | [-] Pollin/Kangtai Powerswitch (IC 2272) | | | | [-] Pollin Powerswitch buried (IC 1527) | | | | [-] Tevion Powerswitch | | | | [-] Intertechno ITS-150 | | | | [-] External filter | | | | [-] Sensing | | | | --- | | | | [*] 868MHz | | | | (0) RFM12 select | | | | [*] FS20 | | | | [*] FHT | | | | [*] ESA | | | | [ ] TX3 | | | | [ ] Send received data via syslog | | | | --- Debugging Flags | | | | [-] Sensing | | | | [ ] FS20 | | == [[ECMD]] == RFM12 FS20 implements an [[ECMD]] interface for send and receive FS20/FHT commands. The received data is formatted as described in the [http://culfw.de/commandref.html#protocol2 CULFW reference]. See [[ECMD_Reference|ECMD reference]] for a command list. == [[Control6]] == work in progress == Troubleshooting == It may happen that not all of the RFM12 FS20 sensors are received. Here are some points that may help to improve reception: * Location: ** Avoid RF transmitter near the RFM12 ** Choose a position in the center of the sensors * Antenna: ** It is recommended to choose an antenna with a length of Lamda/2 (17,3cm) * Bandwidth: Default 400kHz ** Can be changed via ECMD from 400kHz to 67kHz (rfm12 setbandwidth <modulnumber> 1-6) * Gain: Default 14dB ** Can be changed via ECMD from 0dB to -20dB (rfm12 setgain <modulnumber> 0-3) * DRSSI: Default -97dB ** Can be changed via ECMD from -103dB to -61dB (rfm12 setdrssi <modulnumber> 0-7) Checkout the RFM12 datasheet for details on bandwidth, gain and DRSSI. == Decoding received data == work in progress [[Category:RFM12]] 24b66652dfa31c44d3a0a14a2a11c9c7bd33ba95 1008 1007 2013-03-28T16:55:38Z GooPie4o 265 /* Troubleshooting */ wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} The FS20 / FHT system by ELV is currently the most successful wireless home control system in the low cost sector. This arises from the large number of components and the continuous expansion of the system. But the relatively low price, the comprehensive home control systems far below the price of such EIB systems permits, plays a crucial role. This modul is based on [http://culfw.de CULFW by Rudolf Koenig] and supports a wide range of protocols: * FS20: send/receive<br>There are numerous FS20 devices, all of them are fully supported. * FHT: send/receive<br>Communication to the FHT80b is supported. * S300: receive<br>Examples of such devices: S300TH, KS300-2 * EM1000: receive<br>Devices: EM1000FM, EM1000GZ, EM1000WZ * HMS: receive<br>Devices: There are numerous HMS devices, all of them are fully supported. * ESA2000: receive * Lacrosse TX2/TX3: receive == Connection == The RFM12 is connected to the AVR like in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FSK/DATA/nFSS signal (Pin 3) is connected to one of the INT pins of the AVR. This modul does not work in interrupt mode, so the output nRQ signal (Pin 2) can be left unconnected. The software uses the digital filter of the RFM12. To improve sensitivity on short and long distances the [http://jeelabs.net/projects/cafe/wiki/Receiving_OOKASK_with_a_modified_RFM12B C_arssi capacitor needs to be replaced] with a value 150 pf. The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_FS20_USE_INT(1) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_FS20_USE_INT defines whether FSK/DATA/nFSS is connected to INT0, INT1 or INT2 of the AVR. == Configuration == The FS20 system sends on 868,35 MHz, so the 868MHz option is the right one. | | I/O ---> | | ... | | [*] RFM12 ASK ---> | | ... | | [ ] 433MHz | | | | [-] Pollin/Kangtai Powerswitch (IC 2272) | | | | [-] Pollin Powerswitch buried (IC 1527) | | | | [-] Tevion Powerswitch | | | | [-] Intertechno ITS-150 | | | | [-] External filter | | | | [-] Sensing | | | | --- | | | | [*] 868MHz | | | | (0) RFM12 select | | | | [*] FS20 | | | | [*] FHT | | | | [*] ESA | | | | [ ] TX3 | | | | [ ] Send received data via syslog | | | | --- Debugging Flags | | | | [-] Sensing | | | | [ ] FS20 | | == [[ECMD]] == RFM12 FS20 implements an [[ECMD]] interface for send and receive FS20/FHT commands. The received data is formatted as described in the [http://culfw.de/commandref.html#protocol2 CULFW reference]. See [[ECMD_Reference|ECMD reference]] for a command list. == [[Control6]] == work in progress == Troubleshooting == It may happen that not all of the RFM12 FS20 sensors are received. Here are some points that may help to improve reception: * Location: ** Avoid RF transmitter near the RFM12 ** Choose a position in the center of the sensors * Antenna: ** It is recommended to choose an antenna with a length not shorter than Lamda/2 (17,3cm) * Bandwidth: Default 400kHz ** Can be changed via ECMD from 400kHz to 67kHz (rfm12 setbandwidth <modulnumber> 1-6) * Gain: Default -14dB ** Can be changed via ECMD from 0dB to -20dB (rfm12 setgain <modulnumber> 0-3) * DRSSI: Default -97dB ** Can be changed via ECMD from -103dB to -61dB (rfm12 setdrssi <modulnumber> 0-7) Checkout the RFM12 datasheet for details on bandwidth, gain and DRSSI. == Decoding received data == work in progress [[Category:RFM12]] 6f27c4fbaec75032be52d2c4974bbbafb0d9dd27 1009 1008 2013-03-28T17:03:14Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} The FS20 / FHT system by ELV is currently the most successful wireless home control system in the low cost sector. This arises from the large number of components and the continuous expansion of the system. But the relatively low price, the comprehensive home control systems far below the price of such EIB systems permits, plays a crucial role. This modul is based on [http://culfw.de CULFW by Rudolf Koenig] and supports a wide range of protocols: * FS20: send/receive<br>There are numerous FS20 devices, all of them are fully supported. * FHT: send/receive<br>Communication to the FHT80b is supported. * S300: receive<br>Examples of such devices: S300TH, KS300-2 * EM1000: receive<br>Devices: EM1000FM, EM1000GZ, EM1000WZ * HMS: receive<br>Devices: There are numerous HMS devices, all of them are fully supported. * ESA2000: receive * Lacrosse TX2/TX3: receive == Connection == The RFM12 is connected to the AVR like in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FSK/DATA/nFSS signal (Pin 3) is connected to one of the INT pins of the AVR. This modul does not work in interrupt mode, so the output nRQ signal (Pin 2) can be left unconnected. The software uses the digital filter of the RFM12. To improve sensitivity on short and long distances the [http://jeelabs.net/projects/cafe/wiki/Receiving_OOKASK_with_a_modified_RFM12B C_arssi capacitor needs to be replaced] with a value 150 pf. The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_FS20_USE_INT(1) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_FS20_USE_INT defines whether FSK/DATA/nFSS is connected to INT0, INT1 or INT2 of the AVR. == Configuration == The FS20 system sends on 868,35 MHz, so the 868MHz option is the right one. | | I/O ---> | | ... | | [*] RFM12 ASK ---> | | ... | | [ ] 433MHz | | | | [-] Pollin/Kangtai Powerswitch (IC 2272) | | | | [-] Pollin Powerswitch buried (IC 1527) | | | | [-] Tevion Powerswitch | | | | [-] Intertechno ITS-150 | | | | [-] External filter | | | | [-] Sensing | | | | --- | | | | [*] 868MHz | | | | (0) RFM12 select | | | | [*] FS20 | | | | [*] FHT | | | | [*] ESA | | | | [ ] TX3 | | | | [ ] Send received data via syslog | | | | --- Debugging Flags | | | | [-] Sensing | | | | [ ] FS20 | | == [[ECMD]] == RFM12 FS20 implements an [[ECMD]] interface for send and receive FS20/FHT commands. The received data is formatted as described in the [http://culfw.de/commandref.html#protocol2 CULFW reference]. See [[ECMD_Reference|ECMD reference]] for a command list. == [[Control6]] == work in progress == Troubleshooting == It may happen that not all of the RFM12 FS20 sensors are received. Here are some points that may help to improve reception: * Location: ** Avoid RF transmitter near the RFM12 ** Choose a position in the center of the sensors * Antenna: ** It is recommended to choose an antenna with a length not shorter than Lamda/2 (17,3cm) * Bandwidth: Default 400kHz ** Can be changed via ECMD from 400kHz to 67kHz (rfm12 setbandwidth <modulnumber> 1-6) * Gain: Default -14dB ** Can be changed via ECMD from 0dB to -20dB (rfm12 setgain <modulnumber> 0-3) * DRSSI: Default -97dB ** Can be changed via ECMD from -103dB to -61dB (rfm12 setdrssi <modulnumber> 0-7) Checkout the RFM12 datasheet for details on bandwidth, gain and DRSSI. == Decoding received data == The received data is formatted as described in the [http://culfw.de/commandref.html#protocol2 CULFW reference]. One could use the perl scripts from [http://culfw.de/ CULFW] to decode the data. [[Category:RFM12]] f3057b78170c101797c929a11df382a98734351d 1010 1009 2013-04-01T07:39:24Z GooPie4o 265 /* Configuration */ wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} The FS20 / FHT system by ELV is currently the most successful wireless home control system in the low cost sector. This arises from the large number of components and the continuous expansion of the system. But the relatively low price, the comprehensive home control systems far below the price of such EIB systems permits, plays a crucial role. This modul is based on [http://culfw.de CULFW by Rudolf Koenig] and supports a wide range of protocols: * FS20: send/receive<br>There are numerous FS20 devices, all of them are fully supported. * FHT: send/receive<br>Communication to the FHT80b is supported. * S300: receive<br>Examples of such devices: S300TH, KS300-2 * EM1000: receive<br>Devices: EM1000FM, EM1000GZ, EM1000WZ * HMS: receive<br>Devices: There are numerous HMS devices, all of them are fully supported. * ESA2000: receive * Lacrosse TX2/TX3: receive == Connection == The RFM12 is connected to the AVR like in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FSK/DATA/nFSS signal (Pin 3) is connected to one of the INT pins of the AVR. This modul does not work in interrupt mode, so the output nRQ signal (Pin 2) can be left unconnected. The software uses the digital filter of the RFM12. To improve sensitivity on short and long distances the [http://jeelabs.net/projects/cafe/wiki/Receiving_OOKASK_with_a_modified_RFM12B C_arssi capacitor needs to be replaced] with a value 150 pf. The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_FS20_USE_INT(1) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_FS20_USE_INT defines whether FSK/DATA/nFSS is connected to INT0, INT1 or INT2 of the AVR. == Configuration == The FS20 system sends on 868,35 MHz, so the 868MHz option is the right one. | | I/O ---> | | ... | | [*] RFM12 ASK ---> | | ... | | [ ] 433MHz | | | | [-] Pollin/Kangtai Powerswitch (IC 2272) | | | | [-] Pollin Powerswitch buried (IC 1527) | | | | [-] Tevion Powerswitch | | | | [-] Intertechno ITS-150 | | | | [-] External filter | | | | [-] Sensing | | | | --- | | | | [*] 868MHz | | | | (0) RFM12 select | | | | [*] FS20 | | | | [*] FHT | | | | [*] ESA | | | | [ ] TX3 | | | | [ ] Send received data via syslog | | | | --- Debugging Flags | | | | [-] Sensing | | | | [ ] FS20 | | The modul uses Timer 2 of the AVR '''exclusively'''. Currently there is no option to use Timer 1, but this will change in the future. == [[ECMD]] == RFM12 FS20 implements an [[ECMD]] interface for send and receive FS20/FHT commands. The received data is formatted as described in the [http://culfw.de/commandref.html#protocol2 CULFW reference]. See [[ECMD_Reference|ECMD reference]] for a command list. == [[Control6]] == work in progress == Troubleshooting == It may happen that not all of the RFM12 FS20 sensors are received. Here are some points that may help to improve reception: * Location: ** Avoid RF transmitter near the RFM12 ** Choose a position in the center of the sensors * Antenna: ** It is recommended to choose an antenna with a length not shorter than Lamda/2 (17,3cm) * Bandwidth: Default 400kHz ** Can be changed via ECMD from 400kHz to 67kHz (rfm12 setbandwidth <modulnumber> 1-6) * Gain: Default -14dB ** Can be changed via ECMD from 0dB to -20dB (rfm12 setgain <modulnumber> 0-3) * DRSSI: Default -97dB ** Can be changed via ECMD from -103dB to -61dB (rfm12 setdrssi <modulnumber> 0-7) Checkout the RFM12 datasheet for details on bandwidth, gain and DRSSI. == Decoding received data == The received data is formatted as described in the [http://culfw.de/commandref.html#protocol2 CULFW reference]. One could use the perl scripts from [http://culfw.de/ CULFW] to decode the data. [[Category:RFM12]] b1a9d6f42739fade2b696f74124c562438096adf 1011 1010 2013-04-02T10:53:40Z GooPie4o 265 /* Configuration */ wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} The FS20 / FHT system by ELV is currently the most successful wireless home control system in the low cost sector. This arises from the large number of components and the continuous expansion of the system. But the relatively low price, the comprehensive home control systems far below the price of such EIB systems permits, plays a crucial role. This modul is based on [http://culfw.de CULFW by Rudolf Koenig] and supports a wide range of protocols: * FS20: send/receive<br>There are numerous FS20 devices, all of them are fully supported. * FHT: send/receive<br>Communication to the FHT80b is supported. * S300: receive<br>Examples of such devices: S300TH, KS300-2 * EM1000: receive<br>Devices: EM1000FM, EM1000GZ, EM1000WZ * HMS: receive<br>Devices: There are numerous HMS devices, all of them are fully supported. * ESA2000: receive * Lacrosse TX2/TX3: receive == Connection == The RFM12 is connected to the AVR like in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FSK/DATA/nFSS signal (Pin 3) is connected to one of the INT pins of the AVR. This modul does not work in interrupt mode, so the output nRQ signal (Pin 2) can be left unconnected. The software uses the digital filter of the RFM12. To improve sensitivity on short and long distances the [http://jeelabs.net/projects/cafe/wiki/Receiving_OOKASK_with_a_modified_RFM12B C_arssi capacitor needs to be replaced] with a value 150 pf. The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_FS20_USE_INT(1) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_FS20_USE_INT defines whether FSK/DATA/nFSS is connected to INT0, INT1 or INT2 of the AVR. == Configuration == The FS20 system sends on 868,35 MHz, so the 868MHz option is the right one. | | I/O ---> | | ... | | [*] RFM12 ASK ---> | | ... | | [ ] 433MHz | | | | [-] Pollin/Kangtai Powerswitch (IC 2272) | | | | [-] Pollin Powerswitch buried (IC 1527) | | | | [-] Tevion Powerswitch | | | | [-] Intertechno ITS-150 | | | | [-] External filter | | | | [-] Sensing | | | | --- | | | | [*] 868MHz | | | | (0) RFM12 select | | | | [*] FS20 send | | | | [*] FS20 receive | | | | [*] FHT | | | | [*] ESA | | | | [ ] TX3 | | | | [ ] Send received data via syslog | | | | --- Debugging Flags | | | | [-] Sensing | | | | [ ] FS20 | | The modul uses Timer 2 of the AVR '''exclusively'''. Currently there is no option to use Timer 1, but this will change in the future. == [[ECMD]] == RFM12 FS20 implements an [[ECMD]] interface for send and receive FS20/FHT commands. The received data is formatted as described in the [http://culfw.de/commandref.html#protocol2 CULFW reference]. See [[ECMD_Reference|ECMD reference]] for a command list. == [[Control6]] == work in progress == Troubleshooting == It may happen that not all of the RFM12 FS20 sensors are received. Here are some points that may help to improve reception: * Location: ** Avoid RF transmitter near the RFM12 ** Choose a position in the center of the sensors * Antenna: ** It is recommended to choose an antenna with a length not shorter than Lamda/2 (17,3cm) * Bandwidth: Default 400kHz ** Can be changed via ECMD from 400kHz to 67kHz (rfm12 setbandwidth <modulnumber> 1-6) * Gain: Default -14dB ** Can be changed via ECMD from 0dB to -20dB (rfm12 setgain <modulnumber> 0-3) * DRSSI: Default -97dB ** Can be changed via ECMD from -103dB to -61dB (rfm12 setdrssi <modulnumber> 0-7) Checkout the RFM12 datasheet for details on bandwidth, gain and DRSSI. == Decoding received data == The received data is formatted as described in the [http://culfw.de/commandref.html#protocol2 CULFW reference]. One could use the perl scripts from [http://culfw.de/ CULFW] to decode the data. [[Category:RFM12]] 36afb6be2ef2b72da85a412eaf7c8db8887a5c7c 1017 1011 2013-04-02T20:40:38Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |TIMER={{occupies_timer|2}} (RX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} The FS20 / FHT system by ELV is currently the most successful wireless home control system in the low cost sector. This arises from the large number of components and the continuous expansion of the system. But the relatively low price, the comprehensive home control systems far below the price of such EIB systems permits, plays a crucial role. This modul is based on [http://culfw.de CULFW by Rudolf Koenig] and supports a wide range of protocols: * FS20: send/receive<br>There are numerous FS20 devices, all of them are fully supported. * FHT: send/receive<br>Communication to the FHT80b is supported. * S300: receive<br>Examples of such devices: S300TH, KS300-2 * EM1000: receive<br>Devices: EM1000FM, EM1000GZ, EM1000WZ * HMS: receive<br>Devices: There are numerous HMS devices, all of them are fully supported. * ESA2000: receive * Lacrosse TX2/TX3: receive == Connection == The RFM12 is connected to the AVR like in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FSK/DATA/nFSS signal (Pin 3) is connected to one of the INT pins of the AVR. This modul does not work in interrupt mode, so the output nRQ signal (Pin 2) can be left unconnected. The software uses the digital filter of the RFM12. To improve sensitivity on short and long distances the [http://jeelabs.net/projects/cafe/wiki/Receiving_OOKASK_with_a_modified_RFM12B C_arssi capacitor needs to be replaced] with a value 150 pf. The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_FS20_USE_INT(1) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_FS20_USE_INT defines whether FSK/DATA/nFSS is connected to INT0, INT1 or INT2 of the AVR. == Configuration == The FS20 system sends on 868,35 MHz, so the 868MHz option is the right one. | | I/O ---> | | ... | | [*] RFM12 ASK ---> | | ... | | [ ] 433MHz | | | | [-] Pollin/Kangtai Powerswitch (IC 2272) | | | | [-] Pollin Powerswitch buried (IC 1527) | | | | [-] Tevion Powerswitch | | | | [-] Intertechno ITS-150 | | | | [-] External filter | | | | [-] Sensing | | | | --- | | | | [*] 868MHz | | | | (0) RFM12 select | | | | [*] FS20 send | | | | [*] FS20 receive | | | | [*] FHT | | | | [*] ESA | | | | [ ] TX3 | | | | [ ] Send received data via syslog | | | | --- Debugging Flags | | | | [-] Sensing | | | | [ ] FS20 | | The modul uses Timer 2 of the AVR '''exclusively'''. Currently there is no option to use Timer 1, but this will change in the future. == [[ECMD]] == RFM12 FS20 implements an [[ECMD]] interface for send and receive FS20/FHT commands. The received data is formatted as described in the [http://culfw.de/commandref.html#protocol2 CULFW reference]. See [[ECMD_Reference|ECMD reference]] for a command list. == [[Control6]] == work in progress == Troubleshooting == It may happen that not all of the RFM12 FS20 sensors are received. Here are some points that may help to improve reception: * Location: ** Avoid RF transmitter near the RFM12 ** Choose a position in the center of the sensors * Antenna: ** It is recommended to choose an antenna with a length not shorter than Lamda/2 (17,3cm) * Bandwidth: Default 400kHz ** Can be changed via ECMD from 400kHz to 67kHz (rfm12 setbandwidth <modulnumber> 1-6) * Gain: Default -14dB ** Can be changed via ECMD from 0dB to -20dB (rfm12 setgain <modulnumber> 0-3) * DRSSI: Default -97dB ** Can be changed via ECMD from -103dB to -61dB (rfm12 setdrssi <modulnumber> 0-7) Checkout the RFM12 datasheet for details on bandwidth, gain and DRSSI. == Decoding received data == The received data is formatted as described in the [http://culfw.de/commandref.html#protocol2 CULFW reference]. One could use the perl scripts from [http://culfw.de/ CULFW] to decode the data. [[Category:RFM12]] 5ef184f2d9173b82375c0bdf4d32a3f06c682105 1047 1017 2013-06-05T06:46:59Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |TIMER={{occupies_timer|2}} (RX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} The FS20 / FHT system by ELV is currently the most successful wireless home control system in the low cost sector. This arises from the large number of components and the continuous expansion of the system. But the relatively low price, the comprehensive home control systems far below the price of such EIB systems permits, plays a crucial role. This modul is based on [http://culfw.de CULFW by Rudolf Koenig] and supports a wide range of protocols: * FS20: send/receive<br>There are numerous FS20 devices, all of them are fully supported. * FHT: send/receive<br>Communication to the FHT80b is supported. * S300: receive<br>Examples of such devices: S300TH, KS300-2 * EM1000: receive<br>Devices: EM1000FM, EM1000GZ, EM1000WZ * HMS: receive<br>Devices: There are numerous HMS devices, all of them are fully supported. * ESA2000: receive * Lacrosse TX2/TX3: receive == Connection == The RFM12 is connected to the AVR like in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FSK/DATA/nFSS signal (Pin 3) is connected to one of the INT pins of the AVR. This modul does not work in interrupt mode, so the output nRQ signal (Pin 2) can be left unconnected. The software uses the digital filter of the RFM12. To improve sensitivity on short and long distances the [http://jeelabs.net/projects/cafe/wiki/Receiving_OOKASK_with_a_modified_RFM12B C_arssi capacitor needs to be replaced] with a value 150 pf. The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_FS20_USE_INT(1) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_FS20_USE_INT defines whether FSK/DATA/nFSS is connected to INT0, INT1 or INT2 of the AVR. == Configuration == The FS20 system sends on 868,35 MHz, so the 868MHz option is the right one. | | I/O ---> | | ... | | [*] RFM12 ASK ---> | | ... | | [ ] 433MHz | | | | [-] Pollin/Kangtai Powerswitch (IC 2272) | | | | [-] Pollin Powerswitch buried (IC 1527) | | | | [-] Tevion Powerswitch | | | | [-] Intertechno ITS-150 | | | | [-] External filter | | | | [-] Sensing | | | | --- | | | | [*] 868MHz | | | | (0) RFM12 select | | | | [*] FS20 send | | | | [*] FS20 receive | | | | [*] FHT | | | | [*] ESA | | | | [ ] TX3 | | | | [ ] Send received data via syslog | | | | --- Debugging Flags | | | | [-] Sensing | | | | [ ] FS20 | | The modul uses Timer 2 of the AVR '''exclusively'''. Currently there is no option to use Timer 1, but this will change in the future. == [[ECMD]] == RFM12 FS20 implements an [[ECMD]] interface for send and receive FS20/FHT commands. The received data is formatted as described in the [http://culfw.de/commandref.html#protocol2 CULFW reference]. See [[ECMD_Reference|ECMD reference]] for a command list. == Troubleshooting == It may happen that not all of the RFM12 FS20 sensors are received. Here are some points that may help to improve reception: * Location: ** Avoid RF transmitter near the RFM12 ** Choose a position in the center of the sensors * Antenna: ** It is recommended to choose an antenna with a length not shorter than Lamda/2 (17,3cm) * Bandwidth: Default 400kHz ** Can be changed via ECMD from 400kHz to 67kHz (rfm12 setbandwidth <modulnumber> 1-6) * Gain: Default -14dB ** Can be changed via ECMD from 0dB to -20dB (rfm12 setgain <modulnumber> 0-3) * DRSSI: Default -97dB ** Can be changed via ECMD from -103dB to -61dB (rfm12 setdrssi <modulnumber> 0-7) Checkout the RFM12 datasheet for details on bandwidth, gain and DRSSI. == Decoding received data == The received data is formatted as described in the [http://culfw.de/commandref.html#protocol2 CULFW reference]. One could use the perl scripts from [http://culfw.de/ CULFW] to decode the data. [[Category:RFM12]] 985150867219e7564908893110d24b424c424252 14 355 1005 2013-03-27T17:06:04Z GooPie4o 265 Created page with "This category lists all components with an "Control6" interface." wikitext text/x-wiki This category lists all components with an "Control6" interface. 738dee77b146ad7df12153eb22f761390058b404 0 311 1006 995 2013-03-27T17:06:48Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} Das FS20- / FHT-System von ELV ist derzeit das wohl erfolgreichste Funk-Haussteuerungssystem im Niedrigpreissektor. Dies ergibt sich aus der Vielzahl von Komponenten und der ständigen Erweiterung des Systems. Aber auch der relativ günstige Preis, der umfangreiche Haussteuerungen weit unter dem Preis von z.B. EIB-Systemen zulässt, spielt eine entscheidende Rolle. Das Modul basiert auf [http://culfw.de CULFW von Rudolf Koenig] und unterstützt folgende Protokolle: * FS20: senden/empfangen<br>Es gibt eine Vielzahl von FS20 Geräten, die alle unterstützt werden. * FHT: senden/empfangen<br>Die Kommunikation mit FHT80b wird unterstützt. * S300: empfangen<br>Beispiele dieser Geräte: S300TH, KS300-2 * EM1000: empfangen<br>Geräte: EM1000FM, EM1000GZ, EM1000WZ * HMS: empfangen<br>Es gibt eine Vielzahl von HMS Geräten, die alle unterstützt werden. * ESA2000: empfangen * Lacrosse TX2/TX3: empfangen [[Category:RFM12]] 0b6a04189a911e6d8c4f250eb90bd46da3f69195 1018 1006 2013-04-02T20:41:01Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |TIMER={{occupies_timer|2}} (RX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} Das FS20- / FHT-System von ELV ist derzeit das wohl erfolgreichste Funk-Haussteuerungssystem im Niedrigpreissektor. Dies ergibt sich aus der Vielzahl von Komponenten und der ständigen Erweiterung des Systems. Aber auch der relativ günstige Preis, der umfangreiche Haussteuerungen weit unter dem Preis von z.B. EIB-Systemen zulässt, spielt eine entscheidende Rolle. Das Modul basiert auf [http://culfw.de CULFW von Rudolf Koenig] und unterstützt folgende Protokolle: * FS20: senden/empfangen<br>Es gibt eine Vielzahl von FS20 Geräten, die alle unterstützt werden. * FHT: senden/empfangen<br>Die Kommunikation mit FHT80b wird unterstützt. * S300: empfangen<br>Beispiele dieser Geräte: S300TH, KS300-2 * EM1000: empfangen<br>Geräte: EM1000FM, EM1000GZ, EM1000WZ * HMS: empfangen<br>Es gibt eine Vielzahl von HMS Geräten, die alle unterstützt werden. * ESA2000: empfangen * Lacrosse TX2/TX3: empfangen [[Category:RFM12]] 2576e94b15ee7767984b3ca43679bfe2b02838ba 10 356 1012 2013-04-02T20:14:57Z Mgue 312 first version wikitext text/x-wiki Timer {{{1}}} [[Category:Module that uses Timer {{{1}}}| ]] c74d68a264bcee4e3820291f90b5f7e846366833 1016 1012 2013-04-02T20:34:26Z Mgue 312 link test wikitext text/x-wiki [[:Category:Module that uses Timer {{{1}}}| Timer {{{1}}}]] [[Category:Module that uses Timer {{{1}}}| ]] 1635356db920ccbc5a8c606eee10859dee313b7b 10 15 1013 559 2013-04-02T20:17:37Z Mgue 312 TIMER test wikitext text/x-wiki <onlyinclude>{| style="float:right;margin:1em 0 1em 1em; border:1px #AAA solid;background: #f9f9f9;width:330px; font-size:95%;margin-top:0px;" !colspan="2" style="background-color:#CEDAF2; text-align:center"| {{#if: {{{NAME|}}}|<big>{{{NAME}}}</big>|<big>{{PAGENAME}}</big>}} |- {{#if: {{{STATUS|}}}| {{!}} style="vertical-align:top;" {{!}}Status {{!}} {{{STATUS}}} }} |- {{#if: {{{MENUCONFIG|}}}| {{!}} style="vertical-align:top;" {{!}}menuconfig {{!}} {{{MENUCONFIG}}} }} |- {{#if: {{{PINNING|}}}| {{!}} style="vertical-align:top;" {{!}}Pinning {{!}} {{{PINNING}}} }} |- {{#if: {{{ECMD|}}}| {{!}} style="vertical-align:top;" {{!}}Ecmd {{!}} {{{ECMD}}} }} |- {{#if: {{{CONTROL6|}}}| {{!}} style="vertical-align:top;" {{!}}Control6 {{!}} {{{CONTROL6}}} }} |- {{#if: {{{TIMER|}}}| {{!}} style="vertical-align:top;" {{!}}Uses Timer {{!}} {{{TIMER}}} }} |- {{#if: {{{DEPENDS|}}}| {{!}} style="vertical-align:top;" {{!}}Depends on {{!}} {{{DEPENDS}}} }} |- {{#if: {{{REQUIRES|}}}| {{!}} style="vertical-align:top;" {{!}}Requires {{!}} {{{REQUIRES}}} }} |- {{#if: {{{CODE|}}}| {{!}} style="vertical-align:top;" {{!}}Code {{!}} {{{CODE}}} }} |- |}</onlyinclude> == Templates for menuconfig == If you use one of the following templates, the module will automatically added to the proper category {{Codeline|<nowiki>{{I/O}}</nowiki>}} {{Codeline|<nowiki>{{Protocols}}</nowiki>}} {{Codeline|<nowiki>{{Applications}}</nowiki>}} == Templates for STATUS == {| style="width:50%" |- | {{Codeline|<nowiki>{{stable}}</nowiki>}} {{stable}} {{Codeline|<nowiki>{{Experimental}}</nowiki>}} {{Experimental}} {{Codeline|<nowiki>{{In_Development}}</nowiki>}} {{In Development}} {{Codeline|<nowiki>{{Unstable}}</nowiki>}} {{Unstable}} {{Codeline|<nowiki>{{Deprecated}}</nowiki>}} {{Deprecated}} |} == Templates for ECMD == {| style="width:50%" |- | {{Codeline|<nowiki>{{has_ecmd}}</nowiki>}} |} or leave blank == Templates for CONTROL6 == {| style="width:50%" |- | {{Codeline|<nowiki>{{has_control6}}</nowiki>}} |} or leave blank == Example == <pre><nowiki> {{Module |NAME=Onewire |MENUCONFIG={{I/O}}->Onewire support |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }}</nowiki></pre> == Result == {{Module |NAME=Onewire |MENUCONFIG={{I/O}}->Onewire support |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |TIMER={{occupies_timer|1}} |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} f3339c19fe58d5972d1136e7c3beedfe125dd5ab 1014 1013 2013-04-02T20:20:45Z Mgue 312 docu wikitext text/x-wiki <onlyinclude>{| style="float:right;margin:1em 0 1em 1em; border:1px #AAA solid;background: #f9f9f9;width:330px; font-size:95%;margin-top:0px;" !colspan="2" style="background-color:#CEDAF2; text-align:center"| {{#if: {{{NAME|}}}|<big>{{{NAME}}}</big>|<big>{{PAGENAME}}</big>}} |- {{#if: {{{STATUS|}}}| {{!}} style="vertical-align:top;" {{!}}Status {{!}} {{{STATUS}}} }} |- {{#if: {{{MENUCONFIG|}}}| {{!}} style="vertical-align:top;" {{!}}menuconfig {{!}} {{{MENUCONFIG}}} }} |- {{#if: {{{PINNING|}}}| {{!}} style="vertical-align:top;" {{!}}Pinning {{!}} {{{PINNING}}} }} |- {{#if: {{{ECMD|}}}| {{!}} style="vertical-align:top;" {{!}}Ecmd {{!}} {{{ECMD}}} }} |- {{#if: {{{CONTROL6|}}}| {{!}} style="vertical-align:top;" {{!}}Control6 {{!}} {{{CONTROL6}}} }} |- {{#if: {{{TIMER|}}}| {{!}} style="vertical-align:top;" {{!}}Uses Timer {{!}} {{{TIMER}}} }} |- {{#if: {{{DEPENDS|}}}| {{!}} style="vertical-align:top;" {{!}}Depends on {{!}} {{{DEPENDS}}} }} |- {{#if: {{{REQUIRES|}}}| {{!}} style="vertical-align:top;" {{!}}Requires {{!}} {{{REQUIRES}}} }} |- {{#if: {{{CODE|}}}| {{!}} style="vertical-align:top;" {{!}}Code {{!}} {{{CODE}}} }} |- |}</onlyinclude> == Templates for menuconfig == If you use one of the following templates, the module will automatically added to the proper category {{Codeline|<nowiki>{{I/O}}</nowiki>}} {{Codeline|<nowiki>{{Protocols}}</nowiki>}} {{Codeline|<nowiki>{{Applications}}</nowiki>}} == Templates for STATUS == {| style="width:50%" |- | {{Codeline|<nowiki>{{stable}}</nowiki>}} {{stable}} {{Codeline|<nowiki>{{Experimental}}</nowiki>}} {{Experimental}} {{Codeline|<nowiki>{{In_Development}}</nowiki>}} {{In Development}} {{Codeline|<nowiki>{{Unstable}}</nowiki>}} {{Unstable}} {{Codeline|<nowiki>{{Deprecated}}</nowiki>}} {{Deprecated}} |} == Templates for ECMD == {| style="width:50%" |- | {{Codeline|<nowiki>{{has_ecmd}}</nowiki>}} |} or leave blank == Templates for CONTROL6 == {| style="width:50%" |- | {{Codeline|<nowiki>{{has_control6}}</nowiki>}} |} or leave blank == Templates for TIMER == {| style="width:50%" |- | {{Codeline|<nowiki>{{occupies_timer|VALUE}}</nowiki>}} |} or leave blank == Example == <pre><nowiki> {{Module |NAME=Onewire |MENUCONFIG={{I/O}}->Onewire support |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }}</nowiki></pre> == Result == {{Module |NAME=Onewire |MENUCONFIG={{I/O}}->Onewire support |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |TIMER={{occupies_timer|1}} |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} 2ee98b789e5846145b814be0eb449280801ee3a0 0 138 1015 506 2013-04-02T20:21:27Z Mgue 312 timer wikitext text/x-wiki {{i18n|StellaLight}} {{Module |NAME=StellaLight |MENUCONFIG={{Applications}}->StellaLight: Multichannel pwm |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |DEPENDS=[[DMX Storage]] (optional), udpStella (optional) |REQUIRES= |TIMER={{occupies_timer|2}} |CODE=[https://github.com/ethersex/ethersex/tree/master/services/stella https://github.com/ethersex/ethersex/tree/master/services/stella] }} StellaLight produces PWM signals on up to 16 independent pins for driving LEDs or servo motors. == Internals == Stella uses an 8-bit Timer of your choice for producing the PWM signals. Since the overflow interrupts need to be very consistent, StellaLight will not work flawlessy when other modules are active that disable the interrupts for a short amount of time. This is a list of module where you can expect some problems with: [[Onewire]], [[RFM12]] (please add more if you find some). Moreover StellaLight does not support [http://en.wikipedia.org/wiki/Gamma_correction Gamma Correction] since that would require at least 10-12 bit PWM. == Configuration == In Menuconfig you can select the prescaler. '''The higher the frequency, the more often the StellaLight PWM functions will be executed, leading to an higher overall load of the device. So if you run into problems, try decreasing the frequency, ergo increase the prescaler.''' {| border="1" ! Option ! Prescaler |- | Very slow | 1024 |- | Slow | 256 |- | Normal | 128 |- | Fast | 64 |- |} You can calculate the resulting frequency by using this formula: F_CPU: The clockspeed of your AVR (like 8Mhz, 16Mhz etc.) ''F_STELLA=F_CPU/Prescaler/512'' So given a setting of "Normal" on a 16Mhz device will result in '''244Hz''' which is pretty good for most setups. So more than enough for the human eye (10 times more) If you have enabled [[DMX Storage]] in Menuconfig, you also can set the universe and start channel of StellaLight, so you can control StellaLight via [[Artnet]] or [[DMX FXSlot]]. == Pinning == {| border="1" |- | STELLA_PORT1_RANGE(PX'''I''',PX'''J''') | sets the range ('''I''' to '''J''') of StellaLight controlled pins on PORTX |- | STELLA_PORT2_RANGE(PX2'''I''',PX2'''J''') | sets the range ('''I''' to '''J''') of StellaLight controlled pins on PORTX2 |- | STELLA_USE_TIMER('''I''') | programs Timer'''I''' for StellaLight |- |} Two examples: '''1. 3 LEDs (e.g. RGB) on PORTA, Pins: 0,1,2''' <source lang="c"> ifdef(`conf_STELLA', `dnl STELLA_PORT1_RANGE(PA0,PA2) STELLA_USE_TIMER(2) ')dnl </source> '''2. 15 LEDs (e.g. 5x RGB) on PORTA, Pins: 0,1,2,3,4,5,6,7 on PORTD, Pins: 0,1,2,3,4,5,6''' <source lang="c" > ifdef(`conf_STELLA', `dnl STELLA_PORT1_RANGE(PA0,PA7) STELLA_PORT2_RANGE(PD0,PD6) STELLA_USE_TIMER(2) ')dnl </source> == udp control == We recommend to use the [[DMX Storage]]. But for easy set ups it is possible to use a simple udp protocol to control stella channels. Activate protocols->udpStella and configure the port. A datagram for stella has three bytes: {| border="1" ! Byte # ! Semantic ! Valid values |- | 1 | Command Byte | STELLA_SET_IMMEDIATELY=0, STELLA_SET_FADE=1, STELLA_SET_FLASHY=2, STELLA_SET_IMMEDIATELY_RELATIVE=3, STELLA_SET_FADESTEP=4, STELLA_GETALL = 255 |- | 2 | Channel | 0-15 |- | 3 | Value | 0-255 |- |} You will get back an UDP datagram if you send the STELLA_GETALL command. It consists of an identifier ["STELLA"]+[Amount of channels]+[channel#1]+..+[channel#n] == Alternative == Have a look at [[Starburst]] for an improved and more resource-conserving solution. [[Category:e6la]] fdc7a107f4b77aab521ea77235f9b10256b7d004 0 29 1019 982 2013-04-02T20:51:07Z GooPie4o 265 wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR Receivers->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |TIMER={{occupies_timer|0}}&{{occupies_timer|2}} (RX & TX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP is a port of the [http://www.mikrocontroller.net/articles/IRMP infrared multi-protocol decoder] for [[Ethersex]]. == Connection == The reception of IR signals is performed by a receiver TSOP1736 type (or similar). This may be connected to any pin. The interrogation of the pins and the decoding of the IR protocol is done in an ISR, which occupies one 8-bit timer of the ATmegas. When sending the signal with the carrier frequency of the respective IR Protocol is [[PWM]] modulated. This is another 8-bit timer of the ATmegas (OC0/OC2) is demonstrated. On the [[Etherrape]] board takes a [[NE555]] this function, ie the option ''Use external modulator for the transmitter'' is activated. It saves a timer on the [[AVR]] is set at a carrier frequency. Example of a ATMega32 from: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Meaning: * IRMP_RX - pin the IR receiver is connected to * IRMP_USE_TIMER2 - use Timer2 for receiver, Timer0 for sender (undef = reversed) * IRMP_RX_LOW_ACTIVE - the IR receiver is low-active (undef = high-active) * IRMP_RX_LED_LOW_ACTIVE - the control LED of the receiver is switched to USS (undef = switched to GND) * IRMP_TX - pin the IR sender is connected to (=output of Timer0 or Timer2, see IRMP_USE_TIMER2)<br>'''Caution: 0A to 2A if MCU with A / B channel''' * IRMP_TX_LED_LOW_ACTIVE - the control LED of the sender is switched to USS (undef = switched to GND) == Configuration == Each supported IR protocol occupies memory of code. Therefore, one should select only the required protocols. A detailed overview of the protocols are in [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail article in the mikrocontroller forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ --- Debugging Flags │ │ [ ] IRMP IRMP also decodes the RC5 protocol, so that the separately [[Ethersex]] contained [[RC5]] decoder is not needed any longer. == [[ECMD]] == IRMP implements an [[ECMD]] interface for reading received and decoded IR commands and send IR commands. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == === Output received characters via [[SYSLOG|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> IRMP_READ checks for received IR code and stores it in the variables IRMP_PROTOCOL, IRMP_ADDRESS, and IRMP_COMMAND IRMP_FLAGS. Return values ​​greater than zero indicate the validity of the variables. If IRMP_FLAGS = 1 it is a repetition. === Control of [[StellaLight|Stella]]/Pins by IR commands === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> The script switches the Stella channel 0 to 255 or 0, the remote control is a Denon (Protocol 8). With ''include'' access to the Stella sources granted.<br> Instead of ''"stella_setValue (STELLA_SET_IMMEDIATELY, 0, 255);"'' ''"PIN_SET (LED)"'' and ''"PIN_CLEAR (LED)"'' can be used ([[Named_PIN|named pin]]). |Named PIN]]). === Send IR commands === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON dnl 31 = BOSE dnl 32 = A1TVBOX IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Command 5678 to device 1234 will be send with one repetition using the NEC protocol. 032343354f61205192ee884a832130bafb14c257 1021 1019 2013-04-25T09:45:30Z GooPie4o 265 wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR Receivers->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |TIMER={{occupies_timer|0}}&{{occupies_timer|2}} (RX & TX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP is a port of the [http://www.mikrocontroller.net/articles/IRMP infrared multi-protocol decoder] for [[Ethersex]]. == Connection == The reception of IR signals is performed by a receiver TSOP1736 type (or similar). This may be connected to any pin. The interrogation of the pins and the decoding of the IR protocol is done in an ISR, which occupies one 8-bit timer of the ATmegas. When sending the signal with the carrier frequency of the respective IR Protocol is [[PWM]] modulated. This is another 8-bit timer of the ATmegas (OC0/OC2) is demonstrated. On the [[Etherrape]] board takes a [[NE555]] this function, ie the option ''Use external modulator for the transmitter'' is activated. It saves a timer on the [[AVR]] is set at a carrier frequency. Example of a ATMega32 from: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Meaning: * IRMP_RX - pin the IR receiver is connected to * IRMP_USE_TIMER2 - use Timer2 for receiver, Timer0 for sender (undef = reversed) * IRMP_RX_LOW_ACTIVE - the IR receiver is low-active (undef = high-active) * IRMP_RX_LED_LOW_ACTIVE - the control LED of the receiver is switched to USS (undef = switched to GND) * IRMP_TX - pin the IR sender is connected to (=output of Timer0 or Timer2, see IRMP_USE_TIMER2)<br>'''Caution: 0A to 2A if MCU with A / B channel''' * IRMP_TX_LED_LOW_ACTIVE - the control LED of the sender is switched to USS (undef = switched to GND) == Configuration == Each supported IR protocol occupies memory of code. Therefore, one should select only the required protocols. A detailed overview of the protocols are in [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail article in the mikrocontroller forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ [ ] ORTEK │ │ [ ] TELEFUNKEN │ │ [ ] ROOMBA │ │ --- Debugging Flags │ │ [ ] IRMP IRMP also decodes the RC5 protocol, so that the separately [[Ethersex]] contained [[RC5]] decoder is not needed any longer. == [[ECMD]] == IRMP implements an [[ECMD]] interface for reading received and decoded IR commands and send IR commands. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == === Output received characters via [[SYSLOG|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> IRMP_READ checks for received IR code and stores it in the variables IRMP_PROTOCOL, IRMP_ADDRESS, and IRMP_COMMAND IRMP_FLAGS. Return values ​​greater than zero indicate the validity of the variables. If IRMP_FLAGS = 1 it is a repetition. === Control of [[StellaLight|Stella]]/Pins by IR commands === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> The script switches the Stella channel 0 to 255 or 0, the remote control is a Denon (Protocol 8). With ''include'' access to the Stella sources granted.<br> Instead of ''"stella_setValue (STELLA_SET_IMMEDIATELY, 0, 255);"'' ''"PIN_SET (LED)"'' and ''"PIN_CLEAR (LED)"'' can be used ([[Named_PIN|named pin]]). |Named PIN]]). === Send IR commands === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON dnl 31 = BOSE dnl 32 = A1TVBOX dnl 32 = ORTEK dnl 32 = TELEFUNKEN dnl 32 = ROOMBA IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Command 5678 to device 1234 will be send with one repetition using the NEC protocol. cdf6a4550fae7df7d379c19c6d44d872354b2418 1023 1021 2013-04-25T09:47:07Z GooPie4o 265 /* Send IR commands */ wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR Receivers->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |TIMER={{occupies_timer|0}}&{{occupies_timer|2}} (RX & TX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP is a port of the [http://www.mikrocontroller.net/articles/IRMP infrared multi-protocol decoder] for [[Ethersex]]. == Connection == The reception of IR signals is performed by a receiver TSOP1736 type (or similar). This may be connected to any pin. The interrogation of the pins and the decoding of the IR protocol is done in an ISR, which occupies one 8-bit timer of the ATmegas. When sending the signal with the carrier frequency of the respective IR Protocol is [[PWM]] modulated. This is another 8-bit timer of the ATmegas (OC0/OC2) is demonstrated. On the [[Etherrape]] board takes a [[NE555]] this function, ie the option ''Use external modulator for the transmitter'' is activated. It saves a timer on the [[AVR]] is set at a carrier frequency. Example of a ATMega32 from: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Meaning: * IRMP_RX - pin the IR receiver is connected to * IRMP_USE_TIMER2 - use Timer2 for receiver, Timer0 for sender (undef = reversed) * IRMP_RX_LOW_ACTIVE - the IR receiver is low-active (undef = high-active) * IRMP_RX_LED_LOW_ACTIVE - the control LED of the receiver is switched to USS (undef = switched to GND) * IRMP_TX - pin the IR sender is connected to (=output of Timer0 or Timer2, see IRMP_USE_TIMER2)<br>'''Caution: 0A to 2A if MCU with A / B channel''' * IRMP_TX_LED_LOW_ACTIVE - the control LED of the sender is switched to USS (undef = switched to GND) == Configuration == Each supported IR protocol occupies memory of code. Therefore, one should select only the required protocols. A detailed overview of the protocols are in [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail article in the mikrocontroller forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ [ ] ORTEK │ │ [ ] TELEFUNKEN │ │ [ ] ROOMBA │ │ --- Debugging Flags │ │ [ ] IRMP IRMP also decodes the RC5 protocol, so that the separately [[Ethersex]] contained [[RC5]] decoder is not needed any longer. == [[ECMD]] == IRMP implements an [[ECMD]] interface for reading received and decoded IR commands and send IR commands. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == === Output received characters via [[SYSLOG|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> IRMP_READ checks for received IR code and stores it in the variables IRMP_PROTOCOL, IRMP_ADDRESS, and IRMP_COMMAND IRMP_FLAGS. Return values ​​greater than zero indicate the validity of the variables. If IRMP_FLAGS = 1 it is a repetition. === Control of [[StellaLight|Stella]]/Pins by IR commands === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> The script switches the Stella channel 0 to 255 or 0, the remote control is a Denon (Protocol 8). With ''include'' access to the Stella sources granted.<br> Instead of ''"stella_setValue (STELLA_SET_IMMEDIATELY, 0, 255);"'' ''"PIN_SET (LED)"'' and ''"PIN_CLEAR (LED)"'' can be used ([[Named_PIN|named pin]]). |Named PIN]]). === Send IR commands === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON dnl 31 = BOSE dnl 32 = A1TVBOX dnl 33 = ORTEK dnl 34 = TELEFUNKEN dnl 35 = ROOMBA IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Command 5678 to device 1234 will be send with one repetition using the NEC protocol. e2a38017c250dede40271a20cd4da0df640a69ff 0 30 1020 913 2013-04-02T20:51:26Z GooPie4o 265 wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR Receivers->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |TIMER={{occupies_timer|0}}&{{occupies_timer|2}} (RX & TX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP ist eine Portierung des [http://www.mikrocontroller.net/articles/IRMP Infrarot-Multiprotokoll-Decoders] nach [[Ethersex]]. == Anschluss == Der Empfang der IR-Signale erfolgt durch einen Empfänger vom Typ TSOP1736 (oder ähnlich). Dieser kann an einem beliebigen Pin angeschlossen werden. Die Abfrage des Pins und die Dekodierung des IR-Protokolls erfolgt in einer ISR, die einen 8-Bit-Timer des ATMEGAs belegt. Beim Senden wird das Signal mit der Trägerfrequenz des jeweiligen IR-Protokolls über [[PWM_(Deutsch)|PWM]] moduliert. Dazu wird ein weiterer 8-Bit Timer des ATMEGAs (OC0/OC2) belegt. Auf dem '''[[Etherape_(Deutsch)|Etherrape]]'''-Board übernimmt ein [[NE555_(Deutsch)|NE555]] diese Funktion, d.h. die Option ''Use external modulator for sender'' ist zu aktivieren. Man spart einen Timer des [[AVR_(Deutsch)|AVR]] und ist auf eine Trägerfrequenz festgelegt. Beispiel für einen ATMega32 aus: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Bedeutung: * IRMP_RX - Pin an dem der IR-Empfänger angeschlossen ist * IRMP_USE_TIMER2 - benutze Timer2 für den Empfang, Timer0 für das Senden (undef = umgekehrt) * IRMP_RX_LOW_ACTIVE - der IR-Empfänger ist Low-Aktiv (undef = High-aktiv) * IRMP_RX_LED_LOW_ACTIVE - die Kontroll-LED des Empfängers ist gegen USS geschaltet (undef = gegen GND geschaltet) * IRMP_TX - Pin an dem der IR-Sender angschlossen ist (=Ausgang des Timer0 oder Timer2, vgl. IRMP_USE_TIMER2)<br>'''Achtung: 0A bzw 2A bei MCU mit A/B Kanal''' * IRMP_TX_LED_LOW_ACTIVE - die Kontroll-LED des Senders ist gegen USS geschaltet (undef = gegen GND geschaltet) == Konfiguration == Jedes unterstützte IR-Protokoll "verbrät" Speicher an Code. Deshalb sollte man nur die benötigten Protokolle auswählen. Eine detailierte Übersicht über die Protokolle gibt der [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail Artikel im Mikrocontroller Forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ --- Debugging Flags │ │ [ ] IRMP IRMP dekodiert auch das RC5-Protokoll, so dass der separat in [[Ethersex_(Deutsch)|Ethersex]] enthaltene [[RC5_(Deutsch)|RC5]]-Dekoder nicht länger benötigt wird. == [[ECMD_(Deutsch)|ECMD]] == IRMP implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle zum Auslesen empfangener und dekodierter IR-Kommandos und zum Senden von IR-Kommandos. Siehe [[ECMD_Reference|ECMD Referenz]]. == [[Control6_(Deutsch)|Control6]] == === Ausgabe empfangener IR-Zeichen via [[SYSLOG_(Deutsch)|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> Mit IRMP_READ wird auf empfangenen IR-Code geprüft und dieser in die Variablen IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND und IRMP_FLAGS gespeichert. Rückgabewerte größer Null signalisieren die Gültigkeit der Variablen. Bei IRMP_FLAGS=1 handelt es sich um eine Wiederholung. === Steuern von [[StellaLight_(Deutsch)|Stella]]/Pins durch IR-Zeichen === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> Das Script schaltet den Stella Channel 0 auf 255 oder auf 0, die Fernbedienung ist hier eine Denon (Protocol 8). Mit ''include'' wurde dem Script der Zugriff auf die Stellasourcen gestattet.<br> Statt ''"stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255);"'' kann auch ''"PIN_SET(LED)"'' und ''"PIN_CLEAR(LED)"'' verwendet werden ([[Named_PIN_(Deutsch)|Named PIN]]). === Senden von IR-Zeichen === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 * no tx support yet dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON * no tx support yet dnl 31 = BOSE dnl 32 = A1TVBOX IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Kommando 5678 an Gerät 1234 wird mit einer Wiederholung im NEC-Protokoll gesendet. 57a04df3f8c5eac8029f1b95557128f696cced92 1022 1020 2013-04-25T09:46:42Z GooPie4o 265 wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR Receivers->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |TIMER={{occupies_timer|0}}&{{occupies_timer|2}} (RX & TX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP ist eine Portierung des [http://www.mikrocontroller.net/articles/IRMP Infrarot-Multiprotokoll-Decoders] nach [[Ethersex]]. == Anschluss == Der Empfang der IR-Signale erfolgt durch einen Empfänger vom Typ TSOP1736 (oder ähnlich). Dieser kann an einem beliebigen Pin angeschlossen werden. Die Abfrage des Pins und die Dekodierung des IR-Protokolls erfolgt in einer ISR, die einen 8-Bit-Timer des ATMEGAs belegt. Beim Senden wird das Signal mit der Trägerfrequenz des jeweiligen IR-Protokolls über [[PWM_(Deutsch)|PWM]] moduliert. Dazu wird ein weiterer 8-Bit Timer des ATMEGAs (OC0/OC2) belegt. Auf dem '''[[Etherape_(Deutsch)|Etherrape]]'''-Board übernimmt ein [[NE555_(Deutsch)|NE555]] diese Funktion, d.h. die Option ''Use external modulator for sender'' ist zu aktivieren. Man spart einen Timer des [[AVR_(Deutsch)|AVR]] und ist auf eine Trägerfrequenz festgelegt. Beispiel für einen ATMega32 aus: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Bedeutung: * IRMP_RX - Pin an dem der IR-Empfänger angeschlossen ist * IRMP_USE_TIMER2 - benutze Timer2 für den Empfang, Timer0 für das Senden (undef = umgekehrt) * IRMP_RX_LOW_ACTIVE - der IR-Empfänger ist Low-Aktiv (undef = High-aktiv) * IRMP_RX_LED_LOW_ACTIVE - die Kontroll-LED des Empfängers ist gegen USS geschaltet (undef = gegen GND geschaltet) * IRMP_TX - Pin an dem der IR-Sender angschlossen ist (=Ausgang des Timer0 oder Timer2, vgl. IRMP_USE_TIMER2)<br>'''Achtung: 0A bzw 2A bei MCU mit A/B Kanal''' * IRMP_TX_LED_LOW_ACTIVE - die Kontroll-LED des Senders ist gegen USS geschaltet (undef = gegen GND geschaltet) == Konfiguration == Jedes unterstützte IR-Protokoll "verbrät" Speicher an Code. Deshalb sollte man nur die benötigten Protokolle auswählen. Eine detailierte Übersicht über die Protokolle gibt der [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail Artikel im Mikrocontroller Forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ [ ] ORTEK │ │ [ ] TELEFUNKEN │ │ [ ] ROOMBA │ │ --- Debugging Flags │ │ [ ] IRMP IRMP dekodiert auch das RC5-Protokoll, so dass der separat in [[Ethersex_(Deutsch)|Ethersex]] enthaltene [[RC5_(Deutsch)|RC5]]-Dekoder nicht länger benötigt wird. == [[ECMD_(Deutsch)|ECMD]] == IRMP implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle zum Auslesen empfangener und dekodierter IR-Kommandos und zum Senden von IR-Kommandos. Siehe [[ECMD_Reference|ECMD Referenz]]. == [[Control6_(Deutsch)|Control6]] == === Ausgabe empfangener IR-Zeichen via [[SYSLOG_(Deutsch)|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> Mit IRMP_READ wird auf empfangenen IR-Code geprüft und dieser in die Variablen IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND und IRMP_FLAGS gespeichert. Rückgabewerte größer Null signalisieren die Gültigkeit der Variablen. Bei IRMP_FLAGS=1 handelt es sich um eine Wiederholung. === Steuern von [[StellaLight_(Deutsch)|Stella]]/Pins durch IR-Zeichen === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> Das Script schaltet den Stella Channel 0 auf 255 oder auf 0, die Fernbedienung ist hier eine Denon (Protocol 8). Mit ''include'' wurde dem Script der Zugriff auf die Stellasourcen gestattet.<br> Statt ''"stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255);"'' kann auch ''"PIN_SET(LED)"'' und ''"PIN_CLEAR(LED)"'' verwendet werden ([[Named_PIN_(Deutsch)|Named PIN]]). === Senden von IR-Zeichen === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 * no tx support yet dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON * no tx support yet dnl 31 = BOSE dnl 32 = A1TVBOX dnl 33 = ORTEK dnl 34 = TELEFUNKEN dnl 35 = ROOMBA IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Kommando 5678 an Gerät 1234 wird mit einer Wiederholung im NEC-Protokoll gesendet. 91621614e229944c6c5ad0af244c3e6efc0e2e5b 0 169 1024 429 2013-05-02T10:59:20Z Dg9oaa 103 wikitext text/x-wiki {{i18n|Quick Start Guide/Preparation}} = Requirements = * AVR GCC-Compiler (Version 4.1 or higher) * AVR LIBC (Version 1.6.8, for 128er ATMegas 1.7) * GNU-Tools (Bash, Make, m4, awk) * AVR-Programmer (e.g. avrdude) '''Attention:''' binutils ''2.22'' has a bug that causes the compilation of ethersex to fail. Install version 2.21 until [http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52692 GCC 4.7.1 has been released]. == Linux Debian / Ubuntu == apt-get install gcc-avr avr-libc binutils-avr m4 gawk libncurses5-dev make dialog git-core avrdude == Arch Linux == pacman -Sy m4 avr-binutils avr-libc avrdude avr-gcc git gawk ncurses make perl == FreeBSD == add gmake avr-binutils avr-gcc avr-libc (to compile) add gsed m4 gawk (need for ethersex), add avrdude use add_page -r PKG-NAME or use ports (goggle freebsd ports install) == Mac OSX == Using MacPorts (www.macports.org) Apple Bash and sed doesn't work, you need to install Bash V4.0 and GNU sed. First, sync the Port Repository to ensure that you´ll build the latest versions of the requirements. port selfupgrade port install git-core avrdude avr-binutils avr-gcc avr-libc bash sed You can also use the CrossPack, but MacPorts is more straightforward and updated. [http://www.obdev.at/products/crosspack/index-de.html] If the MacPort versions of avr-gcc or avrdude are too old. Here is a instuction how to build the toolchain manually: [http://www.heise.de/ct/projekte/machmit/ctbot/wiki/AVRToolchain] = Download the Source from GitHub = You can download Ethersex from github via git protocol git clone git://github.com/ethersex/ethersex.git or via http git clone http://github.com/ethersex/ethersex.git Updating a local version of ethersex is possible with: git pull origin [[Quick_Start_Guide/Configuration | next step]] 54953c897d0337067cafb8c62313bd597573bbcb 1025 1024 2013-05-02T12:50:57Z Dg9oaa 103 /* FreeBSD */ wikitext text/x-wiki {{i18n|Quick Start Guide/Preparation}} = Requirements = * AVR GCC-Compiler (Version 4.1 or higher) * AVR LIBC (Version 1.6.8, for 128er ATMegas 1.7) * GNU-Tools (Bash, Make, m4, awk) * AVR-Programmer (e.g. avrdude) '''Attention:''' binutils ''2.22'' has a bug that causes the compilation of ethersex to fail. Install version 2.21 until [http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52692 GCC 4.7.1 has been released]. == Linux Debian / Ubuntu == apt-get install gcc-avr avr-libc binutils-avr m4 gawk libncurses5-dev make dialog git-core avrdude == Arch Linux == pacman -Sy m4 avr-binutils avr-libc avrdude avr-gcc git gawk ncurses make perl == FreeBSD == add gmake avr-binutils avr-gcc avr-libc (to compile) add gsed m4 gawk (need for ethersex), add avrdude git use add_page -r PKG-NAME or use ports (goggle freebsd ports install) == Mac OSX == Using MacPorts (www.macports.org) Apple Bash and sed doesn't work, you need to install Bash V4.0 and GNU sed. First, sync the Port Repository to ensure that you´ll build the latest versions of the requirements. port selfupgrade port install git-core avrdude avr-binutils avr-gcc avr-libc bash sed You can also use the CrossPack, but MacPorts is more straightforward and updated. [http://www.obdev.at/products/crosspack/index-de.html] If the MacPort versions of avr-gcc or avrdude are too old. Here is a instuction how to build the toolchain manually: [http://www.heise.de/ct/projekte/machmit/ctbot/wiki/AVRToolchain] = Download the Source from GitHub = You can download Ethersex from github via git protocol git clone git://github.com/ethersex/ethersex.git or via http git clone http://github.com/ethersex/ethersex.git Updating a local version of ethersex is possible with: git pull origin [[Quick_Start_Guide/Configuration | next step]] 796226bbc8d041e2a1c96eca0c2109c553ac7d0a 0 358 1027 2013-05-11T21:59:43Z Beroot 198 Created page with "{{i18n|PCA9632}} {{Module |NAME=PCA9632 |MENUCONFIG={{I/O}}->{{I2C Master}}->I2C PCA9632 |STATUS={{Experimental}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6= |DEPENDS=[[ECMD]] [[I2…" wikitext text/x-wiki {{i18n|PCA9632}} {{Module |NAME=PCA9632 |MENUCONFIG={{I/O}}->{{I2C Master}}->I2C PCA9632 |STATUS={{Experimental}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6= |DEPENDS=[[ECMD]] [[I2C Master]] [[I2C Generic]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/i2c/master/ https://github.com/ethersex/ethersex/tree/master/hardware/i2c/master] }} Driver for the PCA9632 4-Bit LED driver I2C-bus chip from NXP. Please refer to the datasheet for further informations about setting the registers and connecting LEDs to the driver outputs. The dataheet can be fopund here: [http://www.nxp.com/documents/data_sheet/PCA9632.pdf] == Connection == The PCA9632 is connected to the I2C-bus (with pins SDA and SCL). The particular pin numbers depend on the package used (8- or 10-pin). The device slave address is 0x62 (dec. 98). This address is fixed for the 8-pin version. With this package only one chip can be connected to an i2c-bus. The 10-pin package hat two additional address pins which allow up to 4 chips on one bus. == Configuration == │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ Network ---> │ │ I/O ---> ... │ │ [*] I2C Master Support ---> ... │ │ [*] I2C generic read/write support ---> ... │ │ [*] I2C PCA9632 4-bit LED dimmer == [[ECMD]] == PCA9632 implements a [[ECMD]] interface for reading and writing the LED status. See [[ECMD_Reference|ECMD reference]]. == Provided Functions == ''hardware/i2c/master/i2c_pca9632.h'' provides and defines the following functions: '''i2c_pca9632_reset()''' Resets the device to the power-up state values. Returns '''0''' when ok or '''1''' if an error occurred. '''i2c_pca9632_init(uint8_t address, uint8_t mode1, uint8_t mode2, uint8_t led_out_state)''' Initializes the "configuration" registers. ''Address'' is the slave address of the chip (0x62h). In register ''MODE1'' only bit 4 is essential. After power up the internal oscillator is switched off representing bit is 1 (low power mode). To be able to change the LEDs PWM values the oscillator must be turned on by setting bit 4 to 0. All other bits are for standard applications not relevant. Register ''MODE2'' set open-drain or toem pole structure (bit 2), sets outputs inverted or not (bit 4) and sets the group control to dimming or blinking (bit 5). ''led_out_state'' set the LED drivers ''on'', ''off'', ''by PWM'', ''additional group dimm/blink''. '''i2c_pca9632_set_blink(uint8_t address, uint8_t grppwm, uint8_t grpfreq)''' When ''dimming'' is set in MODE2 register the ''grppwm'' value sets the global dimmimgn of all LEDs. When ''blinking'' is set by MODE2 then ''grppwm'' sets the duty cycle and ''grpfreq'' sets the frequency. '''i2c_pca9632_set_led(uint8_t address, uint8_t led_x, uint8_t pwm_x)''' Sets the individual PWM_x value of LED_x (x from 0 to 3). Corresponds to write the registers 0x02h (LED0) to 0x05h (LED3). '''i2c_pca9632_read_led(uint8_t address, uint8_t led_x)''' Reads and returns the individual PWM value of LED_x (0 to 3). == Register Explanations == <source lang="text"> MODE1 (register address 0x00h) bit 4 (SLEEP) has to be set to 0 to start the oscillator and to be able to set LED PWM values. MODE2 (register address 0x01h) (* is default value) bit value description 0 0* unused 1 1* unused 2 0* output open-drain 1 output totem pole 3 0* change on STOP 1 change on ACK (important for synchronizing chips) 4 0* output NOT inverted 1 output inverted 5 0* group control = dimming 1 group control = blinking 6 0* reserved 7 0* reserved PWM registers 0 to 3 (0x02h to 0x05h) (* is default value) address register value 02h PWM0 00000000* 03h PWM1 00000000* 04h PWM2 00000000* 05h PWM3 00000000* GRPPWM Group duty cycle register (0x06h) address register value 06h GRPPWM 11111111 GRPFREQ Group frequency register (0x07h) address register value 07h GRPFREQ 00000000* LED_OUT_STATE (register address 0x08h) (* is default value) bit symbol value 0,1 LDR0 00* 2,3 LDR1 00* 4,5 LDR2 00* 6,7 LDR3 00* LDRx = 00 LED driver is off LDRx = 01 LED driver is on LDRx = 10 LED driver is individually controlled by its PWM LDRx = 11 LED driver is additionally controlled by group dimming or blinking </source> b5ebda006ba1ebb78c7939d0f5ee035d798053ef 0 359 1029 2013-06-02T16:54:34Z GooPie4o 265 Created page with "{{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=…" wikitext text/x-wiki {{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader] }} 68ebe1bd5855ff361abde48fe6f64875b1492eb3 1030 1029 2013-06-02T16:57:04Z GooPie4o 265 wikitext text/x-wiki {{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader] }} == Anschluss == == Konfiguration == == [[ECMD_(Deutsch)|ECMD]] == == [[Control6_(Deutsch)|Control6]] == 40df2475623c871c5e3be087af886fff0b23d6b0 1032 1030 2013-06-03T07:06:41Z GooPie4o 265 wikitext text/x-wiki {{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader] }} Das Modul basiert auf Roland Riegels [http://www.example.com MMC/SD/SDHC card library] ergänzt um die Anbindung an das Ethersex [[VFS|Virtual File System]]. == Anschluss == == Konfiguration == == [[ECMD_(Deutsch)|ECMD]] == == [[Control6_(Deutsch)|Control6]] == a2916ee2bec2888d28ec185ae1cf19ef4269b72f 1033 1032 2013-06-04T05:48:53Z GooPie4o 265 wikitext text/x-wiki {{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader] }} Das Modul basiert auf Roland Riegels [http://www.example.com MMC/SD/SDHC card library] ergänzt um die Anbindung an das Ethersex [[VFS|Virtual File System]]. == Anschluss == MMC- und SD-Speicherkarten lassen sich im [[SPI]]-Modus relativ einfach mit einem Mikrocontroller ansteuern. Prinzipiell gibt es zwischen SD-Card und MMC nicht viele Unterschiede, allerdings sind SD-Karten weiter verbreitet, in der Regel schneller als MMCs, und haben ein besser implementiertes SPI-Interface. Es existieren diverse Varianten (miniSD, microSD), die zur normalen SD-Card weitgehend kompatibel sind. Die Karte liest das anliegende Datenbit mit der steigenden Taktflanke ein, als [[SPI]]-Modi eignen sich somit Mode 0 und Mode 3. Bei MMCs ist der SPI-Modus nicht genau spezifiziert, somit kommt es durchaus mal vor, dass der [[SPI]]-Modus je nach Karte unterschiedlich gewählt werden muss. SD-Karten werden typischerweise mit 3,3 V und Microcontroller oft mit 5 V betrieben. Das erzwingt eine [http://www.mikrocontroller.net/articles/Pegelwandler#5V_.3C-.3E_3.3V Pegelanpassung], weil die Eingangsleitungen zur SD-Karte nicht 5V tolerant sind. Von einer [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#Bekannte_Fehler Pegelanpassung mit Widerständen] wird abgeraten. Neben den Leitungen, die zur SD-Karte führen, gibt es noch zwei weitere Leitungen, die auf den SD-Karten-Sockel führen: nämlich die card-detect Leitung und die write-protect Leitung. Sie dienen dazu, wie die Namen schon sagen, das physische Vorhandensein einer Karte im SD-Sockel und die Stellung des Schreibschutzschiebers zu signalisieren. == Konfiguration == == [[ECMD_(Deutsch)|ECMD]] == == [[Control6_(Deutsch)|Control6]] == e7fa9c8fee28ff7707b24eb0479002782a3be9b2 1034 1033 2013-06-04T05:52:35Z GooPie4o 265 /* Anschluss */ wikitext text/x-wiki {{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader] }} Das Modul basiert auf Roland Riegels [http://www.example.com MMC/SD/SDHC card library] ergänzt um die Anbindung an das Ethersex [[VFS|Virtual File System]]. == Anschluss == MMC- und SD-Speicherkarten lassen sich im [[SPI]]-Modus relativ einfach mit einem Mikrocontroller ansteuern. Prinzipiell gibt es zwischen SD-Card und MMC nicht viele Unterschiede, allerdings sind SD-Karten weiter verbreitet, in der Regel schneller als MMCs, und haben ein besser implementiertes SPI-Interface. Es existieren diverse Varianten (miniSD, microSD), die zur normalen SD-Card weitgehend kompatibel sind. Die Karte liest das anliegende Datenbit mit der steigenden Taktflanke ein, als [[SPI]]-Modi eignen sich somit Mode 0 und Mode 3. Bei MMCs ist der SPI-Modus nicht genau spezifiziert, somit kommt es durchaus mal vor, dass der [[SPI]]-Modus je nach Karte unterschiedlich gewählt werden muss. SD-Karten werden typischerweise mit 3,3V und Microcontroller oft mit 5 V betrieben. Das erzwingt eine [http://www.mikrocontroller.net/articles/Pegelwandler#5V_.3C-.3E_3.3V Pegelanpassung], weil die Eingangsleitungen zur SD-Karte nicht 5V tolerant sind. Von einer [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#Bekannte_Fehler Pegelanpassung mit Widerständen] wird abgeraten. Neben den Leitungen, die zur SD-Karte führen, gibt es noch zwei weitere Leitungen, die auf den SD-Karten-Sockel führen: nämlich die card-detect Leitung und die write-protect Leitung. Sie dienen dazu, wie die Namen schon sagen, das physische Vorhandensein einer Karte im SD-Sockel und die Stellung des Schreibschutzschiebers zu signalisieren. == Konfiguration == == [[ECMD_(Deutsch)|ECMD]] == == [[Control6_(Deutsch)|Control6]] == 483c96f6668a494a4e0bfe5650fa1eb5f5018754 1036 1034 2013-06-04T10:24:07Z GooPie4o 265 /* Konfiguration */ wikitext text/x-wiki {{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader] }} Das Modul basiert auf Roland Riegels [http://www.example.com MMC/SD/SDHC card library] ergänzt um die Anbindung an das Ethersex [[VFS|Virtual File System]]. == Anschluss == MMC- und SD-Speicherkarten lassen sich im [[SPI]]-Modus relativ einfach mit einem Mikrocontroller ansteuern. Prinzipiell gibt es zwischen SD-Card und MMC nicht viele Unterschiede, allerdings sind SD-Karten weiter verbreitet, in der Regel schneller als MMCs, und haben ein besser implementiertes SPI-Interface. Es existieren diverse Varianten (miniSD, microSD), die zur normalen SD-Card weitgehend kompatibel sind. Die Karte liest das anliegende Datenbit mit der steigenden Taktflanke ein, als [[SPI]]-Modi eignen sich somit Mode 0 und Mode 3. Bei MMCs ist der SPI-Modus nicht genau spezifiziert, somit kommt es durchaus mal vor, dass der [[SPI]]-Modus je nach Karte unterschiedlich gewählt werden muss. SD-Karten werden typischerweise mit 3,3V und Microcontroller oft mit 5 V betrieben. Das erzwingt eine [http://www.mikrocontroller.net/articles/Pegelwandler#5V_.3C-.3E_3.3V Pegelanpassung], weil die Eingangsleitungen zur SD-Karte nicht 5V tolerant sind. Von einer [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#Bekannte_Fehler Pegelanpassung mit Widerständen] wird abgeraten. Neben den Leitungen, die zur SD-Karte führen, gibt es noch zwei weitere Leitungen, die auf den SD-Karten-Sockel führen: nämlich die card-detect Leitung und die write-protect Leitung. Sie dienen dazu, wie die Namen schon sagen, das physische Vorhandensein einer Karte im SD-Sockel und die Stellung des Schreibschutzschiebers zu signalisieren. == Konfiguration == ifdef(`conf_SD_READER', ` /* port the sd-reader CS is attached to */ pin(SPI_CS_SD_READER, PB2, OUTPUT) /* uncomment and edit this if you have connected the CD (card detect) signal */ pin(SD_READER_AVAILABLE, PD4, INPUT) /* uncomment and edit this if you have connected the WP (write protected) signal */ pin(SD_READER_WR_PROTECT, PD5, INPUT) ') == [[ECMD_(Deutsch)|ECMD]] == == [[Control6_(Deutsch)|Control6]] == cda1cdb9946d4a6fbd6ae7d798f0a852b509bb97 1037 1036 2013-06-04T10:24:57Z GooPie4o 265 /* Anschluss */ wikitext text/x-wiki {{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader] }} Das Modul basiert auf Roland Riegels [http://www.example.com MMC/SD/SDHC card library] ergänzt um die Anbindung an das Ethersex [[VFS|Virtual File System]]. == Anschluss == MMC- und SD-Speicherkarten lassen sich im [[SPI]]-Modus relativ einfach mit einem Mikrocontroller ansteuern. Prinzipiell gibt es zwischen SD-Card und MMC nicht viele Unterschiede, allerdings sind SD-Karten weiter verbreitet, in der Regel schneller als MMCs, und haben ein besser implementiertes SPI-Interface. Es existieren diverse Varianten (miniSD, microSD), die zur normalen SD-Card weitgehend kompatibel sind. Die Karte liest das anliegende Datenbit mit der steigenden Taktflanke ein, als [[SPI]]-Modi eignen sich somit Mode 0 und Mode 3. Bei MMCs ist der SPI-Modus nicht genau spezifiziert, somit kommt es durchaus mal vor, dass der [[SPI]]-Modus je nach Karte unterschiedlich gewählt werden muss. SD-Karten werden typischerweise mit 3,3V und Microcontroller oft mit 5V betrieben. Das erzwingt eine [http://www.mikrocontroller.net/articles/Pegelwandler#5V_.3C-.3E_3.3V Pegelanpassung], weil die Eingangsleitungen zur SD-Karte nicht 5V tolerant sind. Von einer [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#Bekannte_Fehler Pegelanpassung mit Widerständen] wird abgeraten. Neben den Leitungen, die zur SD-Karte führen, gibt es noch zwei weitere Leitungen, die auf den SD-Karten-Sockel führen: nämlich die card-detect Leitung und die write-protect Leitung. Sie dienen dazu, wie die Namen schon sagen, das physische Vorhandensein einer Karte im SD-Sockel und die Stellung des Schreibschutzschiebers zu signalisieren. == Konfiguration == ifdef(`conf_SD_READER', ` /* port the sd-reader CS is attached to */ pin(SPI_CS_SD_READER, PB2, OUTPUT) /* uncomment and edit this if you have connected the CD (card detect) signal */ pin(SD_READER_AVAILABLE, PD4, INPUT) /* uncomment and edit this if you have connected the WP (write protected) signal */ pin(SD_READER_WR_PROTECT, PD5, INPUT) ') == [[ECMD_(Deutsch)|ECMD]] == == [[Control6_(Deutsch)|Control6]] == 02b801174d46eac658eb6fbe2a32ef05887069d8 1038 1037 2013-06-04T10:26:30Z GooPie4o 265 wikitext text/x-wiki {{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader] }} Das Modul basiert auf Roland Riegels [http://www.roland-riegel.de/sd-reader/ MMC/SD/SDHC card library] ergänzt um die Anbindung an das Ethersex [[VFS|Virtual File System]]. == Anschluss == MMC- und SD-Speicherkarten lassen sich im [[SPI]]-Modus relativ einfach mit einem Mikrocontroller ansteuern. Prinzipiell gibt es zwischen SD-Card und MMC nicht viele Unterschiede, allerdings sind SD-Karten weiter verbreitet, in der Regel schneller als MMCs, und haben ein besser implementiertes SPI-Interface. Es existieren diverse Varianten (miniSD, microSD), die zur normalen SD-Card weitgehend kompatibel sind. Die Karte liest das anliegende Datenbit mit der steigenden Taktflanke ein, als [[SPI]]-Modi eignen sich somit Mode 0 und Mode 3. Bei MMCs ist der SPI-Modus nicht genau spezifiziert, somit kommt es durchaus mal vor, dass der [[SPI]]-Modus je nach Karte unterschiedlich gewählt werden muss. SD-Karten werden typischerweise mit 3,3V und Microcontroller oft mit 5V betrieben. Das erzwingt eine [http://www.mikrocontroller.net/articles/Pegelwandler#5V_.3C-.3E_3.3V Pegelanpassung], weil die Eingangsleitungen zur SD-Karte nicht 5V tolerant sind. Von einer [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#Bekannte_Fehler Pegelanpassung mit Widerständen] wird abgeraten. Neben den Leitungen, die zur SD-Karte führen, gibt es noch zwei weitere Leitungen, die auf den SD-Karten-Sockel führen: nämlich die card-detect Leitung und die write-protect Leitung. Sie dienen dazu, wie die Namen schon sagen, das physische Vorhandensein einer Karte im SD-Sockel und die Stellung des Schreibschutzschiebers zu signalisieren. == Konfiguration == ifdef(`conf_SD_READER', ` /* port the sd-reader CS is attached to */ pin(SPI_CS_SD_READER, PB2, OUTPUT) /* uncomment and edit this if you have connected the CD (card detect) signal */ pin(SD_READER_AVAILABLE, PD4, INPUT) /* uncomment and edit this if you have connected the WP (write protected) signal */ pin(SD_READER_WR_PROTECT, PD5, INPUT) ') == [[ECMD_(Deutsch)|ECMD]] == == [[Control6_(Deutsch)|Control6]] == accfc34e170e5385a47bb117fca1b7d44ffdac11 1039 1038 2013-06-04T10:33:42Z GooPie4o 265 wikitext text/x-wiki {{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader] }} Das Modul basiert auf Roland Riegels [http://www.roland-riegel.de/sd-reader/ MMC/SD/SDHC card library] ergänzt um die Anbindung an das Ethersex [[VFS|Virtual File System]]. == Anschluss == MMC- und SD-Speicherkarten lassen sich im [[SPI]]-Modus relativ einfach mit einem Mikrocontroller ansteuern. Prinzipiell gibt es zwischen SD-Card und MMC nicht viele Unterschiede, allerdings sind SD-Karten weiter verbreitet, in der Regel schneller als MMCs, und haben ein besser implementiertes SPI-Interface. Es existieren diverse Varianten (miniSD, microSD), die zur normalen SD-Card weitgehend kompatibel sind. Die Karte liest das anliegende Datenbit mit der steigenden Taktflanke ein, als [[SPI]]-Modi eignen sich somit Mode 0 und Mode 3. Bei MMCs ist der SPI-Modus nicht genau spezifiziert, somit kommt es durchaus mal vor, dass der [[SPI]]-Modus je nach Karte unterschiedlich gewählt werden muss. SD-Karten werden typischerweise mit 3,3V und Microcontroller oft mit 5V betrieben. Das erzwingt eine [http://www.mikrocontroller.net/articles/Pegelwandler#5V_.3C-.3E_3.3V Pegelanpassung], weil die Eingangsleitungen zur SD-Karte nicht 5V tolerant sind. Von einer [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#Bekannte_Fehler Pegelanpassung mit Widerständen] wird abgeraten. Neben den Leitungen, die zur SD-Karte führen, gibt es noch zwei weitere Leitungen, die auf den SD-Karten-Sockel führen: nämlich die card-detect Leitung und die write-protect Leitung. Sie dienen dazu, wie die Namen schon sagen, das physische Vorhandensein einer Karte im SD-Sockel und die Stellung des Schreibschutzschiebers zu signalisieren. ifdef(`conf_SD_READER', ` /* port the sd-reader CS is attached to */ pin(SPI_CS_SD_READER, PB2, OUTPUT) /* uncomment and edit this if you have connected the CD (card detect) signal */ pin(SD_READER_AVAILABLE, PD4, INPUT) /* uncomment and edit this if you have connected the WP (write protected) signal */ pin(SD_READER_WR_PROTECT, PD5, INPUT) ') == Konfiguration == | | General Setup ---> | | ... | | [*] VFS (Virtual File System) support ---> | | ... | | [*] SD/MMC-Card Filesystem | | | | I/O ---> | | ... | | [*] SD/MMC-Card Reader ---> | | ... | | [ ] SDHC support | | | | [*] VFAT LFN support | | | | [ ] Read-only mode | | | | [*] Use read-timeout | | | | [*] Ping-read SD card every 10s | | | | --- Debugging Flags | | | | [ ] SD-Reader | | == [[ECMD_(Deutsch)|ECMD]] == == [[Control6_(Deutsch)|Control6]] == bff1bf4e0766832701d0a47cb0cca52b432413fa 1040 1039 2013-06-04T10:45:06Z GooPie4o 265 /* Anschluss */ wikitext text/x-wiki {{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader] }} Das Modul basiert auf Roland Riegels [http://www.roland-riegel.de/sd-reader/ MMC/SD/SDHC card library] ergänzt um die Anbindung an das Ethersex [[VFS|Virtual File System]]. == Anschluss == MMC- und SD-Speicherkarten lassen sich im [[SPI]]-Modus relativ einfach mit einem Mikrocontroller ansteuern. Prinzipiell gibt es zwischen SD-Card und MMC nicht viele Unterschiede, allerdings sind SD-Karten weiter verbreitet, in der Regel schneller als MMCs, und haben ein besser implementiertes SPI-Interface. Es existieren diverse Varianten (miniSD, microSD), die zur normalen SD-Card weitgehend kompatibel sind. Die Karte liest das anliegende Datenbit mit der steigenden Taktflanke ein, als [[SPI]]-Modi eignen sich somit Mode 0 und Mode 3. Bei MMCs ist der SPI-Modus nicht genau spezifiziert, somit kommt es durchaus mal vor, dass der [[SPI]]-Modus je nach Karte unterschiedlich gewählt werden muss. SD-Karten werden typischerweise mit 3,3V und Microcontroller oft mit 5V betrieben. Das erzwingt eine [http://www.mikrocontroller.net/articles/Pegelwandler#5V_.3C-.3E_3.3V Pegelanpassung], weil die Eingangsleitungen zur SD-Karte nicht 5V tolerant sind. Von einer [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#Bekannte_Fehler Pegelanpassung mit Widerständen] wird abgeraten. Neben den Leitungen, die zur SD-Karte führen, gibt es noch zwei weitere Leitungen, die auf den SD-Karten-Sockel führen: nämlich die card-detect Leitung und die write-protect Leitung. Sie dienen dazu, wie die Namen schon sagen, das physische Vorhandensein einer Karte im SD-Sockel und die Stellung des Schreibschutzschiebers zu signalisieren. The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. Wird Hardware-SPI verwendet, muss nur die chip select Leitung konfiguriert werden. Die card-detect Leitung und die write-protect Leitung sind optional. ifdef(`conf_SD_READER', ` /* port the sd-reader CS is attached to */ pin(SPI_CS_SD_READER, PB2, OUTPUT) /* uncomment and edit this if you have connected the CD (card detect) signal */ pin(SD_READER_AVAILABLE, PD4, INPUT) /* uncomment and edit this if you have connected the WP (write protected) signal */ pin(SD_READER_WR_PROTECT, PD5, INPUT) ') == Konfiguration == | | General Setup ---> | | ... | | [*] VFS (Virtual File System) support ---> | | ... | | [*] SD/MMC-Card Filesystem | | | | I/O ---> | | ... | | [*] SD/MMC-Card Reader ---> | | ... | | [ ] SDHC support | | | | [*] VFAT LFN support | | | | [ ] Read-only mode | | | | [*] Use read-timeout | | | | [*] Ping-read SD card every 10s | | | | --- Debugging Flags | | | | [ ] SD-Reader | | == [[ECMD_(Deutsch)|ECMD]] == == [[Control6_(Deutsch)|Control6]] == 7ec8565b4151bf1fdd22746f20ae95b656f07258 1043 1040 2013-06-04T10:51:51Z GooPie4o 265 /* Anschluss */ wikitext text/x-wiki {{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader] }} Das Modul basiert auf Roland Riegels [http://www.roland-riegel.de/sd-reader/ MMC/SD/SDHC card library] ergänzt um die Anbindung an das Ethersex [[VFS|Virtual File System]]. == Anschluss == MMC- und SD-Speicherkarten lassen sich im [[SPI]]-Modus relativ einfach mit einem Mikrocontroller ansteuern. Prinzipiell gibt es zwischen SD-Card und MMC nicht viele Unterschiede, allerdings sind SD-Karten weiter verbreitet, in der Regel schneller als MMCs, und haben ein besser implementiertes SPI-Interface. Es existieren diverse Varianten (miniSD, microSD), die zur normalen SD-Card weitgehend kompatibel sind. Die Karte liest das anliegende Datenbit mit der steigenden Taktflanke ein, als [[SPI]]-Modi eignen sich somit Mode 0 und Mode 3. Bei MMCs ist der SPI-Modus nicht genau spezifiziert, somit kommt es durchaus mal vor, dass der [[SPI]]-Modus je nach Karte unterschiedlich gewählt werden muss. SD-Karten werden typischerweise mit 3,3V und Microcontroller oft mit 5V betrieben. Das erzwingt eine [http://www.mikrocontroller.net/articles/Pegelwandler#5V_.3C-.3E_3.3V Pegelanpassung], weil die Eingangsleitungen zur SD-Karte nicht 5V tolerant sind. Von einer [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#Bekannte_Fehler Pegelanpassung mit Widerständen] wird abgeraten. Neben den Leitungen, die zur SD-Karte führen, gibt es noch zwei weitere Leitungen, die auf den SD-Karten-Sockel führen: nämlich die card-detect Leitung und die write-protect Leitung. Sie dienen dazu, wie die Namen schon sagen, das physische Vorhandensein einer Karte im SD-Sockel und die Stellung des Schreibschutzschiebers zu signalisieren. Wird Hardware-SPI verwendet, muss nur die chip select Leitung konfiguriert werden. Die card-detect Leitung und die write-protect Leitung sind optional. ifdef(`conf_SD_READER', ` /* port the sd-reader CS is attached to */ pin(SPI_CS_SD_READER, PB2, OUTPUT) /* uncomment and edit this if you have connected the CD (card detect) signal */ pin(SD_READER_AVAILABLE, PD4, INPUT) /* uncomment and edit this if you have connected the WP (write protected) signal */ pin(SD_READER_WR_PROTECT, PD5, INPUT) ') == Konfiguration == | | General Setup ---> | | ... | | [*] VFS (Virtual File System) support ---> | | ... | | [*] SD/MMC-Card Filesystem | | | | I/O ---> | | ... | | [*] SD/MMC-Card Reader ---> | | ... | | [ ] SDHC support | | | | [*] VFAT LFN support | | | | [ ] Read-only mode | | | | [*] Use read-timeout | | | | [*] Ping-read SD card every 10s | | | | --- Debugging Flags | | | | [ ] SD-Reader | | == [[ECMD_(Deutsch)|ECMD]] == == [[Control6_(Deutsch)|Control6]] == 5f29bf97120305916d8623d8437433503bd20540 1044 1043 2013-06-04T10:58:39Z GooPie4o 265 /* Control6 */ wikitext text/x-wiki {{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader] }} Das Modul basiert auf Roland Riegels [http://www.roland-riegel.de/sd-reader/ MMC/SD/SDHC card library] ergänzt um die Anbindung an das Ethersex [[VFS|Virtual File System]]. == Anschluss == MMC- und SD-Speicherkarten lassen sich im [[SPI]]-Modus relativ einfach mit einem Mikrocontroller ansteuern. Prinzipiell gibt es zwischen SD-Card und MMC nicht viele Unterschiede, allerdings sind SD-Karten weiter verbreitet, in der Regel schneller als MMCs, und haben ein besser implementiertes SPI-Interface. Es existieren diverse Varianten (miniSD, microSD), die zur normalen SD-Card weitgehend kompatibel sind. Die Karte liest das anliegende Datenbit mit der steigenden Taktflanke ein, als [[SPI]]-Modi eignen sich somit Mode 0 und Mode 3. Bei MMCs ist der SPI-Modus nicht genau spezifiziert, somit kommt es durchaus mal vor, dass der [[SPI]]-Modus je nach Karte unterschiedlich gewählt werden muss. SD-Karten werden typischerweise mit 3,3V und Microcontroller oft mit 5V betrieben. Das erzwingt eine [http://www.mikrocontroller.net/articles/Pegelwandler#5V_.3C-.3E_3.3V Pegelanpassung], weil die Eingangsleitungen zur SD-Karte nicht 5V tolerant sind. Von einer [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#Bekannte_Fehler Pegelanpassung mit Widerständen] wird abgeraten. Neben den Leitungen, die zur SD-Karte führen, gibt es noch zwei weitere Leitungen, die auf den SD-Karten-Sockel führen: nämlich die card-detect Leitung und die write-protect Leitung. Sie dienen dazu, wie die Namen schon sagen, das physische Vorhandensein einer Karte im SD-Sockel und die Stellung des Schreibschutzschiebers zu signalisieren. Wird Hardware-SPI verwendet, muss nur die chip select Leitung konfiguriert werden. Die card-detect Leitung und die write-protect Leitung sind optional. ifdef(`conf_SD_READER', ` /* port the sd-reader CS is attached to */ pin(SPI_CS_SD_READER, PB2, OUTPUT) /* uncomment and edit this if you have connected the CD (card detect) signal */ pin(SD_READER_AVAILABLE, PD4, INPUT) /* uncomment and edit this if you have connected the WP (write protected) signal */ pin(SD_READER_WR_PROTECT, PD5, INPUT) ') == Konfiguration == | | General Setup ---> | | ... | | [*] VFS (Virtual File System) support ---> | | ... | | [*] SD/MMC-Card Filesystem | | | | I/O ---> | | ... | | [*] SD/MMC-Card Reader ---> | | ... | | [ ] SDHC support | | | | [*] VFAT LFN support | | | | [ ] Read-only mode | | | | [*] Use read-timeout | | | | [*] Ping-read SD card every 10s | | | | --- Debugging Flags | | | | [ ] SD-Reader | | == [[ECMD_(Deutsch)|ECMD]] == == [[Control6_(Deutsch)|Control6]] == Hier vielleicht ein kleines Beispiel, das die Daten per VFS_LOG in die Datei "temp.log" schreibt sobald sich die Temperatur um mehr als ein Grad zur letzten Messung verändert hat. <pre> #include <stdlib.h> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO uint8_t sign = Temperatur<0; div_t res = div(abs(Temperatur),10); VFS_LOG("temp.log", "temperature changed %S%d.%d",sign?PSTR("-"):PSTR(""),res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> c7e5cd858f26f9fc5e3b1a4c9110264a9f7d15a4 1046 1044 2013-06-04T12:36:04Z GooPie4o 265 /* Konfiguration */ wikitext text/x-wiki {{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader] }} Das Modul basiert auf Roland Riegels [http://www.roland-riegel.de/sd-reader/ MMC/SD/SDHC card library] ergänzt um die Anbindung an das Ethersex [[VFS|Virtual File System]]. == Anschluss == MMC- und SD-Speicherkarten lassen sich im [[SPI]]-Modus relativ einfach mit einem Mikrocontroller ansteuern. Prinzipiell gibt es zwischen SD-Card und MMC nicht viele Unterschiede, allerdings sind SD-Karten weiter verbreitet, in der Regel schneller als MMCs, und haben ein besser implementiertes SPI-Interface. Es existieren diverse Varianten (miniSD, microSD), die zur normalen SD-Card weitgehend kompatibel sind. Die Karte liest das anliegende Datenbit mit der steigenden Taktflanke ein, als [[SPI]]-Modi eignen sich somit Mode 0 und Mode 3. Bei MMCs ist der SPI-Modus nicht genau spezifiziert, somit kommt es durchaus mal vor, dass der [[SPI]]-Modus je nach Karte unterschiedlich gewählt werden muss. SD-Karten werden typischerweise mit 3,3V und Microcontroller oft mit 5V betrieben. Das erzwingt eine [http://www.mikrocontroller.net/articles/Pegelwandler#5V_.3C-.3E_3.3V Pegelanpassung], weil die Eingangsleitungen zur SD-Karte nicht 5V tolerant sind. Von einer [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#Bekannte_Fehler Pegelanpassung mit Widerständen] wird abgeraten. Neben den Leitungen, die zur SD-Karte führen, gibt es noch zwei weitere Leitungen, die auf den SD-Karten-Sockel führen: nämlich die card-detect Leitung und die write-protect Leitung. Sie dienen dazu, wie die Namen schon sagen, das physische Vorhandensein einer Karte im SD-Sockel und die Stellung des Schreibschutzschiebers zu signalisieren. Wird Hardware-SPI verwendet, muss nur die chip select Leitung konfiguriert werden. Die card-detect Leitung und die write-protect Leitung sind optional. ifdef(`conf_SD_READER', ` /* port the sd-reader CS is attached to */ pin(SPI_CS_SD_READER, PB2, OUTPUT) /* uncomment and edit this if you have connected the CD (card detect) signal */ pin(SD_READER_AVAILABLE, PD4, INPUT) /* uncomment and edit this if you have connected the WP (write protected) signal */ pin(SD_READER_WR_PROTECT, PD5, INPUT) ') == Konfiguration == | | I/O ---> | | ... | | [*] SD/MMC-Card Reader ---> | | ... | | [ ] SDHC support | | | | [*] VFAT LFN support | | | | [ ] Read-only mode | | | | [*] Use read-timeout | | | | [*] Ping-read SD card every 10s | | | | --- Debugging Flags | | | | [ ] SD-Reader | | | | General Setup ---> | | ... | | [*] VFS (Virtual File System) support ---> | | ... | | [*] SD/MMC-Card Filesystem | | == [[ECMD_(Deutsch)|ECMD]] == == [[Control6_(Deutsch)|Control6]] == Hier vielleicht ein kleines Beispiel, das die Daten per VFS_LOG in die Datei "temp.log" schreibt sobald sich die Temperatur um mehr als ein Grad zur letzten Messung verändert hat. <pre> #include <stdlib.h> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO uint8_t sign = Temperatur<0; div_t res = div(abs(Temperatur),10); VFS_LOG("temp.log", "temperature changed %S%d.%d",sign?PSTR("-"):PSTR(""),res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> 443c69d7f060c08e65e98db29561ffff483076cd 0 360 1031 2013-06-02T16:59:13Z GooPie4o 265 Created page with "{{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=…" wikitext text/x-wiki {{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader] }} == Connection == == Configuration == == [[ECMD|ECMD]] == == [[Control6|Control6]] == 0acde19b6691fb4975acfc49bae3cce361fd73f7 0 338 1035 988 2013-06-04T05:55:24Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{I/O}}->RFM12 ASK->433MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} In ASK mode the RFM12 module ist used to switch radio outlets. Alternatively you can also receive the radio transmission between the transmitter and radio socket outlet. Currently, the following systems are supported: * Self-learning systems (drive "tevion") * Systems based on the chips or PT2262/PT2272 HX2262/2272 (driver "2272") * Concealed remote dimmer with the transmitter located HS1527 chip (driver "1527") * Transmitter type Intertechno ITS-150 * Oase Inscenio FM Master system == Connection == The RFM12 is connected to the AVRlike in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FFIT signal (Pin 4) is connected to one of the INT pins of the AVR. This modul does not work in interrupt mode, so the output nRQ signal (Pin 2) can be left unconnected. The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_ASK_SENSE_USE_INT(0) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_ASK_SENSE_USE_INT defines whether FFIT is connected to INT0, INT1 or INT2 of the AVR. == Configuration == == [[ECMD]] == RFM12 ASK implements an [[ECMD]] interface to control to switch radio outlets. See [[ECMD_Reference|ECMD reference]]. [[Category:RFM12]] 0e46da51172c5934169549d7baec28c922ee37ed 1042 1035 2013-06-04T10:49:51Z GooPie4o 265 /* Configuration */ wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{I/O}}->RFM12 ASK->433MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} In ASK mode the RFM12 module ist used to switch radio outlets. Alternatively you can also receive the radio transmission between the transmitter and radio socket outlet. Currently, the following systems are supported: * Self-learning systems (drive "tevion") * Systems based on the chips or PT2262/PT2272 HX2262/2272 (driver "2272") * Concealed remote dimmer with the transmitter located HS1527 chip (driver "1527") * Transmitter type Intertechno ITS-150 * Oase Inscenio FM Master system == Connection == The RFM12 is connected to the AVRlike in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FFIT signal (Pin 4) is connected to one of the INT pins of the AVR. This modul does not work in interrupt mode, so the output nRQ signal (Pin 2) can be left unconnected. The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_ASK_SENSE_USE_INT(0) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_ASK_SENSE_USE_INT defines whether FFIT is connected to INT0, INT1 or INT2 of the AVR. == Configuration == | | I/O ---> | | ... | | [*] RFM12 ASK ---> | | ... | | [*] 433MHz | | | | (0) RFM12 select | | | | [ ] Pollin/Kangtai Powerswitch (IC 2272) | | | | [ ] Pollin Powerswitch buried (IC 1527) | | | | [*] Tevion Powerswitch | | | | [ ] Intertechno ITS-150 | | | | [*] Oase FM Master | | | | [ ] External filter | | | | [-] Sensing | | == [[ECMD]] == RFM12 ASK implements an [[ECMD]] interface to control to switch radio outlets. See [[ECMD_Reference|ECMD reference]]. [[Category:RFM12]] bab459ad9a550427b29700372b9c52b5050af824 0 340 1041 993 2013-06-04T10:48:03Z GooPie4o 265 /* Configuration */ wikitext text/x-wiki {{i18n|RFM12 FSK}} {{Module |NAME=RFM12 FSK |MENUCONFIG=Network->IP over RFM12 (FSK transmitter) support |STATUS={{Stable}} |PINNING=yes |ECMD=no |CONTROL6=no |DEPENDS= |REQUIRES=UIP_SUPPORT |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} The default operating mode of the RFM12 is FSK. This mode is used to treat several Ethersex systems connect by radio with each other. Here, one of the systems can act as a router to connect to a wired network. == Connection == If you are using hardware SPI, which is the default, connect the RFM12 to the AVR as follows: [[Image:Rfm12 connection.png|640px]] The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_USE_INT(2) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_USE_INT defines whether nRQ is connected to INT0, INT1 or INT2 of the AVR. == Configuration == | | Network ---> | | ... | | [*] IP over RFM12 (FSK transmitter) support ---> | | ... | | (0) RFM12 select | | | | (433.920MHz) RFM12 frequency | | | | [ ] Use slow SPI | | | | [ ] Use RFM12B | | | | (19200) RFM12 Baudrate | | | | IP address: "192.168.5.1" | | | | Netmask: "255.255.255.0" | | | | [ ] Source Route ALL packets | | | | [ ] RFM12 Packet Forwarding | | | | [-] RFM12 ARP-Proxy | | [[Category:RFM12]] 16009e900c9eb754c83249164ec7bacf18fc28e4 0 153 1045 367 2013-06-04T11:33:13Z GooPie4o 265 Übernahme aus dem alten Wiki wikitext text/x-wiki {{i18n|Clock}} {{Module |NAME=Clock |MENUCONFIG={{Applications}}->System clock support |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] (optional) |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/services/clock https://github.com/ethersex/ethersex/tree/master/services/clock] }} Viele Mikrocontroller-Projekte kommen irgendwann an den Punkt, wo eine (halbwegs) verlässliche Zeitquelle von Nöten ist. Sei es, dass man um eine bestimmte Uhrzeit eine Lampe schalten möchte, die Heizungssteuerung morgens für Warmwasser sorgen soll oder dass man alle halbe Stunde einen Messwert speichert ... Wie könnte es anders sein, Ethersex bietet hierfür eine elegante Lösung: eine Systemuhr :-) <pre> make menuconfig Applications ---&gt; System clock ---&gt; | | [*] System clock support | | | [ ] Use 32 kHz crystal to tick the clock | | | [*] Synchronize using NTP protocol | | | [*] Cron daemon | | | [ ] NTP daemon | | | [ ] Working hour meter | | | (UTC) Time Zone | | </pre> == Der Uhrentakt == Wenn irgendwie möglich, solltest Du Deinem Ethersex einen Uhrenquarz mit einer Taktfrequenz von 32 kHz spendieren (an die Pins TOSC1 resp. TOSC2 anschließen, im Falle des ATmega644 sind das PC6 und PC7) und die Option ''Use 32 kHz crystal to tick the clock'' aktivieren. Die Systemuhr läuft mit dem Uhrenquarz erheblich genauer. Ohne den Quarz wird der Systemtakt als Quelle herangezogen. Dieser ist aber im Vergleich weit weniger genau. == Zeitquellen == Selbstverständlich muss sich die Uhr selbst stellen. Der Controller wäre weitestgehend nutzlos wenn jedesmal die Uhr per Hand eingestellt werden müsste. Ethersex sieht hierzu im Moment zwei Lösungsansätze vor: === Synchronisation mittels NTP === Ethersex kann als NTP-Client einen Zeitserver im Internet nach der Uhrzeit fragen. Hierzu ist lediglich die Option ''Applications → System Clock Support → Synchronize using NTP protocol'' zu aktivieren. Die Firmware frägt dann nach dem Boot und anschließend in regelmäßigen Abständen den Zeitserver. Die standardmäßig festgelegten Server sind in der Datei [https://github.com/ethersex/ethersex/blob/master/services/clock/config.in services/clock/config.in] gesetzt (können aber per <code>menuconfig</code> verändert werden): {| border="1" | ''address type'' | ''DNS aktiviert'' | ''ohne DNS Unterstützung'' |- | IPv6 | ns.ipv6.uni-leipzig.de | 2001:638:902:1:0:0:0:10 |- | IPv4 | ptbtime1.ptb.de | 192.53.103.108 |- |} === [[DCF77]] === Die Ethersex-Firmware kann auch als [[DCF77|DCF77-Empfänger]] (besser bekannt als &quot;Funkuhr&quot;) fungieren. Hierzu ist zunächst ein Uhrenquarz anzuschließen und die zugehörige Option zu aktivieren, vgl. oben. Dann muss die Option ''Synchronize using DCF77 signal'' aktiviert werden. Funktionstüchtige (Empfangs-)hardware und guten Empfang vorausgesetzt, sollte die Uhr nun automatisch gestellt werden. == Zeitinformationen verwenden == === Cron === Ethersex hat einen Cron-Dienst ähnlich dem Dienst auf typischen Unix-Systemen. Dieser kann verwendet werden, um zu bestimmten Uhrzeiten bestimmte Tätigkeiten verrichten zu lassen. Die Jobtabelle selbst findet sich in der Datei ''cron/cron.c'' ziemlich am Anfang. Es ist auch ein Beispieljob eingetragen. Selbstverständlich sind hierzu dann zumindest rudimentäre Programmierkenntnisse in C erforderlich %) Eine (einfachere) Alternative wäre evtl. der Einsatz eines [[Control6]]-Programms. === NTP-Server === Die Ethersex Firmware kann die so gewonnenen Zeitinformationen als NTP-Server auch im lokalen Netzwerk zur Verfügung stellen. Hierzu ist lediglich die Option ''NTP daemon'' zu aktivieren. [[Category:Ethersex]] [[Category:StepByStep]] [[Category:Clock]] [[Category:Network]] c3877ab7db6f8c8a1f810dd11faaaeb7375261db 0 31 1048 83 2013-06-05T08:55:11Z GooPie4o 265 wikitext text/x-wiki {{i18n|RC5}} {{Module |NAME=RC5 |STATUS={{deprecated}} |MENUCONFIG={{I/O}}->IR Receivers->RC5 |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |PINNING=yes |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] |REQUIRES= - |TIMER={{occupies_timer|0}} (RX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/rc5 https://github.com/ethersex/ethersex/tree/master/hardware/ir/rc5] }} RC5 ist ein von Philips entwickelter Code für Infrarot-Fernbedienungen. Ein [[Ethersex_(Deutsch)|Ethersex]]-System kann RC5-Signale sowohl empfangen und dekodieren als auch senden. Das Modul wird nicht länger gepflegt. Bitte [[IRMP_(Deutsch)|IRMP]] stattdessen verwenden. == RC5 == ine Nachricht im RC5 Code besteht aus 14 bits, die auf ein Trägersignal moduliert werden. +--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |S1|S2|T |A5|A4|A3|A2|A1|C6|C5|C4|C3|C2|C1| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | | | |<-Kopf->|<- Adresse ->|<- Befehl ->| Dabei sind S1 und S2 die Startbits, sie sind immer "1". T ist ein Toggle-Bit, das anzeigt, ob eine Taste der Fernbedienung gerade gedrückt wurde oder gedrückt gehalten wurde. Es folgt die 5 bit lange Adresse des Geräts und ein 6 bit langer Befehl. Sowohl für Adressen als auch für Befehle existieren vorgegebene Tabellen. == Verbindung == Der Empfang der IR-Signale erfolgt durch einen Empfänger vom Typ TSOP1736 (oder ähnlich). Dieser muss an einem INT-Eingang angeschlossen werden. Die Modulation des Senders übernimmt ein NE555, dessen Reset-Pin vom AVR angesteuert wird. Beim [[Etherrape]] ist der Empfänger an PD2/INT0 angeschlossen. Zum Senden ist der Reset-Pin des NE555 an PD4 vom [[Etherrape]] angeschlossen. ifdef(`conf_RC5', ` pin(RC5_SEND, PD4) RC5_USE_INT(0) #undef RC5_USE_TIMER2 ') == Konfiguration == == [[ECMD_(Deutsch)|ECMD]] == RC5 implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle zum Auslesen empfangener und dekodierter IR-Kommandos und zum Senden von IR-Kommandos. Siehe [[ECMD_Reference|ECMD Referenz]]. 1b5775b0f75eb97715a640ab6663a9abacef8570 1049 1048 2013-06-05T08:56:47Z GooPie4o 265 wikitext text/x-wiki {{i18n|RC5}} {{Module |NAME=RC5 |STATUS={{deprecated}} |MENUCONFIG={{I/O}}->IR Receivers->RC5 |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |PINNING=yes |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] |REQUIRES= - |TIMER={{occupies_timer|0}} (RX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/rc5 https://github.com/ethersex/ethersex/tree/master/hardware/ir/rc5] }} RC5 ist ein von Philips entwickelter Code für Infrarot-Fernbedienungen. Ein [[Ethersex_(Deutsch)|Ethersex]]-System kann RC5-Signale sowohl empfangen und dekodieren als auch senden. Das Modul wird nicht länger gepflegt. Bitte [[IRMP_(Deutsch)|IRMP]] stattdessen verwenden. == RC5 == ine Nachricht im RC5 Code besteht aus 14 bits, die auf ein Trägersignal moduliert werden. +--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |S1|S2|T |A5|A4|A3|A2|A1|C6|C5|C4|C3|C2|C1| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | | | |<-Kopf->|<- Adresse ->|<- Befehl ->| Dabei sind S1 und S2 die Startbits, sie sind immer "1". T ist ein Toggle-Bit, das anzeigt, ob eine Taste der Fernbedienung gerade gedrückt wurde oder gedrückt gehalten wurde. Es folgt die 5 bit lange Adresse des Geräts und ein 6 bit langer Befehl. Sowohl für Adressen als auch für Befehle existieren vorgegebene Tabellen. == Verbindung == Der Empfang der IR-Signale erfolgt durch einen Empfänger vom Typ TSOP1736 (oder ähnlich). Dieser muss an einem INT-Eingang angeschlossen werden. Die Modulation des Senders übernimmt ein NE555, dessen Reset-Pin vom AVR angesteuert wird. Beim [[Etherrape]] ist der Empfänger an PD2/INT0 angeschlossen. Zum Senden ist der Reset-Pin des NE555 an PD4 vom [[Etherrape]] angeschlossen. ifdef(`conf_RC5', ` pin(RC5_SEND, PD4) RC5_USE_INT(0) #undef RC5_USE_TIMER2 ') == Konfiguration == == [[ECMD_(Deutsch)|ECMD]] == RC5 implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle zum Auslesen empfangener und dekodierter IR-Kommandos und zum Senden von IR-Kommandos. Siehe [[ECMD_Reference|ECMD Referenz]]. == Links == [http://www.sbprojects.com/knowledge/ir/index.php Übersicht IR-Protkolle] fc64e3be6933c189b30bbd5ccb2d759a1cbd9c43 1050 1049 2013-06-05T08:58:49Z GooPie4o 265 /* Konfiguration */ wikitext text/x-wiki {{i18n|RC5}} {{Module |NAME=RC5 |STATUS={{deprecated}} |MENUCONFIG={{I/O}}->IR Receivers->RC5 |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |PINNING=yes |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] |REQUIRES= - |TIMER={{occupies_timer|0}} (RX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/rc5 https://github.com/ethersex/ethersex/tree/master/hardware/ir/rc5] }} RC5 ist ein von Philips entwickelter Code für Infrarot-Fernbedienungen. Ein [[Ethersex_(Deutsch)|Ethersex]]-System kann RC5-Signale sowohl empfangen und dekodieren als auch senden. Das Modul wird nicht länger gepflegt. Bitte [[IRMP_(Deutsch)|IRMP]] stattdessen verwenden. == RC5 == ine Nachricht im RC5 Code besteht aus 14 bits, die auf ein Trägersignal moduliert werden. +--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |S1|S2|T |A5|A4|A3|A2|A1|C6|C5|C4|C3|C2|C1| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | | | |<-Kopf->|<- Adresse ->|<- Befehl ->| Dabei sind S1 und S2 die Startbits, sie sind immer "1". T ist ein Toggle-Bit, das anzeigt, ob eine Taste der Fernbedienung gerade gedrückt wurde oder gedrückt gehalten wurde. Es folgt die 5 bit lange Adresse des Geräts und ein 6 bit langer Befehl. Sowohl für Adressen als auch für Befehle existieren vorgegebene Tabellen. == Verbindung == Der Empfang der IR-Signale erfolgt durch einen Empfänger vom Typ TSOP1736 (oder ähnlich). Dieser muss an einem INT-Eingang angeschlossen werden. Die Modulation des Senders übernimmt ein NE555, dessen Reset-Pin vom AVR angesteuert wird. Beim [[Etherrape]] ist der Empfänger an PD2/INT0 angeschlossen. Zum Senden ist der Reset-Pin des NE555 an PD4 vom [[Etherrape]] angeschlossen. ifdef(`conf_RC5', ` pin(RC5_SEND, PD4) RC5_USE_INT(0) #undef RC5_USE_TIMER2 ') == Konfiguration == | | I/O ---> | | ... | | [*] IR Receivers ---> | | ... | | [*] RC5 IR (deprecated) ---> | | ... | | [*] Send RC5 IR-codes | | | | [-] RC5 IR UDP ---> | | | | --- Debugging Flags | | | | [ ] RC5 | | == [[ECMD_(Deutsch)|ECMD]] == RC5 implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle zum Auslesen empfangener und dekodierter IR-Kommandos und zum Senden von IR-Kommandos. Siehe [[ECMD_Reference|ECMD Referenz]]. == Links == [http://www.sbprojects.com/knowledge/ir/index.php Übersicht IR-Protkolle] 26299ca2b9f1a90e5caa7216fa067b55cb086dda 6 361 1051 2013-06-05T18:14:07Z GooPie4o 265 SD-Card Adapter mit 74HC4050 Pegelwandler wikitext text/x-wiki SD-Card Adapter mit 74HC4050 Pegelwandler e101ccd6a900f887b438d8b8829a5da195c68624 6 362 1052 2013-06-05T18:16:46Z GooPie4o 265 Schaltung zu SD-Card Adapter mit 74HC450 Pegelwandler wikitext text/x-wiki Schaltung zu SD-Card Adapter mit 74HC450 Pegelwandler 928ee342476953ec3d95fce65dc1bbe362e61af9 0 359 1053 1046 2013-06-05T18:19:22Z GooPie4o 265 /* Anschluss */ wikitext text/x-wiki {{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader] }} Das Modul basiert auf Roland Riegels [http://www.roland-riegel.de/sd-reader/ MMC/SD/SDHC card library] ergänzt um die Anbindung an das Ethersex [[VFS|Virtual File System]]. == Anschluss == [[File:Sdcard adapter schaltung.png|200px|thumb|right|SD-Card Adapter Schaltung]] [[File:Sdcard adapter.jpg|200px|thumb|right|SD-Card Adapter Aufbau]] MMC- und SD-Speicherkarten lassen sich im [[SPI]]-Modus relativ einfach mit einem Mikrocontroller ansteuern. Prinzipiell gibt es zwischen SD-Card und MMC nicht viele Unterschiede, allerdings sind SD-Karten weiter verbreitet, in der Regel schneller als MMCs, und haben ein besser implementiertes SPI-Interface. Es existieren diverse Varianten (miniSD, microSD), die zur normalen SD-Card weitgehend kompatibel sind. Die Karte liest das anliegende Datenbit mit der steigenden Taktflanke ein, als [[SPI]]-Modi eignen sich somit Mode 0 und Mode 3. Bei MMCs ist der SPI-Modus nicht genau spezifiziert, somit kommt es durchaus mal vor, dass der [[SPI]]-Modus je nach Karte unterschiedlich gewählt werden muss. SD-Karten werden typischerweise mit 3,3V und Microcontroller oft mit 5V betrieben. Das erzwingt eine [http://www.mikrocontroller.net/articles/Pegelwandler#5V_.3C-.3E_3.3V Pegelanpassung], weil die Eingangsleitungen zur SD-Karte nicht 5V tolerant sind. Von einer [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#Bekannte_Fehler Pegelanpassung mit Widerständen] wird abgeraten. Neben den Leitungen, die zur SD-Karte führen, gibt es noch zwei weitere Leitungen, die auf den SD-Karten-Sockel führen: nämlich die card-detect Leitung und die write-protect Leitung. Sie dienen dazu, wie die Namen schon sagen, das physische Vorhandensein einer Karte im SD-Sockel und die Stellung des Schreibschutzschiebers zu signalisieren. Wird Hardware-SPI verwendet, muss nur die chip select Leitung konfiguriert werden. Die card-detect Leitung und die write-protect Leitung sind optional. ifdef(`conf_SD_READER', ` /* port the sd-reader CS is attached to */ pin(SPI_CS_SD_READER, PB2, OUTPUT) /* uncomment and edit this if you have connected the CD (card detect) signal */ pin(SD_READER_AVAILABLE, PD4, INPUT) /* uncomment and edit this if you have connected the WP (write protected) signal */ pin(SD_READER_WR_PROTECT, PD5, INPUT) ') == Konfiguration == | | I/O ---> | | ... | | [*] SD/MMC-Card Reader ---> | | ... | | [ ] SDHC support | | | | [*] VFAT LFN support | | | | [ ] Read-only mode | | | | [*] Use read-timeout | | | | [*] Ping-read SD card every 10s | | | | --- Debugging Flags | | | | [ ] SD-Reader | | | | General Setup ---> | | ... | | [*] VFS (Virtual File System) support ---> | | ... | | [*] SD/MMC-Card Filesystem | | == [[ECMD_(Deutsch)|ECMD]] == == [[Control6_(Deutsch)|Control6]] == Hier vielleicht ein kleines Beispiel, das die Daten per VFS_LOG in die Datei "temp.log" schreibt sobald sich die Temperatur um mehr als ein Grad zur letzten Messung verändert hat. <pre> #include <stdlib.h> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO uint8_t sign = Temperatur<0; div_t res = div(abs(Temperatur),10); VFS_LOG("temp.log", "temperature changed %S%d.%d",sign?PSTR("-"):PSTR(""),res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> c2a938eaa820fba9145701d66355c728f28ea0a7 1054 1053 2013-06-06T12:12:40Z GooPie4o 265 wikitext text/x-wiki {{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS= |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader] }} Das Modul basiert auf Roland Riegels [http://www.roland-riegel.de/sd-reader/ MMC/SD/SDHC card library] ergänzt um die Anbindung an das Ethersex [[VFS|Virtual File System]]. == Anschluss == [[File:Sdcard adapter schaltung.png|200px|thumb|right|SD-Card Adapter Schaltung]] [[File:Sdcard adapter.jpg|200px|thumb|right|SD-Card Adapter Aufbau]] MMC- und SD-Speicherkarten lassen sich im [[SPI]]-Modus relativ einfach mit einem Mikrocontroller ansteuern. Prinzipiell gibt es zwischen SD-Card und MMC nicht viele Unterschiede, allerdings sind SD-Karten weiter verbreitet, in der Regel schneller als MMCs, und haben ein besser implementiertes SPI-Interface. Es existieren diverse Varianten (miniSD, microSD), die zur normalen SD-Card weitgehend kompatibel sind. Die Karte liest das anliegende Datenbit mit der steigenden Taktflanke ein, als [[SPI]]-Modi eignen sich somit Mode 0 und Mode 3. Bei MMCs ist der SPI-Modus nicht genau spezifiziert, somit kommt es durchaus mal vor, dass der [[SPI]]-Modus je nach Karte unterschiedlich gewählt werden muss. SD-Karten werden typischerweise mit 3,3V und Microcontroller oft mit 5V betrieben. Das erzwingt eine [http://www.mikrocontroller.net/articles/Pegelwandler#5V_.3C-.3E_3.3V Pegelanpassung], weil die Eingangsleitungen zur SD-Karte nicht 5V tolerant sind. Von einer [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#Bekannte_Fehler Pegelanpassung mit Widerständen] wird abgeraten. Neben den Leitungen, die zur SD-Karte führen, gibt es noch zwei weitere Leitungen, die auf den SD-Karten-Sockel führen: nämlich die card-detect Leitung und die write-protect Leitung. Sie dienen dazu, wie die Namen schon sagen, das physische Vorhandensein einer Karte im SD-Sockel und die Stellung des Schreibschutzschiebers zu signalisieren. Wird Hardware-SPI verwendet, muss nur die chip select Leitung konfiguriert werden. Die card-detect Leitung und die write-protect Leitung sind optional. ifdef(`conf_SD_READER', ` /* port the sd-reader CS is attached to */ pin(SPI_CS_SD_READER, PB2, OUTPUT) /* uncomment and edit this if you have connected the CD (card detect) signal */ pin(SD_READER_AVAILABLE, PD4, INPUT) /* uncomment and edit this if you have connected the WP (write protected) signal */ pin(SD_READER_WR_PROTECT, PD5, INPUT) ') == Konfiguration == | | I/O ---> | | ... | | [*] SD/MMC-Card Reader ---> | | ... | | [ ] SDHC support | | | | [*] VFAT LFN support | | | | [ ] Read-only mode | | | | [*] Use read-timeout | | | | [*] Ping-read SD card every 10s | | | | --- Debugging Flags | | | | [ ] SD-Reader | | | | General Setup ---> | | ... | | [*] VFS (Virtual File System) support ---> | | ... | | [*] SD/MMC-Card Filesystem | | == [[ECMD_(Deutsch)|ECMD]] == == [[Control6_(Deutsch)|Control6]] == Hier vielleicht ein kleines Beispiel, das die Daten per VFS_LOG in die Datei "temp.log" schreibt sobald sich die Temperatur um mehr als ein Grad zur letzten Messung verändert hat. <pre> #include <stdlib.h> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO uint8_t sign = Temperatur<0; div_t res = div(abs(Temperatur),10); VFS_LOG("temp.log", "temperature changed %S%d.%d",sign?PSTR("-"):PSTR(""),res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> 2fb1b18d1cf17d34cee86982fbcd98a509f2f51c 1055 1054 2013-06-06T12:18:47Z GooPie4o 265 /* Control6 */ wikitext text/x-wiki {{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS= |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader] }} Das Modul basiert auf Roland Riegels [http://www.roland-riegel.de/sd-reader/ MMC/SD/SDHC card library] ergänzt um die Anbindung an das Ethersex [[VFS|Virtual File System]]. == Anschluss == [[File:Sdcard adapter schaltung.png|200px|thumb|right|SD-Card Adapter Schaltung]] [[File:Sdcard adapter.jpg|200px|thumb|right|SD-Card Adapter Aufbau]] MMC- und SD-Speicherkarten lassen sich im [[SPI]]-Modus relativ einfach mit einem Mikrocontroller ansteuern. Prinzipiell gibt es zwischen SD-Card und MMC nicht viele Unterschiede, allerdings sind SD-Karten weiter verbreitet, in der Regel schneller als MMCs, und haben ein besser implementiertes SPI-Interface. Es existieren diverse Varianten (miniSD, microSD), die zur normalen SD-Card weitgehend kompatibel sind. Die Karte liest das anliegende Datenbit mit der steigenden Taktflanke ein, als [[SPI]]-Modi eignen sich somit Mode 0 und Mode 3. Bei MMCs ist der SPI-Modus nicht genau spezifiziert, somit kommt es durchaus mal vor, dass der [[SPI]]-Modus je nach Karte unterschiedlich gewählt werden muss. SD-Karten werden typischerweise mit 3,3V und Microcontroller oft mit 5V betrieben. Das erzwingt eine [http://www.mikrocontroller.net/articles/Pegelwandler#5V_.3C-.3E_3.3V Pegelanpassung], weil die Eingangsleitungen zur SD-Karte nicht 5V tolerant sind. Von einer [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#Bekannte_Fehler Pegelanpassung mit Widerständen] wird abgeraten. Neben den Leitungen, die zur SD-Karte führen, gibt es noch zwei weitere Leitungen, die auf den SD-Karten-Sockel führen: nämlich die card-detect Leitung und die write-protect Leitung. Sie dienen dazu, wie die Namen schon sagen, das physische Vorhandensein einer Karte im SD-Sockel und die Stellung des Schreibschutzschiebers zu signalisieren. Wird Hardware-SPI verwendet, muss nur die chip select Leitung konfiguriert werden. Die card-detect Leitung und die write-protect Leitung sind optional. ifdef(`conf_SD_READER', ` /* port the sd-reader CS is attached to */ pin(SPI_CS_SD_READER, PB2, OUTPUT) /* uncomment and edit this if you have connected the CD (card detect) signal */ pin(SD_READER_AVAILABLE, PD4, INPUT) /* uncomment and edit this if you have connected the WP (write protected) signal */ pin(SD_READER_WR_PROTECT, PD5, INPUT) ') == Konfiguration == | | I/O ---> | | ... | | [*] SD/MMC-Card Reader ---> | | ... | | [ ] SDHC support | | | | [*] VFAT LFN support | | | | [ ] Read-only mode | | | | [*] Use read-timeout | | | | [*] Ping-read SD card every 10s | | | | --- Debugging Flags | | | | [ ] SD-Reader | | | | General Setup ---> | | ... | | [*] VFS (Virtual File System) support ---> | | ... | | [*] SD/MMC-Card Filesystem | | == [[ECMD_(Deutsch)|ECMD]] == == [[Control6_(Deutsch)|Control6]] == Das folgende Beispiel scrheibt Datum, Uhrzeit und Temperatur per VFS_LOG in die Datei "temp.log" schreibt sobald sich die Temperatur um mehr als ein Grad zur letzten Messung verändert hat. Für Datum und Uhrzeit muss CLOCK_SUPPORT aktiviert sein. <pre> #include <stdlib.h> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO uint8_t sign = Temperatur<0; div_t res = div(abs(Temperatur),10); VFS_LOG("temp.log", "%2d.%2d%2d %2d:%02d %S%d.%d", CLOCK_DAY, CLOCK_MONTH, CLOCK_YEAR, CLOCK_HOUR, CLOCK_MIN, CLOCK_SEC, sign?PSTR("-"):PSTR(""),res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> 30793732abe15498f6808ee64c5ee7f85271e83e 1056 1055 2013-06-06T12:25:40Z GooPie4o 265 wikitext text/x-wiki {{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS= |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader] }} Das Modul basiert auf Roland Riegels [http://www.roland-riegel.de/sd-reader/ MMC/SD/SDHC card library] ergänzt um die Anbindung an das Ethersex [[VFS|Virtual File System]]. == Anschluss == [[File:Sdcard adapter schaltung.png|200px|thumb|right|SD-Card Adapter Schaltung]] [[File:Sdcard adapter.jpg|200px|thumb|right|SD-Card Adapter Aufbau]] MMC- und SD-Speicherkarten lassen sich im [[SPI]]-Modus relativ einfach mit einem Mikrocontroller ansteuern. Prinzipiell gibt es zwischen SD-Card und MMC nicht viele Unterschiede, allerdings sind SD-Karten weiter verbreitet, in der Regel schneller als MMCs, und haben ein besser implementiertes SPI-Interface. Es existieren diverse Varianten (miniSD, microSD), die zur normalen SD-Card weitgehend kompatibel sind. Die Karte liest das anliegende Datenbit mit der steigenden Taktflanke ein, als [[SPI]]-Modi eignen sich somit Mode 0 und Mode 3. Bei MMCs ist der SPI-Modus nicht genau spezifiziert, somit kommt es durchaus mal vor, dass der [[SPI]]-Modus je nach Karte unterschiedlich gewählt werden muss. SD-Karten werden typischerweise mit 3,3V und Microcontroller oft mit 5V betrieben. Das erzwingt eine [http://www.mikrocontroller.net/articles/Pegelwandler#5V_.3C-.3E_3.3V Pegelanpassung], weil die Eingangsleitungen zur SD-Karte nicht 5V tolerant sind. Von einer [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#Bekannte_Fehler Pegelanpassung mit Widerständen] wird abgeraten. Neben den Leitungen, die zur SD-Karte führen, gibt es noch zwei weitere Leitungen, die auf den SD-Karten-Sockel führen: nämlich die card-detect Leitung und die write-protect Leitung. Sie dienen dazu, wie die Namen schon sagen, das physische Vorhandensein einer Karte im SD-Sockel und die Stellung des Schreibschutzschiebers zu signalisieren. Wird Hardware-SPI verwendet, muss nur die chip select Leitung konfiguriert werden. Die card-detect Leitung und die write-protect Leitung sind optional. ifdef(`conf_SD_READER', ` /* port the sd-reader CS is attached to */ pin(SPI_CS_SD_READER, PB2, OUTPUT) /* uncomment and edit this if you have connected the CD (card detect) signal */ pin(SD_READER_AVAILABLE, PD4, INPUT) /* uncomment and edit this if you have connected the WP (write protected) signal */ pin(SD_READER_WR_PROTECT, PD5, INPUT) ') Ein weiteres Problem bei den SD Karten ist die Initialisierung. Schafft es Ethersex nicht in einer bestimmten Zeit zu syncen, so fällt die Karte in den normalen (nicht den SD) Betriebsmodus und kann nicht mehr angesprochen werden. Eine Lösung dafür ist, dass der Karte eine steuerbare Stromversorgung erhält. Dazu definiert man im Pinning nur den Pin pin(SD_READER_POWERON, PB3, OUTPUT) == Konfiguration == | | I/O ---> | | ... | | [*] SD/MMC-Card Reader ---> | | ... | | [ ] SDHC support | | | | [*] VFAT LFN support | | | | [ ] Read-only mode | | | | [*] Use read-timeout | | | | [*] Ping-read SD card every 10s | | | | --- Debugging Flags | | | | [ ] SD-Reader | | | | General Setup ---> | | ... | | [*] VFS (Virtual File System) support ---> | | ... | | [*] SD/MMC-Card Filesystem | | == [[ECMD_(Deutsch)|ECMD]] == == [[Control6_(Deutsch)|Control6]] == Das folgende Beispiel scrheibt Datum, Uhrzeit und Temperatur per VFS_LOG in die Datei "temp.log" schreibt sobald sich die Temperatur um mehr als ein Grad zur letzten Messung verändert hat. Für Datum und Uhrzeit muss CLOCK_SUPPORT aktiviert sein. <pre> #include <stdlib.h> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO uint8_t sign = Temperatur<0; div_t res = div(abs(Temperatur),10); VFS_LOG("temp.log", "%2d.%2d%2d %2d:%02d %S%d.%d", CLOCK_DAY, CLOCK_MONTH, CLOCK_YEAR, CLOCK_HOUR, CLOCK_MIN, CLOCK_SEC, sign?PSTR("-"):PSTR(""),res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> 98c94beac98d0fd1d4de8c5ea6c1ee0ef5fe19bf 1057 1056 2013-06-06T12:31:47Z GooPie4o 265 /* Anschluss */ wikitext text/x-wiki {{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS= |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader] }} Das Modul basiert auf Roland Riegels [http://www.roland-riegel.de/sd-reader/ MMC/SD/SDHC card library] ergänzt um die Anbindung an das Ethersex [[VFS|Virtual File System]]. == Anschluss == [[File:Sdcard adapter schaltung.png|200px|thumb|right|SD-Card Adapter Schaltung]] [[File:Sdcard adapter.jpg|200px|thumb|right|SD-Card Adapter Aufbau]] MMC- und SD-Speicherkarten lassen sich im [[SPI]]-Modus relativ einfach mit einem Mikrocontroller ansteuern. Prinzipiell gibt es zwischen SD-Card und MMC nicht viele Unterschiede, allerdings sind SD-Karten weiter verbreitet, in der Regel schneller als MMCs, und haben ein besser implementiertes SPI-Interface. Es existieren diverse Varianten (miniSD, microSD), die zur normalen SD-Card weitgehend kompatibel sind. Die Karte liest das anliegende Datenbit mit der steigenden Taktflanke ein, als [[SPI]]-Modi eignen sich somit Mode 0 und Mode 3. Bei MMCs ist der SPI-Modus nicht genau spezifiziert, somit kommt es durchaus mal vor, dass der [[SPI]]-Modus je nach Karte unterschiedlich gewählt werden muss. SD-Karten werden typischerweise mit 3,3V und Microcontroller oft mit 5V betrieben. Das erzwingt eine [http://www.mikrocontroller.net/articles/Pegelwandler#5V_.3C-.3E_3.3V Pegelanpassung], weil die Eingangsleitungen zur SD-Karte nicht 5V tolerant sind. Von einer [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#Bekannte_Fehler Pegelanpassung mit Widerständen] wird abgeraten. Neben den Leitungen, die zur SD-Karte führen, gibt es noch zwei weitere Leitungen, die auf den SD-Karten-Sockel führen: nämlich die card-detect Leitung und die write-protect Leitung. Sie dienen dazu, wie die Namen schon sagen, das physische Vorhandensein einer Karte im SD-Sockel und die Stellung des Schreibschutzschiebers zu signalisieren. Wird Hardware-SPI verwendet, muss nur die chip select Leitung konfiguriert werden. Die card-detect Leitung und die write-protect Leitung sind optional. ifdef(`conf_SD_READER', ` /* port the sd-reader CS is attached to */ pin(SPI_CS_SD_READER, PB2, OUTPUT) /* uncomment and edit this if you have connected the CD (card detect) signal */ pin(SD_READER_AVAILABLE, PD4, INPUT) /* uncomment and edit this if you have connected the WP (write protected) signal */ pin(SD_READER_WR_PROTECT, PD5, INPUT) ') Ein weiteres Problem bei den SD Karten ist die Initialisierung. Schafft es Ethersex nicht in einer bestimmten Zeit zu syncen, so fällt die Karte in den normalen (nicht den SD) Betriebsmodus und kann nicht mehr angesprochen werden. Eine Lösung dafür ist, dass der Karte eine steuerbare Stromversorgung erhält. Dazu definiert man im Pinning nur den Pin pin(SD_READER_POWERON, PB3, OUTPUT) ==== Sockel ==== Eine günstige Art der Kontaktierung ist wohl das Ausschlachten eines billigen Cardreaders, wenn man keine Kabel direkt an die Karte löten möchte. Einzeln gekaufte Steckverbinder sind meist erheblich teuerer.Man kann auch alte [http://uanr.com/sdfloppy/ Floppy-Kabel als günstigen Steckverbinder] benutzen. Teile von AT-Slots oder Verbinder von 5,25-Zoll-Floppys gehen auch. Notfalls kann man die Karte zwischen 2 Reihen Stiftleiste einklemmen (oder anlöten). Noch günstiger geht's wenn man Mikro- oder Mini-SD-Karten benutzt und den meist beigelegten Adapter anlötet. Wer jedoch auf einen Selbstbau verzichten will, kann alternativ für relativ schmales Geld einen [http://www.shop.display3000.com/wichtiges-zubehoer/experimentierplatinen/sd-speicherkartenplatine.html fertig aufgebauten SD-Adapter] zum Anschließen an den AVR käulich erwerben. Bei diesem Adapter ist bereits eine bidirektionale Pegelanpassung zwischen den 5V-Pegeln der Steuerleitungen des AVR und den 3,3V-Pegel der SD-Karte an Bord. == Konfiguration == | | I/O ---> | | ... | | [*] SD/MMC-Card Reader ---> | | ... | | [ ] SDHC support | | | | [*] VFAT LFN support | | | | [ ] Read-only mode | | | | [*] Use read-timeout | | | | [*] Ping-read SD card every 10s | | | | --- Debugging Flags | | | | [ ] SD-Reader | | | | General Setup ---> | | ... | | [*] VFS (Virtual File System) support ---> | | ... | | [*] SD/MMC-Card Filesystem | | == [[ECMD_(Deutsch)|ECMD]] == == [[Control6_(Deutsch)|Control6]] == Das folgende Beispiel scrheibt Datum, Uhrzeit und Temperatur per VFS_LOG in die Datei "temp.log" schreibt sobald sich die Temperatur um mehr als ein Grad zur letzten Messung verändert hat. Für Datum und Uhrzeit muss CLOCK_SUPPORT aktiviert sein. <pre> #include <stdlib.h> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO uint8_t sign = Temperatur<0; div_t res = div(abs(Temperatur),10); VFS_LOG("temp.log", "%2d.%2d%2d %2d:%02d %S%d.%d", CLOCK_DAY, CLOCK_MONTH, CLOCK_YEAR, CLOCK_HOUR, CLOCK_MIN, CLOCK_SEC, sign?PSTR("-"):PSTR(""),res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> e3aea525e5b7bfef3ef721b0033751ac2c8e846f 1058 1057 2013-06-06T12:32:25Z GooPie4o 265 /* Sockel */ wikitext text/x-wiki {{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS= |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader] }} Das Modul basiert auf Roland Riegels [http://www.roland-riegel.de/sd-reader/ MMC/SD/SDHC card library] ergänzt um die Anbindung an das Ethersex [[VFS|Virtual File System]]. == Anschluss == [[File:Sdcard adapter schaltung.png|200px|thumb|right|SD-Card Adapter Schaltung]] [[File:Sdcard adapter.jpg|200px|thumb|right|SD-Card Adapter Aufbau]] MMC- und SD-Speicherkarten lassen sich im [[SPI]]-Modus relativ einfach mit einem Mikrocontroller ansteuern. Prinzipiell gibt es zwischen SD-Card und MMC nicht viele Unterschiede, allerdings sind SD-Karten weiter verbreitet, in der Regel schneller als MMCs, und haben ein besser implementiertes SPI-Interface. Es existieren diverse Varianten (miniSD, microSD), die zur normalen SD-Card weitgehend kompatibel sind. Die Karte liest das anliegende Datenbit mit der steigenden Taktflanke ein, als [[SPI]]-Modi eignen sich somit Mode 0 und Mode 3. Bei MMCs ist der SPI-Modus nicht genau spezifiziert, somit kommt es durchaus mal vor, dass der [[SPI]]-Modus je nach Karte unterschiedlich gewählt werden muss. SD-Karten werden typischerweise mit 3,3V und Microcontroller oft mit 5V betrieben. Das erzwingt eine [http://www.mikrocontroller.net/articles/Pegelwandler#5V_.3C-.3E_3.3V Pegelanpassung], weil die Eingangsleitungen zur SD-Karte nicht 5V tolerant sind. Von einer [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#Bekannte_Fehler Pegelanpassung mit Widerständen] wird abgeraten. Neben den Leitungen, die zur SD-Karte führen, gibt es noch zwei weitere Leitungen, die auf den SD-Karten-Sockel führen: nämlich die card-detect Leitung und die write-protect Leitung. Sie dienen dazu, wie die Namen schon sagen, das physische Vorhandensein einer Karte im SD-Sockel und die Stellung des Schreibschutzschiebers zu signalisieren. Wird Hardware-SPI verwendet, muss nur die chip select Leitung konfiguriert werden. Die card-detect Leitung und die write-protect Leitung sind optional. ifdef(`conf_SD_READER', ` /* port the sd-reader CS is attached to */ pin(SPI_CS_SD_READER, PB2, OUTPUT) /* uncomment and edit this if you have connected the CD (card detect) signal */ pin(SD_READER_AVAILABLE, PD4, INPUT) /* uncomment and edit this if you have connected the WP (write protected) signal */ pin(SD_READER_WR_PROTECT, PD5, INPUT) ') Ein weiteres Problem bei den SD Karten ist die Initialisierung. Schafft es Ethersex nicht in einer bestimmten Zeit zu syncen, so fällt die Karte in den normalen (nicht den SD) Betriebsmodus und kann nicht mehr angesprochen werden. Eine Lösung dafür ist, dass der Karte eine steuerbare Stromversorgung erhält. Dazu definiert man im Pinning nur den Pin pin(SD_READER_POWERON, PB3, OUTPUT) ==== Sockel ==== Eine günstige Art der Kontaktierung ist wohl das Ausschlachten eines billigen Cardreaders, wenn man keine Kabel direkt an die Karte löten möchte. Einzeln gekaufte Steckverbinder sind meist erheblich teuerer.Man kann auch alte [http://uanr.com/sdfloppy/ Floppy-Kabel als günstigen Steckverbinder] benutzen. Teile von AT-Slots oder Verbinder von 5,25-Zoll-Floppys gehen auch. Notfalls kann man die Karte zwischen 2 Reihen Stiftleiste einklemmen (oder anlöten). Noch günstiger geht es wenn man Mikro- oder Mini-SD-Karten benutzt und den meist beigelegten Adapter anlötet. Wer jedoch auf einen Selbstbau verzichten will, kann alternativ für relativ schmales Geld einen [http://www.shop.display3000.com/wichtiges-zubehoer/experimentierplatinen/sd-speicherkartenplatine.html fertig aufgebauten SD-Adapter] zum Anschließen an den AVR käulich erwerben. Bei diesem Adapter ist bereits eine bidirektionale Pegelanpassung zwischen den 5V-Pegeln der Steuerleitungen des AVR und den 3,3V-Pegel der SD-Karte an Bord. == Konfiguration == | | I/O ---> | | ... | | [*] SD/MMC-Card Reader ---> | | ... | | [ ] SDHC support | | | | [*] VFAT LFN support | | | | [ ] Read-only mode | | | | [*] Use read-timeout | | | | [*] Ping-read SD card every 10s | | | | --- Debugging Flags | | | | [ ] SD-Reader | | | | General Setup ---> | | ... | | [*] VFS (Virtual File System) support ---> | | ... | | [*] SD/MMC-Card Filesystem | | == [[ECMD_(Deutsch)|ECMD]] == == [[Control6_(Deutsch)|Control6]] == Das folgende Beispiel scrheibt Datum, Uhrzeit und Temperatur per VFS_LOG in die Datei "temp.log" schreibt sobald sich die Temperatur um mehr als ein Grad zur letzten Messung verändert hat. Für Datum und Uhrzeit muss CLOCK_SUPPORT aktiviert sein. <pre> #include <stdlib.h> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO uint8_t sign = Temperatur<0; div_t res = div(abs(Temperatur),10); VFS_LOG("temp.log", "%2d.%2d%2d %2d:%02d %S%d.%d", CLOCK_DAY, CLOCK_MONTH, CLOCK_YEAR, CLOCK_HOUR, CLOCK_MIN, CLOCK_SEC, sign?PSTR("-"):PSTR(""),res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> 0af4f98a3892f2585be8f6356195e79572768af7 1070 1058 2013-06-22T10:35:41Z GooPie4o 265 /* Control6 */ wikitext text/x-wiki {{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS= |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader] }} Das Modul basiert auf Roland Riegels [http://www.roland-riegel.de/sd-reader/ MMC/SD/SDHC card library] ergänzt um die Anbindung an das Ethersex [[VFS|Virtual File System]]. == Anschluss == [[File:Sdcard adapter schaltung.png|200px|thumb|right|SD-Card Adapter Schaltung]] [[File:Sdcard adapter.jpg|200px|thumb|right|SD-Card Adapter Aufbau]] MMC- und SD-Speicherkarten lassen sich im [[SPI]]-Modus relativ einfach mit einem Mikrocontroller ansteuern. Prinzipiell gibt es zwischen SD-Card und MMC nicht viele Unterschiede, allerdings sind SD-Karten weiter verbreitet, in der Regel schneller als MMCs, und haben ein besser implementiertes SPI-Interface. Es existieren diverse Varianten (miniSD, microSD), die zur normalen SD-Card weitgehend kompatibel sind. Die Karte liest das anliegende Datenbit mit der steigenden Taktflanke ein, als [[SPI]]-Modi eignen sich somit Mode 0 und Mode 3. Bei MMCs ist der SPI-Modus nicht genau spezifiziert, somit kommt es durchaus mal vor, dass der [[SPI]]-Modus je nach Karte unterschiedlich gewählt werden muss. SD-Karten werden typischerweise mit 3,3V und Microcontroller oft mit 5V betrieben. Das erzwingt eine [http://www.mikrocontroller.net/articles/Pegelwandler#5V_.3C-.3E_3.3V Pegelanpassung], weil die Eingangsleitungen zur SD-Karte nicht 5V tolerant sind. Von einer [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#Bekannte_Fehler Pegelanpassung mit Widerständen] wird abgeraten. Neben den Leitungen, die zur SD-Karte führen, gibt es noch zwei weitere Leitungen, die auf den SD-Karten-Sockel führen: nämlich die card-detect Leitung und die write-protect Leitung. Sie dienen dazu, wie die Namen schon sagen, das physische Vorhandensein einer Karte im SD-Sockel und die Stellung des Schreibschutzschiebers zu signalisieren. Wird Hardware-SPI verwendet, muss nur die chip select Leitung konfiguriert werden. Die card-detect Leitung und die write-protect Leitung sind optional. ifdef(`conf_SD_READER', ` /* port the sd-reader CS is attached to */ pin(SPI_CS_SD_READER, PB2, OUTPUT) /* uncomment and edit this if you have connected the CD (card detect) signal */ pin(SD_READER_AVAILABLE, PD4, INPUT) /* uncomment and edit this if you have connected the WP (write protected) signal */ pin(SD_READER_WR_PROTECT, PD5, INPUT) ') Ein weiteres Problem bei den SD Karten ist die Initialisierung. Schafft es Ethersex nicht in einer bestimmten Zeit zu syncen, so fällt die Karte in den normalen (nicht den SD) Betriebsmodus und kann nicht mehr angesprochen werden. Eine Lösung dafür ist, dass der Karte eine steuerbare Stromversorgung erhält. Dazu definiert man im Pinning nur den Pin pin(SD_READER_POWERON, PB3, OUTPUT) ==== Sockel ==== Eine günstige Art der Kontaktierung ist wohl das Ausschlachten eines billigen Cardreaders, wenn man keine Kabel direkt an die Karte löten möchte. Einzeln gekaufte Steckverbinder sind meist erheblich teuerer.Man kann auch alte [http://uanr.com/sdfloppy/ Floppy-Kabel als günstigen Steckverbinder] benutzen. Teile von AT-Slots oder Verbinder von 5,25-Zoll-Floppys gehen auch. Notfalls kann man die Karte zwischen 2 Reihen Stiftleiste einklemmen (oder anlöten). Noch günstiger geht es wenn man Mikro- oder Mini-SD-Karten benutzt und den meist beigelegten Adapter anlötet. Wer jedoch auf einen Selbstbau verzichten will, kann alternativ für relativ schmales Geld einen [http://www.shop.display3000.com/wichtiges-zubehoer/experimentierplatinen/sd-speicherkartenplatine.html fertig aufgebauten SD-Adapter] zum Anschließen an den AVR käulich erwerben. Bei diesem Adapter ist bereits eine bidirektionale Pegelanpassung zwischen den 5V-Pegeln der Steuerleitungen des AVR und den 3,3V-Pegel der SD-Karte an Bord. == Konfiguration == | | I/O ---> | | ... | | [*] SD/MMC-Card Reader ---> | | ... | | [ ] SDHC support | | | | [*] VFAT LFN support | | | | [ ] Read-only mode | | | | [*] Use read-timeout | | | | [*] Ping-read SD card every 10s | | | | --- Debugging Flags | | | | [ ] SD-Reader | | | | General Setup ---> | | ... | | [*] VFS (Virtual File System) support ---> | | ... | | [*] SD/MMC-Card Filesystem | | == [[ECMD_(Deutsch)|ECMD]] == == [[Control6_(Deutsch)|Control6]] == Das folgende Beispiel scrheibt Datum, Uhrzeit und Temperatur per VFS_LOG_ALLOCA in die Datei "temp.log" schreibt sobald sich die Temperatur um mehr als ein Grad zur letzten Messung verändert hat. Für Datum und Uhrzeit muss CLOCK_SUPPORT aktiviert sein. <pre> #include <stdlib.h> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO uint8_t sign = Temperatur<0; div_t res = div(abs(Temperatur),10); VFS_LOG_ALLOCA("temp.log", 50, "%2d.%2d.%4d %2d:%02d %S%d.%d", CLOCK_DAY, CLOCK_MONTH, CLOCK_YEAR, CLOCK_HOUR, CLOCK_MIN, sign?PSTR("-"):PSTR(""),res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> 535650d845a2f64a903f609cb6860c2dfba56d7d 1071 1070 2013-06-22T10:39:22Z GooPie4o 265 /* Konfiguration */ wikitext text/x-wiki {{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS= |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader] }} Das Modul basiert auf Roland Riegels [http://www.roland-riegel.de/sd-reader/ MMC/SD/SDHC card library] ergänzt um die Anbindung an das Ethersex [[VFS|Virtual File System]]. == Anschluss == [[File:Sdcard adapter schaltung.png|200px|thumb|right|SD-Card Adapter Schaltung]] [[File:Sdcard adapter.jpg|200px|thumb|right|SD-Card Adapter Aufbau]] MMC- und SD-Speicherkarten lassen sich im [[SPI]]-Modus relativ einfach mit einem Mikrocontroller ansteuern. Prinzipiell gibt es zwischen SD-Card und MMC nicht viele Unterschiede, allerdings sind SD-Karten weiter verbreitet, in der Regel schneller als MMCs, und haben ein besser implementiertes SPI-Interface. Es existieren diverse Varianten (miniSD, microSD), die zur normalen SD-Card weitgehend kompatibel sind. Die Karte liest das anliegende Datenbit mit der steigenden Taktflanke ein, als [[SPI]]-Modi eignen sich somit Mode 0 und Mode 3. Bei MMCs ist der SPI-Modus nicht genau spezifiziert, somit kommt es durchaus mal vor, dass der [[SPI]]-Modus je nach Karte unterschiedlich gewählt werden muss. SD-Karten werden typischerweise mit 3,3V und Microcontroller oft mit 5V betrieben. Das erzwingt eine [http://www.mikrocontroller.net/articles/Pegelwandler#5V_.3C-.3E_3.3V Pegelanpassung], weil die Eingangsleitungen zur SD-Karte nicht 5V tolerant sind. Von einer [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#Bekannte_Fehler Pegelanpassung mit Widerständen] wird abgeraten. Neben den Leitungen, die zur SD-Karte führen, gibt es noch zwei weitere Leitungen, die auf den SD-Karten-Sockel führen: nämlich die card-detect Leitung und die write-protect Leitung. Sie dienen dazu, wie die Namen schon sagen, das physische Vorhandensein einer Karte im SD-Sockel und die Stellung des Schreibschutzschiebers zu signalisieren. Wird Hardware-SPI verwendet, muss nur die chip select Leitung konfiguriert werden. Die card-detect Leitung und die write-protect Leitung sind optional. ifdef(`conf_SD_READER', ` /* port the sd-reader CS is attached to */ pin(SPI_CS_SD_READER, PB2, OUTPUT) /* uncomment and edit this if you have connected the CD (card detect) signal */ pin(SD_READER_AVAILABLE, PD4, INPUT) /* uncomment and edit this if you have connected the WP (write protected) signal */ pin(SD_READER_WR_PROTECT, PD5, INPUT) ') Ein weiteres Problem bei den SD Karten ist die Initialisierung. Schafft es Ethersex nicht in einer bestimmten Zeit zu syncen, so fällt die Karte in den normalen (nicht den SD) Betriebsmodus und kann nicht mehr angesprochen werden. Eine Lösung dafür ist, dass der Karte eine steuerbare Stromversorgung erhält. Dazu definiert man im Pinning nur den Pin pin(SD_READER_POWERON, PB3, OUTPUT) ==== Sockel ==== Eine günstige Art der Kontaktierung ist wohl das Ausschlachten eines billigen Cardreaders, wenn man keine Kabel direkt an die Karte löten möchte. Einzeln gekaufte Steckverbinder sind meist erheblich teuerer.Man kann auch alte [http://uanr.com/sdfloppy/ Floppy-Kabel als günstigen Steckverbinder] benutzen. Teile von AT-Slots oder Verbinder von 5,25-Zoll-Floppys gehen auch. Notfalls kann man die Karte zwischen 2 Reihen Stiftleiste einklemmen (oder anlöten). Noch günstiger geht es wenn man Mikro- oder Mini-SD-Karten benutzt und den meist beigelegten Adapter anlötet. Wer jedoch auf einen Selbstbau verzichten will, kann alternativ für relativ schmales Geld einen [http://www.shop.display3000.com/wichtiges-zubehoer/experimentierplatinen/sd-speicherkartenplatine.html fertig aufgebauten SD-Adapter] zum Anschließen an den AVR käulich erwerben. Bei diesem Adapter ist bereits eine bidirektionale Pegelanpassung zwischen den 5V-Pegeln der Steuerleitungen des AVR und den 3,3V-Pegel der SD-Karte an Bord. == Konfiguration == | | I/O ---> | | ... │ │ Storage ---> │ │ ... | | [*] SD/MMC-Card Reader ---> | | ... | | [ ] SDHC support | | | | [*] VFAT LFN support | | | | [ ] Read-only mode | | | | [*] Use read-timeout | | | | [*] Ping-read SD card every 10s | | | | --- Debugging Flags | | | | [ ] SD-Reader | | | | General Setup ---> | | ... | | [*] VFS (Virtual File System) support ---> | | ... | | [*] SD/MMC-Card Filesystem | | == [[ECMD_(Deutsch)|ECMD]] == == [[Control6_(Deutsch)|Control6]] == Das folgende Beispiel scrheibt Datum, Uhrzeit und Temperatur per VFS_LOG_ALLOCA in die Datei "temp.log" schreibt sobald sich die Temperatur um mehr als ein Grad zur letzten Messung verändert hat. Für Datum und Uhrzeit muss CLOCK_SUPPORT aktiviert sein. <pre> #include <stdlib.h> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO uint8_t sign = Temperatur<0; div_t res = div(abs(Temperatur),10); VFS_LOG_ALLOCA("temp.log", 50, "%2d.%2d.%4d %2d:%02d %S%d.%d", CLOCK_DAY, CLOCK_MONTH, CLOCK_YEAR, CLOCK_HOUR, CLOCK_MIN, sign?PSTR("-"):PSTR(""),res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> 5e86a50ccda3c5cb6a53549c57c0493c1e678f79 1072 1071 2013-06-22T13:45:26Z GooPie4o 265 /* Konfiguration */ wikitext text/x-wiki {{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS= |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader] }} Das Modul basiert auf Roland Riegels [http://www.roland-riegel.de/sd-reader/ MMC/SD/SDHC card library] ergänzt um die Anbindung an das Ethersex [[VFS|Virtual File System]]. == Anschluss == [[File:Sdcard adapter schaltung.png|200px|thumb|right|SD-Card Adapter Schaltung]] [[File:Sdcard adapter.jpg|200px|thumb|right|SD-Card Adapter Aufbau]] MMC- und SD-Speicherkarten lassen sich im [[SPI]]-Modus relativ einfach mit einem Mikrocontroller ansteuern. Prinzipiell gibt es zwischen SD-Card und MMC nicht viele Unterschiede, allerdings sind SD-Karten weiter verbreitet, in der Regel schneller als MMCs, und haben ein besser implementiertes SPI-Interface. Es existieren diverse Varianten (miniSD, microSD), die zur normalen SD-Card weitgehend kompatibel sind. Die Karte liest das anliegende Datenbit mit der steigenden Taktflanke ein, als [[SPI]]-Modi eignen sich somit Mode 0 und Mode 3. Bei MMCs ist der SPI-Modus nicht genau spezifiziert, somit kommt es durchaus mal vor, dass der [[SPI]]-Modus je nach Karte unterschiedlich gewählt werden muss. SD-Karten werden typischerweise mit 3,3V und Microcontroller oft mit 5V betrieben. Das erzwingt eine [http://www.mikrocontroller.net/articles/Pegelwandler#5V_.3C-.3E_3.3V Pegelanpassung], weil die Eingangsleitungen zur SD-Karte nicht 5V tolerant sind. Von einer [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#Bekannte_Fehler Pegelanpassung mit Widerständen] wird abgeraten. Neben den Leitungen, die zur SD-Karte führen, gibt es noch zwei weitere Leitungen, die auf den SD-Karten-Sockel führen: nämlich die card-detect Leitung und die write-protect Leitung. Sie dienen dazu, wie die Namen schon sagen, das physische Vorhandensein einer Karte im SD-Sockel und die Stellung des Schreibschutzschiebers zu signalisieren. Wird Hardware-SPI verwendet, muss nur die chip select Leitung konfiguriert werden. Die card-detect Leitung und die write-protect Leitung sind optional. ifdef(`conf_SD_READER', ` /* port the sd-reader CS is attached to */ pin(SPI_CS_SD_READER, PB2, OUTPUT) /* uncomment and edit this if you have connected the CD (card detect) signal */ pin(SD_READER_AVAILABLE, PD4, INPUT) /* uncomment and edit this if you have connected the WP (write protected) signal */ pin(SD_READER_WR_PROTECT, PD5, INPUT) ') Ein weiteres Problem bei den SD Karten ist die Initialisierung. Schafft es Ethersex nicht in einer bestimmten Zeit zu syncen, so fällt die Karte in den normalen (nicht den SD) Betriebsmodus und kann nicht mehr angesprochen werden. Eine Lösung dafür ist, dass der Karte eine steuerbare Stromversorgung erhält. Dazu definiert man im Pinning nur den Pin pin(SD_READER_POWERON, PB3, OUTPUT) ==== Sockel ==== Eine günstige Art der Kontaktierung ist wohl das Ausschlachten eines billigen Cardreaders, wenn man keine Kabel direkt an die Karte löten möchte. Einzeln gekaufte Steckverbinder sind meist erheblich teuerer.Man kann auch alte [http://uanr.com/sdfloppy/ Floppy-Kabel als günstigen Steckverbinder] benutzen. Teile von AT-Slots oder Verbinder von 5,25-Zoll-Floppys gehen auch. Notfalls kann man die Karte zwischen 2 Reihen Stiftleiste einklemmen (oder anlöten). Noch günstiger geht es wenn man Mikro- oder Mini-SD-Karten benutzt und den meist beigelegten Adapter anlötet. Wer jedoch auf einen Selbstbau verzichten will, kann alternativ für relativ schmales Geld einen [http://www.shop.display3000.com/wichtiges-zubehoer/experimentierplatinen/sd-speicherkartenplatine.html fertig aufgebauten SD-Adapter] zum Anschließen an den AVR käulich erwerben. Bei diesem Adapter ist bereits eine bidirektionale Pegelanpassung zwischen den 5V-Pegeln der Steuerleitungen des AVR und den 3,3V-Pegel der SD-Karte an Bord. == Konfiguration == | | I/O ---> | | ... │ │ Storage ---> │ │ ... | | [*] SD/MMC-Card Reader ---> | | ... | | [ ] SDHC support | | | | [*] VFAT LFN support | | | | [ ] Read-only mode | | | | [*] Use read-timeout | | | | [*] Ping-read SD card every 10s | | | | --- ECMD Support | | | | [*] info | | | | [*] dir | | | | [*] mkdir | | | | [*] rm | | | | --- Debugging Flags | | | | [*] FAT | | | | [*] RAW | | | | [*] VFS | | | | General Setup ---> | | ... | | [*] VFS (Virtual File System) support ---> | | ... | | [*] SD/MMC-Card Filesystem | | == [[ECMD_(Deutsch)|ECMD]] == == [[Control6_(Deutsch)|Control6]] == Das folgende Beispiel scrheibt Datum, Uhrzeit und Temperatur per VFS_LOG_ALLOCA in die Datei "temp.log" schreibt sobald sich die Temperatur um mehr als ein Grad zur letzten Messung verändert hat. Für Datum und Uhrzeit muss CLOCK_SUPPORT aktiviert sein. <pre> #include <stdlib.h> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO uint8_t sign = Temperatur<0; div_t res = div(abs(Temperatur),10); VFS_LOG_ALLOCA("temp.log", 50, "%2d.%2d.%4d %2d:%02d %S%d.%d", CLOCK_DAY, CLOCK_MONTH, CLOCK_YEAR, CLOCK_HOUR, CLOCK_MIN, sign?PSTR("-"):PSTR(""),res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> 3c75875a47427747b13b1cc9bf3634c67a717b4a 1073 1072 2013-06-22T13:47:01Z GooPie4o 265 /* ECMD */ wikitext text/x-wiki {{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS= |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader] }} Das Modul basiert auf Roland Riegels [http://www.roland-riegel.de/sd-reader/ MMC/SD/SDHC card library] ergänzt um die Anbindung an das Ethersex [[VFS|Virtual File System]]. == Anschluss == [[File:Sdcard adapter schaltung.png|200px|thumb|right|SD-Card Adapter Schaltung]] [[File:Sdcard adapter.jpg|200px|thumb|right|SD-Card Adapter Aufbau]] MMC- und SD-Speicherkarten lassen sich im [[SPI]]-Modus relativ einfach mit einem Mikrocontroller ansteuern. Prinzipiell gibt es zwischen SD-Card und MMC nicht viele Unterschiede, allerdings sind SD-Karten weiter verbreitet, in der Regel schneller als MMCs, und haben ein besser implementiertes SPI-Interface. Es existieren diverse Varianten (miniSD, microSD), die zur normalen SD-Card weitgehend kompatibel sind. Die Karte liest das anliegende Datenbit mit der steigenden Taktflanke ein, als [[SPI]]-Modi eignen sich somit Mode 0 und Mode 3. Bei MMCs ist der SPI-Modus nicht genau spezifiziert, somit kommt es durchaus mal vor, dass der [[SPI]]-Modus je nach Karte unterschiedlich gewählt werden muss. SD-Karten werden typischerweise mit 3,3V und Microcontroller oft mit 5V betrieben. Das erzwingt eine [http://www.mikrocontroller.net/articles/Pegelwandler#5V_.3C-.3E_3.3V Pegelanpassung], weil die Eingangsleitungen zur SD-Karte nicht 5V tolerant sind. Von einer [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#Bekannte_Fehler Pegelanpassung mit Widerständen] wird abgeraten. Neben den Leitungen, die zur SD-Karte führen, gibt es noch zwei weitere Leitungen, die auf den SD-Karten-Sockel führen: nämlich die card-detect Leitung und die write-protect Leitung. Sie dienen dazu, wie die Namen schon sagen, das physische Vorhandensein einer Karte im SD-Sockel und die Stellung des Schreibschutzschiebers zu signalisieren. Wird Hardware-SPI verwendet, muss nur die chip select Leitung konfiguriert werden. Die card-detect Leitung und die write-protect Leitung sind optional. ifdef(`conf_SD_READER', ` /* port the sd-reader CS is attached to */ pin(SPI_CS_SD_READER, PB2, OUTPUT) /* uncomment and edit this if you have connected the CD (card detect) signal */ pin(SD_READER_AVAILABLE, PD4, INPUT) /* uncomment and edit this if you have connected the WP (write protected) signal */ pin(SD_READER_WR_PROTECT, PD5, INPUT) ') Ein weiteres Problem bei den SD Karten ist die Initialisierung. Schafft es Ethersex nicht in einer bestimmten Zeit zu syncen, so fällt die Karte in den normalen (nicht den SD) Betriebsmodus und kann nicht mehr angesprochen werden. Eine Lösung dafür ist, dass der Karte eine steuerbare Stromversorgung erhält. Dazu definiert man im Pinning nur den Pin pin(SD_READER_POWERON, PB3, OUTPUT) ==== Sockel ==== Eine günstige Art der Kontaktierung ist wohl das Ausschlachten eines billigen Cardreaders, wenn man keine Kabel direkt an die Karte löten möchte. Einzeln gekaufte Steckverbinder sind meist erheblich teuerer.Man kann auch alte [http://uanr.com/sdfloppy/ Floppy-Kabel als günstigen Steckverbinder] benutzen. Teile von AT-Slots oder Verbinder von 5,25-Zoll-Floppys gehen auch. Notfalls kann man die Karte zwischen 2 Reihen Stiftleiste einklemmen (oder anlöten). Noch günstiger geht es wenn man Mikro- oder Mini-SD-Karten benutzt und den meist beigelegten Adapter anlötet. Wer jedoch auf einen Selbstbau verzichten will, kann alternativ für relativ schmales Geld einen [http://www.shop.display3000.com/wichtiges-zubehoer/experimentierplatinen/sd-speicherkartenplatine.html fertig aufgebauten SD-Adapter] zum Anschließen an den AVR käulich erwerben. Bei diesem Adapter ist bereits eine bidirektionale Pegelanpassung zwischen den 5V-Pegeln der Steuerleitungen des AVR und den 3,3V-Pegel der SD-Karte an Bord. == Konfiguration == | | I/O ---> | | ... │ │ Storage ---> │ │ ... | | [*] SD/MMC-Card Reader ---> | | ... | | [ ] SDHC support | | | | [*] VFAT LFN support | | | | [ ] Read-only mode | | | | [*] Use read-timeout | | | | [*] Ping-read SD card every 10s | | | | --- ECMD Support | | | | [*] info | | | | [*] dir | | | | [*] mkdir | | | | [*] rm | | | | --- Debugging Flags | | | | [*] FAT | | | | [*] RAW | | | | [*] VFS | | | | General Setup ---> | | ... | | [*] VFS (Virtual File System) support ---> | | ... | | [*] SD/MMC-Card Filesystem | | == [[ECMD_(Deutsch)|ECMD]] == Das SD-CARD Modul implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle. Siehe [[ECMD_Reference|ECMD Referenz]]. == [[Control6_(Deutsch)|Control6]] == Das folgende Beispiel scrheibt Datum, Uhrzeit und Temperatur per VFS_LOG_ALLOCA in die Datei "temp.log" schreibt sobald sich die Temperatur um mehr als ein Grad zur letzten Messung verändert hat. Für Datum und Uhrzeit muss CLOCK_SUPPORT aktiviert sein. <pre> #include <stdlib.h> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO uint8_t sign = Temperatur<0; div_t res = div(abs(Temperatur),10); VFS_LOG_ALLOCA("temp.log", 50, "%2d.%2d.%4d %2d:%02d %S%d.%d", CLOCK_DAY, CLOCK_MONTH, CLOCK_YEAR, CLOCK_HOUR, CLOCK_MIN, sign?PSTR("-"):PSTR(""),res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> 3ff1ab43cc00bf29104ee51d244510d604b43f1d 1074 1073 2013-06-22T13:47:26Z GooPie4o 265 wikitext text/x-wiki {{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->Storage->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS= |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader] }} Das Modul basiert auf Roland Riegels [http://www.roland-riegel.de/sd-reader/ MMC/SD/SDHC card library] ergänzt um die Anbindung an das Ethersex [[VFS|Virtual File System]]. == Anschluss == [[File:Sdcard adapter schaltung.png|200px|thumb|right|SD-Card Adapter Schaltung]] [[File:Sdcard adapter.jpg|200px|thumb|right|SD-Card Adapter Aufbau]] MMC- und SD-Speicherkarten lassen sich im [[SPI]]-Modus relativ einfach mit einem Mikrocontroller ansteuern. Prinzipiell gibt es zwischen SD-Card und MMC nicht viele Unterschiede, allerdings sind SD-Karten weiter verbreitet, in der Regel schneller als MMCs, und haben ein besser implementiertes SPI-Interface. Es existieren diverse Varianten (miniSD, microSD), die zur normalen SD-Card weitgehend kompatibel sind. Die Karte liest das anliegende Datenbit mit der steigenden Taktflanke ein, als [[SPI]]-Modi eignen sich somit Mode 0 und Mode 3. Bei MMCs ist der SPI-Modus nicht genau spezifiziert, somit kommt es durchaus mal vor, dass der [[SPI]]-Modus je nach Karte unterschiedlich gewählt werden muss. SD-Karten werden typischerweise mit 3,3V und Microcontroller oft mit 5V betrieben. Das erzwingt eine [http://www.mikrocontroller.net/articles/Pegelwandler#5V_.3C-.3E_3.3V Pegelanpassung], weil die Eingangsleitungen zur SD-Karte nicht 5V tolerant sind. Von einer [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#Bekannte_Fehler Pegelanpassung mit Widerständen] wird abgeraten. Neben den Leitungen, die zur SD-Karte führen, gibt es noch zwei weitere Leitungen, die auf den SD-Karten-Sockel führen: nämlich die card-detect Leitung und die write-protect Leitung. Sie dienen dazu, wie die Namen schon sagen, das physische Vorhandensein einer Karte im SD-Sockel und die Stellung des Schreibschutzschiebers zu signalisieren. Wird Hardware-SPI verwendet, muss nur die chip select Leitung konfiguriert werden. Die card-detect Leitung und die write-protect Leitung sind optional. ifdef(`conf_SD_READER', ` /* port the sd-reader CS is attached to */ pin(SPI_CS_SD_READER, PB2, OUTPUT) /* uncomment and edit this if you have connected the CD (card detect) signal */ pin(SD_READER_AVAILABLE, PD4, INPUT) /* uncomment and edit this if you have connected the WP (write protected) signal */ pin(SD_READER_WR_PROTECT, PD5, INPUT) ') Ein weiteres Problem bei den SD Karten ist die Initialisierung. Schafft es Ethersex nicht in einer bestimmten Zeit zu syncen, so fällt die Karte in den normalen (nicht den SD) Betriebsmodus und kann nicht mehr angesprochen werden. Eine Lösung dafür ist, dass der Karte eine steuerbare Stromversorgung erhält. Dazu definiert man im Pinning nur den Pin pin(SD_READER_POWERON, PB3, OUTPUT) ==== Sockel ==== Eine günstige Art der Kontaktierung ist wohl das Ausschlachten eines billigen Cardreaders, wenn man keine Kabel direkt an die Karte löten möchte. Einzeln gekaufte Steckverbinder sind meist erheblich teuerer.Man kann auch alte [http://uanr.com/sdfloppy/ Floppy-Kabel als günstigen Steckverbinder] benutzen. Teile von AT-Slots oder Verbinder von 5,25-Zoll-Floppys gehen auch. Notfalls kann man die Karte zwischen 2 Reihen Stiftleiste einklemmen (oder anlöten). Noch günstiger geht es wenn man Mikro- oder Mini-SD-Karten benutzt und den meist beigelegten Adapter anlötet. Wer jedoch auf einen Selbstbau verzichten will, kann alternativ für relativ schmales Geld einen [http://www.shop.display3000.com/wichtiges-zubehoer/experimentierplatinen/sd-speicherkartenplatine.html fertig aufgebauten SD-Adapter] zum Anschließen an den AVR käulich erwerben. Bei diesem Adapter ist bereits eine bidirektionale Pegelanpassung zwischen den 5V-Pegeln der Steuerleitungen des AVR und den 3,3V-Pegel der SD-Karte an Bord. == Konfiguration == | | I/O ---> | | ... │ │ Storage ---> │ │ ... | | [*] SD/MMC-Card Reader ---> | | ... | | [ ] SDHC support | | | | [*] VFAT LFN support | | | | [ ] Read-only mode | | | | [*] Use read-timeout | | | | [*] Ping-read SD card every 10s | | | | --- ECMD Support | | | | [*] info | | | | [*] dir | | | | [*] mkdir | | | | [*] rm | | | | --- Debugging Flags | | | | [*] FAT | | | | [*] RAW | | | | [*] VFS | | | | General Setup ---> | | ... | | [*] VFS (Virtual File System) support ---> | | ... | | [*] SD/MMC-Card Filesystem | | == [[ECMD_(Deutsch)|ECMD]] == Das SD-CARD Modul implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle. Siehe [[ECMD_Reference|ECMD Referenz]]. == [[Control6_(Deutsch)|Control6]] == Das folgende Beispiel scrheibt Datum, Uhrzeit und Temperatur per VFS_LOG_ALLOCA in die Datei "temp.log" schreibt sobald sich die Temperatur um mehr als ein Grad zur letzten Messung verändert hat. Für Datum und Uhrzeit muss CLOCK_SUPPORT aktiviert sein. <pre> #include <stdlib.h> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO uint8_t sign = Temperatur<0; div_t res = div(abs(Temperatur),10); VFS_LOG_ALLOCA("temp.log", 50, "%2d.%2d.%4d %2d:%02d %S%d.%d", CLOCK_DAY, CLOCK_MONTH, CLOCK_YEAR, CLOCK_HOUR, CLOCK_MIN, sign?PSTR("-"):PSTR(""),res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> 8dfe74b21a0ea827f3bad09a287d6d00795e6991 1075 1074 2013-06-22T13:49:15Z GooPie4o 265 /* Control6 */ wikitext text/x-wiki {{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->Storage->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS= |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader] }} Das Modul basiert auf Roland Riegels [http://www.roland-riegel.de/sd-reader/ MMC/SD/SDHC card library] ergänzt um die Anbindung an das Ethersex [[VFS|Virtual File System]]. == Anschluss == [[File:Sdcard adapter schaltung.png|200px|thumb|right|SD-Card Adapter Schaltung]] [[File:Sdcard adapter.jpg|200px|thumb|right|SD-Card Adapter Aufbau]] MMC- und SD-Speicherkarten lassen sich im [[SPI]]-Modus relativ einfach mit einem Mikrocontroller ansteuern. Prinzipiell gibt es zwischen SD-Card und MMC nicht viele Unterschiede, allerdings sind SD-Karten weiter verbreitet, in der Regel schneller als MMCs, und haben ein besser implementiertes SPI-Interface. Es existieren diverse Varianten (miniSD, microSD), die zur normalen SD-Card weitgehend kompatibel sind. Die Karte liest das anliegende Datenbit mit der steigenden Taktflanke ein, als [[SPI]]-Modi eignen sich somit Mode 0 und Mode 3. Bei MMCs ist der SPI-Modus nicht genau spezifiziert, somit kommt es durchaus mal vor, dass der [[SPI]]-Modus je nach Karte unterschiedlich gewählt werden muss. SD-Karten werden typischerweise mit 3,3V und Microcontroller oft mit 5V betrieben. Das erzwingt eine [http://www.mikrocontroller.net/articles/Pegelwandler#5V_.3C-.3E_3.3V Pegelanpassung], weil die Eingangsleitungen zur SD-Karte nicht 5V tolerant sind. Von einer [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#Bekannte_Fehler Pegelanpassung mit Widerständen] wird abgeraten. Neben den Leitungen, die zur SD-Karte führen, gibt es noch zwei weitere Leitungen, die auf den SD-Karten-Sockel führen: nämlich die card-detect Leitung und die write-protect Leitung. Sie dienen dazu, wie die Namen schon sagen, das physische Vorhandensein einer Karte im SD-Sockel und die Stellung des Schreibschutzschiebers zu signalisieren. Wird Hardware-SPI verwendet, muss nur die chip select Leitung konfiguriert werden. Die card-detect Leitung und die write-protect Leitung sind optional. ifdef(`conf_SD_READER', ` /* port the sd-reader CS is attached to */ pin(SPI_CS_SD_READER, PB2, OUTPUT) /* uncomment and edit this if you have connected the CD (card detect) signal */ pin(SD_READER_AVAILABLE, PD4, INPUT) /* uncomment and edit this if you have connected the WP (write protected) signal */ pin(SD_READER_WR_PROTECT, PD5, INPUT) ') Ein weiteres Problem bei den SD Karten ist die Initialisierung. Schafft es Ethersex nicht in einer bestimmten Zeit zu syncen, so fällt die Karte in den normalen (nicht den SD) Betriebsmodus und kann nicht mehr angesprochen werden. Eine Lösung dafür ist, dass der Karte eine steuerbare Stromversorgung erhält. Dazu definiert man im Pinning nur den Pin pin(SD_READER_POWERON, PB3, OUTPUT) ==== Sockel ==== Eine günstige Art der Kontaktierung ist wohl das Ausschlachten eines billigen Cardreaders, wenn man keine Kabel direkt an die Karte löten möchte. Einzeln gekaufte Steckverbinder sind meist erheblich teuerer.Man kann auch alte [http://uanr.com/sdfloppy/ Floppy-Kabel als günstigen Steckverbinder] benutzen. Teile von AT-Slots oder Verbinder von 5,25-Zoll-Floppys gehen auch. Notfalls kann man die Karte zwischen 2 Reihen Stiftleiste einklemmen (oder anlöten). Noch günstiger geht es wenn man Mikro- oder Mini-SD-Karten benutzt und den meist beigelegten Adapter anlötet. Wer jedoch auf einen Selbstbau verzichten will, kann alternativ für relativ schmales Geld einen [http://www.shop.display3000.com/wichtiges-zubehoer/experimentierplatinen/sd-speicherkartenplatine.html fertig aufgebauten SD-Adapter] zum Anschließen an den AVR käulich erwerben. Bei diesem Adapter ist bereits eine bidirektionale Pegelanpassung zwischen den 5V-Pegeln der Steuerleitungen des AVR und den 3,3V-Pegel der SD-Karte an Bord. == Konfiguration == | | I/O ---> | | ... │ │ Storage ---> │ │ ... | | [*] SD/MMC-Card Reader ---> | | ... | | [ ] SDHC support | | | | [*] VFAT LFN support | | | | [ ] Read-only mode | | | | [*] Use read-timeout | | | | [*] Ping-read SD card every 10s | | | | --- ECMD Support | | | | [*] info | | | | [*] dir | | | | [*] mkdir | | | | [*] rm | | | | --- Debugging Flags | | | | [*] FAT | | | | [*] RAW | | | | [*] VFS | | | | General Setup ---> | | ... | | [*] VFS (Virtual File System) support ---> | | ... | | [*] SD/MMC-Card Filesystem | | == [[ECMD_(Deutsch)|ECMD]] == Das SD-CARD Modul implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle. Siehe [[ECMD_Reference|ECMD Referenz]]. == [[Control6_(Deutsch)|Control6]] == Das folgende Beispiel scrheibt Datum, Uhrzeit und Temperatur per VFS_LOG_ALLOCA (VFS_LOG erfordert UIP) in die Datei "temp.log" schreibt sobald sich die Temperatur um mehr als ein Grad zur letzten Messung verändert hat. Für Datum und Uhrzeit muss CLOCK_SUPPORT aktiviert sein. <pre> #include <stdlib.h> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO uint8_t sign = Temperatur<0; div_t res = div(abs(Temperatur),10); VFS_LOG_ALLOCA("temp.log", 50, "%2d.%2d.%4d %2d:%02d %S%d.%d", CLOCK_DAY, CLOCK_MONTH, CLOCK_YEAR, CLOCK_HOUR, CLOCK_MIN, sign?PSTR("-"):PSTR(""),res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> c4eb2105e00c774e5b79f57eb452a9ba77eb783d 1077 1075 2013-06-22T13:51:16Z GooPie4o 265 Typo wikitext text/x-wiki {{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->Storage->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS= |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader] }} Das Modul basiert auf Roland Riegels [http://www.roland-riegel.de/sd-reader/ MMC/SD/SDHC card library] ergänzt um die Anbindung an das Ethersex [[VFS|Virtual File System]]. == Anschluss == [[File:Sdcard adapter schaltung.png|200px|thumb|right|SD-Card Adapter Schaltung]] [[File:Sdcard adapter.jpg|200px|thumb|right|SD-Card Adapter Aufbau]] MMC- und SD-Speicherkarten lassen sich im [[SPI]]-Modus relativ einfach mit einem Mikrocontroller ansteuern. Prinzipiell gibt es zwischen SD-Card und MMC nicht viele Unterschiede, allerdings sind SD-Karten weiter verbreitet, in der Regel schneller als MMCs, und haben ein besser implementiertes SPI-Interface. Es existieren diverse Varianten (miniSD, microSD), die zur normalen SD-Card weitgehend kompatibel sind. Die Karte liest das anliegende Datenbit mit der steigenden Taktflanke ein, als [[SPI]]-Modi eignen sich somit Mode 0 und Mode 3. Bei MMCs ist der SPI-Modus nicht genau spezifiziert, somit kommt es durchaus mal vor, dass der [[SPI]]-Modus je nach Karte unterschiedlich gewählt werden muss. SD-Karten werden typischerweise mit 3,3V und Microcontroller oft mit 5V betrieben. Das erzwingt eine [http://www.mikrocontroller.net/articles/Pegelwandler#5V_.3C-.3E_3.3V Pegelanpassung], weil die Eingangsleitungen zur SD-Karte nicht 5V tolerant sind. Von einer [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#Bekannte_Fehler Pegelanpassung mit Widerständen] wird abgeraten. Neben den Leitungen, die zur SD-Karte führen, gibt es noch zwei weitere Leitungen, die auf den SD-Karten-Sockel führen: nämlich die card-detect Leitung und die write-protect Leitung. Sie dienen dazu, wie die Namen schon sagen, das physische Vorhandensein einer Karte im SD-Sockel und die Stellung des Schreibschutzschiebers zu signalisieren. Wird Hardware-SPI verwendet, muss nur die chip select Leitung konfiguriert werden. Die card-detect Leitung und die write-protect Leitung sind optional. ifdef(`conf_SD_READER', ` /* port the sd-reader CS is attached to */ pin(SPI_CS_SD_READER, PB2, OUTPUT) /* uncomment and edit this if you have connected the CD (card detect) signal */ pin(SD_READER_AVAILABLE, PD4, INPUT) /* uncomment and edit this if you have connected the WP (write protected) signal */ pin(SD_READER_WR_PROTECT, PD5, INPUT) ') Ein weiteres Problem bei den SD Karten ist die Initialisierung. Schafft es Ethersex nicht in einer bestimmten Zeit zu syncen, so fällt die Karte in den normalen (nicht den SD) Betriebsmodus und kann nicht mehr angesprochen werden. Eine Lösung dafür ist, dass der Karte eine steuerbare Stromversorgung erhält. Dazu definiert man im Pinning nur den Pin pin(SD_READER_POWERON, PB3, OUTPUT) ==== Sockel ==== Eine günstige Art der Kontaktierung ist wohl das Ausschlachten eines billigen Cardreaders, wenn man keine Kabel direkt an die Karte löten möchte. Einzeln gekaufte Steckverbinder sind meist erheblich teuerer.Man kann auch alte [http://uanr.com/sdfloppy/ Floppy-Kabel als günstigen Steckverbinder] benutzen. Teile von AT-Slots oder Verbinder von 5,25-Zoll-Floppys gehen auch. Notfalls kann man die Karte zwischen 2 Reihen Stiftleiste einklemmen (oder anlöten). Noch günstiger geht es wenn man Mikro- oder Mini-SD-Karten benutzt und den meist beigelegten Adapter anlötet. Wer jedoch auf einen Selbstbau verzichten will, kann alternativ für relativ schmales Geld einen [http://www.shop.display3000.com/wichtiges-zubehoer/experimentierplatinen/sd-speicherkartenplatine.html fertig aufgebauten SD-Adapter] zum Anschließen an den AVR käulich erwerben. Bei diesem Adapter ist bereits eine bidirektionale Pegelanpassung zwischen den 5V-Pegeln der Steuerleitungen des AVR und den 3,3V-Pegel der SD-Karte an Bord. == Konfiguration == | | I/O ---> | | ... │ │ Storage ---> │ │ ... | | [*] SD/MMC-Card Reader ---> | | ... | | [ ] SDHC support | | | | [*] VFAT LFN support | | | | [ ] Read-only mode | | | | [*] Use read-timeout | | | | [*] Ping-read SD card every 10s | | | | --- ECMD Support | | | | [*] info | | | | [*] dir | | | | [*] mkdir | | | | [*] rm | | | | --- Debugging Flags | | | | [*] FAT | | | | [*] RAW | | | | [*] VFS | | | | General Setup ---> | | ... | | [*] VFS (Virtual File System) support ---> | | ... | | [*] SD/MMC-Card Filesystem | | == [[ECMD_(Deutsch)|ECMD]] == Das SD-CARD Modul implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle. Siehe [[ECMD_Reference|ECMD Referenz]]. == [[Control6_(Deutsch)|Control6]] == Das folgende Beispiel schreibt Datum, Uhrzeit und Temperatur per VFS_LOG_ALLOCA (VFS_LOG erfordert UIP) in die Datei "temp.log" schreibt sobald sich die Temperatur um mehr als ein Grad zur letzten Messung verändert hat. Für Datum und Uhrzeit muss CLOCK_SUPPORT aktiviert sein. <pre> #include <stdlib.h> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO uint8_t sign = Temperatur<0; div_t res = div(abs(Temperatur),10); VFS_LOG_ALLOCA("temp.log", 50, "%2d.%2d.%4d %2d:%02d %S%d.%d", CLOCK_DAY, CLOCK_MONTH, CLOCK_YEAR, CLOCK_HOUR, CLOCK_MIN, sign?PSTR("-"):PSTR(""),res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> 6c1a0e016248059225de7709b2f6c163ee71dbcf 1090 1077 2013-06-29T14:45:33Z GooPie4o 265 /* Anschluss */ wikitext text/x-wiki {{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->Storage->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS= |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader] }} Das Modul basiert auf Roland Riegels [http://www.roland-riegel.de/sd-reader/ MMC/SD/SDHC card library] ergänzt um die Anbindung an das Ethersex [[VFS|Virtual File System]]. == Anschluss == [[File:Sdcard adapter schaltung.png|200px|thumb|right|SD-Card Adapter Schaltung]] [[File:Sdcard adapter.jpg|200px|thumb|right|SD-Card Adapter Aufbau]] MMC- und SD-Speicherkarten lassen sich im [[SPI]]-Modus relativ einfach mit einem Mikrocontroller ansteuern. Prinzipiell gibt es zwischen SD-Card und MMC nicht viele Unterschiede, allerdings sind SD-Karten weiter verbreitet, in der Regel schneller als MMCs, und haben ein besser implementiertes SPI-Interface. Es existieren diverse Varianten (miniSD, microSD), die zur normalen SD-Card weitgehend kompatibel sind. Die Karte liest das anliegende Datenbit mit der steigenden Taktflanke ein, als [[SPI]]-Modi eignen sich somit Mode 0 und Mode 3. Bei MMCs ist der SPI-Modus nicht genau spezifiziert, somit kommt es durchaus mal vor, dass der [[SPI]]-Modus je nach Karte unterschiedlich gewählt werden muss. SD-Karten werden typischerweise mit 3,3V und Microcontroller oft mit 5V betrieben. Das erzwingt eine [http://www.mikrocontroller.net/articles/Pegelwandler#5V_.3C-.3E_3.3V Pegelanpassung], weil die Eingangsleitungen zur SD-Karte nicht 5V tolerant sind. Von einer [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#Bekannte_Fehler Pegelanpassung mit Widerständen] wird abgeraten. Die Schaltung rechts nutzt den iC 74HC4050 zur Pegelwandlung. Da dieser IC keine Tri-State-Ausgänge hat blockiert er den SPI auch dann, wenn die SD-Karte nicht selektiert ist. Sofern keine weiteren Komponenten am SPI betrieben werden kann auf Tri-State-Pegelwandler verzichtet werden. Neben den Leitungen, die zur SD-Karte führen, gibt es noch zwei weitere Leitungen, die auf den SD-Karten-Sockel führen: nämlich die card-detect Leitung und die write-protect Leitung. Sie dienen dazu, wie die Namen schon sagen, das physische Vorhandensein einer Karte im SD-Sockel und die Stellung des Schreibschutzschiebers zu signalisieren. Wird Hardware-SPI verwendet, muss nur die chip select Leitung konfiguriert werden. Die card-detect Leitung und die write-protect Leitung sind optional. ifdef(`conf_SD_READER', ` /* port the sd-reader CS is attached to */ pin(SPI_CS_SD_READER, PB2, OUTPUT) /* uncomment and edit this if you have connected the CD (card detect) signal */ pin(SD_READER_AVAILABLE, PD4, INPUT) /* uncomment and edit this if you have connected the WP (write protected) signal */ pin(SD_READER_WR_PROTECT, PD5, INPUT) ') Ein weiteres Problem bei den SD Karten ist die Initialisierung. Schafft es Ethersex nicht in einer bestimmten Zeit zu syncen, so fällt die Karte in den normalen (nicht den SD) Betriebsmodus und kann nicht mehr angesprochen werden. Eine Lösung dafür ist, dass der Karte eine steuerbare Stromversorgung erhält. Dazu definiert man im Pinning nur den Pin pin(SD_READER_POWERON, PB3, OUTPUT) ==== Sockel ==== Eine günstige Art der Kontaktierung ist wohl das Ausschlachten eines billigen Cardreaders, wenn man keine Kabel direkt an die Karte löten möchte. Einzeln gekaufte Steckverbinder sind meist erheblich teuerer.Man kann auch alte [http://uanr.com/sdfloppy/ Floppy-Kabel als günstigen Steckverbinder] benutzen. Teile von AT-Slots oder Verbinder von 5,25-Zoll-Floppys gehen auch. Notfalls kann man die Karte zwischen 2 Reihen Stiftleiste einklemmen (oder anlöten). Noch günstiger geht es wenn man Mikro- oder Mini-SD-Karten benutzt und den meist beigelegten Adapter anlötet. Wer jedoch auf einen Selbstbau verzichten will, kann alternativ für relativ schmales Geld einen [http://www.shop.display3000.com/wichtiges-zubehoer/experimentierplatinen/sd-speicherkartenplatine.html fertig aufgebauten SD-Adapter] zum Anschließen an den AVR käulich erwerben. Bei diesem Adapter ist bereits eine bidirektionale Pegelanpassung zwischen den 5V-Pegeln der Steuerleitungen des AVR und den 3,3V-Pegel der SD-Karte an Bord. == Konfiguration == | | I/O ---> | | ... │ │ Storage ---> │ │ ... | | [*] SD/MMC-Card Reader ---> | | ... | | [ ] SDHC support | | | | [*] VFAT LFN support | | | | [ ] Read-only mode | | | | [*] Use read-timeout | | | | [*] Ping-read SD card every 10s | | | | --- ECMD Support | | | | [*] info | | | | [*] dir | | | | [*] mkdir | | | | [*] rm | | | | --- Debugging Flags | | | | [*] FAT | | | | [*] RAW | | | | [*] VFS | | | | General Setup ---> | | ... | | [*] VFS (Virtual File System) support ---> | | ... | | [*] SD/MMC-Card Filesystem | | == [[ECMD_(Deutsch)|ECMD]] == Das SD-CARD Modul implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle. Siehe [[ECMD_Reference|ECMD Referenz]]. == [[Control6_(Deutsch)|Control6]] == Das folgende Beispiel schreibt Datum, Uhrzeit und Temperatur per VFS_LOG_ALLOCA (VFS_LOG erfordert UIP) in die Datei "temp.log" schreibt sobald sich die Temperatur um mehr als ein Grad zur letzten Messung verändert hat. Für Datum und Uhrzeit muss CLOCK_SUPPORT aktiviert sein. <pre> #include <stdlib.h> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO uint8_t sign = Temperatur<0; div_t res = div(abs(Temperatur),10); VFS_LOG_ALLOCA("temp.log", 50, "%2d.%2d.%4d %2d:%02d %S%d.%d", CLOCK_DAY, CLOCK_MONTH, CLOCK_YEAR, CLOCK_HOUR, CLOCK_MIN, sign?PSTR("-"):PSTR(""),res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> eec7f8a05a7bcf92e34ebe2450b766736ec29267 1091 1090 2013-06-29T14:46:16Z GooPie4o 265 /* Anschluss */ wikitext text/x-wiki {{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->Storage->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS= |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader] }} Das Modul basiert auf Roland Riegels [http://www.roland-riegel.de/sd-reader/ MMC/SD/SDHC card library] ergänzt um die Anbindung an das Ethersex [[VFS|Virtual File System]]. == Anschluss == [[File:Sdcard adapter schaltung.png|200px|thumb|right|SD-Card Adapter Schaltung]] [[File:Sdcard adapter.jpg|200px|thumb|right|SD-Card Adapter Aufbau]] MMC- und SD-Speicherkarten lassen sich im [[SPI]]-Modus relativ einfach mit einem Mikrocontroller ansteuern. Prinzipiell gibt es zwischen SD-Card und MMC nicht viele Unterschiede, allerdings sind SD-Karten weiter verbreitet, in der Regel schneller als MMCs, und haben ein besser implementiertes SPI-Interface. Es existieren diverse Varianten (miniSD, microSD), die zur normalen SD-Card weitgehend kompatibel sind. Die Karte liest das anliegende Datenbit mit der steigenden Taktflanke ein, als [[SPI]]-Modi eignen sich somit Mode 0 und Mode 3. Bei MMCs ist der SPI-Modus nicht genau spezifiziert, somit kommt es durchaus mal vor, dass der [[SPI]]-Modus je nach Karte unterschiedlich gewählt werden muss. SD-Karten werden typischerweise mit 3,3V und Microcontroller oft mit 5V betrieben. Das erzwingt eine [http://www.mikrocontroller.net/articles/Pegelwandler#5V_.3C-.3E_3.3V Pegelanpassung], weil die Eingangsleitungen zur SD-Karte nicht 5V tolerant sind. Von einer [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#Bekannte_Fehler Pegelanpassung mit Widerständen] wird abgeraten. Die Schaltung rechts nutzt den IC 74HC4050 zur Pegelwandlung. Da dieser IC keine Tri-State-Ausgänge hat blockiert er den SPI auch dann, wenn die SD-Karte nicht selektiert ist. Sofern keine weiteren Komponenten am SPI betrieben werden kann auf Tri-State-Pegelwandler verzichtet werden. Neben den Leitungen, die zur SD-Karte führen, gibt es noch zwei weitere Leitungen, die auf den SD-Karten-Sockel führen: nämlich die card-detect Leitung und die write-protect Leitung. Sie dienen dazu, wie die Namen schon sagen, das physische Vorhandensein einer Karte im SD-Sockel und die Stellung des Schreibschutzschiebers zu signalisieren. Wird Hardware-SPI verwendet, muss nur die chip select Leitung konfiguriert werden. Die card-detect Leitung und die write-protect Leitung sind optional. ifdef(`conf_SD_READER', ` /* port the sd-reader CS is attached to */ pin(SPI_CS_SD_READER, PB2, OUTPUT) /* uncomment and edit this if you have connected the CD (card detect) signal */ pin(SD_READER_AVAILABLE, PD4, INPUT) /* uncomment and edit this if you have connected the WP (write protected) signal */ pin(SD_READER_WR_PROTECT, PD5, INPUT) ') Ein weiteres Problem bei den SD Karten ist die Initialisierung. Schafft es Ethersex nicht in einer bestimmten Zeit zu syncen, so fällt die Karte in den normalen (nicht den SD) Betriebsmodus und kann nicht mehr angesprochen werden. Eine Lösung dafür ist, dass der Karte eine steuerbare Stromversorgung erhält. Dazu definiert man im Pinning nur den Pin pin(SD_READER_POWERON, PB3, OUTPUT) ==== Sockel ==== Eine günstige Art der Kontaktierung ist wohl das Ausschlachten eines billigen Cardreaders, wenn man keine Kabel direkt an die Karte löten möchte. Einzeln gekaufte Steckverbinder sind meist erheblich teuerer.Man kann auch alte [http://uanr.com/sdfloppy/ Floppy-Kabel als günstigen Steckverbinder] benutzen. Teile von AT-Slots oder Verbinder von 5,25-Zoll-Floppys gehen auch. Notfalls kann man die Karte zwischen 2 Reihen Stiftleiste einklemmen (oder anlöten). Noch günstiger geht es wenn man Mikro- oder Mini-SD-Karten benutzt und den meist beigelegten Adapter anlötet. Wer jedoch auf einen Selbstbau verzichten will, kann alternativ für relativ schmales Geld einen [http://www.shop.display3000.com/wichtiges-zubehoer/experimentierplatinen/sd-speicherkartenplatine.html fertig aufgebauten SD-Adapter] zum Anschließen an den AVR käulich erwerben. Bei diesem Adapter ist bereits eine bidirektionale Pegelanpassung zwischen den 5V-Pegeln der Steuerleitungen des AVR und den 3,3V-Pegel der SD-Karte an Bord. == Konfiguration == | | I/O ---> | | ... │ │ Storage ---> │ │ ... | | [*] SD/MMC-Card Reader ---> | | ... | | [ ] SDHC support | | | | [*] VFAT LFN support | | | | [ ] Read-only mode | | | | [*] Use read-timeout | | | | [*] Ping-read SD card every 10s | | | | --- ECMD Support | | | | [*] info | | | | [*] dir | | | | [*] mkdir | | | | [*] rm | | | | --- Debugging Flags | | | | [*] FAT | | | | [*] RAW | | | | [*] VFS | | | | General Setup ---> | | ... | | [*] VFS (Virtual File System) support ---> | | ... | | [*] SD/MMC-Card Filesystem | | == [[ECMD_(Deutsch)|ECMD]] == Das SD-CARD Modul implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle. Siehe [[ECMD_Reference|ECMD Referenz]]. == [[Control6_(Deutsch)|Control6]] == Das folgende Beispiel schreibt Datum, Uhrzeit und Temperatur per VFS_LOG_ALLOCA (VFS_LOG erfordert UIP) in die Datei "temp.log" schreibt sobald sich die Temperatur um mehr als ein Grad zur letzten Messung verändert hat. Für Datum und Uhrzeit muss CLOCK_SUPPORT aktiviert sein. <pre> #include <stdlib.h> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO uint8_t sign = Temperatur<0; div_t res = div(abs(Temperatur),10); VFS_LOG_ALLOCA("temp.log", 50, "%2d.%2d.%4d %2d:%02d %S%d.%d", CLOCK_DAY, CLOCK_MONTH, CLOCK_YEAR, CLOCK_HOUR, CLOCK_MIN, sign?PSTR("-"):PSTR(""),res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> 1e0f80077193e5c491d6420ca367cc5335b9c822 1092 1091 2013-06-29T14:48:06Z GooPie4o 265 /* Anschluss */ wikitext text/x-wiki {{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->Storage->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS= |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader] }} Das Modul basiert auf Roland Riegels [http://www.roland-riegel.de/sd-reader/ MMC/SD/SDHC card library] ergänzt um die Anbindung an das Ethersex [[VFS|Virtual File System]]. == Anschluss == [[File:Sdcard adapter schaltung.png|200px|thumb|right|SD-Card Adapter Schaltung]] [[File:Sdcard adapter.jpg|200px|thumb|right|SD-Card Adapter Aufbau]] MMC- und SD-Speicherkarten lassen sich im [[SPI]]-Modus relativ einfach mit einem Mikrocontroller ansteuern. Prinzipiell gibt es zwischen SD-Card und MMC nicht viele Unterschiede, allerdings sind SD-Karten weiter verbreitet, in der Regel schneller als MMCs, und haben ein besser implementiertes SPI-Interface. Es existieren diverse Varianten (miniSD, microSD), die zur normalen SD-Card weitgehend kompatibel sind. Die Karte liest das anliegende Datenbit mit der steigenden Taktflanke ein, als [[SPI]]-Modi eignen sich somit Mode 0 und Mode 3. Bei MMCs ist der SPI-Modus nicht genau spezifiziert, somit kommt es durchaus mal vor, dass der [[SPI]]-Modus je nach Karte unterschiedlich gewählt werden muss. SD-Karten werden typischerweise mit 3,3V und Microcontroller oft mit 5V betrieben. Das erzwingt eine [http://www.mikrocontroller.net/articles/Pegelwandler#5V_.3C-.3E_3.3V Pegelanpassung], weil die Eingangsleitungen zur SD-Karte nicht 5V tolerant sind. Von einer [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#Bekannte_Fehler Pegelanpassung mit Widerständen] wird abgeraten. Neben den Leitungen, die zur SD-Karte führen, gibt es noch zwei weitere Leitungen, die auf den SD-Karten-Sockel führen: nämlich die card-detect Leitung und die write-protect Leitung. Sie dienen dazu, wie die Namen schon sagen, das physische Vorhandensein einer Karte im SD-Sockel und die Stellung des Schreibschutzschiebers zu signalisieren. Wird Hardware-SPI verwendet, muss nur die chip select Leitung konfiguriert werden. Die card-detect Leitung und die write-protect Leitung sind optional. ifdef(`conf_SD_READER', ` /* port the sd-reader CS is attached to */ pin(SPI_CS_SD_READER, PB2, OUTPUT) /* uncomment and edit this if you have connected the CD (card detect) signal */ pin(SD_READER_AVAILABLE, PD4, INPUT) /* uncomment and edit this if you have connected the WP (write protected) signal */ pin(SD_READER_WR_PROTECT, PD5, INPUT) ') Ein weiteres Problem bei den SD Karten ist die Initialisierung. Schafft es Ethersex nicht in einer bestimmten Zeit zu syncen, so fällt die Karte in den normalen (nicht den SD) Betriebsmodus und kann nicht mehr angesprochen werden. Eine Lösung dafür ist, dass der Karte eine steuerbare Stromversorgung erhält. Dazu definiert man im Pinning nur den Pin pin(SD_READER_POWERON, PB3, OUTPUT) ==== Sockel ==== Eine günstige Art der Kontaktierung ist wohl das Ausschlachten eines billigen Cardreaders, wenn man keine Kabel direkt an die Karte löten möchte. Einzeln gekaufte Steckverbinder sind meist erheblich teuerer.Man kann auch alte [http://uanr.com/sdfloppy/ Floppy-Kabel als günstigen Steckverbinder] benutzen. Teile von AT-Slots oder Verbinder von 5,25-Zoll-Floppys gehen auch. Notfalls kann man die Karte zwischen 2 Reihen Stiftleiste einklemmen (oder anlöten). Noch günstiger geht es wenn man Mikro- oder Mini-SD-Karten benutzt und den meist beigelegten Adapter anlötet. Wer jedoch auf einen Selbstbau verzichten will, kann alternativ für relativ schmales Geld einen [http://www.shop.display3000.com/wichtiges-zubehoer/experimentierplatinen/sd-speicherkartenplatine.html fertig aufgebauten SD-Adapter] zum Anschließen an den AVR käulich erwerben. Bei diesem Adapter ist bereits eine bidirektionale Pegelanpassung zwischen den 5V-Pegeln der Steuerleitungen des AVR und den 3,3V-Pegel der SD-Karte an Bord. == Konfiguration == | | I/O ---> | | ... │ │ Storage ---> │ │ ... | | [*] SD/MMC-Card Reader ---> | | ... | | [ ] SDHC support | | | | [*] VFAT LFN support | | | | [ ] Read-only mode | | | | [*] Use read-timeout | | | | [*] Ping-read SD card every 10s | | | | --- ECMD Support | | | | [*] info | | | | [*] dir | | | | [*] mkdir | | | | [*] rm | | | | --- Debugging Flags | | | | [*] FAT | | | | [*] RAW | | | | [*] VFS | | | | General Setup ---> | | ... | | [*] VFS (Virtual File System) support ---> | | ... | | [*] SD/MMC-Card Filesystem | | == [[ECMD_(Deutsch)|ECMD]] == Das SD-CARD Modul implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle. Siehe [[ECMD_Reference|ECMD Referenz]]. == [[Control6_(Deutsch)|Control6]] == Das folgende Beispiel schreibt Datum, Uhrzeit und Temperatur per VFS_LOG_ALLOCA (VFS_LOG erfordert UIP) in die Datei "temp.log" schreibt sobald sich die Temperatur um mehr als ein Grad zur letzten Messung verändert hat. Für Datum und Uhrzeit muss CLOCK_SUPPORT aktiviert sein. <pre> #include <stdlib.h> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO uint8_t sign = Temperatur<0; div_t res = div(abs(Temperatur),10); VFS_LOG_ALLOCA("temp.log", 50, "%2d.%2d.%4d %2d:%02d %S%d.%d", CLOCK_DAY, CLOCK_MONTH, CLOCK_YEAR, CLOCK_HOUR, CLOCK_MIN, sign?PSTR("-"):PSTR(""),res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> 6c1a0e016248059225de7709b2f6c163ee71dbcf 1093 1092 2013-06-29T15:07:33Z GooPie4o 265 /* Control6 */ wikitext text/x-wiki {{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->Storage->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS= |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader] }} Das Modul basiert auf Roland Riegels [http://www.roland-riegel.de/sd-reader/ MMC/SD/SDHC card library] ergänzt um die Anbindung an das Ethersex [[VFS|Virtual File System]]. == Anschluss == [[File:Sdcard adapter schaltung.png|200px|thumb|right|SD-Card Adapter Schaltung]] [[File:Sdcard adapter.jpg|200px|thumb|right|SD-Card Adapter Aufbau]] MMC- und SD-Speicherkarten lassen sich im [[SPI]]-Modus relativ einfach mit einem Mikrocontroller ansteuern. Prinzipiell gibt es zwischen SD-Card und MMC nicht viele Unterschiede, allerdings sind SD-Karten weiter verbreitet, in der Regel schneller als MMCs, und haben ein besser implementiertes SPI-Interface. Es existieren diverse Varianten (miniSD, microSD), die zur normalen SD-Card weitgehend kompatibel sind. Die Karte liest das anliegende Datenbit mit der steigenden Taktflanke ein, als [[SPI]]-Modi eignen sich somit Mode 0 und Mode 3. Bei MMCs ist der SPI-Modus nicht genau spezifiziert, somit kommt es durchaus mal vor, dass der [[SPI]]-Modus je nach Karte unterschiedlich gewählt werden muss. SD-Karten werden typischerweise mit 3,3V und Microcontroller oft mit 5V betrieben. Das erzwingt eine [http://www.mikrocontroller.net/articles/Pegelwandler#5V_.3C-.3E_3.3V Pegelanpassung], weil die Eingangsleitungen zur SD-Karte nicht 5V tolerant sind. Von einer [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#Bekannte_Fehler Pegelanpassung mit Widerständen] wird abgeraten. Neben den Leitungen, die zur SD-Karte führen, gibt es noch zwei weitere Leitungen, die auf den SD-Karten-Sockel führen: nämlich die card-detect Leitung und die write-protect Leitung. Sie dienen dazu, wie die Namen schon sagen, das physische Vorhandensein einer Karte im SD-Sockel und die Stellung des Schreibschutzschiebers zu signalisieren. Wird Hardware-SPI verwendet, muss nur die chip select Leitung konfiguriert werden. Die card-detect Leitung und die write-protect Leitung sind optional. ifdef(`conf_SD_READER', ` /* port the sd-reader CS is attached to */ pin(SPI_CS_SD_READER, PB2, OUTPUT) /* uncomment and edit this if you have connected the CD (card detect) signal */ pin(SD_READER_AVAILABLE, PD4, INPUT) /* uncomment and edit this if you have connected the WP (write protected) signal */ pin(SD_READER_WR_PROTECT, PD5, INPUT) ') Ein weiteres Problem bei den SD Karten ist die Initialisierung. Schafft es Ethersex nicht in einer bestimmten Zeit zu syncen, so fällt die Karte in den normalen (nicht den SD) Betriebsmodus und kann nicht mehr angesprochen werden. Eine Lösung dafür ist, dass der Karte eine steuerbare Stromversorgung erhält. Dazu definiert man im Pinning nur den Pin pin(SD_READER_POWERON, PB3, OUTPUT) ==== Sockel ==== Eine günstige Art der Kontaktierung ist wohl das Ausschlachten eines billigen Cardreaders, wenn man keine Kabel direkt an die Karte löten möchte. Einzeln gekaufte Steckverbinder sind meist erheblich teuerer.Man kann auch alte [http://uanr.com/sdfloppy/ Floppy-Kabel als günstigen Steckverbinder] benutzen. Teile von AT-Slots oder Verbinder von 5,25-Zoll-Floppys gehen auch. Notfalls kann man die Karte zwischen 2 Reihen Stiftleiste einklemmen (oder anlöten). Noch günstiger geht es wenn man Mikro- oder Mini-SD-Karten benutzt und den meist beigelegten Adapter anlötet. Wer jedoch auf einen Selbstbau verzichten will, kann alternativ für relativ schmales Geld einen [http://www.shop.display3000.com/wichtiges-zubehoer/experimentierplatinen/sd-speicherkartenplatine.html fertig aufgebauten SD-Adapter] zum Anschließen an den AVR käulich erwerben. Bei diesem Adapter ist bereits eine bidirektionale Pegelanpassung zwischen den 5V-Pegeln der Steuerleitungen des AVR und den 3,3V-Pegel der SD-Karte an Bord. == Konfiguration == | | I/O ---> | | ... │ │ Storage ---> │ │ ... | | [*] SD/MMC-Card Reader ---> | | ... | | [ ] SDHC support | | | | [*] VFAT LFN support | | | | [ ] Read-only mode | | | | [*] Use read-timeout | | | | [*] Ping-read SD card every 10s | | | | --- ECMD Support | | | | [*] info | | | | [*] dir | | | | [*] mkdir | | | | [*] rm | | | | --- Debugging Flags | | | | [*] FAT | | | | [*] RAW | | | | [*] VFS | | | | General Setup ---> | | ... | | [*] VFS (Virtual File System) support ---> | | ... | | [*] SD/MMC-Card Filesystem | | == [[ECMD_(Deutsch)|ECMD]] == Das SD-CARD Modul implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle. Siehe [[ECMD_Reference|ECMD Referenz]]. == [[Control6_(Deutsch)|Control6]] == Das folgende Beispiel schreibt Datum, Uhrzeit und Temperatur per VFS_LOG_ALLOCA (VFS_LOG erfordert UIP) in die Datei "temp.log" sobald sich die Temperatur um mehr als ein Grad zur letzten Messung verändert hat. Für Datum und Uhrzeit muss CLOCK_SUPPORT aktiviert sein. <pre> #include <stdlib.h> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO uint8_t sign = Temperatur<0; div_t res = div(abs(Temperatur),10); VFS_LOG_ALLOCA("temp.log", 50, "%2d.%2d.%4d %2d:%02d %S%d.%d", CLOCK_DAY, CLOCK_MONTH, CLOCK_YEAR, CLOCK_HOUR, CLOCK_MIN, sign?PSTR("-"):PSTR(""),res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> 82fd254d2a14fd9bad92c6ac6cfb4656763e6040 0 363 1059 2013-06-10T08:03:23Z GooPie4o 265 Created page with "{{i18n|IRMP}} {{Module |NAME=Control6 |MENUCONFIG=General Setup->Control6 script |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS= |REQUIRES=…" wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=Control6 |MENUCONFIG=General Setup->Control6 script |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS= |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/control6 https://github.com/ethersex/ethersex/tree/master/control6] }} e5bfcb86889771b735355e51b548a0e49644bbf9 1060 1059 2013-06-10T08:04:01Z GooPie4o 265 wikitext text/x-wiki {{i18n|Control6}} {{Module |NAME=Control6 |MENUCONFIG=General Setup->Control6 script |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS= |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/control6 https://github.com/ethersex/ethersex/tree/master/control6] }} 67abcd25815bcd024b8116cdee15f74673e43670 0 364 1061 2013-06-10T08:07:46Z GooPie4o 265 Created page with "{{i18n|Control6}} {{Module |NAME=Control6 |MENUCONFIG=General Setup->Control6 script |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS= |REQUI…" wikitext text/x-wiki {{i18n|Control6}} {{Module |NAME=Control6 |MENUCONFIG=General Setup->Control6 script |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS= |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/control6 https://github.com/ethersex/ethersex/tree/master/control6] }} '''Control6''' ist eine auf [http://de.wikipedia.org/wiki/Protothread Protothreads] fußende Art von Skriptsprache, die ein wenig von ''Basic'' inspiriert ist. Control6 soll insbesondere dazu dienen, dass man die einzelnen Komponenten von Ethersex schnell zusammenfügen kann. Beispielsweise können in einer Endlosschleife die Temperaturen von KTY-Sensoren ausgelesen werden und in Abhängigkeit der Werte dann Pins geschaltet, [[SYSLOG]]-Nachrichten abgesetzt oder [[ECMD]]-Befehle versendet werden. Die Skripte werden während des Kompiliervorgangs in C-Code übersetzt und letztlich mit in die Firmware einkompiliert. Sie sind somit ''statisch'' und nur durch Neuprogrammierung änderbar. == So fängt man an == Standardmäßig werden, wenn in Menuconfig die Funktion ''Control6'' aktiviert wurde, die Instruktionen aus der Datei '''control6/control6.src''' in die Firmware eingebunden. Für Eigenentwicklungen, die nicht in die "Distribution" aufgenommen werden sollen, empfiehlt es sich separate Dateien in der Ethersex Ordnerstruktur anzulegen, sodass es zu keinen (oder zumindest seltener) zu Konflikten beim Update auf eine neuere offizielle Firmwareversion kommt. Dazu einfach eine beliebige Datei im Stile der o.g. ''control6.src'' anlegen, zum Beispiel eine ''control6/erste-schritte.src'' und diese dem Makesystem bekannt machen. Letzteres durch folgenden Eintrag in der Datei [[config.mk]] im Hauptverzeichnis (wenn diese noch nicht existiert, einfach eine neue Datei anlegen und nur diese Zeile eintragen): C6_SOURCE = $(TOPDIR)/control6/erste-schritte.src * [[:Category:Control6 Examples|Control6 Beispielcode]] * [[PIN_Commands|Wie schreibe ich ein Control6 Skript]] == Konzepte == * Ein Control6-Skript wird immer von den Tags '''CONTROL_START''' und '''CONTROL_END''' umschlossen. * Mit '''THREAD''' resp. '''THREAD_END''' können leicht quasi nebenläufige Programmabschnitte erstellt werden. Dies ermöglicht mehrere Aufgaben, die miteinander nichts zu tun haben, auch getrennt voneinander im Control6-Code abzubilden. == Befehlssatz == Control6 ist momentan schon relativ mächtig und stellt durchaus eine Alternative zum Verfassen von C-Code dar. Es werden aber nachwievor nicht alle Aspekte von Ethersex auch in Control6 abgebildet und noch weniger werden hier im Wiki bislang thematisiert. * übergreifende Funktionen ** [[Globale Variablen]] ** [[PIN-Befehle]], Threading, Timer und Events ** [[Bedingungen]] * Einzelaspekte, siehe ** [[ADC-Werte abfragen]] ** [[Zugriff auf die Systemuhr]] ** [[Debug-Meldungen und SYSLOG]] ** [[ECMD-Befehle absetzen]] ** [[Jabber]] ** [[eMail versenden]] ** [[Dallas 1-wire Bus]] ** [[KTY81]] ** [[Einfaches Menüsystem|TTY und Menü-System]] ** [[IRMP|IR-Empfänger abfragen]] ** [[TCP-Client als FRITZ!Box Call Monitor]] [[Kategorie:Ethersex]] [[Kategorie:Control6]] c3873896617d30fc99c9ee39dc30c6c02b4c947d 1062 1061 2013-06-10T08:09:03Z GooPie4o 265 wikitext text/x-wiki {{i18n|Control6}} {{Module |NAME=Control6 |MENUCONFIG=General Setup->Control6 script |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=- |REQUIRES=- |TIMER=- |CODE=[https://github.com/ethersex/ethersex/tree/master/control6 https://github.com/ethersex/ethersex/tree/master/control6] }} '''Control6''' ist eine auf [http://de.wikipedia.org/wiki/Protothread Protothreads] fußende Art von Skriptsprache, die ein wenig von ''Basic'' inspiriert ist. Control6 soll insbesondere dazu dienen, dass man die einzelnen Komponenten von Ethersex schnell zusammenfügen kann. Beispielsweise können in einer Endlosschleife die Temperaturen von KTY-Sensoren ausgelesen werden und in Abhängigkeit der Werte dann Pins geschaltet, [[SYSLOG]]-Nachrichten abgesetzt oder [[ECMD]]-Befehle versendet werden. Die Skripte werden während des Kompiliervorgangs in C-Code übersetzt und letztlich mit in die Firmware einkompiliert. Sie sind somit ''statisch'' und nur durch Neuprogrammierung änderbar. == So fängt man an == Standardmäßig werden, wenn in Menuconfig die Funktion ''Control6'' aktiviert wurde, die Instruktionen aus der Datei '''control6/control6.src''' in die Firmware eingebunden. Für Eigenentwicklungen, die nicht in die "Distribution" aufgenommen werden sollen, empfiehlt es sich separate Dateien in der Ethersex Ordnerstruktur anzulegen, sodass es zu keinen (oder zumindest seltener) zu Konflikten beim Update auf eine neuere offizielle Firmwareversion kommt. Dazu einfach eine beliebige Datei im Stile der o.g. ''control6.src'' anlegen, zum Beispiel eine ''control6/erste-schritte.src'' und diese dem Makesystem bekannt machen. Letzteres durch folgenden Eintrag in der Datei [[config.mk]] im Hauptverzeichnis (wenn diese noch nicht existiert, einfach eine neue Datei anlegen und nur diese Zeile eintragen): C6_SOURCE = $(TOPDIR)/control6/erste-schritte.src * [[:Category:Control6 Examples|Control6 Beispielcode]] * [[PIN_Commands|Wie schreibe ich ein Control6 Skript]] == Konzepte == * Ein Control6-Skript wird immer von den Tags '''CONTROL_START''' und '''CONTROL_END''' umschlossen. * Mit '''THREAD''' resp. '''THREAD_END''' können leicht quasi nebenläufige Programmabschnitte erstellt werden. Dies ermöglicht mehrere Aufgaben, die miteinander nichts zu tun haben, auch getrennt voneinander im Control6-Code abzubilden. == Befehlssatz == Control6 ist momentan schon relativ mächtig und stellt durchaus eine Alternative zum Verfassen von C-Code dar. Es werden aber nachwievor nicht alle Aspekte von Ethersex auch in Control6 abgebildet und noch weniger werden hier im Wiki bislang thematisiert. * übergreifende Funktionen ** [[Globale Variablen]] ** [[PIN-Befehle]], Threading, Timer und Events ** [[Bedingungen]] * Einzelaspekte, siehe ** [[ADC-Werte abfragen]] ** [[Zugriff auf die Systemuhr]] ** [[Debug-Meldungen und SYSLOG]] ** [[ECMD-Befehle absetzen]] ** [[Jabber]] ** [[eMail versenden]] ** [[Dallas 1-wire Bus]] ** [[KTY81]] ** [[Einfaches Menüsystem|TTY und Menü-System]] ** [[IRMP|IR-Empfänger abfragen]] ** [[TCP-Client als FRITZ!Box Call Monitor]] [[Kategorie:Ethersex]] [[Kategorie:Control6]] 1af3b34f001d9b3ba94d384b11dda8f2e8e57ea6 1063 1062 2013-06-10T08:11:09Z GooPie4o 265 wikitext text/x-wiki {{i18n|Control6}} {{Module |NAME=Control6 |MENUCONFIG=General Setup->Control6 script |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=- |REQUIRES=- |TIMER=- |CODE=[https://github.com/ethersex/ethersex/tree/master/control6 https://github.com/ethersex/ethersex/tree/master/control6] }} '''Control6''' ist eine auf [http://de.wikipedia.org/wiki/Protothread Protothreads] fußende Art von Skriptsprache, die ein wenig von ''Basic'' inspiriert ist. Control6 soll insbesondere dazu dienen, dass man die einzelnen Komponenten von Ethersex schnell zusammenfügen kann. Beispielsweise können in einer Endlosschleife die Temperaturen von KTY-Sensoren ausgelesen werden und in Abhängigkeit der Werte dann Pins geschaltet, [[SYSLOG_(Deutsch)|SYSLOG]]-Nachrichten abgesetzt oder [[ECMD_(Deutsch)|ECMD]]-Befehle versendet werden. Die Skripte werden während des Kompiliervorgangs in C-Code übersetzt und letztlich mit in die Firmware einkompiliert. Sie sind somit ''statisch'' und nur durch Neuprogrammierung änderbar. == So fängt man an == Standardmäßig werden, wenn in Menuconfig die Funktion ''Control6'' aktiviert wurde, die Instruktionen aus der Datei '''control6/control6.src''' in die Firmware eingebunden. Für Eigenentwicklungen, die nicht in die "Distribution" aufgenommen werden sollen, empfiehlt es sich separate Dateien in der Ethersex Ordnerstruktur anzulegen, sodass es zu keinen (oder zumindest seltener) zu Konflikten beim Update auf eine neuere offizielle Firmwareversion kommt. Dazu einfach eine beliebige Datei im Stile der o.g. ''control6.src'' anlegen, zum Beispiel eine ''control6/erste-schritte.src'' und diese dem Makesystem bekannt machen. Letzteres durch folgenden Eintrag in der Datei [[config.mk_(Deutsch)|config.mk]] im Hauptverzeichnis (wenn diese noch nicht existiert, einfach eine neue Datei anlegen und nur diese Zeile eintragen): C6_SOURCE = $(TOPDIR)/control6/erste-schritte.src * [[:Category:Control6 Examples|Control6 Beispielcode]] * [[PIN_Commands|Wie schreibe ich ein Control6 Skript]] == Konzepte == * Ein Control6-Skript wird immer von den Tags '''CONTROL_START''' und '''CONTROL_END''' umschlossen. * Mit '''THREAD''' resp. '''THREAD_END''' können leicht quasi nebenläufige Programmabschnitte erstellt werden. Dies ermöglicht mehrere Aufgaben, die miteinander nichts zu tun haben, auch getrennt voneinander im Control6-Code abzubilden. == Befehlssatz == Control6 ist momentan schon relativ mächtig und stellt durchaus eine Alternative zum Verfassen von C-Code dar. Es werden aber nachwievor nicht alle Aspekte von Ethersex auch in Control6 abgebildet und noch weniger werden hier im Wiki bislang thematisiert. * übergreifende Funktionen ** [[Globale Variablen]] ** [[PIN-Befehle]], Threading, Timer und Events ** [[Bedingungen]] * Einzelaspekte, siehe ** [[ADC-Werte abfragen]] ** [[Zugriff auf die Systemuhr]] ** [[Debug-Meldungen und SYSLOG]] ** [[ECMD-Befehle absetzen]] ** [[Jabber]] ** [[eMail versenden]] ** [[Dallas 1-wire Bus]] ** [[KTY81]] ** [[Einfaches Menüsystem|TTY und Menü-System]] ** [[IRMP|IR-Empfänger abfragen]] ** [[TCP-Client als FRITZ!Box Call Monitor]] [[Kategorie:Ethersex]] [[Kategorie:Control6]] 90e01795944c33b75c8d5bb11a24930baeba5493 1064 1063 2013-06-10T08:15:15Z GooPie4o 265 /* Befehlssatz */ wikitext text/x-wiki {{i18n|Control6}} {{Module |NAME=Control6 |MENUCONFIG=General Setup->Control6 script |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=- |REQUIRES=- |TIMER=- |CODE=[https://github.com/ethersex/ethersex/tree/master/control6 https://github.com/ethersex/ethersex/tree/master/control6] }} '''Control6''' ist eine auf [http://de.wikipedia.org/wiki/Protothread Protothreads] fußende Art von Skriptsprache, die ein wenig von ''Basic'' inspiriert ist. Control6 soll insbesondere dazu dienen, dass man die einzelnen Komponenten von Ethersex schnell zusammenfügen kann. Beispielsweise können in einer Endlosschleife die Temperaturen von KTY-Sensoren ausgelesen werden und in Abhängigkeit der Werte dann Pins geschaltet, [[SYSLOG_(Deutsch)|SYSLOG]]-Nachrichten abgesetzt oder [[ECMD_(Deutsch)|ECMD]]-Befehle versendet werden. Die Skripte werden während des Kompiliervorgangs in C-Code übersetzt und letztlich mit in die Firmware einkompiliert. Sie sind somit ''statisch'' und nur durch Neuprogrammierung änderbar. == So fängt man an == Standardmäßig werden, wenn in Menuconfig die Funktion ''Control6'' aktiviert wurde, die Instruktionen aus der Datei '''control6/control6.src''' in die Firmware eingebunden. Für Eigenentwicklungen, die nicht in die "Distribution" aufgenommen werden sollen, empfiehlt es sich separate Dateien in der Ethersex Ordnerstruktur anzulegen, sodass es zu keinen (oder zumindest seltener) zu Konflikten beim Update auf eine neuere offizielle Firmwareversion kommt. Dazu einfach eine beliebige Datei im Stile der o.g. ''control6.src'' anlegen, zum Beispiel eine ''control6/erste-schritte.src'' und diese dem Makesystem bekannt machen. Letzteres durch folgenden Eintrag in der Datei [[config.mk_(Deutsch)|config.mk]] im Hauptverzeichnis (wenn diese noch nicht existiert, einfach eine neue Datei anlegen und nur diese Zeile eintragen): C6_SOURCE = $(TOPDIR)/control6/erste-schritte.src * [[:Category:Control6 Examples|Control6 Beispielcode]] * [[PIN_Commands|Wie schreibe ich ein Control6 Skript]] == Konzepte == * Ein Control6-Skript wird immer von den Tags '''CONTROL_START''' und '''CONTROL_END''' umschlossen. * Mit '''THREAD''' resp. '''THREAD_END''' können leicht quasi nebenläufige Programmabschnitte erstellt werden. Dies ermöglicht mehrere Aufgaben, die miteinander nichts zu tun haben, auch getrennt voneinander im Control6-Code abzubilden. == Befehlssatz == Control6 ist momentan schon relativ mächtig und stellt durchaus eine Alternative zum Verfassen von C-Code dar. Es werden aber nachwievor nicht alle Aspekte von Ethersex auch in Control6 abgebildet und noch weniger werden hier im Wiki bislang thematisiert. * übergreifende Funktionen ** [[Globale Variablen]] ** [[PIN-Befehle]], Threading, Timer und Events ** [[Bedingungen]] * Einzelaspekte, siehe ** [[ADC-Werte abfragen]] ** [[Zugriff auf die Systemuhr]] ** [[Debug-Meldungen und SYSLOG]] ** [[ECMD-Befehle absetzen]] ** [[Jabber]] ** [[eMail versenden]] ** [[Dallas 1-wire Bus]] ** [[KTY81]] ** [[Einfaches Menüsystem|TTY und Menü-System]] ** [[IRMP_(Deutsch)|IR-Empfänger abfragen]] ** [[TCP-Client als FRITZ!Box Call Monitor]] [[Kategorie:Ethersex]] [[Kategorie:Control6]] 9c9574595a4a8ce46bedc06166bb07fb3d291ca7 1065 1064 2013-06-10T09:56:09Z GooPie4o 265 wikitext text/x-wiki {{i18n|Control6}} {{Module |NAME=Control6 |MENUCONFIG=General Setup->Control6 script |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=- |REQUIRES=- |TIMER=- |CODE=[https://github.com/ethersex/ethersex/tree/master/control6 https://github.com/ethersex/ethersex/tree/master/control6] }} '''Control6''' ist eine auf [http://de.wikipedia.org/wiki/Protothread Protothreads] fußende Art von Skriptsprache, die ein wenig von ''Basic'' inspiriert ist. Control6 soll insbesondere dazu dienen, dass man die einzelnen Komponenten von Ethersex schnell zusammenfügen kann. Beispielsweise können in einer Endlosschleife die Temperaturen von KTY-Sensoren ausgelesen werden und in Abhängigkeit der Werte dann Pins geschaltet, [[SYSLOG_(Deutsch)|SYSLOG]]-Nachrichten abgesetzt oder [[ECMD_(Deutsch)|ECMD]]-Befehle versendet werden. Die Skripte werden während des Kompiliervorgangs in C-Code übersetzt und letztlich mit in die Firmware einkompiliert. Sie sind somit ''statisch'' und nur durch Neuprogrammierung änderbar. == So fängt man an == Standardmäßig werden, wenn in Menuconfig die Funktion ''Control6'' aktiviert wurde, die Instruktionen aus der Datei '''control6/control6.src''' in die Firmware eingebunden. Für Eigenentwicklungen, die nicht in die "Distribution" aufgenommen werden sollen, empfiehlt es sich separate Dateien in der Ethersex Ordnerstruktur anzulegen, sodass es zu keinen (oder zumindest seltener) zu Konflikten beim Update auf eine neuere offizielle Firmwareversion kommt. Dazu einfach eine beliebige Datei im Stile der o.g. ''control6.src'' anlegen, zum Beispiel eine ''control6/erste-schritte.src'' und diese dem Makesystem bekannt machen. Letzteres durch folgenden Eintrag in der Datei [[config.mk_(Deutsch)|config.mk]] im Hauptverzeichnis (wenn diese noch nicht existiert, einfach eine neue Datei anlegen und nur diese Zeile eintragen): C6_SOURCE = $(TOPDIR)/control6/erste-schritte.src * [[:Kategorie:Control6 Examples|Control6 Beispielcode]] * [[PIN_Commands|Wie schreibe ich ein Control6 Skript]] == Konzepte == * Ein Control6-Skript wird immer von den Tags '''CONTROL_START''' und '''CONTROL_END''' umschlossen. * Mit '''THREAD''' resp. '''THREAD_END''' können leicht quasi nebenläufige Programmabschnitte erstellt werden. Dies ermöglicht mehrere Aufgaben, die miteinander nichts zu tun haben, auch getrennt voneinander im Control6-Code abzubilden. == Befehlssatz == Control6 ist momentan schon relativ mächtig und stellt durchaus eine Alternative zum Verfassen von C-Code dar. Es werden aber nachwievor nicht alle Aspekte von Ethersex auch in Control6 abgebildet und noch weniger werden hier im Wiki bislang thematisiert. * übergreifende Funktionen ** [[Global_Variables_(Deutsch)Globale Variablen]] ** [[PIN_Commands_(Deutsch)|Pin-Befehle]], Threading, Timer und Events ** [[Conditions_(Deutsch)|Bedingungen]] * Einzelaspekte, siehe ** [[ADC-Werte abfragen]] ** [[Zugriff auf die Systemuhr]] ** [[Debug-Meldungen und SYSLOG]] ** [[ECMD-Befehle absetzen]] ** [[Jabber]] ** [[eMail versenden]] ** [[Dallas 1-wire Bus]] ** [[KTY81]] ** [[Einfaches Menüsystem|TTY und Menü-System]] ** [[IRMP_(Deutsch)|IR-Empfänger abfragen]] ** [[TCP-Client als FRITZ!Box Call Monitor]] [[Kategorie:Ethersex]] [[Kategorie:Control6]] baf4578d1083f814d1233281a14c8ecef30b0b55 1066 1065 2013-06-10T09:56:32Z GooPie4o 265 /* Befehlssatz */ wikitext text/x-wiki {{i18n|Control6}} {{Module |NAME=Control6 |MENUCONFIG=General Setup->Control6 script |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=- |REQUIRES=- |TIMER=- |CODE=[https://github.com/ethersex/ethersex/tree/master/control6 https://github.com/ethersex/ethersex/tree/master/control6] }} '''Control6''' ist eine auf [http://de.wikipedia.org/wiki/Protothread Protothreads] fußende Art von Skriptsprache, die ein wenig von ''Basic'' inspiriert ist. Control6 soll insbesondere dazu dienen, dass man die einzelnen Komponenten von Ethersex schnell zusammenfügen kann. Beispielsweise können in einer Endlosschleife die Temperaturen von KTY-Sensoren ausgelesen werden und in Abhängigkeit der Werte dann Pins geschaltet, [[SYSLOG_(Deutsch)|SYSLOG]]-Nachrichten abgesetzt oder [[ECMD_(Deutsch)|ECMD]]-Befehle versendet werden. Die Skripte werden während des Kompiliervorgangs in C-Code übersetzt und letztlich mit in die Firmware einkompiliert. Sie sind somit ''statisch'' und nur durch Neuprogrammierung änderbar. == So fängt man an == Standardmäßig werden, wenn in Menuconfig die Funktion ''Control6'' aktiviert wurde, die Instruktionen aus der Datei '''control6/control6.src''' in die Firmware eingebunden. Für Eigenentwicklungen, die nicht in die "Distribution" aufgenommen werden sollen, empfiehlt es sich separate Dateien in der Ethersex Ordnerstruktur anzulegen, sodass es zu keinen (oder zumindest seltener) zu Konflikten beim Update auf eine neuere offizielle Firmwareversion kommt. Dazu einfach eine beliebige Datei im Stile der o.g. ''control6.src'' anlegen, zum Beispiel eine ''control6/erste-schritte.src'' und diese dem Makesystem bekannt machen. Letzteres durch folgenden Eintrag in der Datei [[config.mk_(Deutsch)|config.mk]] im Hauptverzeichnis (wenn diese noch nicht existiert, einfach eine neue Datei anlegen und nur diese Zeile eintragen): C6_SOURCE = $(TOPDIR)/control6/erste-schritte.src * [[:Kategorie:Control6 Examples|Control6 Beispielcode]] * [[PIN_Commands|Wie schreibe ich ein Control6 Skript]] == Konzepte == * Ein Control6-Skript wird immer von den Tags '''CONTROL_START''' und '''CONTROL_END''' umschlossen. * Mit '''THREAD''' resp. '''THREAD_END''' können leicht quasi nebenläufige Programmabschnitte erstellt werden. Dies ermöglicht mehrere Aufgaben, die miteinander nichts zu tun haben, auch getrennt voneinander im Control6-Code abzubilden. == Befehlssatz == Control6 ist momentan schon relativ mächtig und stellt durchaus eine Alternative zum Verfassen von C-Code dar. Es werden aber nachwievor nicht alle Aspekte von Ethersex auch in Control6 abgebildet und noch weniger werden hier im Wiki bislang thematisiert. * übergreifende Funktionen ** [[Global_Variables_(Deutsch)|Globale Variablen]] ** [[PIN_Commands_(Deutsch)|Pin-Befehle]], Threading, Timer und Events ** [[Conditions_(Deutsch)|Bedingungen]] * Einzelaspekte, siehe ** [[ADC-Werte abfragen]] ** [[Zugriff auf die Systemuhr]] ** [[Debug-Meldungen und SYSLOG]] ** [[ECMD-Befehle absetzen]] ** [[Jabber]] ** [[eMail versenden]] ** [[Dallas 1-wire Bus]] ** [[KTY81]] ** [[Einfaches Menüsystem|TTY und Menü-System]] ** [[IRMP_(Deutsch)|IR-Empfänger abfragen]] ** [[TCP-Client als FRITZ!Box Call Monitor]] [[Kategorie:Ethersex]] [[Kategorie:Control6]] 66471ee7c964c3cbd04375f20c81232122dff426 0 365 1067 2013-06-10T09:58:46Z GooPie4o 265 Created page with "{{i18n|PIN_Commands}} Jedes [[Control6_(Deutsch)|Control6]]-Skript muss mit CONTROL_START beginnen und mit CONTROL_END enden. Dazwischen kannst du verschiedene Aktionen definier…" wikitext text/x-wiki {{i18n|PIN_Commands}} Jedes [[Control6_(Deutsch)|Control6]]-Skript muss mit CONTROL_START beginnen und mit CONTROL_END enden. Dazwischen kannst du verschiedene Aktionen definieren, die mit ACTION($action_name) beginnen und mit ACTION_END($action_name) enden, wobei $action_name durch eine eindeutige Bezeichnung der Aktion ersetzt werden muss. Zwischen den ACTION-Kennzeichnern fügst du den Programmcode für die jeweilige Aktion ein. Außerhalb aller Aktionen schreibst du auf, wie das Control6-Skript auf Ereignisse (Events) reagieren soll. Beispielsweise diesen Programmcode, der außerhalb aller Aktionsblöcke plaziert wird (für das Beispiel musst du "Clock Support" in der Ethersex-Firmware einschalten). <pre>ON CLOCK_MIN == 5 DO THREAD_START(nice_gaudi) END</pre> Hier siehst du, wie ein solcher Event-Handler geschrieben wird. Dieser startet dann, wenn das Minuten-Feld der Zeit genau 5 ist (beispielsweise um 05:05 oder 23:05 Uhr), den Thread "nice_thread". Dabei musst du dir folgender Eigenschaft des THREAD_START-Befehls bewusst sein: Dieser startet den Thread nur dann, wenn er nicht bereits vorher gestartet wurde. Dieser Programmcode startet die Aktion nur beim ersten mal nach Programmstart (falls die Aktion nicht irgendwo mit THREAD_STOP beendet wird). Zusätzlich besteht die Möglichkeit THREAD_RESTART zu verwenden: Bei jedem Aufruf von THREAD_RESTART, wird der Thread neu gestartet. Ein einfaches Beispiel, das dir einige Eigenschaften von Control6 zeigt: <pre> CONTROL_START PIN_INPUT(KEY) PIN_PULLUP(KEY) PIN_OUTPUT(LED) THREAD(nice_gaudi) TIMER_START(new) PIN_SET(LED); TIMER_WAIT(new, 20) PIN_CLEAR(LED); THREAD_END(nice_gaudi) ON CLOCK_MIN == 5 DO THREAD_RESTART(nice_gaudi) END ON PIN_FALLING(KEY) DO THREAD_RESTART(nice_gaudi) END CONTROL_END </pre> * Die typischen Schlüsselwörter CONTROL_START und CONTROL_END umschließen das Control6-Skript. * Die PIN-Befehle: ** Auf welchen Pin sich der Bezeichner PIN_INPUT und die anderen Bezeichner PIN_* beziehen, ist in pinning/*.m4 definiert. Du kannst dort auch deine eigenen Pins hinzufügen. ** PIN_INPUT definiert den Pin KEY pin als Eingabe-Pin (Input), das Register DDRx wird passend gesetzt. ** PIN_PULLUP schaltet den internen Pullup-Widerstand des Mikrocontrollers für den Pin KEY ein, indem das Register PORTx entsprechend gesetzt wird. ** PIN_OUTPUT definiert den Pin LED als Ausgabe-Pin (Output), das Register DDRx wird entsprechend gesetzt. ** PIN_FALLING(KEY) ist ein Event, der durch jede fallende Flanke des Signals am Pin KEY getriggert wird. Entsprechend zu PIN_FALLING, existiert auch der Event PIN_RISING für steigende Flanken. * THREAD und THREAD_END definieren den neuen Thread "nice_gaudi". Innerhalb dieses Threads wird ein Timer gestartet. (Durch den ersten Aufruf von TIMER_START wird gleichzeitig der Timer erzeugt, doch außerdem kann der Timer auch durch TIMER_NEW erzeugt werden). Nachdem der Timer gestartet wird, wird der Pin LED gesetzt. * Durch TIMER_WAIT wird gewartet, bis der erzeugte Timer 20 Sekunden erreicht hat. Danach wird der Pin LED gelöscht. Beachte die Semikola ";" am Ende der Zeilen PIN_SET und PIN_CLEAR. Dies wird benötigt, da diese Zeilen nicht mit M4 interpretiert werden sondern als einfacher C-Code (über CPP-Makros). * Die beiden ON-Kommandos starten den Thread "nice_gaudi" entweder wenn das Minutenfeld der Uhr "5" beträgt (beachte den RESTART) oder eine fallende Flanke am Pin KEY auftritt. [[Category:Control6 Examples]] 1ad96518069432857c4063c6496b2929ef1c732b 0 366 1068 2013-06-11T13:17:50Z Dg9oaa 103 Elektrisches Heben und Senken eines Amateurfunk Mastes wikitext text/x-wiki Hier entsteht eine Beschreibung zur Drehstrommotor Steuerung zum Heben und Senken eines Amateurfunk Mastes e16438aa5f461c77d30018c65880ab88a39dd02e 1082 1068 2013-06-26T15:05:26Z Dg9oaa 103 Mast Steuerung wikitext text/x-wiki {{i18n|Tower}} {{Module |NAME=VersaTower control |MENUCONFIG={{I/O}}->VersaTower control |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] (optional) |REQUIRES= - |CODE=[?] }} Die Mast Steuerung wird per ECMD Kommandos angesprochen. Am Mast befindet sich bei mir eine SPS und ein Drehstrommotor an einer Seilwinde. Die SPS fragt die Endschalter ab und steuert die Wendeschütze. Die SPS wird neben der Handsteuerung vom Etherrape Board angesteuert. Die Steuerung kann somit den Mast senken und heben. Die Ethersex Tower Software wird per ECMD Kommando angesprochen. * tower power 1 schaltet per Relais/Schütz den Drehstrom ein. * tower power 0 macht alles stromlos. Um "Kabelbruch Sicher" zu sein, wird zyklisch das Kommando tower up bzw. down mit einer Zeiteinheit abgesetzt. Die Zeiteinheit z.B. 250ms bewirkt, dass nach 250 ms nach dem Absenden des Kommandos, das Schaltsignal zum Heben oder Senken beendet wird. Wird innerhalb der 250 ms ein weiteres gleiches Kommando abgesetzt, verlängert sich das Schaltsignal zum Heben oder Senken. Per Android App kann nun relativ Sicher der Mast bewegt werden. Fällt die Verbindung zwischen Frontend und Ethersex Baord aus, wird nach Ablauf der Zeiteinheit die SPS nicht mehr angesteuert. == Pinning == Die drei Ausgänge werden in der Datei ''pinning/hardware/<your board>.m4'' beschrieben. ifdef(`conf_TOWERLILO', ` pin(TOWER_LIFT, PC0, OUTPUT) pin(TOWER_LOWER, PC1, OUTPUT) pin(TOWER_POWER, PC2, OUTPUT) ') == ECMD Commands == {| border=1 cellspacing=0 padding=4 class=wikitable ! width="25%" | Command ! Function |- |tower ''power n''|| schaltet die Stromversorgung an (n=1) bzw aus (n=0) |- |- |tower ''status''|| gibt den Status aus |- |- |tower ''up time''|| heben Zeit in ms |- |- |tower ''down time''|| senken Zeit in ms |- |- 9f856a304a31a66964b60da51bb695d962c2c145 0 367 1069 2013-06-11T13:20:40Z Dg9oaa 103 Created page with "Hier entsteht eine Beschreibung zur softwaremäßigen Steuerung eines Rotor-Steuergerätes" wikitext text/x-wiki Hier entsteht eine Beschreibung zur softwaremäßigen Steuerung eines Rotor-Steuergerätes f2f4ee22488886b9578c58644fbdc1d92a09ba5c 1078 1069 2013-06-26T13:49:18Z Dg9oaa 103 Rotor Steuerung wikitext text/x-wiki {{i18n|Frequency Counter}} {{Module |NAME=Rotor Steuerung |MENUCONFIG={{I/O}}->Rotor via HamLib |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] (optional) |REQUIRES= - |CODE=[?] }} Die Rotor Steuerung kann per ECMD Kommandos angesprochen werden. Der Rotor kann in beide Richtungen drehen. Zur primären Verwendung kommt der HAM 4. Dieser Rotor besitzt eine mechanische Bremse. Um ihn zu drehen benötigte der Rotor die Freigabe der Bremse und die Drehrichtung (cw oder ccw). == Pinning == * Die drei Ausgänge CW, CCW, und BREAK weden in der Datei ''pinning/hardware/<your board>.m4'' beschrieben. ifdef(`conf_ROTORHAMLIB', ` pin(ROTOR_CW, PC3, OUTPUT) pin(ROTOR_CCW, PC4, OUTPUT) pin(ROTOR_BREAK, PC5, OUTPUT) ') == ECMD Commands == {| border=1 cellspacing=0 padding=4 class=wikitable ! width="25%" | Command ! Function |- |rotor ''move''|| Angabe von Winkel und Geschwindigkeit in % |- |- |rotor ''status''|| gibt Drehrichtung, Winkel und Geschwindigkeit aus |- |- |rotor ''cw''|| dreht den Rotor im Uhrzeigersinn |- |- |rotor ''ccw''|| dreht den Rotor gegen den Uhrzeigersinn |- |- |rotor ''stop''|| hält den Rotor sofort an |- |- |rotor ''park''|| dreht den Rotor in die Park Position |- |- |rotor ''setparkpos''|| Speicherung der Park Position als Winkel (0-360) |- |- |rotor ''calibrate''|| Angabe der min und max Grenzwerte für die Analog-Digital Wandlung |- |- |rotor ''get calibrate''|| gibt die Grenzwerte aus |- |- f4eac8d621fe93feb2543241870eb1afca1ea1ac 1079 1078 2013-06-26T13:55:53Z Dg9oaa 103 wikitext text/x-wiki {{i18n|Rotor Steuerung}} {{Module |NAME=Rotor Steuerung |MENUCONFIG={{I/O}}->Rotor via HamLib |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] (optional) |REQUIRES= - |CODE=[?] }} Die Rotor Steuerung kann per ECMD Kommandos angesprochen werden. Der Rotor kann in beide Richtungen drehen. Zur primären Verwendung kommt der HAM 4. Dieser Rotor besitzt eine mechanische Bremse. Um ihn zu drehen benötigte der Rotor die Freigabe der Bremse und die Drehrichtung (cw oder ccw). == Pinning == * Die drei Ausgänge CW, CCW, und BREAK weden in der Datei ''pinning/hardware/<your board>.m4'' beschrieben. ifdef(`conf_ROTORHAMLIB', ` pin(ROTOR_CW, PC3, OUTPUT) pin(ROTOR_CCW, PC4, OUTPUT) pin(ROTOR_BREAK, PC5, OUTPUT) ') == ECMD Commands == {| border=1 cellspacing=0 padding=4 class=wikitable ! width="25%" | Command ! Function |- |rotor ''move''|| Angabe von Winkel und Geschwindigkeit in % |- |- |rotor ''status''|| gibt Drehrichtung, Winkel und Geschwindigkeit aus |- |- |rotor ''cw''|| dreht den Rotor im Uhrzeigersinn |- |- |rotor ''ccw''|| dreht den Rotor gegen den Uhrzeigersinn |- |- |rotor ''stop''|| hält den Rotor sofort an |- |- |rotor ''park''|| dreht den Rotor in die Park Position |- |- |rotor ''setparkpos''|| Speicherung der Park Position als Winkel (0-360) |- |- |rotor ''calibrate''|| Angabe der min und max Grenzwerte für die Analog-Digital Wandlung |- |- |rotor ''get calibrate''|| gibt die Grenzwerte aus |- |- b3622acc883702a5a48189a63d764cdf36e3d3d3 1080 1079 2013-06-26T14:00:28Z Dg9oaa 103 wikitext text/x-wiki {{i18n|Rotor}} {{Module |NAME=Rotor Steuerung |MENUCONFIG={{I/O}}->Rotor via HamLib |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] (optional) |REQUIRES= - |CODE=[?] }} Die Rotor Steuerung kann per ECMD Kommandos angesprochen werden. Der Rotor kann in beide Richtungen drehen. Zur primären Verwendung kommt der HAM 4. Dieser Rotor besitzt eine mechanische Bremse. Um ihn zu drehen benötigte der Rotor die Freigabe der Bremse und die Drehrichtung (cw oder ccw). == Pinning == * Die drei Ausgänge CW, CCW, und BREAK weden in der Datei ''pinning/hardware/<your board>.m4'' beschrieben. ifdef(`conf_ROTORHAMLIB', ` pin(ROTOR_CW, PC3, OUTPUT) pin(ROTOR_CCW, PC4, OUTPUT) pin(ROTOR_BREAK, PC5, OUTPUT) ') == ECMD Commands == {| border=1 cellspacing=0 padding=4 class=wikitable ! width="25%" | Command ! Function |- |rotor ''move''|| Angabe von Winkel und Geschwindigkeit in % |- |- |rotor ''status''|| gibt Drehrichtung, Winkel und Geschwindigkeit aus |- |- |rotor ''cw''|| dreht den Rotor im Uhrzeigersinn |- |- |rotor ''ccw''|| dreht den Rotor gegen den Uhrzeigersinn |- |- |rotor ''stop''|| hält den Rotor sofort an |- |- |rotor ''park''|| dreht den Rotor in die Park Position |- |- |rotor ''setparkpos''|| Speicherung der Park Position als Winkel (0-360) |- |- |rotor ''calibrate''|| Angabe der min und max Grenzwerte für die Analog-Digital Wandlung |- |- |rotor ''get calibrate''|| gibt die Grenzwerte aus |- |- bfdceb0a5720b451868d10023e45fc92969e1481 1081 1080 2013-06-26T14:31:50Z Dg9oaa 103 wikitext text/x-wiki {{i18n|Rotor}} {{Module |NAME=Rotor Steuerung |MENUCONFIG={{I/O}}->Rotor via HamLib |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] (optional) |REQUIRES= - |CODE=[?] }} Die Rotor Steuerung kann per ECMD Kommandos angesprochen werden. Zur primären Verwendung kommt der HAM 4. Dieser Rotor besitzt eine mechanische Bremse. Um ihn zu drehen benötigte der Rotor die Freigabe der Bremse und die Drehrichtung (cw oder ccw). == Pinning == Die drei Ausgänge CW, CCW, und BREAK weden in der Datei ''pinning/hardware/<your board>.m4'' beschrieben. ifdef(`conf_ROTORHAMLIB', ` pin(ROTOR_CW, PC3, OUTPUT) pin(ROTOR_CCW, PC4, OUTPUT) pin(ROTOR_BREAK, PC5, OUTPUT) ') Für den Analogwert wird AD Wandler 0 (bzw. der erste) verwendet == Konfiguration == Über den ersten AD Wandler wird die Richtung/Winkel des Rotors ermittelt. Bei den meisten Rotoren wird ein Potentiometer zur Richtungsanzeige verwendet. Diese Spannung wird abgegriffen und dem AD Wandler zu geführt. Achtung, der AD Wandler läuft nur zwischen 0 bis 5 Volt. Meist ist die/der Spannung/Widerstand bei einem Winkel von 0 Grad nicht Null sondern etwas höher. Um der Steuerung mitzuteilen bei welchem Eingangspegel 0 Grad und 360 Grad ist, kann der AD Wert für 0 und 360 Grad gespeichert werden. Der Rotor wird von Hand auf 0 Grad gedreht und mittels Kommando 'rotor status' wird der AD Wandler Wert abgefragt und notiert. Nachdem der Rotor auch bei 360 Grad seinen Status ausgegeben hat, werden beide Werte per Kommando 'rotor calibrate min max' im EEPROM abgespeichert. * Ein Beispiel rotor calibrate 75 950 (maximal Wert ist 1023) == ECMD Commands == {| border=1 cellspacing=0 padding=4 class=wikitable ! width="25%" | Command ! Function |- |rotor ''move''|| Angabe von Winkel und Geschwindigkeit in % |- |- |rotor ''status''|| gibt Drehrichtung, Winkel und Geschwindigkeit aus |- |- |rotor ''cw''|| dreht den Rotor im Uhrzeigersinn |- |- |rotor ''ccw''|| dreht den Rotor gegen den Uhrzeigersinn |- |- |rotor ''stop''|| hält den Rotor sofort an |- |- |rotor ''park''|| dreht den Rotor in die Park Position |- |- |rotor ''setparkpos''|| Speicherung der Park Position als Winkel (0-360) |- |- |rotor ''calibrate''|| Angabe der min und max Grenzwerte für die Analog-Digital Wandlung |- |- |rotor ''get calibrate''|| gibt die Grenzwerte aus |- |- 36850e8c9ade93ccc76430565cab8d4eb3a75001 1095 1081 2013-07-01T09:13:41Z Dg9oaa 103 wikitext text/x-wiki {{i18n|Rotor}} {{Module |NAME=Rotor Steuerung |MENUCONFIG={{I/O}}->Rotor via HamLib |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] (optional) |REQUIRES= - |CODE=[?] }} Die Rotor Steuerung kann per ECMD Kommandos angesprochen werden. Zur primären Verwendung kommt der HAM 4. Dieser Rotor besitzt eine mechanische Bremse. Um ihn zu drehen benötigte der Rotor die Freigabe der Bremse und die Drehrichtung (cw oder ccw). == Pinning == Die drei Ausgänge CW, CCW, und BREAK weden in der Datei ''pinning/hardware/<your board>.m4'' beschrieben. ifdef(`conf_ROTORHAMLIB', ` pin(ROTOR_CW, PC3, OUTPUT) pin(ROTOR_CCW, PC4, OUTPUT) pin(ROTOR_BREAK, PC5, OUTPUT) ') Für den Analogwert wird AD Wandler 0 (bzw. der erste) verwendet == Konfiguration == Über den ersten AD Wandler wird die Richtung/Winkel des Rotors ermittelt. Bei den meisten Rotoren wird ein Potentiometer zur Richtungsanzeige verwendet. Diese Spannung wird abgegriffen und dem AD Wandler zu geführt. Achtung, der AD Wandler läuft nur zwischen 0 bis 5 Volt. Meist ist die/der Spannung/Widerstand bei einem Winkel von 0 Grad nicht Null sondern etwas höher. Um der Steuerung mitzuteilen bei welchem Eingangspegel 0 Grad und 360 Grad ist, kann der AD Wert für 0 und 360 Grad gespeichert werden. Der Rotor wird von Hand auf 0 Grad gedreht und mittels Kommando 'rotor status' wird der AD Wandler Wert abgefragt und notiert. Nachdem der Rotor auch bei 360 Grad seinen Status ausgegeben hat, werden beide Werte per Kommando 'rotor calibrate min max' im EEPROM abgespeichert. * Ein Beispiel rotor calibrate 75 950 (maximal Wert ist 1023) == Steuergerät vom Ham4 == [[File:RotorSG1.jpg|vor dem Einbau|300px]] == ECMD Commands == {| border=1 cellspacing=0 padding=4 class=wikitable ! width="25%" | Command ! Function |- |rotor ''move''|| Angabe von Winkel und Geschwindigkeit in % |- |- |rotor ''status''|| gibt Drehrichtung, Winkel und Geschwindigkeit aus |- |- |rotor ''cw''|| dreht den Rotor im Uhrzeigersinn |- |- |rotor ''ccw''|| dreht den Rotor gegen den Uhrzeigersinn |- |- |rotor ''stop''|| hält den Rotor sofort an |- |- |rotor ''park''|| dreht den Rotor in die Park Position |- |- |rotor ''setparkpos''|| Speicherung der Park Position als Winkel (0-360) |- |- |rotor ''calibrate''|| Angabe der min und max Grenzwerte für die Analog-Digital Wandlung |- |- |rotor ''get calibrate''|| gibt die Grenzwerte aus |- |- 78fd760bcab76deb3ef532fd1c6f630156ab7486 0 360 1076 1031 2013-06-22T13:50:31Z GooPie4o 265 /* Configuration */ wikitext text/x-wiki {{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader] }} == Connection == == Configuration == | | I/O ---> | | ... │ │ Storage ---> │ │ ... | | [*] SD/MMC-Card Reader ---> | | ... | | [ ] SDHC support | | | | [*] VFAT LFN support | | | | [ ] Read-only mode | | | | [*] Use read-timeout | | | | [*] Ping-read SD card every 10s | | | | --- ECMD Support | | | | [*] info | | | | [*] dir | | | | [*] mkdir | | | | [*] rm | | | | --- Debugging Flags | | | | [*] FAT | | | | [*] RAW | | | | [*] VFS | | | | General Setup ---> | | ... | | [*] VFS (Virtual File System) support ---> | | ... | | [*] SD/MMC-Card Filesystem | | == [[ECMD|ECMD]] == == [[Control6|Control6]] == 244b1d4e2699af9fbc2200df5966e1e1a76b0e53 0 368 1083 2013-06-28T11:16:44Z GooPie4o 265 Created page with "{{i18n|Bluetooth}} {{Module |NAME=Bluetooth |MENUCONFIG={{I/O}}->Radio->Bluetooth |STATUS={{In_Development}} |PINNING=yes |ECMD= - |CONTROL6= - |DEPENDS= - |REQUIRES= - |TIMER= …" wikitext text/x-wiki {{i18n|Bluetooth}} {{Module |NAME=Bluetooth |MENUCONFIG={{I/O}}->Radio->Bluetooth |STATUS={{In_Development}} |PINNING=yes |ECMD= - |CONTROL6= - |DEPENDS= - |REQUIRES= - |TIMER= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/bluetooth https://github.com/ethersex/ethersex/tree/master/hardware/radio/bluetooth] }} 597753d3608d72b5bf7692ad1083751fa2b9d1f9 0 338 1084 1042 2013-06-28T11:17:50Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{I/O}}->Radio->RFM12 ASK->433MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} In ASK mode the RFM12 module ist used to switch radio outlets. Alternatively you can also receive the radio transmission between the transmitter and radio socket outlet. Currently, the following systems are supported: * Self-learning systems (drive "tevion") * Systems based on the chips or PT2262/PT2272 HX2262/2272 (driver "2272") * Concealed remote dimmer with the transmitter located HS1527 chip (driver "1527") * Transmitter type Intertechno ITS-150 * Oase Inscenio FM Master system == Connection == The RFM12 is connected to the AVRlike in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FFIT signal (Pin 4) is connected to one of the INT pins of the AVR. This modul does not work in interrupt mode, so the output nRQ signal (Pin 2) can be left unconnected. The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_ASK_SENSE_USE_INT(0) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_ASK_SENSE_USE_INT defines whether FFIT is connected to INT0, INT1 or INT2 of the AVR. == Configuration == | | I/O ---> | | ... | | [*] RFM12 ASK ---> | | ... | | [*] 433MHz | | | | (0) RFM12 select | | | | [ ] Pollin/Kangtai Powerswitch (IC 2272) | | | | [ ] Pollin Powerswitch buried (IC 1527) | | | | [*] Tevion Powerswitch | | | | [ ] Intertechno ITS-150 | | | | [*] Oase FM Master | | | | [ ] External filter | | | | [-] Sensing | | == [[ECMD]] == RFM12 ASK implements an [[ECMD]] interface to control to switch radio outlets. See [[ECMD_Reference|ECMD reference]]. [[Category:RFM12]] 57a4daaf7ca081855539d7533fdd9a3a4b3baf72 1089 1084 2013-06-28T20:19:03Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{I/O}}->Radio->RFM12 ASK->433MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} In ASK mode the RFM12 module ist used to switch radio outlets. Alternatively you can also receive the radio transmission between the transmitter and radio socket outlet. Currently, the following systems are supported: * Self-learning systems (drive "tevion") * Systems based on the chips or PT2262/PT2272 HX2262/2272 (driver "2272") * Concealed remote dimmer with the transmitter located HS1527 chip (driver "1527") * Transmitter type Intertechno ITS-150 * Oase Inscenio FM Master system == Connection == The RFM12 is connected to the AVRlike in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FFIT signal (Pin 4) is connected to one of the INT pins of the AVR. This modul does not work in interrupt mode, so the output nRQ signal (Pin 2) can be left unconnected. The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_ASK_SENSE_USE_INT(0) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_ASK_SENSE_USE_INT defines whether FFIT is connected to INT0, INT1 or INT2 of the AVR. == Configuration == | | I/O ---> | | ... | | Radio ---> | | ... | | [*] RFM12 ASK ---> | | ... | | [*] 433MHz | | | | (0) RFM12 select | | | | [ ] Pollin/Kangtai Powerswitch (IC 2272) | | | | [ ] Pollin Powerswitch buried (IC 1527) | | | | [*] Tevion Powerswitch | | | | [ ] Intertechno ITS-150 | | | | [*] Oase FM Master | | | | [ ] External filter | | | | [-] Sensing | | == [[ECMD]] == RFM12 ASK implements an [[ECMD]] interface to control to switch radio outlets. See [[ECMD_Reference|ECMD reference]]. [[Category:RFM12]] 0437cd21c8af0ef7aaaa8a2a6722046d663cbc6d 0 156 1085 991 2013-06-28T11:18:10Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{I/O}}->Radio->RFM12 ASK->433MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} RFM12 ASK schaltet Funksteckdosen verschiedener Hersteller. == Unterstützte Systeme == ===Tevion=== Funksteckdosen mit einer 'Anlern-Taste' können mit Hilfe des LERN-Buttons auf der embeded Website des etherrapes */rf.ht auf den gesendeten Hauscode programmiert werden. Erstaunlicherweise können mit diesem Modul auch die Codes der X10 Fernbedienung von Pollin gesendet werden. Eine Code-Sammlung gibts [[X10-codes|hier]]. [[Category:RFM12]] Getestet: * Tevion * MMANDOLYN LIBRA GmbH, Model No. WRC001 * X10 Pollin Best.Nr. 721 379 ===Intertechno (ITS-150)=== Bei Sender vom Typ Intertechno ITS-150 wird über einen Drehschalter auf der Rückseite der Familiencode eingestellt. Auf der Vorderseite gibt es einen Schieberegler für die Auswahl von Gruppe 1-4 sowie Ein/Aus Knöpfe für die Geräte 1-4 (siehe Bild). Die zusätzlich vorhandenen Gruppentaste funktioniert mit den Empfängern Intertechno CMR-500 nicht (deshalb nicht implementiert). [[Image:Intertechno-its150.jpg|150px]] ===2272=== Diese Steckdosen werden üblicherweise über einen Block von 10 DIP-Switches konfiguriert. Dabei wird mit den ersten fünf Schaltern der Hauscode gesetzt. Es ergeben sich also 32 mögliche Einstellungen. Die übrigen fünf Schalter geben die Adresse der Steckdose an. Bei Verwendung des mitgelieferten Senders wird jeweils einer der Adressschalter auf "1" gesetzt: In Dose A setzt man Dip 6 auf '1'; in Dose B Dip 7 auf '1'... Bei Ansteuerung mit dem Ethersex-System besteht diese Einschränkung nicht, so dass hier 32 verschiedene Adressen möglich sind. Getestet: {|class=wikitable |[http://www.elro.eu/uploads/products/img/_w200/AB440RA_1.jpg] |[[Image:Duewiaktor.jpg|134px]] |[[Image:Globusaktoren.jpg|134px]] |[[Image:Kangtai2605.jpg|101px]] |[[Image:Kangtai6899s.jpg|100px]] |- |valign=top|ELRO AB440R |valign=top|Düwi Modell 0369-3 |valign=top|Kangtai<br>v. Globus |valign=top|Kangtai<br>Model 2605 |valign=top|Kangtai<br>Model 6899s<br>[[Warnung vor Kangtai 6899s|'''Warnung!''']] |- |Delay 100 |Delay 60 |Delay 72 |Delay 72 |Delay 72 |} === 1527 === Anlernbare Unterputz-Dimmer (zB. Pollin Funkdimmerset FD-UP003) mit Fernbedienung. Die mitgelieferte Fernbedienung besitzt einen HS1527 Encoder (baugleich RT1527/ EV1527/FP1527/SC1527). Der gesendete Code bestehtaus 24 Bits, welche per ASK gesendet werden. Davon sind die ersten 20 Bits fest programmiert - der Hauscode sozusagen. Die letzten 4 Bits sind der eigentliche Schalt-Befehl. Getestet: {|class=wikitable |[[Image:FD-UP003.jpg‎|150px|Pollin Electronic FD-UP003]] |- |valign=top|Pollin FD-UP003<br>[[Hinweis FD-UP003|'''Hinweis!''']] |} === Oase Inscenio FM Master === Das Baukastensystem für Gartensteckdosen der Serie [http://www.oase-livingwater.com/de_DE/wasser-garten/produkte/illumination-und-strom/strommanagement/inscenio.html InScenio] organisiert die gesamte Garten- und Teichtechnik. == Anschluss == == Konfiguration == == [[ECMD]] == RFM12 ASK implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle zur Steuerung von Funksteckdosen. Siehe [[ECMD_Reference|ECMD Referenz]]. cc9373013c942267dadd62d4d1dc0664856e1bcb 0 312 1086 1047 2013-06-28T11:18:31Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->Radio->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |TIMER={{occupies_timer|2}} (RX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} The FS20 / FHT system by ELV is currently the most successful wireless home control system in the low cost sector. This arises from the large number of components and the continuous expansion of the system. But the relatively low price, the comprehensive home control systems far below the price of such EIB systems permits, plays a crucial role. This modul is based on [http://culfw.de CULFW by Rudolf Koenig] and supports a wide range of protocols: * FS20: send/receive<br>There are numerous FS20 devices, all of them are fully supported. * FHT: send/receive<br>Communication to the FHT80b is supported. * S300: receive<br>Examples of such devices: S300TH, KS300-2 * EM1000: receive<br>Devices: EM1000FM, EM1000GZ, EM1000WZ * HMS: receive<br>Devices: There are numerous HMS devices, all of them are fully supported. * ESA2000: receive * Lacrosse TX2/TX3: receive == Connection == The RFM12 is connected to the AVR like in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FSK/DATA/nFSS signal (Pin 3) is connected to one of the INT pins of the AVR. This modul does not work in interrupt mode, so the output nRQ signal (Pin 2) can be left unconnected. The software uses the digital filter of the RFM12. To improve sensitivity on short and long distances the [http://jeelabs.net/projects/cafe/wiki/Receiving_OOKASK_with_a_modified_RFM12B C_arssi capacitor needs to be replaced] with a value 150 pf. The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_FS20_USE_INT(1) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_FS20_USE_INT defines whether FSK/DATA/nFSS is connected to INT0, INT1 or INT2 of the AVR. == Configuration == The FS20 system sends on 868,35 MHz, so the 868MHz option is the right one. | | I/O ---> | | ... | | [*] RFM12 ASK ---> | | ... | | [ ] 433MHz | | | | [-] Pollin/Kangtai Powerswitch (IC 2272) | | | | [-] Pollin Powerswitch buried (IC 1527) | | | | [-] Tevion Powerswitch | | | | [-] Intertechno ITS-150 | | | | [-] External filter | | | | [-] Sensing | | | | --- | | | | [*] 868MHz | | | | (0) RFM12 select | | | | [*] FS20 send | | | | [*] FS20 receive | | | | [*] FHT | | | | [*] ESA | | | | [ ] TX3 | | | | [ ] Send received data via syslog | | | | --- Debugging Flags | | | | [-] Sensing | | | | [ ] FS20 | | The modul uses Timer 2 of the AVR '''exclusively'''. Currently there is no option to use Timer 1, but this will change in the future. == [[ECMD]] == RFM12 FS20 implements an [[ECMD]] interface for send and receive FS20/FHT commands. The received data is formatted as described in the [http://culfw.de/commandref.html#protocol2 CULFW reference]. See [[ECMD_Reference|ECMD reference]] for a command list. == Troubleshooting == It may happen that not all of the RFM12 FS20 sensors are received. Here are some points that may help to improve reception: * Location: ** Avoid RF transmitter near the RFM12 ** Choose a position in the center of the sensors * Antenna: ** It is recommended to choose an antenna with a length not shorter than Lamda/2 (17,3cm) * Bandwidth: Default 400kHz ** Can be changed via ECMD from 400kHz to 67kHz (rfm12 setbandwidth <modulnumber> 1-6) * Gain: Default -14dB ** Can be changed via ECMD from 0dB to -20dB (rfm12 setgain <modulnumber> 0-3) * DRSSI: Default -97dB ** Can be changed via ECMD from -103dB to -61dB (rfm12 setdrssi <modulnumber> 0-7) Checkout the RFM12 datasheet for details on bandwidth, gain and DRSSI. == Decoding received data == The received data is formatted as described in the [http://culfw.de/commandref.html#protocol2 CULFW reference]. One could use the perl scripts from [http://culfw.de/ CULFW] to decode the data. [[Category:RFM12]] 6c9d4de117a7c5dcfb86f2737059d62b91724387 1088 1086 2013-06-28T20:18:03Z GooPie4o 265 /* Configuration */ wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->Radio->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |TIMER={{occupies_timer|2}} (RX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} The FS20 / FHT system by ELV is currently the most successful wireless home control system in the low cost sector. This arises from the large number of components and the continuous expansion of the system. But the relatively low price, the comprehensive home control systems far below the price of such EIB systems permits, plays a crucial role. This modul is based on [http://culfw.de CULFW by Rudolf Koenig] and supports a wide range of protocols: * FS20: send/receive<br>There are numerous FS20 devices, all of them are fully supported. * FHT: send/receive<br>Communication to the FHT80b is supported. * S300: receive<br>Examples of such devices: S300TH, KS300-2 * EM1000: receive<br>Devices: EM1000FM, EM1000GZ, EM1000WZ * HMS: receive<br>Devices: There are numerous HMS devices, all of them are fully supported. * ESA2000: receive * Lacrosse TX2/TX3: receive == Connection == The RFM12 is connected to the AVR like in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FSK/DATA/nFSS signal (Pin 3) is connected to one of the INT pins of the AVR. This modul does not work in interrupt mode, so the output nRQ signal (Pin 2) can be left unconnected. The software uses the digital filter of the RFM12. To improve sensitivity on short and long distances the [http://jeelabs.net/projects/cafe/wiki/Receiving_OOKASK_with_a_modified_RFM12B C_arssi capacitor needs to be replaced] with a value 150 pf. The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_FS20_USE_INT(1) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_FS20_USE_INT defines whether FSK/DATA/nFSS is connected to INT0, INT1 or INT2 of the AVR. == Configuration == The FS20 system sends on 868,35 MHz, so the 868MHz option is the right one. | | I/O ---> | | ... | | Radio ---> | | ... | | [*] RFM12 ASK ---> | | ... | | [ ] 433MHz | | | | [-] Pollin/Kangtai Powerswitch (IC 2272) | | | | [-] Pollin Powerswitch buried (IC 1527) | | | | [-] Tevion Powerswitch | | | | [-] Intertechno ITS-150 | | | | [-] External filter | | | | [-] Sensing | | | | --- | | | | [*] 868MHz | | | | (0) RFM12 select | | | | [*] FS20 send | | | | [*] FS20 receive | | | | [*] FHT | | | | [*] ESA | | | | [ ] TX3 | | | | [ ] Send received data via syslog | | | | --- Debugging Flags | | | | [-] Sensing | | | | [ ] FS20 | | The modul uses Timer 2 of the AVR '''exclusively'''. Currently there is no option to use Timer 1, but this will change in the future. == [[ECMD]] == RFM12 FS20 implements an [[ECMD]] interface for send and receive FS20/FHT commands. The received data is formatted as described in the [http://culfw.de/commandref.html#protocol2 CULFW reference]. See [[ECMD_Reference|ECMD reference]] for a command list. == Troubleshooting == It may happen that not all of the RFM12 FS20 sensors are received. Here are some points that may help to improve reception: * Location: ** Avoid RF transmitter near the RFM12 ** Choose a position in the center of the sensors * Antenna: ** It is recommended to choose an antenna with a length not shorter than Lamda/2 (17,3cm) * Bandwidth: Default 400kHz ** Can be changed via ECMD from 400kHz to 67kHz (rfm12 setbandwidth <modulnumber> 1-6) * Gain: Default -14dB ** Can be changed via ECMD from 0dB to -20dB (rfm12 setgain <modulnumber> 0-3) * DRSSI: Default -97dB ** Can be changed via ECMD from -103dB to -61dB (rfm12 setdrssi <modulnumber> 0-7) Checkout the RFM12 datasheet for details on bandwidth, gain and DRSSI. == Decoding received data == The received data is formatted as described in the [http://culfw.de/commandref.html#protocol2 CULFW reference]. One could use the perl scripts from [http://culfw.de/ CULFW] to decode the data. [[Category:RFM12]] 28a102b02a3eca3e6c4725affe2a26633dc5e3e7 0 311 1087 1018 2013-06-28T11:18:49Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->Radio->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |TIMER={{occupies_timer|2}} (RX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} Das FS20- / FHT-System von ELV ist derzeit das wohl erfolgreichste Funk-Haussteuerungssystem im Niedrigpreissektor. Dies ergibt sich aus der Vielzahl von Komponenten und der ständigen Erweiterung des Systems. Aber auch der relativ günstige Preis, der umfangreiche Haussteuerungen weit unter dem Preis von z.B. EIB-Systemen zulässt, spielt eine entscheidende Rolle. Das Modul basiert auf [http://culfw.de CULFW von Rudolf Koenig] und unterstützt folgende Protokolle: * FS20: senden/empfangen<br>Es gibt eine Vielzahl von FS20 Geräten, die alle unterstützt werden. * FHT: senden/empfangen<br>Die Kommunikation mit FHT80b wird unterstützt. * S300: empfangen<br>Beispiele dieser Geräte: S300TH, KS300-2 * EM1000: empfangen<br>Geräte: EM1000FM, EM1000GZ, EM1000WZ * HMS: empfangen<br>Es gibt eine Vielzahl von HMS Geräten, die alle unterstützt werden. * ESA2000: empfangen * Lacrosse TX2/TX3: empfangen [[Category:RFM12]] 4194b70398edb3e963c8fedb686a4f400bf7fec0 6 369 1094 2013-07-01T09:07:13Z Dg9oaa 103 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 189 1096 919 2013-07-09T15:08:10Z Mgue 312 moved to ethersex-tools wikitext text/x-wiki {{i18n|Onewire}} {{Module |NAME=Onewire |MENUCONFIG={{I/O}}->Onewire support |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] [[HTTPD]] (optional) [[SNMP]] (optional) |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} Ethersex kann 1-wire Temperatursensoren mit [[ECMD]] auflisten und abfragen. Es wird eine reine Softwareimplementierung des Protokolls benutzt, was keine weiteren Hardware erfordert, als die Temperatursensoren selbst. = Pinning = In der Standardkonfiguration liegt der Datapin des Buses auf PD6 (kann z.B. in der pinning/hardware/netio.m4 oder pinning/hardware/etherrape.m4 geändert werden). Die Definition der Pins erfolgt mit: <source lang=c> ONEWIRE_PORT_RANGE(PXn, PXm) </source> wobei PXn und PNm Pins auf PORTX sind. Jeder Pin zwischen und einschließlich PXn und PXm bildet einen eingenständigen Onewire Bus. Du kannst bis zu acht Busse auf einem PORT definieren (alle Busse müssen auf dem selben PORT liegen!) == Beispiele == Wenn Du nur einen einzigen Bus benötigst, definiere den Bereich wie folgt: '''PORTD: PIN2''' <source lang=c> ONEWIRE_PORT_RANGE(PD2, PD2) </source> Für drei Busse würde das ganze etwa so aussehen: '''PORTD: PIN2, PIN3, PIN4''' <source lang=c> ONEWIRE_PORT_RANGE(PD2, PD4) </source> = Polling Modus = │ │ [*] Onewire Polling │ │ │ │ (375) Time between discoveries in 1s steps │ │ │ │ (12) Time between polling in 1s steps │ │ │ │ [*] ECMD 1w list with values │ │ │ │ (10) Maximum sensor count │ │ Im Polling-Modus werden die Sensoren im Hintergrund abgefragt, so dass die Werte bei Bedarf direkt zur Verfügung stehen und nicht erst gewandelt bzw. eingelesen werden müssen. Der Intervall zwischen den Discoveries und zwischen den Abfragen der Werte kann getrennt eingestellt werden. Die Option '''ECMD 1w list with values''' bietet die Möglichkeit, die aktuellen Werte bei Aufruf von '''1w list''' mit ausgeben zu lassen. So können darauf folgende '''1w get''' Kommandos entfallen. Da zur Pufferung der Werte, ROM-Codes, etc. RAM-Speicher benötigt wird, muss per '''Maximum sensor count''' angegeben werden, für wie viele Sensoren Speicher reserviert wird. = Benennung von Sensoren = │ │ [*] Onewire naming support │ │ │ │ (10) Maximum sensor count │ │ Um den Sensoren sinnvolle Namen zu geben besteht die Möglichkeit im EEPROM eine entsprechende Zuweisungstabelle anzulegen (ROM-Code -> Name). Die Namen werden bei bei Aufruf von '''1w list''' mit ausgegeben. Dazu gibt es folgende ECMD Kommandos: 1w name list Auflistung der aktuellen Zuweisungen (Spalten: ID, ROM-Code, Name). Die ID bezeichnet die Position in der Zuweisungstabelle und kann u.a. dazu benutzt werden, Sensoren bei SNMP-Abfragen eindeutig zu referenzieren. 1w name set <ID> <ROM-Code> <Name> Erstellt einen entsprechenden Tabelleneintrag. 1w name clear <ID> Löscht die Felder eines Tabelleneintrags. 1w name save Speichert die aktuelle Tabelle im EEPROM = Unterstützte Hardware = Folgende 1-wire Hardware wird momentan durch Ethersex unterstützt: * DS1820 (Temperatursensor) * DS18B20 (Temperatursensor) * DS1822 (Temperatursensor) * DS2502 (EEPROM) * [[Onewire/DS2450 (Deutsch) | DS2450 (4 Kanal ADC)]] = Onewire Befehle = unter Linux als erstes netcat starten (hierbei natürlich die IP ggf modifizieren): netcat 192.168.0.15 2701 danach am prompt: 1w list Gibt eine Liste mit Hexcodes aller angeschlossenen und erkannten Onewire(tm) Sensoren aus. Bei aktiviertem Naming-Support wird (per TAB getrennt) zusätzlich der Name ausgegeben. Außerdem kann mit '''ECMD 1w list with values (ONEWIRE_ECMD_LIST_VALUE_SUPPORT)''' der aktuelle Temperaturwert mit ausgegeben werden. Dies erspart zusätzliche '''1w get''' Aufrufe, setzt allerding Polling-Support vorraus. 1w convert <hexcode> Veranlasst eine Temperaturmessung des addressierten Sensors, oder, wenn das Argument <hexcode> weggelassen wird, aller angeschlossener Sensoren. Im Polling-Modus wird dieses Kommando ignoriert. 1w get <hexcode> Gibt die gemessene Temperatur eines Sensors aus. = Einbindung in die [[HTTPD]]-Weboberfläche = Unter httpd/embed/ow.ht.m4, bzw httpd/embed/Xow.ht.m4 liegt eine Weboberflaeche, die alle Sensoren erkennt und ihre aktuelle Temperatur regelmässig per Ajax abfragt und anzeigt. Im Falle von Xow.ht.m4 wird sogar Graph der Temperatur mittels SVG gemalt. Um die Dateien einzubinden, muss man einfach bei aktiviertem Onewiresupport den Webserver und das Datei Inlining aktivieren. Die Dateien können dann unter ow.ht bzw. unter Xow.ht angezeigt werden. Das Beispiel zeigt die SVG-Version mit Naming-Support: [[File:onewire-svg.png]] = Anschluss AVR-NET-IO = Für das Pollin AVR-NET-IO Board können die Sensoren DS18S20+ , normal Betrieb [[File:netio-1wire_normal.png]] parasitären Modus [[File:netio-1wire.png]] Anmerkung: Wenn man beim Net-IO nicht alle Analogeingänge benötigt, lässt sich der 1-Wire-Bus auch an der Schraubklemme ADC1 ganz gut aufschalten. Vorteil ist, dass man gleich alle passenden Spannungen (GND, +5V) an den beiden nebenliegenden Schraubklemmen hat. Das Pinning muss dann entspechend in der kann in der Datei pinning/hardware/netio.m4 von PD6 auf PA4 geändert werden. Vorteil dieser Konfiguration ist, dass man den DB-25-Verbinder zum Anschluss der Relaisplatine K8IO von Pollin frei hat und den EXT Steckverbinder zum Anschluss eines LCD über ein 4bit-Interface nutzen kann, ohne die Erweiterungsplatine von Pollin zu benötigen. Pinbelegung: [[File:ds18s20-par-pinout.jpg]] = Anschluss Etherrape = Die Schaltung je nach parasitärem oder normalem Betriebsmodus kann aus der NetIO Skizze übernommen werden. Data liegt auf PORTD an Pin 7: PORTD +---+ |x x| |x X| <- Pin 7 |x x |x x| |x x| +---+ Direkt neben PORTD befinden sich 2 Pins mit GND und 5V als Beschriftung. GND kann als GND und 5V als Vcc genutzt werden. = Einbindung in [[Control6]] = Die Sensoren können mit '''ONEWIRE_GET(sensor-id)''' oder '''ONEWIRE_GET_BY_NAME(sensor-name)''' einfach abgefragt werden. Die Funktion führt automatisch ein ''convert'' aus, es sind also keine zwei Schritte erforderlich wie bei dem Zugriff über [[ECMD]]. Die Rückgabe erfolgt (analog der Funktion '''KTY_GET''') in Centigrad, also Temperatur * 10. Hier vielleicht ein kleines Beispiel, das die Daten per [[SYSLOG]] ausgibt sobald sich die Temperatur um mehr als ein Grad zur letzten Messung verändert hat. <pre> #include <stdlib.h> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO uint8_t sign = Temperatur<0; div_t res = div(abs(Temperatur),10); SYSLOG("temperature changed %S%d.%d",sign?PSTR("-"):PSTR(""),res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> = Abfrage per [[SNMP]] = Falls Polling-Support aktiviert wurde können die Sensorwerte per SNMP abgefragt werden. Mit Naming-Support stehen auch die Namen per SNMP zur Verfügung und die Index-Nummern sind fix auf die Position in der Namenstabelle festgelegt. Dies ist sehr hilfreich, um bestimmte Sensoren über den SNMP-Index anzusprechen. Es gibt folgende OIDs: * .1.3.6.1.4.1.39967.3.1.<idx> : ROM-Code des Sensors * .1.3.6.1.4.1.39967.3.2.<idx> : Sensor-Name (nur mit Naming-Support) * .1.3.6.1.4.1.39967.3.3.<idx> : Temperaturwert in Centigrad * .1.3.6.1.4.1.39967.3.4.<idx> : 0 = Sensor nicht vorhanden, 1 = Sensor vorhanden Hier ein Beispiel: <pre> # snmpwalk -Osn -c public -v 1 192.168.255.90 1.3.6.1.4.1.39967.3 .1.3.6.1.4.1.39967.3.1.0 = STRING: "1080cff6010800f9" .1.3.6.1.4.1.39967.3.1.1 = STRING: "10c8cff60108002d" .1.3.6.1.4.1.39967.3.1.2 = STRING: "1029f6dc0108002f" .1.3.6.1.4.1.39967.3.1.3 = STRING: "10f2d0f60108001c" .1.3.6.1.4.1.39967.3.1.4 = STRING: "105a17f70108001d" .1.3.6.1.4.1.39967.3.1.5 = STRING: "10b8d8f601080098" .1.3.6.1.4.1.39967.3.1.6 = STRING: "104dedf601080057" .1.3.6.1.4.1.39967.3.1.7 = STRING: "10011af701080027" .1.3.6.1.4.1.39967.3.1.8 = STRING: "0000000000000000" .1.3.6.1.4.1.39967.3.1.9 = STRING: "0000000000000000" .1.3.6.1.4.1.39967.3.2.0 = STRING: "kessel" .1.3.6.1.4.1.39967.3.2.1 = STRING: "warmwasser" .1.3.6.1.4.1.39967.3.2.2 = STRING: "aussen" .1.3.6.1.4.1.39967.3.2.3 = STRING: "speicher" .1.3.6.1.4.1.39967.3.2.4 = STRING: "heizung vl" .1.3.6.1.4.1.39967.3.2.5 = STRING: "heizung rl" .1.3.6.1.4.1.39967.3.2.6 = STRING: "boiler vl" .1.3.6.1.4.1.39967.3.2.7 = STRING: "boiler rl" .1.3.6.1.4.1.39967.3.2.8 = "" .1.3.6.1.4.1.39967.3.2.9 = "" .1.3.6.1.4.1.39967.3.3.0 = INTEGER: 334 .1.3.6.1.4.1.39967.3.3.1 = INTEGER: 467 .1.3.6.1.4.1.39967.3.3.2 = INTEGER: 127 .1.3.6.1.4.1.39967.3.3.3 = INTEGER: 185 .1.3.6.1.4.1.39967.3.3.4 = INTEGER: 318 .1.3.6.1.4.1.39967.3.3.5 = INTEGER: 269 .1.3.6.1.4.1.39967.3.3.6 = INTEGER: 366 .1.3.6.1.4.1.39967.3.3.7 = INTEGER: 291 .1.3.6.1.4.1.39967.3.3.8 = INTEGER: 0 .1.3.6.1.4.1.39967.3.3.9 = INTEGER: 0 .1.3.6.1.4.1.39967.3.4.0 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.1 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.2 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.3 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.4 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.5 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.6 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.7 = INTEGER: 1 .1.3.6.1.4.1.39967.3.4.8 = INTEGER: 0 .1.3.6.1.4.1.39967.3.4.9 = INTEGER: 0 </pre> = Codebeispiele = * [https://github.com/ethersex/ethersex-tools/blob/master/hardware/onewire/onewire_request.php PHP] * [https://github.com/ethersex/ethersex-tools/blob/master/hardware/onewire/onewire_request.pl Perl] * [https://github.com/ethersex/ethersex-tools/blob/master/hardware/onewire/onewire_request.py Python] * [https://github.com/ethersex/ethersex-tools/blob/master/hardware/onewire/onewire_request.sh sh/bash] [[Category:Ethersex]] [[Category:StepByStep]] [[Category:Onewire]] = Bezugsquellen = Laut Michael Schultz (k1w1) hat er immer DS1820 auf Lager und kann sie sehr günstig weiterverkaufen. Auch Mindermengen. Mail: ethersex [AT] keyb [DOT] de und natürlich bei den üblichen Verdächtigen: Reichelt, Segor, Conrad. a22b353597310ba32b8c33221d4e9e9f92375205 0 172 1097 420 2013-07-09T15:10:06Z Mgue 312 added client code wikitext text/x-wiki {{i18n|Onewire}} {{Module |NAME=Onewire |MENUCONFIG={{I/O}}->Onewire support |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} = Pinning = Define your Onewire Pins with <source lang=c> ONEWIRE_PORT_RANGE(PX#, PX@) </source> where * PX# is a pin on PORTX * PX@ is a pin on PORTX every pin between and including PX# and PX@ will be a seperate Onewire bus. You can define up to eight buses on one PORT (all buses must be on the same PORT!) If you just need a single bus, define the range like this: <source lang=c> ONEWIRE_PORT_RANGE(PX#, PX#) </source> == Example == '''PORTD: PIN2, PIN3, PIN4''' <source lang=c> ONEWIRE_PORT_RANGE(PD2, PD4) </source> = Polling Mode = = Client Code = The following scripts can be used to read onewire temperatures on a host computer using ECMD. * [https://github.com/ethersex/ethersex-tools/blob/master/hardware/onewire/onewire_request.php PHP] * [https://github.com/ethersex/ethersex-tools/blob/master/hardware/onewire/onewire_request.pl Perl] * [https://github.com/ethersex/ethersex-tools/blob/master/hardware/onewire/onewire_request.py Python] * [https://github.com/ethersex/ethersex-tools/blob/master/hardware/onewire/onewire_request.sh sh/bash] 773c4624b4c82234cf816666cda94c420f853798 0 280 1098 863 2013-07-09T15:14:50Z Mgue 312 typo wikitext text/x-wiki {{i18n|Flashing}} = Flash AVR Net-IO with "ATMEL Evaluations-Board" made by Pollin= As a beginner it's difficult to understand everything in terms of flashing. And it's also difficult to find all information. == What's needed? == * AVR Net-IO * ATMEL Evaluation-Board * a 1 on 1 Cable for the [[ISP]]-Port (10-pin Connector). === Other ISP Programmers === If you have a ISP-Programmer with 6-pin port you can create an adaptor. You can see the pin configuration in figure 4-1 at page 5 [http://www.atmel.com/dyn/resources/prod_documents/doc2521.pdf AVR042: AVR Hardware Design Considerations]. Warning: Pin 4 of the 10-pin connector is not used on the Net-IO. GND has to be connected to one of the other Pins (6, 8 or 10) == Flashing with Linux == *Connect the 10-pin Cable to the ISP-Connector. *Plug in the power adaptor of the AVR Net-IO. *If everything is connected right, the yellow LED of the Evaluation-Board is shining. After compiling the ethersex.hex you can flash it with avrdude. The following commands depend on your ISP-Programmer. This example is for a serial connection: avrdude -v -p m32 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex For a USB-ISP-Programmer this command should be used: avrdude -v -p m32 -c stk500v2 -P /dev/ttyACM0 -U flash:w:ethersex.hex For a parallel ISP-Cable: avrdude -p m32 -e -c stk200 -U flash:w:ethersex.hex After flashing remove the ISP-Cable and interrupt the power connection for a short time to reboot the board. * -p m32: ATMega32; -p m644: ATMega644 * -v: display debug messages * -c ponyser: the way avrdude speaks with the Evaluation Board; -c stkk500v2 for the Atmel board * -P /dev/tty.serial the serial port your programmer is connected to; -P COM1 for windows machines * -U the command you want to execute. In our case we want to flash: -U flash:w:ethersex.hex In some cases you have to set the FUSE Bits, which is possible with this command: * -U lfuse:w:0xCF:m -U hfuse:w:0xDC:m To get the correct FUSE-Settings you should visit http://www.engbedded.com/fusecalc/ Parameters for MyAVR mySmartusb light (the -e is important): avrdude -p m32 -e -c stk500v2 -P /dev/ttyUSB0 -U flash:w:ethersex.hex == Replace ATMega32 with an ATMega644, ATMega644p or ATMega1284p == ATMega644, ATMega644p and ATMega1284p have got a bigger flash then the ATMega32. This gives the possibility to add more modules to your Image. === Swapping the Microcontroller === * Disconnect power and ISP-Connector. * Remove the old processor from your board. * Insert the new processor while the slot is at the same position as in the socket. === Setting the FUSE-Bits === * Reconnect the ISP and the power. * Set the FUSE-Bits. * '''Important: ''' in the condition as supplied the 644 is programmed to 8 MHz internal RC-Oscillator '''and''' the clock is divided by 8 -> 1 MHz clock speed. If an external Quarz is used, the Bit CKDIV8 has to be set to 0. * (taken from dinus) The ATMega has a clock speed of 1 MHz, no JTAG. avrdude -p m644 -c ponyser -P /dev/ttyS0 -U lfuse:w:0xE7:m -U hfuse:w:0xDC:m -U efuse:w:0xFF:m Fuse-Bits from "DiDi". JTAG is turned ON. * -U lfuse:w:0xf7:m -U hfuse:w:0x99:m -U efuse:w:0xfc:m Fuse-Bits from "loddel". JTAG is turned OFF. * -U lfuse:w:0xf7:m -U hfuse:w:0xd9:m -U efuse:w:0xff:m * -U lfuse:w:0xe7:m -U hfuse:w:0xd9:m -U efuse:w:0xff:m Fuse-Bits from "Gregor". "The 644 runs at 16 MHz Quartz and is not divided by 8." JTAG is turned ON. * -U lfuse:w:0xef:m -U hfuse:w:0x99:m -U efuse:w:0xff:m === flash Ethersex === * change Config of Ethersex (make menuconfig) to ATMega644 and build (make) * flash with avrdude -p m644 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex -v === Differences between ATMega32, ATMega644, ATMega644p and ATMega1284p=== {| border=1 cellspacing=0 padding=4 class=wikitable " ! !! ATMega32 !! ATMega644 !! ATMega644p !! ATMega1284p |- | Housing || DIL-40 || DIL-40 || DIL-40 || DIL-40 |- | MHz || max. 16 || max. 20 || max. 20 || max. 20 |- | Flash || 32 KB || 64 KB || 64 KB || 128 KB |- | EEProm || 1 KB || 2 KB || 2 KB || 4 KB |- | RAM || 2 KB || 4 KB || 4 KB || 16 KB |- | I/O || 32 || 32 || 32 || 32 |- | PWM || 4 || 6 || 6 || 6 |- | ext. INT || 3 || 32 || 32 || 32 |- | Ser-Port || 1 || 1 || 2 || 2 |} ====Datasheets==== * [http://www.atmel.com/Images/doc2503.pdf AtMega32] * [http://www.atmel.com/Images/doc2593.pdf ATMega644] * [http://www.atmel.com/images/doc8011.pdf ATMega644p] * [http://www.atmel.com/dyn/resources/prod_documents/8059S.pdf ATMega1284p] == Flashing with Windows == There a two main possibilities: #Flash with avrdude #Flash with AVR Studio If you don't want to install one of those programs, there is a [[Live CD]] to use. ===Flashing with avrdude=== The flashing with avrdude is just like in Linux. You can get the Windows-Binary as a part of [http://sourceforge.net/projects/winavr/ WinAVR] In the command line you have to adjust the name of the serial Ports. (COMx instead of /dev/ttyxx) avrdude -v -p m32 -c ponyser -P com3 -U flash:w:ethersex.hex If the programmer is connected via USB you need: * for real USB-Programmers: libusb0.dll (Part of WinAVR) * USB-to-Serial Converter a matching Driver: [http://www.ftdichip.com/Drivers/VCP.htm] ===Flashing with AVR Studio=== [[AVR Studio]] from Atmel offers a GUI to Controll the ISPs. AVR Studio also brings USB-Drivers for the Programmers with it, which can be installed together with it. For USB-to-Serial converters you need a matching Driver: [http://www.ftdichip.com/Drivers/VCP.htm] == Live-CD == You don't have to worry about your System if you use a Live CD to flash your build. * Download and burn the CD: [http://www.ethersex.de/index.php?title=Live_CD] * Get the libncurses5 Package: apt-get install libncurses5-dev * Update and install the software for ethersex just like described here: [http://ethersex.de/index.php/Quick_Start_Guide/Preparation] * If menuconfig fails try this command: apt-get install dialog * Flash like described in the "Flashing with Linux" section is described. 12a5ad9f51af3330d8a073c2364fb1d312a52e60 1099 1098 2013-07-09T15:24:25Z Mgue 312 rearranged page, removed confusing/dangerous fuse settings, remove liveCD option (currently not available!) wikitext text/x-wiki {{i18n|Flashing}} = Flash AVR Net-IO with "ATMEL Evaluations-Board" made by Pollin= As a beginner it's difficult to understand everything in terms of flashing. And it's also difficult to find all information. == What's needed? == * AVR Net-IO * ATMEL Evaluation-Board * a 1 on 1 Cable for the [[ISP]]-Port (10-pin Connector). === Other ISP Programmers === If you have a ISP-Programmer with 6-pin port you can create an adaptor. You can see the pin configuration in figure 4-1 at page 5 [http://www.atmel.com/dyn/resources/prod_documents/doc2521.pdf AVR042: AVR Hardware Design Considerations]. Warning: Pin 4 of the 10-pin connector is not used on the Net-IO. GND has to be connected to one of the other Pins (6, 8 or 10) == Flashing with Linux == *Connect the 10-pin Cable to the ISP-Connector. *Plug in the power adaptor of the AVR Net-IO. *If everything is connected right, the yellow LED of the Evaluation-Board is shining. === Setting the FUSE-Bits === * Calculate the correct FUSE bits for your controller/setup - you can use http://www.engbedded.com/fusecalc/ for that * '''Important: ''' in the condition as supplied the 644 is programmed to 8 MHz internal RC-Oscillator '''and''' the clock is divided by 8 -> 1 MHz clock speed. If an external Quarz is used, the Bit CKDIV8 has to be set to 0. Also make sure that you leave ''Serial program downloading (SPI)'' enabled! * Connect the ISP and the power. * Set the FUSE-Bits with avrdude * Reset the controller === Flashing the Image === After compiling the ethersex.hex you can flash it with avrdude. The following commands depend on your ISP-Programmer. This example is for a serial connection: avrdude -v -p m32 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex For a USB-ISP-Programmer this command should be used: avrdude -v -p m32 -c stk500v2 -P /dev/ttyACM0 -U flash:w:ethersex.hex For a parallel ISP-Cable: avrdude -p m32 -e -c stk200 -U flash:w:ethersex.hex Parameters for MyAVR mySmartusb light (the -e is important): avrdude -p m32 -e -c stk500v2 -P /dev/ttyUSB0 -U flash:w:ethersex.hex After flashing remove the ISP-Cable and interrupt the power connection for a short time to reboot the board. * -p m32: ATMega32; -p m644: ATMega644 * -v: display debug messages * -c ponyser: the way avrdude speaks with the Evaluation Board; -c stkk500v2 for the Atmel board * -P /dev/tty.serial the serial port your programmer is connected to; -P COM1 for windows machines * -U the command you want to execute. In our case we want to flash: -U flash:w:ethersex.hex == Replace ATMega32 with an ATMega644, ATMega644p or ATMega1284p == ATMega644, ATMega644p and ATMega1284p have got a bigger flash then the ATMega32. This gives the possibility to add more modules to your Image. === Swapping the Microcontroller === * Disconnect power and ISP-Connector. * Remove the old processor from your board. * Insert the new processor while the slot is at the same position as in the socket. === Differences between ATMega32, ATMega644, ATMega644p and ATMega1284p=== {| border=1 cellspacing=0 padding=4 class=wikitable " ! !! ATMega32 !! ATMega644 !! ATMega644p !! ATMega1284p |- | Housing || DIL-40 || DIL-40 || DIL-40 || DIL-40 |- | MHz || max. 16 || max. 20 || max. 20 || max. 20 |- | Flash || 32 KB || 64 KB || 64 KB || 128 KB |- | EEProm || 1 KB || 2 KB || 2 KB || 4 KB |- | RAM || 2 KB || 4 KB || 4 KB || 16 KB |- | I/O || 32 || 32 || 32 || 32 |- | PWM || 4 || 6 || 6 || 6 |- | ext. INT || 3 || 32 || 32 || 32 |- | Ser-Port || 1 || 1 || 2 || 2 |} ====Datasheets==== * [http://www.atmel.com/Images/doc2503.pdf AtMega32] * [http://www.atmel.com/Images/doc2593.pdf ATMega644] * [http://www.atmel.com/images/doc8011.pdf ATMega644p] * [http://www.atmel.com/dyn/resources/prod_documents/8059S.pdf ATMega1284p] == Flashing with Windows == There a two main possibilities: #Flash with avrdude #Flash with AVR Studio ===Flashing with avrdude=== The flashing with avrdude is just like in Linux. You can get the Windows-Binary as a part of [http://sourceforge.net/projects/winavr/ WinAVR] In the command line you have to adjust the name of the serial Ports. (COMx instead of /dev/ttyxx) avrdude -v -p m32 -c ponyser -P com3 -U flash:w:ethersex.hex If the programmer is connected via USB you need: * for real USB-Programmers: libusb0.dll (Part of WinAVR) * USB-to-Serial Converter a matching Driver: [http://www.ftdichip.com/Drivers/VCP.htm] ===Flashing with AVR Studio=== [[AVR Studio]] from Atmel offers a GUI to Controll the ISPs. AVR Studio also brings USB-Drivers for the Programmers with it, which can be installed together with it. For USB-to-Serial converters you need a matching Driver: [http://www.ftdichip.com/Drivers/VCP.htm] 9ad25dc4a6f1682821c8bc200a9671f7bd620d03 1100 1099 2013-07-09T15:31:05Z Mgue 312 more changes, this page should be generic - not netio-only wikitext text/x-wiki {{i18n|Flashing}} = Flashing ethersex = This guide assumes that you have a NETIO, made and produced by [http://www.pollin.de Pollin], however every step should also work with any other board supported by ethersex. == What's needed? == * AVR Net-IO * an ISP Programmer, again we assume it the ATMEL Evaluation-Board made by [http://www.pollin.de Pollin] * an 1-to-1 Cable for the [[ISP]]-Port (10-pin Connector). === Other ISP Programmers === If you have a ISP-Programmer with 6-pin port you can create an adapter. You can see the pin configuration in figure 4-1 at page 5 [http://www.atmel.com/dyn/resources/prod_documents/doc2521.pdf AVR042: AVR Hardware Design Considerations]. Warning: Pin 4 of the 10-pin connector is not used on the Net-IO. GND has to be connected to one of the other Pins (6, 8 or 10) == Flashing with Linux == * Connect the 10-pin Cable to the ISP-Connector. * Plug in the power adapter of the AVR Net-IO. * If everything is connected right, the yellow LED of the Evaluation-Board is shining. === Setting the FUSE-Bits === * Calculate the correct FUSE bits for your controller/setup - you can use http://www.engbedded.com/fusecalc/ for that * '''Important: ''' in the condition as supplied the 644 is programmed to 8 MHz internal RC-Oscillator '''and''' the clock is divided by 8 -> 1 MHz clock speed. If an external Quarz is used, the Bit CKDIV8 has to be set to 0. Also make sure that you leave ''Serial program downloading (SPI)'' enabled! * Connect the ISP and the power. * Set the FUSE-Bits with avrdude * Reset the controller === Flashing the Image === After compiling the ethersex.hex you can flash it with avrdude. The following commands depend on your ISP-Programmer. This example is for a serial connection (e.g. the ATMEL Evaluation-Board): avrdude -v -p m32 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex For a USB-ISP-Programmer this command should be used: avrdude -v -p m32 -c stk500v2 -P /dev/ttyACM0 -U flash:w:ethersex.hex For a parallel ISP-Cable: avrdude -p m32 -e -c stk200 -U flash:w:ethersex.hex Parameters for MyAVR mySmartusb light (the -e is important): avrdude -p m32 -e -c stk500v2 -P /dev/ttyUSB0 -U flash:w:ethersex.hex After flashing remove the ISP-Cable and interrupt the power connection for a short time to reboot the board. * -p m32: ATMega32; -p m644: ATMega644 * -v: display debug messages * -c ponyser: the way avrdude speaks with the Evaluation Board; -c stkk500v2 for the Atmel board * -P /dev/tty.serial the serial port your programmer is connected to; -P COM1 for windows machines * -U the command you want to execute. In our case we want to flash: -U flash:w:ethersex.hex == Replace ATMega32 with an ATMega644, ATMega644p or ATMega1284p == ATMega644, ATMega644p and ATMega1284p have got a bigger flash then the ATMega32. This gives the possibility to add more modules to your Image. === Swapping the Microcontroller === * Disconnect power and ISP-Connector. * Remove the old processor from your board. * Insert the new processor while the slot is at the same position as in the socket. === Differences between ATMega32, ATMega644, ATMega644p and ATMega1284p=== {| border=1 cellspacing=0 padding=4 class=wikitable " ! !! ATMega32 !! ATMega644 !! ATMega644p !! ATMega1284p |- | Housing || DIL-40 || DIL-40 || DIL-40 || DIL-40 |- | MHz || max. 16 || max. 20 || max. 20 || max. 20 |- | Flash || 32 KB || 64 KB || 64 KB || 128 KB |- | EEProm || 1 KB || 2 KB || 2 KB || 4 KB |- | RAM || 2 KB || 4 KB || 4 KB || 16 KB |- | I/O || 32 || 32 || 32 || 32 |- | PWM || 4 || 6 || 6 || 6 |- | ext. INT || 3 || 32 || 32 || 32 |- | Ser-Port || 1 || 1 || 2 || 2 |} ====Datasheets==== * [http://www.atmel.com/Images/doc2503.pdf AtMega32] * [http://www.atmel.com/Images/doc2593.pdf ATMega644] * [http://www.atmel.com/images/doc8011.pdf ATMega644p] * [http://www.atmel.com/dyn/resources/prod_documents/8059S.pdf ATMega1284p] == Flashing with Windows == There a two main possibilities: #Flash with avrdude #Flash with AVR Studio ===Flashing with avrdude=== The flashing with avrdude is just like in Linux. You can get the Windows-Binary as a part of [http://sourceforge.net/projects/winavr/ WinAVR] In the command line you have to adjust the name of the serial Ports. (COMx instead of /dev/ttyxx) avrdude -v -p m32 -c ponyser -P com3 -U flash:w:ethersex.hex If the programmer is connected via USB you need: * for real USB-Programmers: libusb0.dll (Part of WinAVR) * USB-to-Serial Converter a matching Driver: [http://www.ftdichip.com/Drivers/VCP.htm] ===Flashing with AVR Studio=== [[AVR Studio]] from Atmel offers a GUI to Controll the ISPs. AVR Studio also brings USB-Drivers for the Programmers with it, which can be installed together with it. For USB-to-Serial converters you need a matching Driver: [http://www.ftdichip.com/Drivers/VCP.htm] 83c194bc3f9d300c3b565ac45f1376fc696554d0 0 278 1101 698 2013-07-13T08:37:32Z Michaelb 718 /* Requirements */ wikitext text/x-wiki {{i18n|Quick Start Guide/Flashing}} = Requirements = * the previously selected board, e.g. AVR NET-IO, ready built and (hopefully) tested * an ISP-Programmer of your choice supported by [http://www.nongnu.org/avrdude avrdude] * ISP connector cable = Flashing with avrdude = Avrdude offers several options. We will look on the most important, to make basic flashing of ethersex possible. * The chip you use, should be m32 for the ATMega32 in most cases: -p m32 * Debug messages: -v * The protocol spoken with the programmer, for the Evaluation-Board: -c ponyser * The serial port the programmer is connected to: -P /dev/ttyS0 * The command you want to execute: -U flash:w:ethersex.hex After you checked all options and adjusted them to your settings you should have a command like this: avrdude -v -p m32 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex = Writing the Bytes = * Disconnect the power from the NET-IO * Connect your ISP cable to the programmer and the Net-IO * Reconnect the power and connect your programmer to the PC * Execute the command you assembled earlier * Congratulations! If avrdude finished without any error you successfully flashed ethersex to your Net-IO! * Disconnect the power and the programmer from the Net-IO * Reconnect the power, your Net-IO should boot up with ethersex [[Quick_Start_Guide/Configuration | previous step]] | 1396296fc92699bcf56601885a3ee7c71b45374c 6 370 1102 2013-07-15T21:03:45Z Michaelb 718 AVRDUDE Configuration in mainmenu wikitext text/x-wiki AVRDUDE Configuration in mainmenu 0981ee7ee0ee73c04f5f4f9232babf95023f88bc 0 278 1103 1101 2013-07-15T21:05:29Z Michaelb 718 /* Writing the Bytes */ wikitext text/x-wiki {{i18n|Quick Start Guide/Flashing}} = Requirements = * the previously selected board, e.g. AVR NET-IO, ready built and (hopefully) tested * an ISP-Programmer of your choice supported by [http://www.nongnu.org/avrdude avrdude] * ISP connector cable = Flashing with avrdude = Avrdude offers several options. We will look on the most important, to make basic flashing of ethersex possible. * The chip you use, should be m32 for the ATMega32 in most cases: -p m32 * Debug messages: -v * The protocol spoken with the programmer, for the Evaluation-Board: -c ponyser * The serial port the programmer is connected to: -P /dev/ttyS0 * The command you want to execute: -U flash:w:ethersex.hex After you checked all options and adjusted them to your settings you should have a command like this: avrdude -v -p m32 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex = Writing the Bytes = * Disconnect the power from the NET-IO * Connect your ISP cable to the programmer and the Net-IO * Reconnect the power and connect your programmer to the PC * Execute the command you assembled earlier * Congratulations! If avrdude finished without any error you successfully flashed ethersex to your Net-IO! * Disconnect the power and the programmer from the Net-IO * Reconnect the power, your Net-IO should boot up with ethersex = AVRDUDE and menuconfig = == AVRDUDE Configuration == [[File:avrdude_mainmenu.png]] == AVR Fuses == [[Quick_Start_Guide/Configuration | previous step]] | 6acb06fc3990487f7b605e397f258e3f2535b0b0 1105 1103 2013-07-15T21:08:46Z Michaelb 718 /* AVRDUDE Configuration */ wikitext text/x-wiki {{i18n|Quick Start Guide/Flashing}} = Requirements = * the previously selected board, e.g. AVR NET-IO, ready built and (hopefully) tested * an ISP-Programmer of your choice supported by [http://www.nongnu.org/avrdude avrdude] * ISP connector cable = Flashing with avrdude = Avrdude offers several options. We will look on the most important, to make basic flashing of ethersex possible. * The chip you use, should be m32 for the ATMega32 in most cases: -p m32 * Debug messages: -v * The protocol spoken with the programmer, for the Evaluation-Board: -c ponyser * The serial port the programmer is connected to: -P /dev/ttyS0 * The command you want to execute: -U flash:w:ethersex.hex After you checked all options and adjusted them to your settings you should have a command like this: avrdude -v -p m32 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex = Writing the Bytes = * Disconnect the power from the NET-IO * Connect your ISP cable to the programmer and the Net-IO * Reconnect the power and connect your programmer to the PC * Execute the command you assembled earlier * Congratulations! If avrdude finished without any error you successfully flashed ethersex to your Net-IO! * Disconnect the power and the programmer from the Net-IO * Reconnect the power, your Net-IO should boot up with ethersex = AVRDUDE and menuconfig = == AVRDUDE Configuration == [[File:avrdude_mainmenu.png]] [[File:avrdude_menu.png]] == AVR Fuses == [[Quick_Start_Guide/Configuration | previous step]] | ecd2dd883afe4156987a7327b5e35529f130ba5a 1106 1105 2013-07-15T21:10:01Z Michaelb 718 /* AVRDUDE and menuconfig */ wikitext text/x-wiki {{i18n|Quick Start Guide/Flashing}} = Requirements = * the previously selected board, e.g. AVR NET-IO, ready built and (hopefully) tested * an ISP-Programmer of your choice supported by [http://www.nongnu.org/avrdude avrdude] * ISP connector cable = Flashing with avrdude = Avrdude offers several options. We will look on the most important, to make basic flashing of ethersex possible. * The chip you use, should be m32 for the ATMega32 in most cases: -p m32 * Debug messages: -v * The protocol spoken with the programmer, for the Evaluation-Board: -c ponyser * The serial port the programmer is connected to: -P /dev/ttyS0 * The command you want to execute: -U flash:w:ethersex.hex After you checked all options and adjusted them to your settings you should have a command like this: avrdude -v -p m32 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex = Writing the Bytes = * Disconnect the power from the NET-IO * Connect your ISP cable to the programmer and the Net-IO * Reconnect the power and connect your programmer to the PC * Execute the command you assembled earlier * Congratulations! If avrdude finished without any error you successfully flashed ethersex to your Net-IO! * Disconnect the power and the programmer from the Net-IO * Reconnect the power, your Net-IO should boot up with ethersex ---- = AVRDUDE and menuconfig = '''/* PAGE UNDER CONSTRUCTION */''' == AVRDUDE Configuration == [[File:avrdude_mainmenu.png]] [[File:avrdude_menu.png]] == AVR Fuses == [[Quick_Start_Guide/Configuration | previous step]] | e602464e303a28499ff92ddc4c4046cc204fa598 1107 1106 2013-07-15T21:18:33Z Michaelb 718 /* AVRDUDE and menuconfig */ wikitext text/x-wiki {{i18n|Quick Start Guide/Flashing}} = Requirements = * the previously selected board, e.g. AVR NET-IO, ready built and (hopefully) tested * an ISP-Programmer of your choice supported by [http://www.nongnu.org/avrdude avrdude] * ISP connector cable = Flashing with avrdude = Avrdude offers several options. We will look on the most important, to make basic flashing of ethersex possible. * The chip you use, should be m32 for the ATMega32 in most cases: -p m32 * Debug messages: -v * The protocol spoken with the programmer, for the Evaluation-Board: -c ponyser * The serial port the programmer is connected to: -P /dev/ttyS0 * The command you want to execute: -U flash:w:ethersex.hex After you checked all options and adjusted them to your settings you should have a command like this: avrdude -v -p m32 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex = Writing the Bytes = * Disconnect the power from the NET-IO * Connect your ISP cable to the programmer and the Net-IO * Reconnect the power and connect your programmer to the PC * Execute the command you assembled earlier * Congratulations! If avrdude finished without any error you successfully flashed ethersex to your Net-IO! * Disconnect the power and the programmer from the Net-IO * Reconnect the power, your Net-IO should boot up with ethersex ---- = AVRDUDE and menuconfig = '''/* PAGE UNDER CONSTRUCTION */''' Since PR #251 the e6 Makefile supports two new targets <tt>program</tt> and <tt>fuses</tt> to invoke avrdude. The target <tt>program</tt> calls avrdude with the otions to flash <tt>ethersex.hex</tt> to the MCU. <tt>fuses</tt> may be used to program the MCUs fuse registers. == AVRDUDE Configuration == [[File:avrdude_mainmenu.png]] [[File:avrdude_menu.png]] == AVR Fuses == [[Quick_Start_Guide/Configuration | previous step]] | 2da1616f449a760f8942380c7fab0db060840fb5 1108 1107 2013-07-15T21:41:01Z Michaelb 718 /* AVRDUDE and menuconfig */ wikitext text/x-wiki {{i18n|Quick Start Guide/Flashing}} = Requirements = * the previously selected board, e.g. AVR NET-IO, ready built and (hopefully) tested * an ISP-Programmer of your choice supported by [http://www.nongnu.org/avrdude avrdude] * ISP connector cable = Flashing with avrdude = Avrdude offers several options. We will look on the most important, to make basic flashing of ethersex possible. * The chip you use, should be m32 for the ATMega32 in most cases: -p m32 * Debug messages: -v * The protocol spoken with the programmer, for the Evaluation-Board: -c ponyser * The serial port the programmer is connected to: -P /dev/ttyS0 * The command you want to execute: -U flash:w:ethersex.hex After you checked all options and adjusted them to your settings you should have a command like this: avrdude -v -p m32 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex = Writing the Bytes = * Disconnect the power from the NET-IO * Connect your ISP cable to the programmer and the Net-IO * Reconnect the power and connect your programmer to the PC * Execute the command you assembled earlier * Congratulations! If avrdude finished without any error you successfully flashed ethersex to your Net-IO! * Disconnect the power and the programmer from the Net-IO * Reconnect the power, your Net-IO should boot up with ethersex ---- = AVRDUDE in makefile and menuconfig = '''/* PAGE UNDER CONSTRUCTION */''' Since PR #251 the e6 makefile supports two new targets, <tt>program</tt> and <tt>fuses</tt>, to invoke avrdude. The target <tt>program</tt> calls avrdude with the options to flash the previously compiled <tt>ethersex.hex</tt> to the MCU. The <tt>fuses</tt> Target may be used to program the MCUs fuse registers. <!-- REM: Note MCU/Freq settings has to be configured first. --> == AVRDUDE Configuration == If - and only if - the avrdude executable could be found in your <tt>PATH</tt>, menuconfigs mainmenu will show an option to enter AVRDUDE configuration: [[File:avrdude_mainmenu.png]] [[File:avrdude_menu.png]] The AVRDUDE configuration page allows to setup the most common options for avrdude: ;Programmer Type :avrdude option '-c'. :Use the programmer configuration choosen from the list. : :Refer to the official avrdude documentation if you're in doubt about the correct choice for your programmer ([http://www.nongnu.org/avrdude/ avrdude home]). : :NB: The list of choices is generated by calling 'avrdude -c ?' and contains all the programmers your avrdude executable supports. ;Port :avrdude option '-P'. :Specify the port the programmer is connected to. Serial devices like ponyprog use for example <tt>/dev/ttyS0</tt> (= COM1 under Windows!), most modern programmers use <tt>usb</tt>. : : Note that most old-style serial programmers will not work properly when connected to an USB-serial-Adapter! ; Extra verbose output :avrdude option '-v -v'. :Be more verbose. Default is '-v'. Use this, if you experience problems while flashing or simply want to see in detail whats going on... ;Do NOT verify after programming :avrdude option '-V'. :Do NOT verify flash memory after programming. Use with care and only if you're really sure that your setup is perfect. Speeds things up a bit but it's use is generally discouraged. ;Count # of erase cycles in EEPROM :avrdude option '-y'. :Tell avrdude to maintain an erase cycle counter in the last four bytes of the eeprom. The counter has to be initialized by calling avrdude with the option '-Y 1' once. : : Do not use this option if your e6 configuration uses the last four bytes of the eeprom. ;Bitclock for ISP or JTAG : ;Pass extra options to avrdude : == AVR Fuses == BIG FAT WARNING! [[Quick_Start_Guide/Configuration | previous step]] | 0c831f0e4a380a123eb04e03c91fb34f534eaa6c 1109 1108 2013-07-16T06:06:52Z GooPie4o 265 /* AVRDUDE in makefile and menuconfig */ wikitext text/x-wiki {{i18n|Quick Start Guide/Flashing}} = Requirements = * the previously selected board, e.g. AVR NET-IO, ready built and (hopefully) tested * an ISP-Programmer of your choice supported by [http://www.nongnu.org/avrdude avrdude] * ISP connector cable = Flashing with avrdude = Avrdude offers several options. We will look on the most important, to make basic flashing of ethersex possible. * The chip you use, should be m32 for the ATMega32 in most cases: -p m32 * Debug messages: -v * The protocol spoken with the programmer, for the Evaluation-Board: -c ponyser * The serial port the programmer is connected to: -P /dev/ttyS0 * The command you want to execute: -U flash:w:ethersex.hex After you checked all options and adjusted them to your settings you should have a command like this: avrdude -v -p m32 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex = Writing the Bytes = * Disconnect the power from the NET-IO * Connect your ISP cable to the programmer and the Net-IO * Reconnect the power and connect your programmer to the PC * Execute the command you assembled earlier * Congratulations! If avrdude finished without any error you successfully flashed ethersex to your Net-IO! * Disconnect the power and the programmer from the Net-IO * Reconnect the power, your Net-IO should boot up with ethersex ---- = AVRDUDE in makefile and menuconfig = '''/* PAGE UNDER CONSTRUCTION */''' Since commit [https://github.com/ethersex/ethersex/commit/16c2a388ec775b51c049db1eeff3a8171c6ad71b 16c2a388ec] the [[Ethersex]] makefile supports two new targets, ''program'' and ''fuses'', to invoke avrdude. The target ''program'' calls avrdude with the options to flash the previously compiled ''ethersex.hex'' to the MCU. The ''fuses'' target may be used to program the MCUs fuse registers. <!-- REM: Note MCU/Freq settings has to be configured first. --> == AVRDUDE Configuration == If - and only if - the avrdude executable could be found in your ''PATH'', menuconfigs mainmenu will show an option to enter AVRDUDE configuration: [[File:avrdude_mainmenu.png]] [[File:avrdude_menu.png]] The AVRDUDE configuration page allows to setup the most common options for avrdude: ;Programmer Type :avrdude option '-c'. :Use the programmer configuration choosen from the list. : :Refer to the official avrdude documentation if you're in doubt about the correct choice for your programmer ([http://www.nongnu.org/avrdude/ avrdude home]). : :NB: The list of choices is generated by calling 'avrdude -c ?' and contains all the programmers your avrdude executable supports. ;Port :avrdude option '-P'. :Specify the port the programmer is connected to. Serial devices like ponyprog use for example ''/dev/ttyS0'' (= COM1 under Windows!), most modern programmers use ''usb''. : : Note that most old-style serial programmers will not work properly when connected to an USB-serial-Adapter! ; Extra verbose output :avrdude option '-v -v'. :Be more verbose. Default is '-v'. Use this, if you experience problems while flashing or simply want to see in detail whats going on... ;Do NOT verify after programming :avrdude option '-V'. :Do NOT verify flash memory after programming. Use with care and only if you're really sure that your setup is perfect. Speeds things up a bit but it's use is generally discouraged. ;Count # of erase cycles in EEPROM :avrdude option '-y'. :Tell avrdude to maintain an erase cycle counter in the last four bytes of the eeprom. The counter has to be initialized by calling avrdude with the option '-Y 1' once. : : Do not use this option if your e6 configuration uses the last four bytes of the eeprom. ;Bitclock for ISP or JTAG : ;Pass extra options to avrdude : == AVR Fuses == BIG FAT WARNING! [[Quick_Start_Guide/Configuration | previous step]] | 7b67f70a594fffc17d2ce5f481e736dc9b6cfacf 1110 1109 2013-07-16T06:07:29Z GooPie4o 265 /* AVRDUDE in makefile and menuconfig */ wikitext text/x-wiki {{i18n|Quick Start Guide/Flashing}} = Requirements = * the previously selected board, e.g. AVR NET-IO, ready built and (hopefully) tested * an ISP-Programmer of your choice supported by [http://www.nongnu.org/avrdude avrdude] * ISP connector cable = Flashing with avrdude = Avrdude offers several options. We will look on the most important, to make basic flashing of ethersex possible. * The chip you use, should be m32 for the ATMega32 in most cases: -p m32 * Debug messages: -v * The protocol spoken with the programmer, for the Evaluation-Board: -c ponyser * The serial port the programmer is connected to: -P /dev/ttyS0 * The command you want to execute: -U flash:w:ethersex.hex After you checked all options and adjusted them to your settings you should have a command like this: avrdude -v -p m32 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex = Writing the Bytes = * Disconnect the power from the NET-IO * Connect your ISP cable to the programmer and the Net-IO * Reconnect the power and connect your programmer to the PC * Execute the command you assembled earlier * Congratulations! If avrdude finished without any error you successfully flashed ethersex to your Net-IO! * Disconnect the power and the programmer from the Net-IO * Reconnect the power, your Net-IO should boot up with ethersex ---- = AVRDUDE in makefile and menuconfig = '''/* PAGE UNDER CONSTRUCTION */''' Since [https://github.com/ethersex/ethersex/commit/16c2a388ec775b51c049db1eeff3a8171c6ad71b 16c2a388ec] the [[Ethersex]] makefile supports two new targets, ''program'' and ''fuses'', to invoke avrdude. The target ''program'' calls avrdude with the options to flash the previously compiled ''ethersex.hex'' to the MCU. The ''fuses'' target may be used to program the MCUs fuse registers. <!-- REM: Note MCU/Freq settings has to be configured first. --> == AVRDUDE Configuration == If - and only if - the avrdude executable could be found in your ''PATH'', menuconfigs mainmenu will show an option to enter AVRDUDE configuration: [[File:avrdude_mainmenu.png]] [[File:avrdude_menu.png]] The AVRDUDE configuration page allows to setup the most common options for avrdude: ;Programmer Type :avrdude option '-c'. :Use the programmer configuration choosen from the list. : :Refer to the official avrdude documentation if you're in doubt about the correct choice for your programmer ([http://www.nongnu.org/avrdude/ avrdude home]). : :NB: The list of choices is generated by calling 'avrdude -c ?' and contains all the programmers your avrdude executable supports. ;Port :avrdude option '-P'. :Specify the port the programmer is connected to. Serial devices like ponyprog use for example ''/dev/ttyS0'' (= COM1 under Windows!), most modern programmers use ''usb''. : : Note that most old-style serial programmers will not work properly when connected to an USB-serial-Adapter! ; Extra verbose output :avrdude option '-v -v'. :Be more verbose. Default is '-v'. Use this, if you experience problems while flashing or simply want to see in detail whats going on... ;Do NOT verify after programming :avrdude option '-V'. :Do NOT verify flash memory after programming. Use with care and only if you're really sure that your setup is perfect. Speeds things up a bit but it's use is generally discouraged. ;Count # of erase cycles in EEPROM :avrdude option '-y'. :Tell avrdude to maintain an erase cycle counter in the last four bytes of the eeprom. The counter has to be initialized by calling avrdude with the option '-Y 1' once. : : Do not use this option if your e6 configuration uses the last four bytes of the eeprom. ;Bitclock for ISP or JTAG : ;Pass extra options to avrdude : == AVR Fuses == BIG FAT WARNING! [[Quick_Start_Guide/Configuration | previous step]] | e8330aa63a5c430d9a021e9a9b4117b2ee967c2d 1111 1110 2013-07-16T06:08:23Z GooPie4o 265 /* AVRDUDE Configuration */ wikitext text/x-wiki {{i18n|Quick Start Guide/Flashing}} = Requirements = * the previously selected board, e.g. AVR NET-IO, ready built and (hopefully) tested * an ISP-Programmer of your choice supported by [http://www.nongnu.org/avrdude avrdude] * ISP connector cable = Flashing with avrdude = Avrdude offers several options. We will look on the most important, to make basic flashing of ethersex possible. * The chip you use, should be m32 for the ATMega32 in most cases: -p m32 * Debug messages: -v * The protocol spoken with the programmer, for the Evaluation-Board: -c ponyser * The serial port the programmer is connected to: -P /dev/ttyS0 * The command you want to execute: -U flash:w:ethersex.hex After you checked all options and adjusted them to your settings you should have a command like this: avrdude -v -p m32 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex = Writing the Bytes = * Disconnect the power from the NET-IO * Connect your ISP cable to the programmer and the Net-IO * Reconnect the power and connect your programmer to the PC * Execute the command you assembled earlier * Congratulations! If avrdude finished without any error you successfully flashed ethersex to your Net-IO! * Disconnect the power and the programmer from the Net-IO * Reconnect the power, your Net-IO should boot up with ethersex ---- = AVRDUDE in makefile and menuconfig = '''/* PAGE UNDER CONSTRUCTION */''' Since [https://github.com/ethersex/ethersex/commit/16c2a388ec775b51c049db1eeff3a8171c6ad71b 16c2a388ec] the [[Ethersex]] makefile supports two new targets, ''program'' and ''fuses'', to invoke avrdude. The target ''program'' calls avrdude with the options to flash the previously compiled ''ethersex.hex'' to the MCU. The ''fuses'' target may be used to program the MCUs fuse registers. <!-- REM: Note MCU/Freq settings has to be configured first. --> == AVRDUDE Configuration == If - and only if - the avrdude executable could be found in your ''PATH'', menuconfig's mainmenu will show an option to enter AVRDUDE configuration: [[File:avrdude_mainmenu.png]] [[File:avrdude_menu.png]] The AVRDUDE configuration page allows to setup the most common options for avrdude: ;Programmer Type :avrdude option '-c'. :Use the programmer configuration choosen from the list. : :Refer to the official avrdude documentation if you're in doubt about the correct choice for your programmer ([http://www.nongnu.org/avrdude/ avrdude home]). : :NB: The list of choices is generated by calling 'avrdude -c ?' and contains all the programmers your avrdude executable supports. ;Port :avrdude option '-P'. :Specify the port the programmer is connected to. Serial devices like ponyprog use for example ''/dev/ttyS0'' (= COM1 under Windows!), most modern programmers use ''usb''. : : Note that most old-style serial programmers will not work properly when connected to an USB-serial-Adapter! ; Extra verbose output :avrdude option '-v -v'. :Be more verbose. Default is '-v'. Use this, if you experience problems while flashing or simply want to see in detail whats going on... ;Do NOT verify after programming :avrdude option '-V'. :Do NOT verify flash memory after programming. Use with care and only if you're really sure that your setup is perfect. Speeds things up a bit but it's use is generally discouraged. ;Count # of erase cycles in EEPROM :avrdude option '-y'. :Tell avrdude to maintain an erase cycle counter in the last four bytes of the eeprom. The counter has to be initialized by calling avrdude with the option '-Y 1' once. : : Do not use this option if your e6 configuration uses the last four bytes of the eeprom. ;Bitclock for ISP or JTAG : ;Pass extra options to avrdude : == AVR Fuses == BIG FAT WARNING! [[Quick_Start_Guide/Configuration | previous step]] | ac36b986da079e7f8fac832ad714ef1ae4e5d171 1112 1111 2013-07-16T07:24:21Z Michaelb 718 /* AVRDUDE Configuration */ wikitext text/x-wiki {{i18n|Quick Start Guide/Flashing}} = Requirements = * the previously selected board, e.g. AVR NET-IO, ready built and (hopefully) tested * an ISP-Programmer of your choice supported by [http://www.nongnu.org/avrdude avrdude] * ISP connector cable = Flashing with avrdude = Avrdude offers several options. We will look on the most important, to make basic flashing of ethersex possible. * The chip you use, should be m32 for the ATMega32 in most cases: -p m32 * Debug messages: -v * The protocol spoken with the programmer, for the Evaluation-Board: -c ponyser * The serial port the programmer is connected to: -P /dev/ttyS0 * The command you want to execute: -U flash:w:ethersex.hex After you checked all options and adjusted them to your settings you should have a command like this: avrdude -v -p m32 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex = Writing the Bytes = * Disconnect the power from the NET-IO * Connect your ISP cable to the programmer and the Net-IO * Reconnect the power and connect your programmer to the PC * Execute the command you assembled earlier * Congratulations! If avrdude finished without any error you successfully flashed ethersex to your Net-IO! * Disconnect the power and the programmer from the Net-IO * Reconnect the power, your Net-IO should boot up with ethersex ---- = AVRDUDE in makefile and menuconfig = '''/* PAGE UNDER CONSTRUCTION */''' Since [https://github.com/ethersex/ethersex/commit/16c2a388ec775b51c049db1eeff3a8171c6ad71b 16c2a388ec] the [[Ethersex]] makefile supports two new targets, ''program'' and ''fuses'', to invoke avrdude. The target ''program'' calls avrdude with the options to flash the previously compiled ''ethersex.hex'' to the MCU. The ''fuses'' target may be used to program the MCUs fuse registers. <!-- REM: Note MCU/Freq settings has to be configured first. --> == AVRDUDE Configuration == If - and only if - the avrdude executable could be found in your ''PATH'', menuconfig's mainmenu will show an option to enter AVRDUDE configuration: [[File:avrdude_mainmenu.png]] [[File:avrdude_menu.png]] The AVRDUDE configuration page allows to setup the most common options for avrdude: ;Programmer Type :avrdude option '-c'. :Use the programmer configuration choosen from the list. : :Refer to the official avrdude documentation if you're in doubt about the correct choice for your programmer ([http://www.nongnu.org/avrdude/ avrdude home]). : :NB: The list of choices is generated by calling 'avrdude -c ?' and contains all the programmers your avrdude executable supports. ;Port :avrdude option '-P'. :Specify the port the programmer is connected to. Serial devices like ponyprog use for example ''/dev/ttyS0'' (= COM1 under Windows!), most modern programmers use ''usb''. : : Note that most old-style serial programmers will not work properly when connected to an USB-serial-Adapter! ; Extra verbose output :avrdude option '-v -v'. :Be more verbose. Default is '-v'. Use this, if you experience problems while flashing or simply want to see in detail whats going on... ;Do NOT verify after programming :avrdude option '-V'. :Do NOT verify flash memory after programming. Use with care and only if you're really sure that your setup is perfect. Speeds things up a bit but it's use is generally discouraged. ;Count # of erase cycles in EEPROM :avrdude option '-y'. :Tell avrdude to maintain an erase cycle counter in the last four bytes of the eeprom. The counter has to be initialized by calling avrdude with the option '-Y 1' once. : : Do not use this option if your e6 configuration uses the last four bytes of the eeprom. ;Bitclock for ISP or JTAG :avrdude option '-B'. :Specify the bit clock period for the JTAG interface or the ISP clock. :Setting a lower value means higher programming speed. Use higher values if you experience programming errors in your setup. : : The available choices depend on the MCU frequency setting and should not exceed 4/F_CPU in micro seconds: : :*4 micro seconds is required for F_CPU < 4 MHz. :*1 micro second is appropriate for F_CPU < 10 MHz. :*0.5 micro seconds is appropriate for F_CPU < 16 MHz. :*0.3 micro seconds is appropriate for F_CPU >= 16 MHz. : ;Pass extra options to avrdude :If your programmer or setup requires any extra options to avrdude you may pass them here. == AVR Fuses == BIG FAT WARNING! [[Quick_Start_Guide/Configuration | previous step]] | 58c3890f17008d73a57920827ed1213b27b8a793 1113 1112 2013-07-16T07:38:14Z Michaelb 718 /* AVRDUDE in makefile and menuconfig */ wikitext text/x-wiki {{i18n|Quick Start Guide/Flashing}} = Requirements = * the previously selected board, e.g. AVR NET-IO, ready built and (hopefully) tested * an ISP-Programmer of your choice supported by [http://www.nongnu.org/avrdude avrdude] * ISP connector cable = Flashing with avrdude = Avrdude offers several options. We will look on the most important, to make basic flashing of ethersex possible. * The chip you use, should be m32 for the ATMega32 in most cases: -p m32 * Debug messages: -v * The protocol spoken with the programmer, for the Evaluation-Board: -c ponyser * The serial port the programmer is connected to: -P /dev/ttyS0 * The command you want to execute: -U flash:w:ethersex.hex After you checked all options and adjusted them to your settings you should have a command like this: avrdude -v -p m32 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex = Writing the Bytes = * Disconnect the power from the NET-IO * Connect your ISP cable to the programmer and the Net-IO * Reconnect the power and connect your programmer to the PC * Execute the command you assembled earlier * Congratulations! If avrdude finished without any error you successfully flashed ethersex to your Net-IO! * Disconnect the power and the programmer from the Net-IO * Reconnect the power, your Net-IO should boot up with ethersex ---- = AVRDUDE in makefile and menuconfig = '''/* PAGE UNDER CONSTRUCTION */''' Since [https://github.com/ethersex/ethersex/commit/16c2a388ec775b51c049db1eeff3a8171c6ad71b 16c2a388ec] the [[Ethersex]] makefile supports two new targets, ''program'' and ''fuses'', to invoke avrdude. The target ''program'' calls avrdude with the options to flash the previously compiled ''ethersex.hex'' to the MCU. The ''fuses'' target may be used to program the MCUs fuse registers. AVRDUDE options and MCU fuse register settings may be configured via a menuconfig dialog. All settings will be saved to the current profile ''.config''. Available settings and choices on the AVRDUDE configuration page depend on the MCU and clock frequency configured on the General Setup dialog. Please go back to the [[Quick_Start_Guide/Configuration | previous step]] if you haven't done that yet. == AVRDUDE Configuration == If - and only if - the avrdude executable could be found in your ''PATH'', menuconfig's mainmenu will show an option to enter AVRDUDE configuration: [[File:avrdude_mainmenu.png]] [[File:avrdude_menu.png]] The AVRDUDE configuration page allows to setup the most common options for avrdude: ;Programmer Type :avrdude option '-c'. :Use the programmer configuration choosen from the list. : :Refer to the official avrdude documentation if you're in doubt about the correct choice for your programmer ([http://www.nongnu.org/avrdude/ avrdude home]). : :NB: The list of choices is generated by calling 'avrdude -c ?' and contains all the programmers your avrdude executable supports. ;Port :avrdude option '-P'. :Specify the port the programmer is connected to. Serial devices like ponyprog use for example ''/dev/ttyS0'' (= COM1 under Windows!), most modern programmers use ''usb''. : : Note that most old-style serial programmers will not work properly when connected to an USB-serial-Adapter! ; Extra verbose output :avrdude option '-v -v'. :Be more verbose. Default is '-v'. Use this, if you experience problems while flashing or simply want to see in detail whats going on... ;Do NOT verify after programming :avrdude option '-V'. :Do NOT verify flash memory after programming. Use with care and only if you're really sure that your setup is perfect. Speeds things up a bit but it's use is generally discouraged. ;Count # of erase cycles in EEPROM :avrdude option '-y'. :Tell avrdude to maintain an erase cycle counter in the last four bytes of the eeprom. The counter has to be initialized by calling avrdude with the option '-Y 1' once. : : Do not use this option if your e6 configuration uses the last four bytes of the eeprom. ;Bitclock for ISP or JTAG :avrdude option '-B'. :Specify the bit clock period for the JTAG interface or the ISP clock. :Setting a lower value means higher programming speed. Use higher values if you experience programming errors in your setup. : : The available choices depend on the MCU frequency setting and should not exceed 4/F_CPU in micro seconds: : :*4 micro seconds is required for F_CPU < 4 MHz. :*1 micro second is appropriate for F_CPU < 10 MHz. :*0.5 micro seconds is appropriate for F_CPU < 16 MHz. :*0.3 micro seconds is appropriate for F_CPU >= 16 MHz. : ;Pass extra options to avrdude :If your programmer or setup requires any extra options to avrdude you may pass them here. == AVR Fuses == BIG FAT WARNING! [[Quick_Start_Guide/Configuration | previous step]] | 22267a6e2c1911aeb5a053b5c1261ec78e704cb6 1114 1113 2013-07-17T20:18:12Z Michaelb 718 /* AVR Fuses */ wikitext text/x-wiki {{i18n|Quick Start Guide/Flashing}} = Requirements = * the previously selected board, e.g. AVR NET-IO, ready built and (hopefully) tested * an ISP-Programmer of your choice supported by [http://www.nongnu.org/avrdude avrdude] * ISP connector cable = Flashing with avrdude = Avrdude offers several options. We will look on the most important, to make basic flashing of ethersex possible. * The chip you use, should be m32 for the ATMega32 in most cases: -p m32 * Debug messages: -v * The protocol spoken with the programmer, for the Evaluation-Board: -c ponyser * The serial port the programmer is connected to: -P /dev/ttyS0 * The command you want to execute: -U flash:w:ethersex.hex After you checked all options and adjusted them to your settings you should have a command like this: avrdude -v -p m32 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex = Writing the Bytes = * Disconnect the power from the NET-IO * Connect your ISP cable to the programmer and the Net-IO * Reconnect the power and connect your programmer to the PC * Execute the command you assembled earlier * Congratulations! If avrdude finished without any error you successfully flashed ethersex to your Net-IO! * Disconnect the power and the programmer from the Net-IO * Reconnect the power, your Net-IO should boot up with ethersex ---- = AVRDUDE in makefile and menuconfig = '''/* PAGE UNDER CONSTRUCTION */''' Since [https://github.com/ethersex/ethersex/commit/16c2a388ec775b51c049db1eeff3a8171c6ad71b 16c2a388ec] the [[Ethersex]] makefile supports two new targets, ''program'' and ''fuses'', to invoke avrdude. The target ''program'' calls avrdude with the options to flash the previously compiled ''ethersex.hex'' to the MCU. The ''fuses'' target may be used to program the MCUs fuse registers. AVRDUDE options and MCU fuse register settings may be configured via a menuconfig dialog. All settings will be saved to the current profile ''.config''. Available settings and choices on the AVRDUDE configuration page depend on the MCU and clock frequency configured on the General Setup dialog. Please go back to the [[Quick_Start_Guide/Configuration | previous step]] if you haven't done that yet. == AVRDUDE Configuration == If - and only if - the avrdude executable could be found in your ''PATH'', menuconfig's mainmenu will show an option to enter AVRDUDE configuration: [[File:avrdude_mainmenu.png]] [[File:avrdude_menu.png]] The AVRDUDE configuration page allows to setup the most common options for avrdude: ;Programmer Type :avrdude option '-c'. :Use the programmer configuration choosen from the list. : :Refer to the official avrdude documentation if you're in doubt about the correct choice for your programmer ([http://www.nongnu.org/avrdude/ avrdude home]). : :NB: The list of choices is generated by calling 'avrdude -c ?' and contains all the programmers your avrdude executable supports. ;Port :avrdude option '-P'. :Specify the port the programmer is connected to. Serial devices like ponyprog use for example ''/dev/ttyS0'' (= COM1 under Windows!), most modern programmers use ''usb''. : : Note that most old-style serial programmers will not work properly when connected to an USB-serial-Adapter! ; Extra verbose output :avrdude option '-v -v'. :Be more verbose. Default is '-v'. Use this, if you experience problems while flashing or simply want to see in detail whats going on... ;Do NOT verify after programming :avrdude option '-V'. :Do NOT verify flash memory after programming. Use with care and only if you're really sure that your setup is perfect. Speeds things up a bit but it's use is generally discouraged. ;Count # of erase cycles in EEPROM :avrdude option '-y'. :Tell avrdude to maintain an erase cycle counter in the last four bytes of the eeprom. The counter has to be initialized by calling avrdude with the option '-Y 1' once. : : Do not use this option if your e6 configuration uses the last four bytes of the eeprom. ;Bitclock for ISP or JTAG :avrdude option '-B'. :Specify the bit clock period for the JTAG interface or the ISP clock. :Setting a lower value means higher programming speed. Use higher values if you experience programming errors in your setup. : : The available choices depend on the MCU frequency setting and should not exceed 4/F_CPU in micro seconds: : :*4 micro seconds is required for F_CPU < 4 MHz. :*1 micro second is appropriate for F_CPU < 10 MHz. :*0.5 micro seconds is appropriate for F_CPU < 16 MHz. :*0.3 micro seconds is appropriate for F_CPU >= 16 MHz. : ;Pass extra options to avrdude :If your programmer or setup requires any extra options to avrdude you may pass them here. == AVR Fuses == The fuse registers enable/disable or control the basic functionality of the different units of the MCU. One can e. g. enable or disable the Watchdog, the JTAG interface or even the ISP Interface. Configuration of the MCUs clock source or the brown-out detector is also done via the fuse registers. '''WARNING: Programming wrong fuse values may render your MCU UNUSABLE''' (...unless you've access to a JTAG- and/or HV-Programmer.) '''There is nothing like ''the universal correct fuse setting'' or a ''default fuse setting''. Fuse registers are MCU-specific and their correct settings heavily depend on the circuit and parts in use. Be careful and read the datasheet for the MCU acually in use and think twice what is correct for YOUR hardware!!''' ;Fuse Low Byte (FLB) :AVR Fuse Low Byte, two-digit hex value. : ;Fuse High Byte (FHB) :AVR Fuse High Byte, two-digit hex value. : ;Extended Fuse Byte (EFB) :AVR Extended Fuse Byte, two-digit hex value. The necessary hex values for the fuse registers might be calculated with e.g. an online [http://www.engbedded.com/fusecalc AVR fuse calculator]. [http://www.mikrocontroller.net/articles/AVR_Fuses Article on mikrocontroller.net for reference (german only, sorry).] [[Quick_Start_Guide/Configuration | previous step]] | 00ef0982c1533ae157f1be0aa4c94f332082df5e 1115 1114 2013-07-17T20:20:03Z Michaelb 718 /* AVR Fuses */ wikitext text/x-wiki {{i18n|Quick Start Guide/Flashing}} = Requirements = * the previously selected board, e.g. AVR NET-IO, ready built and (hopefully) tested * an ISP-Programmer of your choice supported by [http://www.nongnu.org/avrdude avrdude] * ISP connector cable = Flashing with avrdude = Avrdude offers several options. We will look on the most important, to make basic flashing of ethersex possible. * The chip you use, should be m32 for the ATMega32 in most cases: -p m32 * Debug messages: -v * The protocol spoken with the programmer, for the Evaluation-Board: -c ponyser * The serial port the programmer is connected to: -P /dev/ttyS0 * The command you want to execute: -U flash:w:ethersex.hex After you checked all options and adjusted them to your settings you should have a command like this: avrdude -v -p m32 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex = Writing the Bytes = * Disconnect the power from the NET-IO * Connect your ISP cable to the programmer and the Net-IO * Reconnect the power and connect your programmer to the PC * Execute the command you assembled earlier * Congratulations! If avrdude finished without any error you successfully flashed ethersex to your Net-IO! * Disconnect the power and the programmer from the Net-IO * Reconnect the power, your Net-IO should boot up with ethersex ---- = AVRDUDE in makefile and menuconfig = '''/* PAGE UNDER CONSTRUCTION */''' Since [https://github.com/ethersex/ethersex/commit/16c2a388ec775b51c049db1eeff3a8171c6ad71b 16c2a388ec] the [[Ethersex]] makefile supports two new targets, ''program'' and ''fuses'', to invoke avrdude. The target ''program'' calls avrdude with the options to flash the previously compiled ''ethersex.hex'' to the MCU. The ''fuses'' target may be used to program the MCUs fuse registers. AVRDUDE options and MCU fuse register settings may be configured via a menuconfig dialog. All settings will be saved to the current profile ''.config''. Available settings and choices on the AVRDUDE configuration page depend on the MCU and clock frequency configured on the General Setup dialog. Please go back to the [[Quick_Start_Guide/Configuration | previous step]] if you haven't done that yet. == AVRDUDE Configuration == If - and only if - the avrdude executable could be found in your ''PATH'', menuconfig's mainmenu will show an option to enter AVRDUDE configuration: [[File:avrdude_mainmenu.png]] [[File:avrdude_menu.png]] The AVRDUDE configuration page allows to setup the most common options for avrdude: ;Programmer Type :avrdude option '-c'. :Use the programmer configuration choosen from the list. : :Refer to the official avrdude documentation if you're in doubt about the correct choice for your programmer ([http://www.nongnu.org/avrdude/ avrdude home]). : :NB: The list of choices is generated by calling 'avrdude -c ?' and contains all the programmers your avrdude executable supports. ;Port :avrdude option '-P'. :Specify the port the programmer is connected to. Serial devices like ponyprog use for example ''/dev/ttyS0'' (= COM1 under Windows!), most modern programmers use ''usb''. : : Note that most old-style serial programmers will not work properly when connected to an USB-serial-Adapter! ; Extra verbose output :avrdude option '-v -v'. :Be more verbose. Default is '-v'. Use this, if you experience problems while flashing or simply want to see in detail whats going on... ;Do NOT verify after programming :avrdude option '-V'. :Do NOT verify flash memory after programming. Use with care and only if you're really sure that your setup is perfect. Speeds things up a bit but it's use is generally discouraged. ;Count # of erase cycles in EEPROM :avrdude option '-y'. :Tell avrdude to maintain an erase cycle counter in the last four bytes of the eeprom. The counter has to be initialized by calling avrdude with the option '-Y 1' once. : : Do not use this option if your e6 configuration uses the last four bytes of the eeprom. ;Bitclock for ISP or JTAG :avrdude option '-B'. :Specify the bit clock period for the JTAG interface or the ISP clock. :Setting a lower value means higher programming speed. Use higher values if you experience programming errors in your setup. : : The available choices depend on the MCU frequency setting and should not exceed 4/F_CPU in micro seconds: : :*4 micro seconds is required for F_CPU < 4 MHz. :*1 micro second is appropriate for F_CPU < 10 MHz. :*0.5 micro seconds is appropriate for F_CPU < 16 MHz. :*0.3 micro seconds is appropriate for F_CPU >= 16 MHz. : ;Pass extra options to avrdude :If your programmer or setup requires any extra options to avrdude you may pass them here. == AVR Fuses == The fuse registers enable/disable or control the basic functionality of the different units of the MCU. One can e. g. enable or disable the Watchdog, the JTAG interface or even the ISP Interface. Configuration of the MCUs clock source or the brown-out detector is also done via the fuse registers. '''WARNING: Programming wrong fuse values may render your MCU UNUSABLE''' (...unless you've access to a JTAG- and/or HV-Programmer.) '''There is nothing like ''the universal correct fuse setting'' or ''default fuse setting''. Fuse registers are MCU-specific and their correct settings heavily depend on the circuit and parts in use. Be careful, read the datasheet for the MCU acually in use and think twice what is correct for YOUR hardware!!''' ;Fuse Low Byte (FLB) :AVR Fuse Low Byte, two-digit hex value. : ;Fuse High Byte (FHB) :AVR Fuse High Byte, two-digit hex value. : ;Extended Fuse Byte (EFB) :AVR Extended Fuse Byte, two-digit hex value. The necessary hex values for the fuse registers might be calculated with e.g. an online [http://www.engbedded.com/fusecalc AVR fuse calculator]. [http://www.mikrocontroller.net/articles/AVR_Fuses Article on mikrocontroller.net for reference (german only, sorry).] [[Quick_Start_Guide/Configuration | previous step]] | 490d4d4f9ebea7b72539bb503c42c7cd4d09c2d2 1116 1115 2013-07-17T20:26:11Z Michaelb 718 /* Requirements */ wikitext text/x-wiki {{i18n|Quick Start Guide/Flashing}} == Requirements == * the previously selected board, e.g. AVR NET-IO, ready built and (hopefully) tested * an ISP-Programmer of your choice supported by [http://www.nongnu.org/avrdude avrdude] * ISP connector cable = Flashing with avrdude = Avrdude offers several options. We will look on the most important, to make basic flashing of ethersex possible. * The chip you use, should be m32 for the ATMega32 in most cases: -p m32 * Debug messages: -v * The protocol spoken with the programmer, for the Evaluation-Board: -c ponyser * The serial port the programmer is connected to: -P /dev/ttyS0 * The command you want to execute: -U flash:w:ethersex.hex After you checked all options and adjusted them to your settings you should have a command like this: avrdude -v -p m32 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex = Writing the Bytes = * Disconnect the power from the NET-IO * Connect your ISP cable to the programmer and the Net-IO * Reconnect the power and connect your programmer to the PC * Execute the command you assembled earlier * Congratulations! If avrdude finished without any error you successfully flashed ethersex to your Net-IO! * Disconnect the power and the programmer from the Net-IO * Reconnect the power, your Net-IO should boot up with ethersex ---- = AVRDUDE in makefile and menuconfig = '''/* PAGE UNDER CONSTRUCTION */''' Since [https://github.com/ethersex/ethersex/commit/16c2a388ec775b51c049db1eeff3a8171c6ad71b 16c2a388ec] the [[Ethersex]] makefile supports two new targets, ''program'' and ''fuses'', to invoke avrdude. The target ''program'' calls avrdude with the options to flash the previously compiled ''ethersex.hex'' to the MCU. The ''fuses'' target may be used to program the MCUs fuse registers. AVRDUDE options and MCU fuse register settings may be configured via a menuconfig dialog. All settings will be saved to the current profile ''.config''. Available settings and choices on the AVRDUDE configuration page depend on the MCU and clock frequency configured on the General Setup dialog. Please go back to the [[Quick_Start_Guide/Configuration | previous step]] if you haven't done that yet. == AVRDUDE Configuration == If - and only if - the avrdude executable could be found in your ''PATH'', menuconfig's mainmenu will show an option to enter AVRDUDE configuration: [[File:avrdude_mainmenu.png]] [[File:avrdude_menu.png]] The AVRDUDE configuration page allows to setup the most common options for avrdude: ;Programmer Type :avrdude option '-c'. :Use the programmer configuration choosen from the list. : :Refer to the official avrdude documentation if you're in doubt about the correct choice for your programmer ([http://www.nongnu.org/avrdude/ avrdude home]). : :NB: The list of choices is generated by calling 'avrdude -c ?' and contains all the programmers your avrdude executable supports. ;Port :avrdude option '-P'. :Specify the port the programmer is connected to. Serial devices like ponyprog use for example ''/dev/ttyS0'' (= COM1 under Windows!), most modern programmers use ''usb''. : : Note that most old-style serial programmers will not work properly when connected to an USB-serial-Adapter! ; Extra verbose output :avrdude option '-v -v'. :Be more verbose. Default is '-v'. Use this, if you experience problems while flashing or simply want to see in detail whats going on... ;Do NOT verify after programming :avrdude option '-V'. :Do NOT verify flash memory after programming. Use with care and only if you're really sure that your setup is perfect. Speeds things up a bit but it's use is generally discouraged. ;Count # of erase cycles in EEPROM :avrdude option '-y'. :Tell avrdude to maintain an erase cycle counter in the last four bytes of the eeprom. The counter has to be initialized by calling avrdude with the option '-Y 1' once. : : Do not use this option if your e6 configuration uses the last four bytes of the eeprom. ;Bitclock for ISP or JTAG :avrdude option '-B'. :Specify the bit clock period for the JTAG interface or the ISP clock. :Setting a lower value means higher programming speed. Use higher values if you experience programming errors in your setup. : : The available choices depend on the MCU frequency setting and should not exceed 4/F_CPU in micro seconds: : :*4 micro seconds is required for F_CPU < 4 MHz. :*1 micro second is appropriate for F_CPU < 10 MHz. :*0.5 micro seconds is appropriate for F_CPU < 16 MHz. :*0.3 micro seconds is appropriate for F_CPU >= 16 MHz. : ;Pass extra options to avrdude :If your programmer or setup requires any extra options to avrdude you may pass them here. == AVR Fuses == The fuse registers enable/disable or control the basic functionality of the different units of the MCU. One can e. g. enable or disable the Watchdog, the JTAG interface or even the ISP Interface. Configuration of the MCUs clock source or the brown-out detector is also done via the fuse registers. '''WARNING: Programming wrong fuse values may render your MCU UNUSABLE''' (...unless you've access to a JTAG- and/or HV-Programmer.) '''There is nothing like ''the universal correct fuse setting'' or ''default fuse setting''. Fuse registers are MCU-specific and their correct settings heavily depend on the circuit and parts in use. Be careful, read the datasheet for the MCU acually in use and think twice what is correct for YOUR hardware!!''' ;Fuse Low Byte (FLB) :AVR Fuse Low Byte, two-digit hex value. : ;Fuse High Byte (FHB) :AVR Fuse High Byte, two-digit hex value. : ;Extended Fuse Byte (EFB) :AVR Extended Fuse Byte, two-digit hex value. The necessary hex values for the fuse registers might be calculated with e.g. an online [http://www.engbedded.com/fusecalc AVR fuse calculator]. [http://www.mikrocontroller.net/articles/AVR_Fuses Article on mikrocontroller.net for reference (german only, sorry).] [[Quick_Start_Guide/Configuration | previous step]] | b875221d64e7c485889c1089c3e09268bd473e43 1117 1116 2013-07-17T20:55:13Z Michaelb 718 wikitext text/x-wiki {{i18n|Quick Start Guide/Flashing}} = Flashing = == Prerequisites == * the previously selected board, e.g. AVR NET-IO, ready built and (hopefully) tested * an ISP-Programmer of your choice supported by [http://www.nongnu.org/avrdude avrdude] * an ISP connector cable that fits to your programmer and your board (either 6 or 10-pin) * an ethersex.hex compiled in the [[Quick_Start_Guide/Configuration | previous step]] If you have an ISP-Programmer with a 6-pin port and a board with a 10-pin header - like the AVR NET-IO - you can create an adapter. You can see the pin configuration in figure 4-1 at page 5 [http://www.atmel.com/dyn/resources/prod_documents/doc2521.pdf AVR042: AVR Hardware Design Considerations]. Note that Pin 4 of the 10-pin connector is not used on the AVR NET-IO. GND has to be connected to one of the other Pins (6, 8 or 10). == Flashing the image with avrdude == After compiling the ethersex.hex you can flash it with avrdude. The following commands depend on your ISP-Programmer. This example is for a serial connection (e.g. the ATMEL Evaluation-Board): avrdude -v -p m32 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex This example for a real USB ISP-Programmer: avrdude -p m1284p -c avrispmkII -P usb -U flash:w:ethersex.hex For a serial programmer connected via an USB-serial-adapter this may be used: avrdude -v -p m32 -c stk500v2 -P /dev/ttyACM0 -U flash:w:ethersex.hex And this one for a parallel ISP-Cable: avrdude -p m32 -e -c stk200 -U flash:w:ethersex.hex After flashing remove the ISP-Cable and interrupt the power connection for a short time to reboot the board. * -p m32: ATMega32; -p m644: ATMega644; -p ? to list the valid parts * -v: display debug messages * -c ponyser: traditional serial programmer; -c stkk500v2 for the Atmel board * -P /dev/tty.serial the serial port your programmer is connected to; -P COM1 for windows machines; -P usb for USB * -U the command you want to execute. In our case we want to flash: -U flash:w:ethersex.hex == Writing the Bytes == * Disconnect the power from the NET-IO * Connect your ISP cable to the programmer and the Net-IO * Reconnect the power and connect your programmer to the PC * Execute the command you assembled earlier * Congratulations! If avrdude finished without any error you successfully flashed ethersex to your Net-IO! * Disconnect the power and the programmer from the Net-IO * Reconnect the power, your Net-IO should boot up with ethersex ---- == Using avrdude from the makefile == Since [https://github.com/ethersex/ethersex/commit/16c2a388ec775b51c049db1eeff3a8171c6ad71b 16c2a388ec] the [[Ethersex]] makefile supports two new targets, ''program'' and ''fuses'', to invoke avrdude. The target ''program'' calls avrdude with the options to flash the previously compiled ''ethersex.hex'' to the MCU. The ''fuses'' target may be used to program the MCUs fuse registers. AVRDUDE options and MCU fuse register settings may be configured via a menuconfig dialog. All settings will be saved to the current profile ''.config''. Available settings and choices on the AVRDUDE configuration page depend on the MCU and clock frequency configured on the General Setup dialog. Please go back to the [[Quick_Start_Guide/Configuration | previous step]] if you haven't done that yet. === AVRDUDE Configuration === If - and only if - the avrdude executable could be found in your ''PATH'', menuconfig's mainmenu will show an option to enter AVRDUDE configuration: [[File:avrdude_mainmenu.png]] [[File:avrdude_menu.png]] The AVRDUDE configuration page allows to setup the most common options for avrdude: ;Programmer Type :avrdude option '-c'. :Use the programmer configuration choosen from the list. : :Refer to the official avrdude documentation if you're in doubt about the correct choice for your programmer ([http://www.nongnu.org/avrdude/ avrdude home]). : :NB: The list of choices is generated by calling 'avrdude -c ?' and contains all the programmers your avrdude executable supports. ;Port :avrdude option '-P'. :Specify the port the programmer is connected to. Serial devices like ponyprog use for example ''/dev/ttyS0'' (= COM1 under Windows!), most modern programmers use ''usb''. : : Note that most old-style serial programmers will not work properly when connected to an USB-serial-Adapter! ; Extra verbose output :avrdude option '-v -v'. :Be more verbose. Default is '-v'. Use this, if you experience problems while flashing or simply want to see in detail whats going on... ;Do NOT verify after programming :avrdude option '-V'. :Do NOT verify flash memory after programming. Use with care and only if you're really sure that your setup is perfect. Speeds things up a bit but it's use is generally discouraged. ;Count # of erase cycles in EEPROM :avrdude option '-y'. :Tell avrdude to maintain an erase cycle counter in the last four bytes of the eeprom. The counter has to be initialized by calling avrdude with the option '-Y 1' once. : : Do not use this option if your e6 configuration uses the last four bytes of the eeprom. ;Bitclock for ISP or JTAG :avrdude option '-B'. :Specify the bit clock period for the JTAG interface or the ISP clock. :Setting a lower value means higher programming speed. Use higher values if you experience programming errors in your setup. : : The available choices depend on the MCU frequency setting and should not exceed 4/F_CPU in micro seconds: : :*4 micro seconds is required for F_CPU < 4 MHz. :*1 micro second is appropriate for F_CPU < 10 MHz. :*0.5 micro seconds is appropriate for F_CPU < 16 MHz. :*0.3 micro seconds is appropriate for F_CPU >= 16 MHz. : ;Pass extra options to avrdude :If your programmer or setup requires any extra options to avrdude you may pass them here. === AVR Fuses === The fuse registers enable/disable or control the basic functionality of the different units of the MCU. One can e. g. enable or disable the Watchdog, the JTAG interface or even the ISP Interface. Configuration of the MCUs clock source or the brown-out detector is also done via the fuse registers. '''WARNING: Programming wrong fuse values may render your MCU UNUSABLE''' (...unless you've access to a JTAG- and/or HV-Programmer.) '''There is nothing like ''the universal correct fuse setting'' or ''default fuse setting''. Fuse registers are MCU-specific and their correct settings heavily depend on the circuit and parts in use. Be careful, read the datasheet for the MCU acually in use and think twice what is correct for YOUR hardware!!''' ;Fuse Low Byte (FLB) :AVR Fuse Low Byte, two-digit hex value. : ;Fuse High Byte (FHB) :AVR Fuse High Byte, two-digit hex value. : ;Extended Fuse Byte (EFB) :AVR Extended Fuse Byte, two-digit hex value. The necessary hex values for the fuse registers might be calculated with e.g. an online [http://www.engbedded.com/fusecalc AVR fuse calculator]. [http://www.mikrocontroller.net/articles/AVR_Fuses Article on mikrocontroller.net for reference (german only, sorry).] [[Quick_Start_Guide/Configuration | previous step]] | 3b46d82fd6141168fd7fd43f00cdbf3d446780d5 1118 1117 2013-07-17T20:57:38Z Michaelb 718 wikitext text/x-wiki {{i18n|Quick Start Guide/Flashing}} = Flashing = After compiling the ethersex.hex you can flash it with avrdude. == Prerequisites == * the previously selected board, e.g. AVR NET-IO, ready built and (hopefully) tested * an ISP-Programmer of your choice supported by [http://www.nongnu.org/avrdude avrdude] * an ISP connector cable that fits to your programmer and your board (either 6 or 10-pin) * an ethersex.hex compiled in the [[Quick_Start_Guide/Configuration | previous step]] If you have an ISP-Programmer with a 6-pin port and a board with a 10-pin header - like the AVR NET-IO - you can create an adapter. You can see the pin configuration in figure 4-1 at page 5 [http://www.atmel.com/dyn/resources/prod_documents/doc2521.pdf AVR042: AVR Hardware Design Considerations]. Note that Pin 4 of the 10-pin connector is not used on the AVR NET-IO. GND has to be connected to one of the other Pins (6, 8 or 10). == Flashing the image with avrdude == The following commands are just examples, the actual command line depends on your ISP-Programmer and hardware. This example is for a serial connection (e.g. the ATMEL Evaluation-Board): avrdude -v -p m32 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex This example for a real USB ISP-Programmer: avrdude -p m1284p -c avrispmkII -P usb -U flash:w:ethersex.hex For a serial programmer connected via an USB-serial-adapter this may be used: avrdude -v -p m32 -c stk500v2 -P /dev/ttyACM0 -U flash:w:ethersex.hex And this one for a parallel ISP-Cable: avrdude -p m32 -e -c stk200 -U flash:w:ethersex.hex After flashing remove the ISP-Cable and interrupt the power connection for a short time to reboot the board. * -p m32: ATMega32; -p m644: ATMega644; -p ? to list the valid parts * -v: display debug messages * -c ponyser: traditional serial programmer; -c stkk500v2 for the Atmel board * -P /dev/tty.serial the serial port your programmer is connected to; -P COM1 for windows machines; -P usb for USB * -U the command you want to execute. In our case we want to flash: -U flash:w:ethersex.hex === Writing the Bytes === * Disconnect the power from the NET-IO * Connect your ISP cable to the programmer and the Net-IO * Reconnect the power and connect your programmer to the PC * Execute the command you assembled earlier * Congratulations! If avrdude finished without any error you successfully flashed ethersex to your Net-IO! * Disconnect the power and the programmer from the Net-IO * Reconnect the power, your Net-IO should boot up with ethersex ---- == Using avrdude from the makefile == Since [https://github.com/ethersex/ethersex/commit/16c2a388ec775b51c049db1eeff3a8171c6ad71b 16c2a388ec] the [[Ethersex]] makefile supports two new targets, ''program'' and ''fuses'', to invoke avrdude. The target ''program'' calls avrdude with the options to flash the previously compiled ''ethersex.hex'' to the MCU. The ''fuses'' target may be used to program the MCUs fuse registers. AVRDUDE options and MCU fuse register settings may be configured via a menuconfig dialog. All settings will be saved to the current profile ''.config''. Available settings and choices on the AVRDUDE configuration page depend on the MCU and clock frequency configured on the General Setup dialog. Please go back to the [[Quick_Start_Guide/Configuration | previous step]] if you haven't done that yet. === AVRDUDE Configuration === If - and only if - the avrdude executable could be found in your ''PATH'', menuconfig's mainmenu will show an option to enter AVRDUDE configuration: [[File:avrdude_mainmenu.png]] [[File:avrdude_menu.png]] The AVRDUDE configuration page allows to setup the most common options for avrdude: ;Programmer Type :avrdude option '-c'. :Use the programmer configuration choosen from the list. : :Refer to the official avrdude documentation if you're in doubt about the correct choice for your programmer ([http://www.nongnu.org/avrdude/ avrdude home]). : :NB: The list of choices is generated by calling 'avrdude -c ?' and contains all the programmers your avrdude executable supports. ;Port :avrdude option '-P'. :Specify the port the programmer is connected to. Serial devices like ponyprog use for example ''/dev/ttyS0'' (= COM1 under Windows!), most modern programmers use ''usb''. : : Note that most old-style serial programmers will not work properly when connected to an USB-serial-Adapter! ; Extra verbose output :avrdude option '-v -v'. :Be more verbose. Default is '-v'. Use this, if you experience problems while flashing or simply want to see in detail whats going on... ;Do NOT verify after programming :avrdude option '-V'. :Do NOT verify flash memory after programming. Use with care and only if you're really sure that your setup is perfect. Speeds things up a bit but it's use is generally discouraged. ;Count # of erase cycles in EEPROM :avrdude option '-y'. :Tell avrdude to maintain an erase cycle counter in the last four bytes of the eeprom. The counter has to be initialized by calling avrdude with the option '-Y 1' once. : : Do not use this option if your e6 configuration uses the last four bytes of the eeprom. ;Bitclock for ISP or JTAG :avrdude option '-B'. :Specify the bit clock period for the JTAG interface or the ISP clock. :Setting a lower value means higher programming speed. Use higher values if you experience programming errors in your setup. : : The available choices depend on the MCU frequency setting and should not exceed 4/F_CPU in micro seconds: : :*4 micro seconds is required for F_CPU < 4 MHz. :*1 micro second is appropriate for F_CPU < 10 MHz. :*0.5 micro seconds is appropriate for F_CPU < 16 MHz. :*0.3 micro seconds is appropriate for F_CPU >= 16 MHz. : ;Pass extra options to avrdude :If your programmer or setup requires any extra options to avrdude you may pass them here. === AVR Fuses === The fuse registers enable/disable or control the basic functionality of the different units of the MCU. One can e. g. enable or disable the Watchdog, the JTAG interface or even the ISP Interface. Configuration of the MCUs clock source or the brown-out detector is also done via the fuse registers. '''WARNING: Programming wrong fuse values may render your MCU UNUSABLE''' (...unless you've access to a JTAG- and/or HV-Programmer.) '''There is nothing like ''the universal correct fuse setting'' or ''default fuse setting''. Fuse registers are MCU-specific and their correct settings heavily depend on the circuit and parts in use. Be careful, read the datasheet for the MCU acually in use and think twice what is correct for YOUR hardware!!''' ;Fuse Low Byte (FLB) :AVR Fuse Low Byte, two-digit hex value. : ;Fuse High Byte (FHB) :AVR Fuse High Byte, two-digit hex value. : ;Extended Fuse Byte (EFB) :AVR Extended Fuse Byte, two-digit hex value. The necessary hex values for the fuse registers might be calculated with e.g. an online [http://www.engbedded.com/fusecalc AVR fuse calculator]. [http://www.mikrocontroller.net/articles/AVR_Fuses Article on mikrocontroller.net for reference (german only, sorry).] [[Quick_Start_Guide/Configuration | previous step]] | 1210edc45eff2af737f40b20916f0053ebf90f34 1119 1118 2013-07-17T21:00:05Z Michaelb 718 wikitext text/x-wiki {{i18n|Quick Start Guide/Flashing}} = Flashing = After compiling the ethersex.hex you can flash it with avrdude. == Prerequisites == * the previously selected board, e.g. AVR NET-IO, ready built and (hopefully) tested * an ISP-Programmer of your choice supported by [http://www.nongnu.org/avrdude avrdude] * an ISP connector cable that fits to your programmer and your board (either 6 or 10-pin) * an ethersex.hex compiled in the [[Quick_Start_Guide/Configuration | previous step]] If you have an ISP-Programmer with a 6-pin port and a board with a 10-pin header - like the AVR NET-IO - you can create an adapter. You can see the pin configuration in figure 4-1 at page 5 [http://www.atmel.com/dyn/resources/prod_documents/doc2521.pdf AVR042: AVR Hardware Design Considerations]. Note that Pin 4 of the 10-pin connector is not used on the AVR NET-IO. GND has to be connected to one of the other Pins (6, 8 or 10). == Flashing the image with avrdude == The following commands are just examples, the actual command line depends on your ISP-Programmer and hardware. This example is for a serial connection (e.g. the ATMEL Evaluation-Board): avrdude -v -p m32 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex This example for a real USB ISP-Programmer: avrdude -p m1284p -c avrispmkII -P usb -U flash:w:ethersex.hex For a serial programmer connected via an USB-serial-adapter this may be used: avrdude -v -p m32 -c stk500v2 -P /dev/ttyACM0 -U flash:w:ethersex.hex And this one for a parallel ISP-Cable: avrdude -p m32 -e -c stk200 -U flash:w:ethersex.hex After flashing remove the ISP-Cable and interrupt the power connection for a short time to reboot the board. * -p m32: ATMega32; -p m644: ATMega644; -p ? to list the valid parts * -v: display debug messages * -c ponyser: traditional serial programmer; -c stkk500v2 for the Atmel board * -P /dev/tty.serial the serial port your programmer is connected to; -P COM1 for windows machines; -P usb for USB * -U the command you want to execute. In our case we want to flash: -U flash:w:ethersex.hex == Using avrdude from the makefile == Since [https://github.com/ethersex/ethersex/commit/16c2a388ec775b51c049db1eeff3a8171c6ad71b 16c2a388ec] the [[Ethersex]] makefile supports two new targets, ''program'' and ''fuses'', to invoke avrdude. The target ''program'' calls avrdude with the options to flash the previously compiled ''ethersex.hex'' to the MCU. The ''fuses'' target may be used to program the MCUs fuse registers. AVRDUDE options and MCU fuse register settings may be configured via a menuconfig dialog. All settings will be saved to the current profile ''.config''. Available settings and choices on the AVRDUDE configuration page depend on the MCU and clock frequency configured on the General Setup dialog. Please go back to the [[Quick_Start_Guide/Configuration | previous step]] if you haven't done that yet. === AVRDUDE Configuration === If - and only if - the avrdude executable could be found in your ''PATH'', menuconfig's mainmenu will show an option to enter AVRDUDE configuration: [[File:avrdude_mainmenu.png]] [[File:avrdude_menu.png]] The AVRDUDE configuration page allows to setup the most common options for avrdude: ;Programmer Type :avrdude option '-c'. :Use the programmer configuration choosen from the list. : :Refer to the official avrdude documentation if you're in doubt about the correct choice for your programmer ([http://www.nongnu.org/avrdude/ avrdude home]). : :NB: The list of choices is generated by calling 'avrdude -c ?' and contains all the programmers your avrdude executable supports. ;Port :avrdude option '-P'. :Specify the port the programmer is connected to. Serial devices like ponyprog use for example ''/dev/ttyS0'' (= COM1 under Windows!), most modern programmers use ''usb''. : : Note that most old-style serial programmers will not work properly when connected to an USB-serial-Adapter! ; Extra verbose output :avrdude option '-v -v'. :Be more verbose. Default is '-v'. Use this, if you experience problems while flashing or simply want to see in detail whats going on... ;Do NOT verify after programming :avrdude option '-V'. :Do NOT verify flash memory after programming. Use with care and only if you're really sure that your setup is perfect. Speeds things up a bit but it's use is generally discouraged. ;Count # of erase cycles in EEPROM :avrdude option '-y'. :Tell avrdude to maintain an erase cycle counter in the last four bytes of the eeprom. The counter has to be initialized by calling avrdude with the option '-Y 1' once. : : Do not use this option if your e6 configuration uses the last four bytes of the eeprom. ;Bitclock for ISP or JTAG :avrdude option '-B'. :Specify the bit clock period for the JTAG interface or the ISP clock. :Setting a lower value means higher programming speed. Use higher values if you experience programming errors in your setup. : : The available choices depend on the MCU frequency setting and should not exceed 4/F_CPU in micro seconds: : :*4 micro seconds is required for F_CPU < 4 MHz. :*1 micro second is appropriate for F_CPU < 10 MHz. :*0.5 micro seconds is appropriate for F_CPU < 16 MHz. :*0.3 micro seconds is appropriate for F_CPU >= 16 MHz. : ;Pass extra options to avrdude :If your programmer or setup requires any extra options to avrdude you may pass them here. === AVR Fuses === The fuse registers enable/disable or control the basic functionality of the different units of the MCU. One can e. g. enable or disable the Watchdog, the JTAG interface or even the ISP Interface. Configuration of the MCUs clock source or the brown-out detector is also done via the fuse registers. '''WARNING: Programming wrong fuse values may render your MCU UNUSABLE''' (...unless you've access to a JTAG- and/or HV-Programmer.) '''There is nothing like ''the universal correct fuse setting'' or ''default fuse setting''. Fuse registers are MCU-specific and their correct settings heavily depend on the circuit and parts in use. Be careful, read the datasheet for the MCU acually in use and think twice what is correct for YOUR hardware!!''' ;Fuse Low Byte (FLB) :AVR Fuse Low Byte, two-digit hex value. : ;Fuse High Byte (FHB) :AVR Fuse High Byte, two-digit hex value. : ;Extended Fuse Byte (EFB) :AVR Extended Fuse Byte, two-digit hex value. The necessary hex values for the fuse registers might be calculated with e.g. an online [http://www.engbedded.com/fusecalc AVR fuse calculator]. [http://www.mikrocontroller.net/articles/AVR_Fuses Article on mikrocontroller.net for reference (german only, sorry).] == Writing the Bytes == * Disconnect the power from the target board (the NET-IO) * Connect your ISP cable to the programmer and the target board * Reconnect the power and connect your programmer to the PC * Execute the command you assembled earlier or type ''make program'' * Congratulations! If avrdude finished without any error you successfully flashed ethersex to your target board! * Disconnect the power and the programmer from the target * Reconnect the power, your target should boot up with ethersex [[Quick_Start_Guide/Configuration | previous step]] | 432e1394ed2e6933dab2f31e11149c15630612ec 1120 1119 2013-07-17T21:03:11Z Michaelb 718 wikitext text/x-wiki {{i18n|Quick Start Guide/Flashing}} = Flashing = After compiling the ''ethersex.hex'' you can flash it with avrdude. You can either use avrdude on the command line or call the target ''program'' from the [[Ethersex]] Makefile. == Prerequisites == * the previously selected board, e.g. AVR NET-IO, ready built and (hopefully) tested * an ISP-Programmer of your choice supported by [http://www.nongnu.org/avrdude avrdude] * an ISP connector cable that fits to your programmer and your board (either 6 or 10-pin) * an ethersex.hex compiled in the [[Quick_Start_Guide/Configuration | previous step]] If you have an ISP-Programmer with a 6-pin port and a board with a 10-pin header - like the AVR NET-IO - you can create an adapter. You can see the pin configuration in figure 4-1 at page 5 [http://www.atmel.com/dyn/resources/prod_documents/doc2521.pdf AVR042: AVR Hardware Design Considerations]. Note that Pin 4 of the 10-pin connector is not used on the AVR NET-IO. GND has to be connected to one of the other Pins (6, 8 or 10). == Flashing the image with avrdude == The following commands are just examples, the actual command line depends on your ISP-Programmer and hardware. This example is for a serial connection (e.g. the ATMEL Evaluation-Board): avrdude -v -p m32 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex This example for a real USB ISP-Programmer: avrdude -p m1284p -c avrispmkII -P usb -U flash:w:ethersex.hex For a serial programmer connected via an USB-serial-adapter this may be used: avrdude -v -p m32 -c stk500v2 -P /dev/ttyACM0 -U flash:w:ethersex.hex And this one for a parallel ISP-Cable: avrdude -p m32 -e -c stk200 -U flash:w:ethersex.hex After flashing remove the ISP-Cable and interrupt the power connection for a short time to reboot the board. * -p m32: ATMega32; -p m644: ATMega644; -p ? to list the valid parts * -v: display debug messages * -c ponyser: traditional serial programmer; -c stkk500v2 for the Atmel board * -P /dev/tty.serial the serial port your programmer is connected to; -P COM1 for windows machines; -P usb for USB * -U the command you want to execute. In our case we want to flash: -U flash:w:ethersex.hex == Using avrdude from the makefile == Since [https://github.com/ethersex/ethersex/commit/16c2a388ec775b51c049db1eeff3a8171c6ad71b 16c2a388ec] the [[Ethersex]] makefile supports two new targets, ''program'' and ''fuses'', to invoke avrdude. The target ''program'' calls avrdude with the options to flash the previously compiled ''ethersex.hex'' to the MCU. The ''fuses'' target may be used to program the MCUs fuse registers. AVRDUDE options and MCU fuse register settings may be configured via a menuconfig dialog. All settings will be saved to the current profile ''.config''. Available settings and choices on the AVRDUDE configuration page depend on the MCU and clock frequency configured on the General Setup dialog. Please go back to the [[Quick_Start_Guide/Configuration | previous step]] if you haven't done that yet. === AVRDUDE Configuration === If - and only if - the avrdude executable could be found in your ''PATH'', menuconfig's mainmenu will show an option to enter AVRDUDE configuration: [[File:avrdude_mainmenu.png]] [[File:avrdude_menu.png]] The AVRDUDE configuration page allows to setup the most common options for avrdude: ;Programmer Type :avrdude option '-c'. :Use the programmer configuration choosen from the list. : :Refer to the official avrdude documentation if you're in doubt about the correct choice for your programmer ([http://www.nongnu.org/avrdude/ avrdude home]). : :NB: The list of choices is generated by calling 'avrdude -c ?' and contains all the programmers your avrdude executable supports. ;Port :avrdude option '-P'. :Specify the port the programmer is connected to. Serial devices like ponyprog use for example ''/dev/ttyS0'' (= COM1 under Windows!), most modern programmers use ''usb''. : : Note that most old-style serial programmers will not work properly when connected to an USB-serial-Adapter! ; Extra verbose output :avrdude option '-v -v'. :Be more verbose. Default is '-v'. Use this, if you experience problems while flashing or simply want to see in detail whats going on... ;Do NOT verify after programming :avrdude option '-V'. :Do NOT verify flash memory after programming. Use with care and only if you're really sure that your setup is perfect. Speeds things up a bit but it's use is generally discouraged. ;Count # of erase cycles in EEPROM :avrdude option '-y'. :Tell avrdude to maintain an erase cycle counter in the last four bytes of the eeprom. The counter has to be initialized by calling avrdude with the option '-Y 1' once. : : Do not use this option if your e6 configuration uses the last four bytes of the eeprom. ;Bitclock for ISP or JTAG :avrdude option '-B'. :Specify the bit clock period for the JTAG interface or the ISP clock. :Setting a lower value means higher programming speed. Use higher values if you experience programming errors in your setup. : : The available choices depend on the MCU frequency setting and should not exceed 4/F_CPU in micro seconds: : :*4 micro seconds is required for F_CPU < 4 MHz. :*1 micro second is appropriate for F_CPU < 10 MHz. :*0.5 micro seconds is appropriate for F_CPU < 16 MHz. :*0.3 micro seconds is appropriate for F_CPU >= 16 MHz. : ;Pass extra options to avrdude :If your programmer or setup requires any extra options to avrdude you may pass them here. === AVR Fuses === The fuse registers enable/disable or control the basic functionality of the different units of the MCU. One can e. g. enable or disable the Watchdog, the JTAG interface or even the ISP Interface. Configuration of the MCUs clock source or the brown-out detector is also done via the fuse registers. '''WARNING: Programming wrong fuse values may render your MCU UNUSABLE''' (...unless you've access to a JTAG- and/or HV-Programmer.) '''There is nothing like ''the universal correct fuse setting'' or ''default fuse setting''. Fuse registers are MCU-specific and their correct settings heavily depend on the circuit and parts in use. Be careful, read the datasheet for the MCU acually in use and think twice what is correct for YOUR hardware!!''' ;Fuse Low Byte (FLB) :AVR Fuse Low Byte, two-digit hex value. : ;Fuse High Byte (FHB) :AVR Fuse High Byte, two-digit hex value. : ;Extended Fuse Byte (EFB) :AVR Extended Fuse Byte, two-digit hex value. The necessary hex values for the fuse registers might be calculated with e.g. an online [http://www.engbedded.com/fusecalc AVR fuse calculator]. [http://www.mikrocontroller.net/articles/AVR_Fuses Article on mikrocontroller.net for reference (german only, sorry).] == Writing the Bytes == * Disconnect the power from the target board (the NET-IO) * Connect your ISP cable to the programmer and the target board * Reconnect the power and connect your programmer to the PC * Execute the command you assembled earlier or type ''make program'' * Congratulations! If avrdude finished without any error you successfully flashed ethersex to your target board! * Disconnect the power and the programmer from the target * Reconnect the power, your target should boot up with ethersex [[Quick_Start_Guide/Configuration | previous step]] | 3f24891b474bcc9c0e456ea6ccd72792ce3e944b 1121 1120 2013-07-18T05:35:16Z GooPie4o 265 /* AVR Fuses */ wikitext text/x-wiki {{i18n|Quick Start Guide/Flashing}} = Flashing = After compiling the ''ethersex.hex'' you can flash it with avrdude. You can either use avrdude on the command line or call the target ''program'' from the [[Ethersex]] Makefile. == Prerequisites == * the previously selected board, e.g. AVR NET-IO, ready built and (hopefully) tested * an ISP-Programmer of your choice supported by [http://www.nongnu.org/avrdude avrdude] * an ISP connector cable that fits to your programmer and your board (either 6 or 10-pin) * an ethersex.hex compiled in the [[Quick_Start_Guide/Configuration | previous step]] If you have an ISP-Programmer with a 6-pin port and a board with a 10-pin header - like the AVR NET-IO - you can create an adapter. You can see the pin configuration in figure 4-1 at page 5 [http://www.atmel.com/dyn/resources/prod_documents/doc2521.pdf AVR042: AVR Hardware Design Considerations]. Note that Pin 4 of the 10-pin connector is not used on the AVR NET-IO. GND has to be connected to one of the other Pins (6, 8 or 10). == Flashing the image with avrdude == The following commands are just examples, the actual command line depends on your ISP-Programmer and hardware. This example is for a serial connection (e.g. the ATMEL Evaluation-Board): avrdude -v -p m32 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex This example for a real USB ISP-Programmer: avrdude -p m1284p -c avrispmkII -P usb -U flash:w:ethersex.hex For a serial programmer connected via an USB-serial-adapter this may be used: avrdude -v -p m32 -c stk500v2 -P /dev/ttyACM0 -U flash:w:ethersex.hex And this one for a parallel ISP-Cable: avrdude -p m32 -e -c stk200 -U flash:w:ethersex.hex After flashing remove the ISP-Cable and interrupt the power connection for a short time to reboot the board. * -p m32: ATMega32; -p m644: ATMega644; -p ? to list the valid parts * -v: display debug messages * -c ponyser: traditional serial programmer; -c stkk500v2 for the Atmel board * -P /dev/tty.serial the serial port your programmer is connected to; -P COM1 for windows machines; -P usb for USB * -U the command you want to execute. In our case we want to flash: -U flash:w:ethersex.hex == Using avrdude from the makefile == Since [https://github.com/ethersex/ethersex/commit/16c2a388ec775b51c049db1eeff3a8171c6ad71b 16c2a388ec] the [[Ethersex]] makefile supports two new targets, ''program'' and ''fuses'', to invoke avrdude. The target ''program'' calls avrdude with the options to flash the previously compiled ''ethersex.hex'' to the MCU. The ''fuses'' target may be used to program the MCUs fuse registers. AVRDUDE options and MCU fuse register settings may be configured via a menuconfig dialog. All settings will be saved to the current profile ''.config''. Available settings and choices on the AVRDUDE configuration page depend on the MCU and clock frequency configured on the General Setup dialog. Please go back to the [[Quick_Start_Guide/Configuration | previous step]] if you haven't done that yet. === AVRDUDE Configuration === If - and only if - the avrdude executable could be found in your ''PATH'', menuconfig's mainmenu will show an option to enter AVRDUDE configuration: [[File:avrdude_mainmenu.png]] [[File:avrdude_menu.png]] The AVRDUDE configuration page allows to setup the most common options for avrdude: ;Programmer Type :avrdude option '-c'. :Use the programmer configuration choosen from the list. : :Refer to the official avrdude documentation if you're in doubt about the correct choice for your programmer ([http://www.nongnu.org/avrdude/ avrdude home]). : :NB: The list of choices is generated by calling 'avrdude -c ?' and contains all the programmers your avrdude executable supports. ;Port :avrdude option '-P'. :Specify the port the programmer is connected to. Serial devices like ponyprog use for example ''/dev/ttyS0'' (= COM1 under Windows!), most modern programmers use ''usb''. : : Note that most old-style serial programmers will not work properly when connected to an USB-serial-Adapter! ; Extra verbose output :avrdude option '-v -v'. :Be more verbose. Default is '-v'. Use this, if you experience problems while flashing or simply want to see in detail whats going on... ;Do NOT verify after programming :avrdude option '-V'. :Do NOT verify flash memory after programming. Use with care and only if you're really sure that your setup is perfect. Speeds things up a bit but it's use is generally discouraged. ;Count # of erase cycles in EEPROM :avrdude option '-y'. :Tell avrdude to maintain an erase cycle counter in the last four bytes of the eeprom. The counter has to be initialized by calling avrdude with the option '-Y 1' once. : : Do not use this option if your e6 configuration uses the last four bytes of the eeprom. ;Bitclock for ISP or JTAG :avrdude option '-B'. :Specify the bit clock period for the JTAG interface or the ISP clock. :Setting a lower value means higher programming speed. Use higher values if you experience programming errors in your setup. : : The available choices depend on the MCU frequency setting and should not exceed 4/F_CPU in micro seconds: : :*4 micro seconds is required for F_CPU < 4 MHz. :*1 micro second is appropriate for F_CPU < 10 MHz. :*0.5 micro seconds is appropriate for F_CPU < 16 MHz. :*0.3 micro seconds is appropriate for F_CPU >= 16 MHz. : ;Pass extra options to avrdude :If your programmer or setup requires any extra options to avrdude you may pass them here. === AVR Fuses === The fuse registers enable/disable or control the basic functionality of the different units of the MCU. One can e. g. enable or disable the Watchdog, the JTAG interface or even the ISP Interface. Configuration of the MCUs clock source or the brown-out detector is also done via the fuse registers. '''WARNING: Programming wrong fuse values may render your MCU UNUSABLE''' (...unless you've access to a JTAG- and/or HV-Programmer.) '''There is nothing like ''the universal correct fuse setting'' or ''default fuse setting''. Fuse registers are MCU-specific and their correct settings heavily depend on the circuit and parts in use. Be careful, read the datasheet for the MCU acually in use and think twice what is correct for YOUR hardware!!''' ;Fuse Low Byte (FLB) :AVR Fuse Low Byte, two-digit hex value. : ;Fuse High Byte (FHB) :AVR Fuse High Byte, two-digit hex value. : ;Extended Fuse Byte (EFB) :AVR Extended Fuse Byte, two-digit hex value. The necessary hex values for the fuse registers might be calculated with e.g. an online [http://www.engbedded.com/fusecalc AVR fuse calculator]. [http://www.mikrocontroller.net/articles/AVR_Fuses Article on mikrocontroller.net for reference (German).] == Writing the Bytes == * Disconnect the power from the target board (the NET-IO) * Connect your ISP cable to the programmer and the target board * Reconnect the power and connect your programmer to the PC * Execute the command you assembled earlier or type ''make program'' * Congratulations! If avrdude finished without any error you successfully flashed ethersex to your target board! * Disconnect the power and the programmer from the target * Reconnect the power, your target should boot up with ethersex [[Quick_Start_Guide/Configuration | previous step]] | c7082fc7d1b014339cf18334db8aa98e63962226 1122 1121 2013-07-18T05:37:20Z GooPie4o 265 /* Writing the Bytes */ wikitext text/x-wiki {{i18n|Quick Start Guide/Flashing}} = Flashing = After compiling the ''ethersex.hex'' you can flash it with avrdude. You can either use avrdude on the command line or call the target ''program'' from the [[Ethersex]] Makefile. == Prerequisites == * the previously selected board, e.g. AVR NET-IO, ready built and (hopefully) tested * an ISP-Programmer of your choice supported by [http://www.nongnu.org/avrdude avrdude] * an ISP connector cable that fits to your programmer and your board (either 6 or 10-pin) * an ethersex.hex compiled in the [[Quick_Start_Guide/Configuration | previous step]] If you have an ISP-Programmer with a 6-pin port and a board with a 10-pin header - like the AVR NET-IO - you can create an adapter. You can see the pin configuration in figure 4-1 at page 5 [http://www.atmel.com/dyn/resources/prod_documents/doc2521.pdf AVR042: AVR Hardware Design Considerations]. Note that Pin 4 of the 10-pin connector is not used on the AVR NET-IO. GND has to be connected to one of the other Pins (6, 8 or 10). == Flashing the image with avrdude == The following commands are just examples, the actual command line depends on your ISP-Programmer and hardware. This example is for a serial connection (e.g. the ATMEL Evaluation-Board): avrdude -v -p m32 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex This example for a real USB ISP-Programmer: avrdude -p m1284p -c avrispmkII -P usb -U flash:w:ethersex.hex For a serial programmer connected via an USB-serial-adapter this may be used: avrdude -v -p m32 -c stk500v2 -P /dev/ttyACM0 -U flash:w:ethersex.hex And this one for a parallel ISP-Cable: avrdude -p m32 -e -c stk200 -U flash:w:ethersex.hex After flashing remove the ISP-Cable and interrupt the power connection for a short time to reboot the board. * -p m32: ATMega32; -p m644: ATMega644; -p ? to list the valid parts * -v: display debug messages * -c ponyser: traditional serial programmer; -c stkk500v2 for the Atmel board * -P /dev/tty.serial the serial port your programmer is connected to; -P COM1 for windows machines; -P usb for USB * -U the command you want to execute. In our case we want to flash: -U flash:w:ethersex.hex == Using avrdude from the makefile == Since [https://github.com/ethersex/ethersex/commit/16c2a388ec775b51c049db1eeff3a8171c6ad71b 16c2a388ec] the [[Ethersex]] makefile supports two new targets, ''program'' and ''fuses'', to invoke avrdude. The target ''program'' calls avrdude with the options to flash the previously compiled ''ethersex.hex'' to the MCU. The ''fuses'' target may be used to program the MCUs fuse registers. AVRDUDE options and MCU fuse register settings may be configured via a menuconfig dialog. All settings will be saved to the current profile ''.config''. Available settings and choices on the AVRDUDE configuration page depend on the MCU and clock frequency configured on the General Setup dialog. Please go back to the [[Quick_Start_Guide/Configuration | previous step]] if you haven't done that yet. === AVRDUDE Configuration === If - and only if - the avrdude executable could be found in your ''PATH'', menuconfig's mainmenu will show an option to enter AVRDUDE configuration: [[File:avrdude_mainmenu.png]] [[File:avrdude_menu.png]] The AVRDUDE configuration page allows to setup the most common options for avrdude: ;Programmer Type :avrdude option '-c'. :Use the programmer configuration choosen from the list. : :Refer to the official avrdude documentation if you're in doubt about the correct choice for your programmer ([http://www.nongnu.org/avrdude/ avrdude home]). : :NB: The list of choices is generated by calling 'avrdude -c ?' and contains all the programmers your avrdude executable supports. ;Port :avrdude option '-P'. :Specify the port the programmer is connected to. Serial devices like ponyprog use for example ''/dev/ttyS0'' (= COM1 under Windows!), most modern programmers use ''usb''. : : Note that most old-style serial programmers will not work properly when connected to an USB-serial-Adapter! ; Extra verbose output :avrdude option '-v -v'. :Be more verbose. Default is '-v'. Use this, if you experience problems while flashing or simply want to see in detail whats going on... ;Do NOT verify after programming :avrdude option '-V'. :Do NOT verify flash memory after programming. Use with care and only if you're really sure that your setup is perfect. Speeds things up a bit but it's use is generally discouraged. ;Count # of erase cycles in EEPROM :avrdude option '-y'. :Tell avrdude to maintain an erase cycle counter in the last four bytes of the eeprom. The counter has to be initialized by calling avrdude with the option '-Y 1' once. : : Do not use this option if your e6 configuration uses the last four bytes of the eeprom. ;Bitclock for ISP or JTAG :avrdude option '-B'. :Specify the bit clock period for the JTAG interface or the ISP clock. :Setting a lower value means higher programming speed. Use higher values if you experience programming errors in your setup. : : The available choices depend on the MCU frequency setting and should not exceed 4/F_CPU in micro seconds: : :*4 micro seconds is required for F_CPU < 4 MHz. :*1 micro second is appropriate for F_CPU < 10 MHz. :*0.5 micro seconds is appropriate for F_CPU < 16 MHz. :*0.3 micro seconds is appropriate for F_CPU >= 16 MHz. : ;Pass extra options to avrdude :If your programmer or setup requires any extra options to avrdude you may pass them here. === AVR Fuses === The fuse registers enable/disable or control the basic functionality of the different units of the MCU. One can e. g. enable or disable the Watchdog, the JTAG interface or even the ISP Interface. Configuration of the MCUs clock source or the brown-out detector is also done via the fuse registers. '''WARNING: Programming wrong fuse values may render your MCU UNUSABLE''' (...unless you've access to a JTAG- and/or HV-Programmer.) '''There is nothing like ''the universal correct fuse setting'' or ''default fuse setting''. Fuse registers are MCU-specific and their correct settings heavily depend on the circuit and parts in use. Be careful, read the datasheet for the MCU acually in use and think twice what is correct for YOUR hardware!!''' ;Fuse Low Byte (FLB) :AVR Fuse Low Byte, two-digit hex value. : ;Fuse High Byte (FHB) :AVR Fuse High Byte, two-digit hex value. : ;Extended Fuse Byte (EFB) :AVR Extended Fuse Byte, two-digit hex value. The necessary hex values for the fuse registers might be calculated with e.g. an online [http://www.engbedded.com/fusecalc AVR fuse calculator]. [http://www.mikrocontroller.net/articles/AVR_Fuses Article on mikrocontroller.net for reference (German).] == Writing the Bytes == * Disconnect the power from the target board * Connect your ISP cable to the programmer and the target board * Reconnect the power and connect your programmer to the PC * Execute the command you assembled earlier or type ''make program'' * Congratulations! If [[avrdude]] finished without any error you successfully flashed [[Ethersex]] to your target board! * Disconnect the power and the programmer from the target * Reconnect the power, your target should boot up with [[Ethersex]] [[Quick_Start_Guide/Configuration | previous step]] | 06e42d1e2fc6a97120bb03f621452e561a338f2b 1123 1122 2013-07-18T06:48:25Z Michaelb 718 /* Writing the Bytes */ wikitext text/x-wiki {{i18n|Quick Start Guide/Flashing}} = Flashing = After compiling the ''ethersex.hex'' you can flash it with avrdude. You can either use avrdude on the command line or call the target ''program'' from the [[Ethersex]] Makefile. == Prerequisites == * the previously selected board, e.g. AVR NET-IO, ready built and (hopefully) tested * an ISP-Programmer of your choice supported by [http://www.nongnu.org/avrdude avrdude] * an ISP connector cable that fits to your programmer and your board (either 6 or 10-pin) * an ethersex.hex compiled in the [[Quick_Start_Guide/Configuration | previous step]] If you have an ISP-Programmer with a 6-pin port and a board with a 10-pin header - like the AVR NET-IO - you can create an adapter. You can see the pin configuration in figure 4-1 at page 5 [http://www.atmel.com/dyn/resources/prod_documents/doc2521.pdf AVR042: AVR Hardware Design Considerations]. Note that Pin 4 of the 10-pin connector is not used on the AVR NET-IO. GND has to be connected to one of the other Pins (6, 8 or 10). == Flashing the image with avrdude == The following commands are just examples, the actual command line depends on your ISP-Programmer and hardware. This example is for a serial connection (e.g. the ATMEL Evaluation-Board): avrdude -v -p m32 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex This example for a real USB ISP-Programmer: avrdude -p m1284p -c avrispmkII -P usb -U flash:w:ethersex.hex For a serial programmer connected via an USB-serial-adapter this may be used: avrdude -v -p m32 -c stk500v2 -P /dev/ttyACM0 -U flash:w:ethersex.hex And this one for a parallel ISP-Cable: avrdude -p m32 -e -c stk200 -U flash:w:ethersex.hex After flashing remove the ISP-Cable and interrupt the power connection for a short time to reboot the board. * -p m32: ATMega32; -p m644: ATMega644; -p ? to list the valid parts * -v: display debug messages * -c ponyser: traditional serial programmer; -c stkk500v2 for the Atmel board * -P /dev/tty.serial the serial port your programmer is connected to; -P COM1 for windows machines; -P usb for USB * -U the command you want to execute. In our case we want to flash: -U flash:w:ethersex.hex == Using avrdude from the makefile == Since [https://github.com/ethersex/ethersex/commit/16c2a388ec775b51c049db1eeff3a8171c6ad71b 16c2a388ec] the [[Ethersex]] makefile supports two new targets, ''program'' and ''fuses'', to invoke avrdude. The target ''program'' calls avrdude with the options to flash the previously compiled ''ethersex.hex'' to the MCU. The ''fuses'' target may be used to program the MCUs fuse registers. AVRDUDE options and MCU fuse register settings may be configured via a menuconfig dialog. All settings will be saved to the current profile ''.config''. Available settings and choices on the AVRDUDE configuration page depend on the MCU and clock frequency configured on the General Setup dialog. Please go back to the [[Quick_Start_Guide/Configuration | previous step]] if you haven't done that yet. === AVRDUDE Configuration === If - and only if - the avrdude executable could be found in your ''PATH'', menuconfig's mainmenu will show an option to enter AVRDUDE configuration: [[File:avrdude_mainmenu.png]] [[File:avrdude_menu.png]] The AVRDUDE configuration page allows to setup the most common options for avrdude: ;Programmer Type :avrdude option '-c'. :Use the programmer configuration choosen from the list. : :Refer to the official avrdude documentation if you're in doubt about the correct choice for your programmer ([http://www.nongnu.org/avrdude/ avrdude home]). : :NB: The list of choices is generated by calling 'avrdude -c ?' and contains all the programmers your avrdude executable supports. ;Port :avrdude option '-P'. :Specify the port the programmer is connected to. Serial devices like ponyprog use for example ''/dev/ttyS0'' (= COM1 under Windows!), most modern programmers use ''usb''. : : Note that most old-style serial programmers will not work properly when connected to an USB-serial-Adapter! ; Extra verbose output :avrdude option '-v -v'. :Be more verbose. Default is '-v'. Use this, if you experience problems while flashing or simply want to see in detail whats going on... ;Do NOT verify after programming :avrdude option '-V'. :Do NOT verify flash memory after programming. Use with care and only if you're really sure that your setup is perfect. Speeds things up a bit but it's use is generally discouraged. ;Count # of erase cycles in EEPROM :avrdude option '-y'. :Tell avrdude to maintain an erase cycle counter in the last four bytes of the eeprom. The counter has to be initialized by calling avrdude with the option '-Y 1' once. : : Do not use this option if your e6 configuration uses the last four bytes of the eeprom. ;Bitclock for ISP or JTAG :avrdude option '-B'. :Specify the bit clock period for the JTAG interface or the ISP clock. :Setting a lower value means higher programming speed. Use higher values if you experience programming errors in your setup. : : The available choices depend on the MCU frequency setting and should not exceed 4/F_CPU in micro seconds: : :*4 micro seconds is required for F_CPU < 4 MHz. :*1 micro second is appropriate for F_CPU < 10 MHz. :*0.5 micro seconds is appropriate for F_CPU < 16 MHz. :*0.3 micro seconds is appropriate for F_CPU >= 16 MHz. : ;Pass extra options to avrdude :If your programmer or setup requires any extra options to avrdude you may pass them here. === AVR Fuses === The fuse registers enable/disable or control the basic functionality of the different units of the MCU. One can e. g. enable or disable the Watchdog, the JTAG interface or even the ISP Interface. Configuration of the MCUs clock source or the brown-out detector is also done via the fuse registers. '''WARNING: Programming wrong fuse values may render your MCU UNUSABLE''' (...unless you've access to a JTAG- and/or HV-Programmer.) '''There is nothing like ''the universal correct fuse setting'' or ''default fuse setting''. Fuse registers are MCU-specific and their correct settings heavily depend on the circuit and parts in use. Be careful, read the datasheet for the MCU acually in use and think twice what is correct for YOUR hardware!!''' ;Fuse Low Byte (FLB) :AVR Fuse Low Byte, two-digit hex value. : ;Fuse High Byte (FHB) :AVR Fuse High Byte, two-digit hex value. : ;Extended Fuse Byte (EFB) :AVR Extended Fuse Byte, two-digit hex value. The necessary hex values for the fuse registers might be calculated with e.g. an online [http://www.engbedded.com/fusecalc AVR fuse calculator]. [http://www.mikrocontroller.net/articles/AVR_Fuses Article on mikrocontroller.net for reference (German).] == Writing the Bytes == * Disconnect the power from the target board * Connect your ISP cable to the programmer and the target board * Reconnect the power and connect your programmer to the PC * Execute the command you assembled earlier or type ''make program'' * Congratulations! If [[avrdude]] finished without any error you successfully flashed [[Ethersex]] to your target board! * Disconnect the power and the programmer from the target * Reconnect the power, your target should boot up with [[Ethersex]] [[Quick_Start_Guide/Configuration | previous step]] | [[Category:Ethersex]] [[Category:QuickStartGuide]] [[Category:StepByStep]] 60549605db76e0cfc80e294c27b6e3a534bbdcb2 1126 1123 2013-07-18T06:54:20Z Michaelb 718 wikitext text/x-wiki {{i18n|Quick Start Guide/Flashing}} = Flashing = After compiling the ''ethersex.hex'' you can flash it with avrdude. You can either use avrdude on the command line or call the target ''program'' from the [[Ethersex]] Makefile. == Prerequisites == * the previously selected board, e.g. AVR NET-IO, ready built and (hopefully) tested * an ISP-Programmer of your choice supported by [http://www.nongnu.org/avrdude avrdude] * an ISP connector cable that fits to your programmer and your board (either 6 or 10-pin) * an ethersex.hex compiled in the [[Quick_Start_Guide/Configuration | previous step]] If you have an ISP-Programmer with a 6-pin port and a board with a 10-pin header - like the AVR NET-IO - you can create an adapter. You can see the pin configuration in figure 4-1 at page 5 [http://www.atmel.com/dyn/resources/prod_documents/doc2521.pdf AVR042: AVR Hardware Design Considerations]. Note that Pin 4 of the 10-pin connector is not used on the AVR NET-IO. GND has to be connected to one of the other Pins (6, 8 or 10). == Flashing the image with avrdude == The following commands are just examples, the actual command line depends on your ISP-Programmer and hardware. This example is for a serial connection (e.g. the ATMEL Evaluation-Board): avrdude -v -p m32 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex This example for a real USB ISP-Programmer: avrdude -p m1284p -c avrispmkII -P usb -U flash:w:ethersex.hex For a serial programmer connected via an USB-serial-adapter this may be used: avrdude -v -p m32 -c stk500v2 -P /dev/ttyACM0 -U flash:w:ethersex.hex And this one for a parallel ISP-Cable: avrdude -p m32 -e -c stk200 -U flash:w:ethersex.hex After flashing remove the ISP-Cable and interrupt the power connection for a short time to reboot the board. * -p m32: ATMega32; -p m644: ATMega644; -p ? to list the valid parts * -v: display debug messages * -c ponyser: traditional serial programmer; -c stkk500v2 for the Atmel board * -P /dev/tty.serial the serial port your programmer is connected to; -P COM1 for windows machines; -P usb for USB * -U the command you want to execute. In our case we want to flash: -U flash:w:ethersex.hex == Using avrdude from the makefile == Since [https://github.com/ethersex/ethersex/commit/16c2a388ec775b51c049db1eeff3a8171c6ad71b 16c2a388ec] the [[Ethersex]] makefile supports two new targets, ''program'' and ''fuses'', to invoke avrdude. The target ''program'' calls avrdude with the options to flash the previously compiled ''ethersex.hex'' to the MCU. The ''fuses'' target may be used to program the MCUs fuse registers. AVRDUDE options and MCU fuse register settings may be configured via a menuconfig dialog. All settings will be saved to the current profile ''.config''. Available settings and choices on the AVRDUDE configuration page depend on the MCU and clock frequency configured on the General Setup dialog. Please go back to the [[Quick_Start_Guide/Configuration | previous step]] if you haven't done that yet. === AVRDUDE Configuration === If - and only if - the avrdude executable could be found in your ''PATH'', menuconfig's mainmenu will show an option to enter AVRDUDE configuration: [[File:avrdude_mainmenu.png]] [[File:avrdude_menu.png]] The AVRDUDE configuration page allows to setup the most common options for avrdude: ;Programmer Type :avrdude option '-c'. :Use the programmer configuration choosen from the list. : :Refer to the official avrdude documentation if you're in doubt about the correct choice for your programmer ([http://www.nongnu.org/avrdude/ avrdude home]). : :NB: The list of choices is generated by calling 'avrdude -c ?' and contains all the programmers your avrdude executable supports. ;Port :avrdude option '-P'. :Specify the port the programmer is connected to. Serial devices like ponyprog use for example ''/dev/ttyS0'' (= COM1 under Windows!), most modern programmers use ''usb''. : : Note that most old-style serial programmers will not work properly when connected to an USB-serial-Adapter! ; Extra verbose output :avrdude option '-v -v'. :Be more verbose. Default is '-v'. Use this, if you experience problems while flashing or simply want to see in detail whats going on... ;Do NOT verify after programming :avrdude option '-V'. :Do NOT verify flash memory after programming. Use with care and only if you're really sure that your setup is perfect. Speeds things up a bit but it's use is generally discouraged. ;Count # of erase cycles in EEPROM :avrdude option '-y'. :Tell avrdude to maintain an erase cycle counter in the last four bytes of the eeprom. The counter has to be initialized by calling avrdude with the option '-Y 1' once. : : Do not use this option if your e6 configuration uses the last four bytes of the eeprom. ;Bitclock for ISP or JTAG :avrdude option '-B'. :Specify the bit clock period for the JTAG interface or the ISP clock. :Setting a lower value means higher programming speed. Use higher values if you experience programming errors in your setup. : : The available choices depend on the MCU frequency setting and should not exceed 4/F_CPU in micro seconds: : :*4 micro seconds is required for F_CPU < 4 MHz. :*1 micro second is appropriate for F_CPU < 10 MHz. :*0.5 micro seconds is appropriate for F_CPU < 16 MHz. :*0.3 micro seconds is appropriate for F_CPU >= 16 MHz. : ;Pass extra options to avrdude :If your programmer or setup requires any extra options to avrdude you may pass them here. === AVR Fuses === The fuse registers enable/disable or control the basic functionality of the different units of the MCU. One can e. g. enable or disable the Watchdog, the JTAG interface or even the ISP Interface. Configuration of the MCUs clock source or the brown-out detector is also done via the fuse registers. '''WARNING: Programming wrong fuse values may render your MCU UNUSABLE''' (...unless you've access to a JTAG- and/or HV-Programmer.) '''There is nothing like ''the universal correct fuse setting'' or ''default fuse setting''. Fuse registers are MCU-specific and their correct settings heavily depend on the circuit and parts in use. Be careful, read the datasheet for the MCU acually in use and think twice what is correct for YOUR hardware!!''' ;Fuse Low Byte (FLB) :AVR Fuse Low Byte, two-digit hex value. : ;Fuse High Byte (FHB) :AVR Fuse High Byte, two-digit hex value. : ;Extended Fuse Byte (EFB) :AVR Extended Fuse Byte, two-digit hex value. The necessary hex values for the fuse registers might be calculated with e.g. an online [http://www.engbedded.com/fusecalc AVR fuse calculator]. [http://www.mikrocontroller.net/articles/AVR_Fuses Article on mikrocontroller.net for reference (German).] == Writing the Bytes == * Disconnect the power from the target board * Connect your ISP cable to the programmer and the target board * Reconnect the power and connect your programmer to the PC * Execute the command you assembled earlier or type ''make program'' * Congratulations! If [[avrdude]] finished without any error you successfully flashed [[Ethersex]] to your target board! * Disconnect the power and the programmer from the target * Reconnect the power, your target should boot up with [[Ethersex]] [[Quick_Start_Guide/Configuration | previous step]] | [[Category:Ethersex]] [[Category:Quick Start Guide]] [[Category:StepByStep]] bce2d5cb424029ea58774f2cbe2b413230c6916e 1128 1126 2013-07-18T10:36:35Z Michaelb 718 wikitext text/x-wiki {{i18n|Quick Start Guide/Flashing}} = Flashing = After compiling the ''ethersex.hex'' you can flash it with avrdude. You can either use avrdude on the command line or call the target ''program'' from the [[Ethersex]] Makefile. == Prerequisites == * the previously selected board, e.g. AVR NET-IO, ready built and (hopefully) tested * an ISP-Programmer of your choice supported by [http://www.nongnu.org/avrdude avrdude] * an ISP connector cable that fits to your programmer and your board (either 6 or 10-pin) * an ethersex.hex compiled in the [[Quick_Start_Guide/Configuration | previous step]] If you have an ISP-Programmer with a 6-pin port and a board with a 10-pin header - like the AVR NET-IO - you can create an adapter. You can see the pin configuration in figure 4-1 at page 5 [http://www.atmel.com/dyn/resources/prod_documents/doc2521.pdf AVR042: AVR Hardware Design Considerations]. Note that Pin 4 of the 10-pin connector is not used on the AVR NET-IO. GND has to be connected to one of the other Pins (6, 8 or 10). == Flashing the image with avrdude == The following commands are just examples, the actual command line depends on your ISP-Programmer and hardware. This example is for a serial connection (e.g. the ATMEL Evaluation-Board): avrdude -v -p m32 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex This example for a real USB ISP-Programmer: avrdude -p m1284p -c avrispmkII -P usb -U flash:w:ethersex.hex For a serial programmer connected via an USB-serial-adapter this may be used: avrdude -v -p m32 -c stk500v2 -P /dev/ttyACM0 -U flash:w:ethersex.hex And this one for a parallel ISP-Cable: avrdude -p m32 -e -c stk200 -U flash:w:ethersex.hex After flashing remove the ISP-Cable and interrupt the power connection for a short time to reboot the board. * -p m32: ATMega32; -p m644: ATMega644; -p ? to list the valid parts * -v: display debug messages * -c ponyser: traditional serial programmer; -c stkk500v2 for the Atmel board * -P /dev/tty.serial the serial port your programmer is connected to; -P COM1 for windows machines; -P usb for USB * -U the command you want to execute. In our case we want to flash: -U flash:w:ethersex.hex == Using avrdude from the makefile == Since [https://github.com/ethersex/ethersex/commit/16c2a388ec775b51c049db1eeff3a8171c6ad71b 16c2a388ec] the [[Ethersex]] makefile supports two new targets, ''program'' and ''fuses'', to invoke avrdude. The target ''program'' calls avrdude with the options to flash the previously compiled ''ethersex.hex'' to the MCU. The ''fuses'' target may be used to program the MCUs fuse registers. AVRDUDE options and MCU fuse register settings may be configured via a menuconfig dialog. All settings will be saved to the current profile ''.config''. Available settings and choices on the AVRDUDE configuration page depend on the MCU and clock frequency configured on the General Setup dialog. Please go back to the [[Quick_Start_Guide/Configuration | previous step]] if you haven't done that yet. === AVRDUDE Configuration === If - and only if - the avrdude executable could be found in your ''PATH'', menuconfig's mainmenu will show an option to enter AVRDUDE configuration. [[File:avrdude_mainmenu.png|right|sub|thumb|400px|menuconfig's mainmenu with AVRDUDE Configuration selected]] The AVRDUDE configuration page allows to setup the most common options for avrdude: [[File:avrdude_menu.png|right|sub|thumb|400px|AVRDUDE configuration page]] ;Programmer Type :avrdude option '-c'. :Use the programmer configuration choosen from the list. : :Refer to the official avrdude documentation if you're in doubt about the correct choice for your programmer ([http://www.nongnu.org/avrdude/ avrdude home]). : :NB: The list of choices is generated by calling 'avrdude -c ?' and contains all the programmers your avrdude executable supports. ;Port :avrdude option '-P'. :Specify the port the programmer is connected to. Serial devices like ponyprog use for example ''/dev/ttyS0'' (= COM1 under Windows!), most modern programmers use ''usb''. : : Note that most old-style serial programmers will not work properly when connected to an USB-serial-Adapter! ; Extra verbose output :avrdude option '-v -v'. :Be more verbose. Default is '-v'. Use this, if you experience problems while flashing or simply want to see in detail whats going on... ;Do NOT verify after programming :avrdude option '-V'. :Do NOT verify flash memory after programming. Use with care and only if you're really sure that your setup is perfect. Speeds things up a bit but it's use is generally discouraged. ;Count # of erase cycles in EEPROM :avrdude option '-y'. :Tell avrdude to maintain an erase cycle counter in the last four bytes of the eeprom. The counter has to be initialized by calling avrdude with the option '-Y 1' once. : : Do not use this option if your e6 configuration uses the last four bytes of the eeprom. ;Bitclock for ISP or JTAG :avrdude option '-B'. :Specify the bit clock period for the JTAG interface or the ISP clock. :Setting a lower value means higher programming speed. Use higher values if you experience programming errors in your setup. : : The available choices depend on the MCU frequency setting and should not exceed 4/F_CPU in micro seconds: : :*4 micro seconds is required for F_CPU < 4 MHz. :*1 micro second is appropriate for F_CPU < 10 MHz. :*0.5 micro seconds is appropriate for F_CPU < 16 MHz. :*0.3 micro seconds is appropriate for F_CPU >= 16 MHz. : ;Pass extra options to avrdude :If your programmer or setup requires any extra options to avrdude you may pass them here. === AVR Fuses === The fuse registers enable/disable or control the basic functionality of the different units of the MCU. One can e. g. enable or disable the Watchdog, the JTAG interface or even the ISP Interface. Configuration of the MCUs clock source or the brown-out detector is also done via the fuse registers. '''WARNING: Programming wrong fuse values may render your MCU UNUSABLE''' (...unless you've access to a JTAG- and/or HV-Programmer.) '''There is nothing like ''the universal correct fuse setting'' or ''default fuse setting''. Fuse registers are MCU-specific and their correct settings heavily depend on the circuit and parts in use. Be careful, read the datasheet for the MCU acually in use and think twice what is correct for YOUR hardware!!''' ;Fuse Low Byte (FLB) :AVR Fuse Low Byte, two-digit hex value. : ;Fuse High Byte (FHB) :AVR Fuse High Byte, two-digit hex value. : ;Extended Fuse Byte (EFB) :AVR Extended Fuse Byte, two-digit hex value. The necessary hex values for the fuse registers might be calculated with e.g. an online [http://www.engbedded.com/fusecalc AVR fuse calculator]. [http://www.mikrocontroller.net/articles/AVR_Fuses Article on mikrocontroller.net for reference (German).] == Writing the Bytes == * Disconnect the power from the target board * Connect your ISP cable to the programmer and the target board * Reconnect the power and connect your programmer to the PC * Execute the command you assembled earlier or type ''make program'' * Congratulations! If [[avrdude]] finished without any error you successfully flashed [[Ethersex]] to your target board! * Disconnect the power and the programmer from the target * Reconnect the power, your target should boot up with [[Ethersex]] [[Quick_Start_Guide/Configuration | previous step]] | [[Category:Ethersex]] [[Category:Quick Start Guide]] [[Category:StepByStep]] ff16d4f0c37734a3496835717c35aa989b656f65 6 371 1104 2013-07-15T21:07:40Z Michaelb 718 AVRDude configuration menu details wikitext text/x-wiki AVRDude configuration menu details 66ef689f651077c254027a9dafa54107b3fda035 0 42 1124 417 2013-07-18T06:51:10Z Michaelb 718 wikitext text/x-wiki {{i18n|Quick Start Guide}} INTROTEXT GOES HERE [[Quick_Start_Guide/Preparation | Step 1: Preparation]] [[Quick_Start_Guide/Configuration | Step 2: Configuration]] [[Quick_Start_Guide/Flashing | Step 3: Flashing]] [[Category:Ethersex]] [[Category:QuickStartGuide]] [[Category:StepByStep]] 94246b6cc7da63b71c6a297df560a3d1fba9273e 1125 1124 2013-07-18T06:53:20Z Michaelb 718 wikitext text/x-wiki {{i18n|Quick Start Guide}} INTROTEXT GOES HERE [[Quick_Start_Guide/Preparation | Step 1: Preparation]] [[Quick_Start_Guide/Configuration | Step 2: Configuration]] [[Quick_Start_Guide/Flashing | Step 3: Flashing]] [[Category:Ethersex]] [[Category:Quick Start Guide]] [[Category:StepByStep]] 0ff00facbf60305405eb4c43f4175bf83ca02136 1144 1125 2013-07-18T20:49:15Z Joerg.hermann 719 wikitext text/x-wiki {{i18n|Quick Start Guide}} It only takes three small steps to get Ethersex up and running on your microcontroller! [[Quick_Start_Guide/Preparation | Step 1: Preparation]] [[Quick_Start_Guide/Configuration | Step 2: Configuration]] [[Quick_Start_Guide/Flashing | Step 3: Flashing]] [[Category:Ethersex]] [[Category:Quick Start Guide]] [[Category:StepByStep]] 810ea7c258bb1db013568e357db70443ff167c14 0 171 1127 416 2013-07-18T06:55:11Z Michaelb 718 wikitext text/x-wiki {{i18n|Quick Start Guide/Configuration}} [[File:E6menuconfig.png|right|thumb|400px| make menuconfig inside the hardware menu]] After [[Quick_Start_Guide/Preparation | installing the required software and cloning the repository]], ''cd'' to the root directory of ethersex. == General Settings == Type make menuconfig to start the text-based configuration UI of ethersex. Select the default configuration by selecting (enter). Load a Default Configuration ---> Now select for example Pollin AVR Net-IO Back in the main menu, enter General Setup ---> and select your '''Target MCU''' followed by the '''MCU frequency''' in Hz Go back to the main menu and enter the Network ---> menu. Select Ethernet (ENC28J60) support ---> and enter the '''MAC address''' Now adjust the '''IP address''' and '''Netmask''' for your network. Exit this menu as well as the '''Network''' menu. Hit the '''< Exit >''' button once again and select '''< Yes >''' to save your config. == Compiling == Run make to start the build process. This will only take a few seconds. If everything went well, which means you see something like this... <pre> =======The ethersex project======== Compiled for: atmega644p at 20000000Hz Imagesize: 36057/65536 bytes (55.02%) [================--------------] Program (.text + .data) : 28098 bytes Data (.data + .bss) : 1698 bytes =================================== </pre> ...you are ready to [[Quick_Start_Guide/Flashing | flash the firmware to your board!]] [[Quick_Start_Guide/Preparation | previous step]] | [[Quick_Start_Guide/Flashing | next step]] [[Category:Ethersex]] [[Category:Quick Start Guide]] [[Category:StepByStep]] 0a091a5e3146225b96fc6f8f5cfd21d7fbdfd976 0 58 1129 197 2013-07-18T18:53:33Z Joerg.hermann 719 /* Mac OS X */ wikitext text/x-wiki {{i18n|Quick Start Guide}} === Lade den Quellcode von GITHUB herunter === Du kannst Ethersex von github über das Git-Protokoll herunterladen git clone git://github.com/ethersex/ethersex.git oder über http git clone http://github.com/ethersex/ethersex.git Das Hochladen einer neuen Version von Ethersex ist möglich mit: git pull origin === Vorraussetzungen === * AVR GCC-Compiler (Version 4.1 oder höher) * AVR LIBC (Version 1.6.8, für 128er ATMegas 1.7) * GNU-Tools (Bash, Make, m4, awk) * AVR-Programmer (z.B. avrdude) == Linux Debian / Ubuntu == apt-get install gcc-avr avr-libc binutils-avr m4 gawk libncurses5-dev make dialog git-core avrdude == Mac OS X == Zum Einsatz von ethersex müssen auf Mac OS X noch Softwarepakete installiert werden. Dazu wird [http://www.macports.org MacPorts] benutzt. Sollten die Softwarepakete von Mac Port nicht aktuell sein, gibt es eine [http://www.heise.de/ct/projekte/machmit/ctbot/wiki/AVRToolchain Anleitung], die Arbeitsumgebung für AVR manuell zu bauen. Die Nutzung von Mac Ports ist einfacher und führt schneller zum Ziel. Wer schon einen Atmel AVR programmiert und geflasht hat, besitzt bereits eine funktionierende Arbeitsumgebung. Wenn nicht, müssen zuerst die Softwarepakete zur Programmierung eines AVR installiert werden: sudo port install avr-binutils avr-gcc avr-libc avrdude Für Neueinsteiger wird als Fingerübung empfohlen, eine LED auf dem AVR zum Blinken zu bringen, bevor man sich in das ethersex Abenteuer stürzt. Wer bereits git nutzt, kann den nächsten Schritt auch überspringen: sudo port install git-core Nun kommen die Softwarepakete, die von ethersex benötigt werden: sudo port install bash gsed gawk dialog 9fe7911e9e9fec8cbbc7777d88fb01cf084c5f11 1130 1129 2013-07-18T19:05:34Z Joerg.hermann 719 /* Mac OS X */ wikitext text/x-wiki {{i18n|Quick Start Guide}} === Lade den Quellcode von GITHUB herunter === Du kannst Ethersex von github über das Git-Protokoll herunterladen git clone git://github.com/ethersex/ethersex.git oder über http git clone http://github.com/ethersex/ethersex.git Das Hochladen einer neuen Version von Ethersex ist möglich mit: git pull origin === Vorraussetzungen === * AVR GCC-Compiler (Version 4.1 oder höher) * AVR LIBC (Version 1.6.8, für 128er ATMegas 1.7) * GNU-Tools (Bash, Make, m4, awk) * AVR-Programmer (z.B. avrdude) == Linux Debian / Ubuntu == apt-get install gcc-avr avr-libc binutils-avr m4 gawk libncurses5-dev make dialog git-core avrdude == Mac OS X == Zum Einsatz von ethersex müssen auf Mac OS X noch Softwarepakete installiert werden. Dazu wird [http://www.macports.org MacPorts] benutzt. Sollten die Softwarepakete von MacPorts nicht aktuell sein, gibt es eine [http://www.heise.de/ct/projekte/machmit/ctbot/wiki/AVRToolchain Anleitung], die Arbeitsumgebung für AVR manuell zu bauen. Die Nutzung von MacPorts ist einfacher und führt schneller zum Ziel. Wer schon einen Atmel AVR programmiert und geflasht hat, besitzt bereits eine funktionierende Arbeitsumgebung. Wenn nicht, müssen zuerst die Softwarepakete zur Programmierung eines AVR installiert werden: sudo port install avr-binutils avr-gcc avr-libc avrdude Für Neueinsteiger wird als Fingerübung empfohlen, eine LED auf dem AVR zum Blinken zu bringen, bevor man sich in das ethersex Abenteuer stürzt. Wer bereits git nutzt, kann den nächsten Schritt überspringen: sudo port install git-core Es folgen die Softwarepakete, die von ethersex benötigt werden: sudo port install bash gsed gawk dialog 89f9b1aa6a23df1aa60455105dd731a80c2db7d5 1135 1130 2013-07-18T20:10:56Z Joerg.hermann 719 /* Mac OS X */ wikitext text/x-wiki {{i18n|Quick Start Guide}} === Lade den Quellcode von GITHUB herunter === Du kannst Ethersex von github über das Git-Protokoll herunterladen git clone git://github.com/ethersex/ethersex.git oder über http git clone http://github.com/ethersex/ethersex.git Das Hochladen einer neuen Version von Ethersex ist möglich mit: git pull origin === Vorraussetzungen === * AVR GCC-Compiler (Version 4.1 oder höher) * AVR LIBC (Version 1.6.8, für 128er ATMegas 1.7) * GNU-Tools (Bash, Make, m4, awk) * AVR-Programmer (z.B. avrdude) == Linux Debian / Ubuntu == apt-get install gcc-avr avr-libc binutils-avr m4 gawk libncurses5-dev make dialog git-core avrdude == Mac OS X == Zum Einsatz von Ethersex müssen auf Mac OS X noch Softwarepakete installiert werden. Dazu wird [http://www.macports.org MacPorts] benutzt. Sollten die Softwarepakete von MacPorts nicht aktuell sein, gibt es eine [http://www.heise.de/ct/projekte/machmit/ctbot/wiki/AVRToolchain Anleitung], die Arbeitsumgebung für AVR manuell zu bauen. Die Nutzung von MacPorts ist einfacher und führt schneller zum Ziel. Wer schon einen Atmel AVR programmiert und geflasht hat, besitzt bereits eine funktionierende Arbeitsumgebung. Wenn nicht, müssen zuerst die Softwarepakete zur Programmierung eines AVR installiert werden: sudo port install avr-binutils avr-gcc avr-libc avrdude Für Neueinsteiger wird als Fingerübung empfohlen, eine LED auf dem AVR zum Blinken zu bringen, bevor man sich in das Ethersex Abenteuer stürzt. Wer bereits git nutzt, kann den nächsten Schritt überspringen: sudo port install git-core Es folgen die Softwarepakete, die von Ethersex benötigt werden: sudo port install bash gsed gawk dialog 681f93d5d183b567346aa349dd1d10ea893902b6 1145 1135 2013-07-18T20:53:39Z Joerg.hermann 719 Structure as on english page. wikitext text/x-wiki {{i18n|Quick Start Guide}} Mit drei Schritten läuft Ethersex auf Ihrem Microcontroller! [[Quick_Start_Guide/Preparation | Step 1: Vorbereitung]] [[Quick_Start_Guide/Configuration | Step 2: Konfiguration]] [[Quick_Start_Guide/Flashing | Step 3: Flashen]] [[Category:Ethersex]] [[Category:Quick Start Guide]] [[Category:StepByStep]] 2d2c3512881e2f10a11b4c820f7614cb1e8ee01e 1146 1145 2013-07-19T05:25:46Z GooPie4o 265 wikitext text/x-wiki {{i18n|Quick Start Guide}} Mit drei Schritten läuft Ethersex auf Ihrem Microcontroller! [[Quick_Start_Guide/Preparation_(Deutsch) | Step 1: Vorbereitung]] [[Quick_Start_Guide/Configuration_(Deutsch) | Step 2: Konfiguration]] [[Quick_Start_Guide/Flashing_(Deutsch) | Step 3: Flashen]] [[Category:Ethersex]] [[Category:Quick Start Guide]] [[Category:StepByStep]] 86566509391bcb29eed5e73f4a77150bab5a271c 0 5 1131 511 2013-07-18T20:07:21Z GooPie4o 265 moved [[Main Page]] to [[Ethersex]] wikitext text/x-wiki {{i18n|Main Page}} {{NewWiki}} == Welcome to ethersex.de - the universal AVR firmware == {|style="width:100%;" |style="width:33%;"|{{Facts}} |style="width:33%;vertical-align:baseline;height:100%"|{{Getting Started}} |style="width:33%;vertical-align:baseline;height:100%"|{{Documentation}} |- |} 51c594a36adb4c230b648eabad4ebe5c25ae16eb 1133 1131 2013-07-18T20:10:08Z GooPie4o 265 wikitext text/x-wiki {{i18n|Ethersex}} {{NewWiki}} == Welcome to ethersex.de - the universal AVR firmware == {|style="width:100%;" |style="width:33%;"|{{Facts}} |style="width:33%;vertical-align:baseline;height:100%"|{{Getting Started}} |style="width:33%;vertical-align:baseline;height:100%"|{{Documentation}} |- |} 28facb6ff3f2d3dbc8fb3adb28a61a9cb43ade2b 0 372 1132 2013-07-18T20:07:21Z GooPie4o 265 moved [[Main Page]] to [[Ethersex]] wikitext text/x-wiki #REDIRECT [[Ethersex]] 155d91758ca56cbe914165f976b7ea0461c4b61f 0 57 1134 512 2013-07-18T20:10:41Z GooPie4o 265 wikitext text/x-wiki {{i18n|Ethersex}} {{NewWiki (Deutsch)}} == Willkommen bei ethersex.de - der universalen AVR Firmware == {|style="width:100%;" |style="width:33%;"|{{Facts (Deutsch)}} |style="width:33%;vertical-align:baseline;height:100%"|{{Getting Started (Deutsch)}} |style="width:33%;vertical-align:baseline;height:100%"|{{Documentation (Deutsch)}} |- |} 589ab6bc70eba695550dd60534099c919c5b2059 1136 1134 2013-07-18T20:11:23Z GooPie4o 265 moved [[Main Page (Deutsch)]] to [[Ethersex (Deutsch)]] wikitext text/x-wiki {{i18n|Ethersex}} {{NewWiki (Deutsch)}} == Willkommen bei ethersex.de - der universalen AVR Firmware == {|style="width:100%;" |style="width:33%;"|{{Facts (Deutsch)}} |style="width:33%;vertical-align:baseline;height:100%"|{{Getting Started (Deutsch)}} |style="width:33%;vertical-align:baseline;height:100%"|{{Documentation (Deutsch)}} |- |} 589ab6bc70eba695550dd60534099c919c5b2059 0 373 1137 2013-07-18T20:11:23Z GooPie4o 265 moved [[Main Page (Deutsch)]] to [[Ethersex (Deutsch)]] wikitext text/x-wiki #REDIRECT [[Ethersex (Deutsch)]] dcd89c917c88ec66e6a6e81fdea37fcb32403980 0 169 1138 1025 2013-07-18T20:15:37Z Joerg.hermann 719 /* Mac OS X */ wikitext text/x-wiki {{i18n|Quick Start Guide/Preparation}} = Requirements = * AVR GCC-Compiler (Version 4.1 or higher) * AVR LIBC (Version 1.6.8, for 128er ATMegas 1.7) * GNU-Tools (Bash, Make, m4, awk) * AVR-Programmer (e.g. avrdude) '''Attention:''' binutils ''2.22'' has a bug that causes the compilation of ethersex to fail. Install version 2.21 until [http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52692 GCC 4.7.1 has been released]. == Linux Debian / Ubuntu == apt-get install gcc-avr avr-libc binutils-avr m4 gawk libncurses5-dev make dialog git-core avrdude == Arch Linux == pacman -Sy m4 avr-binutils avr-libc avrdude avr-gcc git gawk ncurses make perl == FreeBSD == add gmake avr-binutils avr-gcc avr-libc (to compile) add gsed m4 gawk (need for ethersex), add avrdude git use add_page -r PKG-NAME or use ports (goggle freebsd ports install) == Mac OS X == Before compiling Ethersex on Mac OS X additional software packages need to be installed. [http://www.macports.org MacPorts] are used for that. In case MacPorts are outdated, there is a [http://www.heise.de/ct/projekte/machmit/ctbot/wiki/AVRToolchain guide] for building the AVR toolchain manually. Using MacPorts is easier and faster. Who already programmed and flashed an Atmel AVR has a proper working environment. Else the packages for programming an AVR need to be installed: sudo port install avr-binutils avr-gcc avr-libc avrdude For newbies it is recommended to connect a LED and have that flashing by the AVR before jumping into the Ethersex adventure. Who already uses git, can skip the next step: sudo port install git-core Now install the software packages that are required by Ethersex: sudo port install bash gsed gawk dialog = Download the Source from GitHub = You can download Ethersex from github via git protocol git clone git://github.com/ethersex/ethersex.git or via http git clone http://github.com/ethersex/ethersex.git Updating a local version of ethersex is possible with: git pull origin [[Quick_Start_Guide/Configuration | next step]] 37fa643e9cfe1e10ff3cc308766fc0dcd7f21799 0 374 1139 2013-07-18T20:22:36Z Michaelb 718 Created page with "{{i18n|Quick Start Guide/Preparation}} = Anforderungen =" wikitext text/x-wiki {{i18n|Quick Start Guide/Preparation}} = Anforderungen = f80368d0ee4b9d7487745f5c3a8fe10c94bc7fb0 1142 1139 2013-07-18T20:42:26Z Joerg.hermann 719 /* Voraussetzungen */ wikitext text/x-wiki {{i18n|Quick Start Guide/Preparation}} {{i18n|Quick Start Guide/Preparation}} = Voraussetzungen = * AVR GCC-Compiler, Version 4.1 oder höher * AVR LIBC Version 1.6.8, für 128er ATMegas 1.7 * GNU-Tools Bash, Make, m4, awk * AVR-Programmier Werkzeug, z. B. avrdude '''Achtung:''' binutils ''2.22'' hat einen Fehler, der das Übersetzen von Ethersex abbricht. Installiere Version 2.21 bis [http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52692 GCC 4.7.1] verfügbar ist. == Linux Debian / Ubuntu == apt-get install gcc-avr avr-libc binutils-avr m4 gawk libncurses5-dev make dialog git-core avrdude == Arch Linux == pacman -Sy m4 avr-binutils avr-libc avrdude avr-gcc git gawk ncurses make perl == FreeBSD == add gmake avr-binutils avr-gcc avr-libc (to compile) add gsed m4 gawk (need for ethersex), add avrdude git use add_page -r PKG-NAME or use ports (goggle freebsd ports install) == Mac OS X == Zum Einsatz von Ethersex müssen auf Mac OS X noch Softwarepakete installiert werden. Dazu wird [http://www.macports.org MacPorts] benutzt. Sollten die Softwarepakete von MacPorts nicht aktuell sein, gibt es eine [http://www.heise.de/ct/projekte/machmit/ctbot/wiki/AVRToolchain Anleitung], die Arbeitsumgebung für AVR manuell zu bauen. Die Nutzung von MacPorts ist einfacher und führt schneller zum Ziel. Wer schon einen Atmel AVR programmiert und geflasht hat, besitzt bereits eine funktionierende Arbeitsumgebung. Wenn nicht, müssen zuerst die Softwarepakete zur Programmierung eines AVR installiert werden: sudo port install avr-binutils avr-gcc avr-libc avrdude Für Neueinsteiger wird als Fingerübung empfohlen, eine LED auf dem AVR zum Blinken zu bringen, bevor man sich in das Ethersex Abenteuer stürzt. Wer bereits git nutzt, kann den nächsten Schritt überspringen: sudo port install git-core Es folgen die Softwarepakete, die von Ethersex benötigt werden: sudo port install bash gsed gawk dialog = Sourcen von GitHub holen= Entweder mit git clone git://github.com/ethersex/ethersex.git oder via http git clone http://github.com/ethersex/ethersex.git Die lokale Version von Ethersex wird aktualisiert mit: git pull origin [[Quick_Start_Guide/Configuration | Nächster Schritt]] f65968c114148dc725f271bc6ee09dc561b5a555 1143 1142 2013-07-18T20:45:39Z Joerg.hermann 719 wikitext text/x-wiki {{i18n|Quick Start Guide/Preparation}} = Voraussetzungen = * AVR GCC-Compiler, Version 4.1 oder höher * AVR LIBC Version 1.6.8, für 128er ATMegas 1.7 * GNU-Tools Bash, Make, m4, awk * AVR-Programmier Werkzeug, z. B. avrdude '''Achtung:''' binutils ''2.22'' hat einen Fehler, der das Übersetzen von Ethersex abbricht. Installiere Version 2.21 bis [http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52692 GCC 4.7.1] verfügbar ist. == Linux Debian / Ubuntu == apt-get install gcc-avr avr-libc binutils-avr m4 gawk libncurses5-dev make dialog git-core avrdude == Arch Linux == pacman -Sy m4 avr-binutils avr-libc avrdude avr-gcc git gawk ncurses make perl == FreeBSD == add gmake avr-binutils avr-gcc avr-libc (to compile) add gsed m4 gawk (need for ethersex), add avrdude git use add_page -r PKG-NAME or use ports (goggle freebsd ports install) == Mac OS X == Zum Einsatz von Ethersex müssen auf Mac OS X noch Softwarepakete installiert werden. Dazu wird [http://www.macports.org MacPorts] benutzt. Sollten die Softwarepakete von MacPorts nicht aktuell sein, gibt es eine [http://www.heise.de/ct/projekte/machmit/ctbot/wiki/AVRToolchain Anleitung], die Arbeitsumgebung für AVR manuell zu bauen. Die Nutzung von MacPorts ist einfacher und führt schneller zum Ziel. Wer schon einen Atmel AVR programmiert und geflasht hat, besitzt bereits eine funktionierende Arbeitsumgebung. Wenn nicht, müssen zuerst die Softwarepakete zur Programmierung eines AVR installiert werden: sudo port install avr-binutils avr-gcc avr-libc avrdude Für Neueinsteiger wird als Fingerübung empfohlen, eine LED auf dem AVR zum Blinken zu bringen, bevor man sich in das Ethersex Abenteuer stürzt. Wer bereits git nutzt, kann den nächsten Schritt überspringen: sudo port install git-core Es folgen die Softwarepakete, die von Ethersex benötigt werden: sudo port install bash gsed gawk dialog = Sourcen von GitHub holen= Entweder mit git clone git://github.com/ethersex/ethersex.git oder via http git clone http://github.com/ethersex/ethersex.git Die lokale Version von Ethersex wird aktualisiert mit: git pull origin [[Quick_Start_Guide/Configuration | Nächster Schritt]] fea3ee3cd9f61a38f3f0fbc091e4109b7ca4641d 0 375 1140 2013-07-18T20:25:36Z Michaelb 718 Created page with "{{i18n|Quick Start Guide/Configuration}} [[File:E6menuconfig.png|right|thumb|400px| make menuconfig inside the hardware menu]]" wikitext text/x-wiki {{i18n|Quick Start Guide/Configuration}} [[File:E6menuconfig.png|right|thumb|400px| make menuconfig inside the hardware menu]] 972110a8da78dbc2c0525b397c1069acdb1a92d3 0 376 1141 2013-07-18T20:27:09Z Michaelb 718 Created page with "{{i18n|Quick Start Guide/Flashing}} = Flashing =" wikitext text/x-wiki {{i18n|Quick Start Guide/Flashing}} = Flashing = 1da5fa3d85f209b92bad0bc62e6d1a5da5a26bf4 1147 1141 2013-07-19T05:26:42Z GooPie4o 265 /* Flashing */ wikitext text/x-wiki {{i18n|Quick Start Guide/Flashing}} = Flashen = bb62d748f9dde5515d1babb34066cae0b2837abb 6 377 1148 2013-07-19T06:36:31Z GooPie4o 265 BT0417C to MCU (5V) wikitext text/x-wiki BT0417C to MCU (5V) 67688d6ee82f59608f543c2c1d479d9884c11d86 6 378 1149 2013-07-19T06:37:05Z GooPie4o 265 BT0417C to MCU (3,3V) wikitext text/x-wiki BT0417C to MCU (3,3V) 66bdbf155a5cfdfc53979c617877105556608bad 0 368 1150 1083 2013-07-19T06:39:09Z GooPie4o 265 wikitext text/x-wiki {{i18n|Bluetooth}} {{Module |NAME=Bluetooth |MENUCONFIG={{I/O}}->Radio->Bluetooth |STATUS={{In_Development}} |PINNING=yes |ECMD= - |CONTROL6= - |DEPENDS= - |REQUIRES= - |TIMER= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/bluetooth https://github.com/ethersex/ethersex/tree/master/hardware/radio/bluetooth] }} == Connection == [[File:bt0417c_5v.jpg|200px|thumb|right|BT0417C to MCU (5V)]] [[File:bt0417c_3_3v.jpg|200px|thumb|right|BT0417C to MCU (3,3V)]] 3cccada2ba8d545eee750c75ea52ed309bdf85ba 1151 1150 2013-07-19T06:43:07Z GooPie4o 265 wikitext text/x-wiki {{i18n|Bluetooth}} {{Module |NAME=Bluetooth |MENUCONFIG={{I/O}}->Radio->Bluetooth |STATUS={{In_Development}} |PINNING=yes |ECMD= - |CONTROL6= - |DEPENDS= - |REQUIRES= - |TIMER= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/bluetooth https://github.com/ethersex/ethersex/tree/master/hardware/radio/bluetooth] }} BT0417C is a generic Bluetooth module loaded with SPP firmware for UART wireless cable replacement functions. == Connection == When used with 5V microcontrollers, The TXD output logic swing of the module still falls within the valid 5V TTL range, hence, can be connected directly to the UART RXD of the 5V microcontroller host. The RXD and inputs, however, are not 5V tolerant, and can be damaged by 5V level logic going in. Some level translation circuit must be added to protect the inputs. A simple diode level translator circuit like the ones shown in Figure 3 and 7 will suffice in most applications. A better alternative is with the use of 5V input tolerant tiny logic chips such as 74LVC1G125 – a single buffer chip housed in smd sot23-5 package. [[File:bt0417c_5v.jpg|200px|thumb|right|BT0417C to MCU (5V)]] [[File:bt0417c_3_3v.jpg|200px|thumb|right|BT0417C to MCU (3,3V)]] 5d5f55b83f0cce2cf5bf37f2ab649ca0af6b3e60 0 368 1152 1151 2013-07-19T06:45:42Z GooPie4o 265 wikitext text/x-wiki {{i18n|Bluetooth}} {{Module |NAME=Bluetooth |MENUCONFIG={{I/O}}->Radio->Bluetooth |STATUS={{In_Development}} |PINNING=yes |ECMD= - |CONTROL6= - |DEPENDS= - |REQUIRES= - |TIMER= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/bluetooth https://github.com/ethersex/ethersex/tree/master/hardware/radio/bluetooth] }} BT0417C is a generic Bluetooth module loaded with SPP firmware for UART wireless cable replacement functions. == Connection == When used with 5V microcontrollers, the TXD output logic swing of the module still falls within the valid 5V TTL range, hence, can be connected directly to the UART RXD of the 5V microcontroller host. The RXD and inputs, however, are not 5V tolerant, and can be damaged by 5V level logic going in. Some level translation circuit must be added to protect the inputs. A simple diode level translator circuit like the ones shown in Figure 3 and 7 will suffice in most applications. A better alternative is with the use of 5V input tolerant tiny logic chips such as 74LVC1G125 – a single buffer chip housed in smd sot23-5 package. [[File:bt0417c_5v.jpg|200px|thumb|right|BT0417C to MCU (5V)]] [[File:bt0417c_3_3v.jpg|200px|thumb|right|BT0417C to MCU (3,3V)]] 80a9b0f282478cf4812d0760f9acef00c318eefe 1153 1152 2013-07-19T06:47:54Z GooPie4o 265 wikitext text/x-wiki {{i18n|Bluetooth}} {{Module |NAME=Bluetooth |MENUCONFIG={{I/O}}->Radio->Bluetooth |STATUS={{In_Development}} |PINNING= - |ECMD= - |CONTROL6= - |DEPENDS= - |REQUIRES= - |TIMER= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/bluetooth https://github.com/ethersex/ethersex/tree/master/hardware/radio/bluetooth] }} BT0417C is a generic Bluetooth module loaded with SPP firmware for UART wireless cable replacement functions. == Connection == When used with 5V microcontrollers, the TXD output logic swing of the module still falls within the valid 5V TTL range, hence, can be connected directly to the UART RXD of the 5V microcontroller host. The RXD and inputs, however, are not 5V tolerant, and can be damaged by 5V level logic going in. Some level translation circuit must be added to protect the inputs. A simple diode level translator circuit like the ones shown in Figure 3 and 7 will suffice in most applications. A better alternative is with the use of 5V input tolerant tiny logic chips such as 74LVC1G125 – a single buffer chip housed in smd sot23-5 package. [[File:bt0417c_5v.jpg|200px|thumb|right|BT0417C to MCU (5V)]] [[File:bt0417c_3_3v.jpg|200px|thumb|right|BT0417C to MCU (3,3V)]] 1fc3291f6792eeb094bdfcb7c752ba6a40f09606 1154 1153 2013-07-19T06:56:16Z GooPie4o 265 wikitext text/x-wiki {{i18n|Bluetooth}} {{Module |NAME=Bluetooth |MENUCONFIG={{I/O}}->Radio->Bluetooth |STATUS={{In_Development}} |PINNING= - |ECMD= - |CONTROL6= - |DEPENDS= - |REQUIRES= - |TIMER= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/bluetooth https://github.com/ethersex/ethersex/tree/master/hardware/radio/bluetooth] }} BT0417C is a generic Bluetooth module loaded with SPP firmware for UART wireless cable replacement functions. It allows your target device to both send or receive the TTL data via Bluetooth technology without connecting a serial cable to your computer. Features: * TTL data transparent transfer between a host Bluetooth device * Compatible with all Bluetooth adapters that support SPP * Default baud rate: 9600,8,1,N * Pair code: 1234 * Built in antenna * Bluetooth Technology v2.0 compatible * Power input:3.3VDC * Compact Size == Connection == When used with 5V microcontrollers, the TXD output logic swing of the module still falls within the valid 5V TTL range, hence, can be connected directly to the UART RXD of the 5V microcontroller host. The RXD and inputs, however, are not 5V tolerant, and can be damaged by 5V level logic going in. Some level translation circuit must be added to protect the inputs. A simple diode level translator circuit like the ones shown in Figure 3 and 7 will suffice in most applications. A better alternative is with the use of 5V input tolerant tiny logic chips such as 74LVC1G125 – a single buffer chip housed in smd sot23-5 package. [[File:bt0417c_5v.jpg|200px|thumb|right|BT0417C to MCU (5V)]] [[File:bt0417c_3_3v.jpg|200px|thumb|right|BT0417C to MCU (3,3V)]] 744d951cf6605d91c4b09781d230fe1dc15512e3 1155 1154 2013-07-19T07:13:44Z GooPie4o 265 /* Connection */ wikitext text/x-wiki {{i18n|Bluetooth}} {{Module |NAME=Bluetooth |MENUCONFIG={{I/O}}->Radio->Bluetooth |STATUS={{In_Development}} |PINNING= - |ECMD= - |CONTROL6= - |DEPENDS= - |REQUIRES= - |TIMER= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/bluetooth https://github.com/ethersex/ethersex/tree/master/hardware/radio/bluetooth] }} BT0417C is a generic Bluetooth module loaded with SPP firmware for UART wireless cable replacement functions. It allows your target device to both send or receive the TTL data via Bluetooth technology without connecting a serial cable to your computer. Features: * TTL data transparent transfer between a host Bluetooth device * Compatible with all Bluetooth adapters that support SPP * Default baud rate: 9600,8,1,N * Pair code: 1234 * Built in antenna * Bluetooth Technology v2.0 compatible * Power input:3.3VDC * Compact Size == Connection == [[File:bt0417c_5v.jpg|200px|thumb|right|BT0417C to MCU (5V)]] [[File:bt0417c_3_3v.jpg|200px|thumb|right|BT0417C to MCU (3,3V)]] When used with 5V microcontrollers, the TXD output logic swing of the module still falls within the valid 5V TTL range, hence, can be connected directly to the UART RXD of the 5V microcontroller host. The RXD and inputs, however, are not 5V tolerant, and can be damaged by 5V level logic going in. Some level translation circuit must be added to protect the inputs. A simple diode level translator circuit like the ones shown in Figure 3 and 7 will suffice in most applications. A better alternative is with the use of 5V input tolerant tiny logic chips such as 74LVC1G125 – a single buffer chip housed in smd sot23-5 package. b0ebf1c2b20c42923c6b696c3dbd3d8eef57da38 1157 1155 2013-07-19T12:52:09Z GooPie4o 265 wikitext text/x-wiki {{i18n|Bluetooth}} {{Module |NAME=Bluetooth |MENUCONFIG={{I/O}}->Radio->Bluetooth |STATUS={{In_Development}} |PINNING= - |ECMD= - |CONTROL6= - |DEPENDS= - |REQUIRES= - |TIMER= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/bluetooth https://github.com/ethersex/ethersex/tree/master/hardware/radio/bluetooth] }} BT0417C is a generic Bluetooth module loaded with SPP firmware for UART wireless cable replacement functions. It allows your target device to both send or receive the TTL data via Bluetooth technology without connecting a serial cable to your computer. Features: * TTL data transparent transfer between a host Bluetooth device * Compatible with all Bluetooth adapters that support SPP * Default baud rate: 9600,8,1,N * Pair code: 1234 * Built in antenna * Bluetooth Technology v2.0 compatible * Power input:3.3VDC * Compact Size == Connection == [[File:bt0417c_5v.jpg|200px|thumb|right|BT0417C to MCU (5V)]] [[File:bt0417c_3_3v.jpg|200px|thumb|right|BT0417C to MCU (3,3V)]] When used with 5V microcontrollers, the TXD output logic swing of the module still falls within the valid 5V TTL range, hence, can be connected directly to the UART RXD of the 5V microcontroller host. The RXD and inputs, however, are not 5V tolerant, and can be damaged by 5V level logic going in. Some level translation circuit must be added to protect the inputs. A simple diode level translator circuit like the ones shown in Figure 3 and 7 will suffice in most applications. A better alternative is with the use of 5V input tolerant tiny logic chips such as 74LVC1G125 – a single buffer chip housed in smd sot23-5 package. == Configuration == == [[ECMD]] === 6b88848ea3681ac3fff55a6c08a5923c902a15c7 1158 1157 2013-07-19T12:52:31Z GooPie4o 265 wikitext text/x-wiki {{i18n|Bluetooth}} {{Module |NAME=Bluetooth |MENUCONFIG={{I/O}}->Radio->Bluetooth |STATUS={{In_Development}} |PINNING= - |ECMD= - |CONTROL6= - |DEPENDS= - |REQUIRES= - |TIMER= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/bluetooth https://github.com/ethersex/ethersex/tree/master/hardware/radio/bluetooth] }} BT0417C is a generic Bluetooth module loaded with SPP firmware for UART wireless cable replacement functions. It allows your target device to both send or receive the TTL data via Bluetooth technology without connecting a serial cable to your computer. Features: * TTL data transparent transfer between a host Bluetooth device * Compatible with all Bluetooth adapters that support SPP * Default baud rate: 9600,8,1,N * Pair code: 1234 * Built in antenna * Bluetooth Technology v2.0 compatible * Power input:3.3VDC * Compact Size == Connection == [[File:bt0417c_5v.jpg|200px|thumb|right|BT0417C to MCU (5V)]] [[File:bt0417c_3_3v.jpg|200px|thumb|right|BT0417C to MCU (3,3V)]] When used with 5V microcontrollers, the TXD output logic swing of the module still falls within the valid 5V TTL range, hence, can be connected directly to the UART RXD of the 5V microcontroller host. The RXD and inputs, however, are not 5V tolerant, and can be damaged by 5V level logic going in. Some level translation circuit must be added to protect the inputs. A simple diode level translator circuit like the ones shown in Figure 3 and 7 will suffice in most applications. A better alternative is with the use of 5V input tolerant tiny logic chips such as 74LVC1G125 – a single buffer chip housed in smd sot23-5 package. == Configuration == == [[ECMD]] == 17c8ba08e484fea5b58710052d876ac8f0e05b5a 1164 1158 2013-07-20T10:56:31Z GooPie4o 265 wikitext text/x-wiki {{i18n|Bluetooth}} {{Module |NAME=Bluetooth |MENUCONFIG={{I/O}}->Radio->Bluetooth |STATUS={{In_Development}} |PINNING= - |ECMD= - |CONTROL6= - |DEPENDS= - |REQUIRES= - |TIMER= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/bluetooth https://github.com/ethersex/ethersex/tree/master/hardware/radio/bluetooth] }} [[File:bt0417c.jpg|200px|thumb|right|module and breakout board]] BT0417C is a generic Bluetooth module loaded with SPP firmware for UART wireless cable replacement functions. It allows your target device to both send or receive the TTL data via Bluetooth technology without connecting a serial cable to your computer. Features: * TTL data transparent transfer between a host Bluetooth device * Compatible with all Bluetooth adapters that support SPP * Default baud rate: 9600,8,1,N * Pair code: 1234 * Built in antenna * Bluetooth Technology v2.0 compatible * Power input:3.3VDC * Compact Size == Connection == [[File:bt0417c_5v.jpg|200px|thumb|right|BT0417C to MCU (5V)]] [[File:bt0417c_3_3v.jpg|200px|thumb|right|BT0417C to MCU (3,3V)]] When used with 5V microcontrollers, the TXD output logic swing of the module still falls within the valid 5V TTL range, hence, can be connected directly to the UART RXD of the 5V microcontroller host. The RXD and inputs, however, are not 5V tolerant, and can be damaged by 5V level logic going in. Some level translation circuit must be added to protect the inputs. A simple diode level translator circuit like the ones shown in Figure 3 and 7 will suffice in most applications. A better alternative is with the use of 5V input tolerant tiny logic chips such as 74LVC1G125 – a single buffer chip housed in smd sot23-5 package. == Configuration == == [[ECMD]] == faabd8e9e9679f796e24f8090cf9828b97b27970 1165 1164 2013-07-20T11:05:01Z GooPie4o 265 wikitext text/x-wiki {{i18n|Bluetooth}} {{Module |NAME=Bluetooth |MENUCONFIG={{I/O}}->Radio->Bluetooth |STATUS={{In_Development}} |PINNING= - |ECMD= - |CONTROL6= - |DEPENDS= - |REQUIRES= - |TIMER= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/bluetooth https://github.com/ethersex/ethersex/tree/master/hardware/radio/bluetooth] }} BT0417C is a generic Bluetooth module loaded with SPP firmware for UART wireless cable replacement functions. It allows your target device to both send or receive the TTL data via Bluetooth technology without connecting a serial cable to your computer. Features: * TTL data transparent transfer between a host Bluetooth device * Compatible with all Bluetooth adapters that support SPP * Default baud rate: 9600,8,1,N * Pair code: 1234 * Built in antenna * Bluetooth Technology v2.0 compatible * Power input:3.3VDC * Compact Size == Connection == When used with 5V microcontrollers, the TXD output logic swing of the module still falls within the valid 5V TTL range, hence, can be connected directly to the UART RXD of the 5V microcontroller host. The RXD and inputs, however, are not 5V tolerant, and can be damaged by 5V level logic going in. Some level translation circuit must be added to protect the inputs. A simple diode level translator circuit like the ones shown in Figure 3 and 7 will suffice in most applications. A better alternative is with the use of 5V input tolerant tiny logic chips such as 74LVC1G125 – a single buffer chip housed in smd sot23-5 package. <gallery> File:bt0417c.jpg|BT0417C and breakout board File:bt0417c_5v.jpg|BT0417C to MCU (5V) File:bt0417c_3_3v.jpg|BT0417C to MCU (3,3V) </gallery> == Configuration == == [[ECMD]] == 8408e57a1b3f720fa2848c0ec902fb71163691d5 1166 1165 2013-07-21T12:43:12Z GooPie4o 265 wikitext text/x-wiki {{i18n|Bluetooth}} {{Module |NAME=Bluetooth |MENUCONFIG={{I/O}}->Radio->Bluetooth |STATUS={{In_Development}} |PINNING= - |ECMD= - |CONTROL6= - |DEPENDS= - |REQUIRES= - |TIMER= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/bluetooth https://github.com/ethersex/ethersex/tree/master/hardware/radio/bluetooth] }} BT0417C is a generic Bluetooth module loaded with SPP firmware for UART wireless cable replacement functions. It allows your target device to both send or receive the TTL data via Bluetooth technology without connecting a serial cable to your computer. Features: * TTL data transparent transfer between a host Bluetooth device * Compatible with all Bluetooth adapters that support SPP * Default baud rate: 9600,8,1,N * Pair code: 1234 * Built in antenna * Bluetooth Technology v2.0 compatible * Power input:3.3VDC * Compact Size == Connection == When used with 5V microcontrollers, the TXD output logic swing of the module still falls within the valid 5V TTL range, hence, can be connected directly to the UART RXD of the 5V microcontroller host. The RXD and inputs, however, are not 5V tolerant, and can be damaged by 5V level logic going in. Some level translation circuit must be added to protect the inputs. A simple diode level translator circuit like the ones shown in Figure 3 and 7 will suffice in most applications. A better alternative is with the use of 5V input tolerant tiny logic chips such as 74LVC1G125 – a single buffer chip housed in smd sot23-5 package. <gallery> File:bt0417c.jpg|BT0417C and breakout board File:bt0417c_5v.jpg|BT0417C to MCU (5V) File:bt0417c_3_3v.jpg|BT0417C to MCU (3,3V) </gallery> == Configuration == == [[ECMD]] == == Links == [http://www.multiwii.com/forum/viewtopic.php?f=6&t=133 Serial Bluetooth RF Transceiver Module RS232] 3fd6c34f9712cc7e41d804a94a903d0fbfef057d 1167 1166 2013-07-21T14:53:21Z GooPie4o 265 /* Links */ wikitext text/x-wiki {{i18n|Bluetooth}} {{Module |NAME=Bluetooth |MENUCONFIG={{I/O}}->Radio->Bluetooth |STATUS={{In_Development}} |PINNING= - |ECMD= - |CONTROL6= - |DEPENDS= - |REQUIRES= - |TIMER= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/bluetooth https://github.com/ethersex/ethersex/tree/master/hardware/radio/bluetooth] }} BT0417C is a generic Bluetooth module loaded with SPP firmware for UART wireless cable replacement functions. It allows your target device to both send or receive the TTL data via Bluetooth technology without connecting a serial cable to your computer. Features: * TTL data transparent transfer between a host Bluetooth device * Compatible with all Bluetooth adapters that support SPP * Default baud rate: 9600,8,1,N * Pair code: 1234 * Built in antenna * Bluetooth Technology v2.0 compatible * Power input:3.3VDC * Compact Size == Connection == When used with 5V microcontrollers, the TXD output logic swing of the module still falls within the valid 5V TTL range, hence, can be connected directly to the UART RXD of the 5V microcontroller host. The RXD and inputs, however, are not 5V tolerant, and can be damaged by 5V level logic going in. Some level translation circuit must be added to protect the inputs. A simple diode level translator circuit like the ones shown in Figure 3 and 7 will suffice in most applications. A better alternative is with the use of 5V input tolerant tiny logic chips such as 74LVC1G125 – a single buffer chip housed in smd sot23-5 package. <gallery> File:bt0417c.jpg|BT0417C and breakout board File:bt0417c_5v.jpg|BT0417C to MCU (5V) File:bt0417c_3_3v.jpg|BT0417C to MCU (3,3V) </gallery> == Configuration == == [[ECMD]] == == Links == [http://www.multiwii.com/forum/viewtopic.php?f=6&t=133 Serial Bluetooth RF Transceiver Module RS232]<br> [http://byron76.blogspot.de/ Firmware programmer] a12f35b21deafe4515bf281e44d7396b815e340d 1168 1167 2013-07-21T14:56:07Z GooPie4o 265 /* Connection */ wikitext text/x-wiki {{i18n|Bluetooth}} {{Module |NAME=Bluetooth |MENUCONFIG={{I/O}}->Radio->Bluetooth |STATUS={{In_Development}} |PINNING= - |ECMD= - |CONTROL6= - |DEPENDS= - |REQUIRES= - |TIMER= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/bluetooth https://github.com/ethersex/ethersex/tree/master/hardware/radio/bluetooth] }} BT0417C is a generic Bluetooth module loaded with SPP firmware for UART wireless cable replacement functions. It allows your target device to both send or receive the TTL data via Bluetooth technology without connecting a serial cable to your computer. Features: * TTL data transparent transfer between a host Bluetooth device * Compatible with all Bluetooth adapters that support SPP * Default baud rate: 9600,8,1,N * Pair code: 1234 * Built in antenna * Bluetooth Technology v2.0 compatible * Power input:3.3VDC * Compact Size == Connection == When used with 5V microcontrollers, the TXD output logic swing of the module still falls within the valid 5V TTL range, hence, can be connected directly to the UART RXD of the 5V microcontroller host. The RXD and inputs, however, are not 5V tolerant, and can be damaged by 5V level logic going in. Some level translation circuit must be added to protect the inputs. A simple diode level translator circuit like the ones shown in Figure 3 and 7 will suffice in most applications. A better alternative is with the use of 5V input tolerant tiny logic chips such as 74LVC1G125 – a single buffer chip housed in SMD SOT23-5 package. <gallery> File:bt0417c.jpg|BT0417C and breakout board File:bt0417c_5v.jpg|BT0417C to MCU (5V) File:bt0417c_3_3v.jpg|BT0417C to MCU (3,3V) </gallery> Attention: there are different version of the module and breakout board around with different firmware and different pin assignment. == Configuration == == [[ECMD]] == == Links == [http://www.multiwii.com/forum/viewtopic.php?f=6&t=133 Serial Bluetooth RF Transceiver Module RS232]<br> [http://byron76.blogspot.de/ Firmware programmer] a84cd719923f3d68166bc606611285b67adf9bd2 1169 1168 2013-07-22T16:45:05Z GooPie4o 265 /* Connection */ wikitext text/x-wiki {{i18n|Bluetooth}} {{Module |NAME=Bluetooth |MENUCONFIG={{I/O}}->Radio->Bluetooth |STATUS={{In_Development}} |PINNING= - |ECMD= - |CONTROL6= - |DEPENDS= - |REQUIRES= - |TIMER= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/bluetooth https://github.com/ethersex/ethersex/tree/master/hardware/radio/bluetooth] }} BT0417C is a generic Bluetooth module loaded with SPP firmware for UART wireless cable replacement functions. It allows your target device to both send or receive the TTL data via Bluetooth technology without connecting a serial cable to your computer. Features: * TTL data transparent transfer between a host Bluetooth device * Compatible with all Bluetooth adapters that support SPP * Default baud rate: 9600,8,1,N * Pair code: 1234 * Built in antenna * Bluetooth Technology v2.0 compatible * Power input:3.3VDC * Compact Size == Connection == When used with 5V microcontrollers, the TXD output logic swing of the module still falls within the valid 5V TTL range, hence, can be connected directly to the UART RXD of the 5V microcontroller host. The RXD and inputs, however, are not 5V tolerant, and can be damaged by 5V level logic going in. Some level translation circuit must be added to protect the inputs. A simple diode level translator circuit like the ones shown in Figure 3 and 7 will suffice in most applications. A better alternative is with the use of 5V input tolerant tiny logic chips such as 74LVC1G125 – a single buffer chip housed in SMD SOT23-5 package. <gallery> File:bt0417c.jpg|BT0417C and breakout board File:bt0417c_5v.jpg|BT0417C to MCU (5V) File:bt0417c_3_3v.jpg|BT0417C to MCU (3,3V) </gallery> Attention: there are different version of the module and breakout board around with different firmware and pin assignment. == Configuration == == [[ECMD]] == == Links == [http://www.multiwii.com/forum/viewtopic.php?f=6&t=133 Serial Bluetooth RF Transceiver Module RS232]<br> [http://byron76.blogspot.de/ Firmware programmer] a2891045577d817ddf3ebfdda3afe85b72dec1c3 1175 1169 2013-10-17T08:52:52Z GooPie4o 265 /* Connection */ wikitext text/x-wiki {{i18n|Bluetooth}} {{Module |NAME=Bluetooth |MENUCONFIG={{I/O}}->Radio->Bluetooth |STATUS={{In_Development}} |PINNING= - |ECMD= - |CONTROL6= - |DEPENDS= - |REQUIRES= - |TIMER= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/bluetooth https://github.com/ethersex/ethersex/tree/master/hardware/radio/bluetooth] }} BT0417C is a generic Bluetooth module loaded with SPP firmware for UART wireless cable replacement functions. It allows your target device to both send or receive the TTL data via Bluetooth technology without connecting a serial cable to your computer. Features: * TTL data transparent transfer between a host Bluetooth device * Compatible with all Bluetooth adapters that support SPP * Default baud rate: 9600,8,1,N * Pair code: 1234 * Built in antenna * Bluetooth Technology v2.0 compatible * Power input:3.3VDC * Compact Size == Connection == When used with 5V microcontrollers, the TXD output logic swing of the module still falls within the valid 5V TTL range, hence, can be connected directly to the UART RXD of the 5V microcontroller host. The RXD and inputs, however, are not 5V tolerant, and can be damaged by 5V level logic going in. Some level translation circuit must be added to protect the inputs. A simple diode level translator circuit like the ones shown in Figure 2 will suffice in most applications. A better alternative is with the use of 5V input tolerant tiny logic chips such as 74LVC1G125 – a single buffer chip housed in SMD SOT23-5 package. <gallery> File:bt0417c.jpg|BT0417C and breakout board File:bt0417c_5v.jpg|BT0417C to MCU (5V) File:bt0417c_3_3v.jpg|BT0417C to MCU (3,3V) </gallery> Attention: there are different version of the module and breakout board around with different firmware and pin assignment. == Configuration == == [[ECMD]] == == Links == [http://www.multiwii.com/forum/viewtopic.php?f=6&t=133 Serial Bluetooth RF Transceiver Module RS232]<br> [http://byron76.blogspot.de/ Firmware programmer] 0a30ce340c62312d899c7172459a432a63ff8458 0 319 1156 830 2013-07-19T07:20:00Z GooPie4o 265 /* Hardware Drivers */ wikitext text/x-wiki {{i18n|Features}} == Supported Network Hardware == * Ethernet [[ENC28J60 | Microchip's ENC28J60]] with IEEE 802.1q VLAN tagging * [[USB]] * [[RFM12]] * [[ZBUS]] == Network Protocols == * IPv4, IPv4 * TCP/IP, UDP/IP and ICMP * DNS * mDNS (Avahi) * [[BOOTP]] * [[DHCP]] * TFTP (can be used in combination with the [[Ethernet Loader]]) * SYSLOG * [[SNMP]] * SMTP * [[NTP]] (Client and Server) * DynDNS * MySQL (Client) * IRC (Client) * [[XMPP | XMPP / Jabber Client]] * MPD (Music Player Daemon) * [[SOAP]]/XMLRPC * [[UPnP]] * [[Artnet]] == Hardware Drivers == * [[Onewire]] * [[I2C]] Master / Slave * [[ADC input]] * [[PWM Generator]] * [[RFM12 FS20]] * [[RFM12 ASK]] * [[Bluetooth|Bluetooth SPP]] * [[USB]] * [[PS/2 Keyboard]] * [[Button Input]] * [[HC595]] * [[HC165]] * [[IRMP | IR Receivers]] * [[SRAM]] == Software Modules == * [[Ethersex Lighting Architecture]] ** [[Starburst]] ** [[StellaLight]] ** [[DMX Storage]] ** [[DMX FXSlot]] * [[Cron Daemon]] * [[System Clock | Clock ]] * [[VNC Server]] * [[lome6]] * [[Frequency Counter]] a0de53a09e885328750f8c205cf7d18e4ce540f5 1171 1156 2013-07-25T15:36:18Z Mgue 312 cron link wikitext text/x-wiki {{i18n|Features}} == Supported Network Hardware == * Ethernet [[ENC28J60 | Microchip's ENC28J60]] with IEEE 802.1q VLAN tagging * [[USB]] * [[RFM12]] * [[ZBUS]] == Network Protocols == * IPv4, IPv4 * TCP/IP, UDP/IP and ICMP * DNS * mDNS (Avahi) * [[BOOTP]] * [[DHCP]] * TFTP (can be used in combination with the [[Ethernet Loader]]) * SYSLOG * [[SNMP]] * SMTP * [[NTP]] (Client and Server) * DynDNS * MySQL (Client) * IRC (Client) * [[XMPP | XMPP / Jabber Client]] * MPD (Music Player Daemon) * [[SOAP]]/XMLRPC * [[UPnP]] * [[Artnet]] == Hardware Drivers == * [[Onewire]] * [[I2C]] Master / Slave * [[ADC input]] * [[PWM Generator]] * [[RFM12 FS20]] * [[RFM12 ASK]] * [[Bluetooth|Bluetooth SPP]] * [[USB]] * [[PS/2 Keyboard]] * [[Button Input]] * [[HC595]] * [[HC165]] * [[IRMP | IR Receivers]] * [[SRAM]] == Software Modules == * [[Ethersex Lighting Architecture]] ** [[Starburst]] ** [[StellaLight]] ** [[DMX Storage]] ** [[DMX FXSlot]] * [[Cron Daemon | Cron ]] * [[System Clock | Clock ]] * [[VNC Server]] * [[lome6]] * [[Frequency Counter]] a9cea537e023c444ddad1cd97d338b06fe7418ff 1172 1171 2013-07-25T15:36:52Z Mgue 312 cron link wikitext text/x-wiki {{i18n|Features}} == Supported Network Hardware == * Ethernet [[ENC28J60 | Microchip's ENC28J60]] with IEEE 802.1q VLAN tagging * [[USB]] * [[RFM12]] * [[ZBUS]] == Network Protocols == * IPv4, IPv4 * TCP/IP, UDP/IP and ICMP * DNS * mDNS (Avahi) * [[BOOTP]] * [[DHCP]] * TFTP (can be used in combination with the [[Ethernet Loader]]) * SYSLOG * [[SNMP]] * SMTP * [[NTP]] (Client and Server) * DynDNS * MySQL (Client) * IRC (Client) * [[XMPP | XMPP / Jabber Client]] * MPD (Music Player Daemon) * [[SOAP]]/XMLRPC * [[UPnP]] * [[Artnet]] == Hardware Drivers == * [[Onewire]] * [[I2C]] Master / Slave * [[ADC input]] * [[PWM Generator]] * [[RFM12 FS20]] * [[RFM12 ASK]] * [[Bluetooth|Bluetooth SPP]] * [[USB]] * [[PS/2 Keyboard]] * [[Button Input]] * [[HC595]] * [[HC165]] * [[IRMP | IR Receivers]] * [[SRAM]] == Software Modules == * [[Ethersex Lighting Architecture]] ** [[Starburst]] ** [[StellaLight]] ** [[DMX Storage]] ** [[DMX FXSlot]] * [[Cron | Cron Daemon]] * [[System Clock | Clock ]] * [[VNC Server]] * [[lome6]] * [[Frequency Counter]] 2918c333e8cbff6cca52325061e2e8fa706c4a17 1200 1172 2014-03-30T15:22:43Z GooPie4o 265 /* Hardware Drivers */ wikitext text/x-wiki {{i18n|Features}} == Supported Network Hardware == * Ethernet [[ENC28J60 | Microchip's ENC28J60]] with IEEE 802.1q VLAN tagging * [[USB]] * [[RFM12]] * [[ZBUS]] == Network Protocols == * IPv4, IPv4 * TCP/IP, UDP/IP and ICMP * DNS * mDNS (Avahi) * [[BOOTP]] * [[DHCP]] * TFTP (can be used in combination with the [[Ethernet Loader]]) * SYSLOG * [[SNMP]] * SMTP * [[NTP]] (Client and Server) * DynDNS * MySQL (Client) * IRC (Client) * [[XMPP | XMPP / Jabber Client]] * MPD (Music Player Daemon) * [[SOAP]]/XMLRPC * [[UPnP]] * [[Artnet]] == Hardware Drivers == * [[Onewire]] * [[I2C]] Master / Slave * [[ADC input]] * [[PWM Generator]] * [[RFM12 FS20]] * [[RFM12 ASK]] * [[Generic ASK Modules]] * [[Bluetooth|Bluetooth SPP]] * [[USB]] * [[PS/2 Keyboard]] * [[Button Input]] * [[HC595]] * [[HC165]] * [[IRMP | IR Receivers]] * [[SRAM]] == Software Modules == * [[Ethersex Lighting Architecture]] ** [[Starburst]] ** [[StellaLight]] ** [[DMX Storage]] ** [[DMX FXSlot]] * [[Cron | Cron Daemon]] * [[System Clock | Clock ]] * [[VNC Server]] * [[lome6]] * [[Frequency Counter]] c98b023380e28aa6983e2f2b0f372d0bf6e0bbae 0 359 1159 1093 2013-07-19T12:57:32Z GooPie4o 265 /* Anschluss */ wikitext text/x-wiki {{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->Storage->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS= |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader] }} Das Modul basiert auf Roland Riegels [http://www.roland-riegel.de/sd-reader/ MMC/SD/SDHC card library] ergänzt um die Anbindung an das Ethersex [[VFS|Virtual File System]]. == Anschluss == [[File:Sdcard adapter schaltung.png|200px|thumb|right|SD-Card Adapter Schaltung]] [[File:Sdcard adapter.jpg|200px|thumb|right|SD-Card Adapter Aufbau]] MMC- und SD-Speicherkarten lassen sich im [[SPI]]-Modus relativ einfach mit einem Mikrocontroller ansteuern. Prinzipiell gibt es zwischen SD-Card und MMC nicht viele Unterschiede, allerdings sind SD-Karten weiter verbreitet, in der Regel schneller als MMCs, und haben ein besser implementiertes SPI-Interface. Es existieren diverse Varianten (miniSD, microSD), die zur normalen SD-Card weitgehend kompatibel sind. Die Karte liest das anliegende Datenbit mit der steigenden Taktflanke ein, als [[SPI]]-Modi eignen sich somit Mode 0 und Mode 3. Bei MMCs ist der SPI-Modus nicht genau spezifiziert, somit kommt es durchaus mal vor, dass der [[SPI]]-Modus je nach Karte unterschiedlich gewählt werden muss. SD-Karten werden typischerweise mit 3,3V und Microcontroller oft mit 5V betrieben. Das erzwingt eine [http://www.mikrocontroller.net/articles/Pegelwandler#5V_.3C-.3E_3.3V Pegelanpassung], weil die Eingangsleitungen zur SD-Karte nicht 5V tolerant sind. Von einer [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#Bekannte_Fehler Pegelanpassung mit Widerständen] wird abgeraten. Neben den Leitungen, die zur SD-Karte führen, gibt es noch zwei weitere Leitungen, die auf den SD-Karten-Sockel führen: nämlich die card-detect Leitung und die write-protect Leitung. Sie dienen dazu, wie die Namen schon sagen, das physische Vorhandensein einer Karte im SD-Sockel und die Stellung des Schreibschutzschiebers zu signalisieren. Wird Hardware-SPI verwendet, muss nur die chip select Leitung konfiguriert werden. Die card-detect Leitung und die write-protect Leitung sind optional. ifdef(`conf_SD_READER', ` /* port the sd-reader CS is attached to */ pin(SPI_CS_SD_READER, PB2, OUTPUT) /* uncomment and edit this if you have connected the CD (card detect) signal */ pin(SD_READER_AVAILABLE, PD4, INPUT) /* uncomment and edit this if you have connected the WP (write protected) signal */ pin(SD_READER_WR_PROTECT, PD5, INPUT) ') Ein weiteres Problem bei den SD Karten ist die Initialisierung. Schafft es Ethersex nicht in einer bestimmten Zeit zu syncen, so fällt die Karte in den normalen (nicht den SD) Betriebsmodus und kann nicht mehr angesprochen werden. Eine Lösung dafür ist, dass die Karte eine steuerbare Stromversorgung erhält. Dazu definiert man im Pinning nur den Pin pin(SD_READER_POWERON, PB3, OUTPUT) ==== Sockel ==== Eine günstige Art der Kontaktierung ist wohl das Ausschlachten eines billigen Cardreaders, wenn man keine Kabel direkt an die Karte löten möchte. Einzeln gekaufte Steckverbinder sind meist erheblich teuerer.Man kann auch alte [http://uanr.com/sdfloppy/ Floppy-Kabel als günstigen Steckverbinder] benutzen. Teile von AT-Slots oder Verbinder von 5,25-Zoll-Floppys gehen auch. Notfalls kann man die Karte zwischen 2 Reihen Stiftleiste einklemmen (oder anlöten). Noch günstiger geht es wenn man Mikro- oder Mini-SD-Karten benutzt und den meist beigelegten Adapter anlötet. Wer jedoch auf einen Selbstbau verzichten will, kann alternativ für relativ schmales Geld einen [http://www.shop.display3000.com/wichtiges-zubehoer/experimentierplatinen/sd-speicherkartenplatine.html fertig aufgebauten SD-Adapter] zum Anschließen an den AVR käulich erwerben. Bei diesem Adapter ist bereits eine bidirektionale Pegelanpassung zwischen den 5V-Pegeln der Steuerleitungen des AVR und den 3,3V-Pegel der SD-Karte an Bord. == Konfiguration == | | I/O ---> | | ... │ │ Storage ---> │ │ ... | | [*] SD/MMC-Card Reader ---> | | ... | | [ ] SDHC support | | | | [*] VFAT LFN support | | | | [ ] Read-only mode | | | | [*] Use read-timeout | | | | [*] Ping-read SD card every 10s | | | | --- ECMD Support | | | | [*] info | | | | [*] dir | | | | [*] mkdir | | | | [*] rm | | | | --- Debugging Flags | | | | [*] FAT | | | | [*] RAW | | | | [*] VFS | | | | General Setup ---> | | ... | | [*] VFS (Virtual File System) support ---> | | ... | | [*] SD/MMC-Card Filesystem | | == [[ECMD_(Deutsch)|ECMD]] == Das SD-CARD Modul implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle. Siehe [[ECMD_Reference|ECMD Referenz]]. == [[Control6_(Deutsch)|Control6]] == Das folgende Beispiel schreibt Datum, Uhrzeit und Temperatur per VFS_LOG_ALLOCA (VFS_LOG erfordert UIP) in die Datei "temp.log" sobald sich die Temperatur um mehr als ein Grad zur letzten Messung verändert hat. Für Datum und Uhrzeit muss CLOCK_SUPPORT aktiviert sein. <pre> #include <stdlib.h> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO uint8_t sign = Temperatur<0; div_t res = div(abs(Temperatur),10); VFS_LOG_ALLOCA("temp.log", 50, "%2d.%2d.%4d %2d:%02d %S%d.%d", CLOCK_DAY, CLOCK_MONTH, CLOCK_YEAR, CLOCK_HOUR, CLOCK_MIN, sign?PSTR("-"):PSTR(""),res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> ba107c7f647abd6923f05d36b986431f56396656 1182 1159 2013-11-14T07:02:25Z GooPie4o 265 URL korrigiert wikitext text/x-wiki {{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->Storage->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS= |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader] }} Das Modul basiert auf Roland Riegels [http://www.roland-riegel.de/sd-reader/ MMC/SD/SDHC card library] ergänzt um die Anbindung an das Ethersex [[VFS|Virtual File System]]. == Anschluss == [[File:Sdcard adapter schaltung.png|200px|thumb|right|SD-Card Adapter Schaltung]] [[File:Sdcard adapter.jpg|200px|thumb|right|SD-Card Adapter Aufbau]] MMC- und SD-Speicherkarten lassen sich im [[SPI]]-Modus relativ einfach mit einem Mikrocontroller ansteuern. Prinzipiell gibt es zwischen SD-Card und MMC nicht viele Unterschiede, allerdings sind SD-Karten weiter verbreitet, in der Regel schneller als MMCs, und haben ein besser implementiertes SPI-Interface. Es existieren diverse Varianten (miniSD, microSD), die zur normalen SD-Card weitgehend kompatibel sind. Die Karte liest das anliegende Datenbit mit der steigenden Taktflanke ein, als [[SPI]]-Modi eignen sich somit Mode 0 und Mode 3. Bei MMCs ist der SPI-Modus nicht genau spezifiziert, somit kommt es durchaus mal vor, dass der [[SPI]]-Modus je nach Karte unterschiedlich gewählt werden muss. SD-Karten werden typischerweise mit 3,3V und Microcontroller oft mit 5V betrieben. Das erzwingt eine [http://www.mikrocontroller.net/articles/Pegelwandler#5V_.3C-.3E_3.3V Pegelanpassung], weil die Eingangsleitungen zur SD-Karte nicht 5V tolerant sind. Von einer [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#Bekannte_Fehler Pegelanpassung mit Widerständen] wird abgeraten. Neben den Leitungen, die zur SD-Karte führen, gibt es noch zwei weitere Leitungen, die auf den SD-Karten-Sockel führen: nämlich die card-detect Leitung und die write-protect Leitung. Sie dienen dazu, wie die Namen schon sagen, das physische Vorhandensein einer Karte im SD-Sockel und die Stellung des Schreibschutzschiebers zu signalisieren. Wird Hardware-SPI verwendet, muss nur die chip select Leitung konfiguriert werden. Die card-detect Leitung und die write-protect Leitung sind optional. ifdef(`conf_SD_READER', ` /* port the sd-reader CS is attached to */ pin(SPI_CS_SD_READER, PB2, OUTPUT) /* uncomment and edit this if you have connected the CD (card detect) signal */ pin(SD_READER_AVAILABLE, PD4, INPUT) /* uncomment and edit this if you have connected the WP (write protected) signal */ pin(SD_READER_WR_PROTECT, PD5, INPUT) ') Ein weiteres Problem bei den SD Karten ist die Initialisierung. Schafft es Ethersex nicht in einer bestimmten Zeit zu syncen, so fällt die Karte in den normalen (nicht den SD) Betriebsmodus und kann nicht mehr angesprochen werden. Eine Lösung dafür ist, dass die Karte eine steuerbare Stromversorgung erhält. Dazu definiert man im Pinning nur den Pin pin(SD_READER_POWERON, PB3, OUTPUT) ==== Sockel ==== Eine günstige Art der Kontaktierung ist wohl das Ausschlachten eines billigen Cardreaders, wenn man keine Kabel direkt an die Karte löten möchte. Einzeln gekaufte Steckverbinder sind meist erheblich teuerer.Man kann auch alte [http://uanr.com/sdfloppy/ Floppy-Kabel als günstigen Steckverbinder] benutzen. Teile von AT-Slots oder Verbinder von 5,25-Zoll-Floppys gehen auch. Notfalls kann man die Karte zwischen 2 Reihen Stiftleiste einklemmen (oder anlöten). Noch günstiger geht es wenn man Mikro- oder Mini-SD-Karten benutzt und den meist beigelegten Adapter anlötet. Wer jedoch auf einen Selbstbau verzichten will, kann alternativ für relativ schmales Geld einen [http://www.shop.display3000.com/elektronikmodule/sd-kartenmodul/index.html fertig aufgebauten SD-Adapter] zum Anschließen an den AVR käulich erwerben. Bei diesem Adapter ist bereits eine bidirektionale Pegelanpassung zwischen den 5V-Pegeln der Steuerleitungen des AVR und den 3,3V-Pegel der SD-Karte an Bord. == Konfiguration == | | I/O ---> | | ... │ │ Storage ---> │ │ ... | | [*] SD/MMC-Card Reader ---> | | ... | | [ ] SDHC support | | | | [*] VFAT LFN support | | | | [ ] Read-only mode | | | | [*] Use read-timeout | | | | [*] Ping-read SD card every 10s | | | | --- ECMD Support | | | | [*] info | | | | [*] dir | | | | [*] mkdir | | | | [*] rm | | | | --- Debugging Flags | | | | [*] FAT | | | | [*] RAW | | | | [*] VFS | | | | General Setup ---> | | ... | | [*] VFS (Virtual File System) support ---> | | ... | | [*] SD/MMC-Card Filesystem | | == [[ECMD_(Deutsch)|ECMD]] == Das SD-CARD Modul implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle. Siehe [[ECMD_Reference|ECMD Referenz]]. == [[Control6_(Deutsch)|Control6]] == Das folgende Beispiel schreibt Datum, Uhrzeit und Temperatur per VFS_LOG_ALLOCA (VFS_LOG erfordert UIP) in die Datei "temp.log" sobald sich die Temperatur um mehr als ein Grad zur letzten Messung verändert hat. Für Datum und Uhrzeit muss CLOCK_SUPPORT aktiviert sein. <pre> #include <stdlib.h> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO uint8_t sign = Temperatur<0; div_t res = div(abs(Temperatur),10); VFS_LOG_ALLOCA("temp.log", 50, "%2d.%2d.%4d %2d:%02d %S%d.%d", CLOCK_DAY, CLOCK_MONTH, CLOCK_YEAR, CLOCK_HOUR, CLOCK_MIN, sign?PSTR("-"):PSTR(""),res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> c0d518c7b248aebbc11b9f18d08cb425cc3739a8 1183 1182 2013-11-14T07:03:11Z GooPie4o 265 /* Konfiguration */ wikitext text/x-wiki {{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->Storage->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS= |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader] }} Das Modul basiert auf Roland Riegels [http://www.roland-riegel.de/sd-reader/ MMC/SD/SDHC card library] ergänzt um die Anbindung an das Ethersex [[VFS|Virtual File System]]. == Anschluss == [[File:Sdcard adapter schaltung.png|200px|thumb|right|SD-Card Adapter Schaltung]] [[File:Sdcard adapter.jpg|200px|thumb|right|SD-Card Adapter Aufbau]] MMC- und SD-Speicherkarten lassen sich im [[SPI]]-Modus relativ einfach mit einem Mikrocontroller ansteuern. Prinzipiell gibt es zwischen SD-Card und MMC nicht viele Unterschiede, allerdings sind SD-Karten weiter verbreitet, in der Regel schneller als MMCs, und haben ein besser implementiertes SPI-Interface. Es existieren diverse Varianten (miniSD, microSD), die zur normalen SD-Card weitgehend kompatibel sind. Die Karte liest das anliegende Datenbit mit der steigenden Taktflanke ein, als [[SPI]]-Modi eignen sich somit Mode 0 und Mode 3. Bei MMCs ist der SPI-Modus nicht genau spezifiziert, somit kommt es durchaus mal vor, dass der [[SPI]]-Modus je nach Karte unterschiedlich gewählt werden muss. SD-Karten werden typischerweise mit 3,3V und Microcontroller oft mit 5V betrieben. Das erzwingt eine [http://www.mikrocontroller.net/articles/Pegelwandler#5V_.3C-.3E_3.3V Pegelanpassung], weil die Eingangsleitungen zur SD-Karte nicht 5V tolerant sind. Von einer [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#Bekannte_Fehler Pegelanpassung mit Widerständen] wird abgeraten. Neben den Leitungen, die zur SD-Karte führen, gibt es noch zwei weitere Leitungen, die auf den SD-Karten-Sockel führen: nämlich die card-detect Leitung und die write-protect Leitung. Sie dienen dazu, wie die Namen schon sagen, das physische Vorhandensein einer Karte im SD-Sockel und die Stellung des Schreibschutzschiebers zu signalisieren. Wird Hardware-SPI verwendet, muss nur die chip select Leitung konfiguriert werden. Die card-detect Leitung und die write-protect Leitung sind optional. ifdef(`conf_SD_READER', ` /* port the sd-reader CS is attached to */ pin(SPI_CS_SD_READER, PB2, OUTPUT) /* uncomment and edit this if you have connected the CD (card detect) signal */ pin(SD_READER_AVAILABLE, PD4, INPUT) /* uncomment and edit this if you have connected the WP (write protected) signal */ pin(SD_READER_WR_PROTECT, PD5, INPUT) ') Ein weiteres Problem bei den SD Karten ist die Initialisierung. Schafft es Ethersex nicht in einer bestimmten Zeit zu syncen, so fällt die Karte in den normalen (nicht den SD) Betriebsmodus und kann nicht mehr angesprochen werden. Eine Lösung dafür ist, dass die Karte eine steuerbare Stromversorgung erhält. Dazu definiert man im Pinning nur den Pin pin(SD_READER_POWERON, PB3, OUTPUT) ==== Sockel ==== Eine günstige Art der Kontaktierung ist wohl das Ausschlachten eines billigen Cardreaders, wenn man keine Kabel direkt an die Karte löten möchte. Einzeln gekaufte Steckverbinder sind meist erheblich teuerer.Man kann auch alte [http://uanr.com/sdfloppy/ Floppy-Kabel als günstigen Steckverbinder] benutzen. Teile von AT-Slots oder Verbinder von 5,25-Zoll-Floppys gehen auch. Notfalls kann man die Karte zwischen 2 Reihen Stiftleiste einklemmen (oder anlöten). Noch günstiger geht es wenn man Mikro- oder Mini-SD-Karten benutzt und den meist beigelegten Adapter anlötet. Wer jedoch auf einen Selbstbau verzichten will, kann alternativ für relativ schmales Geld einen [http://www.shop.display3000.com/elektronikmodule/sd-kartenmodul/index.html fertig aufgebauten SD-Adapter] zum Anschließen an den AVR käulich erwerben. Bei diesem Adapter ist bereits eine bidirektionale Pegelanpassung zwischen den 5V-Pegeln der Steuerleitungen des AVR und den 3,3V-Pegel der SD-Karte an Bord. == Konfiguration == | | I/O ---> | | ... │ │ Storage ---> │ │ ... | | [*] SD/MMC-Card Reader ---> | | ... | | [ ] SDHC support | | | | [*] VFAT LFN support | | | | [ ] Read-only mode | | | | [*] Use read-timeout | | | | [*] Ping-read SD card every 10s | | | | --- ECMD Support | | | | [*] info | | | | [*] dir | | | | [*] mkdir | | | | [*] rm | | | | --- Debugging Flags | | | | [ ] FAT | | | | [ ] RAW | | | | [ ] VFS | | | | General Setup ---> | | ... | | [*] VFS (Virtual File System) support ---> | | ... | | [*] SD/MMC-Card Filesystem | | == [[ECMD_(Deutsch)|ECMD]] == Das SD-CARD Modul implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle. Siehe [[ECMD_Reference|ECMD Referenz]]. == [[Control6_(Deutsch)|Control6]] == Das folgende Beispiel schreibt Datum, Uhrzeit und Temperatur per VFS_LOG_ALLOCA (VFS_LOG erfordert UIP) in die Datei "temp.log" sobald sich die Temperatur um mehr als ein Grad zur letzten Messung verändert hat. Für Datum und Uhrzeit muss CLOCK_SUPPORT aktiviert sein. <pre> #include <stdlib.h> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO uint8_t sign = Temperatur<0; div_t res = div(abs(Temperatur),10); VFS_LOG_ALLOCA("temp.log", 50, "%2d.%2d.%4d %2d:%02d %S%d.%d", CLOCK_DAY, CLOCK_MONTH, CLOCK_YEAR, CLOCK_HOUR, CLOCK_MIN, sign?PSTR("-"):PSTR(""),res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> f2fb46b533a7d48280deb9289d6b83ded3a0e328 1184 1183 2013-11-14T07:09:41Z GooPie4o 265 Bezugsquellen wikitext text/x-wiki {{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->Storage->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS= |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader] }} Das Modul basiert auf Roland Riegels [http://www.roland-riegel.de/sd-reader/ MMC/SD/SDHC card library] ergänzt um die Anbindung an das Ethersex [[VFS|Virtual File System]]. == Anschluss == [[File:Sdcard adapter schaltung.png|200px|thumb|right|SD-Card Adapter Schaltung]] [[File:Sdcard adapter.jpg|200px|thumb|right|SD-Card Adapter Aufbau]] MMC- und SD-Speicherkarten lassen sich im [[SPI]]-Modus relativ einfach mit einem Mikrocontroller ansteuern. Prinzipiell gibt es zwischen SD-Card und MMC nicht viele Unterschiede, allerdings sind SD-Karten weiter verbreitet, in der Regel schneller als MMCs, und haben ein besser implementiertes SPI-Interface. Es existieren diverse Varianten (miniSD, microSD), die zur normalen SD-Card weitgehend kompatibel sind. Die Karte liest das anliegende Datenbit mit der steigenden Taktflanke ein, als [[SPI]]-Modi eignen sich somit Mode 0 und Mode 3. Bei MMCs ist der SPI-Modus nicht genau spezifiziert, somit kommt es durchaus mal vor, dass der [[SPI]]-Modus je nach Karte unterschiedlich gewählt werden muss. SD-Karten werden typischerweise mit 3,3V und Microcontroller oft mit 5V betrieben. Das erzwingt eine [http://www.mikrocontroller.net/articles/Pegelwandler#5V_.3C-.3E_3.3V Pegelanpassung], weil die Eingangsleitungen zur SD-Karte nicht 5V tolerant sind. Von einer [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#Bekannte_Fehler Pegelanpassung mit Widerständen] wird abgeraten. Neben den Leitungen, die zur SD-Karte führen, gibt es noch zwei weitere Leitungen, die auf den SD-Karten-Sockel führen: nämlich die card-detect Leitung und die write-protect Leitung. Sie dienen dazu, wie die Namen schon sagen, das physische Vorhandensein einer Karte im SD-Sockel und die Stellung des Schreibschutzschiebers zu signalisieren. Wird Hardware-SPI verwendet, muss nur die chip select Leitung konfiguriert werden. Die card-detect Leitung und die write-protect Leitung sind optional. ifdef(`conf_SD_READER', ` /* port the sd-reader CS is attached to */ pin(SPI_CS_SD_READER, PB2, OUTPUT) /* uncomment and edit this if you have connected the CD (card detect) signal */ pin(SD_READER_AVAILABLE, PD4, INPUT) /* uncomment and edit this if you have connected the WP (write protected) signal */ pin(SD_READER_WR_PROTECT, PD5, INPUT) ') Ein weiteres Problem bei den SD Karten ist die Initialisierung. Schafft es Ethersex nicht in einer bestimmten Zeit zu syncen, so fällt die Karte in den normalen (nicht den SD) Betriebsmodus und kann nicht mehr angesprochen werden. Eine Lösung dafür ist, dass die Karte eine steuerbare Stromversorgung erhält. Dazu definiert man im Pinning nur den Pin pin(SD_READER_POWERON, PB3, OUTPUT) ==== Sockel ==== Eine günstige Art der Kontaktierung ist wohl das Ausschlachten eines billigen Cardreaders, wenn man keine Kabel direkt an die Karte löten möchte. Einzeln gekaufte Steckverbinder sind meist erheblich teuerer.Man kann auch alte [http://uanr.com/sdfloppy/ Floppy-Kabel als günstigen Steckverbinder] benutzen. Teile von AT-Slots oder Verbinder von 5,25-Zoll-Floppys gehen auch. Notfalls kann man die Karte zwischen 2 Reihen Stiftleiste einklemmen (oder anlöten). Noch günstiger geht es wenn man Mikro- oder Mini-SD-Karten benutzt und den meist beigelegten Adapter anlötet. Wer jedoch auf einen Selbstbau verzichten will, kann alternativ für relativ schmales Geld einen [http://www.shop.display3000.com/elektronikmodule/sd-kartenmodul/index.html fertig aufgebauten SD-Adapter] zum Anschließen an den AVR käulich erwerben. Bei diesem Adapter ist bereits eine bidirektionale Pegelanpassung zwischen den 5V-Pegeln der Steuerleitungen des AVR und den 3,3V-Pegel der SD-Karte an Bord. Preiswerter können diese Module über [http://www.ebay.com/sch/i.html?_from=R40&_sacat=0&_nkw=Micro+SD+Card+Module+SPI&rt=nc&LH_PrefLoc=2 ebay] aus China bezogen werden. == Konfiguration == | | I/O ---> | | ... │ │ Storage ---> │ │ ... | | [*] SD/MMC-Card Reader ---> | | ... | | [ ] SDHC support | | | | [*] VFAT LFN support | | | | [ ] Read-only mode | | | | [*] Use read-timeout | | | | [*] Ping-read SD card every 10s | | | | --- ECMD Support | | | | [*] info | | | | [*] dir | | | | [*] mkdir | | | | [*] rm | | | | --- Debugging Flags | | | | [ ] FAT | | | | [ ] RAW | | | | [ ] VFS | | | | General Setup ---> | | ... | | [*] VFS (Virtual File System) support ---> | | ... | | [*] SD/MMC-Card Filesystem | | == [[ECMD_(Deutsch)|ECMD]] == Das SD-CARD Modul implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle. Siehe [[ECMD_Reference|ECMD Referenz]]. == [[Control6_(Deutsch)|Control6]] == Das folgende Beispiel schreibt Datum, Uhrzeit und Temperatur per VFS_LOG_ALLOCA (VFS_LOG erfordert UIP) in die Datei "temp.log" sobald sich die Temperatur um mehr als ein Grad zur letzten Messung verändert hat. Für Datum und Uhrzeit muss CLOCK_SUPPORT aktiviert sein. <pre> #include <stdlib.h> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO uint8_t sign = Temperatur<0; div_t res = div(abs(Temperatur),10); VFS_LOG_ALLOCA("temp.log", 50, "%2d.%2d.%4d %2d:%02d %S%d.%d", CLOCK_DAY, CLOCK_MONTH, CLOCK_YEAR, CLOCK_HOUR, CLOCK_MIN, sign?PSTR("-"):PSTR(""),res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> 8a6818ec4a6ab76d0656a9b08e9fa1ec6c42b6ba 1185 1184 2013-11-14T07:10:36Z GooPie4o 265 /* Sockel */ wikitext text/x-wiki {{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->Storage->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS= |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader] }} Das Modul basiert auf Roland Riegels [http://www.roland-riegel.de/sd-reader/ MMC/SD/SDHC card library] ergänzt um die Anbindung an das Ethersex [[VFS|Virtual File System]]. == Anschluss == [[File:Sdcard adapter schaltung.png|200px|thumb|right|SD-Card Adapter Schaltung]] [[File:Sdcard adapter.jpg|200px|thumb|right|SD-Card Adapter Aufbau]] MMC- und SD-Speicherkarten lassen sich im [[SPI]]-Modus relativ einfach mit einem Mikrocontroller ansteuern. Prinzipiell gibt es zwischen SD-Card und MMC nicht viele Unterschiede, allerdings sind SD-Karten weiter verbreitet, in der Regel schneller als MMCs, und haben ein besser implementiertes SPI-Interface. Es existieren diverse Varianten (miniSD, microSD), die zur normalen SD-Card weitgehend kompatibel sind. Die Karte liest das anliegende Datenbit mit der steigenden Taktflanke ein, als [[SPI]]-Modi eignen sich somit Mode 0 und Mode 3. Bei MMCs ist der SPI-Modus nicht genau spezifiziert, somit kommt es durchaus mal vor, dass der [[SPI]]-Modus je nach Karte unterschiedlich gewählt werden muss. SD-Karten werden typischerweise mit 3,3V und Microcontroller oft mit 5V betrieben. Das erzwingt eine [http://www.mikrocontroller.net/articles/Pegelwandler#5V_.3C-.3E_3.3V Pegelanpassung], weil die Eingangsleitungen zur SD-Karte nicht 5V tolerant sind. Von einer [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#Bekannte_Fehler Pegelanpassung mit Widerständen] wird abgeraten. Neben den Leitungen, die zur SD-Karte führen, gibt es noch zwei weitere Leitungen, die auf den SD-Karten-Sockel führen: nämlich die card-detect Leitung und die write-protect Leitung. Sie dienen dazu, wie die Namen schon sagen, das physische Vorhandensein einer Karte im SD-Sockel und die Stellung des Schreibschutzschiebers zu signalisieren. Wird Hardware-SPI verwendet, muss nur die chip select Leitung konfiguriert werden. Die card-detect Leitung und die write-protect Leitung sind optional. ifdef(`conf_SD_READER', ` /* port the sd-reader CS is attached to */ pin(SPI_CS_SD_READER, PB2, OUTPUT) /* uncomment and edit this if you have connected the CD (card detect) signal */ pin(SD_READER_AVAILABLE, PD4, INPUT) /* uncomment and edit this if you have connected the WP (write protected) signal */ pin(SD_READER_WR_PROTECT, PD5, INPUT) ') Ein weiteres Problem bei den SD Karten ist die Initialisierung. Schafft es Ethersex nicht in einer bestimmten Zeit zu syncen, so fällt die Karte in den normalen (nicht den SD) Betriebsmodus und kann nicht mehr angesprochen werden. Eine Lösung dafür ist, dass die Karte eine steuerbare Stromversorgung erhält. Dazu definiert man im Pinning nur den Pin pin(SD_READER_POWERON, PB3, OUTPUT) ==== Sockel ==== Eine günstige Art der Kontaktierung ist wohl das Ausschlachten eines billigen Cardreaders, wenn man keine Kabel direkt an die Karte löten möchte. Einzeln gekaufte Steckverbinder sind meist erheblich teuerer.Man kann auch alte [http://uanr.com/sdfloppy/ Floppy-Kabel als günstigen Steckverbinder] benutzen. Teile von AT-Slots oder Verbinder von 5,25-Zoll-Floppys gehen auch. Notfalls kann man die Karte zwischen 2 Reihen Stiftleiste einklemmen (oder anlöten). Noch günstiger geht es wenn man Mikro- oder Mini-SD-Karten benutzt und den meist beigelegten Adapter anlötet. Wer jedoch auf einen Selbstbau verzichten will, kann alternativ für relativ schmales Geld einen [http://www.shop.display3000.com/elektronikmodule/sd-kartenmodul/index.html fertig aufgebauten SD-Adapter] zum Anschließen an den AVR käuflich erwerben. Bei diesem Adapter ist bereits eine bidirektionale Pegelanpassung zwischen den 5V-Pegeln der Steuerleitungen des AVR und den 3,3V-Pegel der SD-Karte an Bord. Preiswerter können diese Module über [http://www.ebay.com/sch/i.html?_from=R40&_sacat=0&_nkw=Micro+SD+Card+Module+SPI&rt=nc&LH_PrefLoc=2 ebay] aus China bezogen werden. == Konfiguration == | | I/O ---> | | ... │ │ Storage ---> │ │ ... | | [*] SD/MMC-Card Reader ---> | | ... | | [ ] SDHC support | | | | [*] VFAT LFN support | | | | [ ] Read-only mode | | | | [*] Use read-timeout | | | | [*] Ping-read SD card every 10s | | | | --- ECMD Support | | | | [*] info | | | | [*] dir | | | | [*] mkdir | | | | [*] rm | | | | --- Debugging Flags | | | | [ ] FAT | | | | [ ] RAW | | | | [ ] VFS | | | | General Setup ---> | | ... | | [*] VFS (Virtual File System) support ---> | | ... | | [*] SD/MMC-Card Filesystem | | == [[ECMD_(Deutsch)|ECMD]] == Das SD-CARD Modul implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle. Siehe [[ECMD_Reference|ECMD Referenz]]. == [[Control6_(Deutsch)|Control6]] == Das folgende Beispiel schreibt Datum, Uhrzeit und Temperatur per VFS_LOG_ALLOCA (VFS_LOG erfordert UIP) in die Datei "temp.log" sobald sich die Temperatur um mehr als ein Grad zur letzten Messung verändert hat. Für Datum und Uhrzeit muss CLOCK_SUPPORT aktiviert sein. <pre> #include <stdlib.h> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO uint8_t sign = Temperatur<0; div_t res = div(abs(Temperatur),10); VFS_LOG_ALLOCA("temp.log", 50, "%2d.%2d.%4d %2d:%02d %S%d.%d", CLOCK_DAY, CLOCK_MONTH, CLOCK_YEAR, CLOCK_HOUR, CLOCK_MIN, sign?PSTR("-"):PSTR(""),res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> dbee88d244b15bd88ebafa47b7a4a286c1aa2f19 1194 1185 2013-12-08T16:45:38Z GooPie4o 265 wikitext text/x-wiki {{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->Storage->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS= |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader] }} Das Modul basiert auf Roland Riegels [http://www.roland-riegel.de/sd-reader/ MMC/SD/SDHC card library] ergänzt um die Anbindung an das Ethersex [[VFS|Virtual File System]]. == Anschluss == [[File:Sdcard adapter schaltung.png|200px|thumb|right|SD-Card Adapter Schaltung]] [[File:Sdcard adapter.jpg|200px|thumb|right|SD-Card Adapter Aufbau]] [[File:Microsd_adapter.jpg|200px|thumb|right|MicroSD-Card Adapter aus China]] MMC- und SD-Speicherkarten lassen sich im [[SPI]]-Modus relativ einfach mit einem Mikrocontroller ansteuern. Prinzipiell gibt es zwischen SD-Card und MMC nicht viele Unterschiede, allerdings sind SD-Karten weiter verbreitet, in der Regel schneller als MMCs, und haben ein besser implementiertes SPI-Interface. Es existieren diverse Varianten (miniSD, microSD), die zur normalen SD-Card weitgehend kompatibel sind. Die Karte liest das anliegende Datenbit mit der steigenden Taktflanke ein, als [[SPI]]-Modi eignen sich somit Mode 0 und Mode 3. Bei MMCs ist der SPI-Modus nicht genau spezifiziert, somit kommt es durchaus mal vor, dass der [[SPI]]-Modus je nach Karte unterschiedlich gewählt werden muss. SD-Karten werden typischerweise mit 3,3V und Microcontroller oft mit 5V betrieben. Das erzwingt eine [http://www.mikrocontroller.net/articles/Pegelwandler#5V_.3C-.3E_3.3V Pegelanpassung], weil die Eingangsleitungen zur SD-Karte nicht 5V tolerant sind. Von einer [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#Bekannte_Fehler Pegelanpassung mit Widerständen] wird abgeraten. Neben den Leitungen, die zur SD-Karte führen, gibt es noch zwei weitere Leitungen, die auf den SD-Karten-Sockel führen: nämlich die card-detect Leitung und die write-protect Leitung. Sie dienen dazu, wie die Namen schon sagen, das physische Vorhandensein einer Karte im SD-Sockel und die Stellung des Schreibschutzschiebers zu signalisieren. Wird Hardware-SPI verwendet, muss nur die chip select Leitung konfiguriert werden. Die card-detect Leitung und die write-protect Leitung sind optional. ifdef(`conf_SD_READER', ` /* port the sd-reader CS is attached to */ pin(SPI_CS_SD_READER, PB2, OUTPUT) /* uncomment and edit this if you have connected the CD (card detect) signal */ pin(SD_READER_AVAILABLE, PD4, INPUT) /* uncomment and edit this if you have connected the WP (write protected) signal */ pin(SD_READER_WR_PROTECT, PD5, INPUT) ') Ein weiteres Problem bei den SD Karten ist die Initialisierung. Schafft es Ethersex nicht in einer bestimmten Zeit zu syncen, so fällt die Karte in den normalen (nicht den SD) Betriebsmodus und kann nicht mehr angesprochen werden. Eine Lösung dafür ist, dass die Karte eine steuerbare Stromversorgung erhält. Dazu definiert man im Pinning nur den Pin pin(SD_READER_POWERON, PB3, OUTPUT) ==== Sockel ==== Eine günstige Art der Kontaktierung ist wohl das Ausschlachten eines billigen Cardreaders, wenn man keine Kabel direkt an die Karte löten möchte. Einzeln gekaufte Steckverbinder sind meist erheblich teuerer.Man kann auch alte [http://uanr.com/sdfloppy/ Floppy-Kabel als günstigen Steckverbinder] benutzen. Teile von AT-Slots oder Verbinder von 5,25-Zoll-Floppys gehen auch. Notfalls kann man die Karte zwischen 2 Reihen Stiftleiste einklemmen (oder anlöten). Noch günstiger geht es wenn man Mikro- oder Mini-SD-Karten benutzt und den meist beigelegten Adapter anlötet. Wer jedoch auf einen Selbstbau verzichten will, kann alternativ für relativ schmales Geld einen [http://www.shop.display3000.com/elektronikmodule/sd-kartenmodul/index.html fertig aufgebauten SD-Adapter] zum Anschließen an den AVR käuflich erwerben. Bei diesem Adapter ist bereits eine bidirektionale Pegelanpassung zwischen den 5V-Pegeln der Steuerleitungen des AVR und den 3,3V-Pegel der SD-Karte an Bord. Preiswerter können diese Module über [http://www.ebay.com/sch/i.html?_from=R40&_sacat=0&_nkw=Micro+SD+Card+Module+SPI&rt=nc&LH_PrefLoc=2 ebay] aus China bezogen werden. == Konfiguration == | | I/O ---> | | ... │ │ Storage ---> │ │ ... | | [*] SD/MMC-Card Reader ---> | | ... | | [ ] SDHC support | | | | [*] VFAT LFN support | | | | [ ] Read-only mode | | | | [*] Use read-timeout | | | | [*] Ping-read SD card every 10s | | | | --- ECMD Support | | | | [*] info | | | | [*] dir | | | | [*] mkdir | | | | [*] rm | | | | --- Debugging Flags | | | | [ ] FAT | | | | [ ] RAW | | | | [ ] VFS | | | | General Setup ---> | | ... | | [*] VFS (Virtual File System) support ---> | | ... | | [*] SD/MMC-Card Filesystem | | == [[ECMD_(Deutsch)|ECMD]] == Das SD-CARD Modul implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle. Siehe [[ECMD_Reference|ECMD Referenz]]. == [[Control6_(Deutsch)|Control6]] == Das folgende Beispiel schreibt Datum, Uhrzeit und Temperatur per VFS_LOG_ALLOCA (VFS_LOG erfordert UIP) in die Datei "temp.log" sobald sich die Temperatur um mehr als ein Grad zur letzten Messung verändert hat. Für Datum und Uhrzeit muss CLOCK_SUPPORT aktiviert sein. <pre> #include <stdlib.h> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO uint8_t sign = Temperatur<0; div_t res = div(abs(Temperatur),10); VFS_LOG_ALLOCA("temp.log", 50, "%2d.%2d.%4d %2d:%02d %S%d.%d", CLOCK_DAY, CLOCK_MONTH, CLOCK_YEAR, CLOCK_HOUR, CLOCK_MIN, sign?PSTR("-"):PSTR(""),res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> 477cca4e3befd98e945b43f5f00eac3c681477d7 1195 1194 2013-12-08T17:40:00Z GooPie4o 265 wikitext text/x-wiki {{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->Storage->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS= |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader] }} Das Modul basiert auf Roland Riegels [http://www.roland-riegel.de/sd-reader/ MMC/SD/SDHC card library] ergänzt um die Anbindung an das Ethersex [[VFS|Virtual File System]]. == Anschluss == [[File:Sdcard adapter schaltung.png|200px|thumb|right|SD-Card Adapter Schaltung]] [[File:Sdcard adapter.jpg|200px|thumb|right|SD-Card Adapter Aufbau]] [[File:Microsd_adapter.jpg|200px|thumb|right|MicroSD-Card Adapter mit Level-Shifter aus China]] MMC- und SD-Speicherkarten lassen sich im [[SPI]]-Modus relativ einfach mit einem Mikrocontroller ansteuern. Prinzipiell gibt es zwischen SD-Card und MMC nicht viele Unterschiede, allerdings sind SD-Karten weiter verbreitet, in der Regel schneller als MMCs, und haben ein besser implementiertes SPI-Interface. Es existieren diverse Varianten (miniSD, microSD), die zur normalen SD-Card weitgehend kompatibel sind. Die Karte liest das anliegende Datenbit mit der steigenden Taktflanke ein, als [[SPI]]-Modi eignen sich somit Mode 0 und Mode 3. Bei MMCs ist der SPI-Modus nicht genau spezifiziert, somit kommt es durchaus mal vor, dass der [[SPI]]-Modus je nach Karte unterschiedlich gewählt werden muss. SD-Karten werden typischerweise mit 3,3V und Microcontroller oft mit 5V betrieben. Das erzwingt eine [http://www.mikrocontroller.net/articles/Pegelwandler#5V_.3C-.3E_3.3V Pegelanpassung], weil die Eingangsleitungen zur SD-Karte nicht 5V tolerant sind. Von einer [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#Bekannte_Fehler Pegelanpassung mit Widerständen] wird abgeraten. Neben den Leitungen, die zur SD-Karte führen, gibt es noch zwei weitere Leitungen, die auf den SD-Karten-Sockel führen: nämlich die card-detect Leitung und die write-protect Leitung. Sie dienen dazu, wie die Namen schon sagen, das physische Vorhandensein einer Karte im SD-Sockel und die Stellung des Schreibschutzschiebers zu signalisieren. Wird Hardware-SPI verwendet, muss nur die chip select Leitung konfiguriert werden. Die card-detect Leitung und die write-protect Leitung sind optional und bei MicroSD ohnehin nicht vorhanden. ifdef(`conf_SD_READER', ` /* port the sd-reader CS is attached to */ pin(SPI_CS_SD_READER, PB2, OUTPUT) /* uncomment and edit this if you have connected the CD (card detect) signal */ pin(SD_READER_AVAILABLE, PD4, INPUT) /* uncomment and edit this if you have connected the WP (write protected) signal */ pin(SD_READER_WR_PROTECT, PD5, INPUT) ') Ein weiteres Problem bei den SD Karten ist die Initialisierung. Schafft es Ethersex nicht in einer bestimmten Zeit zu syncen, so fällt die Karte in den normalen (nicht den SD) Betriebsmodus und kann nicht mehr angesprochen werden. Eine Lösung dafür ist, dass die Karte eine steuerbare Stromversorgung erhält. Dazu definiert man im Pinning nur den Pin pin(SD_READER_POWERON, PB3, OUTPUT) ==== Sockel ==== Eine günstige Art der Kontaktierung ist wohl das Ausschlachten eines billigen Cardreaders, wenn man keine Kabel direkt an die Karte löten möchte. Einzeln gekaufte Steckverbinder sind meist erheblich teuerer.Man kann auch alte [http://uanr.com/sdfloppy/ Floppy-Kabel als günstigen Steckverbinder] benutzen. Teile von AT-Slots oder Verbinder von 5,25-Zoll-Floppys gehen auch. Notfalls kann man die Karte zwischen 2 Reihen Stiftleiste einklemmen (oder anlöten). Noch günstiger geht es wenn man Mikro- oder Mini-SD-Karten benutzt und den meist beigelegten Adapter anlötet. Wer jedoch auf einen Selbstbau verzichten will, kann alternativ für relativ schmales Geld einen [http://www.shop.display3000.com/elektronikmodule/sd-kartenmodul/index.html fertig aufgebauten SD-Adapter] zum Anschließen an den AVR käuflich erwerben. Bei diesem Adapter ist bereits eine bidirektionale Pegelanpassung zwischen den 5V-Pegeln der Steuerleitungen des AVR und den 3,3V-Pegel der SD-Karte an Bord. Preiswerter können diese Module über [http://www.ebay.com/sch/i.html?_from=R40&_sacat=0&_nkw=Micro+SD+Card+Module+SPI&rt=nc&LH_PrefLoc=2 ebay] aus China bezogen werden. == Konfiguration == | | I/O ---> | | ... │ │ Storage ---> │ │ ... | | [*] SD/MMC-Card Reader ---> | | ... | | [ ] SDHC support | | | | [*] VFAT LFN support | | | | [ ] Read-only mode | | | | [*] Use read-timeout | | | | [*] Ping-read SD card every 10s | | | | --- ECMD Support | | | | [*] info | | | | [*] dir | | | | [*] mkdir | | | | [*] rm | | | | --- Debugging Flags | | | | [ ] FAT | | | | [ ] RAW | | | | [ ] VFS | | | | General Setup ---> | | ... | | [*] VFS (Virtual File System) support ---> | | ... | | [*] SD/MMC-Card Filesystem | | == [[ECMD_(Deutsch)|ECMD]] == Das SD-CARD Modul implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle. Siehe [[ECMD_Reference|ECMD Referenz]]. == [[Control6_(Deutsch)|Control6]] == Das folgende Beispiel schreibt Datum, Uhrzeit und Temperatur per VFS_LOG_ALLOCA (VFS_LOG erfordert UIP) in die Datei "temp.log" sobald sich die Temperatur um mehr als ein Grad zur letzten Messung verändert hat. Für Datum und Uhrzeit muss CLOCK_SUPPORT aktiviert sein. <pre> #include <stdlib.h> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO uint8_t sign = Temperatur<0; div_t res = div(abs(Temperatur),10); VFS_LOG_ALLOCA("temp.log", 50, "%2d.%2d.%4d %2d:%02d %S%d.%d", CLOCK_DAY, CLOCK_MONTH, CLOCK_YEAR, CLOCK_HOUR, CLOCK_MIN, sign?PSTR("-"):PSTR(""),res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> b368f23a063a6bcf6ede8364967da658aab5857b 1198 1195 2013-12-19T08:48:50Z GooPie4o 265 /* Anschluss */ wikitext text/x-wiki {{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->Storage->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS= |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader] }} Das Modul basiert auf Roland Riegels [http://www.roland-riegel.de/sd-reader/ MMC/SD/SDHC card library] ergänzt um die Anbindung an das Ethersex [[VFS|Virtual File System]]. == Anschluss == [[File:Sdcard adapter schaltung.png|200px|thumb|right|SD-Card Adapter Schaltung]] [[File:Sdcard adapter.jpg|200px|thumb|right|SD-Card Adapter Aufbau]] [[File:Microsd_adapter.jpg|200px|thumb|right|MicroSD-Card Adapter mit Level-Shifter aus China]] MMC- und SD-Speicherkarten lassen sich im [[SPI]]-Modus relativ einfach mit einem Mikrocontroller ansteuern. Prinzipiell gibt es zwischen SD-Card und MMC nicht viele Unterschiede, allerdings sind SD-Karten weiter verbreitet, in der Regel schneller als MMCs, und haben ein besser implementiertes SPI-Interface. Es existieren diverse Varianten (miniSD, microSD), die zur normalen SD-Card weitgehend kompatibel sind. Die Karte liest das anliegende Datenbit mit der steigenden Taktflanke ein, als [[SPI]]-Modi eignen sich somit Mode 0 und Mode 3. Bei MMCs ist der SPI-Modus nicht genau spezifiziert, somit kommt es durchaus mal vor, dass der [[SPI]]-Modus je nach Karte unterschiedlich gewählt werden muss. SD-Karten werden typischerweise mit 3,3V und Microcontroller oft mit 5V betrieben. Das erzwingt eine [http://www.mikrocontroller.net/articles/Pegelwandler#5V_.3C-.3E_3.3V Pegelanpassung], weil die Eingangsleitungen zur SD-Karte nicht 5V tolerant sind. Von einer [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#Bekannte_Fehler Pegelanpassung mit Widerständen] wird abgeraten. Neben den Leitungen, die zur SD-Karte führen, gibt es noch zwei weitere Leitungen, die auf den SD-Karten-Sockel führen: nämlich die card-detect Leitung und die write-protect Leitung. Sie dienen dazu, wie die Namen schon sagen, das physische Vorhandensein einer Karte im SD-Sockel und die Stellung des Schreibschutzschiebers zu signalisieren. Wird Hardware-SPI verwendet, muss nur die chip select Leitung konfiguriert werden. Die card-detect Leitung und die write-protect Leitung sind optional und bei MicroSD ohnehin nicht vorhanden. ifdef(`conf_SD_READER', ` /* port the sd-reader CS is attached to */ pin(SPI_CS_SD_READER, PB2, OUTPUT) /* uncomment and edit this if you have connected the CD (card detect) signal */ pin(SD_READER_AVAILABLE, PD4, INPUT) /* uncomment and edit this if you have connected the WP (write protected) signal */ pin(SD_READER_WR_PROTECT, PD5, INPUT) ') Ein weiteres Problem bei den SD Karten ist die Initialisierung. Schafft es Ethersex nicht in einer bestimmten Zeit zu syncen, so fällt die Karte in den normalen (nicht den SD) Betriebsmodus und kann nicht mehr angesprochen werden. Eine Lösung dafür ist, dass die Karte eine steuerbare Stromversorgung erhält. Dazu definiert man im Pinning nur den Pin pin(SD_READER_POWERON, PB3, OUTPUT) ==== Sockel ==== Eine günstige Art der Kontaktierung ist wohl das Ausschlachten eines billigen Cardreaders, wenn man keine Kabel direkt an die Karte löten möchte. Einzeln gekaufte Steckverbinder sind meist erheblich teuerer. Man kann auch alte [http://uanr.com/sdfloppy/ Floppy-Kabel als günstigen Steckverbinder] benutzen. Teile von AT-Slots oder Verbinder von 5,25-Zoll-Floppys gehen auch. Notfalls kann man die Karte zwischen 2 Reihen Stiftleiste einklemmen (oder anlöten). Noch günstiger geht es wenn man Mikro- oder Mini-SD-Karten benutzt und den meist beigelegten Adapter anlötet. Wer jedoch auf einen Selbstbau verzichten will, kann alternativ für relativ schmales Geld einen [http://www.shop.display3000.com/elektronikmodule/sd-kartenmodul/index.html fertig aufgebauten SD-Adapter] zum Anschließen an den AVR käuflich erwerben. Bei diesem Adapter ist bereits eine bidirektionale Pegelanpassung zwischen den 5V-Pegeln der Steuerleitungen des AVR und den 3,3V-Pegel der SD-Karte an Bord. Preiswerter können diese Module über [http://www.ebay.com/sch/i.html?_from=R40&_sacat=0&_nkw=Micro+SD+Card+Module+SPI&rt=nc&LH_PrefLoc=2 ebay] aus China bezogen werden. == Konfiguration == | | I/O ---> | | ... │ │ Storage ---> │ │ ... | | [*] SD/MMC-Card Reader ---> | | ... | | [ ] SDHC support | | | | [*] VFAT LFN support | | | | [ ] Read-only mode | | | | [*] Use read-timeout | | | | [*] Ping-read SD card every 10s | | | | --- ECMD Support | | | | [*] info | | | | [*] dir | | | | [*] mkdir | | | | [*] rm | | | | --- Debugging Flags | | | | [ ] FAT | | | | [ ] RAW | | | | [ ] VFS | | | | General Setup ---> | | ... | | [*] VFS (Virtual File System) support ---> | | ... | | [*] SD/MMC-Card Filesystem | | == [[ECMD_(Deutsch)|ECMD]] == Das SD-CARD Modul implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle. Siehe [[ECMD_Reference|ECMD Referenz]]. == [[Control6_(Deutsch)|Control6]] == Das folgende Beispiel schreibt Datum, Uhrzeit und Temperatur per VFS_LOG_ALLOCA (VFS_LOG erfordert UIP) in die Datei "temp.log" sobald sich die Temperatur um mehr als ein Grad zur letzten Messung verändert hat. Für Datum und Uhrzeit muss CLOCK_SUPPORT aktiviert sein. <pre> #include <stdlib.h> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO uint8_t sign = Temperatur<0; div_t res = div(abs(Temperatur),10); VFS_LOG_ALLOCA("temp.log", 50, "%2d.%2d.%4d %2d:%02d %S%d.%d", CLOCK_DAY, CLOCK_MONTH, CLOCK_YEAR, CLOCK_HOUR, CLOCK_MIN, sign?PSTR("-"):PSTR(""),res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> c2297f13d3d9b72fdf3f33d76b94c7a712e018b6 0 278 1160 1128 2013-07-19T14:14:09Z GooPie4o 265 /* AVRDUDE Configuration */ wikitext text/x-wiki {{i18n|Quick Start Guide/Flashing}} = Flashing = After compiling the ''ethersex.hex'' you can flash it with avrdude. You can either use avrdude on the command line or call the target ''program'' from the [[Ethersex]] Makefile. == Prerequisites == * the previously selected board, e.g. AVR NET-IO, ready built and (hopefully) tested * an ISP-Programmer of your choice supported by [http://www.nongnu.org/avrdude avrdude] * an ISP connector cable that fits to your programmer and your board (either 6 or 10-pin) * an ethersex.hex compiled in the [[Quick_Start_Guide/Configuration | previous step]] If you have an ISP-Programmer with a 6-pin port and a board with a 10-pin header - like the AVR NET-IO - you can create an adapter. You can see the pin configuration in figure 4-1 at page 5 [http://www.atmel.com/dyn/resources/prod_documents/doc2521.pdf AVR042: AVR Hardware Design Considerations]. Note that Pin 4 of the 10-pin connector is not used on the AVR NET-IO. GND has to be connected to one of the other Pins (6, 8 or 10). == Flashing the image with avrdude == The following commands are just examples, the actual command line depends on your ISP-Programmer and hardware. This example is for a serial connection (e.g. the ATMEL Evaluation-Board): avrdude -v -p m32 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex This example for a real USB ISP-Programmer: avrdude -p m1284p -c avrispmkII -P usb -U flash:w:ethersex.hex For a serial programmer connected via an USB-serial-adapter this may be used: avrdude -v -p m32 -c stk500v2 -P /dev/ttyACM0 -U flash:w:ethersex.hex And this one for a parallel ISP-Cable: avrdude -p m32 -e -c stk200 -U flash:w:ethersex.hex After flashing remove the ISP-Cable and interrupt the power connection for a short time to reboot the board. * -p m32: ATMega32; -p m644: ATMega644; -p ? to list the valid parts * -v: display debug messages * -c ponyser: traditional serial programmer; -c stkk500v2 for the Atmel board * -P /dev/tty.serial the serial port your programmer is connected to; -P COM1 for windows machines; -P usb for USB * -U the command you want to execute. In our case we want to flash: -U flash:w:ethersex.hex == Using avrdude from the makefile == Since [https://github.com/ethersex/ethersex/commit/16c2a388ec775b51c049db1eeff3a8171c6ad71b 16c2a388ec] the [[Ethersex]] makefile supports two new targets, ''program'' and ''fuses'', to invoke avrdude. The target ''program'' calls avrdude with the options to flash the previously compiled ''ethersex.hex'' to the MCU. The ''fuses'' target may be used to program the MCUs fuse registers. AVRDUDE options and MCU fuse register settings may be configured via a menuconfig dialog. All settings will be saved to the current profile ''.config''. Available settings and choices on the AVRDUDE configuration page depend on the MCU and clock frequency configured on the General Setup dialog. Please go back to the [[Quick_Start_Guide/Configuration | previous step]] if you haven't done that yet. === AVRDUDE Configuration === If - and only if - the avrdude executable could be found in your ''PATH'', menuconfig's mainmenu will show an option to enter AVRDUDE configuration. [[File:avrdude_mainmenu.png|right|sub|thumb|200px|menuconfig's mainmenu with AVRDUDE Configuration selected]] The AVRDUDE configuration page allows to setup the most common options for avrdude: [[File:avrdude_menu.png|right|sub|thumb|200px|AVRDUDE configuration page]] ;Programmer Type :avrdude option '-c'. :Use the programmer configuration choosen from the list. : :Refer to the official avrdude documentation if you're in doubt about the correct choice for your programmer ([http://www.nongnu.org/avrdude/ avrdude home]). : :NB: The list of choices is generated by calling 'avrdude -c ?' and contains all the programmers your avrdude executable supports. ;Port :avrdude option '-P'. :Specify the port the programmer is connected to. Serial devices like ponyprog use for example ''/dev/ttyS0'' (= COM1 under Windows!), most modern programmers use ''usb''. : : Note that most old-style serial programmers will not work properly when connected to an USB-serial-Adapter! ; Extra verbose output :avrdude option '-v -v'. :Be more verbose. Default is '-v'. Use this, if you experience problems while flashing or simply want to see in detail whats going on... ;Do NOT verify after programming :avrdude option '-V'. :Do NOT verify flash memory after programming. Use with care and only if you're really sure that your setup is perfect. Speeds things up a bit but it's use is generally discouraged. ;Count # of erase cycles in EEPROM :avrdude option '-y'. :Tell avrdude to maintain an erase cycle counter in the last four bytes of the eeprom. The counter has to be initialized by calling avrdude with the option '-Y 1' once. : : Do not use this option if your e6 configuration uses the last four bytes of the eeprom. ;Bitclock for ISP or JTAG :avrdude option '-B'. :Specify the bit clock period for the JTAG interface or the ISP clock. :Setting a lower value means higher programming speed. Use higher values if you experience programming errors in your setup. : : The available choices depend on the MCU frequency setting and should not exceed 4/F_CPU in micro seconds: : :*4 micro seconds is required for F_CPU < 4 MHz. :*1 micro second is appropriate for F_CPU < 10 MHz. :*0.5 micro seconds is appropriate for F_CPU < 16 MHz. :*0.3 micro seconds is appropriate for F_CPU >= 16 MHz. : ;Pass extra options to avrdude :If your programmer or setup requires any extra options to avrdude you may pass them here. === AVR Fuses === The fuse registers enable/disable or control the basic functionality of the different units of the MCU. One can e. g. enable or disable the Watchdog, the JTAG interface or even the ISP Interface. Configuration of the MCUs clock source or the brown-out detector is also done via the fuse registers. '''WARNING: Programming wrong fuse values may render your MCU UNUSABLE''' (...unless you've access to a JTAG- and/or HV-Programmer.) '''There is nothing like ''the universal correct fuse setting'' or ''default fuse setting''. Fuse registers are MCU-specific and their correct settings heavily depend on the circuit and parts in use. Be careful, read the datasheet for the MCU acually in use and think twice what is correct for YOUR hardware!!''' ;Fuse Low Byte (FLB) :AVR Fuse Low Byte, two-digit hex value. : ;Fuse High Byte (FHB) :AVR Fuse High Byte, two-digit hex value. : ;Extended Fuse Byte (EFB) :AVR Extended Fuse Byte, two-digit hex value. The necessary hex values for the fuse registers might be calculated with e.g. an online [http://www.engbedded.com/fusecalc AVR fuse calculator]. [http://www.mikrocontroller.net/articles/AVR_Fuses Article on mikrocontroller.net for reference (German).] == Writing the Bytes == * Disconnect the power from the target board * Connect your ISP cable to the programmer and the target board * Reconnect the power and connect your programmer to the PC * Execute the command you assembled earlier or type ''make program'' * Congratulations! If [[avrdude]] finished without any error you successfully flashed [[Ethersex]] to your target board! * Disconnect the power and the programmer from the target * Reconnect the power, your target should boot up with [[Ethersex]] [[Quick_Start_Guide/Configuration | previous step]] | [[Category:Ethersex]] [[Category:Quick Start Guide]] [[Category:StepByStep]] 12aa1d216bdad446af71ceb93ee6f9b204b0a8b6 1161 1160 2013-07-19T14:14:49Z GooPie4o 265 /* Writing the Bytes */ wikitext text/x-wiki {{i18n|Quick Start Guide/Flashing}} = Flashing = After compiling the ''ethersex.hex'' you can flash it with avrdude. You can either use avrdude on the command line or call the target ''program'' from the [[Ethersex]] Makefile. == Prerequisites == * the previously selected board, e.g. AVR NET-IO, ready built and (hopefully) tested * an ISP-Programmer of your choice supported by [http://www.nongnu.org/avrdude avrdude] * an ISP connector cable that fits to your programmer and your board (either 6 or 10-pin) * an ethersex.hex compiled in the [[Quick_Start_Guide/Configuration | previous step]] If you have an ISP-Programmer with a 6-pin port and a board with a 10-pin header - like the AVR NET-IO - you can create an adapter. You can see the pin configuration in figure 4-1 at page 5 [http://www.atmel.com/dyn/resources/prod_documents/doc2521.pdf AVR042: AVR Hardware Design Considerations]. Note that Pin 4 of the 10-pin connector is not used on the AVR NET-IO. GND has to be connected to one of the other Pins (6, 8 or 10). == Flashing the image with avrdude == The following commands are just examples, the actual command line depends on your ISP-Programmer and hardware. This example is for a serial connection (e.g. the ATMEL Evaluation-Board): avrdude -v -p m32 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex This example for a real USB ISP-Programmer: avrdude -p m1284p -c avrispmkII -P usb -U flash:w:ethersex.hex For a serial programmer connected via an USB-serial-adapter this may be used: avrdude -v -p m32 -c stk500v2 -P /dev/ttyACM0 -U flash:w:ethersex.hex And this one for a parallel ISP-Cable: avrdude -p m32 -e -c stk200 -U flash:w:ethersex.hex After flashing remove the ISP-Cable and interrupt the power connection for a short time to reboot the board. * -p m32: ATMega32; -p m644: ATMega644; -p ? to list the valid parts * -v: display debug messages * -c ponyser: traditional serial programmer; -c stkk500v2 for the Atmel board * -P /dev/tty.serial the serial port your programmer is connected to; -P COM1 for windows machines; -P usb for USB * -U the command you want to execute. In our case we want to flash: -U flash:w:ethersex.hex == Using avrdude from the makefile == Since [https://github.com/ethersex/ethersex/commit/16c2a388ec775b51c049db1eeff3a8171c6ad71b 16c2a388ec] the [[Ethersex]] makefile supports two new targets, ''program'' and ''fuses'', to invoke avrdude. The target ''program'' calls avrdude with the options to flash the previously compiled ''ethersex.hex'' to the MCU. The ''fuses'' target may be used to program the MCUs fuse registers. AVRDUDE options and MCU fuse register settings may be configured via a menuconfig dialog. All settings will be saved to the current profile ''.config''. Available settings and choices on the AVRDUDE configuration page depend on the MCU and clock frequency configured on the General Setup dialog. Please go back to the [[Quick_Start_Guide/Configuration | previous step]] if you haven't done that yet. === AVRDUDE Configuration === If - and only if - the avrdude executable could be found in your ''PATH'', menuconfig's mainmenu will show an option to enter AVRDUDE configuration. [[File:avrdude_mainmenu.png|right|sub|thumb|200px|menuconfig's mainmenu with AVRDUDE Configuration selected]] The AVRDUDE configuration page allows to setup the most common options for avrdude: [[File:avrdude_menu.png|right|sub|thumb|200px|AVRDUDE configuration page]] ;Programmer Type :avrdude option '-c'. :Use the programmer configuration choosen from the list. : :Refer to the official avrdude documentation if you're in doubt about the correct choice for your programmer ([http://www.nongnu.org/avrdude/ avrdude home]). : :NB: The list of choices is generated by calling 'avrdude -c ?' and contains all the programmers your avrdude executable supports. ;Port :avrdude option '-P'. :Specify the port the programmer is connected to. Serial devices like ponyprog use for example ''/dev/ttyS0'' (= COM1 under Windows!), most modern programmers use ''usb''. : : Note that most old-style serial programmers will not work properly when connected to an USB-serial-Adapter! ; Extra verbose output :avrdude option '-v -v'. :Be more verbose. Default is '-v'. Use this, if you experience problems while flashing or simply want to see in detail whats going on... ;Do NOT verify after programming :avrdude option '-V'. :Do NOT verify flash memory after programming. Use with care and only if you're really sure that your setup is perfect. Speeds things up a bit but it's use is generally discouraged. ;Count # of erase cycles in EEPROM :avrdude option '-y'. :Tell avrdude to maintain an erase cycle counter in the last four bytes of the eeprom. The counter has to be initialized by calling avrdude with the option '-Y 1' once. : : Do not use this option if your e6 configuration uses the last four bytes of the eeprom. ;Bitclock for ISP or JTAG :avrdude option '-B'. :Specify the bit clock period for the JTAG interface or the ISP clock. :Setting a lower value means higher programming speed. Use higher values if you experience programming errors in your setup. : : The available choices depend on the MCU frequency setting and should not exceed 4/F_CPU in micro seconds: : :*4 micro seconds is required for F_CPU < 4 MHz. :*1 micro second is appropriate for F_CPU < 10 MHz. :*0.5 micro seconds is appropriate for F_CPU < 16 MHz. :*0.3 micro seconds is appropriate for F_CPU >= 16 MHz. : ;Pass extra options to avrdude :If your programmer or setup requires any extra options to avrdude you may pass them here. === AVR Fuses === The fuse registers enable/disable or control the basic functionality of the different units of the MCU. One can e. g. enable or disable the Watchdog, the JTAG interface or even the ISP Interface. Configuration of the MCUs clock source or the brown-out detector is also done via the fuse registers. '''WARNING: Programming wrong fuse values may render your MCU UNUSABLE''' (...unless you've access to a JTAG- and/or HV-Programmer.) '''There is nothing like ''the universal correct fuse setting'' or ''default fuse setting''. Fuse registers are MCU-specific and their correct settings heavily depend on the circuit and parts in use. Be careful, read the datasheet for the MCU acually in use and think twice what is correct for YOUR hardware!!''' ;Fuse Low Byte (FLB) :AVR Fuse Low Byte, two-digit hex value. : ;Fuse High Byte (FHB) :AVR Fuse High Byte, two-digit hex value. : ;Extended Fuse Byte (EFB) :AVR Extended Fuse Byte, two-digit hex value. The necessary hex values for the fuse registers might be calculated with e.g. an online [http://www.engbedded.com/fusecalc AVR fuse calculator]. [http://www.mikrocontroller.net/articles/AVR_Fuses Article on mikrocontroller.net for reference (German).] == Writing the Bytes == * Disconnect the power from the target board * Connect your ISP cable to the programmer and the target board * Reconnect the power and connect your programmer to the PC * Execute the command you assembled earlier or type ''make program'' * Congratulations! If [[avrdude]] finished without any error you successfully flashed [[Ethersex]] to your target board! * Disconnect the power and the programmer from the target * Reconnect the power, your target should boot up with [[Ethersex]] [[Quick_Start_Guide/Configuration | previous step]] [[Category:Ethersex]] [[Category:Quick Start Guide]] [[Category:StepByStep]] d03e954bc806a39253f2e022156ce5c76a6205ce 0 171 1162 1127 2013-07-19T14:16:18Z GooPie4o 265 wikitext text/x-wiki {{i18n|Quick Start Guide/Configuration}} [[File:E6menuconfig.png|right|thumb|200px| make menuconfig inside the hardware menu]] After [[Quick_Start_Guide/Preparation | installing the required software and cloning the repository]], ''cd'' to the root directory of ethersex. == General Settings == Type make menuconfig to start the text-based configuration UI of ethersex. Select the default configuration by selecting (enter). Load a Default Configuration ---> Now select for example Pollin AVR Net-IO Back in the main menu, enter General Setup ---> and select your '''Target MCU''' followed by the '''MCU frequency''' in Hz Go back to the main menu and enter the Network ---> menu. Select Ethernet (ENC28J60) support ---> and enter the '''MAC address''' Now adjust the '''IP address''' and '''Netmask''' for your network. Exit this menu as well as the '''Network''' menu. Hit the '''< Exit >''' button once again and select '''< Yes >''' to save your config. == Compiling == Run make to start the build process. This will only take a few seconds. If everything went well, which means you see something like this... <pre> =======The ethersex project======== Compiled for: atmega644p at 20000000Hz Imagesize: 36057/65536 bytes (55.02%) [================--------------] Program (.text + .data) : 28098 bytes Data (.data + .bss) : 1698 bytes =================================== </pre> ...you are ready to [[Quick_Start_Guide/Flashing | flash the firmware to your board!]] [[Quick_Start_Guide/Preparation | previous step]] | [[Quick_Start_Guide/Flashing | next step]] [[Category:Ethersex]] [[Category:Quick Start Guide]] [[Category:StepByStep]] a5ba1c7ddcf58db4d90b4636c98e6c7d0abca6df 6 379 1163 2013-07-20T10:52:39Z GooPie4o 265 BT0417C on breakout board wikitext text/x-wiki BT0417C on breakout board 85cc2b938e31d5d036421dd5ce29c579ded29cbc 0 139 1170 586 2013-07-24T17:02:22Z Mgue 312 /* include files in make-process */ wikitext text/x-wiki {{i18n|own_module}} Here you can find the most relevant information in order to develop your own module. Note also the project-wide [[Contributing#Coding_Style | coding style]] and other information as described in [[define pins in ethersex]]. == License == In order to publish your module with Ethersex you have to put your code under a GPLv3-compatible license. At best include the following license header in each of your source code files (*.h, *.c): /* * * Copyright (c) 2012 by YOUR_NAME <FIRST@SIR.net> * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * as published by the Free Software Foundation; either version 3 * of the License, or (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. * * For more information on the GPL, please go to: * http://www.gnu.org/copyleft/gpl.html */ Don't forget to replace YOUR_NAME with your Name. == proper directory == You can place your module in one of the directories „hardware“, „services“ or „protocols“. If your module fulfills several of these categories, the module may be divided into smaller sub-modules. Detailed descriptions can be found in each directory in the file "content.txt". If you're not sure where to put your module, ask on the mailing list. the three categories roughly outlined: * Hardware: modules to control external hardware. * Services: modules implementing applications/daemons/services. * Protocols: modules implementing protocols. == include files in make-process == Let's assume you've added a file in a subdirectory. In order to make the file known to the make-system you need to create a Makefile, which can look like the following example: <pre> TOPDIR ?= ../.. include $(TOPDIR)/.config $(DC3840_SUPPORT)_SRC += hardware/camera/dc3840.c ############################################################################## # generic fluff include $(TOPDIR)/scripts/rules.mk </pre> Instead of the variable, which ends on _SRC, you can choose one of the following alternatives: # the file should be linked always. <pre> SRC += path/yourfile.c </pre> # the files inclusion depends on a config option in Menuconfig. <pre>${YOURBRILLIANTMODUL_SUPPORT}_SRC += path/yourfile.c </pre> # the files inclusion depends on another config option, if the ecmd parser is enabled. <pre>${YOURBRILLIANTMODUL_SUPPORT}_ECMD_SRC += path/yourfile.c </pre> Depending on the depth of the folder you have created, the path to your folder must of course adapt the number of '' ../'' to your folder. Furthermore, you have to include the directory of your module in the appropriate Makefile (/hardware/Makefile /protocols/Makefile or /services/Makefile). Example: /hardware/Makefile: SUBSUBDIRS += hardware/camera You can also add this entry in the corresponding custom.mk file (e.g. /hardware/custom.mk). This has the advantage that any changes in *custom.mk are not tracked by git. With this solution you can add own modules without committing them and still be able keep the repository up-to-date. == Menuconfig == To add your module for graphical configuration (make menuconfig), you need a file in your module folder called config.in, for example, with the following contents: dep_bool_menu 'brilliant module' YOURBRILLIANTMODUL_SUPPORT $TCP_SUPPORT This entry creates a submenu and you can activate your module only if TCP_SUPPORT is enabled. To activate your module without dependencies and without an additional menu to choose from you should use be following method: bool 'brilliant module' YOURBRILLIANTMODUL_SUPPORT Analogous to the Makefile you have to include your config.in in $(TOPDIR)/config.in: source hardware/camera/config.in == starting functions after boot and periodically == # You have developed a new module, that contains an initialization function which should be called after boot. # Your module contains a function that is constantly called if possible (or as often as possible, at least as much computing time is left over by the other application which run as a service. Therefore are the ''Ethersex Meta'' areas, maybe you've already discovered them at the end of some C-files. It basically has the following structure: <pre> / * - Ethersex META - mainloop(stella_process) init(stella_init) * / </pre> These lines, inserted at end of a file, ensure that the function ''stella_init'' is called once at the start of your modified Ethersex-Firmware and the function ''stella_process'' is called as often as possible. You can include multiple ''init'', ''mainloop'' and ... directives in the meta area. Other directives are: * '''initearly''' - works like ''init''. The functions are called just before'' init''. This is useful for dependencies, in general, you should use, however, ''init''. * '''net_init''' - to initialize network applications. The functions are called after the'' init'' functions. * '''startup''' - these functions are started before calling the mainloop. The Sendmail service for example sends the start message. * '''timer''' - Periodically (every 20ms) as in mainloop. Example: timer(50, function()) calls function() every 50*20ms, thus 1x per second. * '''header''' - not documented the functions must be called in case of init without parentheses init(<fkt>) and the timer directive without brackets timer(<int> <fkt>()) . == debug output == Programming for embedded systems can be quite unnerving sometimes. Normally you do not have the necessary hardware (JTAG) for step-by-step debugging. The Ethersex core offers you some debug output functions to at least observe the program flow via syslog or the serial interface. The following debug functions are available after you include core/debug.h in your files: * void debug_printf(s, args...) // syntax like printf from the standard C library * char* debug_binary(uint8_t) // returns an 8 Byte long string of 0/1, which represents the integer The following debug functions are available after you include protocols/syslog/syslog.h in your files: * void syslog_sendf(s, args...) // syntax like printf from the standard C library [[Category:Ethersex]] [[Category:StepByStep]] [[Category:Development]] f651e8a82bd260c2ebc6e871d9e6434446861ec5 2 329 1173 861 2013-08-11T18:37:27Z Djmaster 255 wikitext text/x-wiki [[File:RJ45Buchse_Pinout.png|400px|thumb|RJ45 Buchse]] ==Person== Nick im IRC: djmaster oder djmaster2<br> Web: http://wiki.senseye.org/ ==Bauteile== Für [http://www.lochraster.org/etherrape/ Etherrape] Module {| | {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%;" |- ! Bauteil !! Hersteller !! HerstellerNr !! Lieferant !! Bestellnummer !! Dokumente !! Sonstiges |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/products/en?q=6605424-1 6605424-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154361/ 615-4361] || [http://www.te.com/catalog/pn/en/6605424-1?RQPN=6605424-1 Link] || Netzwerkbuchse ohne LED, Verriegelung Unten |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/pn/en/5-6605308-1 5-6605308-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154383/ 615-4383] || [http://www.te.com/catalog/pn/en/5-6605308-1?RQPN=5-6605308-1 Link] || Netzwerkbuchse mit LED, Verriegelung Unten |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/products/en?q=6605759-1 6605759-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154399/ 615-4399] || [http://www.te.com/catalog/pn/en/6605759-1?RQPN=6605759-1 Link] || Netzwerkbuchse ohne LED, Verriegelung Oben |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/products/en?q=5-6605758-1 5-6605758-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154412/ 615-4412] || [http://www.te.com/catalog/pn/en/5-6605758-1?RQPN=5-6605758-1 Link] || Netzwerkbuchse mit LED, Verriegelung Oben |- align="right" | Hutschienen Gehäuse || Axxatronic || [http://www.axxatronic.de/serie-cnmb.html CNMB-4-KIT-CON] || Conrad || [http://www.conrad.at/ce/de/product/531443/Axxatronic-Hutschienen-Gehaeuse-CNMB-4-KIT-CON-Polycarbonat-L-x-B-x-H-90-x-710-x-58-mm 531443 - 62] || [http://www.axxatronic.de/serie-cnmb.html Link] || (L x B x H) 90 x 71.0 x 58 mm |- align="right" | DS2450 || Maxim || [http://www.maximintegrated.com/datasheet/index.mvp/id/2921 DS2450] || RS-Components || [http://at.rs-online.com/web/p/products/07327557/ 732-7557] || [http://datasheets.maximintegrated.com/en/ds/DS2450.pdf Link] || Onewire quad AD Converter |- align="right" | HIH4000-001 || Honeywell || [http://sensing.honeywell.com/product%20page?pr_id=53944 HIH4000-001] || RS-Components || [http://at.rs-online.com/web/p/products/05283171/ 528-3171] || [http://sensing.honeywell.com/product%20page?pr_id=53944 Link] || Luftfeuchte Sensor von Honeywell |- align="right" | MPXH6115AC6U || Freescale || xx || RS-Components || [http://at.rs-online.com/web/p/products/07176536/ 717-6536] || [http://www.freescale.com/files/sensors/doc/data_sheet/MPXA6115A.pdf Link] || Luftdruck Sensor von Freescale |} ==Die Software== [[File:Ethersex det ssr.png|400px|thumb|die Theorie]] [[File:Hausbus v1.JPG|400px|thumb|die Praxis]] ===TFTP-Bootloader & Fuses=== Menuconfig: │ │ Load a Default Configuration ---> │ │ [*] Ethernet Bootloader │ │ Network ---> │ │ [*] Ethernet (ENC28J60) support ---> │ │ Etherrape IP address: "192.168.12.220" │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ Applications ---> │ │ [*] TFTP support ---> │ │ Bootloader configuration ---> │ │ [*] TFTP-o-matic │ │ --- TFTP-o-matic configuration │ │ TFTP IP address: "192.168.12.120" │ │ TFTP image to load: "ethersex.bin" make clean && make --> ethersex.hex =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 6064/65536 bytes (9.25%) [==----------------------------] Program (.text + .data) : 6064 bytes Data (.data + .bss) : 826 bytes =================================== sudo avrdude -cusbasp -pm644 -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m sudo avrdude -cusbasp -pm644 -U flash:w:ethersex.hex sudo avrdude -cusbasp -pm644 -U lock:w:0x0F:m Achtung bei den SMD Typen vom mega644, ich habe mega644P bekommen, wobei ich jetzt nicht weiß ob die SMD immer P Typen sind. Egal das Problem ist man sollte avrdude genau lesen und auch "-p m644p" anhängen da der P Type eine andere Signatur aufweist. Hat mich ne Stunde gekostet. ;) ==Bilder== ===Testsystem=== <gallery perrow=7> File:1_stella_all_off.jpg File:2_stella_all_on.jpg File:3_mosfets.jpg File:4_schaltung_fet.png File:IMG_5286.JPG File:IMG_6592.JPG File:IMG_6594.JPG File:S0-zaehler_img.JPG File:Esex sensor1.JPG </gallery><br> ==Probleme== 25.1.2011 - ethersex mit m644 und 32khz uhrenquarz.<br> datenblatt mega644 seite 101 - http://www.atmel.com/dyn/resources/prod_documents/doc2593.pdf<br> services/clock/clock.c - zeile 64<br> <obiflix> du könntest https://github.com/ethersex/ethersex/commit/da511f074940423e8e8ef7ee67ca20e6d91f608c rückgängig machen <obiflix> möglicherweise bekommst du dann probleme mit dcf77, falls du das nutzen möchtest, aber einen versuch ist es wert ;) Notiz: Hat funktioniert für den MEGA644<br> Update#1<br> 26.1.2011 - Problem sollte nun behoben sein, Danke an eku! master Erik Kunze * ae3ef98 (2 files in 1 dirs): use timer makros for prescaler 64 (32768Hz/256/64=2Hz) - http://bit.ly/eG2d4c --- DCF muss noch getestet werden ==Notizzettel== schnell mal notiert ein script zum email versenden wenn zb..PIN_LOW... <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include <util/delay.h> CONTROL_START CLOCK_USED() ECMD_GLOBAL(t1, 0, uint16_t); ECMD_GLOBAL(var1, 0); ECMD_GLOBAL(var2, 0); ECMD_GLOBAL(aqua_mail_sent, 0, uint8_t) THREAD(start) if (!PIN_HIGH(WTR)) t1++; else t1=0; if (t1 > 10) var1=1; else var1 = 0; if (t1 > 400) var2=1; else var2 = 0; if (var1 == 1) PIN_CLEAR(LED1); else PIN_SET(LED1); if (var2 == 1){ if (aqua_mail_sent == 0){ PIN_CLEAR(LED2); mail_send(); aqua_mail_sent = 1; } var2 = 0; }else{ PIN_SET(LED2); } THREAD_END(start) ON STARTUP DO THREAD_START(start) END CONTROL_END </source> c4e8d18f6d0368196fafc73a63a478d79590e56d 0 28 1174 405 2013-08-12T23:44:35Z Mgue 312 updated versions wikitext text/x-wiki {{i18n|DMX Storage}} {{Module |NAME=DMX Storage |MENUCONFIG={{Applications}}->DMX Storage |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] (optional) |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/services/dmx-storage https://github.com/ethersex/ethersex/tree/master/services/dmx-storage] }} Dmx Storage provides a database-like storage layer for DMX information. It forms the core of the [[Ethersex Lighting Architecture]]. == Modules (input) == The following modules change/alter the DMX data *[[Artnet]] *[[DMX]] (not yet implemented) *[[DMX FXSlot]] *[[DMX_Storage#HTML_Interface | DMX WebGUI]] == Modules (output) == The following modules display/use the dmx data *[[Artnet]] *[[DMX]] *[[Starburst]] *[[StellaLight]] == [[ECMD]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx channels | Get channels per universe |- | dmx get | Return channel value |- | dmx set | Set channel values |- | dmx universe | Get a whole universe |- | dmx universes | Get universes |- |} == Web GUI == DMX Storage Channels can also be altered via the HTTP-Server. The interface currently works in most of the Webkit-based browsers (e.g. Google Chrome) and Mozilla Firefox (Version 4+). The interface can be enabled in the [VFS] menu. Tested browsers: {| border='1' |- | Browser | Version | Works |- | Firefox | 23 | yes (see note) |- | Chromium | 28.0.1500.95 | yes |- | Konqueror | 4.10.5 | yes |- | Android Browser | Android 4.3 | yes |- |} When using Firefox with a version < 23, make sure to enable "Support <input type=range> for Firefox". [[File:Ethersex-dmxUI.png|right|500px|thumb|The HTML interface in Chromium 17]] [[Category:e6la]] 043c3a9ba670d37e32c88c6902bed231b0e48d39 0 156 1176 1085 2013-10-25T13:41:58Z Pewel 720 /* 2272 */ wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{I/O}}->Radio->RFM12 ASK->433MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} RFM12 ASK schaltet Funksteckdosen verschiedener Hersteller. == Unterstützte Systeme == ===Tevion=== Funksteckdosen mit einer 'Anlern-Taste' können mit Hilfe des LERN-Buttons auf der embeded Website des etherrapes */rf.ht auf den gesendeten Hauscode programmiert werden. Erstaunlicherweise können mit diesem Modul auch die Codes der X10 Fernbedienung von Pollin gesendet werden. Eine Code-Sammlung gibts [[X10-codes|hier]]. [[Category:RFM12]] Getestet: * Tevion * MMANDOLYN LIBRA GmbH, Model No. WRC001 * X10 Pollin Best.Nr. 721 379 ===Intertechno (ITS-150)=== Bei Sender vom Typ Intertechno ITS-150 wird über einen Drehschalter auf der Rückseite der Familiencode eingestellt. Auf der Vorderseite gibt es einen Schieberegler für die Auswahl von Gruppe 1-4 sowie Ein/Aus Knöpfe für die Geräte 1-4 (siehe Bild). Die zusätzlich vorhandenen Gruppentaste funktioniert mit den Empfängern Intertechno CMR-500 nicht (deshalb nicht implementiert). [[Image:Intertechno-its150.jpg|150px]] ===2272=== Diese Steckdosen werden üblicherweise über einen Block von 10 DIP-Switches konfiguriert. Dabei wird mit den ersten fünf Schaltern der Hauscode gesetzt. Es ergeben sich also 32 mögliche Einstellungen. Die übrigen fünf Schalter geben die Adresse der Steckdose an. Bei Verwendung des mitgelieferten Senders wird jeweils einer der Adressschalter auf "1" gesetzt: In Dose A setzt man Dip 6 auf '1'; in Dose B Dip 7 auf '1'... Bei Ansteuerung mit dem Ethersex-System besteht diese Einschränkung nicht, so dass hier 32 verschiedene Adressen möglich sind. Getestet: {|class=wikitable |[http://www.elro.eu/uploads/products/img/_w200/AB440RA_1.jpg] |[[Image:Duewiaktor.jpg|134px]] |[[Image:Globusaktoren.jpg|134px]] |[[Image:Kangtai2605.jpg|101px]] |[[Image:Kangtai6899s.jpg|100px]] |- |valign=top|ELRO AB440R |valign=top|Düwi Modell 0369-3 |valign=top|Kangtai<br>v. Globus |valign=top|Kangtai<br>Model 2605 |valign=top|Kangtai<br>Model 6899s<br>[[Warnung vor Kangtai 6899s|'''Warnung!''']] |- |Delay 100 |Delay 60 |Delay 72 |Delay 72 |Delay 72 |} ---- ==== Funkleuchten lassen sich auch schalten! ==== Neben den hier aufgeführten Funksteckdosen, lassen sich mit diesem Modul auch wunderbar diverse "neumodische" Funk-Leuchten, wie man sie aus Einrichtungshäusern kennt schalten. Die Fernbedienungen der Leuchten arbeiten dabei nicht mit dem 2262 Codierchip, sondern mit dem W0369DGP Codierchip. Dieser codiert genau wie der 2262 jedoch ist die Aufteilung der Codierbits (DIP-Schalter) auf Hauscode und Gerätecode anders als bei den Funk Steckdosen. ToBeDone === 1527 === Anlernbare Unterputz-Dimmer (zB. Pollin Funkdimmerset FD-UP003) mit Fernbedienung. Die mitgelieferte Fernbedienung besitzt einen HS1527 Encoder (baugleich RT1527/ EV1527/FP1527/SC1527). Der gesendete Code bestehtaus 24 Bits, welche per ASK gesendet werden. Davon sind die ersten 20 Bits fest programmiert - der Hauscode sozusagen. Die letzten 4 Bits sind der eigentliche Schalt-Befehl. Getestet: {|class=wikitable |[[Image:FD-UP003.jpg‎|150px|Pollin Electronic FD-UP003]] |- |valign=top|Pollin FD-UP003<br>[[Hinweis FD-UP003|'''Hinweis!''']] |} === Oase Inscenio FM Master === Das Baukastensystem für Gartensteckdosen der Serie [http://www.oase-livingwater.com/de_DE/wasser-garten/produkte/illumination-und-strom/strommanagement/inscenio.html InScenio] organisiert die gesamte Garten- und Teichtechnik. == Anschluss == == Konfiguration == == [[ECMD]] == RFM12 ASK implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle zur Steuerung von Funksteckdosen. Siehe [[ECMD_Reference|ECMD Referenz]]. ca8609f94d49131c049b0856243fbe70429381f5 1177 1176 2013-10-25T13:42:51Z Pewel 720 /* 2272 */ wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{I/O}}->Radio->RFM12 ASK->433MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} RFM12 ASK schaltet Funksteckdosen verschiedener Hersteller. == Unterstützte Systeme == ===Tevion=== Funksteckdosen mit einer 'Anlern-Taste' können mit Hilfe des LERN-Buttons auf der embeded Website des etherrapes */rf.ht auf den gesendeten Hauscode programmiert werden. Erstaunlicherweise können mit diesem Modul auch die Codes der X10 Fernbedienung von Pollin gesendet werden. Eine Code-Sammlung gibts [[X10-codes|hier]]. [[Category:RFM12]] Getestet: * Tevion * MMANDOLYN LIBRA GmbH, Model No. WRC001 * X10 Pollin Best.Nr. 721 379 ===Intertechno (ITS-150)=== Bei Sender vom Typ Intertechno ITS-150 wird über einen Drehschalter auf der Rückseite der Familiencode eingestellt. Auf der Vorderseite gibt es einen Schieberegler für die Auswahl von Gruppe 1-4 sowie Ein/Aus Knöpfe für die Geräte 1-4 (siehe Bild). Die zusätzlich vorhandenen Gruppentaste funktioniert mit den Empfängern Intertechno CMR-500 nicht (deshalb nicht implementiert). [[Image:Intertechno-its150.jpg|150px]] ===2272=== Diese Steckdosen werden üblicherweise über einen Block von 10 DIP-Switches konfiguriert. Dabei wird mit den ersten fünf Schaltern der Hauscode gesetzt. Es ergeben sich also 32 mögliche Einstellungen. Die übrigen fünf Schalter geben die Adresse der Steckdose an. Bei Verwendung des mitgelieferten Senders wird jeweils einer der Adressschalter auf "1" gesetzt: In Dose A setzt man Dip 6 auf '1'; in Dose B Dip 7 auf '1'... Bei Ansteuerung mit dem Ethersex-System besteht diese Einschränkung nicht, so dass hier 32 verschiedene Adressen möglich sind. Getestet: {|class=wikitable |[http://www.elro.eu/uploads/products/img/_w200/AB440RA_1.jpg] |[[Image:Duewiaktor.jpg|134px]] |[[Image:Globusaktoren.jpg|134px]] |[[Image:Kangtai2605.jpg|101px]] |[[Image:Kangtai6899s.jpg|100px]] |- |valign=top|ELRO AB440R |valign=top|Düwi Modell 0369-3 |valign=top|Kangtai<br>v. Globus |valign=top|Kangtai<br>Model 2605 |valign=top|Kangtai<br>Model 6899s<br>[[Warnung vor Kangtai 6899s|'''Warnung!''']] |- |Delay 100 |Delay 60 |Delay 72 |Delay 72 |Delay 72 |} ====== Funkleuchten lassen sich auch schalten! ===== Neben den hier aufgeführten Funksteckdosen, lassen sich mit diesem Modul auch wunderbar diverse "neumodische" Funk-Leuchten, wie man sie aus Einrichtungshäusern kennt schalten. Die Fernbedienungen der Leuchten arbeiten dabei nicht mit dem 2262 Codierchip, sondern mit dem W0369DGP Codierchip. Dieser codiert genau wie der 2262 jedoch ist die Aufteilung der Codierbits (DIP-Schalter) auf Hauscode und Gerätecode anders als bei den Funk Steckdosen. ToBeDone === 1527 === Anlernbare Unterputz-Dimmer (zB. Pollin Funkdimmerset FD-UP003) mit Fernbedienung. Die mitgelieferte Fernbedienung besitzt einen HS1527 Encoder (baugleich RT1527/ EV1527/FP1527/SC1527). Der gesendete Code bestehtaus 24 Bits, welche per ASK gesendet werden. Davon sind die ersten 20 Bits fest programmiert - der Hauscode sozusagen. Die letzten 4 Bits sind der eigentliche Schalt-Befehl. Getestet: {|class=wikitable |[[Image:FD-UP003.jpg‎|150px|Pollin Electronic FD-UP003]] |- |valign=top|Pollin FD-UP003<br>[[Hinweis FD-UP003|'''Hinweis!''']] |} === Oase Inscenio FM Master === Das Baukastensystem für Gartensteckdosen der Serie [http://www.oase-livingwater.com/de_DE/wasser-garten/produkte/illumination-und-strom/strommanagement/inscenio.html InScenio] organisiert die gesamte Garten- und Teichtechnik. == Anschluss == == Konfiguration == == [[ECMD]] == RFM12 ASK implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle zur Steuerung von Funksteckdosen. Siehe [[ECMD_Reference|ECMD Referenz]]. 460dd154955b0a4815fa5425d1c794f4719d0c32 1178 1177 2013-10-28T09:07:29Z GooPie4o 265 /* = Funkleuchten lassen sich auch schalten! */ wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{I/O}}->Radio->RFM12 ASK->433MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} RFM12 ASK schaltet Funksteckdosen verschiedener Hersteller. == Unterstützte Systeme == ===Tevion=== Funksteckdosen mit einer 'Anlern-Taste' können mit Hilfe des LERN-Buttons auf der embeded Website des etherrapes */rf.ht auf den gesendeten Hauscode programmiert werden. Erstaunlicherweise können mit diesem Modul auch die Codes der X10 Fernbedienung von Pollin gesendet werden. Eine Code-Sammlung gibts [[X10-codes|hier]]. [[Category:RFM12]] Getestet: * Tevion * MMANDOLYN LIBRA GmbH, Model No. WRC001 * X10 Pollin Best.Nr. 721 379 ===Intertechno (ITS-150)=== Bei Sender vom Typ Intertechno ITS-150 wird über einen Drehschalter auf der Rückseite der Familiencode eingestellt. Auf der Vorderseite gibt es einen Schieberegler für die Auswahl von Gruppe 1-4 sowie Ein/Aus Knöpfe für die Geräte 1-4 (siehe Bild). Die zusätzlich vorhandenen Gruppentaste funktioniert mit den Empfängern Intertechno CMR-500 nicht (deshalb nicht implementiert). [[Image:Intertechno-its150.jpg|150px]] ===2272=== Diese Steckdosen werden üblicherweise über einen Block von 10 DIP-Switches konfiguriert. Dabei wird mit den ersten fünf Schaltern der Hauscode gesetzt. Es ergeben sich also 32 mögliche Einstellungen. Die übrigen fünf Schalter geben die Adresse der Steckdose an. Bei Verwendung des mitgelieferten Senders wird jeweils einer der Adressschalter auf "1" gesetzt: In Dose A setzt man Dip 6 auf '1'; in Dose B Dip 7 auf '1'... Bei Ansteuerung mit dem Ethersex-System besteht diese Einschränkung nicht, so dass hier 32 verschiedene Adressen möglich sind. Getestet: {|class=wikitable |[http://www.elro.eu/uploads/products/img/_w200/AB440RA_1.jpg] |[[Image:Duewiaktor.jpg|134px]] |[[Image:Globusaktoren.jpg|134px]] |[[Image:Kangtai2605.jpg|101px]] |[[Image:Kangtai6899s.jpg|100px]] |- |valign=top|ELRO AB440R |valign=top|Düwi Modell 0369-3 |valign=top|Kangtai<br>v. Globus |valign=top|Kangtai<br>Model 2605 |valign=top|Kangtai<br>Model 6899s<br>[[Warnung vor Kangtai 6899s|'''Warnung!''']] |- |Delay 100 |Delay 60 |Delay 72 |Delay 72 |Delay 72 |} ===== Funkleuchten lassen sich auch schalten! ===== Neben den hier aufgeführten Funksteckdosen, lassen sich mit diesem Modul auch wunderbar diverse "neumodische" Funk-Leuchten, wie man sie aus Einrichtungshäusern kennt schalten. Die Fernbedienungen der Leuchten arbeiten dabei nicht mit dem 2262 Codierchip, sondern mit dem W0369DGP Codierchip. Dieser codiert genau wie der 2262 jedoch ist die Aufteilung der Codierbits (DIP-Schalter) auf Hauscode und Gerätecode anders als bei den Funk Steckdosen. ToBeDone === 1527 === Anlernbare Unterputz-Dimmer (zB. Pollin Funkdimmerset FD-UP003) mit Fernbedienung. Die mitgelieferte Fernbedienung besitzt einen HS1527 Encoder (baugleich RT1527/ EV1527/FP1527/SC1527). Der gesendete Code bestehtaus 24 Bits, welche per ASK gesendet werden. Davon sind die ersten 20 Bits fest programmiert - der Hauscode sozusagen. Die letzten 4 Bits sind der eigentliche Schalt-Befehl. Getestet: {|class=wikitable |[[Image:FD-UP003.jpg‎|150px|Pollin Electronic FD-UP003]] |- |valign=top|Pollin FD-UP003<br>[[Hinweis FD-UP003|'''Hinweis!''']] |} === Oase Inscenio FM Master === Das Baukastensystem für Gartensteckdosen der Serie [http://www.oase-livingwater.com/de_DE/wasser-garten/produkte/illumination-und-strom/strommanagement/inscenio.html InScenio] organisiert die gesamte Garten- und Teichtechnik. == Anschluss == == Konfiguration == == [[ECMD]] == RFM12 ASK implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle zur Steuerung von Funksteckdosen. Siehe [[ECMD_Reference|ECMD Referenz]]. a6880bd48008cbd7829072f9c76c677cdee04b0b 1179 1178 2013-10-28T19:17:02Z Pewel 720 /* Funkleuchten lassen sich auch schalten! */ wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{I/O}}->Radio->RFM12 ASK->433MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} RFM12 ASK schaltet Funksteckdosen verschiedener Hersteller. == Unterstützte Systeme == ===Tevion=== Funksteckdosen mit einer 'Anlern-Taste' können mit Hilfe des LERN-Buttons auf der embeded Website des etherrapes */rf.ht auf den gesendeten Hauscode programmiert werden. Erstaunlicherweise können mit diesem Modul auch die Codes der X10 Fernbedienung von Pollin gesendet werden. Eine Code-Sammlung gibts [[X10-codes|hier]]. [[Category:RFM12]] Getestet: * Tevion * MMANDOLYN LIBRA GmbH, Model No. WRC001 * X10 Pollin Best.Nr. 721 379 ===Intertechno (ITS-150)=== Bei Sender vom Typ Intertechno ITS-150 wird über einen Drehschalter auf der Rückseite der Familiencode eingestellt. Auf der Vorderseite gibt es einen Schieberegler für die Auswahl von Gruppe 1-4 sowie Ein/Aus Knöpfe für die Geräte 1-4 (siehe Bild). Die zusätzlich vorhandenen Gruppentaste funktioniert mit den Empfängern Intertechno CMR-500 nicht (deshalb nicht implementiert). [[Image:Intertechno-its150.jpg|150px]] ===2272=== Diese Steckdosen werden üblicherweise über einen Block von 10 DIP-Switches konfiguriert. Dabei wird mit den ersten fünf Schaltern der Hauscode gesetzt. Es ergeben sich also 32 mögliche Einstellungen. Die übrigen fünf Schalter geben die Adresse der Steckdose an. Bei Verwendung des mitgelieferten Senders wird jeweils einer der Adressschalter auf "1" gesetzt: In Dose A setzt man Dip 6 auf '1'; in Dose B Dip 7 auf '1'... Bei Ansteuerung mit dem Ethersex-System besteht diese Einschränkung nicht, so dass hier 32 verschiedene Adressen möglich sind. Getestet: {|class=wikitable |[http://www.elro.eu/uploads/products/img/_w200/AB440RA_1.jpg] |[[Image:Duewiaktor.jpg|134px]] |[[Image:Globusaktoren.jpg|134px]] |[[Image:Kangtai2605.jpg|101px]] |[[Image:Kangtai6899s.jpg|100px]] |- |valign=top|ELRO AB440R |valign=top|Düwi Modell 0369-3 |valign=top|Kangtai<br>v. Globus |valign=top|Kangtai<br>Model 2605 |valign=top|Kangtai<br>Model 6899s<br>[[Warnung vor Kangtai 6899s|'''Warnung!''']] |- |Delay 100 |Delay 60 |Delay 72 |Delay 72 |Delay 72 |} ===== Funkleuchten lassen sich auch schalten! ===== Neben den hier aufgeführten Funksteckdosen, lassen sich mit diesem Modul auch wunderbar diverse "neumodische" Funk-Leuchten, wie man sie aus Einrichtungshäusern kennt schalten. Die Fernbedienungen der Leuchten arbeiten dabei nicht mit dem 2262 Codierchip, sondern mit dem W0369DGP Codierchip. Dieser codiert genau wie der 2262 jedoch ist die Aufteilung der Codierbits (DIP-Schalter; in meinem Fall Lötbrücken) auf Hauscode und Gerätecode anders als bei den Funk Steckdosen. Die ersten 8 Codierbits sind sowohl in der Fernbedienung als auch in der Leuchte als Geräteadresse über Lötbrücken fest codiert. Dabei ist zu beachten, dass nur diese 8 Bits tri-state sind, also den Zustand "0", "1" oder "f" haben dürfen. Die weiteren 4 Bits sind die Schaltbefehle. WICHTIG: Die 4 Schalt-Bits können nur "0" oder "1" sein. === 1527 === Anlernbare Unterputz-Dimmer (zB. Pollin Funkdimmerset FD-UP003) mit Fernbedienung. Die mitgelieferte Fernbedienung besitzt einen HS1527 Encoder (baugleich RT1527/ EV1527/FP1527/SC1527). Der gesendete Code bestehtaus 24 Bits, welche per ASK gesendet werden. Davon sind die ersten 20 Bits fest programmiert - der Hauscode sozusagen. Die letzten 4 Bits sind der eigentliche Schalt-Befehl. Getestet: {|class=wikitable |[[Image:FD-UP003.jpg‎|150px|Pollin Electronic FD-UP003]] |- |valign=top|Pollin FD-UP003<br>[[Hinweis FD-UP003|'''Hinweis!''']] |} === Oase Inscenio FM Master === Das Baukastensystem für Gartensteckdosen der Serie [http://www.oase-livingwater.com/de_DE/wasser-garten/produkte/illumination-und-strom/strommanagement/inscenio.html InScenio] organisiert die gesamte Garten- und Teichtechnik. == Anschluss == == Konfiguration == == [[ECMD]] == RFM12 ASK implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle zur Steuerung von Funksteckdosen. Siehe [[ECMD_Reference|ECMD Referenz]]. 8df684d989231ada71750d032acd43321c824fbd 1180 1179 2013-10-28T19:18:14Z Pewel 720 /* Funkleuchten lassen sich auch schalten! */ wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{I/O}}->Radio->RFM12 ASK->433MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} RFM12 ASK schaltet Funksteckdosen verschiedener Hersteller. == Unterstützte Systeme == ===Tevion=== Funksteckdosen mit einer 'Anlern-Taste' können mit Hilfe des LERN-Buttons auf der embeded Website des etherrapes */rf.ht auf den gesendeten Hauscode programmiert werden. Erstaunlicherweise können mit diesem Modul auch die Codes der X10 Fernbedienung von Pollin gesendet werden. Eine Code-Sammlung gibts [[X10-codes|hier]]. [[Category:RFM12]] Getestet: * Tevion * MMANDOLYN LIBRA GmbH, Model No. WRC001 * X10 Pollin Best.Nr. 721 379 ===Intertechno (ITS-150)=== Bei Sender vom Typ Intertechno ITS-150 wird über einen Drehschalter auf der Rückseite der Familiencode eingestellt. Auf der Vorderseite gibt es einen Schieberegler für die Auswahl von Gruppe 1-4 sowie Ein/Aus Knöpfe für die Geräte 1-4 (siehe Bild). Die zusätzlich vorhandenen Gruppentaste funktioniert mit den Empfängern Intertechno CMR-500 nicht (deshalb nicht implementiert). [[Image:Intertechno-its150.jpg|150px]] ===2272=== Diese Steckdosen werden üblicherweise über einen Block von 10 DIP-Switches konfiguriert. Dabei wird mit den ersten fünf Schaltern der Hauscode gesetzt. Es ergeben sich also 32 mögliche Einstellungen. Die übrigen fünf Schalter geben die Adresse der Steckdose an. Bei Verwendung des mitgelieferten Senders wird jeweils einer der Adressschalter auf "1" gesetzt: In Dose A setzt man Dip 6 auf '1'; in Dose B Dip 7 auf '1'... Bei Ansteuerung mit dem Ethersex-System besteht diese Einschränkung nicht, so dass hier 32 verschiedene Adressen möglich sind. Getestet: {|class=wikitable |[http://www.elro.eu/uploads/products/img/_w200/AB440RA_1.jpg] |[[Image:Duewiaktor.jpg|134px]] |[[Image:Globusaktoren.jpg|134px]] |[[Image:Kangtai2605.jpg|101px]] |[[Image:Kangtai6899s.jpg|100px]] |- |valign=top|ELRO AB440R |valign=top|Düwi Modell 0369-3 |valign=top|Kangtai<br>v. Globus |valign=top|Kangtai<br>Model 2605 |valign=top|Kangtai<br>Model 6899s<br>[[Warnung vor Kangtai 6899s|'''Warnung!''']] |- |Delay 100 |Delay 60 |Delay 72 |Delay 72 |Delay 72 |} === 1527 === Anlernbare Unterputz-Dimmer (zB. Pollin Funkdimmerset FD-UP003) mit Fernbedienung. Die mitgelieferte Fernbedienung besitzt einen HS1527 Encoder (baugleich RT1527/ EV1527/FP1527/SC1527). Der gesendete Code bestehtaus 24 Bits, welche per ASK gesendet werden. Davon sind die ersten 20 Bits fest programmiert - der Hauscode sozusagen. Die letzten 4 Bits sind der eigentliche Schalt-Befehl. Getestet: {|class=wikitable |[[Image:FD-UP003.jpg‎|150px|Pollin Electronic FD-UP003]] |- |valign=top|Pollin FD-UP003<br>[[Hinweis FD-UP003|'''Hinweis!''']] |} === Oase Inscenio FM Master === Das Baukastensystem für Gartensteckdosen der Serie [http://www.oase-livingwater.com/de_DE/wasser-garten/produkte/illumination-und-strom/strommanagement/inscenio.html InScenio] organisiert die gesamte Garten- und Teichtechnik. == Anschluss == == Konfiguration == == [[ECMD]] == RFM12 ASK implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle zur Steuerung von Funksteckdosen. Siehe [[ECMD_Reference|ECMD Referenz]]. cc9373013c942267dadd62d4d1dc0664856e1bcb 1181 1180 2013-10-28T19:20:30Z Pewel 720 /* 2272 */ wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{I/O}}->Radio->RFM12 ASK->433MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} RFM12 ASK schaltet Funksteckdosen verschiedener Hersteller. == Unterstützte Systeme == ===Tevion=== Funksteckdosen mit einer 'Anlern-Taste' können mit Hilfe des LERN-Buttons auf der embeded Website des etherrapes */rf.ht auf den gesendeten Hauscode programmiert werden. Erstaunlicherweise können mit diesem Modul auch die Codes der X10 Fernbedienung von Pollin gesendet werden. Eine Code-Sammlung gibts [[X10-codes|hier]]. [[Category:RFM12]] Getestet: * Tevion * MMANDOLYN LIBRA GmbH, Model No. WRC001 * X10 Pollin Best.Nr. 721 379 ===Intertechno (ITS-150)=== Bei Sender vom Typ Intertechno ITS-150 wird über einen Drehschalter auf der Rückseite der Familiencode eingestellt. Auf der Vorderseite gibt es einen Schieberegler für die Auswahl von Gruppe 1-4 sowie Ein/Aus Knöpfe für die Geräte 1-4 (siehe Bild). Die zusätzlich vorhandenen Gruppentaste funktioniert mit den Empfängern Intertechno CMR-500 nicht (deshalb nicht implementiert). [[Image:Intertechno-its150.jpg|150px]] ===2272=== Diese Steckdosen werden üblicherweise über einen Block von 10 DIP-Switches konfiguriert. Dabei wird mit den ersten fünf Schaltern der Hauscode gesetzt. Es ergeben sich also 32 mögliche Einstellungen. Die übrigen fünf Schalter geben die Adresse der Steckdose an. Bei Verwendung des mitgelieferten Senders wird jeweils einer der Adressschalter auf "1" gesetzt: In Dose A setzt man Dip 6 auf '1'; in Dose B Dip 7 auf '1'... Bei Ansteuerung mit dem Ethersex-System besteht diese Einschränkung nicht, so dass hier 32 verschiedene Adressen möglich sind. Getestet: {|class=wikitable |[http://www.elro.eu/uploads/products/img/_w200/AB440RA_1.jpg] |[[Image:Duewiaktor.jpg|134px]] |[[Image:Globusaktoren.jpg|134px]] |[[Image:Kangtai2605.jpg|101px]] |[[Image:Kangtai6899s.jpg|100px]] |- |valign=top|ELRO AB440R |valign=top|Düwi Modell 0369-3 |valign=top|Kangtai<br>v. Globus |valign=top|Kangtai<br>Model 2605 |valign=top|Kangtai<br>Model 6899s<br>[[Warnung vor Kangtai 6899s|'''Warnung!''']] |- |Delay 100 |Delay 60 |Delay 72 |Delay 72 |Delay 72 |} ====Funkleuchten lassen sich auch schalten!==== Neben den hier aufgeführten Funksteckdosen, lassen sich mit diesem Modul auch wunderbar diverse "neumodische" Funk-Leuchten, wie man sie aus Einrichtungshäusern kennt schalten. Die Fernbedienungen der Leuchten arbeiten dabei nicht mit dem 2262 Codierchip, sondern mit dem W0369DGP Codierchip. Dieser codiert genau wie der 2262 jedoch ist die Aufteilung der Codierbits (DIP-Schalter; in meinem Fall Lötbrücken) auf Hauscode und Gerätecode anders als bei den Funk Steckdosen. Die ersten 8 Codierbits sind sowohl in der Fernbedienung als auch in der Leuchte als Geräteadresse über Lötbrücken fest codiert. Dabei ist zu beachten, dass nur diese 8 Bits tri-state sind, also den Zustand "0", "1" oder "f" haben dürfen. Die weiteren 4 Bits sind die Schaltbefehle. WICHTIG: Die 4 Schalt-Bits können nur "0" oder "1" sein. === 1527 === Anlernbare Unterputz-Dimmer (zB. Pollin Funkdimmerset FD-UP003) mit Fernbedienung. Die mitgelieferte Fernbedienung besitzt einen HS1527 Encoder (baugleich RT1527/ EV1527/FP1527/SC1527). Der gesendete Code bestehtaus 24 Bits, welche per ASK gesendet werden. Davon sind die ersten 20 Bits fest programmiert - der Hauscode sozusagen. Die letzten 4 Bits sind der eigentliche Schalt-Befehl. Getestet: {|class=wikitable |[[Image:FD-UP003.jpg‎|150px|Pollin Electronic FD-UP003]] |- |valign=top|Pollin FD-UP003<br>[[Hinweis FD-UP003|'''Hinweis!''']] |} === Oase Inscenio FM Master === Das Baukastensystem für Gartensteckdosen der Serie [http://www.oase-livingwater.com/de_DE/wasser-garten/produkte/illumination-und-strom/strommanagement/inscenio.html InScenio] organisiert die gesamte Garten- und Teichtechnik. == Anschluss == == Konfiguration == == [[ECMD]] == RFM12 ASK implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle zur Steuerung von Funksteckdosen. Siehe [[ECMD_Reference|ECMD Referenz]]. bf39b6d474f841b99c50ea0c9d50bc58a92b043c 0 341 1186 1000 2013-11-14T07:12:37Z GooPie4o 265 /* Configuration */ wikitext text/x-wiki {{i18n|DHT}} {{Module |NAME=DHT |MENUCONFIG={{I/O}}->Humidity & temperature sensors->DHT 11/22 |STATUS={{Experimental}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/dht https://github.com/ethersex/ethersex/tree/master/hardware/dht] }} ==== DHT11/DHT21/DHT22 etc. Temperature & Humidity sensors ==== These sensors are very basic and slow, but are great for hobbyists who want to do some basic data logging. The DHT sensors are made of two parts, a capacitive humidity sensor and a thermistor. There is also a very basic chip inside that does some analog to digital conversion and spits out a digital signal with the temperature and humidity. ==== DHT11 vs DHT22 ==== There are two versions of the DHT sensor available, they look a bit similar and have the same pinout, but have different characteristics. Here are the specs: DHT11 * Ultra low cost * 3 to 5V power and I/O * 2.5mA max current use during conversion (while requesting data) * Good for 20-80% humidity readings with 5% accuracy * Good for 0-50°C temperature readings ±2°C accuracy * No more than 1 Hz sampling rate (once every second) * Body size 15.5mm x 12mm x 5.5mm * 4 pins with 0.1" spacing DHT22 * Low cost * 3 to 5V power and I/O * 2.5mA max current use during conversion (while requesting data) * Good for 0-100% humidity readings with 2-5% accuracy * Good for -40 to 125°C temperature readings ±0.5°C accuracy * No more than 0.5 Hz sampling rate (once every 2 seconds) * Body size 15.1mm x 25mm x 7.7mm * 4 pins with 0.1" spacing == Connection == Likewise, it is fairly easy to connect up to the DHT sensors. They have four pins # VCC (3 to 5V power) # Data out # Not connected # Ground Simply ignore pin 3, it is not used. You will want to place a 10K resistor between VCC and the data pin, to act as a medium-strength pull up on the data line. The data out can be connected to any port pin of the ATmega, i.e. PA0 as listed in the pinning example: ifdef(`conf_DHT', `dnl pin(DHT, PA0, INPUT) ') == Configuration == Ethersex polls the sensors every n seconds. The advantage of this feature is that the reading opererates without any noticeable lags. Also it is easier to have multiple applications requesting sensor information since more request will not increase traffic. | | I/O ---> ... [*] Humidity & temperature sensors ---> ... [*] DHT 11/22 ---> | | (DHT11) Sensor type | | (30) Time between polling in 1s steps | | --- Debugging Flags | | [ ] DHT == [[ECMD]] == DHT implements an [[ECMD]] interface for reading humidity and temperature values. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == Humidity and temperature can be accessed in [[Control6]] scripts through the DHT_HUMIDITY and DHT_TEMPERATURE keywords. The values returnd are fixed point integers including one decimal. The following example calculates and outputs the dew point on a LCD once every minute. <source lang="text"> #include <stdio.h> #include <math.h> #include "hardware/lcd/hd44780.h" CONTROL_START THREAD(read_dht) ON ONCE CLOCK_SEC == 0 DO float a = 17.271; float b = 237.7; float temperatur = (a * DHT_TEMPERATURE) / (b + DHT_TEMPERATURE) + log(DHT_HUMIDITY/100); float taupunkt = (b * temperatur) / (a - temperatur); hd44780_clear(); hd44780_home(); fprintf_P(&lcd, PSTR("Taupunkt: %f"), taupunkt); END THREAD_END(read_dht) ON STARTUP DO THREAD_START(read_dht); END CONTROL_END </source> [[Category:Sensors]] 9da08863e31e28058a505ec2728b1cd22b1af0e4 1187 1186 2013-11-14T07:20:39Z GooPie4o 265 /* Control6 */ wikitext text/x-wiki {{i18n|DHT}} {{Module |NAME=DHT |MENUCONFIG={{I/O}}->Humidity & temperature sensors->DHT 11/22 |STATUS={{Experimental}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/dht https://github.com/ethersex/ethersex/tree/master/hardware/dht] }} ==== DHT11/DHT21/DHT22 etc. Temperature & Humidity sensors ==== These sensors are very basic and slow, but are great for hobbyists who want to do some basic data logging. The DHT sensors are made of two parts, a capacitive humidity sensor and a thermistor. There is also a very basic chip inside that does some analog to digital conversion and spits out a digital signal with the temperature and humidity. ==== DHT11 vs DHT22 ==== There are two versions of the DHT sensor available, they look a bit similar and have the same pinout, but have different characteristics. Here are the specs: DHT11 * Ultra low cost * 3 to 5V power and I/O * 2.5mA max current use during conversion (while requesting data) * Good for 20-80% humidity readings with 5% accuracy * Good for 0-50°C temperature readings ±2°C accuracy * No more than 1 Hz sampling rate (once every second) * Body size 15.5mm x 12mm x 5.5mm * 4 pins with 0.1" spacing DHT22 * Low cost * 3 to 5V power and I/O * 2.5mA max current use during conversion (while requesting data) * Good for 0-100% humidity readings with 2-5% accuracy * Good for -40 to 125°C temperature readings ±0.5°C accuracy * No more than 0.5 Hz sampling rate (once every 2 seconds) * Body size 15.1mm x 25mm x 7.7mm * 4 pins with 0.1" spacing == Connection == Likewise, it is fairly easy to connect up to the DHT sensors. They have four pins # VCC (3 to 5V power) # Data out # Not connected # Ground Simply ignore pin 3, it is not used. You will want to place a 10K resistor between VCC and the data pin, to act as a medium-strength pull up on the data line. The data out can be connected to any port pin of the ATmega, i.e. PA0 as listed in the pinning example: ifdef(`conf_DHT', `dnl pin(DHT, PA0, INPUT) ') == Configuration == Ethersex polls the sensors every n seconds. The advantage of this feature is that the reading opererates without any noticeable lags. Also it is easier to have multiple applications requesting sensor information since more request will not increase traffic. | | I/O ---> ... [*] Humidity & temperature sensors ---> ... [*] DHT 11/22 ---> | | (DHT11) Sensor type | | (30) Time between polling in 1s steps | | --- Debugging Flags | | [ ] DHT == [[ECMD]] == DHT implements an [[ECMD]] interface for reading humidity and temperature values. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == Humidity and temperature can be accessed in [[Control6]] scripts through the DHT_HUMIDITY and DHT_TEMPERATURE keywords. The values returnd are fixed point integers including one decimal. The following example calculates and outputs the dew point on a LCD once every minute. '''To output floating point values the floating point printf version is required (Makefile: LDFLAGS += -Wl,-u,vfprintf -lprintf_flt -lm).''' <source lang="text"> #include <stdio.h> #include <math.h> #include "hardware/lcd/hd44780.h" CONTROL_START THREAD(read_dht) ON ONCE CLOCK_SEC == 0 DO float a = 17.271; float b = 237.7; float temperatur = (a * DHT_TEMPERATURE) / (b + DHT_TEMPERATURE) + log(DHT_HUMIDITY/100); float taupunkt = (b * temperatur) / (a - temperatur); hd44780_clear(); hd44780_home(); fprintf_P(&lcd, PSTR("Taupunkt: %f"), taupunkt); END THREAD_END(read_dht) ON STARTUP DO THREAD_START(read_dht); END CONTROL_END </source> [[Category:Sensors]] 56df405aca3805293c2320130e86dc3e4ca2cfaf 0 35 1188 396 2013-11-18T09:41:48Z GooPie4o 265 /* Current Reply List */ wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or any other incompatible licesne. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or any other incompatible license. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! GPLv3 -> GPLv3+ !! Ethersex decides |- |Güntner, Maximilian || YES || YES || YES || YES || NO || NO |- |Kunze, Erik || YES || YES || YES || YES || NO || NO |- |Riegel, Roland || NO || NO || NO || NO || NO || NO |- |Neumann, Alexander: onewire.* (Nov 16 18:50:10 2013) || NO || NO || NO || NO || YES || NO |- |} == Current TODO List == * collect files with incompatible license. {| border="1" ! File !! License !! Status |- | core/gui/font.c || 3-clause BSD || OK |- | core/host/host.h || unknown || OK empty file - does not need a license |- | core/host/util/crc16.h || no license, has to be 3-clause BSD || File is a partial copy of util/crc16.h, so we should use the 3-clause BSD for that file |- | core/setbaud.h || 3-clause BSD || removed - use utils/setbaud.h from avrlibc |- | hardware/ir/irmp/irmp_lib.c || GPLv2+ || OK |- | hardware/lcd/s1d15g10/bunnies.h || GPLv2+ assumed || OK |- | hardware/lcd/ST7626/4x6.h || GPLv3+ || not replied, OK - we can assume GPLv3+ because of ST7626.c |- | hardware/lcd/ST7626/ST7626.h || GPLv3+ || not replied, OK - we can assume GPLv3+ because of ST7626.c |- | hardware/sram/sram.h || GPLv2+ || OK - we can assume GPLv2+ because of sram.c |- | hardware/storage/sd_reader/byteordering.* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/fat* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/partition* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/sd_raw* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/sd-reader_config.h || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | protocols/bootp/bootphdr.h || MIT || OK |- | protocols/uip/uip-conf.h || BSD || OK - license and copyright disappeared with 7c2045a0b3e67b53a12e74a337abb124ee0c55bf |- | protocols/usb/usbconfig.h || GPLv2 or v3 || OK, see the included protocols/usb/usbdrv/License.txt |- | protocols/ustream/vs1053.c || unknown || contacted 4.11.11, replied - agreed on MIT |- | protocols/ustream/vs1053.h || unknown || contacted 4.11.11, replied - agreed on MIT |- | services/glcdmenu/menu-interpreter/menudata-progmem.c || unknown || contacted 4.11.11, generated code - no need to license |- | services/glcdmenu/menu-interpreter/menu-interpreter-config.h || unknown || contacted 4.11.11, generated code - no need to license |- |} to find out all the authors of a certain file, run ''contrib/license-lister file'' . e.g. ''contrib/license-lister protocols/bootp/bootphdr.h'' * send an email to authors of source files with incompatible license == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD * Adam Dunkels' uIP Stack is licensed under the BSD http://en.wikipedia.org/wiki/UIP_(micro_IP) https://github.com/ethersex/ethersex/blob/master/protocols/uip/uip.c#L25 * MIT/X is compatible with GPLv3 ** http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing * reintegrate SD Reader library from http://www.roland-riegel.de/sd-reader/ ** done https://github.com/ethersex/ethersex/commit/0ba2a832b2f0e16e78cb26202b5e4fe4e266614b * reintegrate V-USB from http://www.obdev.at/products/vusb/download.html ** done https://github.com/ethersex/ethersex/commit/87c4d2b07c3939bf43779714d3b1cbcacd6848b3 b0976fd48a670126f446fd0cb84c84beadfee5fd 1189 1188 2013-11-18T09:43:45Z GooPie4o 265 /* Current Reply List */ wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or any other incompatible licesne. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or any other incompatible license. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! GPLv3 -> GPLv3+ !! Ethersex decides !! Code !! Date |- |Güntner, Maximilian || YES || YES || YES || YES || NO || NO || ALL || N/A |- |Kunze, Erik || YES || YES || YES || YES || NO || NO || ALL || N/A |- |Riegel, Roland || NO || NO || NO || NO || NO || NO || sd_reader || N/A |- |Neumann, Alexander || NO || NO || NO || NO || YES || NO || onewire.* || Nov 16 18:50:10 2013 |- |} == Current TODO List == * collect files with incompatible license. {| border="1" ! File !! License !! Status |- | core/gui/font.c || 3-clause BSD || OK |- | core/host/host.h || unknown || OK empty file - does not need a license |- | core/host/util/crc16.h || no license, has to be 3-clause BSD || File is a partial copy of util/crc16.h, so we should use the 3-clause BSD for that file |- | core/setbaud.h || 3-clause BSD || removed - use utils/setbaud.h from avrlibc |- | hardware/ir/irmp/irmp_lib.c || GPLv2+ || OK |- | hardware/lcd/s1d15g10/bunnies.h || GPLv2+ assumed || OK |- | hardware/lcd/ST7626/4x6.h || GPLv3+ || not replied, OK - we can assume GPLv3+ because of ST7626.c |- | hardware/lcd/ST7626/ST7626.h || GPLv3+ || not replied, OK - we can assume GPLv3+ because of ST7626.c |- | hardware/sram/sram.h || GPLv2+ || OK - we can assume GPLv2+ because of sram.c |- | hardware/storage/sd_reader/byteordering.* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/fat* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/partition* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/sd_raw* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/sd-reader_config.h || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | protocols/bootp/bootphdr.h || MIT || OK |- | protocols/uip/uip-conf.h || BSD || OK - license and copyright disappeared with 7c2045a0b3e67b53a12e74a337abb124ee0c55bf |- | protocols/usb/usbconfig.h || GPLv2 or v3 || OK, see the included protocols/usb/usbdrv/License.txt |- | protocols/ustream/vs1053.c || unknown || contacted 4.11.11, replied - agreed on MIT |- | protocols/ustream/vs1053.h || unknown || contacted 4.11.11, replied - agreed on MIT |- | services/glcdmenu/menu-interpreter/menudata-progmem.c || unknown || contacted 4.11.11, generated code - no need to license |- | services/glcdmenu/menu-interpreter/menu-interpreter-config.h || unknown || contacted 4.11.11, generated code - no need to license |- |} to find out all the authors of a certain file, run ''contrib/license-lister file'' . e.g. ''contrib/license-lister protocols/bootp/bootphdr.h'' * send an email to authors of source files with incompatible license == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD * Adam Dunkels' uIP Stack is licensed under the BSD http://en.wikipedia.org/wiki/UIP_(micro_IP) https://github.com/ethersex/ethersex/blob/master/protocols/uip/uip.c#L25 * MIT/X is compatible with GPLv3 ** http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing * reintegrate SD Reader library from http://www.roland-riegel.de/sd-reader/ ** done https://github.com/ethersex/ethersex/commit/0ba2a832b2f0e16e78cb26202b5e4fe4e266614b * reintegrate V-USB from http://www.obdev.at/products/vusb/download.html ** done https://github.com/ethersex/ethersex/commit/87c4d2b07c3939bf43779714d3b1cbcacd6848b3 9559ff16c5c080cf0a08ef98e502c8da4fb16ee5 1190 1189 2013-11-18T09:45:45Z GooPie4o 265 /* Ethersex Relicensing Effort */ wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or any other incompatible license. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or any other incompatible license. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! GPLv3 -> GPLv3+ !! Ethersex decides !! Code !! Date |- |Güntner, Maximilian || YES || YES || YES || YES || NO || NO || ALL || N/A |- |Kunze, Erik || YES || YES || YES || YES || NO || NO || ALL || N/A |- |Riegel, Roland || NO || NO || NO || NO || NO || NO || sd_reader || N/A |- |Neumann, Alexander || NO || NO || NO || NO || YES || NO || onewire.* || Nov 16 18:50:10 2013 |- |} == Current TODO List == * collect files with incompatible license. {| border="1" ! File !! License !! Status |- | core/gui/font.c || 3-clause BSD || OK |- | core/host/host.h || unknown || OK empty file - does not need a license |- | core/host/util/crc16.h || no license, has to be 3-clause BSD || File is a partial copy of util/crc16.h, so we should use the 3-clause BSD for that file |- | core/setbaud.h || 3-clause BSD || removed - use utils/setbaud.h from avrlibc |- | hardware/ir/irmp/irmp_lib.c || GPLv2+ || OK |- | hardware/lcd/s1d15g10/bunnies.h || GPLv2+ assumed || OK |- | hardware/lcd/ST7626/4x6.h || GPLv3+ || not replied, OK - we can assume GPLv3+ because of ST7626.c |- | hardware/lcd/ST7626/ST7626.h || GPLv3+ || not replied, OK - we can assume GPLv3+ because of ST7626.c |- | hardware/sram/sram.h || GPLv2+ || OK - we can assume GPLv2+ because of sram.c |- | hardware/storage/sd_reader/byteordering.* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/fat* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/partition* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/sd_raw* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/sd-reader_config.h || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | protocols/bootp/bootphdr.h || MIT || OK |- | protocols/uip/uip-conf.h || BSD || OK - license and copyright disappeared with 7c2045a0b3e67b53a12e74a337abb124ee0c55bf |- | protocols/usb/usbconfig.h || GPLv2 or v3 || OK, see the included protocols/usb/usbdrv/License.txt |- | protocols/ustream/vs1053.c || unknown || contacted 4.11.11, replied - agreed on MIT |- | protocols/ustream/vs1053.h || unknown || contacted 4.11.11, replied - agreed on MIT |- | services/glcdmenu/menu-interpreter/menudata-progmem.c || unknown || contacted 4.11.11, generated code - no need to license |- | services/glcdmenu/menu-interpreter/menu-interpreter-config.h || unknown || contacted 4.11.11, generated code - no need to license |- |} to find out all the authors of a certain file, run ''contrib/license-lister file'' . e.g. ''contrib/license-lister protocols/bootp/bootphdr.h'' * send an email to authors of source files with incompatible license == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD * Adam Dunkels' uIP Stack is licensed under the BSD http://en.wikipedia.org/wiki/UIP_(micro_IP) https://github.com/ethersex/ethersex/blob/master/protocols/uip/uip.c#L25 * MIT/X is compatible with GPLv3 ** http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing * reintegrate SD Reader library from http://www.roland-riegel.de/sd-reader/ ** done https://github.com/ethersex/ethersex/commit/0ba2a832b2f0e16e78cb26202b5e4fe4e266614b * reintegrate V-USB from http://www.obdev.at/products/vusb/download.html ** done https://github.com/ethersex/ethersex/commit/87c4d2b07c3939bf43779714d3b1cbcacd6848b3 3b12c7d360221be1881639590c414c7130035461 1191 1190 2013-11-18T09:46:51Z GooPie4o 265 /* How can I help? */ wikitext text/x-wiki == Ethersex Relicensing Effort == === Why does it matter? === Ethersex is licensed unter GPLv3, but a few parts are currently licensed as GPLv2 only or any other incompatible license. However, we still need to validate with the individual copyright holders that a relicense to GPLv2+ or GPLv2+v3 is okay with them. Therefore, in an effort we're trying to identify the contributors that have contributed under the terms of GPLv2 and where the "+" part was not explicitly mentioned or any other incompatible license. If we know that all contributors agreed to a relicense, we can go ahead and flip the license of the individual source file. == How can I help? == By identifying a contributor who as contributed under the terms of GPLv2, and contacting him if he wasn't already contacted. Ask him the following questions: * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or later"? * Are you okay with relicensing your contributions done under "GPLv2" to "GPLv2 or GPLv3" ? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or later"? * Are you okay with relicensing your contributions done under "LGPLv2" to "LGPLv2 or LGPLv3"? * Are you okay with relicensing your contributions done under "GPLv3" to "GPLv3+"? * Are you okay with the Ethersex maintainer deciding on a future licensing change to your code, should that be necessary? === What's next? === # checkout ethersex # run the script ''contrib/license-lister'' # you interpret the result. check each commit that is being complained about carefully. Try to get the copyright's holder's permission. If you get it, update the whitelist in the script. # review the list of declared copyright holders in the file. # if you're all clear, change the license to the most liberal license possible. Document your change verbosely in the git commit log. == Current Reply List == * Please keep the list sorted by family name! * Please only use "YES" or "NO" {| border="1" ! Name !! GPLv2->GPLv2+ !! LGPLv2 -> LGPLv2+ !! GPLv2 -> GPLv2+v3 !! LGPLv2 -> LGPLv2+LGPLv3 !! GPLv3 -> GPLv3+ !! Ethersex decides !! Code !! Date |- |Güntner, Maximilian || YES || YES || YES || YES || NO || NO || ALL || N/A |- |Kunze, Erik || YES || YES || YES || YES || NO || NO || ALL || N/A |- |Riegel, Roland || NO || NO || NO || NO || NO || NO || sd_reader || N/A |- |Neumann, Alexander || NO || NO || NO || NO || YES || NO || onewire.* || Nov 16 18:50:10 2013 |- |} == Current TODO List == * collect files with incompatible license. {| border="1" ! File !! License !! Status |- | core/gui/font.c || 3-clause BSD || OK |- | core/host/host.h || unknown || OK empty file - does not need a license |- | core/host/util/crc16.h || no license, has to be 3-clause BSD || File is a partial copy of util/crc16.h, so we should use the 3-clause BSD for that file |- | core/setbaud.h || 3-clause BSD || removed - use utils/setbaud.h from avrlibc |- | hardware/ir/irmp/irmp_lib.c || GPLv2+ || OK |- | hardware/lcd/s1d15g10/bunnies.h || GPLv2+ assumed || OK |- | hardware/lcd/ST7626/4x6.h || GPLv3+ || not replied, OK - we can assume GPLv3+ because of ST7626.c |- | hardware/lcd/ST7626/ST7626.h || GPLv3+ || not replied, OK - we can assume GPLv3+ because of ST7626.c |- | hardware/sram/sram.h || GPLv2+ || OK - we can assume GPLv2+ because of sram.c |- | hardware/storage/sd_reader/byteordering.* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/fat* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/partition* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/sd_raw* || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | hardware/storage/sd_reader/sd-reader_config.h || GPLv2/LGPLv2.1 || contacted 31.10.11, replied - [http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses compatible] |- | protocols/bootp/bootphdr.h || MIT || OK |- | protocols/uip/uip-conf.h || BSD || OK - license and copyright disappeared with 7c2045a0b3e67b53a12e74a337abb124ee0c55bf |- | protocols/usb/usbconfig.h || GPLv2 or v3 || OK, see the included protocols/usb/usbdrv/License.txt |- | protocols/ustream/vs1053.c || unknown || contacted 4.11.11, replied - agreed on MIT |- | protocols/ustream/vs1053.h || unknown || contacted 4.11.11, replied - agreed on MIT |- | services/glcdmenu/menu-interpreter/menudata-progmem.c || unknown || contacted 4.11.11, generated code - no need to license |- | services/glcdmenu/menu-interpreter/menu-interpreter-config.h || unknown || contacted 4.11.11, generated code - no need to license |- |} to find out all the authors of a certain file, run ''contrib/license-lister file'' . e.g. ''contrib/license-lister protocols/bootp/bootphdr.h'' * send an email to authors of source files with incompatible license == Relicensing progress == * reintegrate avr-crypto-lib from http://www.das-labor.org/wiki/AVR-Crypto-Lib ** done https://github.com/ethersex/ethersex/commit/09cf68410180bad2e22bd4a26a1b319b1e5ecb25 * clarify if files under BSD license need to be relicensed ** new BSD license is GPLv3 compatible http://www.gnu.org/licenses/gpl-faq.html#OrigBSD * Adam Dunkels' uIP Stack is licensed under the BSD http://en.wikipedia.org/wiki/UIP_(micro_IP) https://github.com/ethersex/ethersex/blob/master/protocols/uip/uip.c#L25 * MIT/X is compatible with GPLv3 ** http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing * reintegrate SD Reader library from http://www.roland-riegel.de/sd-reader/ ** done https://github.com/ethersex/ethersex/commit/0ba2a832b2f0e16e78cb26202b5e4fe4e266614b * reintegrate V-USB from http://www.obdev.at/products/vusb/download.html ** done https://github.com/ethersex/ethersex/commit/87c4d2b07c3939bf43779714d3b1cbcacd6848b3 d958fef712ab00041726322aee39c6ab81e9b4fd 0 367 1192 1095 2013-11-27T11:58:10Z Dg9oaa 103 wikitext text/x-wiki {{i18n|Rotor}} {{Module |NAME=Rotor Steuerung |MENUCONFIG={{I/O}}->Rotor via HamLib |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] (optional) |REQUIRES= - |CODE=[?] }} Die Rotor Steuerung kann per ECMD Kommandos angesprochen werden. Zur primären Verwendung kommt der HAM 4. Dieser Rotor besitzt eine mechanische Bremse. Um ihn zu drehen benötigte der Rotor die Freigabe der Bremse und die Drehrichtung (cw oder ccw). == Pinning == Die drei Ausgänge CW, CCW, und BREAK weden in der Datei ''pinning/hardware/<your board>.m4'' beschrieben. ifdef(`conf_ROTORHAMLIB', ` pin(ROTOR_CW, PC3, OUTPUT) pin(ROTOR_CCW, PC4, OUTPUT) pin(ROTOR_BREAK, PC5, OUTPUT) ') Für den Analogwert wird AD Wandler 0 (bzw. der erste) verwendet == Konfiguration == Über den ersten AD Wandler wird die Richtung/Winkel des Rotors ermittelt. Bei den meisten Rotoren wird ein Potentiometer zur Richtungsanzeige verwendet. Diese Spannung wird abgegriffen und dem AD Wandler zu geführt. Achtung, der AD Wandler läuft nur zwischen 0 bis 5 Volt. Meist ist die/der Spannung/Widerstand bei einem Winkel von 0 Grad nicht Null sondern etwas höher. Um der Steuerung mitzuteilen bei welchem Eingangspegel 0 Grad und 360 Grad ist, kann der AD Wert für 0 und 360 Grad gespeichert werden. Der Rotor wird von Hand auf 0 Grad gedreht und mittels Kommando 'rotor status' wird der AD Wandler Wert abgefragt und notiert. Nachdem der Rotor auch bei 360 Grad seinen Status ausgegeben hat, werden beide Werte per Kommando 'rotor calibrate min max' im EEPROM abgespeichert. * Ein Beispiel rotor calibrate 75 950 (maximal Wert ist 1023) == Steuergerät vom Ham4 == [[File:RotorSG1.jpg|vor dem Einbau|300px]] == Ansteuerung von Hamlib == Das OpenSource Projekt Hamlib [https://sourceforge.net/apps/mediawiki/hamlib/index.php?title=Main_Page] bietet Software zum Steuern des Rotor Interfaces. An den Hamlib-rotctld können viele Amateurfunk Software Hilfsprogramme angebunden werden. Der rotctld ist ein Geschwister vom rigctld. Der rigctld kann die Funkgeräte über die CAT Schnittstelle fernsteuern. GPredict steuert bei mir meinen Rotor. * rotctld -m 1501 -r towerio:2701 -T freebsd Das Argument -m 1501 spezifiziert das Ethersex-Interface -r towerio:2701 gibt den Host und den Port des Ethersex Boards an -T gibt die lokale IP-Adresse an / zwingt rotctl(d) auf IP4 bzw. IP6 == ECMD Commands == {| border=1 cellspacing=0 padding=4 class=wikitable ! width="25%" | Command ! Function |- |rotor ''move''|| Angabe von Winkel und Geschwindigkeit in % |- |- |rotor ''status''|| gibt Drehrichtung, Winkel und Geschwindigkeit aus |- |- |rotor ''cw''|| dreht den Rotor im Uhrzeigersinn |- |- |rotor ''ccw''|| dreht den Rotor gegen den Uhrzeigersinn |- |- |rotor ''stop''|| hält den Rotor sofort an |- |- |rotor ''park''|| dreht den Rotor in die Park Position |- |- |rotor ''setparkpos''|| Speicherung der Park Position als Winkel (0-360) |- |- |rotor ''calibrate''|| Angabe der min und max Grenzwerte für die Analog-Digital Wandlung |- |- |rotor ''get calibrate''|| gibt die Grenzwerte aus |- |- e3e61d36b53fedd5fbca71b26e100359219ccbaf 6 380 1193 2013-12-08T16:43:54Z GooPie4o 265 picture of sdcard adapter available from china via eBay wikitext text/x-wiki picture of sdcard adapter available from china via eBay c0ebc330ac754649949ea3bb2b636da12018ed9d 0 360 1196 1076 2013-12-19T08:39:50Z GooPie4o 265 wikitext text/x-wiki {{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader] }} The module is based on Roland Riegel's [http://www.roland-riegel.de/sd-reader/ MMC/SD/SDHC card library] complemented by the connection to the Ethersex [[VFS|Virtual File System]]. == Connection == [[File:Sdcard adapter schaltung.png|200px|thumb|right|SD-Card Adapter Schaltung]] [[File:Sdcard adapter.jpg|200px|thumb|right|SD-Card Adapter Aufbau]] [[File:Microsd_adapter.jpg|200px|thumb|right|MicroSD-Card Adapter mit Level-Shifter aus China]] == Configuration == | | I/O ---> | | ... │ │ Storage ---> │ │ ... | | [*] SD/MMC-Card Reader ---> | | ... | | [ ] SDHC support | | | | [*] VFAT LFN support | | | | [ ] Read-only mode | | | | [*] Use read-timeout | | | | [*] Ping-read SD card every 10s | | | | --- ECMD Support | | | | [*] info | | | | [*] dir | | | | [*] mkdir | | | | [*] rm | | | | --- Debugging Flags | | | | [*] FAT | | | | [*] RAW | | | | [*] VFS | | | | General Setup ---> | | ... | | [*] VFS (Virtual File System) support ---> | | ... | | [*] SD/MMC-Card Filesystem | | == [[ECMD|ECMD]] == IRMP implements an [[ECMD]] interface. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == The following example writes the date, time and temperature by VFS_LOG_ALLOCA (VFS_LOG requires UIP) in the file "temp.log" as soon as the temperature has changed by more than a degree to the last measurement. For date and time CLOCK_SUPPORT must be enabled. <pre> #include <stdlib.h> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO uint8_t sign = Temperatur<0; div_t res = div(abs(Temperatur),10); VFS_LOG_ALLOCA("temp.log", 50, "%2d.%2d.%4d %2d:%02d %S%d.%d", CLOCK_DAY, CLOCK_MONTH, CLOCK_YEAR, CLOCK_HOUR, CLOCK_MIN, sign?PSTR("-"):PSTR(""),res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> f9751c95ed486b7622df86d6fae05daa4cc1a2b1 1197 1196 2013-12-19T08:48:36Z GooPie4o 265 /* Connection */ wikitext text/x-wiki {{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader] }} The module is based on Roland Riegel's [http://www.roland-riegel.de/sd-reader/ MMC/SD/SDHC card library] complemented by the connection to the Ethersex [[VFS|Virtual File System]]. == Connection == [[File:Sdcard adapter schaltung.png|200px|thumb|right|SD-Card Adapter Schaltung]] [[File:Sdcard adapter.jpg|200px|thumb|right|SD-Card Adapter Aufbau]] [[File:Microsd_adapter.jpg|200px|thumb|right|MicroSD-Card Adapter mit Level-Shifter aus China]] MMC and SD memory cards can be used in [[SPI]] mode relatively easily controlled with a microcontroller. In principle, there is not between SD Card and MMC many differences, but SD cards are more common, generally faster than MMCs, and have a better-implemented SPI interface. There are several variants (miniSD, microSD), which are largely compatible with the standard SD-card. The card reads the adjacent data bits with the rising clock edge, as [[SPI]] modes are thus suitable Mode 0 and Mode 3 In MMCs, the SPI mode is not precisely specified, so it does happen sometimes that the SPI mode must be selected differ depending on the card. SD cards are typically often operated with 3.3V and 5V microcontrollers. This forces a [http://www.mikrocontroller.net/articles/Pegelwandler#5V_.3C-.3E_3.3V level adjustment], because the input lines to the SD card are not 5V tolerant. [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#Bekannte_Fehler A level adjustment] with resistors is not recommended. In addition to the lines leading to the SD card, there are two other lines which lead to the SD card socket: namely, the card-detect line and the write-protect line. They serve as the name already say, to signal the physical presence of a card in the SD socket and the position of the write protect switch. If hardware SPI used, only the chip select line must be configured. The card-detect line and the write-protect line are optional and MicroSD anyway not exist. ifdef(`conf_SD_READER', ` /* port the sd-reader CS is attached to */ pin(SPI_CS_SD_READER, PB2, OUTPUT) /* uncomment and edit this if you have connected the CD (card detect) signal */ pin(SD_READER_AVAILABLE, PD4, INPUT) /* uncomment and edit this if you have connected the WP (write protected) signal */ pin(SD_READER_WR_PROTECT, PD5, INPUT) ') Another problem with the SD card is the initialization. Manages Ethersex not in a certain time to sync, so the card into the normal drops (not the SD) mode and can no longer be addressed. A solution for this is that the card receives a controllable power supply. For this purpose, we define the pinning only pin pin(SD_READER_POWERON, PB3, OUTPUT) === Connector === A cheap type of contact is probably cannibalizing a cheap card reader if you want to solder any cables directly to the card. Individually purchased connectors can usually considerably teuerer. Even [http://uanr.com/sdfloppy/ old floppy cable] can be used as cheap connectors. Parts of AT slots or connectors of 5.25-inch floppies go. If necessary, you can see the card between two rows of pin strip pinch (or solder). It's even cheaper if you use micro or mini SD cards and usually included adapter anlötet. However, anyone who wants to give up a DIY, alternatively, for relatively little money a [http://www.shop.display3000.com/elektronikmodule/sd-kartenmodul/index.html completely assembled SD adapter] available for purchase to be connected to the AVR. With this adapter already is a bidirectional signal level between the 5V levels of the control lines of the AVR and the 3.3 V level of the SD card on board. Affordable these modules can [http://www.ebay.com/sch/i.html?_from=R40&_sacat=0&_nkw=Micro+SD+Card+Module+SPI&rt=nc&LH_PrefLoc=2 ebay] are sourced from China. == Configuration == | | I/O ---> | | ... │ │ Storage ---> │ │ ... | | [*] SD/MMC-Card Reader ---> | | ... | | [ ] SDHC support | | | | [*] VFAT LFN support | | | | [ ] Read-only mode | | | | [*] Use read-timeout | | | | [*] Ping-read SD card every 10s | | | | --- ECMD Support | | | | [*] info | | | | [*] dir | | | | [*] mkdir | | | | [*] rm | | | | --- Debugging Flags | | | | [*] FAT | | | | [*] RAW | | | | [*] VFS | | | | General Setup ---> | | ... | | [*] VFS (Virtual File System) support ---> | | ... | | [*] SD/MMC-Card Filesystem | | == [[ECMD|ECMD]] == IRMP implements an [[ECMD]] interface. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == The following example writes the date, time and temperature by VFS_LOG_ALLOCA (VFS_LOG requires UIP) in the file "temp.log" as soon as the temperature has changed by more than a degree to the last measurement. For date and time CLOCK_SUPPORT must be enabled. <pre> #include <stdlib.h> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO uint8_t sign = Temperatur<0; div_t res = div(abs(Temperatur),10); VFS_LOG_ALLOCA("temp.log", 50, "%2d.%2d.%4d %2d:%02d %S%d.%d", CLOCK_DAY, CLOCK_MONTH, CLOCK_YEAR, CLOCK_HOUR, CLOCK_MIN, sign?PSTR("-"):PSTR(""),res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> e0257d905b8ac57976d62285470a67969614cb37 0 312 1199 1088 2014-03-30T15:03:04Z GooPie4o 265 /* Connection */ wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->Radio->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |TIMER={{occupies_timer|2}} (RX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} The FS20 / FHT system by ELV is currently the most successful wireless home control system in the low cost sector. This arises from the large number of components and the continuous expansion of the system. But the relatively low price, the comprehensive home control systems far below the price of such EIB systems permits, plays a crucial role. This modul is based on [http://culfw.de CULFW by Rudolf Koenig] and supports a wide range of protocols: * FS20: send/receive<br>There are numerous FS20 devices, all of them are fully supported. * FHT: send/receive<br>Communication to the FHT80b is supported. * S300: receive<br>Examples of such devices: S300TH, KS300-2 * EM1000: receive<br>Devices: EM1000FM, EM1000GZ, EM1000WZ * HMS: receive<br>Devices: There are numerous HMS devices, all of them are fully supported. * ESA2000: receive * Lacrosse TX2/TX3: receive == Connection == The RFM12 is connected to the AVR like in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FSK/DATA/nFSS signal (Pin 3) is connected to one of the INT pins of the AVR. This modul does not work in interrupt mode, so the output nRQ signal (Pin 2) can be left unconnected. The software uses the digital filter of the RFM12. To improve sensitivity on short and long distances the [http://jeelabs.net/projects/cafe/wiki/Receiving_OOKASK_with_a_modified_RFM12B C_arssi capacitor needs to be replaced] with a value of 150 pF. The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_FS20_USE_INT(1) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_FS20_USE_INT defines whether FSK/DATA/nFSS is connected to INT0, INT1 or INT2 of the AVR. == Configuration == The FS20 system sends on 868,35 MHz, so the 868MHz option is the right one. | | I/O ---> | | ... | | Radio ---> | | ... | | [*] RFM12 ASK ---> | | ... | | [ ] 433MHz | | | | [-] Pollin/Kangtai Powerswitch (IC 2272) | | | | [-] Pollin Powerswitch buried (IC 1527) | | | | [-] Tevion Powerswitch | | | | [-] Intertechno ITS-150 | | | | [-] External filter | | | | [-] Sensing | | | | --- | | | | [*] 868MHz | | | | (0) RFM12 select | | | | [*] FS20 send | | | | [*] FS20 receive | | | | [*] FHT | | | | [*] ESA | | | | [ ] TX3 | | | | [ ] Send received data via syslog | | | | --- Debugging Flags | | | | [-] Sensing | | | | [ ] FS20 | | The modul uses Timer 2 of the AVR '''exclusively'''. Currently there is no option to use Timer 1, but this will change in the future. == [[ECMD]] == RFM12 FS20 implements an [[ECMD]] interface for send and receive FS20/FHT commands. The received data is formatted as described in the [http://culfw.de/commandref.html#protocol2 CULFW reference]. See [[ECMD_Reference|ECMD reference]] for a command list. == Troubleshooting == It may happen that not all of the RFM12 FS20 sensors are received. Here are some points that may help to improve reception: * Location: ** Avoid RF transmitter near the RFM12 ** Choose a position in the center of the sensors * Antenna: ** It is recommended to choose an antenna with a length not shorter than Lamda/2 (17,3cm) * Bandwidth: Default 400kHz ** Can be changed via ECMD from 400kHz to 67kHz (rfm12 setbandwidth <modulnumber> 1-6) * Gain: Default -14dB ** Can be changed via ECMD from 0dB to -20dB (rfm12 setgain <modulnumber> 0-3) * DRSSI: Default -97dB ** Can be changed via ECMD from -103dB to -61dB (rfm12 setdrssi <modulnumber> 0-7) Checkout the RFM12 datasheet for details on bandwidth, gain and DRSSI. == Decoding received data == The received data is formatted as described in the [http://culfw.de/commandref.html#protocol2 CULFW reference]. One could use the perl scripts from [http://culfw.de/ CULFW] to decode the data. [[Category:RFM12]] 3b6f2b3c4edb88d4ef14b8716217b9d1016b4b22 0 381 1201 2014-03-30T15:25:57Z GooPie4o 265 Created page with "{{i18n|Generic ASK Modules}} {{Module |NAME=Generic ASK Modules |MENUCONFIG={{I/O}}->Radio->Generic ASK |STATUS={{In_Development}} |PINNING=yes |ECMD= no |CONTROL6=no |DEPENDS= -…" wikitext text/x-wiki {{i18n|Generic ASK Modules}} {{Module |NAME=Generic ASK Modules |MENUCONFIG={{I/O}}->Radio->Generic ASK |STATUS={{In_Development}} |PINNING=yes |ECMD= no |CONTROL6=no |DEPENDS= - |REQUIRES= - |TIMER={{occupies_timer|2}} (RX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/generic_ask https://github.com/ethersex/ethersex/tree/master/hardware/radio/generic_ask] }} == Connection == == Configuration == [[Category:ASK]] 1d132673b1ee1d43a2e9a9df0911f1fdc924a2a2 6 382 1202 2014-03-30T15:26:50Z GooPie4o 265 self taken wikitext text/x-wiki self taken 9215bed28daef84dd3d4aec9e72090f7e2fe119a 6 383 1203 2014-03-30T15:27:51Z GooPie4o 265 self taken wikitext text/x-wiki self taken 9215bed28daef84dd3d4aec9e72090f7e2fe119a 0 381 1204 1201 2014-03-30T15:30:29Z GooPie4o 265 wikitext text/x-wiki {{i18n|Generic ASK Modules}} {{Module |NAME=Generic ASK Modules |MENUCONFIG={{I/O}}->Radio->Generic ASK |STATUS={{In_Development}} |PINNING=yes |ECMD= no |CONTROL6=no |DEPENDS= - |REQUIRES= - |TIMER={{occupies_timer|2}} (RX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/generic_ask https://github.com/ethersex/ethersex/tree/master/hardware/radio/generic_ask] }} [[File:Generic ask module front.jpg|200px|thumb|right|Generic ASK Module TX and RX (front)]] [[File:Generic ask module back.jpg|200px|thumb|right|Generic ASK Module TX and RX (back)]] == Connection == == Configuration == [[Category:ASK]] 544534449c5feb7c0030d5138ef0a47abc32ed0b 1206 1204 2014-03-30T15:44:47Z GooPie4o 265 wikitext text/x-wiki {{i18n|Generic ASK Modules}} {{Module |NAME=Generic ASK Modules |MENUCONFIG={{I/O}}->Radio->Generic ASK |STATUS={{In_Development}} |PINNING=yes |ECMD= no |CONTROL6=no |DEPENDS= - |REQUIRES= - |TIMER={{occupies_timer|2}} (RX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/generic_ask https://github.com/ethersex/ethersex/tree/master/hardware/radio/generic_ask] }} [[File:Generic ask module front.jpg|200px|thumb|right|Generic ASK Module TX and RX (front)]] [[File:Generic ask module back.jpg|200px|thumb|right|Generic ASK Module TX and RX (back)]] These modules are sourced from China and can be bougth via [http://www.ebay.com/sch/i.html?_sacat=0&_from=R40&_sop=15&LH_BIN=1&_nkw=433Mhz+RF+Transmitter+And+Receiver+Kit&LH_PrefLoc=2&rt=nc&LH_FS=1 ebay]. == Connection == == Configuration == [[Category:ASK]] c356cf483cfb91b37f8f2e8a335efeee67637347 1207 1206 2014-03-30T15:50:46Z GooPie4o 265 wikitext text/x-wiki {{i18n|Generic ASK Modules}} {{Module |NAME=Generic ASK Modules |MENUCONFIG={{I/O}}->Radio->Generic ASK |STATUS={{In_Development}} |PINNING=yes |ECMD= no |CONTROL6=no |DEPENDS= - |REQUIRES= - |TIMER={{occupies_timer|2}} (RX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/generic_ask https://github.com/ethersex/ethersex/tree/master/hardware/radio/generic_ask] }} [[File:Generic ask module front.jpg|200px|thumb|right|Generic ASK Module TX and RX (front)]] [[File:Generic ask module back.jpg|200px|thumb|right|Generic ASK Module TX and RX (back)]] ==== Technical Specifications ==== * Receiver module parameters ** Product Model: MX-05V ** Operating voltage: DC5V ** Quiescent Current: 4mA ** Receiving frequency: 433.92MHZ ** Receiver sensitivity: -105DB ** Size: 30 * 14 * 7mm ** External antenna: 32CM single core wire, wound into a spiral * Transmitter module parameters ** Product Model: MX-FS-03V ** Launch distance: 20-200 meters (different voltage, different results) ** Operating voltage: 3.5-12V ** Dimensions: 19 * 19mm ** Operating mode: AM ** Transfer rate: 4KB/s ** Transmitting power: 10mW ** Transmitting frequency: 433M ** An external antenna: 25cm ordinary multi-core or single-core line ** Pinout from left → right: (DATA; VCC; GND) ==== Application environment ==== Remote control switch, receiver module, motorcycles, automobile anti-theft products, home security products, electric doors, shutter doors, windows, remote control socket, remote control LED, remote audio remote control electric doors, garage door remote control, remote control retractable doors, remote volume gate, pan doors, remote control door opener, door closing device control system, remote control curtains, alarm host, alarm, remote control motorcycle remote control electric cars, remote control MP3. ==== Remark ==== * VCC voltage module operating voltage and good power filtering; * Great influence on the antenna module reception, preferably connected to the 1/4 wavelength of the antenna, typically 50 ohm single conductor, the length of the antenna 433M of about 17cm; * Antenna position has also affected the reception of the module, the installation, the antenna as possible straight away from the shield, high pressure, and interference source; frequency used to receive, decode and oscillation resistor should match with the transmitter. These modules are sourced from China and can be bougth via [http://www.ebay.com/sch/i.html?_sacat=0&_from=R40&_sop=15&LH_BIN=1&_nkw=433Mhz+RF+Transmitter+And+Receiver+Kit&LH_PrefLoc=2&rt=nc&LH_FS=1 ebay]. == Connection == == Configuration == [[Category:ASK]] 28aa32974a68d5d09a738f7d77db57df4bb7d869 1208 1207 2014-03-31T16:58:28Z GooPie4o 265 /* Connection */ wikitext text/x-wiki {{i18n|Generic ASK Modules}} {{Module |NAME=Generic ASK Modules |MENUCONFIG={{I/O}}->Radio->Generic ASK |STATUS={{In_Development}} |PINNING=yes |ECMD= no |CONTROL6=no |DEPENDS= - |REQUIRES= - |TIMER={{occupies_timer|2}} (RX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/generic_ask https://github.com/ethersex/ethersex/tree/master/hardware/radio/generic_ask] }} [[File:Generic ask module front.jpg|200px|thumb|right|Generic ASK Module TX and RX (front)]] [[File:Generic ask module back.jpg|200px|thumb|right|Generic ASK Module TX and RX (back)]] ==== Technical Specifications ==== * Receiver module parameters ** Product Model: MX-05V ** Operating voltage: DC5V ** Quiescent Current: 4mA ** Receiving frequency: 433.92MHZ ** Receiver sensitivity: -105DB ** Size: 30 * 14 * 7mm ** External antenna: 32CM single core wire, wound into a spiral * Transmitter module parameters ** Product Model: MX-FS-03V ** Launch distance: 20-200 meters (different voltage, different results) ** Operating voltage: 3.5-12V ** Dimensions: 19 * 19mm ** Operating mode: AM ** Transfer rate: 4KB/s ** Transmitting power: 10mW ** Transmitting frequency: 433M ** An external antenna: 25cm ordinary multi-core or single-core line ** Pinout from left → right: (DATA; VCC; GND) ==== Application environment ==== Remote control switch, receiver module, motorcycles, automobile anti-theft products, home security products, electric doors, shutter doors, windows, remote control socket, remote control LED, remote audio remote control electric doors, garage door remote control, remote control retractable doors, remote volume gate, pan doors, remote control door opener, door closing device control system, remote control curtains, alarm host, alarm, remote control motorcycle remote control electric cars, remote control MP3. ==== Remark ==== * VCC voltage module operating voltage and good power filtering; * Great influence on the antenna module reception, preferably connected to the 1/4 wavelength of the antenna, typically 50 ohm single conductor, the length of the antenna 433M of about 17cm; * Antenna position has also affected the reception of the module, the installation, the antenna as possible straight away from the shield, high pressure, and interference source; frequency used to receive, decode and oscillation resistor should match with the transmitter. These modules are sourced from China and can be bougth via [http://www.ebay.com/sch/i.html?_sacat=0&_from=R40&_sop=15&LH_BIN=1&_nkw=433Mhz+RF+Transmitter+And+Receiver+Kit&LH_PrefLoc=2&rt=nc&LH_FS=1 ebay]. == Connection == {| class="wikitable" style="float:left; margin-right:1em" |+ TX Module ! Pin !! Description |- | 1 || GND |- | 2 || VCC (3.5-12V) |- | 3 || DATA |} {| class="wikitable" style="float:left; margin-right:1em" |+ RX Module ! Pin !! Description |- | 1 || GND |- | 2 || DATA |- | 3 || DATA |- | 4 || VCC (5V) |} == Configuration == [[Category:ASK]] 4fb8fe624cb204611596bf5a287aba8311e895bd 1211 1208 2014-03-31T17:02:38Z GooPie4o 265 wikitext text/x-wiki {{i18n|Generic ASK Modules}} {{Module |NAME=Generic ASK Modules |MENUCONFIG={{I/O}}->Radio->Generic ASK |STATUS={{In_Development}} |PINNING=yes |ECMD= no |CONTROL6=no |DEPENDS= - |REQUIRES= - |TIMER={{occupies_timer|2}} (RX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/generic_ask https://github.com/ethersex/ethersex/tree/master/hardware/radio/generic_ask] }} [[File:Generic ask module front.jpg|200px|thumb|right|Generic ASK Module TX and RX (front)]] [[File:Generic ask module back.jpg|200px|thumb|right|Generic ASK Module TX and RX (back)]] [[File:Ask_sender.jpg|200px|thumb|right|Shematic of TX Module]] [[File:Ask_receiver.gif|200px|thumb|right|Shematic of RX Module)]] ==== Technical Specifications ==== * Receiver module parameters ** Product Model: MX-05V ** Operating voltage: DC5V ** Quiescent Current: 4mA ** Receiving frequency: 433.92MHZ ** Receiver sensitivity: -105DB ** Size: 30 * 14 * 7mm ** External antenna: 32CM single core wire, wound into a spiral * Transmitter module parameters ** Product Model: MX-FS-03V ** Launch distance: 20-200 meters (different voltage, different results) ** Operating voltage: 3.5-12V ** Dimensions: 19 * 19mm ** Operating mode: AM ** Transfer rate: 4KB/s ** Transmitting power: 10mW ** Transmitting frequency: 433M ** An external antenna: 25cm ordinary multi-core or single-core line ** Pinout from left → right: (DATA; VCC; GND) ==== Application environment ==== Remote control switch, receiver module, motorcycles, automobile anti-theft products, home security products, electric doors, shutter doors, windows, remote control socket, remote control LED, remote audio remote control electric doors, garage door remote control, remote control retractable doors, remote volume gate, pan doors, remote control door opener, door closing device control system, remote control curtains, alarm host, alarm, remote control motorcycle remote control electric cars, remote control MP3. ==== Remark ==== * VCC voltage module operating voltage and good power filtering; * Great influence on the antenna module reception, preferably connected to the 1/4 wavelength of the antenna, typically 50 ohm single conductor, the length of the antenna 433M of about 17cm; * Antenna position has also affected the reception of the module, the installation, the antenna as possible straight away from the shield, high pressure, and interference source; frequency used to receive, decode and oscillation resistor should match with the transmitter. These modules are sourced from China and can be bougth via [http://www.ebay.com/sch/i.html?_sacat=0&_from=R40&_sop=15&LH_BIN=1&_nkw=433Mhz+RF+Transmitter+And+Receiver+Kit&LH_PrefLoc=2&rt=nc&LH_FS=1 ebay]. == Connection == {| class="wikitable" style="float:left; margin-right:1em" |+ TX Module ! Pin !! Description |- | 1 || GND |- | 2 || VCC (3.5-12V) |- | 3 || DATA |} {| class="wikitable" style="float:left; margin-right:1em" |+ RX Module ! Pin !! Description |- | 1 || GND |- | 2 || DATA |- | 3 || DATA |- | 4 || VCC (5V) |} == Configuration == [[Category:ASK]] c8e20fb4819105d5400ff1ca842a0d71dac32b05 1223 1211 2014-05-05T16:41:22Z GooPie4o 265 wikitext text/x-wiki {{i18n|Generic ASK Modules}} {{Module |NAME=Generic ASK Modules |MENUCONFIG={{I/O}}->Radio->Generic ASK |STATUS={{In_Development}} |PINNING=yes |ECMD= no |CONTROL6=no |DEPENDS= - |REQUIRES= - |TIMER={{occupies_timer|2}} (RX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/generic_ask https://github.com/ethersex/ethersex/tree/master/hardware/radio/generic_ask] }} [[File:Generic ask module front.jpg|200px|thumb|right|Generic ASK Module TX and RX (front)]] [[File:Generic ask module back.jpg|200px|thumb|right|Generic ASK Module TX and RX (back)]] [[File:Ask_sender.jpg|200px|thumb|right|Shematic of TX Module]] [[File:Ask_receiver.gif|200px|thumb|right|Shematic of RX Module)]] ==== Technical Specifications ==== * Receiver module parameters ** Product Model: MX-05V ** Operating voltage: DC5V ** Quiescent Current: 4mA ** Receiving frequency: 433.92MHZ ** Receiver sensitivity: -105DB ** Size: 30 * 14 * 7mm ** External antenna: 32CM single core wire, wound into a spiral * Transmitter module parameters ** Product Model: MX-FS-03V ** Launch distance: 20-200 meters (different voltage, different results) ** Operating voltage: 3.5-12V ** Dimensions: 19 * 19mm ** Operating mode: AM ** Transfer rate: 4KB/s ** Transmitting power: 10mW ** Transmitting frequency: 433M ** An external antenna: 25cm ordinary multi-core or single-core line ** Pinout from left → right: (DATA; VCC; GND) ==== Application environment ==== Remote control switch, receiver module, motorcycles, automobile anti-theft products, home security products, electric doors, shutter doors, windows, remote control socket, remote control LED, remote audio remote control electric doors, garage door remote control, remote control retractable doors, remote volume gate, pan doors, remote control door opener, door closing device control system, remote control curtains, alarm host, alarm, remote control motorcycle remote control electric cars, remote control MP3. ==== Remark ==== * VCC voltage module operating voltage and good power filtering; * Great influence on the antenna module reception, preferably connected to the 1/4 wavelength of the antenna, typically 50 ohm single conductor, the length of the antenna 433M of about 17cm; * Antenna position has also affected the reception of the module, the installation, the antenna as possible straight away from the shield, high pressure, and interference source; frequency used to receive, decode and oscillation resistor should match with the transmitter. These modules are sourced from China and can be bougth via [http://www.ebay.com/sch/i.html?_sacat=0&_from=R40&_sop=15&LH_BIN=1&_nkw=433Mhz+RF+Transmitter+And+Receiver+Kit&LH_PrefLoc=2&rt=nc&LH_FS=1 ebay]. '''Finally they will be used as a cheap replacement for [[RFM12]] to switch radio outlets. For details see [https://github.com/ethersex/ethersex/issues/284 Issue 284 on Github].''' == Connection == {| class="wikitable" style="float:left; margin-right:1em" |+ TX Module ! Pin !! Description |- | 1 || GND |- | 2 || VCC (3.5-12V) |- | 3 || DATA |} {| class="wikitable" style="float:left; margin-right:1em" |+ RX Module ! Pin !! Description |- | 1 || GND |- | 2 || DATA |- | 3 || DATA |- | 4 || VCC (5V) |} == Configuration == [[Category:ASK]] c9f9057f026533608a237d4b78cecd3ceac4d3db 1226 1223 2014-05-10T07:09:28Z GooPie4o 265 wikitext text/x-wiki {{i18n|Generic ASK Modules}} {{Module |NAME=Generic ASK Modules |MENUCONFIG={{I/O}}->Radio->Generic ASK |STATUS={{In_Development}} |PINNING=yes |ECMD= no |CONTROL6=no |DEPENDS= - |REQUIRES= - |TIMER={{occupies_timer|2}} (RX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/generic_ask https://github.com/ethersex/ethersex/tree/master/hardware/radio/generic_ask] }} [[File:Generic ask module front.jpg|200px|thumb|right|Generic ASK Module TX and RX (front)]] [[File:Generic ask module back.jpg|200px|thumb|right|Generic ASK Module TX and RX (back)]] [[File:Ask_sender.jpg|200px|thumb|right|Shematic of TX Module]] [[File:Ask_receiver.gif|200px|thumb|right|Shematic of RX Module]] ==== Technical Specifications ==== * Receiver module parameters ** Product Model: MX-05V ** Operating voltage: DC5V ** Quiescent Current: 4mA ** Receiving frequency: 433.92MHZ ** Receiver sensitivity: -105DB ** Size: 30 * 14 * 7mm ** External antenna: 32CM single core wire, wound into a spiral * Transmitter module parameters ** Product Model: MX-FS-03V ** Launch distance: 20-200 meters (different voltage, different results) ** Operating voltage: 3.5-12V ** Dimensions: 19 * 19mm ** Operating mode: AM ** Transfer rate: 4KB/s ** Transmitting power: 10mW ** Transmitting frequency: 433M ** An external antenna: 25cm ordinary multi-core or single-core line ** Pinout from left → right: (DATA; VCC; GND) ==== Application environment ==== Remote control switch, receiver module, motorcycles, automobile anti-theft products, home security products, electric doors, shutter doors, windows, remote control socket, remote control LED, remote audio remote control electric doors, garage door remote control, remote control retractable doors, remote volume gate, pan doors, remote control door opener, door closing device control system, remote control curtains, alarm host, alarm, remote control motorcycle remote control electric cars, remote control MP3. ==== Remark ==== * VCC voltage module operating voltage and good power filtering; * Great influence on the antenna module reception, preferably connected to the 1/4 wavelength of the antenna, typically 50 ohm single conductor, the length of the antenna 433M of about 17cm; * Antenna position has also affected the reception of the module, the installation, the antenna as possible straight away from the shield, high pressure, and interference source; frequency used to receive, decode and oscillation resistor should match with the transmitter. These modules are sourced from China and can be bougth via [http://www.ebay.com/sch/i.html?_sacat=0&_from=R40&_sop=15&LH_BIN=1&_nkw=433Mhz+RF+Transmitter+And+Receiver+Kit&LH_PrefLoc=2&rt=nc&LH_FS=1 ebay]. '''Finally they will be used as a cheap replacement for [[RFM12]] to switch radio outlets. For details see [https://github.com/ethersex/ethersex/issues/284 Issue 284 on Github].''' == Connection == {| class="wikitable" style="float:left; margin-right:1em" |+ TX Module ! Pin !! Description |- | 1 || GND |- | 2 || VCC (3.5-12V) |- | 3 || DATA |} {| class="wikitable" style="float:left; margin-right:1em" |+ RX Module ! Pin !! Description |- | 1 || GND |- | 2 || DATA |- | 3 || DATA |- | 4 || VCC (5V) |} == Configuration == [[Category:ASK]] 469021b7b2870a09ff9ba0eabf5e81b12ea28681 1227 1226 2014-05-15T10:53:18Z GooPie4o 265 wikitext text/x-wiki {{i18n|Generic ASK Modules}} {{Module |NAME=Generic ASK Modules |MENUCONFIG={{I/O}}->Radio->Generic ASK |STATUS={{In_Development}} |PINNING=yes |ECMD= no |CONTROL6=no |DEPENDS= - |REQUIRES= - |TIMER={{occupies_timer|2}} (RX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/generic_ask https://github.com/ethersex/ethersex/tree/master/hardware/radio/generic_ask] }} [[File:Generic ask module front.jpg|200px|thumb|right|Generic ASK Module TX and RX (front)]] [[File:Generic ask module back.jpg|200px|thumb|right|Generic ASK Module TX and RX (back)]] [[File:Ask_sender.jpg|200px|thumb|right|Shematic of TX Module]] [[File:Ask_receiver.gif|200px|thumb|right|Shematic of RX Module]] ==== Technical Specifications ==== * Receiver module parameters ** Product Model: MX-05V ** Operating voltage: DC5V ** Quiescent Current: 4mA ** Receiving frequency: 433.92MHZ ** Receiver sensitivity: -105DB ** Size: 30 * 14 * 7mm ** External antenna: 32CM single core wire, wound into a spiral * Transmitter module parameters ** Product Model: MX-FS-03V ** Launch distance: 20-200 meters (different voltage, different results) ** Operating voltage: 3.5-12V ** Dimensions: 19 * 19mm ** Operating mode: AM ** Transfer rate: 4KB/s ** Transmitting power: 10mW ** Transmitting frequency: 433M ** An external antenna: 25cm ordinary multi-core or single-core line ** Pinout from left → right: (DATA; VCC; GND) ==== Application environment ==== Remote control switch, receiver module, motorcycles, automobile anti-theft products, home security products, electric doors, shutter doors, windows, remote control socket, remote control LED, remote audio remote control electric doors, garage door remote control, remote control retractable doors, remote volume gate, pan doors, remote control door opener, door closing device control system, remote control curtains, alarm host, alarm, remote control motorcycle remote control electric cars, remote control MP3. ==== Remark ==== * VCC voltage module operating voltage and good power filtering; * Great influence on the antenna module reception, preferably connected to the 1/4 wavelength of the antenna, typically 50 ohm single conductor, the length of the antenna 433M of about 17cm; * Antenna position has also affected the reception of the module, the installation, the antenna as possible straight away from the shield, high pressure, and interference source; frequency used to receive, decode and oscillation resistor should match with the transmitter. These modules are sourced from China and can be bougth via [http://www.ebay.com/sch/i.html?_sacat=0&_from=R40&_sop=15&LH_BIN=1&_nkw=433Mhz+RF+Transmitter+And+Receiver+Kit&LH_PrefLoc=2&rt=nc&LH_FS=1 ebay]. '''Finally they will be used as a cheap replacement for [[RFM12]] to switch radio outlets. For details see [https://github.com/ethersex/ethersex/issues/284 Issue 284 on Github].''' == Connection == {| class="wikitable" style="left; margin-right:1em" |+ TX Module ! Pin !! Description |- | 1 || GND |- | 2 || VCC (3.5-12V) |- | 3 || DATA |} {| class="wikitable" style="left; margin-right:1em" |+ RX Module ! Pin !! Description |- | 1 || GND |- | 2 || DATA |- | 3 || DATA |- | 4 || VCC (5V) |} == Configuration == == Links == * [http://www.youtube.com/watch?v=LDGr38Ie1L4 Demo] on Youtube * [http://www.electrodragon.com/wp-content/uploads/2012/04/VirtualWire.pdf Documentation of library virtualwire] * [http://www.electrodragon.com/wp-content/uploads/2012/04/KLP_Walkthrough.pdf KLP/KLPA module walkthrough] * [http://winavr.scienceprog.com/example-avr-projects/running-tx433-and-rx433-rf-modules-with-avr-microcontrollers.html Running TX433 and RX433 RF modules with AVR microcontrollers] [[Category:ASK]] 4b8bdb7556ade8ae97a1c7296c8251637007f5b8 1228 1227 2014-05-16T07:20:38Z GooPie4o 265 wikitext text/x-wiki {{i18n|Generic ASK Modules}} {{Module |NAME=Generic ASK Modules |MENUCONFIG={{I/O}}->Radio->Generic ASK |STATUS={{In_Development}} |PINNING=yes |ECMD= no |CONTROL6=no |DEPENDS= - |REQUIRES= - |TIMER={{occupies_timer|2}} (RX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/generic_ask https://github.com/ethersex/ethersex/tree/master/hardware/radio/generic_ask] }} [[File:Generic ask module front.jpg|200px|thumb|right|Generic ASK Module TX and RX (front)]] [[File:Generic ask module back.jpg|200px|thumb|right|Generic ASK Module TX and RX (back)]] [[File:Ask_sender.jpg|200px|thumb|right|Shematic of TX Module]] [[File:Ask_receiver.gif|200px|thumb|right|Shematic of RX Module]] ==== Technical Specifications ==== * Receiver module parameters ** Product Model: MX-05V ** Operating voltage: DC5V ** Quiescent Current: 4mA ** Receiving frequency: 433.92MHZ ** Receiver sensitivity: -105DB ** Size: 30 * 14 * 7mm ** External antenna: 32CM single core wire, wound into a spiral * Transmitter module parameters ** Product Model: MX-FS-03V ** Launch distance: 20-200 meters (different voltage, different results) ** Operating voltage: 3.5-12V ** Dimensions: 19 * 19mm ** Operating mode: AM ** Transfer rate: 4KB/s ** Transmitting power: 10mW ** Transmitting frequency: 433M ** An external antenna: 25cm ordinary multi-core or single-core line ** Pinout from left → right: (DATA; VCC; GND) ==== Remark ==== * VCC voltage module operating voltage and good power filtering; * Great influence on the antenna module reception, preferably connected to the 1/4 wavelength of the antenna, typically 50 ohm single conductor, the length of the antenna 433M of about 17cm; * Antenna position has also affected the reception of the module, the installation, the antenna as possible straight away from the shield, high pressure, and interference source; frequency used to receive, decode and oscillation resistor should match with the transmitter. These modules are sourced from China and can be bougth via [http://www.ebay.com/sch/i.html?_sacat=0&_from=R40&_sop=15&LH_BIN=1&_nkw=433Mhz+RF+Transmitter+And+Receiver+Kit&LH_PrefLoc=2&rt=nc&LH_FS=1 ebay]. '''Finally they will be used as a cheap replacement for [[RFM12]] to switch radio outlets. For details see [https://github.com/ethersex/ethersex/issues/284 Issue 284 on Github].''' == Connection == {| class="wikitable" style="left; margin-right:1em" |+ TX Module ! Pin !! Description |- | 1 || GND |- | 2 || VCC (3.5-12V) |- | 3 || DATA |} {| class="wikitable" style="left; margin-right:1em" |+ RX Module ! Pin !! Description |- | 1 || GND |- | 2 || DATA |- | 3 || DATA |- | 4 || VCC (5V) |} == Configuration == == Links == * [http://www.youtube.com/watch?v=LDGr38Ie1L4 Demo] on Youtube * [http://www.electrodragon.com/wp-content/uploads/2012/04/VirtualWire.pdf Documentation of library virtualwire] * [http://www.electrodragon.com/wp-content/uploads/2012/04/KLP_Walkthrough.pdf KLP/KLPA module walkthrough] * [http://winavr.scienceprog.com/example-avr-projects/running-tx433-and-rx433-rf-modules-with-avr-microcontrollers.html Running TX433 and RX433 RF modules with AVR microcontrollers] [[Category:ASK]] 8faa2b9b0ed6e2d8e8421cadbbd065a95ebb9436 1229 1228 2014-05-16T07:21:21Z GooPie4o 265 wikitext text/x-wiki {{i18n|Generic ASK Modules}} {{Module |NAME=Generic ASK Modules |MENUCONFIG={{I/O}}->Radio->Generic ASK |STATUS={{In_Development}} |PINNING=yes |ECMD= no |CONTROL6=no |DEPENDS= - |REQUIRES= - |TIMER={{occupies_timer|2}} (RX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/generic_ask https://github.com/ethersex/ethersex/tree/master/hardware/radio/generic_ask] }} [[File:Generic ask module front.jpg|200px|thumb|right|Generic ASK Module TX and RX (front)]] [[File:Generic ask module back.jpg|200px|thumb|right|Generic ASK Module TX and RX (back)]] [[File:Ask_sender.jpg|200px|thumb|right|Shematic of TX Module]] [[File:Ask_receiver.gif|200px|thumb|right|Shematic of RX Module]] These modules are sourced from China and can be bougth via [http://www.ebay.com/sch/i.html?_sacat=0&_from=R40&_sop=15&LH_BIN=1&_nkw=433Mhz+RF+Transmitter+And+Receiver+Kit&LH_PrefLoc=2&rt=nc&LH_FS=1 ebay]. '''Finally they will be used as a cheap replacement for [[RFM12]] to switch radio outlets. For details see [https://github.com/ethersex/ethersex/issues/284 Issue 284 on Github].''' ==== Technical Specifications ==== * Receiver module parameters ** Product Model: MX-05V ** Operating voltage: DC5V ** Quiescent Current: 4mA ** Receiving frequency: 433.92MHZ ** Receiver sensitivity: -105DB ** Size: 30 * 14 * 7mm ** External antenna: 32CM single core wire, wound into a spiral * Transmitter module parameters ** Product Model: MX-FS-03V ** Launch distance: 20-200 meters (different voltage, different results) ** Operating voltage: 3.5-12V ** Dimensions: 19 * 19mm ** Operating mode: AM ** Transfer rate: 4KB/s ** Transmitting power: 10mW ** Transmitting frequency: 433M ** An external antenna: 25cm ordinary multi-core or single-core line ** Pinout from left → right: (DATA; VCC; GND) ==== Remark ==== * VCC voltage module operating voltage and good power filtering; * Great influence on the antenna module reception, preferably connected to the 1/4 wavelength of the antenna, typically 50 ohm single conductor, the length of the antenna 433M of about 17cm; * Antenna position has also affected the reception of the module, the installation, the antenna as possible straight away from the shield, high pressure, and interference source; frequency used to receive, decode and oscillation resistor should match with the transmitter. == Connection == {| class="wikitable" style="left; margin-right:1em" |+ TX Module ! Pin !! Description |- | 1 || GND |- | 2 || VCC (3.5-12V) |- | 3 || DATA |} {| class="wikitable" style="left; margin-right:1em" |+ RX Module ! Pin !! Description |- | 1 || GND |- | 2 || DATA |- | 3 || DATA |- | 4 || VCC (5V) |} == Configuration == == Links == * [http://www.youtube.com/watch?v=LDGr38Ie1L4 Demo] on Youtube * [http://www.electrodragon.com/wp-content/uploads/2012/04/VirtualWire.pdf Documentation of library virtualwire] * [http://www.electrodragon.com/wp-content/uploads/2012/04/KLP_Walkthrough.pdf KLP/KLPA module walkthrough] * [http://winavr.scienceprog.com/example-avr-projects/running-tx433-and-rx433-rf-modules-with-avr-microcontrollers.html Running TX433 and RX433 RF modules with AVR microcontrollers] [[Category:ASK]] f3571a7e7bb4ad60390d484c9450e921d9d7baa2 1230 1229 2014-05-31T15:11:48Z GooPie4o 265 wikitext text/x-wiki {{i18n|Generic ASK Modules}} {{Module |NAME=Generic ASK Modules |MENUCONFIG={{I/O}}->Radio->Generic ASK |STATUS={{In_Development}} |PINNING=yes |ECMD= no |CONTROL6=no |DEPENDS= - |REQUIRES= - |TIMER={{occupies_timer|2}} (RX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/generic_ask https://github.com/ethersex/ethersex/tree/master/hardware/radio/generic_ask] }} [[File:Generic ask module front.jpg|200px|thumb|right|Generic ASK Module TX and RX (front)]] [[File:Generic ask module back.jpg|200px|thumb|right|Generic ASK Module TX and RX (back)]] [[File:Ask_sender.jpg|200px|thumb|right|Shematic of TX Module]] [[File:Ask_receiver.gif|200px|thumb|right|Shematic of RX Module]] These modules are sourced from China and can be bougth via [http://www.ebay.com/sch/i.html?_sacat=0&_from=R40&_sop=15&LH_BIN=1&_nkw=433Mhz+RF+Transmitter+And+Receiver+Kit&LH_PrefLoc=2&rt=nc&LH_FS=1 ebay]. '''Finally they will be used as a cheap replacement for [[RFM12]] to switch radio outlets. For details see [https://github.com/ethersex/ethersex/issues/284 Issue 284 on Github].''' ==== Technical Specifications ==== * Receiver module parameters ** Product Model: MX-05V ** Operating voltage: DC5V ** Quiescent Current: 4mA ** Receiving frequency: 433.92MHZ ** Receiver sensitivity: -105DB ** Size: 30 * 14 * 7mm ** External antenna: 32CM single core wire, wound into a spiral * Transmitter module parameters ** Product Model: MX-FS-03V ** Launch distance: 20-200 meters (different voltage, different results) ** Operating voltage: 3.5-12V ** Dimensions: 19 * 19mm ** Operating mode: AM ** Transfer rate: 4KB/s ** Transmitting power: 10mW ** Transmitting frequency: 433M ** An external antenna: 25cm ordinary multi-core or single-core line ** Pinout from left → right: (DATA; VCC; GND) ==== Remark ==== * VCC voltage module operating voltage and good power filtering; * Great influence on the antenna module reception, preferably connected to the 1/4 wavelength of the antenna, typically 50 ohm single conductor, the length of the antenna 433M of about 17cm; * Antenna position has also affected the reception of the module, the installation, the antenna as possible straight away from the shield, high pressure, and interference source; frequency used to receive, decode and oscillation resistor should match with the transmitter. == Connection == {| class="wikitable" style="left; margin-right:1em" |+ TX Module ! Pin !! Description |- | 1 || GND |- | 2 || VCC (3.5-12V) |- | 3 || DATA |} {| class="wikitable" style="left; margin-right:1em" |+ RX Module ! Pin !! Description |- | 1 || GND |- | 2 || DATA |- | 3 || DATA |- | 4 || VCC (5V) |} == Configuration == First enable the hardware and then select it in the protocol section. | | I/O ---> | | ... | | Radio ---> | | ... | | [*] Generic ASK (433MHz) | | | | Protocols ---> | | ... | | Radio ---> | | | | [*] Radio outlets (433MHz) ---> | | ... | | (Generic) Transmitter hardware | | | | [*] Pollin/Kangtai Powerswitch (IC 2272) | | | | [*] Pollin Powerswitch buried (IC 1527) | | | | [*] Tevion Powerswitch | | | | [*] Intertechno ITS-150 | | | | [*] Intertechno Self Learning | | | | [*] Oase FM Master | | == Links == * [http://www.youtube.com/watch?v=LDGr38Ie1L4 Demo] on Youtube * [http://www.electrodragon.com/wp-content/uploads/2012/04/VirtualWire.pdf Documentation of library virtualwire] * [http://www.electrodragon.com/wp-content/uploads/2012/04/KLP_Walkthrough.pdf KLP/KLPA module walkthrough] * [http://winavr.scienceprog.com/example-avr-projects/running-tx433-and-rx433-rf-modules-with-avr-microcontrollers.html Running TX433 and RX433 RF modules with AVR microcontrollers] [[Category:ASK]] 1a2c95ce548f6997f7d06b350d6327fa912f5247 1231 1230 2014-05-31T15:16:18Z GooPie4o 265 /* Connection */ wikitext text/x-wiki {{i18n|Generic ASK Modules}} {{Module |NAME=Generic ASK Modules |MENUCONFIG={{I/O}}->Radio->Generic ASK |STATUS={{In_Development}} |PINNING=yes |ECMD= no |CONTROL6=no |DEPENDS= - |REQUIRES= - |TIMER={{occupies_timer|2}} (RX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/generic_ask https://github.com/ethersex/ethersex/tree/master/hardware/radio/generic_ask] }} [[File:Generic ask module front.jpg|200px|thumb|right|Generic ASK Module TX and RX (front)]] [[File:Generic ask module back.jpg|200px|thumb|right|Generic ASK Module TX and RX (back)]] [[File:Ask_sender.jpg|200px|thumb|right|Shematic of TX Module]] [[File:Ask_receiver.gif|200px|thumb|right|Shematic of RX Module]] These modules are sourced from China and can be bougth via [http://www.ebay.com/sch/i.html?_sacat=0&_from=R40&_sop=15&LH_BIN=1&_nkw=433Mhz+RF+Transmitter+And+Receiver+Kit&LH_PrefLoc=2&rt=nc&LH_FS=1 ebay]. '''Finally they will be used as a cheap replacement for [[RFM12]] to switch radio outlets. For details see [https://github.com/ethersex/ethersex/issues/284 Issue 284 on Github].''' ==== Technical Specifications ==== * Receiver module parameters ** Product Model: MX-05V ** Operating voltage: DC5V ** Quiescent Current: 4mA ** Receiving frequency: 433.92MHZ ** Receiver sensitivity: -105DB ** Size: 30 * 14 * 7mm ** External antenna: 32CM single core wire, wound into a spiral * Transmitter module parameters ** Product Model: MX-FS-03V ** Launch distance: 20-200 meters (different voltage, different results) ** Operating voltage: 3.5-12V ** Dimensions: 19 * 19mm ** Operating mode: AM ** Transfer rate: 4KB/s ** Transmitting power: 10mW ** Transmitting frequency: 433M ** An external antenna: 25cm ordinary multi-core or single-core line ** Pinout from left → right: (DATA; VCC; GND) ==== Remark ==== * VCC voltage module operating voltage and good power filtering; * Great influence on the antenna module reception, preferably connected to the 1/4 wavelength of the antenna, typically 50 ohm single conductor, the length of the antenna 433M of about 17cm; * Antenna position has also affected the reception of the module, the installation, the antenna as possible straight away from the shield, high pressure, and interference source; frequency used to receive, decode and oscillation resistor should match with the transmitter. == Connection == The DATA pin of the transmitter module is named GENERIC_ASK in Ethersex's pinning. The example below uses PA0. ifdef(`conf_GENERIC_ASK', `dnl pin(GENERIC_ASK, PA0, OUTPUT) ')dnl {| class="wikitable" style="left; margin-right:1em" |+ TX Module ! Pin !! Description |- | 1 || GND |- | 2 || VCC (3.5-12V) |- | 3 || DATA |} {| class="wikitable" style="left; margin-right:1em" |+ RX Module ! Pin !! Description |- | 1 || GND |- | 2 || DATA |- | 3 || DATA |- | 4 || VCC (5V) |} == Configuration == First enable the hardware and then select it in the protocol section. | | I/O ---> | | ... | | Radio ---> | | ... | | [*] Generic ASK (433MHz) | | | | Protocols ---> | | ... | | Radio ---> | | | | [*] Radio outlets (433MHz) ---> | | ... | | (Generic) Transmitter hardware | | | | [*] Pollin/Kangtai Powerswitch (IC 2272) | | | | [*] Pollin Powerswitch buried (IC 1527) | | | | [*] Tevion Powerswitch | | | | [*] Intertechno ITS-150 | | | | [*] Intertechno Self Learning | | | | [*] Oase FM Master | | == Links == * [http://www.youtube.com/watch?v=LDGr38Ie1L4 Demo] on Youtube * [http://www.electrodragon.com/wp-content/uploads/2012/04/VirtualWire.pdf Documentation of library virtualwire] * [http://www.electrodragon.com/wp-content/uploads/2012/04/KLP_Walkthrough.pdf KLP/KLPA module walkthrough] * [http://winavr.scienceprog.com/example-avr-projects/running-tx433-and-rx433-rf-modules-with-avr-microcontrollers.html Running TX433 and RX433 RF modules with AVR microcontrollers] [[Category:ASK]] f1a2fd5ee4ca785c1fb77ccc9009d34629262dd3 1232 1231 2014-05-31T15:17:02Z GooPie4o 265 wikitext text/x-wiki {{i18n|Generic ASK Modules}} {{Module |NAME=Generic ASK Modules |MENUCONFIG={{I/O}}->Radio->Generic ASK |STATUS={{In_Development}} |PINNING=yes |ECMD= no |CONTROL6=no |DEPENDS= - |REQUIRES= - |TIMER={{occupies_timer|2}} (RX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/generic_ask https://github.com/ethersex/ethersex/tree/master/hardware/radio/generic_ask] }} [[File:Generic ask module front.jpg|200px|thumb|right|Generic ASK Module TX and RX (front)]] [[File:Generic ask module back.jpg|200px|thumb|right|Generic ASK Module TX and RX (back)]] [[File:Ask_sender.jpg|200px|thumb|right|Shematic of TX Module]] [[File:Ask_receiver.gif|200px|thumb|right|Shematic of RX Module]] These modules are sourced from China and can be bougth via [http://www.ebay.com/sch/i.html?_sacat=0&_from=R40&_sop=15&LH_BIN=1&_nkw=433Mhz+RF+Transmitter+And+Receiver+Kit&LH_PrefLoc=2&rt=nc&LH_FS=1 ebay]. '''Finally they will be used as a cheap replacement for [[RFM12]] to switch radio outlets. For details see [https://github.com/ethersex/ethersex/issues/284 Issue 284 on Github].''' ==== Technical Specifications ==== * Receiver module parameters ** Product Model: MX-05V ** Operating voltage: DC5V ** Quiescent Current: 4mA ** Receiving frequency: 433.92MHZ ** Receiver sensitivity: -105DB ** Size: 30 * 14 * 7mm ** External antenna: 32CM single core wire, wound into a spiral * Transmitter module parameters ** Product Model: MX-FS-03V ** Launch distance: 20-200 meters (different voltage, different results) ** Operating voltage: 3.5-12V ** Dimensions: 19 * 19mm ** Operating mode: AM ** Transfer rate: 4KB/s ** Transmitting power: 10mW ** Transmitting frequency: 433M ** An external antenna: 25cm ordinary multi-core or single-core line ==== Remark ==== * VCC voltage module operating voltage and good power filtering; * Great influence on the antenna module reception, preferably connected to the 1/4 wavelength of the antenna, typically 50 ohm single conductor, the length of the antenna 433M of about 17cm; * Antenna position has also affected the reception of the module, the installation, the antenna as possible straight away from the shield, high pressure, and interference source; frequency used to receive, decode and oscillation resistor should match with the transmitter. == Connection == The DATA pin of the transmitter module is named GENERIC_ASK in Ethersex's pinning. The example below uses PA0. ifdef(`conf_GENERIC_ASK', `dnl pin(GENERIC_ASK, PA0, OUTPUT) ')dnl {| class="wikitable" style="left; margin-right:1em" |+ TX Module ! Pin !! Description |- | 1 || GND |- | 2 || VCC (3.5-12V) |- | 3 || DATA |} {| class="wikitable" style="left; margin-right:1em" |+ RX Module ! Pin !! Description |- | 1 || GND |- | 2 || DATA |- | 3 || DATA |- | 4 || VCC (5V) |} == Configuration == First enable the hardware and then select it in the protocol section. | | I/O ---> | | ... | | Radio ---> | | ... | | [*] Generic ASK (433MHz) | | | | Protocols ---> | | ... | | Radio ---> | | | | [*] Radio outlets (433MHz) ---> | | ... | | (Generic) Transmitter hardware | | | | [*] Pollin/Kangtai Powerswitch (IC 2272) | | | | [*] Pollin Powerswitch buried (IC 1527) | | | | [*] Tevion Powerswitch | | | | [*] Intertechno ITS-150 | | | | [*] Intertechno Self Learning | | | | [*] Oase FM Master | | == Links == * [http://www.youtube.com/watch?v=LDGr38Ie1L4 Demo] on Youtube * [http://www.electrodragon.com/wp-content/uploads/2012/04/VirtualWire.pdf Documentation of library virtualwire] * [http://www.electrodragon.com/wp-content/uploads/2012/04/KLP_Walkthrough.pdf KLP/KLPA module walkthrough] * [http://winavr.scienceprog.com/example-avr-projects/running-tx433-and-rx433-rf-modules-with-avr-microcontrollers.html Running TX433 and RX433 RF modules with AVR microcontrollers] [[Category:ASK]] 76fb293ea2eccfed7b51e05e3760f4f823e62940 1244 1232 2014-07-09T06:03:31Z GooPie4o 265 wikitext text/x-wiki {{i18n|Generic ASK Modules}} {{Module |NAME=Generic ASK Modules |MENUCONFIG={{I/O}}->Radio->Generic ASK |STATUS={{In_Development}} |PINNING=yes |ECMD= no |CONTROL6=no |DEPENDS= - |REQUIRES= - |TIMER={{occupies_timer|2}} (RX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/generic_ask https://github.com/ethersex/ethersex/tree/master/hardware/radio/generic_ask] }} [[File:Generic ask module front.jpg|200px|thumb|right|Generic ASK Module TX and RX (front)]] [[File:Generic ask module back.jpg|200px|thumb|right|Generic ASK Module TX and RX (back)]] [[File:Ask_sender.jpg|200px|thumb|right|Shematic of TX Module]] [[File:Ask_receiver.gif|200px|thumb|right|Shematic of RX Module]] These modules are sourced from China and can be bougth via [http://www.ebay.com/sch/i.html?_sacat=0&_from=R40&_sop=15&LH_BIN=1&_nkw=433Mhz+RF+Transmitter+And+Receiver+Kit&LH_PrefLoc=2&rt=nc&LH_FS=1 ebay]. '''Finally they will be used as a cheap replacement for [[RFM12]] to switch radio outlets. For details see [https://github.com/ethersex/ethersex/issues/284 Issue 284 on Github].''' ==== Technical Specifications ==== * Receiver module parameters ** Product Model: MX-05V ** Operating voltage: DC5V ** Quiescent Current: 4mA ** Receiving frequency: 433.92MHZ ** Receiver sensitivity: -105DB ** Size: 30 * 14 * 7mm ** External antenna: 32CM single core wire, wound into a spiral * Transmitter module parameters ** Product Model: MX-FS-03V ** Launch distance: 20-200 meters (different voltage, different results) ** Operating voltage: 3.5-12V ** Dimensions: 19 * 19mm ** Operating mode: AM ** Transfer rate: 4KB/s ** Transmitting power: 10mW ** Transmitting frequency: 433M ** An external antenna: 25cm ordinary multi-core or single-core line ==== Remark ==== * VCC voltage module operating voltage and good power filtering; * Great influence on the antenna module reception, preferably connected to the 1/4 wavelength of the antenna, typically 50 ohm single conductor, the length of the antenna 433M of about 17cm; * Antenna position has also affected the reception of the module, the installation, the antenna as possible straight away from the shield, high pressure, and interference source; frequency used to receive, decode and oscillation resistor should match with the transmitter. == Connection == The DATA pin of the transmitter module is named GENERIC_ASK in Ethersex's pinning. The example below uses PA0. ifdef(`conf_GENERIC_ASK', `dnl pin(GENERIC_ASK_TX, PA0, OUTPUT) ')dnl {| class="wikitable" style="left; margin-right:1em" |+ TX Module ! Pin !! Description |- | 1 || GND |- | 2 || VCC (3.5-12V) |- | 3 || DATA |} {| class="wikitable" style="left; margin-right:1em" |+ RX Module ! Pin !! Description |- | 1 || GND |- | 2 || DATA |- | 3 || DATA |- | 4 || VCC (5V) |} == Configuration == First enable the hardware and then select it in the protocol section. | | I/O ---> | | ... | | Radio ---> | | ... | | [*] Generic ASK (433MHz) | | | | Protocols ---> | | ... | | Radio ---> | | | | [*] Radio outlets (433MHz) ---> | | ... | | (Generic) Transmitter hardware | | | | [*] Pollin/Kangtai Powerswitch (IC 2272) | | | | [*] Pollin Powerswitch buried (IC 1527) | | | | [*] Tevion Powerswitch | | | | [*] Intertechno ITS-150 | | | | [*] Intertechno Self Learning | | | | [*] Oase FM Master | | == Links == * [http://www.youtube.com/watch?v=LDGr38Ie1L4 Demo] on Youtube * [http://www.electrodragon.com/wp-content/uploads/2012/04/VirtualWire.pdf Documentation of library virtualwire] * [http://www.electrodragon.com/wp-content/uploads/2012/04/KLP_Walkthrough.pdf KLP/KLPA module walkthrough] * [http://winavr.scienceprog.com/example-avr-projects/running-tx433-and-rx433-rf-modules-with-avr-microcontrollers.html Running TX433 and RX433 RF modules with AVR microcontrollers] [[Category:ASK]] 2a0ab4ca1f765d6a431f3636726a49681b32c4e6 1245 1244 2014-07-09T06:04:06Z GooPie4o 265 /* Connection */ wikitext text/x-wiki {{i18n|Generic ASK Modules}} {{Module |NAME=Generic ASK Modules |MENUCONFIG={{I/O}}->Radio->Generic ASK |STATUS={{In_Development}} |PINNING=yes |ECMD= no |CONTROL6=no |DEPENDS= - |REQUIRES= - |TIMER={{occupies_timer|2}} (RX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/generic_ask https://github.com/ethersex/ethersex/tree/master/hardware/radio/generic_ask] }} [[File:Generic ask module front.jpg|200px|thumb|right|Generic ASK Module TX and RX (front)]] [[File:Generic ask module back.jpg|200px|thumb|right|Generic ASK Module TX and RX (back)]] [[File:Ask_sender.jpg|200px|thumb|right|Shematic of TX Module]] [[File:Ask_receiver.gif|200px|thumb|right|Shematic of RX Module]] These modules are sourced from China and can be bougth via [http://www.ebay.com/sch/i.html?_sacat=0&_from=R40&_sop=15&LH_BIN=1&_nkw=433Mhz+RF+Transmitter+And+Receiver+Kit&LH_PrefLoc=2&rt=nc&LH_FS=1 ebay]. '''Finally they will be used as a cheap replacement for [[RFM12]] to switch radio outlets. For details see [https://github.com/ethersex/ethersex/issues/284 Issue 284 on Github].''' ==== Technical Specifications ==== * Receiver module parameters ** Product Model: MX-05V ** Operating voltage: DC5V ** Quiescent Current: 4mA ** Receiving frequency: 433.92MHZ ** Receiver sensitivity: -105DB ** Size: 30 * 14 * 7mm ** External antenna: 32CM single core wire, wound into a spiral * Transmitter module parameters ** Product Model: MX-FS-03V ** Launch distance: 20-200 meters (different voltage, different results) ** Operating voltage: 3.5-12V ** Dimensions: 19 * 19mm ** Operating mode: AM ** Transfer rate: 4KB/s ** Transmitting power: 10mW ** Transmitting frequency: 433M ** An external antenna: 25cm ordinary multi-core or single-core line ==== Remark ==== * VCC voltage module operating voltage and good power filtering; * Great influence on the antenna module reception, preferably connected to the 1/4 wavelength of the antenna, typically 50 ohm single conductor, the length of the antenna 433M of about 17cm; * Antenna position has also affected the reception of the module, the installation, the antenna as possible straight away from the shield, high pressure, and interference source; frequency used to receive, decode and oscillation resistor should match with the transmitter. == Connection == The DATA pin of the transmitter module is named GENERIC_ASK_TX in Ethersex's pinning. The example below uses PA0. ifdef(`conf_GENERIC_ASK', `dnl pin(GENERIC_ASK_TX, PA0, OUTPUT) ')dnl {| class="wikitable" style="left; margin-right:1em" |+ TX Module ! Pin !! Description |- | 1 || GND |- | 2 || VCC (3.5-12V) |- | 3 || DATA |} {| class="wikitable" style="left; margin-right:1em" |+ RX Module ! Pin !! Description |- | 1 || GND |- | 2 || DATA |- | 3 || DATA |- | 4 || VCC (5V) |} == Configuration == First enable the hardware and then select it in the protocol section. | | I/O ---> | | ... | | Radio ---> | | ... | | [*] Generic ASK (433MHz) | | | | Protocols ---> | | ... | | Radio ---> | | | | [*] Radio outlets (433MHz) ---> | | ... | | (Generic) Transmitter hardware | | | | [*] Pollin/Kangtai Powerswitch (IC 2272) | | | | [*] Pollin Powerswitch buried (IC 1527) | | | | [*] Tevion Powerswitch | | | | [*] Intertechno ITS-150 | | | | [*] Intertechno Self Learning | | | | [*] Oase FM Master | | == Links == * [http://www.youtube.com/watch?v=LDGr38Ie1L4 Demo] on Youtube * [http://www.electrodragon.com/wp-content/uploads/2012/04/VirtualWire.pdf Documentation of library virtualwire] * [http://www.electrodragon.com/wp-content/uploads/2012/04/KLP_Walkthrough.pdf KLP/KLPA module walkthrough] * [http://winavr.scienceprog.com/example-avr-projects/running-tx433-and-rx433-rf-modules-with-avr-microcontrollers.html Running TX433 and RX433 RF modules with AVR microcontrollers] [[Category:ASK]] a4636f8059e46d4180bb061c58e3af203bf785bb 0 360 1205 1197 2014-03-30T15:43:45Z GooPie4o 265 wikitext text/x-wiki {{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader] }} The module is based on Roland Riegel's [http://www.roland-riegel.de/sd-reader/ MMC/SD/SDHC card library] complemented by the connection to the Ethersex [[VFS|Virtual File System]]. == Connection == [[File:Sdcard adapter schaltung.png|200px|thumb|right|SD-Card Adapter Schaltung]] [[File:Sdcard adapter.jpg|200px|thumb|right|SD-Card Adapter Aufbau]] [[File:Microsd_adapter.jpg|200px|thumb|right|MicroSD-Card Adapter mit Level-Shifter aus China]] MMC and SD memory cards can be used in [[SPI]] mode relatively easily controlled with a microcontroller. In principle, there is not between SD Card and MMC many differences, but SD cards are more common, generally faster than MMCs, and have a better-implemented SPI interface. There are several variants (miniSD, microSD), which are largely compatible with the standard SD-card. The card reads the adjacent data bits with the rising clock edge, as [[SPI]] modes are thus suitable Mode 0 and Mode 3 In MMCs, the SPI mode is not precisely specified, so it does happen sometimes that the SPI mode must be selected differ depending on the card. SD cards are typically often operated with 3.3V and 5V microcontrollers. This forces a [http://www.mikrocontroller.net/articles/Pegelwandler#5V_.3C-.3E_3.3V level adjustment], because the input lines to the SD card are not 5V tolerant. [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#Bekannte_Fehler A level adjustment] with resistors is not recommended. In addition to the lines leading to the SD card, there are two other lines which lead to the SD card socket: namely, the card-detect line and the write-protect line. They serve as the name already say, to signal the physical presence of a card in the SD socket and the position of the write protect switch. If hardware SPI used, only the chip select line must be configured. The card-detect line and the write-protect line are optional and MicroSD anyway not exist. ifdef(`conf_SD_READER', ` /* port the sd-reader CS is attached to */ pin(SPI_CS_SD_READER, PB2, OUTPUT) /* uncomment and edit this if you have connected the CD (card detect) signal */ pin(SD_READER_AVAILABLE, PD4, INPUT) /* uncomment and edit this if you have connected the WP (write protected) signal */ pin(SD_READER_WR_PROTECT, PD5, INPUT) ') Another problem with the SD card is the initialization. Manages Ethersex not in a certain time to sync, so the card into the normal drops (not the SD) mode and can no longer be addressed. A solution for this is that the card receives a controllable power supply. For this purpose, we define the pinning only pin pin(SD_READER_POWERON, PB3, OUTPUT) === Connector === A cheap type of contact is probably cannibalizing a cheap card reader if you want to solder any cables directly to the card. Individually purchased connectors can usually considerably teuerer. Even [http://uanr.com/sdfloppy/ old floppy cable] can be used as cheap connectors. Parts of AT slots or connectors of 5.25-inch floppies go. If necessary, you can see the card between two rows of pin strip pinch (or solder). It's even cheaper if you use micro or mini SD cards and usually included adapter anlötet. However, anyone who wants to give up a DIY, alternatively, for relatively little money a [http://www.shop.display3000.com/elektronikmodule/sd-kartenmodul/index.html completely assembled SD adapter] available for purchase to be connected to the AVR. With this adapter already is a bidirectional signal level between the 5V levels of the control lines of the AVR and the 3.3 V level of the SD card on board. Affordable modules sourced from China are available on [http://www.ebay.com/sch/i.html?_from=R40&_sacat=0&_nkw=Micro+SD+Card+Module+SPI&rt=nc&LH_PrefLoc=2 ebay]. == Configuration == | | I/O ---> | | ... │ │ Storage ---> │ │ ... | | [*] SD/MMC-Card Reader ---> | | ... | | [ ] SDHC support | | | | [*] VFAT LFN support | | | | [ ] Read-only mode | | | | [*] Use read-timeout | | | | [*] Ping-read SD card every 10s | | | | --- ECMD Support | | | | [*] info | | | | [*] dir | | | | [*] mkdir | | | | [*] rm | | | | --- Debugging Flags | | | | [*] FAT | | | | [*] RAW | | | | [*] VFS | | | | General Setup ---> | | ... | | [*] VFS (Virtual File System) support ---> | | ... | | [*] SD/MMC-Card Filesystem | | == [[ECMD|ECMD]] == IRMP implements an [[ECMD]] interface. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == The following example writes the date, time and temperature by VFS_LOG_ALLOCA (VFS_LOG requires UIP) in the file "temp.log" as soon as the temperature has changed by more than a degree to the last measurement. For date and time CLOCK_SUPPORT must be enabled. <pre> #include <stdlib.h> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO uint8_t sign = Temperatur<0; div_t res = div(abs(Temperatur),10); VFS_LOG_ALLOCA("temp.log", 50, "%2d.%2d.%4d %2d:%02d %S%d.%d", CLOCK_DAY, CLOCK_MONTH, CLOCK_YEAR, CLOCK_HOUR, CLOCK_MIN, sign?PSTR("-"):PSTR(""),res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> d4d8cdc59ea7405f20ecf6144cb4d97085302410 1213 1205 2014-05-03T08:37:16Z GooPie4o 265 /* ECMD */ wikitext text/x-wiki {{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader] }} The module is based on Roland Riegel's [http://www.roland-riegel.de/sd-reader/ MMC/SD/SDHC card library] complemented by the connection to the Ethersex [[VFS|Virtual File System]]. == Connection == [[File:Sdcard adapter schaltung.png|200px|thumb|right|SD-Card Adapter Schaltung]] [[File:Sdcard adapter.jpg|200px|thumb|right|SD-Card Adapter Aufbau]] [[File:Microsd_adapter.jpg|200px|thumb|right|MicroSD-Card Adapter mit Level-Shifter aus China]] MMC and SD memory cards can be used in [[SPI]] mode relatively easily controlled with a microcontroller. In principle, there is not between SD Card and MMC many differences, but SD cards are more common, generally faster than MMCs, and have a better-implemented SPI interface. There are several variants (miniSD, microSD), which are largely compatible with the standard SD-card. The card reads the adjacent data bits with the rising clock edge, as [[SPI]] modes are thus suitable Mode 0 and Mode 3 In MMCs, the SPI mode is not precisely specified, so it does happen sometimes that the SPI mode must be selected differ depending on the card. SD cards are typically often operated with 3.3V and 5V microcontrollers. This forces a [http://www.mikrocontroller.net/articles/Pegelwandler#5V_.3C-.3E_3.3V level adjustment], because the input lines to the SD card are not 5V tolerant. [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#Bekannte_Fehler A level adjustment] with resistors is not recommended. In addition to the lines leading to the SD card, there are two other lines which lead to the SD card socket: namely, the card-detect line and the write-protect line. They serve as the name already say, to signal the physical presence of a card in the SD socket and the position of the write protect switch. If hardware SPI used, only the chip select line must be configured. The card-detect line and the write-protect line are optional and MicroSD anyway not exist. ifdef(`conf_SD_READER', ` /* port the sd-reader CS is attached to */ pin(SPI_CS_SD_READER, PB2, OUTPUT) /* uncomment and edit this if you have connected the CD (card detect) signal */ pin(SD_READER_AVAILABLE, PD4, INPUT) /* uncomment and edit this if you have connected the WP (write protected) signal */ pin(SD_READER_WR_PROTECT, PD5, INPUT) ') Another problem with the SD card is the initialization. Manages Ethersex not in a certain time to sync, so the card into the normal drops (not the SD) mode and can no longer be addressed. A solution for this is that the card receives a controllable power supply. For this purpose, we define the pinning only pin pin(SD_READER_POWERON, PB3, OUTPUT) === Connector === A cheap type of contact is probably cannibalizing a cheap card reader if you want to solder any cables directly to the card. Individually purchased connectors can usually considerably teuerer. Even [http://uanr.com/sdfloppy/ old floppy cable] can be used as cheap connectors. Parts of AT slots or connectors of 5.25-inch floppies go. If necessary, you can see the card between two rows of pin strip pinch (or solder). It's even cheaper if you use micro or mini SD cards and usually included adapter anlötet. However, anyone who wants to give up a DIY, alternatively, for relatively little money a [http://www.shop.display3000.com/elektronikmodule/sd-kartenmodul/index.html completely assembled SD adapter] available for purchase to be connected to the AVR. With this adapter already is a bidirectional signal level between the 5V levels of the control lines of the AVR and the 3.3 V level of the SD card on board. Affordable modules sourced from China are available on [http://www.ebay.com/sch/i.html?_from=R40&_sacat=0&_nkw=Micro+SD+Card+Module+SPI&rt=nc&LH_PrefLoc=2 ebay]. == Configuration == | | I/O ---> | | ... │ │ Storage ---> │ │ ... | | [*] SD/MMC-Card Reader ---> | | ... | | [ ] SDHC support | | | | [*] VFAT LFN support | | | | [ ] Read-only mode | | | | [*] Use read-timeout | | | | [*] Ping-read SD card every 10s | | | | --- ECMD Support | | | | [*] info | | | | [*] dir | | | | [*] mkdir | | | | [*] rm | | | | --- Debugging Flags | | | | [*] FAT | | | | [*] RAW | | | | [*] VFS | | | | General Setup ---> | | ... | | [*] VFS (Virtual File System) support ---> | | ... | | [*] SD/MMC-Card Filesystem | | == [[ECMD|ECMD]] == The SD CARD module implements an [[ECMD]] interface. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == The following example writes the date, time and temperature by VFS_LOG_ALLOCA (VFS_LOG requires UIP) in the file "temp.log" as soon as the temperature has changed by more than a degree to the last measurement. For date and time CLOCK_SUPPORT must be enabled. <pre> #include <stdlib.h> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO uint8_t sign = Temperatur<0; div_t res = div(abs(Temperatur),10); VFS_LOG_ALLOCA("temp.log", 50, "%2d.%2d.%4d %2d:%02d %S%d.%d", CLOCK_DAY, CLOCK_MONTH, CLOCK_YEAR, CLOCK_HOUR, CLOCK_MIN, sign?PSTR("-"):PSTR(""),res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> 09cfd9565eb7fb82477e23f9262f45d362364c12 6 384 1209 2014-03-31T17:00:08Z GooPie4o 265 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 385 1210 2014-03-31T17:00:34Z GooPie4o 265 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 386 1212 2014-05-02T13:56:57Z GooPie4o 265 Created page with "{{i18n|SOAP}} {{Module |NAME=SOAP |MENUCONFIG={{Protocols}}->SOAP (XML RPC) |STATUS={{stable}} |PINNING=no |ECMD=no |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/eth..." wikitext text/x-wiki {{i18n|SOAP}} {{Module |NAME=SOAP |MENUCONFIG={{Protocols}}->SOAP (XML RPC) |STATUS={{stable}} |PINNING=no |ECMD=no |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/protocols/soap https://github.com/ethersex/ethersex/tree/master/protocols/soap] }} == Usage == <source lang="perl"> #!/usr/bin/perl -w use strict; use SOAP::Lite; my $soap = SOAP::Lite -> uri('http://ethersex.de/SOAP') -> proxy('http://192.168.22.130/soap'); my $whm = $soap->whm(); print "Aktuelle Uptime des Ethersex: ", $whm, "\n"; my $time = $soap->time(); print "Aktuelle Systemzeit (Unix-Timestamp): ", $time, "\n"; </source> == Links == CPAN [http://search.cpan.org/~phred/SOAP-Lite-1.11/lib/SOAP/Lite.pm SOAP::Lite - Perl's Web Services Toolkit] [http://www.perl.com/pub/2001/01/soap.html Quick Start with SOAP] f74b1b3a88d4526088b818dfa720cdb79f853526 1214 1212 2014-05-04T17:36:59Z GooPie4o 265 wikitext text/x-wiki {{i18n|SOAP}} {{Module |NAME=SOAP |MENUCONFIG={{Protocols}}->SOAP (XML RPC) |STATUS={{stable}} |PINNING=no |ECMD=no |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/protocols/soap https://github.com/ethersex/ethersex/tree/master/protocols/soap] }} == Configuration == == Links == CPAN [http://search.cpan.org/~phred/SOAP-Lite-1.11/lib/SOAP/Lite.pm SOAP::Lite - Perl's Web Services Toolkit] [http://www.perl.com/pub/2001/01/soap.html Quick Start with SOAP] 88e056478662d585099b5e75f8bf50c1e6f262db 1216 1214 2014-05-04T17:52:19Z GooPie4o 265 wikitext text/x-wiki {{i18n|SOAP}} {{Module |NAME=SOAP |MENUCONFIG={{Protocols}}->SOAP (XML RPC) |STATUS={{stable}} |PINNING=no |ECMD=no |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/protocols/soap https://github.com/ethersex/ethersex/tree/master/protocols/soap] }} Ethersex supports the SOAP protocol over HTTP, which allows for easier communication of Ethersex with programs of any kind. The functions can be used directly in the program code with SOAP. == Configuration == First, the protocol needs to be enabled, and then the support for it in the embedded web server. | | Protocols ---> | | ... | | [*] SOAP (XML RPC) | | | | Applications ---> | | ... | | [*] HTTP Server ---> | | ... | | [*] SOAP backend | | == Client Code == The following script can be used as a starting point for your own SOAP requests. * [https://github.com/ethersex/ethersex-tools/blob/master/prot/onewire/onewire_request.php Perl] == Links == CPAN [http://search.cpan.org/~phred/SOAP-Lite-1.11/lib/SOAP/Lite.pm SOAP::Lite - Perl's Web Services Toolkit] [http://www.perl.com/pub/2001/01/soap.html Quick Start with SOAP] 303f090bda1ce0e8a2f2620208b93304a19bca9c 1218 1216 2014-05-05T10:53:54Z GooPie4o 265 wikitext text/x-wiki {{i18n|SOAP}} {{Module |NAME=SOAP |MENUCONFIG={{Protocols}}->SOAP (XML RPC) |STATUS={{stable}} |PINNING=no |ECMD=no |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/protocols/soap https://github.com/ethersex/ethersex/tree/master/protocols/soap] }} Ethersex supports the SOAP protocol over HTTP, which allows for easier communication of Ethersex with programs of any kind. The functions can be used directly in the program code with SOAP. == Configuration == First, the protocol needs to be enabled, and then the support for it in the embedded web server. | | Protocols ---> | | ... | | [*] SOAP (XML RPC) | | | | Applications ---> | | ... | | [*] HTTP Server ---> | | ... | | [*] SOAP backend | | == Client Code == The following script can be used as a starting point for your own SOAP requests. * [https://github.com/ethersex/ethersex-tools/blob/master/protocols/soap/soap_request.pl Perl] == Links == CPAN [http://search.cpan.org/~phred/SOAP-Lite-1.11/lib/SOAP/Lite.pm SOAP::Lite - Perl's Web Services Toolkit] [http://www.perl.com/pub/2001/01/soap.html Quick Start with SOAP] 5f170305f16b0d3b3a464167ae79d15f2784fd47 1221 1218 2014-05-05T11:03:23Z GooPie4o 265 wikitext text/x-wiki {{i18n|SOAP}} {{Module |NAME=SOAP |MENUCONFIG={{Protocols}}->SOAP (XML RPC) |STATUS={{stable}} |PINNING=no |ECMD=no |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/protocols/soap https://github.com/ethersex/ethersex/tree/master/protocols/soap] }} Ethersex supports the SOAP protocol over HTTP, which allows for easier communication of Ethersex with programs of any kind. The functions can be used directly in the program code with SOAP. == Configuration == First, the protocol needs to be enabled, and then the support for it in the embedded web server. | | Protocols ---> | | ... | | [*] SOAP (XML RPC) | | | | Applications ---> | | ... | | [*] HTTP Server ---> | | ... | | [*] SOAP backend | | To make Ethersex functions available for SOAP the M4 macro ''soap_rpc'' is used. The following example is from [https://github.com/ethersex/ethersex/blob/master/services/clock/clock_soap.c services/clock/clock_soap.c] /* -- Ethersex META -- soap_rpc(soap_rpc_time, "time") */ == Client Code == The following script can be used as a starting point for your own SOAP requests. * [https://github.com/ethersex/ethersex-tools/blob/master/protocols/soap/soap_request.pl Perl] == Links == CPAN [http://search.cpan.org/~phred/SOAP-Lite-1.11/lib/SOAP/Lite.pm SOAP::Lite - Perl's Web Services Toolkit] [http://www.perl.com/pub/2001/01/soap.html Quick Start with SOAP] f819c4b61bc97e7df05c2241c7ed7ad3e73db438 0 387 1215 2014-05-04T17:47:08Z GooPie4o 265 Created page with "{{i18n|SOAP}} {{Module |NAME=SOAP |MENUCONFIG={{Protocols}}->SOAP (XML RPC) |STATUS={{stable}} |PINNING=no |ECMD=no |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/eth..." wikitext text/x-wiki {{i18n|SOAP}} {{Module |NAME=SOAP |MENUCONFIG={{Protocols}}->SOAP (XML RPC) |STATUS={{stable}} |PINNING=no |ECMD=no |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/protocols/soap https://github.com/ethersex/ethersex/tree/master/protocols/soap] }} Ethersex unterstützt seit kurzem das SOAP-Protokoll über HTTP, was eine einfachere Kommunikation des Ethersex mit Programmen jedweder Art erlaubt. Bislang musste immer der Umweg über eine TCP-Verbindung auf den ECMD-Port gegangen werden und die Text Ein-/Ausgabe geparst werden. Mit SOAP können die Funktionen direkt im Programm-Code verwendet werden. == Konfiguration == Zunächst muss das Protokoll und dann die Unterstützung dafür im eingebetteten Webserver aktiviert werden. | | Protocols ---> | | ... | | [*] SOAP (XML RPC) | | | | Applications ---> | | ... | | [*] HTTP Server ---> | | ... | | [*] SOAP backend | | == Client Code == Das folgende Skript kann als Start für eigene SOAP Requests dienen: * [https://github.com/ethersex/ethersex-tools/blob/master/prot/onewire/onewire_request.php Perl] == Links == CPAN [http://search.cpan.org/~phred/SOAP-Lite-1.11/lib/SOAP/Lite.pm SOAP::Lite - Perl's Web Services Toolkit] [http://www.perl.com/pub/2001/01/soap.html Quick Start with SOAP] 43ec715fe050d39c12af07e7495ddf10fda5625e 1217 1215 2014-05-05T10:52:51Z GooPie4o 265 wikitext text/x-wiki {{i18n|SOAP}} {{Module |NAME=SOAP |MENUCONFIG={{Protocols}}->SOAP (XML RPC) |STATUS={{stable}} |PINNING=no |ECMD=no |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/protocols/soap https://github.com/ethersex/ethersex/tree/master/protocols/soap] }} Ethersex unterstützt das SOAP-Protokoll über HTTP, was eine einfachere Kommunikation des Ethersex mit Programmen jedweder Art erlaubt. Bislang musste immer der Umweg über eine TCP-Verbindung auf den ECMD-Port gegangen werden und die Text Ein-/Ausgabe geparst werden. Mit SOAP können die Funktionen direkt im Programm-Code verwendet werden. == Konfiguration == Zunächst muss das Protokoll und dann die Unterstützung dafür im eingebetteten Webserver aktiviert werden. | | Protocols ---> | | ... | | [*] SOAP (XML RPC) | | | | Applications ---> | | ... | | [*] HTTP Server ---> | | ... | | [*] SOAP backend | | == Client Code == Das folgende Skript kann als Start für eigene SOAP Requests dienen: * [https://github.com/ethersex/ethersex-tools/blob/master/prot/onewire/onewire_request.php Perl] == Links == CPAN [http://search.cpan.org/~phred/SOAP-Lite-1.11/lib/SOAP/Lite.pm SOAP::Lite - Perl's Web Services Toolkit] [http://www.perl.com/pub/2001/01/soap.html Quick Start with SOAP] b30d6931f7b80ffa238354709c997a007a4e35b0 1219 1217 2014-05-05T10:54:12Z GooPie4o 265 wikitext text/x-wiki {{i18n|SOAP}} {{Module |NAME=SOAP |MENUCONFIG={{Protocols}}->SOAP (XML RPC) |STATUS={{stable}} |PINNING=no |ECMD=no |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/protocols/soap https://github.com/ethersex/ethersex/tree/master/protocols/soap] }} Ethersex unterstützt das SOAP-Protokoll über HTTP, was eine einfachere Kommunikation des Ethersex mit Programmen jedweder Art erlaubt. Bislang musste immer der Umweg über eine TCP-Verbindung auf den ECMD-Port gegangen werden und die Text Ein-/Ausgabe geparst werden. Mit SOAP können die Funktionen direkt im Programm-Code verwendet werden. == Konfiguration == Zunächst muss das Protokoll und dann die Unterstützung dafür im eingebetteten Webserver aktiviert werden. | | Protocols ---> | | ... | | [*] SOAP (XML RPC) | | | | Applications ---> | | ... | | [*] HTTP Server ---> | | ... | | [*] SOAP backend | | == Client Code == Das folgende Skript kann als Start für eigene SOAP Requests dienen: * [https://github.com/ethersex/ethersex-tools/blob/master/protocols/soap/soap_request.pl Perl] == Links == CPAN [http://search.cpan.org/~phred/SOAP-Lite-1.11/lib/SOAP/Lite.pm SOAP::Lite - Perl's Web Services Toolkit] [http://www.perl.com/pub/2001/01/soap.html Quick Start with SOAP] 33ad38333f52dd630d4355c9abf26ac00ee34b52 1220 1219 2014-05-05T11:01:50Z GooPie4o 265 wikitext text/x-wiki {{i18n|SOAP}} {{Module |NAME=SOAP |MENUCONFIG={{Protocols}}->SOAP (XML RPC) |STATUS={{stable}} |PINNING=no |ECMD=no |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/protocols/soap https://github.com/ethersex/ethersex/tree/master/protocols/soap] }} Ethersex unterstützt das SOAP-Protokoll über HTTP, was eine einfachere Kommunikation des Ethersex mit Programmen jedweder Art erlaubt. Bislang musste immer der Umweg über eine TCP-Verbindung auf den ECMD-Port gegangen werden und die Text Ein-/Ausgabe geparst werden. Mit SOAP können die Funktionen direkt im Programm-Code verwendet werden. == Konfiguration == Zunächst muss das Protokoll und dann die Unterstützung dafür im eingebetteten Webserver aktiviert werden. | | Protocols ---> | | ... | | [*] SOAP (XML RPC) | | | | Applications ---> | | ... | | [*] HTTP Server ---> | | ... | | [*] SOAP backend | | Um Ethersex Funktionen über SOAP zur Verfügung zu stellen, existiert das M4 Makro ''soap_rpc''. Hier ein Beispiel aus [https://github.com/ethersex/ethersex/blob/master/services/clock/clock_soap.c services/clock/clock_soap.c] /* -- Ethersex META -- soap_rpc(soap_rpc_time, "time") */ == Client Code == Das folgende Skript kann als Start für eigene SOAP Requests dienen: * [https://github.com/ethersex/ethersex-tools/blob/master/protocols/soap/soap_request.pl Perl] == Links == CPAN [http://search.cpan.org/~phred/SOAP-Lite-1.11/lib/SOAP/Lite.pm SOAP::Lite - Perl's Web Services Toolkit] [http://www.perl.com/pub/2001/01/soap.html Quick Start with SOAP] 0dcdd0985eac395620b1aa867ae96ae0c363a2b4 0 338 1222 1089 2014-05-05T16:39:16Z GooPie4o 265 typo wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{I/O}}->Radio->RFM12 ASK->433MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} In ASK mode the RFM12 module is used to switch radio outlets. Alternatively you can also receive the radio transmission between the transmitter and radio socket outlet. Currently, the following systems are supported: * Self-learning systems (drive "tevion") * Systems based on the chips or PT2262/PT2272 HX2262/2272 (driver "2272") * Concealed remote dimmer with the transmitter located HS1527 chip (driver "1527") * Transmitter type Intertechno ITS-150 * Oase Inscenio FM Master system == Connection == The RFM12 is connected to the AVRlike in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FFIT signal (Pin 4) is connected to one of the INT pins of the AVR. This modul does not work in interrupt mode, so the output nRQ signal (Pin 2) can be left unconnected. The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_ASK_SENSE_USE_INT(0) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_ASK_SENSE_USE_INT defines whether FFIT is connected to INT0, INT1 or INT2 of the AVR. == Configuration == | | I/O ---> | | ... | | Radio ---> | | ... | | [*] RFM12 ASK ---> | | ... | | [*] 433MHz | | | | (0) RFM12 select | | | | [ ] Pollin/Kangtai Powerswitch (IC 2272) | | | | [ ] Pollin Powerswitch buried (IC 1527) | | | | [*] Tevion Powerswitch | | | | [ ] Intertechno ITS-150 | | | | [*] Oase FM Master | | | | [ ] External filter | | | | [-] Sensing | | == [[ECMD]] == RFM12 ASK implements an [[ECMD]] interface to control to switch radio outlets. See [[ECMD_Reference|ECMD reference]]. [[Category:RFM12]] 6fd07da1f04aa0d4e1a43cb67d33cd1dcfd563b3 1246 1222 2014-07-09T06:08:54Z GooPie4o 265 /* Configuration */ wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{I/O}}->Radio->RFM12 ASK->433MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} In ASK mode the RFM12 module is used to switch radio outlets. Alternatively you can also receive the radio transmission between the transmitter and radio socket outlet. Currently, the following systems are supported: * Self-learning systems (drive "tevion") * Systems based on the chips or PT2262/PT2272 HX2262/2272 (driver "2272") * Concealed remote dimmer with the transmitter located HS1527 chip (driver "1527") * Transmitter type Intertechno ITS-150 * Oase Inscenio FM Master system == Connection == The RFM12 is connected to the AVRlike in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FFIT signal (Pin 4) is connected to one of the INT pins of the AVR. This modul does not work in interrupt mode, so the output nRQ signal (Pin 2) can be left unconnected. The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_ASK_SENSE_USE_INT(0) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_ASK_SENSE_USE_INT defines whether FFIT is connected to INT0, INT1 or INT2 of the AVR. == Configuration == | | I/O ---> | | ... | | Radio ---> | | ... | | [*] RFM12 ASK ---> | | ... | | [*] 433MHz | | | | (0) RFM12 select | | | | Protocols ---> | | ... | | Radio ---> | | | | [*] Radio outlets (433MHz) ---> | | ... | | (RFM12) Transmitter hardware | | | | [ ] Pollin/Kangtai Powerswitch (IC 2272) | | | | [ ] Pollin Powerswitch buried (IC 1527) | | | | [*] Tevion Powerswitch | | | | [ ] Intertechno ITS-150 | | | | [*] Oase FM Master | | == [[ECMD]] == RFM12 ASK implements an [[ECMD]] interface to control to switch radio outlets. See [[ECMD_Reference|ECMD reference]]. [[Category:RFM12]] 91ce86f810800f6b9228e55cb9451a57a121235f 1247 1246 2014-07-09T06:14:56Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{Protocols}}->Radio->Radio outlets (433MHz) |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/protocols/radio/ask https://github.com/ethersex/ethersex/tree/master/protocols/radio/ask] }} In ASK mode the RFM12 module is used to switch radio outlets. Alternatively you can also receive the radio transmission between the transmitter and radio socket outlet. Currently, the following systems are supported: * Self-learning systems (drive "tevion") * Systems based on the chips or PT2262/PT2272 HX2262/2272 (driver "2272") * Concealed remote dimmer with the transmitter located HS1527 chip (driver "1527") * Transmitter type Intertechno ITS-150 * Oase Inscenio FM Master system == Connection == The RFM12 is connected to the AVRlike in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FFIT signal (Pin 4) is connected to one of the INT pins of the AVR. This modul does not work in interrupt mode, so the output nRQ signal (Pin 2) can be left unconnected. The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_ASK_SENSE_USE_INT(0) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_ASK_SENSE_USE_INT defines whether FFIT is connected to INT0, INT1 or INT2 of the AVR. == Configuration == | | I/O ---> | | ... | | Radio ---> | | ... | | [*] RFM12 ASK ---> | | ... | | [*] 433MHz | | | | (0) RFM12 select | | | | Protocols ---> | | ... | | Radio ---> | | | | [*] Radio outlets (433MHz) ---> | | ... | | (RFM12) Transmitter hardware | | | | [ ] Pollin/Kangtai Powerswitch (IC 2272) | | | | [ ] Pollin Powerswitch buried (IC 1527) | | | | [*] Tevion Powerswitch | | | | [ ] Intertechno ITS-150 | | | | [*] Oase FM Master | | == [[ECMD]] == RFM12 ASK implements an [[ECMD]] interface to control to switch radio outlets. See [[ECMD_Reference|ECMD reference]]. [[Category:RFM12]] 11540fd2585799e915bbaee22cf46d04d289b4cf 8 313 1224 812 2014-05-05T19:41:02Z Stesie 1 wikitext text/x-wiki * navigation ** mainpage|mainpage-description ** https://github.com/ethersex/ethersex|Sourcecode ** https://github.com/ethersex/ethersex/issues|Report a Bug ** currentevents-url|currentevents ** recentchanges-url|recentchanges ** randompage-url|randompage ** helppage|help * SEARCH * TOOLBOX * LANGUAGES 50fb93a678fe01008fc4434ba344734f18f306c7 1225 1224 2014-05-05T19:44:02Z Stesie 1 wikitext text/x-wiki * navigation ** mainpage|mainpage-description ** https://github.com/ethersex/ethersex|Sourcecode ** https://github.com/ethersex/ethersex/issues/new|Report a Bug ** currentevents-url|currentevents ** recentchanges-url|recentchanges ** randompage-url|randompage ** helppage|help * SEARCH * TOOLBOX * LANGUAGES 78e2f048c6468699ddb08a45538b46c2d7dda771 0 29 1233 1023 2014-06-04T15:43:32Z GooPie4o 265 /* Configuration */ wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR Receivers->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |TIMER={{occupies_timer|0}}&{{occupies_timer|2}} (RX & TX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP is a port of the [http://www.mikrocontroller.net/articles/IRMP infrared multi-protocol decoder] for [[Ethersex]]. == Connection == The reception of IR signals is performed by a receiver TSOP1736 type (or similar). This may be connected to any pin. The interrogation of the pins and the decoding of the IR protocol is done in an ISR, which occupies one 8-bit timer of the ATmegas. When sending the signal with the carrier frequency of the respective IR Protocol is [[PWM]] modulated. This is another 8-bit timer of the ATmegas (OC0/OC2) is demonstrated. On the [[Etherrape]] board takes a [[NE555]] this function, ie the option ''Use external modulator for the transmitter'' is activated. It saves a timer on the [[AVR]] is set at a carrier frequency. Example of a ATMega32 from: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Meaning: * IRMP_RX - pin the IR receiver is connected to * IRMP_USE_TIMER2 - use Timer2 for receiver, Timer0 for sender (undef = reversed) * IRMP_RX_LOW_ACTIVE - the IR receiver is low-active (undef = high-active) * IRMP_RX_LED_LOW_ACTIVE - the control LED of the receiver is switched to USS (undef = switched to GND) * IRMP_TX - pin the IR sender is connected to (=output of Timer0 or Timer2, see IRMP_USE_TIMER2)<br>'''Caution: 0A to 2A if MCU with A / B channel''' * IRMP_TX_LED_LOW_ACTIVE - the control LED of the sender is switched to USS (undef = switched to GND) == Configuration == Each supported IR protocol occupies memory of code. Therefore, one should select only the required protocols. A detailed overview of the protocols are in [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail article in the mikrocontroller forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ [ ] ORTEK │ │ [ ] TELEFUNKEN │ │ [ ] ROOMBA │ │ [ ] RCMM32 │ │ [ ] RCMM24 │ │ [ ] RCMM12 │ │ --- Debugging Flags │ │ [ ] IRMP IRMP also decodes the RC5 protocol, so that the separately [[Ethersex]] contained [[RC5]] decoder is not needed any longer. == [[ECMD]] == IRMP implements an [[ECMD]] interface for reading received and decoded IR commands and send IR commands. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == === Output received characters via [[SYSLOG|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> IRMP_READ checks for received IR code and stores it in the variables IRMP_PROTOCOL, IRMP_ADDRESS, and IRMP_COMMAND IRMP_FLAGS. Return values ​​greater than zero indicate the validity of the variables. If IRMP_FLAGS = 1 it is a repetition. === Control of [[StellaLight|Stella]]/Pins by IR commands === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> The script switches the Stella channel 0 to 255 or 0, the remote control is a Denon (Protocol 8). With ''include'' access to the Stella sources granted.<br> Instead of ''"stella_setValue (STELLA_SET_IMMEDIATELY, 0, 255);"'' ''"PIN_SET (LED)"'' and ''"PIN_CLEAR (LED)"'' can be used ([[Named_PIN|named pin]]). |Named PIN]]). === Send IR commands === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON dnl 31 = BOSE dnl 32 = A1TVBOX dnl 33 = ORTEK dnl 34 = TELEFUNKEN dnl 35 = ROOMBA IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Command 5678 to device 1234 will be send with one repetition using the NEC protocol. 82ede287a81c67739d834e2695e6d73e06bb42a8 1234 1233 2014-06-04T15:44:23Z GooPie4o 265 /* Send IR commands */ wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR Receivers->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |TIMER={{occupies_timer|0}}&{{occupies_timer|2}} (RX & TX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP is a port of the [http://www.mikrocontroller.net/articles/IRMP infrared multi-protocol decoder] for [[Ethersex]]. == Connection == The reception of IR signals is performed by a receiver TSOP1736 type (or similar). This may be connected to any pin. The interrogation of the pins and the decoding of the IR protocol is done in an ISR, which occupies one 8-bit timer of the ATmegas. When sending the signal with the carrier frequency of the respective IR Protocol is [[PWM]] modulated. This is another 8-bit timer of the ATmegas (OC0/OC2) is demonstrated. On the [[Etherrape]] board takes a [[NE555]] this function, ie the option ''Use external modulator for the transmitter'' is activated. It saves a timer on the [[AVR]] is set at a carrier frequency. Example of a ATMega32 from: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Meaning: * IRMP_RX - pin the IR receiver is connected to * IRMP_USE_TIMER2 - use Timer2 for receiver, Timer0 for sender (undef = reversed) * IRMP_RX_LOW_ACTIVE - the IR receiver is low-active (undef = high-active) * IRMP_RX_LED_LOW_ACTIVE - the control LED of the receiver is switched to USS (undef = switched to GND) * IRMP_TX - pin the IR sender is connected to (=output of Timer0 or Timer2, see IRMP_USE_TIMER2)<br>'''Caution: 0A to 2A if MCU with A / B channel''' * IRMP_TX_LED_LOW_ACTIVE - the control LED of the sender is switched to USS (undef = switched to GND) == Configuration == Each supported IR protocol occupies memory of code. Therefore, one should select only the required protocols. A detailed overview of the protocols are in [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail article in the mikrocontroller forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ [ ] ORTEK │ │ [ ] TELEFUNKEN │ │ [ ] ROOMBA │ │ [ ] RCMM32 │ │ [ ] RCMM24 │ │ [ ] RCMM12 │ │ --- Debugging Flags │ │ [ ] IRMP IRMP also decodes the RC5 protocol, so that the separately [[Ethersex]] contained [[RC5]] decoder is not needed any longer. == [[ECMD]] == IRMP implements an [[ECMD]] interface for reading received and decoded IR commands and send IR commands. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == === Output received characters via [[SYSLOG|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> IRMP_READ checks for received IR code and stores it in the variables IRMP_PROTOCOL, IRMP_ADDRESS, and IRMP_COMMAND IRMP_FLAGS. Return values ​​greater than zero indicate the validity of the variables. If IRMP_FLAGS = 1 it is a repetition. === Control of [[StellaLight|Stella]]/Pins by IR commands === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> The script switches the Stella channel 0 to 255 or 0, the remote control is a Denon (Protocol 8). With ''include'' access to the Stella sources granted.<br> Instead of ''"stella_setValue (STELLA_SET_IMMEDIATELY, 0, 255);"'' ''"PIN_SET (LED)"'' and ''"PIN_CLEAR (LED)"'' can be used ([[Named_PIN|named pin]]). |Named PIN]]). === Send IR commands === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON dnl 31 = BOSE dnl 32 = A1TVBOX dnl 33 = ORTEK dnl 34 = TELEFUNKEN dnl 35 = ROOMBA dnl 36 = RCMM32 dnl 37 = RCMM24 dnl 38 = RCMM16 IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Command 5678 to device 1234 will be send with one repetition using the NEC protocol. 1293096157e09c2c853951ce32f8db4711c63afc 1235 1234 2014-06-04T15:50:01Z GooPie4o 265 /* Send IR commands */ wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR Receivers->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |TIMER={{occupies_timer|0}}&{{occupies_timer|2}} (RX & TX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP is a port of the [http://www.mikrocontroller.net/articles/IRMP infrared multi-protocol decoder] for [[Ethersex]]. == Connection == The reception of IR signals is performed by a receiver TSOP1736 type (or similar). This may be connected to any pin. The interrogation of the pins and the decoding of the IR protocol is done in an ISR, which occupies one 8-bit timer of the ATmegas. When sending the signal with the carrier frequency of the respective IR Protocol is [[PWM]] modulated. This is another 8-bit timer of the ATmegas (OC0/OC2) is demonstrated. On the [[Etherrape]] board takes a [[NE555]] this function, ie the option ''Use external modulator for the transmitter'' is activated. It saves a timer on the [[AVR]] is set at a carrier frequency. Example of a ATMega32 from: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Meaning: * IRMP_RX - pin the IR receiver is connected to * IRMP_USE_TIMER2 - use Timer2 for receiver, Timer0 for sender (undef = reversed) * IRMP_RX_LOW_ACTIVE - the IR receiver is low-active (undef = high-active) * IRMP_RX_LED_LOW_ACTIVE - the control LED of the receiver is switched to USS (undef = switched to GND) * IRMP_TX - pin the IR sender is connected to (=output of Timer0 or Timer2, see IRMP_USE_TIMER2)<br>'''Caution: 0A to 2A if MCU with A / B channel''' * IRMP_TX_LED_LOW_ACTIVE - the control LED of the sender is switched to USS (undef = switched to GND) == Configuration == Each supported IR protocol occupies memory of code. Therefore, one should select only the required protocols. A detailed overview of the protocols are in [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail article in the mikrocontroller forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ [ ] ORTEK │ │ [ ] TELEFUNKEN │ │ [ ] ROOMBA │ │ [ ] RCMM32 │ │ [ ] RCMM24 │ │ [ ] RCMM12 │ │ --- Debugging Flags │ │ [ ] IRMP IRMP also decodes the RC5 protocol, so that the separately [[Ethersex]] contained [[RC5]] decoder is not needed any longer. == [[ECMD]] == IRMP implements an [[ECMD]] interface for reading received and decoded IR commands and send IR commands. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == === Output received characters via [[SYSLOG|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> IRMP_READ checks for received IR code and stores it in the variables IRMP_PROTOCOL, IRMP_ADDRESS, and IRMP_COMMAND IRMP_FLAGS. Return values ​​greater than zero indicate the validity of the variables. If IRMP_FLAGS = 1 it is a repetition. === Control of [[StellaLight|Stella]]/Pins by IR commands === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> The script switches the Stella channel 0 to 255 or 0, the remote control is a Denon (Protocol 8). With ''include'' access to the Stella sources granted.<br> Instead of ''"stella_setValue (STELLA_SET_IMMEDIATELY, 0, 255);"'' ''"PIN_SET (LED)"'' and ''"PIN_CLEAR (LED)"'' can be used ([[Named_PIN|named pin]]). |Named PIN]]). === Send IR commands === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 * no tx support yet dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON dnl 31 = BOSE * no tx support yet dnl 32 = A1TVBOX dnl 33 = ORTEK * no tx support yet dnl 34 = TELEFUNKEN * no tx support yet dnl 35 = ROOMBA dnl 36 = RCMM32 * no tx support yet dnl 37 = RCMM24 * no tx support yet dnl 38 = RCMM16 * no tx support yet IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Command 5678 to device 1234 will be send with one repetition using the NEC protocol. 5bafab3bdfe445fba401ed11914930d00a987816 1236 1235 2014-06-04T15:50:26Z GooPie4o 265 /* Send IR commands */ wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR Receivers->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |TIMER={{occupies_timer|0}}&{{occupies_timer|2}} (RX & TX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP is a port of the [http://www.mikrocontroller.net/articles/IRMP infrared multi-protocol decoder] for [[Ethersex]]. == Connection == The reception of IR signals is performed by a receiver TSOP1736 type (or similar). This may be connected to any pin. The interrogation of the pins and the decoding of the IR protocol is done in an ISR, which occupies one 8-bit timer of the ATmegas. When sending the signal with the carrier frequency of the respective IR Protocol is [[PWM]] modulated. This is another 8-bit timer of the ATmegas (OC0/OC2) is demonstrated. On the [[Etherrape]] board takes a [[NE555]] this function, ie the option ''Use external modulator for the transmitter'' is activated. It saves a timer on the [[AVR]] is set at a carrier frequency. Example of a ATMega32 from: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Meaning: * IRMP_RX - pin the IR receiver is connected to * IRMP_USE_TIMER2 - use Timer2 for receiver, Timer0 for sender (undef = reversed) * IRMP_RX_LOW_ACTIVE - the IR receiver is low-active (undef = high-active) * IRMP_RX_LED_LOW_ACTIVE - the control LED of the receiver is switched to USS (undef = switched to GND) * IRMP_TX - pin the IR sender is connected to (=output of Timer0 or Timer2, see IRMP_USE_TIMER2)<br>'''Caution: 0A to 2A if MCU with A / B channel''' * IRMP_TX_LED_LOW_ACTIVE - the control LED of the sender is switched to USS (undef = switched to GND) == Configuration == Each supported IR protocol occupies memory of code. Therefore, one should select only the required protocols. A detailed overview of the protocols are in [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail article in the mikrocontroller forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ [ ] ORTEK │ │ [ ] TELEFUNKEN │ │ [ ] ROOMBA │ │ [ ] RCMM32 │ │ [ ] RCMM24 │ │ [ ] RCMM12 │ │ --- Debugging Flags │ │ [ ] IRMP IRMP also decodes the RC5 protocol, so that the separately [[Ethersex]] contained [[RC5]] decoder is not needed any longer. == [[ECMD]] == IRMP implements an [[ECMD]] interface for reading received and decoded IR commands and send IR commands. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == === Output received characters via [[SYSLOG|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> IRMP_READ checks for received IR code and stores it in the variables IRMP_PROTOCOL, IRMP_ADDRESS, and IRMP_COMMAND IRMP_FLAGS. Return values ​​greater than zero indicate the validity of the variables. If IRMP_FLAGS = 1 it is a repetition. === Control of [[StellaLight|Stella]]/Pins by IR commands === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> The script switches the Stella channel 0 to 255 or 0, the remote control is a Denon (Protocol 8). With ''include'' access to the Stella sources granted.<br> Instead of ''"stella_setValue (STELLA_SET_IMMEDIATELY, 0, 255);"'' ''"PIN_SET (LED)"'' and ''"PIN_CLEAR (LED)"'' can be used ([[Named_PIN|named pin]]). |Named PIN]]). === Send IR commands === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 * no tx support yet dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON dnl 31 = BOSE * no tx support yet dnl 32 = A1TVBOX dnl 33 = ORTEK * no tx support yet dnl 34 = TELEFUNKEN * no tx support yet dnl 35 = ROOMBA dnl 36 = RCMM32 * no tx support yet dnl 37 = RCMM24 * no tx support yet dnl 38 = RCMM16 * no tx support yet IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Command 5678 to device 1234 will be send with one repetition using the NEC protocol. e913a87d0fc32e7f0f82cf1fa39f5fa490086910 1237 1236 2014-06-04T15:50:49Z GooPie4o 265 /* Send IR commands */ wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR Receivers->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |TIMER={{occupies_timer|0}}&{{occupies_timer|2}} (RX & TX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP is a port of the [http://www.mikrocontroller.net/articles/IRMP infrared multi-protocol decoder] for [[Ethersex]]. == Connection == The reception of IR signals is performed by a receiver TSOP1736 type (or similar). This may be connected to any pin. The interrogation of the pins and the decoding of the IR protocol is done in an ISR, which occupies one 8-bit timer of the ATmegas. When sending the signal with the carrier frequency of the respective IR Protocol is [[PWM]] modulated. This is another 8-bit timer of the ATmegas (OC0/OC2) is demonstrated. On the [[Etherrape]] board takes a [[NE555]] this function, ie the option ''Use external modulator for the transmitter'' is activated. It saves a timer on the [[AVR]] is set at a carrier frequency. Example of a ATMega32 from: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Meaning: * IRMP_RX - pin the IR receiver is connected to * IRMP_USE_TIMER2 - use Timer2 for receiver, Timer0 for sender (undef = reversed) * IRMP_RX_LOW_ACTIVE - the IR receiver is low-active (undef = high-active) * IRMP_RX_LED_LOW_ACTIVE - the control LED of the receiver is switched to USS (undef = switched to GND) * IRMP_TX - pin the IR sender is connected to (=output of Timer0 or Timer2, see IRMP_USE_TIMER2)<br>'''Caution: 0A to 2A if MCU with A / B channel''' * IRMP_TX_LED_LOW_ACTIVE - the control LED of the sender is switched to USS (undef = switched to GND) == Configuration == Each supported IR protocol occupies memory of code. Therefore, one should select only the required protocols. A detailed overview of the protocols are in [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail article in the mikrocontroller forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ [ ] ORTEK │ │ [ ] TELEFUNKEN │ │ [ ] ROOMBA │ │ [ ] RCMM32 │ │ [ ] RCMM24 │ │ [ ] RCMM12 │ │ --- Debugging Flags │ │ [ ] IRMP IRMP also decodes the RC5 protocol, so that the separately [[Ethersex]] contained [[RC5]] decoder is not needed any longer. == [[ECMD]] == IRMP implements an [[ECMD]] interface for reading received and decoded IR commands and send IR commands. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == === Output received characters via [[SYSLOG|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> IRMP_READ checks for received IR code and stores it in the variables IRMP_PROTOCOL, IRMP_ADDRESS, and IRMP_COMMAND IRMP_FLAGS. Return values ​​greater than zero indicate the validity of the variables. If IRMP_FLAGS = 1 it is a repetition. === Control of [[StellaLight|Stella]]/Pins by IR commands === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> The script switches the Stella channel 0 to 255 or 0, the remote control is a Denon (Protocol 8). With ''include'' access to the Stella sources granted.<br> Instead of ''"stella_setValue (STELLA_SET_IMMEDIATELY, 0, 255);"'' ''"PIN_SET (LED)"'' and ''"PIN_CLEAR (LED)"'' can be used ([[Named_PIN|named pin]]). |Named PIN]]). === Send IR commands === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 * no tx support yet dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON dnl 31 = BOSE * no tx support yet dnl 32 = A1TVBOX dnl 33 = ORTEK * no tx support yet dnl 34 = TELEFUNKEN * no tx support yet dnl 35 = ROOMBA dnl 36 = RCMM32 * no tx support yet dnl 37 = RCMM24 * no tx support yet dnl 38 = RCMM16 * no tx support yet IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Command 5678 to device 1234 will be send with one repetition using the NEC protocol. 5bafab3bdfe445fba401ed11914930d00a987816 1238 1237 2014-06-04T15:51:17Z GooPie4o 265 Undo revision 1237 by [[Special:Contributions/GooPie4o|GooPie4o]] ([[User talk:GooPie4o|talk]]) wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR Receivers->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |TIMER={{occupies_timer|0}}&{{occupies_timer|2}} (RX & TX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP is a port of the [http://www.mikrocontroller.net/articles/IRMP infrared multi-protocol decoder] for [[Ethersex]]. == Connection == The reception of IR signals is performed by a receiver TSOP1736 type (or similar). This may be connected to any pin. The interrogation of the pins and the decoding of the IR protocol is done in an ISR, which occupies one 8-bit timer of the ATmegas. When sending the signal with the carrier frequency of the respective IR Protocol is [[PWM]] modulated. This is another 8-bit timer of the ATmegas (OC0/OC2) is demonstrated. On the [[Etherrape]] board takes a [[NE555]] this function, ie the option ''Use external modulator for the transmitter'' is activated. It saves a timer on the [[AVR]] is set at a carrier frequency. Example of a ATMega32 from: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Meaning: * IRMP_RX - pin the IR receiver is connected to * IRMP_USE_TIMER2 - use Timer2 for receiver, Timer0 for sender (undef = reversed) * IRMP_RX_LOW_ACTIVE - the IR receiver is low-active (undef = high-active) * IRMP_RX_LED_LOW_ACTIVE - the control LED of the receiver is switched to USS (undef = switched to GND) * IRMP_TX - pin the IR sender is connected to (=output of Timer0 or Timer2, see IRMP_USE_TIMER2)<br>'''Caution: 0A to 2A if MCU with A / B channel''' * IRMP_TX_LED_LOW_ACTIVE - the control LED of the sender is switched to USS (undef = switched to GND) == Configuration == Each supported IR protocol occupies memory of code. Therefore, one should select only the required protocols. A detailed overview of the protocols are in [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail article in the mikrocontroller forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ [ ] ORTEK │ │ [ ] TELEFUNKEN │ │ [ ] ROOMBA │ │ [ ] RCMM32 │ │ [ ] RCMM24 │ │ [ ] RCMM12 │ │ --- Debugging Flags │ │ [ ] IRMP IRMP also decodes the RC5 protocol, so that the separately [[Ethersex]] contained [[RC5]] decoder is not needed any longer. == [[ECMD]] == IRMP implements an [[ECMD]] interface for reading received and decoded IR commands and send IR commands. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == === Output received characters via [[SYSLOG|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> IRMP_READ checks for received IR code and stores it in the variables IRMP_PROTOCOL, IRMP_ADDRESS, and IRMP_COMMAND IRMP_FLAGS. Return values ​​greater than zero indicate the validity of the variables. If IRMP_FLAGS = 1 it is a repetition. === Control of [[StellaLight|Stella]]/Pins by IR commands === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> The script switches the Stella channel 0 to 255 or 0, the remote control is a Denon (Protocol 8). With ''include'' access to the Stella sources granted.<br> Instead of ''"stella_setValue (STELLA_SET_IMMEDIATELY, 0, 255);"'' ''"PIN_SET (LED)"'' and ''"PIN_CLEAR (LED)"'' can be used ([[Named_PIN|named pin]]). |Named PIN]]). === Send IR commands === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 * no tx support yet dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON dnl 31 = BOSE * no tx support yet dnl 32 = A1TVBOX dnl 33 = ORTEK * no tx support yet dnl 34 = TELEFUNKEN * no tx support yet dnl 35 = ROOMBA dnl 36 = RCMM32 * no tx support yet dnl 37 = RCMM24 * no tx support yet dnl 38 = RCMM16 * no tx support yet IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Command 5678 to device 1234 will be send with one repetition using the NEC protocol. e913a87d0fc32e7f0f82cf1fa39f5fa490086910 1249 1238 2014-07-21T17:30:42Z GooPie4o 265 /* Configuration */ wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR Receivers->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |TIMER={{occupies_timer|0}}&{{occupies_timer|2}} (RX & TX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP is a port of the [http://www.mikrocontroller.net/articles/IRMP infrared multi-protocol decoder] for [[Ethersex]]. == Connection == The reception of IR signals is performed by a receiver TSOP1736 type (or similar). This may be connected to any pin. The interrogation of the pins and the decoding of the IR protocol is done in an ISR, which occupies one 8-bit timer of the ATmegas. When sending the signal with the carrier frequency of the respective IR Protocol is [[PWM]] modulated. This is another 8-bit timer of the ATmegas (OC0/OC2) is demonstrated. On the [[Etherrape]] board takes a [[NE555]] this function, ie the option ''Use external modulator for the transmitter'' is activated. It saves a timer on the [[AVR]] is set at a carrier frequency. Example of a ATMega32 from: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Meaning: * IRMP_RX - pin the IR receiver is connected to * IRMP_USE_TIMER2 - use Timer2 for receiver, Timer0 for sender (undef = reversed) * IRMP_RX_LOW_ACTIVE - the IR receiver is low-active (undef = high-active) * IRMP_RX_LED_LOW_ACTIVE - the control LED of the receiver is switched to USS (undef = switched to GND) * IRMP_TX - pin the IR sender is connected to (=output of Timer0 or Timer2, see IRMP_USE_TIMER2)<br>'''Caution: 0A to 2A if MCU with A / B channel''' * IRMP_TX_LED_LOW_ACTIVE - the control LED of the sender is switched to USS (undef = switched to GND) == Configuration == Each supported IR protocol occupies memory of code. Therefore, one should select only the required protocols. A detailed overview of the protocols are in [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail article in the mikrocontroller forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ [ ] ORTEK │ │ [ ] TELEFUNKEN │ │ [ ] ROOMBA │ │ [ ] RCMM32 │ │ [ ] RCMM24 │ │ [ ] RCMM12 │ │ --- Network │ │ [*] Remote IRMP │ │ (10001) UDP port (default 10001) │ │ --- Debugging Flags │ │ [ ] IRMP │ │ [ ] Remote IRMP IRMP also decodes the RC5 protocol, so that the separately [[Ethersex]] contained [[RC5]] decoder is not needed any longer. == [[ECMD]] == IRMP implements an [[ECMD]] interface for reading received and decoded IR commands and send IR commands. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == === Output received characters via [[SYSLOG|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> IRMP_READ checks for received IR code and stores it in the variables IRMP_PROTOCOL, IRMP_ADDRESS, and IRMP_COMMAND IRMP_FLAGS. Return values ​​greater than zero indicate the validity of the variables. If IRMP_FLAGS = 1 it is a repetition. === Control of [[StellaLight|Stella]]/Pins by IR commands === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> The script switches the Stella channel 0 to 255 or 0, the remote control is a Denon (Protocol 8). With ''include'' access to the Stella sources granted.<br> Instead of ''"stella_setValue (STELLA_SET_IMMEDIATELY, 0, 255);"'' ''"PIN_SET (LED)"'' and ''"PIN_CLEAR (LED)"'' can be used ([[Named_PIN|named pin]]). |Named PIN]]). === Send IR commands === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 * no tx support yet dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON dnl 31 = BOSE * no tx support yet dnl 32 = A1TVBOX dnl 33 = ORTEK * no tx support yet dnl 34 = TELEFUNKEN * no tx support yet dnl 35 = ROOMBA dnl 36 = RCMM32 * no tx support yet dnl 37 = RCMM24 * no tx support yet dnl 38 = RCMM16 * no tx support yet IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Command 5678 to device 1234 will be send with one repetition using the NEC protocol. 17f75ba6c698350267bbae9af5d524e173afe231 1250 1249 2014-07-21T17:31:44Z GooPie4o 265 wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR Receivers->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |TIMER={{occupies_timer|0}}&{{occupies_timer|2}} (RX & TX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP is a port of the [http://www.mikrocontroller.net/articles/IRMP infrared multi-protocol decoder] for [[Ethersex]]. == Connection == The reception of IR signals is performed by a receiver TSOP1736 type (or similar). This may be connected to any pin. The interrogation of the pins and the decoding of the IR protocol is done in an ISR, which occupies one 8-bit timer of the ATmegas. When sending the signal with the carrier frequency of the respective IR Protocol is [[PWM]] modulated. This is another 8-bit timer of the ATmegas (OC0/OC2) is demonstrated. On the [[Etherrape]] board takes a [[NE555]] this function, ie the option ''Use external modulator for the transmitter'' is activated. It saves a timer on the [[AVR]] is set at a carrier frequency. Example of a ATMega32 from: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Meaning: * IRMP_RX - pin the IR receiver is connected to * IRMP_USE_TIMER2 - use Timer2 for receiver, Timer0 for sender (undef = reversed) * IRMP_RX_LOW_ACTIVE - the IR receiver is low-active (undef = high-active) * IRMP_RX_LED_LOW_ACTIVE - the control LED of the receiver is switched to USS (undef = switched to GND) * IRMP_TX - pin the IR sender is connected to (=output of Timer0 or Timer2, see IRMP_USE_TIMER2)<br>'''Caution: 0A to 2A if MCU with A / B channel''' * IRMP_TX_LED_LOW_ACTIVE - the control LED of the sender is switched to USS (undef = switched to GND) == Configuration == Each supported IR protocol occupies memory of code. Therefore, one should select only the required protocols. A detailed overview of the protocols are in [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail article in the mikrocontroller forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ [ ] ORTEK │ │ [ ] TELEFUNKEN │ │ [ ] ROOMBA │ │ [ ] RCMM32 │ │ [ ] RCMM24 │ │ [ ] RCMM12 │ │ --- Network │ │ [*] Remote IRMP │ │ (10001) UDP port (default 10001) │ │ --- Debugging Flags │ │ [ ] IRMP │ │ [ ] Remote IRMP IRMP also decodes the RC5 protocol, so that the separately [[Ethersex]] contained [[RC5]] decoder is not needed any longer. == [[ECMD]] == IRMP implements an [[ECMD]] interface for reading received and decoded IR commands and send IR commands. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == === Output received characters via [[SYSLOG|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> IRMP_READ checks for received IR code and stores it in the variables IRMP_PROTOCOL, IRMP_ADDRESS, and IRMP_COMMAND IRMP_FLAGS. Return values ​​greater than zero indicate the validity of the variables. If IRMP_FLAGS = 1 it is a repetition. === Control of [[StellaLight|Stella]]/Pins by IR commands === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> The script switches the Stella channel 0 to 255 or 0, the remote control is a Denon (Protocol 8). With ''include'' access to the Stella sources granted.<br> Instead of ''"stella_setValue (STELLA_SET_IMMEDIATELY, 0, 255);"'' ''"PIN_SET (LED)"'' and ''"PIN_CLEAR (LED)"'' can be used ([[Named_PIN|named pin]]). |Named PIN]]). === Send IR commands === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 * no tx support yet dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON dnl 31 = BOSE * no tx support yet dnl 32 = A1TVBOX dnl 33 = ORTEK * no tx support yet dnl 34 = TELEFUNKEN * no tx support yet dnl 35 = ROOMBA dnl 36 = RCMM32 * no tx support yet dnl 37 = RCMM24 * no tx support yet dnl 38 = RCMM16 * no tx support yet IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Command 5678 to device 1234 will be send with one repetition using the NEC protocol. == Remote IRMP == work in progress... 10817d0d2ecc736a884af40d1d9916083a6ad8e9 0 341 1239 1187 2014-06-04T15:57:29Z GooPie4o 265 /* Connection */ wikitext text/x-wiki {{i18n|DHT}} {{Module |NAME=DHT |MENUCONFIG={{I/O}}->Humidity & temperature sensors->DHT 11/22 |STATUS={{Experimental}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/dht https://github.com/ethersex/ethersex/tree/master/hardware/dht] }} ==== DHT11/DHT21/DHT22 etc. Temperature & Humidity sensors ==== These sensors are very basic and slow, but are great for hobbyists who want to do some basic data logging. The DHT sensors are made of two parts, a capacitive humidity sensor and a thermistor. There is also a very basic chip inside that does some analog to digital conversion and spits out a digital signal with the temperature and humidity. ==== DHT11 vs DHT22 ==== There are two versions of the DHT sensor available, they look a bit similar and have the same pinout, but have different characteristics. Here are the specs: DHT11 * Ultra low cost * 3 to 5V power and I/O * 2.5mA max current use during conversion (while requesting data) * Good for 20-80% humidity readings with 5% accuracy * Good for 0-50°C temperature readings ±2°C accuracy * No more than 1 Hz sampling rate (once every second) * Body size 15.5mm x 12mm x 5.5mm * 4 pins with 0.1" spacing DHT22 * Low cost * 3 to 5V power and I/O * 2.5mA max current use during conversion (while requesting data) * Good for 0-100% humidity readings with 2-5% accuracy * Good for -40 to 125°C temperature readings ±0.5°C accuracy * No more than 0.5 Hz sampling rate (once every 2 seconds) * Body size 15.1mm x 25mm x 7.7mm * 4 pins with 0.1" spacing == Connection == Likewise, it is fairly easy to connect up to the DHT sensors. They have four pins # VCC (3 to 5V power) # Data out # Not connected # Ground Simply ignore pin 3, it is not used. You will want to place a 10K resistor between VCC and the data pin, to act as a medium-strength pull up on the data line. The data out can be connected to any port pin of the ATmega. Each sensor requires its own port pin for data input. == Configuration == Ethersex polls the sensors every n seconds. The advantage of this feature is that the reading opererates without any noticeable lags. Also it is easier to have multiple applications requesting sensor information since more request will not increase traffic. | | I/O ---> ... [*] Humidity & temperature sensors ---> ... [*] DHT 11/22 ---> | | (DHT11) Sensor type | | (30) Time between polling in 1s steps | | --- Debugging Flags | | [ ] DHT == [[ECMD]] == DHT implements an [[ECMD]] interface for reading humidity and temperature values. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == Humidity and temperature can be accessed in [[Control6]] scripts through the DHT_HUMIDITY and DHT_TEMPERATURE keywords. The values returnd are fixed point integers including one decimal. The following example calculates and outputs the dew point on a LCD once every minute. '''To output floating point values the floating point printf version is required (Makefile: LDFLAGS += -Wl,-u,vfprintf -lprintf_flt -lm).''' <source lang="text"> #include <stdio.h> #include <math.h> #include "hardware/lcd/hd44780.h" CONTROL_START THREAD(read_dht) ON ONCE CLOCK_SEC == 0 DO float a = 17.271; float b = 237.7; float temperatur = (a * DHT_TEMPERATURE) / (b + DHT_TEMPERATURE) + log(DHT_HUMIDITY/100); float taupunkt = (b * temperatur) / (a - temperatur); hd44780_clear(); hd44780_home(); fprintf_P(&lcd, PSTR("Taupunkt: %f"), taupunkt); END THREAD_END(read_dht) ON STARTUP DO THREAD_START(read_dht); END CONTROL_END </source> [[Category:Sensors]] 7f3be8a6fc9e3c076be8a38b4b8e3aa08a8a7ea0 1240 1239 2014-06-04T16:02:39Z GooPie4o 265 /* Configuration */ wikitext text/x-wiki {{i18n|DHT}} {{Module |NAME=DHT |MENUCONFIG={{I/O}}->Humidity & temperature sensors->DHT 11/22 |STATUS={{Experimental}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/dht https://github.com/ethersex/ethersex/tree/master/hardware/dht] }} ==== DHT11/DHT21/DHT22 etc. Temperature & Humidity sensors ==== These sensors are very basic and slow, but are great for hobbyists who want to do some basic data logging. The DHT sensors are made of two parts, a capacitive humidity sensor and a thermistor. There is also a very basic chip inside that does some analog to digital conversion and spits out a digital signal with the temperature and humidity. ==== DHT11 vs DHT22 ==== There are two versions of the DHT sensor available, they look a bit similar and have the same pinout, but have different characteristics. Here are the specs: DHT11 * Ultra low cost * 3 to 5V power and I/O * 2.5mA max current use during conversion (while requesting data) * Good for 20-80% humidity readings with 5% accuracy * Good for 0-50°C temperature readings ±2°C accuracy * No more than 1 Hz sampling rate (once every second) * Body size 15.5mm x 12mm x 5.5mm * 4 pins with 0.1" spacing DHT22 * Low cost * 3 to 5V power and I/O * 2.5mA max current use during conversion (while requesting data) * Good for 0-100% humidity readings with 2-5% accuracy * Good for -40 to 125°C temperature readings ±0.5°C accuracy * No more than 0.5 Hz sampling rate (once every 2 seconds) * Body size 15.1mm x 25mm x 7.7mm * 4 pins with 0.1" spacing == Connection == Likewise, it is fairly easy to connect up to the DHT sensors. They have four pins # VCC (3 to 5V power) # Data out # Not connected # Ground Simply ignore pin 3, it is not used. You will want to place a 10K resistor between VCC and the data pin, to act as a medium-strength pull up on the data line. The data out can be connected to any port pin of the ATmega. Each sensor requires its own port pin for data input. == Configuration == Ethersex polls the sensors every n seconds. The advantage of this feature is that the reading opererates without any noticeable lags. Also it is easier to have multiple applications requesting sensor information since more request will not increase traffic. | | I/O ---> ... [*] Humidity & temperature sensors ---> ... [*] DHT 11/22 ---> | | (DHT11) Sensor type | | (30) Time between polling in 1s steps | | Edit pin configuration/dht/dht_pinning.conf | | [-] SNMP support | | --- ECMD Support | | [x] temp | | [x] humid | | [x] list | | [-] list with values | | --- Debugging Flags | | [ ] DHT The module has its own pinning file ''hardware/dht/dht_pinning.conf'', that you can edit via the edit menu entry. # # DHT Configuration File # # You can assign pins and names to your sensors here. # # Keep in mind that this names must consist of alphanumeric # characters only! # # Every line starting with a hash sign (#) is a comment. # # # PIN | Name #-----+-------------------------- PB3 keller PA3 bad == [[ECMD]] == DHT implements an [[ECMD]] interface for reading humidity and temperature values. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == Humidity and temperature can be accessed in [[Control6]] scripts through the DHT_HUMIDITY and DHT_TEMPERATURE keywords. The values returnd are fixed point integers including one decimal. The following example calculates and outputs the dew point on a LCD once every minute. '''To output floating point values the floating point printf version is required (Makefile: LDFLAGS += -Wl,-u,vfprintf -lprintf_flt -lm).''' <source lang="text"> #include <stdio.h> #include <math.h> #include "hardware/lcd/hd44780.h" CONTROL_START THREAD(read_dht) ON ONCE CLOCK_SEC == 0 DO float a = 17.271; float b = 237.7; float temperatur = (a * DHT_TEMPERATURE) / (b + DHT_TEMPERATURE) + log(DHT_HUMIDITY/100); float taupunkt = (b * temperatur) / (a - temperatur); hd44780_clear(); hd44780_home(); fprintf_P(&lcd, PSTR("Taupunkt: %f"), taupunkt); END THREAD_END(read_dht) ON STARTUP DO THREAD_START(read_dht); END CONTROL_END </source> [[Category:Sensors]] 9b4f12c81bcbc0ecb3fbb5cbd4b85d6d2ef8a1af 1241 1240 2014-06-04T16:04:33Z GooPie4o 265 wikitext text/x-wiki {{i18n|DHT}} {{Module |NAME=DHT |MENUCONFIG={{I/O}}->Humidity & temperature sensors->DHT 11/22 |STATUS={{Stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/dht https://github.com/ethersex/ethersex/tree/master/hardware/dht] }} ==== DHT11/DHT21/DHT22 etc. Temperature & Humidity sensors ==== These sensors are very basic and slow, but are great for hobbyists who want to do some basic data logging. The DHT sensors are made of two parts, a capacitive humidity sensor and a thermistor. There is also a very basic chip inside that does some analog to digital conversion and spits out a digital signal with the temperature and humidity. ==== DHT11 vs DHT22 ==== There are two versions of the DHT sensor available, they look a bit similar and have the same pinout, but have different characteristics. Here are the specs: DHT11 * Ultra low cost * 3 to 5V power and I/O * 2.5mA max current use during conversion (while requesting data) * Good for 20-80% humidity readings with 5% accuracy * Good for 0-50°C temperature readings ±2°C accuracy * No more than 1 Hz sampling rate (once every second) * Body size 15.5mm x 12mm x 5.5mm * 4 pins with 0.1" spacing DHT22 * Low cost * 3 to 5V power and I/O * 2.5mA max current use during conversion (while requesting data) * Good for 0-100% humidity readings with 2-5% accuracy * Good for -40 to 125°C temperature readings ±0.5°C accuracy * No more than 0.5 Hz sampling rate (once every 2 seconds) * Body size 15.1mm x 25mm x 7.7mm * 4 pins with 0.1" spacing == Connection == Likewise, it is fairly easy to connect up to the DHT sensors. They have four pins # VCC (3 to 5V power) # Data out # Not connected # Ground Simply ignore pin 3, it is not used. You will want to place a 10K resistor between VCC and the data pin, to act as a medium-strength pull up on the data line. The data out can be connected to any port pin of the ATmega. Each sensor requires its own port pin for data input. == Configuration == Ethersex polls the sensors every n seconds. The advantage of this feature is that the reading opererates without any noticeable lags. Also it is easier to have multiple applications requesting sensor information since more request will not increase traffic. | | I/O ---> ... [*] Humidity & temperature sensors ---> ... [*] DHT 11/22 ---> | | (DHT11) Sensor type | | (30) Time between polling in 1s steps | | Edit pin configuration/dht/dht_pinning.conf | | [-] SNMP support | | --- ECMD Support | | [x] temp | | [x] humid | | [x] list | | [-] list with values | | --- Debugging Flags | | [ ] DHT The module has its own pinning file ''hardware/dht/dht_pinning.conf'', that you can edit via the edit menu entry. # # DHT Configuration File # # You can assign pins and names to your sensors here. # # Keep in mind that this names must consist of alphanumeric # characters only! # # Every line starting with a hash sign (#) is a comment. # # # PIN | Name #-----+-------------------------- PB3 keller PA3 bad == [[ECMD]] == DHT implements an [[ECMD]] interface for reading humidity and temperature values. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == Humidity and temperature can be accessed in [[Control6]] scripts through the DHT_HUMIDITY and DHT_TEMPERATURE keywords. The values returnd are fixed point integers including one decimal. The following example calculates and outputs the dew point on a LCD once every minute. '''To output floating point values the floating point printf version is required (Makefile: LDFLAGS += -Wl,-u,vfprintf -lprintf_flt -lm).''' <source lang="text"> #include <stdio.h> #include <math.h> #include "hardware/lcd/hd44780.h" CONTROL_START THREAD(read_dht) ON ONCE CLOCK_SEC == 0 DO float a = 17.271; float b = 237.7; float temperatur = (a * DHT_TEMPERATURE) / (b + DHT_TEMPERATURE) + log(DHT_HUMIDITY/100); float taupunkt = (b * temperatur) / (a - temperatur); hd44780_clear(); hd44780_home(); fprintf_P(&lcd, PSTR("Taupunkt: %f"), taupunkt); END THREAD_END(read_dht) ON STARTUP DO THREAD_START(read_dht); END CONTROL_END </source> [[Category:Sensors]] ace6c64e608943f0aff73d0a8af50d72b95bff35 1242 1241 2014-06-04T16:07:38Z GooPie4o 265 /* Control6 */ wikitext text/x-wiki {{i18n|DHT}} {{Module |NAME=DHT |MENUCONFIG={{I/O}}->Humidity & temperature sensors->DHT 11/22 |STATUS={{Stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/dht https://github.com/ethersex/ethersex/tree/master/hardware/dht] }} ==== DHT11/DHT21/DHT22 etc. Temperature & Humidity sensors ==== These sensors are very basic and slow, but are great for hobbyists who want to do some basic data logging. The DHT sensors are made of two parts, a capacitive humidity sensor and a thermistor. There is also a very basic chip inside that does some analog to digital conversion and spits out a digital signal with the temperature and humidity. ==== DHT11 vs DHT22 ==== There are two versions of the DHT sensor available, they look a bit similar and have the same pinout, but have different characteristics. Here are the specs: DHT11 * Ultra low cost * 3 to 5V power and I/O * 2.5mA max current use during conversion (while requesting data) * Good for 20-80% humidity readings with 5% accuracy * Good for 0-50°C temperature readings ±2°C accuracy * No more than 1 Hz sampling rate (once every second) * Body size 15.5mm x 12mm x 5.5mm * 4 pins with 0.1" spacing DHT22 * Low cost * 3 to 5V power and I/O * 2.5mA max current use during conversion (while requesting data) * Good for 0-100% humidity readings with 2-5% accuracy * Good for -40 to 125°C temperature readings ±0.5°C accuracy * No more than 0.5 Hz sampling rate (once every 2 seconds) * Body size 15.1mm x 25mm x 7.7mm * 4 pins with 0.1" spacing == Connection == Likewise, it is fairly easy to connect up to the DHT sensors. They have four pins # VCC (3 to 5V power) # Data out # Not connected # Ground Simply ignore pin 3, it is not used. You will want to place a 10K resistor between VCC and the data pin, to act as a medium-strength pull up on the data line. The data out can be connected to any port pin of the ATmega. Each sensor requires its own port pin for data input. == Configuration == Ethersex polls the sensors every n seconds. The advantage of this feature is that the reading opererates without any noticeable lags. Also it is easier to have multiple applications requesting sensor information since more request will not increase traffic. | | I/O ---> ... [*] Humidity & temperature sensors ---> ... [*] DHT 11/22 ---> | | (DHT11) Sensor type | | (30) Time between polling in 1s steps | | Edit pin configuration/dht/dht_pinning.conf | | [-] SNMP support | | --- ECMD Support | | [x] temp | | [x] humid | | [x] list | | [-] list with values | | --- Debugging Flags | | [ ] DHT The module has its own pinning file ''hardware/dht/dht_pinning.conf'', that you can edit via the edit menu entry. # # DHT Configuration File # # You can assign pins and names to your sensors here. # # Keep in mind that this names must consist of alphanumeric # characters only! # # Every line starting with a hash sign (#) is a comment. # # # PIN | Name #-----+-------------------------- PB3 keller PA3 bad == [[ECMD]] == DHT implements an [[ECMD]] interface for reading humidity and temperature values. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == Humidity and temperature can be accessed in [[Control6]] scripts through the DHT_HUMIDITY ''sensor number'' and DHT_TEMPERATURE ''sensor number'' keywords. The values returnd are fixed point integers including one decimal. The following example calculates and outputs the dew point on a LCD once every minute. '''To output floating point values the floating point printf version is required (Makefile: LDFLAGS += -Wl,-u,vfprintf -lprintf_flt -lm).''' <source lang="text"> #include <stdio.h> #include <math.h> #include "hardware/lcd/hd44780.h" CONTROL_START THREAD(read_dht) ON ONCE CLOCK_SEC == 0 DO float a = 17.271; float b = 237.7; float temperatur = (a * DHT_TEMPERATURE 0) / (b + DHT_TEMPERATURE 0) + log(DHT_HUMIDITY 0 /100); float taupunkt = (b * temperatur) / (a - temperatur); hd44780_clear(); hd44780_home(); fprintf_P(&lcd, PSTR("Taupunkt: %f"), taupunkt); END THREAD_END(read_dht) ON STARTUP DO THREAD_START(read_dht); END CONTROL_END </source> [[Category:Sensors]] 9b255fd66cc2f94739183d53c31aefa4a1757606 1243 1242 2014-06-04T17:48:40Z GooPie4o 265 /* Configuration */ wikitext text/x-wiki {{i18n|DHT}} {{Module |NAME=DHT |MENUCONFIG={{I/O}}->Humidity & temperature sensors->DHT 11/22 |STATUS={{Stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/dht https://github.com/ethersex/ethersex/tree/master/hardware/dht] }} ==== DHT11/DHT21/DHT22 etc. Temperature & Humidity sensors ==== These sensors are very basic and slow, but are great for hobbyists who want to do some basic data logging. The DHT sensors are made of two parts, a capacitive humidity sensor and a thermistor. There is also a very basic chip inside that does some analog to digital conversion and spits out a digital signal with the temperature and humidity. ==== DHT11 vs DHT22 ==== There are two versions of the DHT sensor available, they look a bit similar and have the same pinout, but have different characteristics. Here are the specs: DHT11 * Ultra low cost * 3 to 5V power and I/O * 2.5mA max current use during conversion (while requesting data) * Good for 20-80% humidity readings with 5% accuracy * Good for 0-50°C temperature readings ±2°C accuracy * No more than 1 Hz sampling rate (once every second) * Body size 15.5mm x 12mm x 5.5mm * 4 pins with 0.1" spacing DHT22 * Low cost * 3 to 5V power and I/O * 2.5mA max current use during conversion (while requesting data) * Good for 0-100% humidity readings with 2-5% accuracy * Good for -40 to 125°C temperature readings ±0.5°C accuracy * No more than 0.5 Hz sampling rate (once every 2 seconds) * Body size 15.1mm x 25mm x 7.7mm * 4 pins with 0.1" spacing == Connection == Likewise, it is fairly easy to connect up to the DHT sensors. They have four pins # VCC (3 to 5V power) # Data out # Not connected # Ground Simply ignore pin 3, it is not used. You will want to place a 10K resistor between VCC and the data pin, to act as a medium-strength pull up on the data line. The data out can be connected to any port pin of the ATmega. Each sensor requires its own port pin for data input. == Configuration == Ethersex polls the sensors every n seconds. The advantage of this feature is that the reading opererates without any noticeable lags. Also it is easier to have multiple applications requesting sensor information since more request will not increase traffic. | | I/O ---> ... [*] Humidity & temperature sensors ---> ... [*] DHT 11/22 ---> | | (DHT11) Sensor type | | (30) Time between polling in 1s steps | | Edit pin configuration | | [-] SNMP support | | --- ECMD Support | | [x] temp | | [x] humid | | [x] list | | [-] list with values | | --- Debugging Flags | | [ ] DHT The module has its own pinning file ''hardware/dht/dht_pinning.conf'', that you can edit via the edit menu entry. # # DHT Configuration File # # You can assign pins and names to your sensors here. # # Keep in mind that this names must consist of alphanumeric # characters only! # # Every line starting with a hash sign (#) is a comment. # # # PIN | Name #-----+-------------------------- PB3 keller PA3 bad == [[ECMD]] == DHT implements an [[ECMD]] interface for reading humidity and temperature values. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == Humidity and temperature can be accessed in [[Control6]] scripts through the DHT_HUMIDITY ''sensor number'' and DHT_TEMPERATURE ''sensor number'' keywords. The values returnd are fixed point integers including one decimal. The following example calculates and outputs the dew point on a LCD once every minute. '''To output floating point values the floating point printf version is required (Makefile: LDFLAGS += -Wl,-u,vfprintf -lprintf_flt -lm).''' <source lang="text"> #include <stdio.h> #include <math.h> #include "hardware/lcd/hd44780.h" CONTROL_START THREAD(read_dht) ON ONCE CLOCK_SEC == 0 DO float a = 17.271; float b = 237.7; float temperatur = (a * DHT_TEMPERATURE 0) / (b + DHT_TEMPERATURE 0) + log(DHT_HUMIDITY 0 /100); float taupunkt = (b * temperatur) / (a - temperatur); hd44780_clear(); hd44780_home(); fprintf_P(&lcd, PSTR("Taupunkt: %f"), taupunkt); END THREAD_END(read_dht) ON STARTUP DO THREAD_START(read_dht); END CONTROL_END </source> [[Category:Sensors]] 7791a7b8b575126ec8c526283304df95dea3e325 0 156 1248 1181 2014-07-09T06:15:46Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{Protocols}}->Radio->Radio outlets (433MHz) |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/protocols/radio/ask https://github.com/ethersex/ethersex/tree/master/protocols/radio/ask] }} RFM12 ASK schaltet Funksteckdosen verschiedener Hersteller. == Unterstützte Systeme == ===Tevion=== Funksteckdosen mit einer 'Anlern-Taste' können mit Hilfe des LERN-Buttons auf der embeded Website des etherrapes */rf.ht auf den gesendeten Hauscode programmiert werden. Erstaunlicherweise können mit diesem Modul auch die Codes der X10 Fernbedienung von Pollin gesendet werden. Eine Code-Sammlung gibts [[X10-codes|hier]]. [[Category:RFM12]] Getestet: * Tevion * MMANDOLYN LIBRA GmbH, Model No. WRC001 * X10 Pollin Best.Nr. 721 379 ===Intertechno (ITS-150)=== Bei Sender vom Typ Intertechno ITS-150 wird über einen Drehschalter auf der Rückseite der Familiencode eingestellt. Auf der Vorderseite gibt es einen Schieberegler für die Auswahl von Gruppe 1-4 sowie Ein/Aus Knöpfe für die Geräte 1-4 (siehe Bild). Die zusätzlich vorhandenen Gruppentaste funktioniert mit den Empfängern Intertechno CMR-500 nicht (deshalb nicht implementiert). [[Image:Intertechno-its150.jpg|150px]] ===2272=== Diese Steckdosen werden üblicherweise über einen Block von 10 DIP-Switches konfiguriert. Dabei wird mit den ersten fünf Schaltern der Hauscode gesetzt. Es ergeben sich also 32 mögliche Einstellungen. Die übrigen fünf Schalter geben die Adresse der Steckdose an. Bei Verwendung des mitgelieferten Senders wird jeweils einer der Adressschalter auf "1" gesetzt: In Dose A setzt man Dip 6 auf '1'; in Dose B Dip 7 auf '1'... Bei Ansteuerung mit dem Ethersex-System besteht diese Einschränkung nicht, so dass hier 32 verschiedene Adressen möglich sind. Getestet: {|class=wikitable |[http://www.elro.eu/uploads/products/img/_w200/AB440RA_1.jpg] |[[Image:Duewiaktor.jpg|134px]] |[[Image:Globusaktoren.jpg|134px]] |[[Image:Kangtai2605.jpg|101px]] |[[Image:Kangtai6899s.jpg|100px]] |- |valign=top|ELRO AB440R |valign=top|Düwi Modell 0369-3 |valign=top|Kangtai<br>v. Globus |valign=top|Kangtai<br>Model 2605 |valign=top|Kangtai<br>Model 6899s<br>[[Warnung vor Kangtai 6899s|'''Warnung!''']] |- |Delay 100 |Delay 60 |Delay 72 |Delay 72 |Delay 72 |} ====Funkleuchten lassen sich auch schalten!==== Neben den hier aufgeführten Funksteckdosen, lassen sich mit diesem Modul auch wunderbar diverse "neumodische" Funk-Leuchten, wie man sie aus Einrichtungshäusern kennt schalten. Die Fernbedienungen der Leuchten arbeiten dabei nicht mit dem 2262 Codierchip, sondern mit dem W0369DGP Codierchip. Dieser codiert genau wie der 2262 jedoch ist die Aufteilung der Codierbits (DIP-Schalter; in meinem Fall Lötbrücken) auf Hauscode und Gerätecode anders als bei den Funk Steckdosen. Die ersten 8 Codierbits sind sowohl in der Fernbedienung als auch in der Leuchte als Geräteadresse über Lötbrücken fest codiert. Dabei ist zu beachten, dass nur diese 8 Bits tri-state sind, also den Zustand "0", "1" oder "f" haben dürfen. Die weiteren 4 Bits sind die Schaltbefehle. WICHTIG: Die 4 Schalt-Bits können nur "0" oder "1" sein. === 1527 === Anlernbare Unterputz-Dimmer (zB. Pollin Funkdimmerset FD-UP003) mit Fernbedienung. Die mitgelieferte Fernbedienung besitzt einen HS1527 Encoder (baugleich RT1527/ EV1527/FP1527/SC1527). Der gesendete Code bestehtaus 24 Bits, welche per ASK gesendet werden. Davon sind die ersten 20 Bits fest programmiert - der Hauscode sozusagen. Die letzten 4 Bits sind der eigentliche Schalt-Befehl. Getestet: {|class=wikitable |[[Image:FD-UP003.jpg‎|150px|Pollin Electronic FD-UP003]] |- |valign=top|Pollin FD-UP003<br>[[Hinweis FD-UP003|'''Hinweis!''']] |} === Oase Inscenio FM Master === Das Baukastensystem für Gartensteckdosen der Serie [http://www.oase-livingwater.com/de_DE/wasser-garten/produkte/illumination-und-strom/strommanagement/inscenio.html InScenio] organisiert die gesamte Garten- und Teichtechnik. == Anschluss == == Konfiguration == == [[ECMD]] == RFM12 ASK implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle zur Steuerung von Funksteckdosen. Siehe [[ECMD_Reference|ECMD Referenz]]. 37081d790378a1689add72bd329460d81cb8f601 0 30 1251 1022 2014-07-23T06:44:05Z GooPie4o 265 /* Konfiguration */ wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR Receivers->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |TIMER={{occupies_timer|0}}&{{occupies_timer|2}} (RX & TX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP ist eine Portierung des [http://www.mikrocontroller.net/articles/IRMP Infrarot-Multiprotokoll-Decoders] nach [[Ethersex]]. == Anschluss == Der Empfang der IR-Signale erfolgt durch einen Empfänger vom Typ TSOP1736 (oder ähnlich). Dieser kann an einem beliebigen Pin angeschlossen werden. Die Abfrage des Pins und die Dekodierung des IR-Protokolls erfolgt in einer ISR, die einen 8-Bit-Timer des ATMEGAs belegt. Beim Senden wird das Signal mit der Trägerfrequenz des jeweiligen IR-Protokolls über [[PWM_(Deutsch)|PWM]] moduliert. Dazu wird ein weiterer 8-Bit Timer des ATMEGAs (OC0/OC2) belegt. Auf dem '''[[Etherape_(Deutsch)|Etherrape]]'''-Board übernimmt ein [[NE555_(Deutsch)|NE555]] diese Funktion, d.h. die Option ''Use external modulator for sender'' ist zu aktivieren. Man spart einen Timer des [[AVR_(Deutsch)|AVR]] und ist auf eine Trägerfrequenz festgelegt. Beispiel für einen ATMega32 aus: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Bedeutung: * IRMP_RX - Pin an dem der IR-Empfänger angeschlossen ist * IRMP_USE_TIMER2 - benutze Timer2 für den Empfang, Timer0 für das Senden (undef = umgekehrt) * IRMP_RX_LOW_ACTIVE - der IR-Empfänger ist Low-Aktiv (undef = High-aktiv) * IRMP_RX_LED_LOW_ACTIVE - die Kontroll-LED des Empfängers ist gegen USS geschaltet (undef = gegen GND geschaltet) * IRMP_TX - Pin an dem der IR-Sender angschlossen ist (=Ausgang des Timer0 oder Timer2, vgl. IRMP_USE_TIMER2)<br>'''Achtung: 0A bzw 2A bei MCU mit A/B Kanal''' * IRMP_TX_LED_LOW_ACTIVE - die Kontroll-LED des Senders ist gegen USS geschaltet (undef = gegen GND geschaltet) == Konfiguration == Jedes unterstützte IR-Protokoll "verbrät" Speicher an Code. Deshalb sollte man nur die benötigten Protokolle auswählen. Eine detailierte Übersicht über die Protokolle gibt der [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail Artikel im Mikrocontroller Forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ [ ] ORTEK │ │ [ ] TELEFUNKEN │ │ [ ] ROOMBA │ │ --- Network │ │ [*] Remote IRMP │ │ (10001) UDP port (default 10001) │ │ --- Debugging Flags │ │ [ ] IRMP │ │ [ ] Remote IRMP IRMP dekodiert auch das RC5-Protokoll, so dass der separat in [[Ethersex_(Deutsch)|Ethersex]] enthaltene [[RC5_(Deutsch)|RC5]]-Dekoder nicht länger benötigt wird. == [[ECMD_(Deutsch)|ECMD]] == IRMP implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle zum Auslesen empfangener und dekodierter IR-Kommandos und zum Senden von IR-Kommandos. Siehe [[ECMD_Reference|ECMD Referenz]]. == [[Control6_(Deutsch)|Control6]] == === Ausgabe empfangener IR-Zeichen via [[SYSLOG_(Deutsch)|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> Mit IRMP_READ wird auf empfangenen IR-Code geprüft und dieser in die Variablen IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND und IRMP_FLAGS gespeichert. Rückgabewerte größer Null signalisieren die Gültigkeit der Variablen. Bei IRMP_FLAGS=1 handelt es sich um eine Wiederholung. === Steuern von [[StellaLight_(Deutsch)|Stella]]/Pins durch IR-Zeichen === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> Das Script schaltet den Stella Channel 0 auf 255 oder auf 0, die Fernbedienung ist hier eine Denon (Protocol 8). Mit ''include'' wurde dem Script der Zugriff auf die Stellasourcen gestattet.<br> Statt ''"stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255);"'' kann auch ''"PIN_SET(LED)"'' und ''"PIN_CLEAR(LED)"'' verwendet werden ([[Named_PIN_(Deutsch)|Named PIN]]). === Senden von IR-Zeichen === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 * no tx support yet dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON * no tx support yet dnl 31 = BOSE dnl 32 = A1TVBOX dnl 33 = ORTEK dnl 34 = TELEFUNKEN dnl 35 = ROOMBA IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Kommando 5678 an Gerät 1234 wird mit einer Wiederholung im NEC-Protokoll gesendet. dc6b665c101f6c2d965dd6f870562e46a1ff74c2 0 29 1252 1250 2014-07-23T06:56:32Z GooPie4o 265 /* Remote IRMP */ wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR Receivers->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |TIMER={{occupies_timer|0}}&{{occupies_timer|2}} (RX & TX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP is a port of the [http://www.mikrocontroller.net/articles/IRMP infrared multi-protocol decoder] for [[Ethersex]]. == Connection == The reception of IR signals is performed by a receiver TSOP1736 type (or similar). This may be connected to any pin. The interrogation of the pins and the decoding of the IR protocol is done in an ISR, which occupies one 8-bit timer of the ATmegas. When sending the signal with the carrier frequency of the respective IR Protocol is [[PWM]] modulated. This is another 8-bit timer of the ATmegas (OC0/OC2) is demonstrated. On the [[Etherrape]] board takes a [[NE555]] this function, ie the option ''Use external modulator for the transmitter'' is activated. It saves a timer on the [[AVR]] is set at a carrier frequency. Example of a ATMega32 from: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Meaning: * IRMP_RX - pin the IR receiver is connected to * IRMP_USE_TIMER2 - use Timer2 for receiver, Timer0 for sender (undef = reversed) * IRMP_RX_LOW_ACTIVE - the IR receiver is low-active (undef = high-active) * IRMP_RX_LED_LOW_ACTIVE - the control LED of the receiver is switched to USS (undef = switched to GND) * IRMP_TX - pin the IR sender is connected to (=output of Timer0 or Timer2, see IRMP_USE_TIMER2)<br>'''Caution: 0A to 2A if MCU with A / B channel''' * IRMP_TX_LED_LOW_ACTIVE - the control LED of the sender is switched to USS (undef = switched to GND) == Configuration == Each supported IR protocol occupies memory of code. Therefore, one should select only the required protocols. A detailed overview of the protocols are in [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail article in the mikrocontroller forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ [ ] ORTEK │ │ [ ] TELEFUNKEN │ │ [ ] ROOMBA │ │ [ ] RCMM32 │ │ [ ] RCMM24 │ │ [ ] RCMM12 │ │ --- Network │ │ [*] Remote IRMP │ │ (10001) UDP port (default 10001) │ │ --- Debugging Flags │ │ [ ] IRMP │ │ [ ] Remote IRMP IRMP also decodes the RC5 protocol, so that the separately [[Ethersex]] contained [[RC5]] decoder is not needed any longer. == [[ECMD]] == IRMP implements an [[ECMD]] interface for reading received and decoded IR commands and send IR commands. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == === Output received characters via [[SYSLOG|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> IRMP_READ checks for received IR code and stores it in the variables IRMP_PROTOCOL, IRMP_ADDRESS, and IRMP_COMMAND IRMP_FLAGS. Return values ​​greater than zero indicate the validity of the variables. If IRMP_FLAGS = 1 it is a repetition. === Control of [[StellaLight|Stella]]/Pins by IR commands === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> The script switches the Stella channel 0 to 255 or 0, the remote control is a Denon (Protocol 8). With ''include'' access to the Stella sources granted.<br> Instead of ''"stella_setValue (STELLA_SET_IMMEDIATELY, 0, 255);"'' ''"PIN_SET (LED)"'' and ''"PIN_CLEAR (LED)"'' can be used ([[Named_PIN|named pin]]). |Named PIN]]). === Send IR commands === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 * no tx support yet dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON dnl 31 = BOSE * no tx support yet dnl 32 = A1TVBOX dnl 33 = ORTEK * no tx support yet dnl 34 = TELEFUNKEN * no tx support yet dnl 35 = ROOMBA dnl 36 = RCMM32 * no tx support yet dnl 37 = RCMM24 * no tx support yet dnl 38 = RCMM16 * no tx support yet IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Command 5678 to device 1234 will be send with one repetition using the NEC protocol. == Remote IRMP == Control your HiFi equipment with your smartphone. This is an implementation of the [https://www.mikrocontroller.net/articles/Remote_IRMP Remote IRMP protocol ] in [[Ethersex]]. 35235c7588a2d122a2c0aa899bc2614435bc828d 1255 1252 2014-07-23T07:00:30Z GooPie4o 265 /* Remote IRMP */ wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR Receivers->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |TIMER={{occupies_timer|0}}&{{occupies_timer|2}} (RX & TX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP is a port of the [http://www.mikrocontroller.net/articles/IRMP infrared multi-protocol decoder] for [[Ethersex]]. == Connection == The reception of IR signals is performed by a receiver TSOP1736 type (or similar). This may be connected to any pin. The interrogation of the pins and the decoding of the IR protocol is done in an ISR, which occupies one 8-bit timer of the ATmegas. When sending the signal with the carrier frequency of the respective IR Protocol is [[PWM]] modulated. This is another 8-bit timer of the ATmegas (OC0/OC2) is demonstrated. On the [[Etherrape]] board takes a [[NE555]] this function, ie the option ''Use external modulator for the transmitter'' is activated. It saves a timer on the [[AVR]] is set at a carrier frequency. Example of a ATMega32 from: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Meaning: * IRMP_RX - pin the IR receiver is connected to * IRMP_USE_TIMER2 - use Timer2 for receiver, Timer0 for sender (undef = reversed) * IRMP_RX_LOW_ACTIVE - the IR receiver is low-active (undef = high-active) * IRMP_RX_LED_LOW_ACTIVE - the control LED of the receiver is switched to USS (undef = switched to GND) * IRMP_TX - pin the IR sender is connected to (=output of Timer0 or Timer2, see IRMP_USE_TIMER2)<br>'''Caution: 0A to 2A if MCU with A / B channel''' * IRMP_TX_LED_LOW_ACTIVE - the control LED of the sender is switched to USS (undef = switched to GND) == Configuration == Each supported IR protocol occupies memory of code. Therefore, one should select only the required protocols. A detailed overview of the protocols are in [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail article in the mikrocontroller forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ [ ] ORTEK │ │ [ ] TELEFUNKEN │ │ [ ] ROOMBA │ │ [ ] RCMM32 │ │ [ ] RCMM24 │ │ [ ] RCMM12 │ │ --- Network │ │ [*] Remote IRMP │ │ (10001) UDP port (default 10001) │ │ --- Debugging Flags │ │ [ ] IRMP │ │ [ ] Remote IRMP IRMP also decodes the RC5 protocol, so that the separately [[Ethersex]] contained [[RC5]] decoder is not needed any longer. == [[ECMD]] == IRMP implements an [[ECMD]] interface for reading received and decoded IR commands and send IR commands. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == === Output received characters via [[SYSLOG|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> IRMP_READ checks for received IR code and stores it in the variables IRMP_PROTOCOL, IRMP_ADDRESS, and IRMP_COMMAND IRMP_FLAGS. Return values ​​greater than zero indicate the validity of the variables. If IRMP_FLAGS = 1 it is a repetition. === Control of [[StellaLight|Stella]]/Pins by IR commands === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> The script switches the Stella channel 0 to 255 or 0, the remote control is a Denon (Protocol 8). With ''include'' access to the Stella sources granted.<br> Instead of ''"stella_setValue (STELLA_SET_IMMEDIATELY, 0, 255);"'' ''"PIN_SET (LED)"'' and ''"PIN_CLEAR (LED)"'' can be used ([[Named_PIN|named pin]]). |Named PIN]]). === Send IR commands === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 * no tx support yet dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON dnl 31 = BOSE * no tx support yet dnl 32 = A1TVBOX dnl 33 = ORTEK * no tx support yet dnl 34 = TELEFUNKEN * no tx support yet dnl 35 = ROOMBA dnl 36 = RCMM32 * no tx support yet dnl 37 = RCMM24 * no tx support yet dnl 38 = RCMM16 * no tx support yet IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Command 5678 to device 1234 will be send with one repetition using the NEC protocol. == Remote IRMP == This is an implementation of the [https://www.mikrocontroller.net/articles/Remote_IRMP Remote IRMP protocol ] in [[Ethersex]]. Control your HiFi equipment with your smartphone. 44f67795b3cf82efb1f6485da2c1257c305c266d 1257 1255 2014-07-23T07:04:50Z GooPie4o 265 wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR Receivers->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |TIMER={{occupies_timer|0}}&{{occupies_timer|2}} (RX & TX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP is a port of the [http://www.mikrocontroller.net/articles/IRMP infrared multi-protocol decoder] for [[Ethersex]]. == Connection == The reception of IR signals is performed by a receiver TSOP1736 type (or similar). This may be connected to any pin. The interrogation of the pins and the decoding of the IR protocol is done in an ISR, which occupies one 8-bit timer of the ATmegas. When sending the signal with the carrier frequency of the respective IR Protocol is [[PWM]] modulated. This is another 8-bit timer of the ATmegas (OC0/OC2) is demonstrated. On the [[Etherrape]] board takes a [[NE555]] this function, ie the option ''Use external modulator for the transmitter'' is activated. It saves a timer on the [[AVR]] is set at a carrier frequency. Example of a ATMega32 from: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Meaning: * IRMP_RX - pin the IR receiver is connected to * IRMP_USE_TIMER2 - use Timer2 for receiver, Timer0 for sender (undef = reversed) * IRMP_RX_LOW_ACTIVE - the IR receiver is low-active (undef = high-active) * IRMP_RX_LED_LOW_ACTIVE - the control LED of the receiver is switched to USS (undef = switched to GND) * IRMP_TX - pin the IR sender is connected to (=output of Timer0 or Timer2, see IRMP_USE_TIMER2)<br>'''Caution: 0A to 2A if MCU with A / B channel''' * IRMP_TX_LED_LOW_ACTIVE - the control LED of the sender is switched to USS (undef = switched to GND) == Configuration == Each supported IR protocol occupies memory of code. Therefore, one should select only the required protocols. A detailed overview of the protocols are in [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail article in the mikrocontroller forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ [ ] ORTEK │ │ [ ] TELEFUNKEN │ │ [ ] ROOMBA │ │ [ ] RCMM32 │ │ [ ] RCMM24 │ │ [ ] RCMM12 │ │ --- Network │ │ [*] Remote IRMP │ │ (10001) UDP port (default 10001) │ │ --- Debugging Flags │ │ [ ] IRMP │ │ [ ] Remote IRMP IRMP also decodes the RC5 protocol, so that the separately [[Ethersex]] contained [[RC5]] decoder is not needed any longer. == [[ECMD]] == IRMP implements an [[ECMD]] interface for reading received and decoded IR commands and send IR commands. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == === Output received characters via [[SYSLOG|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> IRMP_READ checks for received IR code and stores it in the variables IRMP_PROTOCOL, IRMP_ADDRESS, and IRMP_COMMAND IRMP_FLAGS. Return values ​​greater than zero indicate the validity of the variables. If IRMP_FLAGS = 1 it is a repetition. === Control of [[StellaLight|Stella]]/Pins by IR commands === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> The script switches the Stella channel 0 to 255 or 0, the remote control is a Denon (Protocol 8). With ''include'' access to the Stella sources granted.<br> Instead of ''"stella_setValue (STELLA_SET_IMMEDIATELY, 0, 255);"'' ''"PIN_SET (LED)"'' and ''"PIN_CLEAR (LED)"'' can be used ([[Named_PIN|named pin]]). |Named PIN]]). === Send IR commands === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 * no tx support yet dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON dnl 31 = BOSE * no tx support yet dnl 32 = A1TVBOX dnl 33 = ORTEK * no tx support yet dnl 34 = TELEFUNKEN * no tx support yet dnl 35 = ROOMBA dnl 36 = RCMM32 * no tx support yet dnl 37 = RCMM24 * no tx support yet dnl 38 = RCMM16 * no tx support yet IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Command 5678 to device 1234 will be send with one repetition using the NEC protocol. == Remote IRMP == [[File:Remote_buttler.png|200px|thumb|right|Android App]] This is an implementation of the [https://www.mikrocontroller.net/articles/Remote_IRMP Remote IRMP protocol ] in [[Ethersex]]. Control your HiFi equipment with your smartphone. ffcf91ae0d1b09226af14dbe8583aa30bfe3e371 1289 1257 2014-08-12T11:49:52Z Coffee 722 Edit for clarity that pins other than OC0/OC2 can not be used to send IR Signals. wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR Receivers->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |TIMER={{occupies_timer|0}}&{{occupies_timer|2}} (RX & TX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP is a port of the [http://www.mikrocontroller.net/articles/IRMP infrared multi-protocol decoder] for [[Ethersex]]. == Connection == The reception of IR signals is performed by a receiver TSOP1736 type (or similar). This may be connected to any pin. The interrogation of the pins and the decoding of the IR protocol is done in an ISR, which occupies one 8-bit timer of the ATmegas. When sending the signal with the carrier frequency of the respective IR Protocol is [[PWM]] modulated. This is another 8-bit timer of the ATmegas (OC0/OC2) is demonstrated. On the [[Etherrape]] board takes a [[NE555]] this function, ie the option ''Use external modulator for the transmitter'' is activated. It saves a timer on the [[AVR]] is set at a carrier frequency. Example of a ATMega32 from: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Meaning: * IRMP_RX - pin the IR receiver is connected to * IRMP_USE_TIMER2 - use Timer2 for receiver, Timer0 for sender (undef = reversed) * IRMP_RX_LOW_ACTIVE - the IR receiver is low-active (undef = high-active) * IRMP_RX_LED_LOW_ACTIVE - the control LED of the receiver is switched to USS (undef = switched to GND) * IRMP_TX - pin the IR sender is connected to (=output of Timer0 or Timer2, see IRMP_USE_TIMER2)<br>'''Caution: 0A to 2A if MCU with A / B channel''' Pins other than OC0 or 0C2 can not be used. Trying to do so will fail without an error message. * IRMP_TX_LED_LOW_ACTIVE - the control LED of the sender is switched to USS (undef = switched to GND) == Configuration == Each supported IR protocol occupies memory of code. Therefore, one should select only the required protocols. A detailed overview of the protocols are in [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail article in the mikrocontroller forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ [ ] ORTEK │ │ [ ] TELEFUNKEN │ │ [ ] ROOMBA │ │ [ ] RCMM32 │ │ [ ] RCMM24 │ │ [ ] RCMM12 │ │ --- Network │ │ [*] Remote IRMP │ │ (10001) UDP port (default 10001) │ │ --- Debugging Flags │ │ [ ] IRMP │ │ [ ] Remote IRMP IRMP also decodes the RC5 protocol, so that the separately [[Ethersex]] contained [[RC5]] decoder is not needed any longer. == [[ECMD]] == IRMP implements an [[ECMD]] interface for reading received and decoded IR commands and send IR commands. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == === Output received characters via [[SYSLOG|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> IRMP_READ checks for received IR code and stores it in the variables IRMP_PROTOCOL, IRMP_ADDRESS, and IRMP_COMMAND IRMP_FLAGS. Return values ​​greater than zero indicate the validity of the variables. If IRMP_FLAGS = 1 it is a repetition. === Control of [[StellaLight|Stella]]/Pins by IR commands === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> The script switches the Stella channel 0 to 255 or 0, the remote control is a Denon (Protocol 8). With ''include'' access to the Stella sources granted.<br> Instead of ''"stella_setValue (STELLA_SET_IMMEDIATELY, 0, 255);"'' ''"PIN_SET (LED)"'' and ''"PIN_CLEAR (LED)"'' can be used ([[Named_PIN|named pin]]). |Named PIN]]). === Send IR commands === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 * no tx support yet dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON dnl 31 = BOSE * no tx support yet dnl 32 = A1TVBOX dnl 33 = ORTEK * no tx support yet dnl 34 = TELEFUNKEN * no tx support yet dnl 35 = ROOMBA dnl 36 = RCMM32 * no tx support yet dnl 37 = RCMM24 * no tx support yet dnl 38 = RCMM16 * no tx support yet IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Command 5678 to device 1234 will be send with one repetition using the NEC protocol. == Remote IRMP == [[File:Remote_buttler.png|200px|thumb|right|Android App]] This is an implementation of the [https://www.mikrocontroller.net/articles/Remote_IRMP Remote IRMP protocol ] in [[Ethersex]]. Control your HiFi equipment with your smartphone. 34fcaf3b2315acd49e7ddf43696af90fe32e74ab 1290 1289 2014-08-12T11:54:00Z Coffee 722 correct previous revision wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR Receivers->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |TIMER={{occupies_timer|0}}&{{occupies_timer|2}} (RX & TX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP is a port of the [http://www.mikrocontroller.net/articles/IRMP infrared multi-protocol decoder] for [[Ethersex]]. == Connection == The reception of IR signals is performed by a receiver TSOP1736 type (or similar). This may be connected to any pin. The interrogation of the pins and the decoding of the IR protocol is done in an ISR, which occupies one 8-bit timer of the ATmegas. When sending the signal with the carrier frequency of the respective IR Protocol is [[PWM]] modulated. This is another 8-bit timer of the ATmegas (OC0/OC2) is demonstrated. On the [[Etherrape]] board takes a [[NE555]] this function, ie the option ''Use external modulator for the transmitter'' is activated. It saves a timer on the [[AVR]] is set at a carrier frequency. Example of a ATMega32 from: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Meaning: * IRMP_RX - pin the IR receiver is connected to * IRMP_USE_TIMER2 - use Timer2 for receiver, Timer0 for sender (undef = reversed) * IRMP_RX_LOW_ACTIVE - the IR receiver is low-active (undef = high-active) * IRMP_RX_LED_LOW_ACTIVE - the control LED of the receiver is switched to USS (undef = switched to GND) * IRMP_TX - pin the IR sender is connected to (=output of Timer0 or Timer2, see IRMP_USE_TIMER2)<br>'''Caution: 0A to 2A if MCU with A / B channel''' Without an external modulator, pins other than OC0 or 0C2 can not be used. Trying to do so will fail without an error message. * IRMP_TX_LED_LOW_ACTIVE - the control LED of the sender is switched to USS (undef = switched to GND) == Configuration == Each supported IR protocol occupies memory of code. Therefore, one should select only the required protocols. A detailed overview of the protocols are in [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail article in the mikrocontroller forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ [ ] ORTEK │ │ [ ] TELEFUNKEN │ │ [ ] ROOMBA │ │ [ ] RCMM32 │ │ [ ] RCMM24 │ │ [ ] RCMM12 │ │ --- Network │ │ [*] Remote IRMP │ │ (10001) UDP port (default 10001) │ │ --- Debugging Flags │ │ [ ] IRMP │ │ [ ] Remote IRMP IRMP also decodes the RC5 protocol, so that the separately [[Ethersex]] contained [[RC5]] decoder is not needed any longer. == [[ECMD]] == IRMP implements an [[ECMD]] interface for reading received and decoded IR commands and send IR commands. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == === Output received characters via [[SYSLOG|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> IRMP_READ checks for received IR code and stores it in the variables IRMP_PROTOCOL, IRMP_ADDRESS, and IRMP_COMMAND IRMP_FLAGS. Return values ​​greater than zero indicate the validity of the variables. If IRMP_FLAGS = 1 it is a repetition. === Control of [[StellaLight|Stella]]/Pins by IR commands === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> The script switches the Stella channel 0 to 255 or 0, the remote control is a Denon (Protocol 8). With ''include'' access to the Stella sources granted.<br> Instead of ''"stella_setValue (STELLA_SET_IMMEDIATELY, 0, 255);"'' ''"PIN_SET (LED)"'' and ''"PIN_CLEAR (LED)"'' can be used ([[Named_PIN|named pin]]). |Named PIN]]). === Send IR commands === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 * no tx support yet dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON dnl 31 = BOSE * no tx support yet dnl 32 = A1TVBOX dnl 33 = ORTEK * no tx support yet dnl 34 = TELEFUNKEN * no tx support yet dnl 35 = ROOMBA dnl 36 = RCMM32 * no tx support yet dnl 37 = RCMM24 * no tx support yet dnl 38 = RCMM16 * no tx support yet IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Command 5678 to device 1234 will be send with one repetition using the NEC protocol. == Remote IRMP == [[File:Remote_buttler.png|200px|thumb|right|Android App]] This is an implementation of the [https://www.mikrocontroller.net/articles/Remote_IRMP Remote IRMP protocol ] in [[Ethersex]]. Control your HiFi equipment with your smartphone. bec33f574af60b7301b7ff8390352888a28d442d 0 30 1253 1251 2014-07-23T06:58:57Z GooPie4o 265 wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR Receivers->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |TIMER={{occupies_timer|0}}&{{occupies_timer|2}} (RX & TX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP ist eine Portierung des [http://www.mikrocontroller.net/articles/IRMP Infrarot-Multiprotokoll-Decoders] nach [[Ethersex]]. == Anschluss == Der Empfang der IR-Signale erfolgt durch einen Empfänger vom Typ TSOP1736 (oder ähnlich). Dieser kann an einem beliebigen Pin angeschlossen werden. Die Abfrage des Pins und die Dekodierung des IR-Protokolls erfolgt in einer ISR, die einen 8-Bit-Timer des ATMEGAs belegt. Beim Senden wird das Signal mit der Trägerfrequenz des jeweiligen IR-Protokolls über [[PWM_(Deutsch)|PWM]] moduliert. Dazu wird ein weiterer 8-Bit Timer des ATMEGAs (OC0/OC2) belegt. Auf dem '''[[Etherape_(Deutsch)|Etherrape]]'''-Board übernimmt ein [[NE555_(Deutsch)|NE555]] diese Funktion, d.h. die Option ''Use external modulator for sender'' ist zu aktivieren. Man spart einen Timer des [[AVR_(Deutsch)|AVR]] und ist auf eine Trägerfrequenz festgelegt. Beispiel für einen ATMega32 aus: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Bedeutung: * IRMP_RX - Pin an dem der IR-Empfänger angeschlossen ist * IRMP_USE_TIMER2 - benutze Timer2 für den Empfang, Timer0 für das Senden (undef = umgekehrt) * IRMP_RX_LOW_ACTIVE - der IR-Empfänger ist Low-Aktiv (undef = High-aktiv) * IRMP_RX_LED_LOW_ACTIVE - die Kontroll-LED des Empfängers ist gegen USS geschaltet (undef = gegen GND geschaltet) * IRMP_TX - Pin an dem der IR-Sender angschlossen ist (=Ausgang des Timer0 oder Timer2, vgl. IRMP_USE_TIMER2)<br>'''Achtung: 0A bzw 2A bei MCU mit A/B Kanal''' * IRMP_TX_LED_LOW_ACTIVE - die Kontroll-LED des Senders ist gegen USS geschaltet (undef = gegen GND geschaltet) == Konfiguration == Jedes unterstützte IR-Protokoll "verbrät" Speicher an Code. Deshalb sollte man nur die benötigten Protokolle auswählen. Eine detailierte Übersicht über die Protokolle gibt der [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail Artikel im Mikrocontroller Forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ [ ] ORTEK │ │ [ ] TELEFUNKEN │ │ [ ] ROOMBA │ │ --- Network │ │ [*] Remote IRMP │ │ (10001) UDP port (default 10001) │ │ --- Debugging Flags │ │ [ ] IRMP │ │ [ ] Remote IRMP IRMP dekodiert auch das RC5-Protokoll, so dass der separat in [[Ethersex_(Deutsch)|Ethersex]] enthaltene [[RC5_(Deutsch)|RC5]]-Dekoder nicht länger benötigt wird. == [[ECMD_(Deutsch)|ECMD]] == IRMP implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle zum Auslesen empfangener und dekodierter IR-Kommandos und zum Senden von IR-Kommandos. Siehe [[ECMD_Reference|ECMD Referenz]]. == [[Control6_(Deutsch)|Control6]] == === Ausgabe empfangener IR-Zeichen via [[SYSLOG_(Deutsch)|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> Mit IRMP_READ wird auf empfangenen IR-Code geprüft und dieser in die Variablen IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND und IRMP_FLAGS gespeichert. Rückgabewerte größer Null signalisieren die Gültigkeit der Variablen. Bei IRMP_FLAGS=1 handelt es sich um eine Wiederholung. === Steuern von [[StellaLight_(Deutsch)|Stella]]/Pins durch IR-Zeichen === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> Das Script schaltet den Stella Channel 0 auf 255 oder auf 0, die Fernbedienung ist hier eine Denon (Protocol 8). Mit ''include'' wurde dem Script der Zugriff auf die Stellasourcen gestattet.<br> Statt ''"stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255);"'' kann auch ''"PIN_SET(LED)"'' und ''"PIN_CLEAR(LED)"'' verwendet werden ([[Named_PIN_(Deutsch)|Named PIN]]). === Senden von IR-Zeichen === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 * no tx support yet dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON * no tx support yet dnl 31 = BOSE dnl 32 = A1TVBOX dnl 33 = ORTEK dnl 34 = TELEFUNKEN dnl 35 = ROOMBA IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Kommando 5678 an Gerät 1234 wird mit einer Wiederholung im NEC-Protokoll gesendet. == Remote IRMP == Damit wird es möglich, mit einer Android-App eine anlernbare IR-Fernbedienung zu realisieren. Der Anwender kann dann mehrere Geräte, die irgendwo im Haushalt verteilt sind, über das Handy steuern. Dabei sendet die App über WLAN zuvor gespeicherte IRMP-Codes an das gewünschtee Ethersex Gerät. Dieses strahlt dann die Signale über den IR-Sender aus, um damit unsere Geräte aus der Unterhaltungsindustrie zu schalten. Dies ist die Implementierung des [https://www.mikrocontroller.net/articles/Remote_IRMP Remote IRMP Protocols] in [[Ethersex]]. 90b4caf2f096aa18a099004405b0b4bc80406860 1254 1253 2014-07-23T06:59:38Z GooPie4o 265 /* Remote IRMP */ wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR Receivers->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |TIMER={{occupies_timer|0}}&{{occupies_timer|2}} (RX & TX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP ist eine Portierung des [http://www.mikrocontroller.net/articles/IRMP Infrarot-Multiprotokoll-Decoders] nach [[Ethersex]]. == Anschluss == Der Empfang der IR-Signale erfolgt durch einen Empfänger vom Typ TSOP1736 (oder ähnlich). Dieser kann an einem beliebigen Pin angeschlossen werden. Die Abfrage des Pins und die Dekodierung des IR-Protokolls erfolgt in einer ISR, die einen 8-Bit-Timer des ATMEGAs belegt. Beim Senden wird das Signal mit der Trägerfrequenz des jeweiligen IR-Protokolls über [[PWM_(Deutsch)|PWM]] moduliert. Dazu wird ein weiterer 8-Bit Timer des ATMEGAs (OC0/OC2) belegt. Auf dem '''[[Etherape_(Deutsch)|Etherrape]]'''-Board übernimmt ein [[NE555_(Deutsch)|NE555]] diese Funktion, d.h. die Option ''Use external modulator for sender'' ist zu aktivieren. Man spart einen Timer des [[AVR_(Deutsch)|AVR]] und ist auf eine Trägerfrequenz festgelegt. Beispiel für einen ATMega32 aus: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Bedeutung: * IRMP_RX - Pin an dem der IR-Empfänger angeschlossen ist * IRMP_USE_TIMER2 - benutze Timer2 für den Empfang, Timer0 für das Senden (undef = umgekehrt) * IRMP_RX_LOW_ACTIVE - der IR-Empfänger ist Low-Aktiv (undef = High-aktiv) * IRMP_RX_LED_LOW_ACTIVE - die Kontroll-LED des Empfängers ist gegen USS geschaltet (undef = gegen GND geschaltet) * IRMP_TX - Pin an dem der IR-Sender angschlossen ist (=Ausgang des Timer0 oder Timer2, vgl. IRMP_USE_TIMER2)<br>'''Achtung: 0A bzw 2A bei MCU mit A/B Kanal''' * IRMP_TX_LED_LOW_ACTIVE - die Kontroll-LED des Senders ist gegen USS geschaltet (undef = gegen GND geschaltet) == Konfiguration == Jedes unterstützte IR-Protokoll "verbrät" Speicher an Code. Deshalb sollte man nur die benötigten Protokolle auswählen. Eine detailierte Übersicht über die Protokolle gibt der [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail Artikel im Mikrocontroller Forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ [ ] ORTEK │ │ [ ] TELEFUNKEN │ │ [ ] ROOMBA │ │ --- Network │ │ [*] Remote IRMP │ │ (10001) UDP port (default 10001) │ │ --- Debugging Flags │ │ [ ] IRMP │ │ [ ] Remote IRMP IRMP dekodiert auch das RC5-Protokoll, so dass der separat in [[Ethersex_(Deutsch)|Ethersex]] enthaltene [[RC5_(Deutsch)|RC5]]-Dekoder nicht länger benötigt wird. == [[ECMD_(Deutsch)|ECMD]] == IRMP implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle zum Auslesen empfangener und dekodierter IR-Kommandos und zum Senden von IR-Kommandos. Siehe [[ECMD_Reference|ECMD Referenz]]. == [[Control6_(Deutsch)|Control6]] == === Ausgabe empfangener IR-Zeichen via [[SYSLOG_(Deutsch)|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> Mit IRMP_READ wird auf empfangenen IR-Code geprüft und dieser in die Variablen IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND und IRMP_FLAGS gespeichert. Rückgabewerte größer Null signalisieren die Gültigkeit der Variablen. Bei IRMP_FLAGS=1 handelt es sich um eine Wiederholung. === Steuern von [[StellaLight_(Deutsch)|Stella]]/Pins durch IR-Zeichen === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> Das Script schaltet den Stella Channel 0 auf 255 oder auf 0, die Fernbedienung ist hier eine Denon (Protocol 8). Mit ''include'' wurde dem Script der Zugriff auf die Stellasourcen gestattet.<br> Statt ''"stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255);"'' kann auch ''"PIN_SET(LED)"'' und ''"PIN_CLEAR(LED)"'' verwendet werden ([[Named_PIN_(Deutsch)|Named PIN]]). === Senden von IR-Zeichen === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 * no tx support yet dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON * no tx support yet dnl 31 = BOSE dnl 32 = A1TVBOX dnl 33 = ORTEK dnl 34 = TELEFUNKEN dnl 35 = ROOMBA IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Kommando 5678 an Gerät 1234 wird mit einer Wiederholung im NEC-Protokoll gesendet. == Remote IRMP == Dies ist die Implementierung des [https://www.mikrocontroller.net/articles/Remote_IRMP Remote IRMP Protocols] in [[Ethersex]]. Damit wird es möglich, mit einer Android-App eine anlernbare IR-Fernbedienung zu realisieren. Der Anwender kann dann mehrere Geräte, die irgendwo im Haushalt verteilt sind, über das Handy steuern. Dabei sendet die App über WLAN zuvor gespeicherte IRMP-Codes an das gewünschtee Ethersex Gerät. Dieses strahlt dann die Signale über den IR-Sender aus, um damit unsere Geräte aus der Unterhaltungsindustrie zu schalten. f384e5aeea02c4c5c0386acf343cd1b70fb1fe44 1258 1254 2014-07-23T07:05:11Z GooPie4o 265 /* Remote IRMP */ wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR Receivers->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |TIMER={{occupies_timer|0}}&{{occupies_timer|2}} (RX & TX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP ist eine Portierung des [http://www.mikrocontroller.net/articles/IRMP Infrarot-Multiprotokoll-Decoders] nach [[Ethersex]]. == Anschluss == Der Empfang der IR-Signale erfolgt durch einen Empfänger vom Typ TSOP1736 (oder ähnlich). Dieser kann an einem beliebigen Pin angeschlossen werden. Die Abfrage des Pins und die Dekodierung des IR-Protokolls erfolgt in einer ISR, die einen 8-Bit-Timer des ATMEGAs belegt. Beim Senden wird das Signal mit der Trägerfrequenz des jeweiligen IR-Protokolls über [[PWM_(Deutsch)|PWM]] moduliert. Dazu wird ein weiterer 8-Bit Timer des ATMEGAs (OC0/OC2) belegt. Auf dem '''[[Etherape_(Deutsch)|Etherrape]]'''-Board übernimmt ein [[NE555_(Deutsch)|NE555]] diese Funktion, d.h. die Option ''Use external modulator for sender'' ist zu aktivieren. Man spart einen Timer des [[AVR_(Deutsch)|AVR]] und ist auf eine Trägerfrequenz festgelegt. Beispiel für einen ATMega32 aus: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Bedeutung: * IRMP_RX - Pin an dem der IR-Empfänger angeschlossen ist * IRMP_USE_TIMER2 - benutze Timer2 für den Empfang, Timer0 für das Senden (undef = umgekehrt) * IRMP_RX_LOW_ACTIVE - der IR-Empfänger ist Low-Aktiv (undef = High-aktiv) * IRMP_RX_LED_LOW_ACTIVE - die Kontroll-LED des Empfängers ist gegen USS geschaltet (undef = gegen GND geschaltet) * IRMP_TX - Pin an dem der IR-Sender angschlossen ist (=Ausgang des Timer0 oder Timer2, vgl. IRMP_USE_TIMER2)<br>'''Achtung: 0A bzw 2A bei MCU mit A/B Kanal''' * IRMP_TX_LED_LOW_ACTIVE - die Kontroll-LED des Senders ist gegen USS geschaltet (undef = gegen GND geschaltet) == Konfiguration == Jedes unterstützte IR-Protokoll "verbrät" Speicher an Code. Deshalb sollte man nur die benötigten Protokolle auswählen. Eine detailierte Übersicht über die Protokolle gibt der [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail Artikel im Mikrocontroller Forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ [ ] ORTEK │ │ [ ] TELEFUNKEN │ │ [ ] ROOMBA │ │ --- Network │ │ [*] Remote IRMP │ │ (10001) UDP port (default 10001) │ │ --- Debugging Flags │ │ [ ] IRMP │ │ [ ] Remote IRMP IRMP dekodiert auch das RC5-Protokoll, so dass der separat in [[Ethersex_(Deutsch)|Ethersex]] enthaltene [[RC5_(Deutsch)|RC5]]-Dekoder nicht länger benötigt wird. == [[ECMD_(Deutsch)|ECMD]] == IRMP implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle zum Auslesen empfangener und dekodierter IR-Kommandos und zum Senden von IR-Kommandos. Siehe [[ECMD_Reference|ECMD Referenz]]. == [[Control6_(Deutsch)|Control6]] == === Ausgabe empfangener IR-Zeichen via [[SYSLOG_(Deutsch)|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> Mit IRMP_READ wird auf empfangenen IR-Code geprüft und dieser in die Variablen IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND und IRMP_FLAGS gespeichert. Rückgabewerte größer Null signalisieren die Gültigkeit der Variablen. Bei IRMP_FLAGS=1 handelt es sich um eine Wiederholung. === Steuern von [[StellaLight_(Deutsch)|Stella]]/Pins durch IR-Zeichen === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> Das Script schaltet den Stella Channel 0 auf 255 oder auf 0, die Fernbedienung ist hier eine Denon (Protocol 8). Mit ''include'' wurde dem Script der Zugriff auf die Stellasourcen gestattet.<br> Statt ''"stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255);"'' kann auch ''"PIN_SET(LED)"'' und ''"PIN_CLEAR(LED)"'' verwendet werden ([[Named_PIN_(Deutsch)|Named PIN]]). === Senden von IR-Zeichen === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 * no tx support yet dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON * no tx support yet dnl 31 = BOSE dnl 32 = A1TVBOX dnl 33 = ORTEK dnl 34 = TELEFUNKEN dnl 35 = ROOMBA IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Kommando 5678 an Gerät 1234 wird mit einer Wiederholung im NEC-Protokoll gesendet. == Remote IRMP == [[File:Remote_buttler.png|200px|thumb|right|Android App]] Dies ist die Implementierung des [https://www.mikrocontroller.net/articles/Remote_IRMP Remote IRMP Protocols] in [[Ethersex]]. Damit wird es möglich, mit einer Android-App eine anlernbare IR-Fernbedienung zu realisieren. Der Anwender kann dann mehrere Geräte, die irgendwo im Haushalt verteilt sind, über das Handy steuern. Dabei sendet die App über WLAN zuvor gespeicherte IRMP-Codes an das gewünschtee Ethersex Gerät. Dieses strahlt dann die Signale über den IR-Sender aus, um damit unsere Geräte aus der Unterhaltungsindustrie zu schalten. 9d759f259d7b2d4c71a9f2796e62fe50dc6be3dd 1288 1258 2014-08-12T11:46:13Z Coffee 722 IRMP_TX Pin-Belegung verständlicher gemacht, Rechtschreibfehler berichtigt wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR Receivers->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |TIMER={{occupies_timer|0}}&{{occupies_timer|2}} (RX & TX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP ist eine Portierung des [http://www.mikrocontroller.net/articles/IRMP Infrarot-Multiprotokoll-Decoders] nach [[Ethersex]]. == Anschluss == Der Empfang der IR-Signale erfolgt durch einen Empfänger vom Typ TSOP1736 (oder ähnlich). Dieser kann an einem beliebigen Pin angeschlossen werden. Die Abfrage des Pins und die Dekodierung des IR-Protokolls erfolgt in einer ISR, die einen 8-Bit-Timer des ATMEGAs belegt. Beim Senden wird das Signal mit der Trägerfrequenz des jeweiligen IR-Protokolls über [[PWM_(Deutsch)|PWM]] moduliert. Dazu wird ein weiterer 8-Bit Timer des ATMEGAs (OC0/OC2) belegt. Auf dem '''[[Etherape_(Deutsch)|Etherrape]]'''-Board übernimmt ein [[NE555_(Deutsch)|NE555]] diese Funktion, d.h. die Option ''Use external modulator for sender'' ist zu aktivieren. Man spart einen Timer des [[AVR_(Deutsch)|AVR]] und ist auf eine Trägerfrequenz festgelegt. Beispiel für einen ATMega32 aus: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Bedeutung: * IRMP_RX - Pin an dem der IR-Empfänger angeschlossen ist * IRMP_USE_TIMER2 - benutze Timer2 für den Empfang, Timer0 für das Senden (undef = umgekehrt) * IRMP_RX_LOW_ACTIVE - der IR-Empfänger ist Low-Aktiv (undef = High-aktiv) * IRMP_RX_LED_LOW_ACTIVE - die Kontroll-LED des Empfängers ist gegen USS geschaltet (undef = gegen GND geschaltet) * IRMP_TX - Pin an dem der IR-Sender angeschlossen ist (= Ausgang des Timer0 oder Timer2, vgl. IRMP_USE_TIMER2)<br>'''Achtung: 0A bzw 2A bei MCU mit A/B Kanal''' Möglich sind ''ausschließlich'' OC0 oder OC2. Der Versuch einen anderen Pin zu konfigurieren wird ohne Fehlermeldung fehlschlagen. * IRMP_TX_LED_LOW_ACTIVE - die Kontroll-LED des Senders ist gegen USS geschaltet (undef = gegen GND geschaltet) == Konfiguration == Jedes unterstützte IR-Protokoll "verbrät" Speicher an Code. Deshalb sollte man nur die benötigten Protokolle auswählen. Eine detailierte Übersicht über die Protokolle gibt der [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail Artikel im Mikrocontroller Forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ [ ] ORTEK │ │ [ ] TELEFUNKEN │ │ [ ] ROOMBA │ │ --- Network │ │ [*] Remote IRMP │ │ (10001) UDP port (default 10001) │ │ --- Debugging Flags │ │ [ ] IRMP │ │ [ ] Remote IRMP IRMP dekodiert auch das RC5-Protokoll, so dass der separat in [[Ethersex_(Deutsch)|Ethersex]] enthaltene [[RC5_(Deutsch)|RC5]]-Dekoder nicht länger benötigt wird. == [[ECMD_(Deutsch)|ECMD]] == IRMP implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle zum Auslesen empfangener und dekodierter IR-Kommandos und zum Senden von IR-Kommandos. Siehe [[ECMD_Reference|ECMD Referenz]]. == [[Control6_(Deutsch)|Control6]] == === Ausgabe empfangener IR-Zeichen via [[SYSLOG_(Deutsch)|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> Mit IRMP_READ wird auf empfangenen IR-Code geprüft und dieser in die Variablen IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND und IRMP_FLAGS gespeichert. Rückgabewerte größer Null signalisieren die Gültigkeit der Variablen. Bei IRMP_FLAGS=1 handelt es sich um eine Wiederholung. === Steuern von [[StellaLight_(Deutsch)|Stella]]/Pins durch IR-Zeichen === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> Das Script schaltet den Stella Channel 0 auf 255 oder auf 0, die Fernbedienung ist hier eine Denon (Protocol 8). Mit ''include'' wurde dem Script der Zugriff auf die Stellasourcen gestattet.<br> Statt ''"stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255);"'' kann auch ''"PIN_SET(LED)"'' und ''"PIN_CLEAR(LED)"'' verwendet werden ([[Named_PIN_(Deutsch)|Named PIN]]). === Senden von IR-Zeichen === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 * no tx support yet dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON * no tx support yet dnl 31 = BOSE dnl 32 = A1TVBOX dnl 33 = ORTEK dnl 34 = TELEFUNKEN dnl 35 = ROOMBA IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Kommando 5678 an Gerät 1234 wird mit einer Wiederholung im NEC-Protokoll gesendet. == Remote IRMP == [[File:Remote_buttler.png|200px|thumb|right|Android App]] Dies ist die Implementierung des [https://www.mikrocontroller.net/articles/Remote_IRMP Remote IRMP Protocols] in [[Ethersex]]. Damit wird es möglich, mit einer Android-App eine anlernbare IR-Fernbedienung zu realisieren. Der Anwender kann dann mehrere Geräte, die irgendwo im Haushalt verteilt sind, über das Handy steuern. Dabei sendet die App über WLAN zuvor gespeicherte IRMP-Codes an das gewünschtee Ethersex Gerät. Dieses strahlt dann die Signale über den IR-Sender aus, um damit unsere Geräte aus der Unterhaltungsindustrie zu schalten. e234405adfa0ca4437c02dce0e641294cad9e870 1291 1288 2014-08-12T11:55:01Z Coffee 722 korrigiere vorhergehende Revision wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR Receivers->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |TIMER={{occupies_timer|0}}&{{occupies_timer|2}} (RX & TX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} IRMP ist eine Portierung des [http://www.mikrocontroller.net/articles/IRMP Infrarot-Multiprotokoll-Decoders] nach [[Ethersex]]. == Anschluss == Der Empfang der IR-Signale erfolgt durch einen Empfänger vom Typ TSOP1736 (oder ähnlich). Dieser kann an einem beliebigen Pin angeschlossen werden. Die Abfrage des Pins und die Dekodierung des IR-Protokolls erfolgt in einer ISR, die einen 8-Bit-Timer des ATMEGAs belegt. Beim Senden wird das Signal mit der Trägerfrequenz des jeweiligen IR-Protokolls über [[PWM_(Deutsch)|PWM]] moduliert. Dazu wird ein weiterer 8-Bit Timer des ATMEGAs (OC0/OC2) belegt. Auf dem '''[[Etherape_(Deutsch)|Etherrape]]'''-Board übernimmt ein [[NE555_(Deutsch)|NE555]] diese Funktion, d.h. die Option ''Use external modulator for sender'' ist zu aktivieren. Man spart einen Timer des [[AVR_(Deutsch)|AVR]] und ist auf eine Trägerfrequenz festgelegt. Beispiel für einen ATMega32 aus: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Bedeutung: * IRMP_RX - Pin an dem der IR-Empfänger angeschlossen ist * IRMP_USE_TIMER2 - benutze Timer2 für den Empfang, Timer0 für das Senden (undef = umgekehrt) * IRMP_RX_LOW_ACTIVE - der IR-Empfänger ist Low-Aktiv (undef = High-aktiv) * IRMP_RX_LED_LOW_ACTIVE - die Kontroll-LED des Empfängers ist gegen USS geschaltet (undef = gegen GND geschaltet) * IRMP_TX - Pin an dem der IR-Sender angeschlossen ist (= Ausgang des Timer0 oder Timer2, vgl. IRMP_USE_TIMER2)<br>'''Achtung: 0A bzw 2A bei MCU mit A/B Kanal''' Ohne einen externen Modulator sind ausschließlich OC0 oder OC2 möglich. Der Versuch einen anderen Pin zu konfigurieren wird ohne Fehlermeldung fehlschlagen. * IRMP_TX_LED_LOW_ACTIVE - die Kontroll-LED des Senders ist gegen USS geschaltet (undef = gegen GND geschaltet) == Konfiguration == Jedes unterstützte IR-Protokoll "verbrät" Speicher an Code. Deshalb sollte man nur die benötigten Protokolle auswählen. Eine detailierte Übersicht über die Protokolle gibt der [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail Artikel im Mikrocontroller Forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ [ ] ORTEK │ │ [ ] TELEFUNKEN │ │ [ ] ROOMBA │ │ --- Network │ │ [*] Remote IRMP │ │ (10001) UDP port (default 10001) │ │ --- Debugging Flags │ │ [ ] IRMP │ │ [ ] Remote IRMP IRMP dekodiert auch das RC5-Protokoll, so dass der separat in [[Ethersex_(Deutsch)|Ethersex]] enthaltene [[RC5_(Deutsch)|RC5]]-Dekoder nicht länger benötigt wird. == [[ECMD_(Deutsch)|ECMD]] == IRMP implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle zum Auslesen empfangener und dekodierter IR-Kommandos und zum Senden von IR-Kommandos. Siehe [[ECMD_Reference|ECMD Referenz]]. == [[Control6_(Deutsch)|Control6]] == === Ausgabe empfangener IR-Zeichen via [[SYSLOG_(Deutsch)|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> Mit IRMP_READ wird auf empfangenen IR-Code geprüft und dieser in die Variablen IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND und IRMP_FLAGS gespeichert. Rückgabewerte größer Null signalisieren die Gültigkeit der Variablen. Bei IRMP_FLAGS=1 handelt es sich um eine Wiederholung. === Steuern von [[StellaLight_(Deutsch)|Stella]]/Pins durch IR-Zeichen === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> Das Script schaltet den Stella Channel 0 auf 255 oder auf 0, die Fernbedienung ist hier eine Denon (Protocol 8). Mit ''include'' wurde dem Script der Zugriff auf die Stellasourcen gestattet.<br> Statt ''"stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255);"'' kann auch ''"PIN_SET(LED)"'' und ''"PIN_CLEAR(LED)"'' verwendet werden ([[Named_PIN_(Deutsch)|Named PIN]]). === Senden von IR-Zeichen === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 * no tx support yet dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON * no tx support yet dnl 31 = BOSE dnl 32 = A1TVBOX dnl 33 = ORTEK dnl 34 = TELEFUNKEN dnl 35 = ROOMBA IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Kommando 5678 an Gerät 1234 wird mit einer Wiederholung im NEC-Protokoll gesendet. == Remote IRMP == [[File:Remote_buttler.png|200px|thumb|right|Android App]] Dies ist die Implementierung des [https://www.mikrocontroller.net/articles/Remote_IRMP Remote IRMP Protocols] in [[Ethersex]]. Damit wird es möglich, mit einer Android-App eine anlernbare IR-Fernbedienung zu realisieren. Der Anwender kann dann mehrere Geräte, die irgendwo im Haushalt verteilt sind, über das Handy steuern. Dabei sendet die App über WLAN zuvor gespeicherte IRMP-Codes an das gewünschtee Ethersex Gerät. Dieses strahlt dann die Signale über den IR-Sender aus, um damit unsere Geräte aus der Unterhaltungsindustrie zu schalten. 3fd8e129e8b4258d3f9056db1e7425b83432a2cf 6 388 1256 2014-07-23T07:03:17Z GooPie4o 265 Taken from https://www.mikrocontroller.net/articles/Remote_IRMP wikitext text/x-wiki Taken from https://www.mikrocontroller.net/articles/Remote_IRMP 194d20909e60faaa5d82f7c65227c4dabef98e6e 0 381 1259 1245 2014-07-23T07:20:54Z GooPie4o 265 wikitext text/x-wiki {{i18n|Generic ASK Modules}} {{Module |NAME=Generic ASK Modules |MENUCONFIG={{I/O}}->Radio->Generic ASK |STATUS={{In_Development}} |PINNING=yes |ECMD= no |CONTROL6=no |DEPENDS= - |REQUIRES= - |TIMER={{occupies_timer|2}} (RX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/generic_ask https://github.com/ethersex/ethersex/tree/master/hardware/radio/generic_ask] }} [[File:Generic ask module front.jpg|200px|thumb|right|Generic ASK Module TX and RX (front)]] [[File:Generic ask module back.jpg|200px|thumb|right|Generic ASK Module TX and RX (back)]] [[File:Ask_sender.jpg|200px|thumb|right|Shematic of TX Module]] [[File:Ask_receiver.gif|200px|thumb|right|Shematic of RX Module]] These modules are sourced from China and can be bougth via [http://www.ebay.com/sch/i.html?_sacat=0&_from=R40&_sop=15&LH_BIN=1&_nkw=433Mhz+RF+Transmitter+And+Receiver+Kit&LH_PrefLoc=2&rt=nc&LH_FS=1 ebay]. They can be used as a cheap replacement for [[RFM12]] to switch radio outlets. ==== Technical Specifications ==== * Receiver module parameters ** Product Model: MX-05V ** Operating voltage: DC5V ** Quiescent Current: 4mA ** Receiving frequency: 433.92MHZ ** Receiver sensitivity: -105DB ** Size: 30 * 14 * 7mm ** External antenna: 32CM single core wire, wound into a spiral * Transmitter module parameters ** Product Model: MX-FS-03V ** Launch distance: 20-200 meters (different voltage, different results) ** Operating voltage: 3.5-12V ** Dimensions: 19 * 19mm ** Operating mode: AM ** Transfer rate: 4KB/s ** Transmitting power: 10mW ** Transmitting frequency: 433M ** An external antenna: 25cm ordinary multi-core or single-core line ==== Remark ==== * VCC voltage module operating voltage and good power filtering; * Great influence on the antenna module reception, preferably connected to the 1/4 wavelength of the antenna, typically 50 ohm single conductor, the length of the antenna 433M of about 17cm; * Antenna position has also affected the reception of the module, the installation, the antenna as possible straight away from the shield, high pressure, and interference source; frequency used to receive, decode and oscillation resistor should match with the transmitter. == Connection == The DATA pin of the transmitter module is named GENERIC_ASK_TX in Ethersex's pinning. The example below uses PA0. ifdef(`conf_GENERIC_ASK', `dnl pin(GENERIC_ASK_TX, PA0, OUTPUT) ')dnl {| class="wikitable" style="left; margin-right:1em" |+ TX Module ! Pin !! Description |- | 1 || GND |- | 2 || VCC (3.5-12V) |- | 3 || DATA |} {| class="wikitable" style="left; margin-right:1em" |+ RX Module ! Pin !! Description |- | 1 || GND |- | 2 || DATA |- | 3 || DATA |- | 4 || VCC (5V) |} == Configuration == First enable the hardware and then select it in the protocol section. | | I/O ---> | | ... | | Radio ---> | | ... | | [*] Generic ASK (433MHz) | | | | Protocols ---> | | ... | | Radio ---> | | | | [*] Radio outlets (433MHz) ---> | | ... | | (Generic) Transmitter hardware | | | | [*] Pollin/Kangtai Powerswitch (IC 2272) | | | | [*] Pollin Powerswitch buried (IC 1527) | | | | [*] Tevion Powerswitch | | | | [*] Intertechno ITS-150 | | | | [*] Intertechno Self Learning | | | | [*] Oase FM Master | | == Links == * [http://www.youtube.com/watch?v=LDGr38Ie1L4 Demo] on Youtube * [http://www.electrodragon.com/wp-content/uploads/2012/04/VirtualWire.pdf Documentation of library virtualwire] * [http://www.electrodragon.com/wp-content/uploads/2012/04/KLP_Walkthrough.pdf KLP/KLPA module walkthrough] * [http://winavr.scienceprog.com/example-avr-projects/running-tx433-and-rx433-rf-modules-with-avr-microcontrollers.html Running TX433 and RX433 RF modules with AVR microcontrollers] [[Category:ASK]] 0d26c073ae0d959c9456c37b6422bd4d8b8d7323 0 360 1260 1213 2014-07-23T07:23:39Z GooPie4o 265 wikitext text/x-wiki {{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader] }} The module is based on Roland Riegel's [http://www.roland-riegel.de/sd-reader/ MMC/SD/SDHC card library] complemented by the connection to the Ethersex [[VFS|Virtual File System]]. == Connection == [[File:Sdcard adapter schaltung.png|200px|thumb|right|SD-Card Adapter Schaltung]] [[File:Sdcard adapter.jpg|200px|thumb|right|SD-Card Adapter Aufbau]] [[File:Microsd_adapter.jpg|200px|thumb|right|MicroSD card adapter with level-shifter from China]] MMC and SD memory cards can be used in [[SPI]] mode relatively easily controlled with a microcontroller. In principle, there is not between SD Card and MMC many differences, but SD cards are more common, generally faster than MMCs, and have a better-implemented SPI interface. There are several variants (miniSD, microSD), which are largely compatible with the standard SD-card. The card reads the adjacent data bits with the rising clock edge, as [[SPI]] modes are thus suitable Mode 0 and Mode 3 In MMCs, the SPI mode is not precisely specified, so it does happen sometimes that the SPI mode must be selected differ depending on the card. SD cards are typically often operated with 3.3V and 5V microcontrollers. This forces a [http://www.mikrocontroller.net/articles/Pegelwandler#5V_.3C-.3E_3.3V level adjustment], because the input lines to the SD card are not 5V tolerant. [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#Bekannte_Fehler A level adjustment] with resistors is not recommended. In addition to the lines leading to the SD card, there are two other lines which lead to the SD card socket: namely, the card-detect line and the write-protect line. They serve as the name already say, to signal the physical presence of a card in the SD socket and the position of the write protect switch. If hardware SPI used, only the chip select line must be configured. The card-detect line and the write-protect line are optional and MicroSD anyway not exist. ifdef(`conf_SD_READER', ` /* port the sd-reader CS is attached to */ pin(SPI_CS_SD_READER, PB2, OUTPUT) /* uncomment and edit this if you have connected the CD (card detect) signal */ pin(SD_READER_AVAILABLE, PD4, INPUT) /* uncomment and edit this if you have connected the WP (write protected) signal */ pin(SD_READER_WR_PROTECT, PD5, INPUT) ') Another problem with the SD card is the initialization. Manages Ethersex not in a certain time to sync, so the card into the normal drops (not the SD) mode and can no longer be addressed. A solution for this is that the card receives a controllable power supply. For this purpose, we define the pinning only pin pin(SD_READER_POWERON, PB3, OUTPUT) === Connector === A cheap type of contact is probably cannibalizing a cheap card reader if you want to solder any cables directly to the card. Individually purchased connectors can usually considerably teuerer. Even [http://uanr.com/sdfloppy/ old floppy cable] can be used as cheap connectors. Parts of AT slots or connectors of 5.25-inch floppies go. If necessary, you can see the card between two rows of pin strip pinch (or solder). It's even cheaper if you use micro or mini SD cards and usually included adapter anlötet. However, anyone who wants to give up a DIY, alternatively, for relatively little money a [http://www.shop.display3000.com/elektronikmodule/sd-kartenmodul/index.html completely assembled SD adapter] available for purchase to be connected to the AVR. With this adapter already is a bidirectional signal level between the 5V levels of the control lines of the AVR and the 3.3 V level of the SD card on board. Affordable modules sourced from China are available on [http://www.ebay.com/sch/i.html?_from=R40&_sacat=0&_nkw=Micro+SD+Card+Module+SPI&rt=nc&LH_PrefLoc=2 ebay]. == Configuration == | | I/O ---> | | ... │ │ Storage ---> │ │ ... | | [*] SD/MMC-Card Reader ---> | | ... | | [ ] SDHC support | | | | [*] VFAT LFN support | | | | [ ] Read-only mode | | | | [*] Use read-timeout | | | | [*] Ping-read SD card every 10s | | | | --- ECMD Support | | | | [*] info | | | | [*] dir | | | | [*] mkdir | | | | [*] rm | | | | --- Debugging Flags | | | | [*] FAT | | | | [*] RAW | | | | [*] VFS | | | | General Setup ---> | | ... | | [*] VFS (Virtual File System) support ---> | | ... | | [*] SD/MMC-Card Filesystem | | == [[ECMD|ECMD]] == The SD CARD module implements an [[ECMD]] interface. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == The following example writes the date, time and temperature by VFS_LOG_ALLOCA (VFS_LOG requires UIP) in the file "temp.log" as soon as the temperature has changed by more than a degree to the last measurement. For date and time CLOCK_SUPPORT must be enabled. <pre> #include <stdlib.h> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO uint8_t sign = Temperatur<0; div_t res = div(abs(Temperatur),10); VFS_LOG_ALLOCA("temp.log", 50, "%2d.%2d.%4d %2d:%02d %S%d.%d", CLOCK_DAY, CLOCK_MONTH, CLOCK_YEAR, CLOCK_HOUR, CLOCK_MIN, sign?PSTR("-"):PSTR(""),res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> a5299c3bc88d770b6d78404c1d14aeeb0d819a53 1261 1260 2014-07-23T07:27:22Z GooPie4o 265 wikitext text/x-wiki {{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader] }} The module is based on Roland Riegel's [http://www.roland-riegel.de/sd-reader/ MMC/SD/SDHC card library] complemented by the connection to the Ethersex [[VFS|Virtual File System]]. == Connection == [[File:Sdcard adapter schaltung.png|200px|thumb|right|SD-Card adapter circuit diagram]] [[File:Sdcard adapter.jpg|200px|thumb|right|SD-Card adapter module]] [[File:Microsd_adapter.jpg|200px|thumb|right|MicroSD card adapter with level-shifter from China]] MMC and SD memory cards can be used in [[SPI]] mode relatively easily controlled with a microcontroller. In principle, there is not between SD Card and MMC many differences, but SD cards are more common, generally faster than MMCs, and have a better-implemented SPI interface. There are several variants (miniSD, microSD), which are largely compatible with the standard SD-card. The card reads the adjacent data bits with the rising clock edge, as [[SPI]] modes are thus suitable Mode 0 and Mode 3 In MMCs, the SPI mode is not precisely specified, so it does happen sometimes that the SPI mode must be selected differ depending on the card. SD cards are typically often operated with 3.3V and 5V microcontrollers. This forces a [http://www.mikrocontroller.net/articles/Pegelwandler#5V_.3C-.3E_3.3V level adjustment], because the input lines to the SD card are not 5V tolerant. [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#Bekannte_Fehler A level adjustment] with resistors is not recommended. In addition to the lines leading to the SD card, there are two other lines which lead to the SD card socket: namely, the card-detect line and the write-protect line. They serve as the name already say, to signal the physical presence of a card in the SD socket and the position of the write protect switch. If hardware SPI used, only the chip select line must be configured. The card-detect line and the write-protect line are optional and MicroSD anyway not exist. ifdef(`conf_SD_READER', ` /* port the sd-reader CS is attached to */ pin(SPI_CS_SD_READER, PB2, OUTPUT) /* uncomment and edit this if you have connected the CD (card detect) signal */ pin(SD_READER_AVAILABLE, PD4, INPUT) /* uncomment and edit this if you have connected the WP (write protected) signal */ pin(SD_READER_WR_PROTECT, PD5, INPUT) ') Another problem with the SD card is the initialization. Manages Ethersex not in a certain time to sync, so the card into the normal drops (not the SD) mode and can no longer be addressed. A solution for this is that the card receives a controllable power supply. For this purpose, we define the pinning only pin pin(SD_READER_POWERON, PB3, OUTPUT) === Connector === A cheap type of contact is probably cannibalizing a cheap card reader if you want to solder any cables directly to the card. Individually purchased connectors can usually considerably teuerer. Even [http://uanr.com/sdfloppy/ old floppy cable] can be used as cheap connectors. Parts of AT slots or connectors of 5.25-inch floppies go. If necessary, you can see the card between two rows of pin strip pinch (or solder). It's even cheaper if you use micro or mini SD cards and usually included adapter anlötet. However, anyone who wants to give up a DIY, alternatively, for relatively little money a [http://www.shop.display3000.com/elektronikmodule/sd-kartenmodul/index.html completely assembled SD adapter] available for purchase to be connected to the AVR. With this adapter already is a bidirectional signal level between the 5V levels of the control lines of the AVR and the 3.3 V level of the SD card on board. Affordable modules sourced from China are available on [http://www.ebay.com/sch/i.html?_from=R40&_sacat=0&_nkw=Micro+SD+Card+Module+SPI&rt=nc&LH_PrefLoc=2 ebay]. == Configuration == | | I/O ---> | | ... │ │ Storage ---> │ │ ... | | [*] SD/MMC-Card Reader ---> | | ... | | [ ] SDHC support | | | | [*] VFAT LFN support | | | | [ ] Read-only mode | | | | [*] Use read-timeout | | | | [*] Ping-read SD card every 10s | | | | --- ECMD Support | | | | [*] info | | | | [*] dir | | | | [*] mkdir | | | | [*] rm | | | | --- Debugging Flags | | | | [*] FAT | | | | [*] RAW | | | | [*] VFS | | | | General Setup ---> | | ... | | [*] VFS (Virtual File System) support ---> | | ... | | [*] SD/MMC-Card Filesystem | | == [[ECMD|ECMD]] == The SD CARD module implements an [[ECMD]] interface. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == The following example writes the date, time and temperature by VFS_LOG_ALLOCA (VFS_LOG requires UIP) in the file "temp.log" as soon as the temperature has changed by more than a degree to the last measurement. For date and time CLOCK_SUPPORT must be enabled. <pre> #include <stdlib.h> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO uint8_t sign = Temperatur<0; div_t res = div(abs(Temperatur),10); VFS_LOG_ALLOCA("temp.log", 50, "%2d.%2d.%4d %2d:%02d %S%d.%d", CLOCK_DAY, CLOCK_MONTH, CLOCK_YEAR, CLOCK_HOUR, CLOCK_MIN, sign?PSTR("-"):PSTR(""),res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> aaa80026c4afdeff0c0390398f8136e56f94c5bf 0 312 1262 1199 2014-07-24T17:56:21Z GooPie4o 265 /* Configuration */ wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->Radio->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |TIMER={{occupies_timer|2}} (RX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} The FS20 / FHT system by ELV is currently the most successful wireless home control system in the low cost sector. This arises from the large number of components and the continuous expansion of the system. But the relatively low price, the comprehensive home control systems far below the price of such EIB systems permits, plays a crucial role. This modul is based on [http://culfw.de CULFW by Rudolf Koenig] and supports a wide range of protocols: * FS20: send/receive<br>There are numerous FS20 devices, all of them are fully supported. * FHT: send/receive<br>Communication to the FHT80b is supported. * S300: receive<br>Examples of such devices: S300TH, KS300-2 * EM1000: receive<br>Devices: EM1000FM, EM1000GZ, EM1000WZ * HMS: receive<br>Devices: There are numerous HMS devices, all of them are fully supported. * ESA2000: receive * Lacrosse TX2/TX3: receive == Connection == The RFM12 is connected to the AVR like in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FSK/DATA/nFSS signal (Pin 3) is connected to one of the INT pins of the AVR. This modul does not work in interrupt mode, so the output nRQ signal (Pin 2) can be left unconnected. The software uses the digital filter of the RFM12. To improve sensitivity on short and long distances the [http://jeelabs.net/projects/cafe/wiki/Receiving_OOKASK_with_a_modified_RFM12B C_arssi capacitor needs to be replaced] with a value of 150 pF. The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_FS20_USE_INT(1) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_FS20_USE_INT defines whether FSK/DATA/nFSS is connected to INT0, INT1 or INT2 of the AVR. == Configuration == The FS20 system sends on 868,35 MHz, so the 868MHz option is the right one. | | I/O ---> | | ... | | Radio ---> | | ... | | [*] RFM12 ASK ---> | | ... | | [ ] 433MHz | | | | () RFM12 select | | | | [ ] External filter | | | | [-] Sensing | | | | --- | | | | [*] 868MHz | | | | (0) RFM12 select | | | | --- Debugging Flags | | | | [-] Sensing | | | | Protocols ---> | | ... | | Radio ---> | | ... | | [*] FS20 (868MHz) ---> | | ... | | (RFM12) Transmitter/receiver hardware | | | | [*] FS20 Send | | | | [*] FS20 Receive | | | | [*] FHT | | | | [ ] ESA | | | | [ ] TX3 | | | | [ ] Send received data via syslog | | | | --- Debugging Flags | | | | [ ] FS20 | | The modul uses Timer 2 of the AVR '''exclusively'''. Currently there is no option to use Timer 1, but this will change in the future. == [[ECMD]] == RFM12 FS20 implements an [[ECMD]] interface for send and receive FS20/FHT commands. The received data is formatted as described in the [http://culfw.de/commandref.html#protocol2 CULFW reference]. See [[ECMD_Reference|ECMD reference]] for a command list. == Troubleshooting == It may happen that not all of the RFM12 FS20 sensors are received. Here are some points that may help to improve reception: * Location: ** Avoid RF transmitter near the RFM12 ** Choose a position in the center of the sensors * Antenna: ** It is recommended to choose an antenna with a length not shorter than Lamda/2 (17,3cm) * Bandwidth: Default 400kHz ** Can be changed via ECMD from 400kHz to 67kHz (rfm12 setbandwidth <modulnumber> 1-6) * Gain: Default -14dB ** Can be changed via ECMD from 0dB to -20dB (rfm12 setgain <modulnumber> 0-3) * DRSSI: Default -97dB ** Can be changed via ECMD from -103dB to -61dB (rfm12 setdrssi <modulnumber> 0-7) Checkout the RFM12 datasheet for details on bandwidth, gain and DRSSI. == Decoding received data == The received data is formatted as described in the [http://culfw.de/commandref.html#protocol2 CULFW reference]. One could use the perl scripts from [http://culfw.de/ CULFW] to decode the data. [[Category:RFM12]] 6a7d9c59ae0a221641914e5a67ea0ba0d3178e01 1263 1262 2014-07-24T17:56:33Z GooPie4o 265 /* Configuration */ wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->Radio->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |TIMER={{occupies_timer|2}} (RX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} The FS20 / FHT system by ELV is currently the most successful wireless home control system in the low cost sector. This arises from the large number of components and the continuous expansion of the system. But the relatively low price, the comprehensive home control systems far below the price of such EIB systems permits, plays a crucial role. This modul is based on [http://culfw.de CULFW by Rudolf Koenig] and supports a wide range of protocols: * FS20: send/receive<br>There are numerous FS20 devices, all of them are fully supported. * FHT: send/receive<br>Communication to the FHT80b is supported. * S300: receive<br>Examples of such devices: S300TH, KS300-2 * EM1000: receive<br>Devices: EM1000FM, EM1000GZ, EM1000WZ * HMS: receive<br>Devices: There are numerous HMS devices, all of them are fully supported. * ESA2000: receive * Lacrosse TX2/TX3: receive == Connection == The RFM12 is connected to the AVR like in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FSK/DATA/nFSS signal (Pin 3) is connected to one of the INT pins of the AVR. This modul does not work in interrupt mode, so the output nRQ signal (Pin 2) can be left unconnected. The software uses the digital filter of the RFM12. To improve sensitivity on short and long distances the [http://jeelabs.net/projects/cafe/wiki/Receiving_OOKASK_with_a_modified_RFM12B C_arssi capacitor needs to be replaced] with a value of 150 pF. The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_FS20_USE_INT(1) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_FS20_USE_INT defines whether FSK/DATA/nFSS is connected to INT0, INT1 or INT2 of the AVR. == Configuration == The FS20 system sends on 868,35 MHz, so the 868MHz option is the right one. | | I/O ---> | | ... | | Radio ---> | | ... | | [*] RFM12 ASK ---> | | ... | | [ ] 433MHz | | | | () RFM12 select | | | | [ ] External filter | | | | [-] Sensing | | | | --- | | | | [*] 868MHz | | | | (0) RFM12 select | | | | --- Debugging Flags | | | | [-] Sensing | | | | Protocols ---> | | ... | | Radio ---> | | ... | | [*] FS20 (868MHz) ---> | | ... | | (RFM12) Transmitter/receiver hardware | | | | [*] FS20 Send | | | | [*] FS20 Receive | | | | [*] FHT | | | | [ ] ESA | | | | [ ] TX3 | | | | [ ] Send received data via syslog | | | | --- Debugging Flags | | | | [ ] FS20 | | The modul uses Timer 2 of the AVR '''exclusively'''. Currently there is no option to use Timer 1, but this will change in the future. == [[ECMD]] == RFM12 FS20 implements an [[ECMD]] interface for send and receive FS20/FHT commands. The received data is formatted as described in the [http://culfw.de/commandref.html#protocol2 CULFW reference]. See [[ECMD_Reference|ECMD reference]] for a command list. == Troubleshooting == It may happen that not all of the RFM12 FS20 sensors are received. Here are some points that may help to improve reception: * Location: ** Avoid RF transmitter near the RFM12 ** Choose a position in the center of the sensors * Antenna: ** It is recommended to choose an antenna with a length not shorter than Lamda/2 (17,3cm) * Bandwidth: Default 400kHz ** Can be changed via ECMD from 400kHz to 67kHz (rfm12 setbandwidth <modulnumber> 1-6) * Gain: Default -14dB ** Can be changed via ECMD from 0dB to -20dB (rfm12 setgain <modulnumber> 0-3) * DRSSI: Default -97dB ** Can be changed via ECMD from -103dB to -61dB (rfm12 setdrssi <modulnumber> 0-7) Checkout the RFM12 datasheet for details on bandwidth, gain and DRSSI. == Decoding received data == The received data is formatted as described in the [http://culfw.de/commandref.html#protocol2 CULFW reference]. One could use the perl scripts from [http://culfw.de/ CULFW] to decode the data. [[Category:RFM12]] 83583985b0659fc681637adc4089fcda4eb11673 1264 1263 2014-07-24T17:57:39Z GooPie4o 265 /* Configuration */ wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->Radio->RFM12 ASK->868MHz |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |TIMER={{occupies_timer|2}} (RX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} The FS20 / FHT system by ELV is currently the most successful wireless home control system in the low cost sector. This arises from the large number of components and the continuous expansion of the system. But the relatively low price, the comprehensive home control systems far below the price of such EIB systems permits, plays a crucial role. This modul is based on [http://culfw.de CULFW by Rudolf Koenig] and supports a wide range of protocols: * FS20: send/receive<br>There are numerous FS20 devices, all of them are fully supported. * FHT: send/receive<br>Communication to the FHT80b is supported. * S300: receive<br>Examples of such devices: S300TH, KS300-2 * EM1000: receive<br>Devices: EM1000FM, EM1000GZ, EM1000WZ * HMS: receive<br>Devices: There are numerous HMS devices, all of them are fully supported. * ESA2000: receive * Lacrosse TX2/TX3: receive == Connection == The RFM12 is connected to the AVR like in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FSK/DATA/nFSS signal (Pin 3) is connected to one of the INT pins of the AVR. This modul does not work in interrupt mode, so the output nRQ signal (Pin 2) can be left unconnected. The software uses the digital filter of the RFM12. To improve sensitivity on short and long distances the [http://jeelabs.net/projects/cafe/wiki/Receiving_OOKASK_with_a_modified_RFM12B C_arssi capacitor needs to be replaced] with a value of 150 pF. The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_FS20_USE_INT(1) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_FS20_USE_INT defines whether FSK/DATA/nFSS is connected to INT0, INT1 or INT2 of the AVR. == Configuration == The FS20 system sends on 868,35 MHz, so the 868MHz option is the right one. | | I/O ---> | | ... | | Radio ---> | | ... | | [*] RFM12 ASK ---> | | ... | | [*] 868MHz | | | | (0) RFM12 select | | | | Protocols ---> | | ... | | Radio ---> | | ... | | [*] FS20 (868MHz) ---> | | ... | | (RFM12) Transmitter/receiver hardware | | | | [*] FS20 Send | | | | [*] FS20 Receive | | | | [*] FHT | | | | [ ] ESA | | | | [ ] TX3 | | | | [ ] Send received data via syslog | | | | --- Debugging Flags | | | | [ ] FS20 | | The modul uses Timer 2 of the AVR '''exclusively'''. Currently there is no option to use Timer 1, but this will change in the future. == [[ECMD]] == RFM12 FS20 implements an [[ECMD]] interface for send and receive FS20/FHT commands. The received data is formatted as described in the [http://culfw.de/commandref.html#protocol2 CULFW reference]. See [[ECMD_Reference|ECMD reference]] for a command list. == Troubleshooting == It may happen that not all of the RFM12 FS20 sensors are received. Here are some points that may help to improve reception: * Location: ** Avoid RF transmitter near the RFM12 ** Choose a position in the center of the sensors * Antenna: ** It is recommended to choose an antenna with a length not shorter than Lamda/2 (17,3cm) * Bandwidth: Default 400kHz ** Can be changed via ECMD from 400kHz to 67kHz (rfm12 setbandwidth <modulnumber> 1-6) * Gain: Default -14dB ** Can be changed via ECMD from 0dB to -20dB (rfm12 setgain <modulnumber> 0-3) * DRSSI: Default -97dB ** Can be changed via ECMD from -103dB to -61dB (rfm12 setdrssi <modulnumber> 0-7) Checkout the RFM12 datasheet for details on bandwidth, gain and DRSSI. == Decoding received data == The received data is formatted as described in the [http://culfw.de/commandref.html#protocol2 CULFW reference]. One could use the perl scripts from [http://culfw.de/ CULFW] to decode the data. [[Category:RFM12]] 870e35a380131afd40da6062444fcdf5c9882fa9 0 390 1266 2014-08-03T17:32:43Z Kpwg 721 Created page with "{{i18n|Nutzung in FHEM}} == Was ist FHEM? == [http://www.fhemwiki.de/wiki/Hauptseite FHEM] ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um di..." wikitext text/x-wiki {{i18n|Nutzung in FHEM}} == Was ist FHEM? == [http://www.fhemwiki.de/wiki/Hauptseite FHEM] ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um diverse per Funk und Kabel angebundene Komponenten aus dem Bereich der Hausautomation zu steuern. Er ist lizensiert unter der GPL v2. Eine erste Dokumentation zur Einbindung des AVR-Net-IO von [http://www.pollin.de Pollin] ist [http://www.fhemwiki.de/wiki/AVR-NET-IO hier] zu finden. Über [[ECMD]] lassen sich dabei theoretisch alle in Ethersex vorhandenen Möglichkeiten nutzen, sofern in FHEM entsprechende [http://fhem.de/commandref.html#ECMD ECMD-Devices] definiert und eingebunden werden. == 1-Wire Temperatursensoren == todo [[Category:Application|Application]] 9d9b571f894d78fb3b6add4827494af7bf0e3f77 1268 1266 2014-08-04T16:07:38Z Kpwg 721 wikitext text/x-wiki {{i18n|Nutzung in FHEM}} == Was ist FHEM? == [http://www.fhemwiki.de/wiki/Hauptseite FHEM] ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um diverse per Funk und Kabel angebundene Komponenten aus dem Bereich der Hausautomation zu steuern. Er ist lizensiert unter der GPL v2. Eine erste Dokumentation zur Einbindung des AVR-Net-IO von [http://www.pollin.de Pollin] ist [http://www.fhemwiki.de/wiki/AVR-NET-IO hier] zu finden. Über [[ECMD]] lassen sich dabei theoretisch alle in Ethersex vorhandenen Möglichkeiten nutzen, sofern in FHEM entsprechende [http://fhem.de/commandref.html#ECMD ECMD-Devices] definiert und eingebunden werden. == 1-Wire Temperatursensoren == todo == DHT22 Temperatursensoren == todo == BMP085/BMP180 Drucksensor == todo == analoge Eingänge == todo == LTC1257 D/A-Wandler == todo == HD44780 Punktmatrixdisplays == todo == Intertechno schalten mit RFM12 == todo == IC2272 schalten mit RFM12 == todo [[Category:Application|Application]] 2409980876ca385fc3fecd30cf8f9920519b8e57 1269 1268 2014-08-04T16:08:28Z Kpwg 721 /* DHT22 Temperatursensoren */ wikitext text/x-wiki {{i18n|Nutzung in FHEM}} == Was ist FHEM? == [http://www.fhemwiki.de/wiki/Hauptseite FHEM] ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um diverse per Funk und Kabel angebundene Komponenten aus dem Bereich der Hausautomation zu steuern. Er ist lizensiert unter der GPL v2. Eine erste Dokumentation zur Einbindung des AVR-Net-IO von [http://www.pollin.de Pollin] ist [http://www.fhemwiki.de/wiki/AVR-NET-IO hier] zu finden. Über [[ECMD]] lassen sich dabei theoretisch alle in Ethersex vorhandenen Möglichkeiten nutzen, sofern in FHEM entsprechende [http://fhem.de/commandref.html#ECMD ECMD-Devices] definiert und eingebunden werden. == 1-Wire Temperatursensoren == todo == DHT22 Temperatur-/Feuchtesensoren == todo == BMP085/BMP180 Drucksensor == todo == analoge Eingänge == todo == LTC1257 D/A-Wandler == todo == HD44780 Punktmatrixdisplays == todo == Intertechno schalten mit RFM12 == todo == IC2272 schalten mit RFM12 == todo [[Category:Application|Application]] 22253ab40c9854a89168f98c921e8721c4235891 1270 1269 2014-08-04T17:12:43Z GooPie4o 265 wikitext text/x-wiki {{i18n|Nutzung in FHEM}} [http://www.fhemwiki.de/wiki/Hauptseite FHEM] ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um diverse per Funk und Kabel angebundene Komponenten aus dem Bereich der Hausautomation zu steuern. Er ist lizensiert unter der GPL v2. Eine erste Dokumentation zur Einbindung des AVR-Net-IO von [http://www.pollin.de Pollin] ist [http://www.fhemwiki.de/wiki/AVR-NET-IO hier] zu finden. Über [[ECMD]] lassen sich dabei theoretisch alle in Ethersex vorhandenen Möglichkeiten nutzen, sofern in FHEM entsprechende [http://fhem.de/commandref.html#ECMD ECMD-Devices] definiert und eingebunden werden. == 1-Wire Temperatursensoren == todo == DHT22 Temperatur-/Feuchtesensoren == todo == BMP085/BMP180 Drucksensor == todo == analoge Eingänge == todo == LTC1257 D/A-Wandler == todo == HD44780 Punktmatrixdisplays == todo == Intertechno schalten mit RFM12 == todo == IC2272 schalten mit RFM12 == todo [[Category:Application|Application]] 37fca30200e4b4a115d88cfbc8259ee43220bdc9 1271 1270 2014-08-04T17:19:03Z GooPie4o 265 /* DHT22 Temperatur-/Feuchtesensoren */ wikitext text/x-wiki {{i18n|Nutzung in FHEM}} [http://www.fhemwiki.de/wiki/Hauptseite FHEM] ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um diverse per Funk und Kabel angebundene Komponenten aus dem Bereich der Hausautomation zu steuern. Er ist lizensiert unter der GPL v2. Eine erste Dokumentation zur Einbindung des AVR-Net-IO von [http://www.pollin.de Pollin] ist [http://www.fhemwiki.de/wiki/AVR-NET-IO hier] zu finden. Über [[ECMD]] lassen sich dabei theoretisch alle in Ethersex vorhandenen Möglichkeiten nutzen, sofern in FHEM entsprechende [http://fhem.de/commandref.html#ECMD ECMD-Devices] definiert und eingebunden werden. == 1-Wire Temperatursensoren == todo == [[DHT|DHT22 Temperatur-/Feuchtesensoren]] == todo == BMP085/BMP180 Drucksensor == todo == analoge Eingänge == todo == LTC1257 D/A-Wandler == todo == HD44780 Punktmatrixdisplays == todo == Intertechno schalten mit RFM12 == todo == IC2272 schalten mit RFM12 == todo [[Category:Application|Application]] 642f23d6b69b3b904ad45ab1b082b95e28253fd5 1272 1271 2014-08-04T17:21:27Z GooPie4o 265 wikitext text/x-wiki {{i18n|Nutzung in FHEM}} [http://www.fhemwiki.de/wiki/Hauptseite FHEM] ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um diverse per Funk und Kabel angebundene Komponenten aus dem Bereich der Hausautomation zu steuern. Er ist lizensiert unter der GPL v2. Das AVR-Net-IO von [http://www.pollin.de Pollin] mit [[Ethersex]] dient [http://www.fhemwiki.de/wiki/AVR-NET-IO als preisgünstige Einstieg in die Hausautomatisierung]. Über [[ECMD]] lassen sich dabei theoretisch alle in [[Ethersex vorhandenen]] Möglichkeiten nutzen, sofern in FHEM entsprechende [http://fhem.de/commandref.html#ECMD ECMD-Devices] definiert und eingebunden werden. == 1-Wire Temperatursensoren == todo == [[DHT|DHT22 Temperatur-/Feuchtesensoren]] == todo == BMP085/BMP180 Drucksensor == todo == analoge Eingänge == todo == LTC1257 D/A-Wandler == todo == HD44780 Punktmatrixdisplays == todo == Intertechno schalten mit RFM12 == todo == IC2272 schalten mit RFM12 == todo [[Category:Application|Application]] b62587fe6ebc4c753bb8d2268c2591f4a65abe0f 1273 1272 2014-08-04T17:22:23Z GooPie4o 265 wikitext text/x-wiki {{i18n|Nutzung in FHEM}} [http://www.fhemwiki.de/wiki/Hauptseite FHEM] ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um diverse per Funk und Kabel angebundene Komponenten aus dem Bereich der Hausautomation zu steuern. Er ist lizensiert unter der GPL v2. Das AVR-Net-IO von [http://www.pollin.de Pollin] mit [[Ethersex]] dient [http://www.fhemwiki.de/wiki/AVR-NET-IO als preisgünstige Einstieg in die Hausautomatisierung]. Über [[ECMD]] lassen sich dabei theoretisch alle in [[Ethersex]] vorhandenen Möglichkeiten nutzen, sofern in FHEM entsprechende [http://fhem.de/commandref.html#ECMD ECMD-Devices] definiert und eingebunden werden. == 1-Wire Temperatursensoren == todo == [[DHT|DHT22 Temperatur-/Feuchtesensoren]] == todo == BMP085/BMP180 Drucksensor == todo == analoge Eingänge == todo == LTC1257 D/A-Wandler == todo == HD44780 Punktmatrixdisplays == todo == Intertechno schalten mit RFM12 == todo == IC2272 schalten mit RFM12 == todo [[Category:Application|Application]] ce53b05e7931a5ffa04ddc83986b0617c6a140fd 1274 1273 2014-08-04T17:23:47Z GooPie4o 265 wikitext text/x-wiki {{i18n|Nutzung in FHEM}} [http://www.fhemwiki.de/wiki/Hauptseite FHEM] ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um diverse per Funk und Kabel angebundene Komponenten aus dem Bereich der Hausautomation zu steuern. Er ist lizensiert unter der GPL v2. Das AVR-Net-IO von [http://www.pollin.de Pollin] mit [[Ethersex]] dient als [http://www.fhemwiki.de/wiki/AVR-NET-IO preisgünstiger Einstieg in die Hausautomatisierung]. Über [[ECMD]] lassen sich dabei theoretisch alle in [[Ethersex]] vorhandenen Möglichkeiten nutzen, sofern in FHEM entsprechende [http://fhem.de/commandref.html#ECMD ECMD-Devices] definiert und eingebunden werden. == 1-Wire Temperatursensoren == todo == [[DHT|DHT22 Temperatur-/Feuchtesensoren]] == todo == BMP085/BMP180 Drucksensor == todo == analoge Eingänge == todo == LTC1257 D/A-Wandler == todo == HD44780 Punktmatrixdisplays == todo == Intertechno schalten mit RFM12 == todo == IC2272 schalten mit RFM12 == todo [[Category:Application|Application]] 26cb1053384a8ed6b1b4bcffa9c8620a3ba51ac2 1275 1274 2014-08-04T17:27:58Z GooPie4o 265 wikitext text/x-wiki {{i18n|Nutzung in FHEM}} [http://www.fhemwiki.de/wiki/Hauptseite FHEM] ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um diverse per Funk und Kabel angebundene Komponenten aus dem Bereich der Hausautomation zu steuern. Er ist lizensiert unter der GPL v2. Das [http://www.pollin.de/shop/suchergebnis.html?S_TEXT=810+058 AVR-Net-IO] von [http://www.pollin.de Pollin] mit [[Ethersex]] dient als [http://www.fhemwiki.de/wiki/AVR-NET-IO preisgünstiger Einstieg in die Hausautomatisierung]. Über [[ECMD]] lassen sich dabei theoretisch alle in [[Ethersex]] vorhandenen Möglichkeiten nutzen, sofern in FHEM entsprechende [http://fhem.de/commandref.html#ECMD ECMD-Devices] definiert und eingebunden werden. == 1-Wire Temperatursensoren == todo == [[DHT|DHT22 Temperatur-/Feuchtesensoren]] == todo == BMP085/BMP180 Drucksensor == todo == analoge Eingänge == todo == LTC1257 D/A-Wandler == todo == HD44780 Punktmatrixdisplays == todo == Intertechno schalten mit RFM12 == todo == IC2272 schalten mit RFM12 == todo [[Category:Application|Application]] 017e18264ba6296e5fc7ee6af8870c8af5d7ee5d 1276 1275 2014-08-05T18:07:21Z Kpwg 721 wikitext text/x-wiki {{i18n|Nutzung in FHEM}} [http://www.fhemwiki.de/wiki/Hauptseite FHEM] ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um diverse per Funk und Kabel angebundene Komponenten aus dem Bereich der Hausautomation zu steuern. Er ist lizensiert unter der GPL v2. Das [http://www.pollin.de/shop/suchergebnis.html?S_TEXT=810+058 AVR-Net-IO] von [http://www.pollin.de Pollin] mit [[Ethersex]] dient als [http://www.fhemwiki.de/wiki/AVR-NET-IO preisgünstiger Einstieg in die Hausautomatisierung]. Über [[ECMD]] lassen sich dabei theoretisch alle in [[Ethersex]] vorhandenen Möglichkeiten nutzen, sofern in FHEM entsprechende [http://fhem.de/commandref.html#ECMD ECMD-Devices] definiert und eingebunden werden. == Grundlagen == Ausgehend von einem fertigen und per Telnet erreichbaren Ethersex muss in FHEM zuerst per define das entsprechende Device definiert werden. <pre> define NETIO_WZ ECMD telnet 192.168.3.81:2701 </pre> Eine serielle Anbindung kann mit ''define <name> ECMD serial <SerialDevice>[<@BaudRate>]'' alternativ erfolgen. Anschließend werden die erstellten .classdef-Konfigurationsdateien der einzelnen Funktionen dem System bekannt gemacht. In diesen .classdef-Dateien (Name und Endung sind frei wählbar!) wird die Schnittstelle zwischen FHEM und ECMD/Ethersex definiert. Dabei können mit perl übergebene Parameter und empfangene Daten bearbeitet sowie die in FHEM gebräuchlichen Readings erstellt werden. <pre> attr NETIO_WZ classdefs RFM12_2272=/opt/fhem/FHEM/rfm12_2272.classdef:RFM12_IT=/opt/fhem/FHEM/rfm12_it.classdef:LCD=/opt/fhem/FHEM/lcd.classdef:DHT22=/opt/fhem/FHEM/dht22.classdef:1WIRE=/opt/fhem/FHEM/1wire.classdef </pre> Die Definitionen für IC2272, Intertechno, HD44780-LCD, DHT22 und 1wire wurden eingebunden. == 1-Wire Temperatursensoren == todo == [[DHT|DHT22 Temperatur-/Feuchtesensoren]] == todo == BMP085/BMP180 Drucksensor == todo == analoge Eingänge == todo == LTC1257 D/A-Wandler == todo == HD44780 Punktmatrixdisplays == todo == Intertechno schalten mit RFM12 == todo == IC2272 schalten mit RFM12 == todo [[Category:Application|Application]] d369e2062ecea0d11080f8299a1cdd3c3504c672 1277 1276 2014-08-06T15:18:25Z Kpwg 721 /* BMP085/BMP180 Drucksensor */ wikitext text/x-wiki {{i18n|Nutzung in FHEM}} [http://www.fhemwiki.de/wiki/Hauptseite FHEM] ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um diverse per Funk und Kabel angebundene Komponenten aus dem Bereich der Hausautomation zu steuern. Er ist lizensiert unter der GPL v2. Das [http://www.pollin.de/shop/suchergebnis.html?S_TEXT=810+058 AVR-Net-IO] von [http://www.pollin.de Pollin] mit [[Ethersex]] dient als [http://www.fhemwiki.de/wiki/AVR-NET-IO preisgünstiger Einstieg in die Hausautomatisierung]. Über [[ECMD]] lassen sich dabei theoretisch alle in [[Ethersex]] vorhandenen Möglichkeiten nutzen, sofern in FHEM entsprechende [http://fhem.de/commandref.html#ECMD ECMD-Devices] definiert und eingebunden werden. == Grundlagen == Ausgehend von einem fertigen und per Telnet erreichbaren Ethersex muss in FHEM zuerst per define das entsprechende Device definiert werden. <pre> define NETIO_WZ ECMD telnet 192.168.3.81:2701 </pre> Eine serielle Anbindung kann mit ''define <name> ECMD serial <SerialDevice>[<@BaudRate>]'' alternativ erfolgen. Anschließend werden die erstellten .classdef-Konfigurationsdateien der einzelnen Funktionen dem System bekannt gemacht. In diesen .classdef-Dateien (Name und Endung sind frei wählbar!) wird die Schnittstelle zwischen FHEM und ECMD/Ethersex definiert. Dabei können mit perl übergebene Parameter und empfangene Daten bearbeitet sowie die in FHEM gebräuchlichen Readings erstellt werden. <pre> attr NETIO_WZ classdefs RFM12_2272=/opt/fhem/FHEM/rfm12_2272.classdef:RFM12_IT=/opt/fhem/FHEM/rfm12_it.classdef:LCD=/opt/fhem/FHEM/lcd.classdef:DHT22=/opt/fhem/FHEM/dht22.classdef:1WIRE=/opt/fhem/FHEM/1wire.classdef </pre> Die Definitionen für IC2272, Intertechno, HD44780-LCD, DHT22 und 1wire wurden eingebunden. == 1-Wire Temperatursensoren == todo == [[DHT|DHT22 Temperatur-/Feuchtesensoren]] == todo == [[BMP085 | BMP085/BMP180 Drucksensor]] == Ethersex unterstützt den BMP085 (bzw. den BMP180; der Code ist identisch) über das [[I2C_(Deutsch) | I2C]]-Interface. Da der Sensor für 3.3V Betriebsspannung ausgelegt ist, muss entweder der I2C-Pegel angepasst oder der ATMega auf 3.3V adaptiert werden. Weiterhin sollte die Höhe über Null bekannt sein. Beispiel: Eine Abfrage per [[ECMD]] mit ''bmp085 pressnn 59000'' bedeutet, das ich 590m (59000cm) über NN wohne. Die im BMP180 verfügbare Temperatur wird gleichzeitig mit ausgelesen. '''Einbindung in FHEM''' bmp085.classdef erstellen <pre> get BMP cmd {"bmp085 temp\n\000bmp085 pressnn 59000\n"} get BMP expect ".*" get BMP postproc {\ s/(.*)\n(.*)\n/T: $1 P: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1/10;\ my $pressure = sprintf("%.1f",$2/100);\ my $state = "T: $temperature P: $pressure";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "pressure", $pressure, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </pre> Die Temperatur wird in °C mit einer Nachkommastelle gelesen, der Luftdruck in hPa bzw. mbar auf eine Nachkommastelle gerundet. Passende Readings werden erstellt. Das expect .* kann noch angepasst werden, um im Falle fehlerhafter Messwerte entsprechend zu reagieren. Die classdef wird in FHEM eingebunden: <pre> define NETIO_STK ECMD telnet 192.168.3.89:2701 attr NETIO_STK classdefs BMP=/opt/fhem/FHEM/bmp085.classdef </pre> Der Sensor wird definiert: <pre> define BMP180 ECMDDevice BMP attr BMP180 IODev NETIO_STK </pre> Das STATE kann etwas aufgehübscht werden: <pre> attr BMP180 stateFormat { sprintf("%s°C %shPa", ReadingsVal("BMP180","temperature",0), ReadingsVal("BMP180","pressure",0)) ;; } </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_BMP at +*00:04 get BMP180 BMP attr Messung_BMP verbose 0 </pre> == analoge Eingänge == todo == LTC1257 D/A-Wandler == todo == HD44780 Punktmatrixdisplays == todo == Intertechno schalten mit RFM12 == todo == IC2272 schalten mit RFM12 == todo [[Category:Application|Application]] 48783f7b2a53fcd6bd8fce40959133619a70f82d 1278 1277 2014-08-06T15:29:41Z Kpwg 721 /* BMP085/BMP180 Drucksensor */ wikitext text/x-wiki {{i18n|Nutzung in FHEM}} [http://www.fhemwiki.de/wiki/Hauptseite FHEM] ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um diverse per Funk und Kabel angebundene Komponenten aus dem Bereich der Hausautomation zu steuern. Er ist lizensiert unter der GPL v2. Das [http://www.pollin.de/shop/suchergebnis.html?S_TEXT=810+058 AVR-Net-IO] von [http://www.pollin.de Pollin] mit [[Ethersex]] dient als [http://www.fhemwiki.de/wiki/AVR-NET-IO preisgünstiger Einstieg in die Hausautomatisierung]. Über [[ECMD]] lassen sich dabei theoretisch alle in [[Ethersex]] vorhandenen Möglichkeiten nutzen, sofern in FHEM entsprechende [http://fhem.de/commandref.html#ECMD ECMD-Devices] definiert und eingebunden werden. == Grundlagen == Ausgehend von einem fertigen und per Telnet erreichbaren Ethersex muss in FHEM zuerst per define das entsprechende Device definiert werden. <pre> define NETIO_WZ ECMD telnet 192.168.3.81:2701 </pre> Eine serielle Anbindung kann mit ''define <name> ECMD serial <SerialDevice>[<@BaudRate>]'' alternativ erfolgen. Anschließend werden die erstellten .classdef-Konfigurationsdateien der einzelnen Funktionen dem System bekannt gemacht. In diesen .classdef-Dateien (Name und Endung sind frei wählbar!) wird die Schnittstelle zwischen FHEM und ECMD/Ethersex definiert. Dabei können mit perl übergebene Parameter und empfangene Daten bearbeitet sowie die in FHEM gebräuchlichen Readings erstellt werden. <pre> attr NETIO_WZ classdefs RFM12_2272=/opt/fhem/FHEM/rfm12_2272.classdef:RFM12_IT=/opt/fhem/FHEM/rfm12_it.classdef:LCD=/opt/fhem/FHEM/lcd.classdef:DHT22=/opt/fhem/FHEM/dht22.classdef:1WIRE=/opt/fhem/FHEM/1wire.classdef </pre> Die Definitionen für IC2272, Intertechno, HD44780-LCD, DHT22 und 1wire wurden eingebunden. == 1-Wire Temperatursensoren == todo == [[DHT|DHT22 Temperatur-/Feuchtesensoren]] == todo == [[BMP085 | BMP085/BMP180 Drucksensor]] == Ethersex unterstützt den BMP085 (bzw. den BMP180; der Code ist identisch) über das [[I2C_(Deutsch) | I2C]]-Interface. Da der Sensor für 3.3V Betriebsspannung ausgelegt ist, muss entweder der I2C-Pegel angepasst oder der ATMega auf 3.3V adaptiert werden. Weiterhin sollte die Höhe über Null bekannt sein. Beispiel: Eine Abfrage per [[ECMD]] mit ''bmp085 pressnn 59000'' bedeutet, das ich 590m (59000cm) über NN wohne. Die im Sensor verfügbare Temperatur wird parallel ausgelesen. '''Einbindung in FHEM''' bmp085.classdef erstellen <pre> get BMP cmd {"bmp085 temp\n\000bmp085 pressnn 59000\n"} get BMP expect ".*" get BMP postproc {\ s/(.*)\n(.*)\n/T: $1 P: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1/10;\ my $pressure = sprintf("%.1f",$2/100);\ my $state = "T: $temperature P: $pressure";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "pressure", $pressure, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </pre> Die Temperatur wird in °C mit einer Nachkommastelle gelesen, der Luftdruck in hPa bzw. mbar auf eine Nachkommastelle gerundet. Passende Readings werden erstellt. Das expect .* kann noch angepasst werden, um bei fehlerhaften Messwerten entsprechend zu reagieren. Die classdef wird in FHEM eingebunden (mehrere .classdef mit Doppelpunkt trennen: siehe [[Nutzung_in_FHEM_(Deutsch)#Grundlagen | Grundlagen]]): <pre> define NETIO_STK ECMD telnet 192.168.3.89:2701 attr NETIO_STK classdefs BMP=/opt/fhem/FHEM/bmp085.classdef </pre> Der Sensor wird definiert: <pre> define BMP180 ECMDDevice BMP attr BMP180 IODev NETIO_STK </pre> Das STATE ''kann'' mit Maßeinheiten versehen werden: <pre> attr BMP180 stateFormat { sprintf("%s°C %shPa", ReadingsVal("BMP180","temperature",0), ReadingsVal("BMP180","pressure",0)) ;; } </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_BMP at +*00:04 get BMP180 BMP attr Messung_BMP verbose 0 </pre> Dabei unterdrückt verbose 0 einen zusätzlichen (doppelten) Logeintrag des Messvorganges. == analoge Eingänge == todo == LTC1257 D/A-Wandler == todo == HD44780 Punktmatrixdisplays == todo == Intertechno schalten mit RFM12 == todo == IC2272 schalten mit RFM12 == todo [[Category:Application|Application]] 0d0ff9b1301f0f2de88af4127c557a3e76351c34 1279 1278 2014-08-06T15:47:26Z Kpwg 721 /* Grundlagen */ wikitext text/x-wiki {{i18n|Nutzung in FHEM}} [http://www.fhemwiki.de/wiki/Hauptseite FHEM] ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um diverse per Funk und Kabel angebundene Komponenten aus dem Bereich der Hausautomation zu steuern. Er ist lizensiert unter der GPL v2. Das [http://www.pollin.de/shop/suchergebnis.html?S_TEXT=810+058 AVR-Net-IO] von [http://www.pollin.de Pollin] mit [[Ethersex]] dient als [http://www.fhemwiki.de/wiki/AVR-NET-IO preisgünstiger Einstieg in die Hausautomatisierung]. Über [[ECMD]] lassen sich dabei theoretisch alle in [[Ethersex]] vorhandenen Möglichkeiten nutzen, sofern in FHEM entsprechende [http://fhem.de/commandref.html#ECMD ECMD-Devices] definiert und eingebunden werden. == Grundlagen == Ausgehend von einem fertigen und per Telnet erreichbaren Ethersex muss in FHEM zuerst per define das entsprechende Device definiert werden. <pre> define NETIO_WZ ECMD telnet 192.168.3.81:2701 </pre> Eine serielle Anbindung kann mit ''define <name> ECMD serial <SerialDevice>[<@BaudRate>]'' alternativ erfolgen. Anschließend werden die erstellten .classdef-Konfigurationsdateien der einzelnen Funktionen dem System bekannt gemacht. In diesen .classdef-Dateien (Name und Endung sind frei wählbar!) wird die Schnittstelle zwischen FHEM und ECMD/Ethersex definiert. Dabei können mit perl übergebene Parameter und empfangene Daten bearbeitet sowie die in FHEM gebräuchlichen Readings erstellt werden. <pre> attr NETIO_WZ classdefs RFM12_2272=/opt/fhem/FHEM/rfm12_2272.classdef:RFM12_IT=/opt/fhem/FHEM/rfm12_it.classdef:LCD=/opt/fhem/FHEM/lcd.classdef:DHT22=/opt/fhem/FHEM/dht22.classdef:1WIRE=/opt/fhem/FHEM/1wire.classdef </pre> Die Definitionen für IC2272, Intertechno, HD44780-LCD, DHT22 und 1wire sind nun eingebunden. In den folgenden Abschnitten wird auf die einzelnen Devices näher eingegangen. Generell sind Pfade und IP-Adressen sowie übergebene Parameter noch entsprechend der eigenen Konfiguration anzupassen. == 1-Wire Temperatursensoren == todo == [[DHT|DHT22 Temperatur-/Feuchtesensoren]] == todo == [[BMP085 | BMP085/BMP180 Drucksensor]] == Ethersex unterstützt den BMP085 (bzw. den BMP180; der Code ist identisch) über das [[I2C_(Deutsch) | I2C]]-Interface. Da der Sensor für 3.3V Betriebsspannung ausgelegt ist, muss entweder der I2C-Pegel angepasst oder der ATMega auf 3.3V adaptiert werden. Weiterhin sollte die Höhe über Null bekannt sein. Beispiel: Eine Abfrage per [[ECMD]] mit ''bmp085 pressnn 59000'' bedeutet, das ich 590m (59000cm) über NN wohne. Die im Sensor verfügbare Temperatur wird parallel ausgelesen. '''Einbindung in FHEM''' bmp085.classdef erstellen <pre> get BMP cmd {"bmp085 temp\n\000bmp085 pressnn 59000\n"} get BMP expect ".*" get BMP postproc {\ s/(.*)\n(.*)\n/T: $1 P: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1/10;\ my $pressure = sprintf("%.1f",$2/100);\ my $state = "T: $temperature P: $pressure";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "pressure", $pressure, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </pre> Die Temperatur wird in °C mit einer Nachkommastelle gelesen, der Luftdruck in hPa bzw. mbar auf eine Nachkommastelle gerundet. Passende Readings werden erstellt. Das expect .* kann noch angepasst werden, um bei fehlerhaften Messwerten entsprechend zu reagieren. Die classdef wird in FHEM eingebunden (mehrere .classdef mit Doppelpunkt trennen: siehe [[Nutzung_in_FHEM_(Deutsch)#Grundlagen | Grundlagen]]): <pre> define NETIO_STK ECMD telnet 192.168.3.89:2701 attr NETIO_STK classdefs BMP=/opt/fhem/FHEM/bmp085.classdef </pre> Der Sensor wird definiert: <pre> define BMP180 ECMDDevice BMP attr BMP180 IODev NETIO_STK </pre> Das STATE ''kann'' mit Maßeinheiten versehen werden: <pre> attr BMP180 stateFormat { sprintf("%s°C %shPa", ReadingsVal("BMP180","temperature",0), ReadingsVal("BMP180","pressure",0)) ;; } </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_BMP at +*00:04 get BMP180 BMP attr Messung_BMP verbose 0 </pre> Dabei unterdrückt verbose 0 einen zusätzlichen (doppelten) Logeintrag des Messvorganges. == analoge Eingänge == todo == LTC1257 D/A-Wandler == todo == HD44780 Punktmatrixdisplays == todo == Intertechno schalten mit RFM12 == todo == IC2272 schalten mit RFM12 == todo [[Category:Application|Application]] 2be07c466fcb0d477f509a864da5e824cad81552 1280 1279 2014-08-06T18:11:21Z Kpwg 721 wikitext text/x-wiki {{i18n|Nutzung in FHEM}} [http://www.fhemwiki.de/wiki/Hauptseite FHEM] ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um diverse per Funk und Kabel angebundene Komponenten aus dem Bereich der Hausautomation zu steuern. Er ist lizensiert unter der GPL v2. Das [http://www.pollin.de/shop/suchergebnis.html?S_TEXT=810+058 AVR-Net-IO] von [http://www.pollin.de Pollin] mit [[Ethersex]] dient als [http://www.fhemwiki.de/wiki/AVR-NET-IO preisgünstiger Einstieg in die Hausautomatisierung]. Über [[ECMD]] lassen sich dabei theoretisch alle in [[Ethersex]] vorhandenen Möglichkeiten nutzen, sofern in FHEM entsprechende [http://fhem.de/commandref.html#ECMD ECMD-Devices] definiert und eingebunden werden. == Grundlagen == Ausgehend von einem fertigen und per Telnet erreichbaren Ethersex muss in FHEM zuerst das entsprechende Device definiert werden. <pre> define NETIO_WZ ECMD telnet 192.168.3.81:2701 </pre> Eine serielle Anbindung kann mit ''define <name> ECMD serial <SerialDevice>[<@BaudRate>]'' alternativ erfolgen. Anschließend werden die erstellten .classdef-Konfigurationsdateien der einzelnen Funktionen dem System bekannt gemacht. In diesen .classdef-Dateien (Name und Endung sind frei wählbar!) wird die Schnittstelle zwischen FHEM und ECMD/Ethersex definiert. Dabei können mit perl übergebene Parameter und empfangene Daten bearbeitet sowie die in FHEM gebräuchlichen Readings erstellt werden. <pre> attr NETIO_WZ classdefs RFM12_2272=/opt/fhem/FHEM/rfm12_2272.classdef:RFM12_IT=/opt/fhem/FHEM/rfm12_it.classdef:LCD=/opt/fhem/FHEM/lcd.classdef:DHT22=/opt/fhem/FHEM/dht22.classdef:1WIRE=/opt/fhem/FHEM/1wire.classdef </pre> Die Definitionen für IC2272, Intertechno, HD44780-LCD, DHT22 und 1wire sind nun eingebunden. In den folgenden Abschnitten wird auf die einzelnen Devices näher eingegangen. Generell sind Pfade und IP-Adressen sowie übergebene Parameter noch entsprechend der eigenen Konfiguration anzupassen. == [[Onewire_(Deutsch) | 1-Wire Temperatursensoren]] == todo == [[DHT|DHT22 Temperatur-/Feuchtesensoren]] == todo == [[BMP085 | BMP085/BMP180 Luftdrucksensor]] == Ethersex unterstützt den BMP085 (bzw. den BMP180; der Code ist identisch) über das [[I2C_(Deutsch) | I2C]]-Interface. Da der Sensor für 3.3V Betriebsspannung ausgelegt ist, muss entweder der I2C-Pegel angepasst oder der ATMega auf 3.3V adaptiert werden. Weiterhin sollte die Höhe über Null bekannt sein. Beispiel: Eine Abfrage per [[ECMD]] mit ''bmp085 pressnn 59000'' bedeutet, das ich 590m (59000cm) über NN wohne. Die im Sensor verfügbare Temperatur wird parallel ausgelesen. '''Einbindung in FHEM''' bmp085.classdef erstellen <pre> get BMP cmd {"bmp085 temp\n\000bmp085 pressnn 59000\n"} get BMP expect ".*" get BMP postproc {\ s/(.*)\n(.*)\n/T: $1 P: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1/10;\ my $pressure = sprintf("%.1f",$2/100);\ my $state = "T: $temperature P: $pressure";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "pressure", $pressure, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </pre> Die Temperatur wird in °C mit einer Nachkommastelle gelesen, der Luftdruck in hPa bzw. mbar auf eine Nachkommastelle gerundet. Passende Readings werden erstellt. Das expect .* kann noch angepasst werden, um bei fehlerhaften Messwerten entsprechend zu reagieren. Die classdef wird in FHEM eingebunden (mehrere .classdef mit Doppelpunkt trennen: siehe [[Nutzung_in_FHEM_(Deutsch)#Grundlagen | Grundlagen]]): <pre> define NETIO_STK ECMD telnet 192.168.3.89:2701 attr NETIO_STK classdefs BMP=/opt/fhem/FHEM/bmp085.classdef </pre> Der Sensor wird definiert: <pre> define BMP180 ECMDDevice BMP attr BMP180 IODev NETIO_STK </pre> Das STATE ''kann'' mit Maßeinheiten versehen werden: <pre> attr BMP180 stateFormat { sprintf("%s°C %shPa", ReadingsVal("BMP180","temperature",0), ReadingsVal("BMP180","pressure",0)) ;; } </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_BMP at +*00:04 get BMP180 BMP attr Messung_BMP verbose 0 </pre> Dabei unterdrückt verbose 0 einen zusätzlichen (doppelten) Logeintrag des Messvorganges. == analoge Eingänge == todo == LTC1257 D/A-Wandler == todo == HD44780 Punktmatrixdisplays == todo == [[RFM12_ASK_(Deutsch) | Intertechno schalten mit RFM12]] == todo == [[RFM12_ASK_(Deutsch) | IC2272 schalten mit RFM12]] == todo [[Category:Application|Application]] a727ad05de8d34584573b6f392f2149508e793ef 1282 1280 2014-08-07T15:07:01Z Kpwg 721 /* BMP085/BMP180 Luftdrucksensor */ wikitext text/x-wiki {{i18n|Nutzung in FHEM}} [http://www.fhemwiki.de/wiki/Hauptseite FHEM] ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um diverse per Funk und Kabel angebundene Komponenten aus dem Bereich der Hausautomation zu steuern. Er ist lizensiert unter der GPL v2. Das [http://www.pollin.de/shop/suchergebnis.html?S_TEXT=810+058 AVR-Net-IO] von [http://www.pollin.de Pollin] mit [[Ethersex]] dient als [http://www.fhemwiki.de/wiki/AVR-NET-IO preisgünstiger Einstieg in die Hausautomatisierung]. Über [[ECMD]] lassen sich dabei theoretisch alle in [[Ethersex]] vorhandenen Möglichkeiten nutzen, sofern in FHEM entsprechende [http://fhem.de/commandref.html#ECMD ECMD-Devices] definiert und eingebunden werden. == Grundlagen == Ausgehend von einem fertigen und per Telnet erreichbaren Ethersex muss in FHEM zuerst das entsprechende Device definiert werden. <pre> define NETIO_WZ ECMD telnet 192.168.3.81:2701 </pre> Eine serielle Anbindung kann mit ''define <name> ECMD serial <SerialDevice>[<@BaudRate>]'' alternativ erfolgen. Anschließend werden die erstellten .classdef-Konfigurationsdateien der einzelnen Funktionen dem System bekannt gemacht. In diesen .classdef-Dateien (Name und Endung sind frei wählbar!) wird die Schnittstelle zwischen FHEM und ECMD/Ethersex definiert. Dabei können mit perl übergebene Parameter und empfangene Daten bearbeitet sowie die in FHEM gebräuchlichen Readings erstellt werden. <pre> attr NETIO_WZ classdefs RFM12_2272=/opt/fhem/FHEM/rfm12_2272.classdef:RFM12_IT=/opt/fhem/FHEM/rfm12_it.classdef:LCD=/opt/fhem/FHEM/lcd.classdef:DHT22=/opt/fhem/FHEM/dht22.classdef:1WIRE=/opt/fhem/FHEM/1wire.classdef </pre> Die Definitionen für IC2272, Intertechno, HD44780-LCD, DHT22 und 1wire sind nun eingebunden. In den folgenden Abschnitten wird auf die einzelnen Devices näher eingegangen. Generell sind Pfade und IP-Adressen sowie übergebene Parameter noch entsprechend der eigenen Konfiguration anzupassen. == [[Onewire_(Deutsch) | 1-Wire Temperatursensoren]] == todo == [[DHT|DHT22 Temperatur-/Feuchtesensoren]] == todo == [[BMP085 | BMP085/BMP180 Luftdrucksensor]] == [[File:BMP180.jpg|150px|thumb|right|BMP180 (unten links)]] Ethersex unterstützt den BMP085 (bzw. den BMP180; der Code ist identisch) über das [[I2C_(Deutsch) | I2C]]-Interface. Da der Sensor für 3.3V Betriebsspannung ausgelegt ist, muss entweder der I2C-Pegel angepasst oder der ATMega auf 3.3V adaptiert werden. Weiterhin sollte die Höhe über Null bekannt sein. Beispiel: Eine Abfrage per [[ECMD]] mit ''bmp085 pressnn 59000'' bedeutet, das ich 590m (59000cm) über NN wohne. Die im Sensor verfügbare Temperatur wird parallel ausgelesen. '''Einbindung in FHEM''' bmp085.classdef erstellen <pre> get BMP cmd {"bmp085 temp\n\000bmp085 pressnn 59000\n"} get BMP expect ".*" get BMP postproc {\ s/(.*)\n(.*)\n/T: $1 P: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1/10;\ my $pressure = sprintf("%.1f",$2/100);\ my $state = "T: $temperature P: $pressure";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "pressure", $pressure, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </pre> Die Temperatur wird in °C mit einer Nachkommastelle gelesen, der Luftdruck in hPa bzw. mbar auf eine Nachkommastelle gerundet. Passende Readings werden erstellt. Das expect .* kann noch angepasst werden, um bei fehlerhaften Messwerten entsprechend zu reagieren. Die classdef wird in FHEM eingebunden (mehrere .classdef mit Doppelpunkt trennen: siehe [[Nutzung_in_FHEM_(Deutsch)#Grundlagen | Grundlagen]]): <pre> define NETIO_STK ECMD telnet 192.168.3.89:2701 attr NETIO_STK classdefs BMP=/opt/fhem/FHEM/bmp085.classdef </pre> Der Sensor wird definiert: <pre> define BMP180 ECMDDevice BMP attr BMP180 IODev NETIO_STK </pre> Das STATE ''kann'' mit Maßeinheiten versehen werden: <pre> attr BMP180 stateFormat { sprintf("%s°C %shPa", ReadingsVal("BMP180","temperature",0), ReadingsVal("BMP180","pressure",0)) ;; } </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_BMP at +*00:04 get BMP180 BMP attr Messung_BMP verbose 0 </pre> Dabei unterdrückt verbose 0 einen zusätzlichen (doppelten) Logeintrag des Messvorganges. == analoge Eingänge == todo == LTC1257 D/A-Wandler == todo == HD44780 Punktmatrixdisplays == todo == [[RFM12_ASK_(Deutsch) | Intertechno schalten mit RFM12]] == todo == [[RFM12_ASK_(Deutsch) | IC2272 schalten mit RFM12]] == todo [[Category:Application|Application]] 58475106bdb16bcaac07143b94173443148eef14 1283 1282 2014-08-10T11:07:45Z Kpwg 721 wikitext text/x-wiki {{i18n|Nutzung in FHEM}} [http://www.fhemwiki.de/wiki/Hauptseite FHEM] ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um diverse per Funk und Kabel angebundene Komponenten aus dem Bereich der Hausautomation zu steuern. Er ist lizensiert unter der GPL v2. Das [http://www.pollin.de/shop/suchergebnis.html?S_TEXT=810+058 AVR-Net-IO] von [http://www.pollin.de Pollin] mit [[Ethersex]] dient als [http://www.fhemwiki.de/wiki/AVR-NET-IO preisgünstiger Einstieg in die Hausautomatisierung]. Verwendbar ist aber auch jede andere Hardware, die von Ethersex unterstützt wird ([http://arduino.cc/en/pmwiki.php?n=Main/ArduinoBoardProMini Arduino], eigene Entwicklungen, etc.). Über [[ECMD]] lassen sich dabei theoretisch alle in [[Ethersex]] vorhandenen Möglichkeiten nutzen, sofern in FHEM entsprechende [http://fhem.de/commandref.html#ECMD ECMD-Devices] definiert und eingebunden werden. == Grundlagen == Ausgehend von einem fertigen und per Telnet erreichbaren Ethersex muss in FHEM zuerst das entsprechende Device definiert werden. <pre> define NETIO_WZ ECMD telnet 192.168.3.81:2701 </pre> Eine serielle Anbindung kann mit ''define <name> ECMD serial <SerialDevice>[<@BaudRate>]'' alternativ erfolgen. Anschließend werden die erstellten .classdef-Konfigurationsdateien der einzelnen Funktionen dem System bekannt gemacht. In diesen .classdef-Dateien (Name und Endung sind frei wählbar!) wird die Schnittstelle zwischen FHEM und ECMD/Ethersex definiert. Dabei können mit perl übergebene Parameter und empfangene Daten bearbeitet sowie die in FHEM gebräuchlichen Readings erstellt werden. <pre> attr NETIO_WZ classdefs RFM12_2272=/opt/fhem/FHEM/rfm12_2272.classdef:RFM12_IT=/opt/fhem/FHEM/rfm12_it.classdef:LCD=/opt/fhem/FHEM/lcd.classdef:DHT22=/opt/fhem/FHEM/dht22.classdef:1WIRE=/opt/fhem/FHEM/1wire.classdef </pre> Die Definitionen für IC2272, Intertechno, HD44780-LCD, DHT22 und 1wire sind nun eingebunden. In den folgenden Abschnitten wird auf die einzelnen Devices näher eingegangen. Generell sind Pfade und IP-Adressen sowie übergebene Parameter noch entsprechend der eigenen Konfiguration anzupassen. == [[Onewire_(Deutsch) | 1-Wire Temperatursensoren]] == todo == [[DHT|DHT22 Temperatur-/Feuchtesensoren]] == todo == [[BMP085 | BMP085/BMP180 Luftdrucksensor]] == [[File:BMP180.jpg|150px|thumb|right|BMP180 (unten links)]] Ethersex unterstützt den BMP085 (bzw. den BMP180; der Code ist identisch) über das [[I2C_(Deutsch) | I2C]]-Interface. Da der Sensor für 3.3V Betriebsspannung ausgelegt ist, muss entweder der I2C-Pegel angepasst oder der ATMega auf 3.3V adaptiert werden. Weiterhin sollte die Höhe über Null bekannt sein. Beispiel: Eine Abfrage per [[ECMD]] mit ''bmp085 pressnn 59000'' bedeutet, das ich 590m (59000cm) über NN wohne. Die im Sensor verfügbare Temperatur wird parallel ausgelesen. '''Einbindung in FHEM''' bmp085.classdef erstellen <pre> get BMP cmd {"bmp085 temp\n\000bmp085 pressnn 59000\n"} get BMP expect ".*" get BMP postproc {\ s/(.*)\n(.*)\n/T: $1 P: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1/10;\ my $pressure = sprintf("%.1f",$2/100);\ my $state = "T: $temperature P: $pressure";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "pressure", $pressure, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </pre> Die Temperatur wird in °C mit einer Nachkommastelle gelesen, der Luftdruck in hPa bzw. mbar auf eine Nachkommastelle gerundet. Passende Readings werden erstellt. Das expect .* kann noch angepasst werden, um bei fehlerhaften Messwerten entsprechend zu reagieren. Die classdef wird in FHEM eingebunden (mehrere .classdef mit Doppelpunkt trennen: siehe [[Nutzung_in_FHEM_(Deutsch)#Grundlagen | Grundlagen]]): <pre> define NETIO_STK ECMD telnet 192.168.3.89:2701 attr NETIO_STK classdefs BMP=/opt/fhem/FHEM/bmp085.classdef </pre> Der Sensor wird definiert: <pre> define BMP180 ECMDDevice BMP attr BMP180 IODev NETIO_STK </pre> Das STATE ''kann'' mit Maßeinheiten versehen werden: <pre> attr BMP180 stateFormat { sprintf("%s°C %shPa", ReadingsVal("BMP180","temperature",0), ReadingsVal("BMP180","pressure",0)) ;; } </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_BMP at +*00:04 get BMP180 BMP attr Messung_BMP verbose 0 </pre> Dabei unterdrückt verbose 0 einen zusätzlichen (doppelten) Logeintrag des Messvorganges. == analoge Eingänge == todo == LTC1257 D/A-Wandler == todo == HD44780 Punktmatrixdisplays == todo == [[RFM12_ASK_(Deutsch) | Intertechno schalten mit RFM12]] == todo == [[RFM12_ASK_(Deutsch) | IC2272 schalten mit RFM12]] == todo [[Category:Application|Application]] df67415aedc5617e641863a94fe96c55d5211433 1287 1283 2014-08-10T11:58:35Z Kpwg 721 wikitext text/x-wiki {{i18n|Nutzung in FHEM}} [http://www.fhemwiki.de/wiki/Hauptseite FHEM] ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um diverse per Funk und Kabel angebundene Komponenten aus dem Bereich der Hausautomation zu steuern. Er ist lizensiert unter der GPL v2. Das [http://www.pollin.de/shop/suchergebnis.html?S_TEXT=810+058 AVR-Net-IO] von [http://www.pollin.de Pollin] mit [[Ethersex]] dient als [http://www.fhemwiki.de/wiki/AVR-NET-IO preisgünstiger Einstieg in die Hausautomatisierung]. Verwendbar ist aber auch jede andere Hardware, die von Ethersex unterstützt wird ([http://arduino.cc/en/pmwiki.php?n=Main/ArduinoBoardProMini Arduino], eigene Entwicklungen, etc.). Über [[ECMD]] lassen sich dabei theoretisch alle in [[Ethersex]] vorhandenen Möglichkeiten nutzen, sofern in FHEM entsprechende [http://fhem.de/commandref.html#ECMD ECMD-Devices] definiert und eingebunden werden. == Grundlagen == Ausgehend von einem fertigen und per Telnet erreichbaren Ethersex muss in FHEM zuerst das entsprechende Device definiert werden. <pre> define NETIO_WZ ECMD telnet 192.168.3.81:2701 </pre> Eine serielle Anbindung kann mit ''define <name> ECMD serial <SerialDevice>[<@BaudRate>]'' alternativ erfolgen. Anschließend werden die erstellten .classdef-Konfigurationsdateien der einzelnen Funktionen dem System bekannt gemacht. In diesen .classdef-Dateien (Name und Endung sind frei wählbar!) wird die Schnittstelle zwischen FHEM und ECMD/Ethersex definiert. Dabei können mit perl übergebene Parameter und empfangene Daten bearbeitet sowie die in FHEM gebräuchlichen Readings erstellt werden. <pre> attr NETIO_WZ classdefs RFM12_2272=/opt/fhem/FHEM/rfm12_2272.classdef:RFM12_IT=/opt/fhem/FHEM/rfm12_it.classdef:LCD=/opt/fhem/FHEM/lcd.classdef:DHT22=/opt/fhem/FHEM/dht22.classdef:1WIRE=/opt/fhem/FHEM/1wire.classdef </pre> Die Definitionen für IC2272, Intertechno, HD44780-LCD, DHT22 und 1wire sind nun eingebunden. In den folgenden Abschnitten wird auf die einzelnen Devices näher eingegangen. Generell sind Pfade und IP-Adressen sowie übergebene Parameter noch entsprechend der eigenen Konfiguration anzupassen. == [[Onewire_(Deutsch) | 1-Wire Temperatursensoren]] == todo == [[DHT|DHT22 Temperatur-/Feuchtesensoren]] == todo == [[BMP085 | BMP085/BMP180 Luftdrucksensor]] == [[File:BMP180.jpg|150px|thumb|right|BMP180 (unten links)]] Ethersex unterstützt den BMP085 (bzw. den BMP180; der Code ist identisch) über das [[I2C_(Deutsch) | I2C]]-Interface. Da der Sensor für 3.3V Betriebsspannung ausgelegt ist, muss entweder der I2C-Pegel angepasst oder der ATMega auf 3.3V adaptiert werden. Weiterhin sollte die Höhe über Null bekannt sein. Beispiel: Eine Abfrage per [[ECMD]] mit ''bmp085 pressnn 59000'' bedeutet, das ich 590m (59000cm) über NN wohne. Die im Sensor verfügbare Temperatur wird parallel ausgelesen. '''Einbindung in FHEM''' bmp085.classdef erstellen <pre> get BMP cmd {"bmp085 temp\n\000bmp085 pressnn 59000\n"} get BMP expect ".*" get BMP postproc {\ s/(.*)\n(.*)\n/T: $1 P: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1/10;\ my $pressure = sprintf("%.1f",$2/100);\ my $state = "T: $temperature P: $pressure";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "pressure", $pressure, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </pre> Die Temperatur wird in °C mit einer Nachkommastelle gelesen, der Luftdruck in hPa bzw. mbar auf eine Nachkommastelle gerundet. Passende Readings werden erstellt. Das expect .* kann noch angepasst werden, um bei fehlerhaften Messwerten entsprechend zu reagieren. Die classdef wird in FHEM eingebunden (mehrere .classdef mit Doppelpunkt trennen: siehe [[Nutzung_in_FHEM_(Deutsch)#Grundlagen | Grundlagen]]): <pre> define NETIO_STK ECMD telnet 192.168.3.89:2701 attr NETIO_STK classdefs BMP=/opt/fhem/FHEM/bmp085.classdef </pre> Der Sensor wird definiert: <pre> define BMP180 ECMDDevice BMP attr BMP180 IODev NETIO_STK </pre> Das STATE ''kann'' mit Maßeinheiten versehen werden: <pre> attr BMP180 stateFormat { sprintf("%s°C %shPa", ReadingsVal("BMP180","temperature",0), ReadingsVal("BMP180","pressure",0)) ;; } </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_BMP at +*00:04 get BMP180 BMP attr Messung_BMP verbose 0 </pre> Dabei unterdrückt verbose 0 einen zusätzlichen (doppelten) Logeintrag des Messvorganges. == analoge Eingänge == todo == [[Porterweiterungen_%28Deutsch%29#D.2FA-Wandler_mit_LTC1257 | LTC1257 D/A-Wandler]] == todo == HD44780 Punktmatrixdisplays == todo == [[RFM12_ASK_(Deutsch) | Intertechno schalten mit RFM12]] == todo == [[RFM12_ASK_(Deutsch) | IC2272 schalten mit RFM12]] == todo [[Category:Application|Application]] b927a16305709b4e7c390ec94e95cea0d29b568d 1303 1287 2014-08-13T15:30:09Z Kpwg 721 /* DHT22 Temperatur-/Feuchtesensoren */ wikitext text/x-wiki {{i18n|Nutzung in FHEM}} [http://www.fhemwiki.de/wiki/Hauptseite FHEM] ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um diverse per Funk und Kabel angebundene Komponenten aus dem Bereich der Hausautomation zu steuern. Er ist lizensiert unter der GPL v2. Das [http://www.pollin.de/shop/suchergebnis.html?S_TEXT=810+058 AVR-Net-IO] von [http://www.pollin.de Pollin] mit [[Ethersex]] dient als [http://www.fhemwiki.de/wiki/AVR-NET-IO preisgünstiger Einstieg in die Hausautomatisierung]. Verwendbar ist aber auch jede andere Hardware, die von Ethersex unterstützt wird ([http://arduino.cc/en/pmwiki.php?n=Main/ArduinoBoardProMini Arduino], eigene Entwicklungen, etc.). Über [[ECMD]] lassen sich dabei theoretisch alle in [[Ethersex]] vorhandenen Möglichkeiten nutzen, sofern in FHEM entsprechende [http://fhem.de/commandref.html#ECMD ECMD-Devices] definiert und eingebunden werden. == Grundlagen == Ausgehend von einem fertigen und per Telnet erreichbaren Ethersex muss in FHEM zuerst das entsprechende Device definiert werden. <pre> define NETIO_WZ ECMD telnet 192.168.3.81:2701 </pre> Eine serielle Anbindung kann mit ''define <name> ECMD serial <SerialDevice>[<@BaudRate>]'' alternativ erfolgen. Anschließend werden die erstellten .classdef-Konfigurationsdateien der einzelnen Funktionen dem System bekannt gemacht. In diesen .classdef-Dateien (Name und Endung sind frei wählbar!) wird die Schnittstelle zwischen FHEM und ECMD/Ethersex definiert. Dabei können mit perl übergebene Parameter und empfangene Daten bearbeitet sowie die in FHEM gebräuchlichen Readings erstellt werden. <pre> attr NETIO_WZ classdefs RFM12_2272=/opt/fhem/FHEM/rfm12_2272.classdef:RFM12_IT=/opt/fhem/FHEM/rfm12_it.classdef:LCD=/opt/fhem/FHEM/lcd.classdef:DHT22=/opt/fhem/FHEM/dht22.classdef:1WIRE=/opt/fhem/FHEM/1wire.classdef </pre> Die Definitionen für IC2272, Intertechno, HD44780-LCD, DHT22 und 1wire sind nun eingebunden. In den folgenden Abschnitten wird auf die einzelnen Devices näher eingegangen. Generell sind Pfade und IP-Adressen sowie übergebene Parameter noch entsprechend der eigenen Konfiguration anzupassen. == [[Onewire_(Deutsch) | 1-Wire Temperatursensoren]] == todo == [[DHT|DHT22 Temperatur-/Feuchtesensoren]] == [[File:DHT22.jpg|150px|thumb|right|DHT22-Sensoren]] Es werden seit 05/2014 mehrere der preiswerten, aber recht genauen DHT22 Temperatur-/Feuchtesensoren in einem Ethersex unterstützt. Die Sensoren benötigen 5V Betriebsspannung und kommunizieren über je einen Pin mit dem Prozessor. Der Preis pro Stück liegt derzeit bei ebay etwa bei 3.50 Euro. Wer die Trägheit und Ungenauigkeit der S300TH oder TX29DTH kennt, wünscht sich vermutlich Besseres; vor allem bei Berechnung von Taupunkt und absoluter Feuchte, welche von Genauigkeit sehr profitieren. Vor- und Nachteile sind bereits [[DHT#DHT11_vs_DHT22 | hier]] erklärt. '''Einbindung in FHEM''' dht22m.classdef: <pre> # Uebergabeparameter DHT22 ID 0...n params devID # Umsetzung in ECMD Befehle fuer DHT22 get DHT cmd {"dht temp %devID\n\000dht humid %devID\n"} get DHT expect "\d+.\d\n" get DHT postproc {\ s/(.*)\n(.*)\n/T: $1 H: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1;\ my $humidity = $2;\ my $state = $_;\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "humidity", $humidity, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </pre> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs LCD=/opt/fhem/FHEM/lcd.classdef:DHT22M=/opt/fhem/FHEM/dht22m.classdef </pre> Die Sensoren werden definiert: <pre> define Test0 ECMDDevice DHT22M 0 attr Test0 IODev NETIO_TEST define Test1 ECMDDevice DHT22M 1 attr Test1 IODev NETIO_TEST define Test2 ECMDDevice DHT22M 2 attr Test2 IODev NETIO_TEST define Test3 ECMDDevice DHT22M 3 attr Test3 IODev NETIO_TEST </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_DHT at +*00:04 get Test0 DHT;; get Test1 DHT;; get Test2 DHT;; get Test3 DHT attr Messung_DHT verbose 0 </pre> Fünfzehn Messwerte pro Stunde genügen den allermeisten Anforderungen. == [[BMP085 | BMP085/BMP180 Luftdrucksensor]] == [[File:BMP180.jpg|150px|thumb|right|BMP180 (unten links)]] Ethersex unterstützt den BMP085 (bzw. den BMP180; der Code ist identisch) über das [[I2C_(Deutsch) | I2C]]-Interface. Da der Sensor für 3.3V Betriebsspannung ausgelegt ist, muss entweder der I2C-Pegel angepasst oder der ATMega auf 3.3V adaptiert werden. Weiterhin sollte die Höhe über Null bekannt sein. Beispiel: Eine Abfrage per [[ECMD]] mit ''bmp085 pressnn 59000'' bedeutet, das ich 590m (59000cm) über NN wohne. Die im Sensor verfügbare Temperatur wird parallel ausgelesen. '''Einbindung in FHEM''' bmp085.classdef erstellen <pre> get BMP cmd {"bmp085 temp\n\000bmp085 pressnn 59000\n"} get BMP expect ".*" get BMP postproc {\ s/(.*)\n(.*)\n/T: $1 P: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1/10;\ my $pressure = sprintf("%.1f",$2/100);\ my $state = "T: $temperature P: $pressure";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "pressure", $pressure, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </pre> Die Temperatur wird in °C mit einer Nachkommastelle gelesen, der Luftdruck in hPa bzw. mbar auf eine Nachkommastelle gerundet. Passende Readings werden erstellt. Das expect .* kann noch angepasst werden, um bei fehlerhaften Messwerten entsprechend zu reagieren. Die classdef wird in FHEM eingebunden (mehrere .classdef mit Doppelpunkt trennen: siehe [[Nutzung_in_FHEM_(Deutsch)#Grundlagen | Grundlagen]]): <pre> define NETIO_STK ECMD telnet 192.168.3.89:2701 attr NETIO_STK classdefs BMP=/opt/fhem/FHEM/bmp085.classdef </pre> Der Sensor wird definiert: <pre> define BMP180 ECMDDevice BMP attr BMP180 IODev NETIO_STK </pre> Das STATE ''kann'' mit Maßeinheiten versehen werden: <pre> attr BMP180 stateFormat { sprintf("%s°C %shPa", ReadingsVal("BMP180","temperature",0), ReadingsVal("BMP180","pressure",0)) ;; } </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_BMP at +*00:04 get BMP180 BMP attr Messung_BMP verbose 0 </pre> Dabei unterdrückt verbose 0 einen zusätzlichen (doppelten) Logeintrag des Messvorganges. == analoge Eingänge == todo == [[Porterweiterungen_%28Deutsch%29#D.2FA-Wandler_mit_LTC1257 | LTC1257 D/A-Wandler]] == todo == HD44780 Punktmatrixdisplays == todo == [[RFM12_ASK_(Deutsch) | Intertechno schalten mit RFM12]] == todo == [[RFM12_ASK_(Deutsch) | IC2272 schalten mit RFM12]] == todo [[Category:Application|Application]] 927f73ec0cdf412bd5613575789ace448280b662 6 391 1281 2014-08-07T15:01:29Z Kpwg 721 Luftdrucksensor BMP180 wikitext text/x-wiki Luftdrucksensor BMP180 94238bf640f0b1cd80ac85d001a21e02b6cc9f27 6 392 1284 2014-08-10T11:33:57Z Kpwg 721 Temperatur-/Feuchtesensor DHT22 (AM2302) wikitext text/x-wiki Temperatur-/Feuchtesensor DHT22 (AM2302) cc62154bbe0771b5ce2e7afd37698f72ce3573ce 6 393 1285 2014-08-10T11:34:51Z Kpwg 721 1wire Temperatursensoren DS18B20 wikitext text/x-wiki 1wire Temperatursensoren DS18B20 d83ba5c20c682c2511b734c27fdab6c664d1de84 6 394 1286 2014-08-10T11:35:40Z Kpwg 721 HD44780 und kompatible Displays wikitext text/x-wiki HD44780 und kompatible Displays ce574346e52a0e2227b7745acebff790c39698c7 0 395 1292 2014-08-12T12:03:52Z Coffee 722 übertrage Seite aus dem alten Wiki wikitext text/x-wiki Der Support für den [http://arduino.cc/en/Main/ArduinoBoardDuemilanove Arduino Duemilanove] ist noch experimentell! == Named Pin Konfiguration == Hier die passende core/portio/config für [[Named_PIN]] * Named Pin muss aktiviert sein! # # Named Pin Configuration File # # You can assign names to your microcontroller's pins here. # Keep in mind that this names must consist of alphanumeric # characters only! # # Every line starting with a hash sign (#) is a comment. # # # PIN | IN/OUT | When active? | Name #-----+--------+--------------+---------------- PD0 OUTPUT HIGH p0 PD1 OUTPUT HIGH p1 PD2 OUTPUT HIGH p2 PD3 OUTPUT HIGH p3 PD4 OUTPUT HIGH p4 PD5 OUTPUT HIGH p5 PD6 OUTPUT HIGH p6 PD7 OUTPUT HIGH p7 PB0 OUTPUT HIGH p8 PB1 OUTPUT HIGH p9 PB2 OUTPUT HIGH p10 PB3 OUTPUT HIGH p11 PB4 OUTPUT HIGH p12 PB5 OUTPUT HIGH p13 PC0 INPUT HIGH a1 PC1 INPUT HIGH a2 PC2 INPUT HIGH a3 PC3 INPUT HIGH a4 PC4 INPUT HIGH a5 PC5 INPUT HIGH a6 == Control6 Scripte == Einen Einstieg in [[Control6]] gibt es auch auf der Seite für [[PIN_Commands]] === Beispiel für ein [[Control6]] mit Named Pin=== * Script unter control6/control6.src * control6 muss aktiviert sein! * [[Named_Pin]] muss aktiviert sein! THREAD(arduino_blink) PIN_CLEAR(p13); WAIT(1); PIN_SET(p13); WAIT(1); THREAD_END(arduino_blink) THREAD_START(arduino_blink) === Beispiel ohne Named Pin === * Script unter control6/control6.src THREAD(arduino_blink) PORTB &= ~_BV(PB5); WAIT(1); PORTB |= _BV(PB5); WAIT(1); THREAD_END(arduino_blink) THREAD_START(arduino_blink) [[Category:Hardware]] [[Category:Arduino]] [[Category:Control6]] [[Category:Control6_Examples]] b2755b3eda904d4369180cc012b7dc217a20b220 1293 1292 2014-08-12T12:04:40Z Coffee 722 entferne Seite aus Kategorien die im neuen Wiki nicht existieren wikitext text/x-wiki Der Support für den [http://arduino.cc/en/Main/ArduinoBoardDuemilanove Arduino Duemilanove] ist noch experimentell! == Named Pin Konfiguration == Hier die passende core/portio/config für [[Named_PIN]] * Named Pin muss aktiviert sein! # # Named Pin Configuration File # # You can assign names to your microcontroller's pins here. # Keep in mind that this names must consist of alphanumeric # characters only! # # Every line starting with a hash sign (#) is a comment. # # # PIN | IN/OUT | When active? | Name #-----+--------+--------------+---------------- PD0 OUTPUT HIGH p0 PD1 OUTPUT HIGH p1 PD2 OUTPUT HIGH p2 PD3 OUTPUT HIGH p3 PD4 OUTPUT HIGH p4 PD5 OUTPUT HIGH p5 PD6 OUTPUT HIGH p6 PD7 OUTPUT HIGH p7 PB0 OUTPUT HIGH p8 PB1 OUTPUT HIGH p9 PB2 OUTPUT HIGH p10 PB3 OUTPUT HIGH p11 PB4 OUTPUT HIGH p12 PB5 OUTPUT HIGH p13 PC0 INPUT HIGH a1 PC1 INPUT HIGH a2 PC2 INPUT HIGH a3 PC3 INPUT HIGH a4 PC4 INPUT HIGH a5 PC5 INPUT HIGH a6 == Control6 Scripte == Einen Einstieg in [[Control6]] gibt es auch auf der Seite für [[PIN_Commands]] === Beispiel für ein [[Control6]] mit Named Pin=== * Script unter control6/control6.src * control6 muss aktiviert sein! * [[Named_Pin]] muss aktiviert sein! THREAD(arduino_blink) PIN_CLEAR(p13); WAIT(1); PIN_SET(p13); WAIT(1); THREAD_END(arduino_blink) THREAD_START(arduino_blink) === Beispiel ohne Named Pin === * Script unter control6/control6.src THREAD(arduino_blink) PORTB &= ~_BV(PB5); WAIT(1); PORTB |= _BV(PB5); WAIT(1); THREAD_END(arduino_blink) THREAD_START(arduino_blink) [[Category:Hardware]] [[Category:Arduino]] e057b845ec52c9b040eeae3c833ce7c8b451da68 1294 1293 2014-08-12T12:17:19Z Coffee 722 füge i18n Leiste hinzu wikitext text/x-wiki {{i18n|Arduino_Duemilanove}} Der Support für den [http://arduino.cc/en/Main/ArduinoBoardDuemilanove Arduino Duemilanove] ist noch experimentell! == Named Pin Konfiguration == Hier die passende core/portio/config für [[Named_PIN]] * Named Pin muss aktiviert sein! # # Named Pin Configuration File # # You can assign names to your microcontroller's pins here. # Keep in mind that this names must consist of alphanumeric # characters only! # # Every line starting with a hash sign (#) is a comment. # # # PIN | IN/OUT | When active? | Name #-----+--------+--------------+---------------- PD0 OUTPUT HIGH p0 PD1 OUTPUT HIGH p1 PD2 OUTPUT HIGH p2 PD3 OUTPUT HIGH p3 PD4 OUTPUT HIGH p4 PD5 OUTPUT HIGH p5 PD6 OUTPUT HIGH p6 PD7 OUTPUT HIGH p7 PB0 OUTPUT HIGH p8 PB1 OUTPUT HIGH p9 PB2 OUTPUT HIGH p10 PB3 OUTPUT HIGH p11 PB4 OUTPUT HIGH p12 PB5 OUTPUT HIGH p13 PC0 INPUT HIGH a1 PC1 INPUT HIGH a2 PC2 INPUT HIGH a3 PC3 INPUT HIGH a4 PC4 INPUT HIGH a5 PC5 INPUT HIGH a6 == Control6 Scripte == Einen Einstieg in [[Control6]] gibt es auch auf der Seite für [[PIN_Commands]] === Beispiel für ein [[Control6]] mit Named Pin=== * Script unter control6/control6.src * control6 muss aktiviert sein! * [[Named_Pin]] muss aktiviert sein! THREAD(arduino_blink) PIN_CLEAR(p13); WAIT(1); PIN_SET(p13); WAIT(1); THREAD_END(arduino_blink) THREAD_START(arduino_blink) === Beispiel ohne Named Pin === * Script unter control6/control6.src THREAD(arduino_blink) PORTB &= ~_BV(PB5); WAIT(1); PORTB |= _BV(PB5); WAIT(1); THREAD_END(arduino_blink) THREAD_START(arduino_blink) [[Category:Hardware]] [[Category:Arduino]] 191c97ca4979e72760afd1a67ecc8e79265b8b17 1295 1294 2014-08-12T12:18:09Z Coffee 722 Remove german text from english page. wikitext text/x-wiki {{i18n|Arduino_Duemilanove}} 8dffac25af25ef19e0db5b20782da3d2a12191ae 1298 1295 2014-08-12T12:24:54Z Coffee 722 draft English translation of this page wikitext text/x-wiki {{i18n|Arduino_Duemilanove}} {{i18n|Arduino_Duemilanove}} Support for [http://arduino.cc/en/Main/ArduinoBoardDuemilanove Arduino Duemilanove] is still experimental! == Named Pin Configuration == Here the appropriate core/portio/config for [[Named_PIN]] * Named Pin must be enabled! # # Named Pin Configuration File # # You can assign names to your microcontroller's pins here. # Keep in mind that this names must consist of alphanumeric # characters only! # # Every line starting with a hash sign (#) is a comment. # # # PIN | IN/OUT | When active? | Name #-----+--------+--------------+---------------- PD0 OUTPUT HIGH p0 PD1 OUTPUT HIGH p1 PD2 OUTPUT HIGH p2 PD3 OUTPUT HIGH p3 PD4 OUTPUT HIGH p4 PD5 OUTPUT HIGH p5 PD6 OUTPUT HIGH p6 PD7 OUTPUT HIGH p7 PB0 OUTPUT HIGH p8 PB1 OUTPUT HIGH p9 PB2 OUTPUT HIGH p10 PB3 OUTPUT HIGH p11 PB4 OUTPUT HIGH p12 PB5 OUTPUT HIGH p13 PC0 INPUT HIGH a1 PC1 INPUT HIGH a2 PC2 INPUT HIGH a3 PC3 INPUT HIGH a4 PC4 INPUT HIGH a5 PC5 INPUT HIGH a6 == Control6 Scripts == An Introduction into [[Control6]] is also available on the page for [[PIN_Commands]] === Example for a [[Control6]] with Named Pin=== * Script at control6/control6.src * control6 must be enabled! * [[Named_Pin]] must be enabled! THREAD(arduino_blink) PIN_CLEAR(p13); WAIT(1); PIN_SET(p13); WAIT(1); THREAD_END(arduino_blink) THREAD_START(arduino_blink) === Example with Named Pin === * Script at control6/control6.src THREAD(arduino_blink) PORTB &= ~_BV(PB5); WAIT(1); PORTB |= _BV(PB5); WAIT(1); THREAD_END(arduino_blink) THREAD_START(arduino_blink) [[Category:Hardware]] [[Category:Arduino]] 77d344ebde77f5667127e7da4abbe5d41d15d785 1299 1298 2014-08-12T12:25:21Z Coffee 722 correct previous edit wikitext text/x-wiki {{i18n|Arduino_Duemilanove}} Support for [http://arduino.cc/en/Main/ArduinoBoardDuemilanove Arduino Duemilanove] is still experimental! == Named Pin Configuration == Here the appropriate core/portio/config for [[Named_PIN]] * Named Pin must be enabled! # # Named Pin Configuration File # # You can assign names to your microcontroller's pins here. # Keep in mind that this names must consist of alphanumeric # characters only! # # Every line starting with a hash sign (#) is a comment. # # # PIN | IN/OUT | When active? | Name #-----+--------+--------------+---------------- PD0 OUTPUT HIGH p0 PD1 OUTPUT HIGH p1 PD2 OUTPUT HIGH p2 PD3 OUTPUT HIGH p3 PD4 OUTPUT HIGH p4 PD5 OUTPUT HIGH p5 PD6 OUTPUT HIGH p6 PD7 OUTPUT HIGH p7 PB0 OUTPUT HIGH p8 PB1 OUTPUT HIGH p9 PB2 OUTPUT HIGH p10 PB3 OUTPUT HIGH p11 PB4 OUTPUT HIGH p12 PB5 OUTPUT HIGH p13 PC0 INPUT HIGH a1 PC1 INPUT HIGH a2 PC2 INPUT HIGH a3 PC3 INPUT HIGH a4 PC4 INPUT HIGH a5 PC5 INPUT HIGH a6 == Control6 Scripts == An Introduction into [[Control6]] is also available on the page for [[PIN_Commands]] === Example for a [[Control6]] with Named Pin=== * Script at control6/control6.src * control6 must be enabled! * [[Named_Pin]] must be enabled! THREAD(arduino_blink) PIN_CLEAR(p13); WAIT(1); PIN_SET(p13); WAIT(1); THREAD_END(arduino_blink) THREAD_START(arduino_blink) === Example with Named Pin === * Script at control6/control6.src THREAD(arduino_blink) PORTB &= ~_BV(PB5); WAIT(1); PORTB |= _BV(PB5); WAIT(1); THREAD_END(arduino_blink) THREAD_START(arduino_blink) [[Category:Hardware]] [[Category:Arduino]] 88e04c94606740065f705c78c45f4f36826ae629 0 396 1296 2014-08-12T12:18:22Z Coffee 722 Created page with "Der Support für den [http://arduino.cc/en/Main/ArduinoBoardDuemilanove Arduino Duemilanove] ist noch experimentell! == Named Pin Konfiguration == Hier die passende core/por..." wikitext text/x-wiki Der Support für den [http://arduino.cc/en/Main/ArduinoBoardDuemilanove Arduino Duemilanove] ist noch experimentell! == Named Pin Konfiguration == Hier die passende core/portio/config für [[Named_PIN]] * Named Pin muss aktiviert sein! # # Named Pin Configuration File # # You can assign names to your microcontroller's pins here. # Keep in mind that this names must consist of alphanumeric # characters only! # # Every line starting with a hash sign (#) is a comment. # # # PIN | IN/OUT | When active? | Name #-----+--------+--------------+---------------- PD0 OUTPUT HIGH p0 PD1 OUTPUT HIGH p1 PD2 OUTPUT HIGH p2 PD3 OUTPUT HIGH p3 PD4 OUTPUT HIGH p4 PD5 OUTPUT HIGH p5 PD6 OUTPUT HIGH p6 PD7 OUTPUT HIGH p7 PB0 OUTPUT HIGH p8 PB1 OUTPUT HIGH p9 PB2 OUTPUT HIGH p10 PB3 OUTPUT HIGH p11 PB4 OUTPUT HIGH p12 PB5 OUTPUT HIGH p13 PC0 INPUT HIGH a1 PC1 INPUT HIGH a2 PC2 INPUT HIGH a3 PC3 INPUT HIGH a4 PC4 INPUT HIGH a5 PC5 INPUT HIGH a6 == Control6 Scripte == Einen Einstieg in [[Control6]] gibt es auch auf der Seite für [[PIN_Commands]] === Beispiel für ein [[Control6]] mit Named Pin=== * Script unter control6/control6.src * control6 muss aktiviert sein! * [[Named_Pin]] muss aktiviert sein! THREAD(arduino_blink) PIN_CLEAR(p13); WAIT(1); PIN_SET(p13); WAIT(1); THREAD_END(arduino_blink) THREAD_START(arduino_blink) === Beispiel ohne Named Pin === * Script unter control6/control6.src THREAD(arduino_blink) PORTB &= ~_BV(PB5); WAIT(1); PORTB |= _BV(PB5); WAIT(1); THREAD_END(arduino_blink) THREAD_START(arduino_blink) [[Category:Hardware]] [[Category:Arduino]] e057b845ec52c9b040eeae3c833ce7c8b451da68 1297 1296 2014-08-12T12:19:05Z Coffee 722 i18n Leiste wikitext text/x-wiki {{i18n|Arduino_Duemilanove}} Der Support für den [http://arduino.cc/en/Main/ArduinoBoardDuemilanove Arduino Duemilanove] ist noch experimentell! == Named Pin Konfiguration == Hier die passende core/portio/config für [[Named_PIN]] * Named Pin muss aktiviert sein! # # Named Pin Configuration File # # You can assign names to your microcontroller's pins here. # Keep in mind that this names must consist of alphanumeric # characters only! # # Every line starting with a hash sign (#) is a comment. # # # PIN | IN/OUT | When active? | Name #-----+--------+--------------+---------------- PD0 OUTPUT HIGH p0 PD1 OUTPUT HIGH p1 PD2 OUTPUT HIGH p2 PD3 OUTPUT HIGH p3 PD4 OUTPUT HIGH p4 PD5 OUTPUT HIGH p5 PD6 OUTPUT HIGH p6 PD7 OUTPUT HIGH p7 PB0 OUTPUT HIGH p8 PB1 OUTPUT HIGH p9 PB2 OUTPUT HIGH p10 PB3 OUTPUT HIGH p11 PB4 OUTPUT HIGH p12 PB5 OUTPUT HIGH p13 PC0 INPUT HIGH a1 PC1 INPUT HIGH a2 PC2 INPUT HIGH a3 PC3 INPUT HIGH a4 PC4 INPUT HIGH a5 PC5 INPUT HIGH a6 == Control6 Scripte == Einen Einstieg in [[Control6]] gibt es auch auf der Seite für [[PIN_Commands]] === Beispiel für ein [[Control6]] mit Named Pin=== * Script unter control6/control6.src * control6 muss aktiviert sein! * [[Named_Pin]] muss aktiviert sein! THREAD(arduino_blink) PIN_CLEAR(p13); WAIT(1); PIN_SET(p13); WAIT(1); THREAD_END(arduino_blink) THREAD_START(arduino_blink) === Beispiel ohne Named Pin === * Script unter control6/control6.src THREAD(arduino_blink) PORTB &= ~_BV(PB5); WAIT(1); PORTB |= _BV(PB5); WAIT(1); THREAD_END(arduino_blink) THREAD_START(arduino_blink) [[Category:Hardware]] [[Category:Arduino]] 17c857287a706ef337008f9dc531e2a7e141620e 0 276 1300 687 2014-08-12T13:02:26Z Coffee 722 translate page into English wikitext text/x-wiki {{i18n|HTTPD}} {{Module |NAME=HTTPD |MENUCONFIG={{Applications}}->HTTP Server->HTTPD |STATUS={{stable}} |PINNING=? |ECMD=? |CONTROL6=? |DEPENDS=? |REQUIRES=? |CODE=? }} == Web server on the ethersex == The built-in web servir in ethersex can read the files it should serve from various locations: * from an external dataflash * files stored in the flash memory of the MCU right after the firmware * run ECMD commands and serve the results (for AJAX) Any of these sources for data can be enabled independent of the others. The easiest option is to initially keep the files in the internal flash memory and to access dynamic content via the HTTP ECMD interface. === Configuration === <pre> General Setup ---&gt; [*] VFS (Virtual File System) support ---&gt; | | [ ] Atmel SPI Dataflash | | | [*] VFS File Inlining | | | [ ] SD/MMC-Card Access | | | [ ] EEPROM (24cxx) Raw Access | | | [-] DC3840 Camera | ... Applications ---&gt; | | [*] HTTP Server | | | [ ] Basic Authentication | ... Applications ---&gt; Etherrape Control Interface (ECMD) ---&gt; | | [*] ECMD support | </pre> === Embedding files === If the option ''Supply Inline Files'' is enabled, all files stored in ''vfs/embed/'' will be automatically packed with gzip and appended to the end of the firmware when building the image. Filenames remain unchanged, however the maximum length of filenames is 6 characters. === Preprocess files with the C preprocessor or m4 === To include files dependent on configuration options (or not) respectively including only parts, if a certain option is enabled, they can be preprocessed by cpp or m4, before the output is packed and appended to the firmware. For that, the file must end in .cpp or .m4. When using cpp, all defines from config.h/autoconf.h are accessible (e.g. ~np~ONEWIRE_SUPPORT~/np~). When using m4, ~np~ONEWIRE_SUPPORT turns into conf_ONEWIRE ~/np~. === Content type of the files === Because the web server can not dynamically determine the content type, this information needs to be supplied in advance. The content type is determined by the first character of the file name: * S (e.g. Sty.c): text/css * X (e.g. Xow.ht): application/xhtml+xml; * everything else is served as text/html === Access files from the SD card === To serve files from an SD card, they are copied to the SD card. These can then be accessed by the browser via the following URL (IP and file name must of course be changed) <pre>http://192.168.23.244/Filename</pre> If the file is located in a folder on the SD card, it can be accessed via the following URL. <pre>http://192.168.23.244/Foldername/Filename</pre> The length of filenames is not limited to 6 characters with the SD card. === Manually triggering ECMD commands (via HTTP) === To query the IP via ECMD, the following URL (the IP must of course be changed) can be accessed with the browser, returning the output via HTTP. <pre>http://192.168.23.244/ecmd?ip</pre> In order to use commands containing spaces, e.g. "1w list", the spaces must be replaced with "+" or "%20". The following command lists 1-wire sensors, if any are present: <pre>http://192.168.23.244/ecmd?1w+list</pre> or <pre>http://192.168.23.244/ecmd?1w%20list</pre> === Ethersex start page === If the web server is compiled in, when accessing <nowiki>http://YOUR_ETHERSEX_IP/</nowiki> the browser should show such a page: [[Bild:Ethersex-screen-startseite.png|600px]] === Dataflash === '''TODO''' [[Category:Ethersex]] [[Category:StepByStep]] [[Category:Network]] 3a0df9a5cd585fadc2fe7550bf59d2a5f92db79b 1301 1300 2014-08-12T13:30:10Z GooPie4o 265 wikitext text/x-wiki {{i18n|HTTPD}} {{Module |NAME=HTTPD |MENUCONFIG={{Applications}}->HTTP Server->HTTPD |STATUS={{stable}} |PINNING=- |ECMD=- |CONTROL6=- |DEPENDS=? |REQUIRES=? |CODE=? }} == Web server on the ethersex == The built-in web server in [[Ethersex]] can read the files it should serve from various locations: * from an external dataflash * files stored in the flash memory of the MCU right after the firmware * run ECMD commands and serve the results (for AJAX) Any of these sources for data can be enabled independent of the others. The easiest option is to initially keep the files in the internal flash memory and to access dynamic content via the HTTP ECMD interface. === Configuration === <pre> General Setup ---&gt; [*] VFS (Virtual File System) support ---&gt; | | [ ] Atmel SPI Dataflash | | | [*] VFS File Inlining | | | [ ] SD/MMC-Card Access | | | [ ] EEPROM (24cxx) Raw Access | | | [-] DC3840 Camera | ... Applications ---&gt; | | [*] HTTP Server | | | [ ] Basic Authentication | ... Applications ---&gt; Etherrape Control Interface (ECMD) ---&gt; | | [*] ECMD support | </pre> === Embedding files === If the option ''Supply Inline Files'' is enabled, all files stored in ''vfs/embed/'' will be automatically packed with gzip and appended to the end of the firmware when building the image. Filenames remain unchanged, however the maximum length of filenames is 6 characters. === Preprocess files with the C preprocessor or m4 === To include files dependent on configuration options (or not) respectively including only parts, if a certain option is enabled, they can be preprocessed by cpp or m4, before the output is packed and appended to the firmware. For that, the file must end in .cpp or .m4. When using cpp, all defines from config.h/autoconf.h are accessible (e.g. ~np~ONEWIRE_SUPPORT~/np~). When using m4, ~np~ONEWIRE_SUPPORT turns into conf_ONEWIRE ~/np~. === Content type of the files === Because the web server can not dynamically determine the content type, this information needs to be supplied in advance. The content type is determined by the first character of the file name: * S (e.g. Sty.c): text/css * X (e.g. Xow.ht): application/xhtml+xml; * everything else is served as text/html === Access files from the SD card === To serve files from an SD card, they are copied to the SD card. These can then be accessed by the browser via the following URL (IP and file name must of course be changed) <pre>http://192.168.23.244/Filename</pre> If the file is located in a folder on the SD card, it can be accessed via the following URL. <pre>http://192.168.23.244/Foldername/Filename</pre> The length of filenames is not limited to 6 characters with the SD card. === Manually triggering ECMD commands (via HTTP) === To query the IP via ECMD, the following URL (the IP must of course be changed) can be accessed with the browser, returning the output via HTTP. <pre>http://192.168.23.244/ecmd?ip</pre> In order to use commands containing spaces, e.g. "1w list", the spaces must be replaced with "+" or "%20". The following command lists 1-wire sensors, if any are present: <pre>http://192.168.23.244/ecmd?1w+list</pre> or <pre>http://192.168.23.244/ecmd?1w%20list</pre> === Ethersex start page === If the web server is compiled in, when accessing <nowiki>http://YOUR_ETHERSEX_IP/</nowiki> the browser should show such a page: [[Bild:Ethersex-screen-startseite.png|600px]] === Dataflash === '''TODO''' [[Category:Ethersex]] [[Category:StepByStep]] [[Category:Network]] c9496c2ad1e145033ee57d39903ca499fd6fb618 0 36 1302 338 2014-08-12T15:56:50Z GooPie4o 265 /* Writing Code */ wikitext text/x-wiki {{i18n|Contributing}} = How to Contribute = We are a truly open source [[community]] and therefore appreciate any effort to make ethersex even more awesome. You can help in various ways like writing code, supporting other users (e.g. on [[Community|IRC]]) or expanding this wiki with your knowledge. == Writing Code == All your code needs to be [http://www.gnu.org/copyleft/gpl.html ''GPLv3 or later''] if you plan to publish your code. == Coding Style == To keep the source code readable some formatting rules should be adhered to. There is further evidence found in [[own_module|''adding your own module'']]. The supplied script ''scripts/indent.sh'' may be used to format the source code before committing it to the repository. Please keep in mind that pull requests might be rejected if source violates formatting rules. * GPLv3 license header if none exists * Maximum line length is 78 chars. * No text editor specific formatting rules. * Use spaces instead of tabs, two spaces per indent level. * Braces on single line, no additional indent. * No spaces between the name of the procedure being called and the `('. * Put the `*' character at the left of comments. * Break long lines after operators. * Macros are defined just below the includes Function prototypes are defined as. <source lang="c"> void func(void); </source> and implemented as <source lang="c"> void func(void) { /* content */ } </source> == Patches == For version control we use [http://git-scm.com/ Git]. Our repository is hosted [https://github.com/ethersex/ethersex on github]. If you haven't work with git so far, you should familiarize yourself with it by reading [http://help.github.com/ the beginners guide on github]. === Fork us! === [http://help.github.com/fork-a-repo/ The help page on github] pretty much explains how that works. To make your life easier you should create a branch for '''each''' new feature you will be implementing. '''NEVER''' touch the ''master'' branch - or you probably will not be able to merge upstream changes into your fork without conflicts. === Pull requests === Pull requests are the easiest way to get your code integrated into the ethersex code base. Developers don't need to send patches around on mailing lists and can respond faster to questions/concerns maintainers may have about the code. Please read [http://help.github.com/send-pull-requests/ this page] in case you don't know how to use pull requests on github. 6ae32d45f9bc044dff2965fa21717fa75ef5e60d 0 390 1304 1303 2014-08-13T15:45:35Z Kpwg 721 /* DHT22 Temperatur-/Feuchtesensoren */ wikitext text/x-wiki {{i18n|Nutzung in FHEM}} [http://www.fhemwiki.de/wiki/Hauptseite FHEM] ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um diverse per Funk und Kabel angebundene Komponenten aus dem Bereich der Hausautomation zu steuern. Er ist lizensiert unter der GPL v2. Das [http://www.pollin.de/shop/suchergebnis.html?S_TEXT=810+058 AVR-Net-IO] von [http://www.pollin.de Pollin] mit [[Ethersex]] dient als [http://www.fhemwiki.de/wiki/AVR-NET-IO preisgünstiger Einstieg in die Hausautomatisierung]. Verwendbar ist aber auch jede andere Hardware, die von Ethersex unterstützt wird ([http://arduino.cc/en/pmwiki.php?n=Main/ArduinoBoardProMini Arduino], eigene Entwicklungen, etc.). Über [[ECMD]] lassen sich dabei theoretisch alle in [[Ethersex]] vorhandenen Möglichkeiten nutzen, sofern in FHEM entsprechende [http://fhem.de/commandref.html#ECMD ECMD-Devices] definiert und eingebunden werden. == Grundlagen == Ausgehend von einem fertigen und per Telnet erreichbaren Ethersex muss in FHEM zuerst das entsprechende Device definiert werden. <pre> define NETIO_WZ ECMD telnet 192.168.3.81:2701 </pre> Eine serielle Anbindung kann mit ''define <name> ECMD serial <SerialDevice>[<@BaudRate>]'' alternativ erfolgen. Anschließend werden die erstellten .classdef-Konfigurationsdateien der einzelnen Funktionen dem System bekannt gemacht. In diesen .classdef-Dateien (Name und Endung sind frei wählbar!) wird die Schnittstelle zwischen FHEM und ECMD/Ethersex definiert. Dabei können mit perl übergebene Parameter und empfangene Daten bearbeitet sowie die in FHEM gebräuchlichen Readings erstellt werden. <pre> attr NETIO_WZ classdefs RFM12_2272=/opt/fhem/FHEM/rfm12_2272.classdef:RFM12_IT=/opt/fhem/FHEM/rfm12_it.classdef:LCD=/opt/fhem/FHEM/lcd.classdef:DHT22=/opt/fhem/FHEM/dht22.classdef:1WIRE=/opt/fhem/FHEM/1wire.classdef </pre> Die Definitionen für IC2272, Intertechno, HD44780-LCD, DHT22 und 1wire sind nun eingebunden. In den folgenden Abschnitten wird auf die einzelnen Devices näher eingegangen. Generell sind Pfade und IP-Adressen sowie übergebene Parameter noch entsprechend der eigenen Konfiguration anzupassen. == [[Onewire_(Deutsch) | 1-Wire Temperatursensoren]] == todo == [[DHT|DHT22 Temperatur-/Feuchtesensoren]] == [[File:DHT22.jpg|150px|thumb|right|DHT22-Sensoren]] Es werden seit 05/2014 mehrere der preiswerten, aber recht genauen DHT22 Temperatur-/Feuchtesensoren in einem Ethersex unterstützt. Die Sensoren benötigen 5V Betriebsspannung und kommunizieren über je einen Pin mit dem Prozessor. Der Preis pro Stück liegt derzeit bei etwa 3.50 Euro (ebay/China). Wer die Trägheit und Ungenauigkeit der S300TH oder TX29DTH kennt, wünscht sich vermutlich Besseres; vor allem bei Berechnung von [http://de.wikipedia.org/wiki/Taupunkt Taupunkt] und [http://de.wikipedia.org/wiki/Luftfeuchtigkeit#Absolute_Luftfeuchtigkeit absoluter Feuchte], welche von der Genauigkeit der gemessenen Eingangsgrößen sehr profitieren. Berechnungen von Hand kann man [http://www.wetterochs.de/wetter/feuchte.html hier] durchführen. Die automatische Berechnung der absoluten Feuchte in FHEM wird [http://forum.fhem.de/index.php/topic,21458.0.html im Forum] erklärt. Vor- und Nachteile der DHT22 sind bereits [[DHT#DHT11_vs_DHT22 | hier]] erklärt. '''Einbindung in FHEM''' dht22m.classdef erstellen: <pre> # Uebergabeparameter DHT22 ID 0...n params devID # Umsetzung in ECMD Befehle fuer DHT22 get DHT cmd {"dht temp %devID\n\000dht humid %devID\n"} get DHT expect "\d+.\d\n" get DHT postproc {\ s/(.*)\n(.*)\n/T: $1 H: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1;\ my $humidity = $2;\ my $state = $_;\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "humidity", $humidity, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </pre> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs DHT22M=/opt/fhem/FHEM/dht22m.classdef </pre> Die Sensoren werden definiert: <pre> define Test0 ECMDDevice DHT22M 0 attr Test0 IODev NETIO_TEST define Test1 ECMDDevice DHT22M 1 attr Test1 IODev NETIO_TEST define Test2 ECMDDevice DHT22M 2 attr Test2 IODev NETIO_TEST define Test3 ECMDDevice DHT22M 3 attr Test3 IODev NETIO_TEST </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_DHT at +*00:04 get Test0 DHT;; get Test1 DHT;; get Test2 DHT;; get Test3 DHT attr Messung_DHT verbose 0 </pre> Fünfzehn Messwerte pro Stunde genügen den allermeisten Anforderungen. == [[BMP085 | BMP085/BMP180 Luftdrucksensor]] == [[File:BMP180.jpg|150px|thumb|right|BMP180 (unten links)]] Ethersex unterstützt den BMP085 (bzw. den BMP180; der Code ist identisch) über das [[I2C_(Deutsch) | I2C]]-Interface. Da der Sensor für 3.3V Betriebsspannung ausgelegt ist, muss entweder der I2C-Pegel angepasst oder der ATMega auf 3.3V adaptiert werden. Weiterhin sollte die Höhe über Null bekannt sein. Beispiel: Eine Abfrage per [[ECMD]] mit ''bmp085 pressnn 59000'' bedeutet, das ich 590m (59000cm) über NN wohne. Die im Sensor verfügbare Temperatur wird parallel ausgelesen. '''Einbindung in FHEM''' bmp085.classdef erstellen <pre> get BMP cmd {"bmp085 temp\n\000bmp085 pressnn 59000\n"} get BMP expect ".*" get BMP postproc {\ s/(.*)\n(.*)\n/T: $1 P: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1/10;\ my $pressure = sprintf("%.1f",$2/100);\ my $state = "T: $temperature P: $pressure";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "pressure", $pressure, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </pre> Die Temperatur wird in °C mit einer Nachkommastelle gelesen, der Luftdruck in hPa bzw. mbar auf eine Nachkommastelle gerundet. Passende Readings werden erstellt. Das expect .* kann noch angepasst werden, um bei fehlerhaften Messwerten entsprechend zu reagieren. Die classdef wird in FHEM eingebunden (mehrere .classdef mit Doppelpunkt trennen: siehe [[Nutzung_in_FHEM_(Deutsch)#Grundlagen | Grundlagen]]): <pre> define NETIO_STK ECMD telnet 192.168.3.89:2701 attr NETIO_STK classdefs BMP=/opt/fhem/FHEM/bmp085.classdef </pre> Der Sensor wird definiert: <pre> define BMP180 ECMDDevice BMP attr BMP180 IODev NETIO_STK </pre> Das STATE ''kann'' mit Maßeinheiten versehen werden: <pre> attr BMP180 stateFormat { sprintf("%s°C %shPa", ReadingsVal("BMP180","temperature",0), ReadingsVal("BMP180","pressure",0)) ;; } </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_BMP at +*00:04 get BMP180 BMP attr Messung_BMP verbose 0 </pre> Dabei unterdrückt verbose 0 einen zusätzlichen (doppelten) Logeintrag des Messvorganges. == analoge Eingänge == todo == [[Porterweiterungen_%28Deutsch%29#D.2FA-Wandler_mit_LTC1257 | LTC1257 D/A-Wandler]] == todo == HD44780 Punktmatrixdisplays == todo == [[RFM12_ASK_(Deutsch) | Intertechno schalten mit RFM12]] == todo == [[RFM12_ASK_(Deutsch) | IC2272 schalten mit RFM12]] == todo [[Category:Application|Application]] 7fe5d91b17662a589fe1af8deca372e9126e96aa 1308 1304 2014-08-17T07:47:04Z Kpwg 721 wikitext text/x-wiki {{i18n|Nutzung in FHEM}} [http://www.fhemwiki.de/wiki/Hauptseite FHEM] ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um diverse per Funk und Kabel angebundene Komponenten aus dem Bereich der Hausautomation zu steuern. Er ist lizensiert unter der GPL v2. Das [http://www.pollin.de/shop/suchergebnis.html?S_TEXT=810+058 AVR-Net-IO] von [http://www.pollin.de Pollin] mit [[Ethersex]] dient als [http://www.fhemwiki.de/wiki/AVR-NET-IO preisgünstiger Einstieg in die Hausautomatisierung]. Verwendbar ist aber auch jede andere Hardware, die von Ethersex unterstützt wird ([http://arduino.cc/en/pmwiki.php?n=Main/ArduinoBoardProMini Arduino], eigene Entwicklungen, etc.). Über [[ECMD]] lassen sich dabei theoretisch alle in [[Ethersex]] vorhandenen [[ECMD_Protocols_%28Deutsch%29 | Möglichkeiten]] nutzen, sofern in FHEM entsprechende [http://fhem.de/commandref.html#ECMD ECMD-Devices] definiert und eingebunden werden. == Grundlagen == Ausgehend von einem fertigen und per Telnet erreichbaren Ethersex muss in FHEM zuerst das entsprechende Device definiert werden. <pre> define NETIO_WZ ECMD telnet 192.168.3.81:2701 </pre> Eine serielle Anbindung kann mit ''define <name> ECMD serial <SerialDevice>[<@BaudRate>]'' alternativ erfolgen. Anschließend werden die erstellten .classdef-Konfigurationsdateien der einzelnen Funktionen dem System bekannt gemacht. In diesen .classdef-Dateien (Name und Endung sind frei wählbar!) wird die Schnittstelle zwischen FHEM und ECMD/Ethersex definiert. Dabei können mit perl übergebene Parameter und empfangene Daten bearbeitet sowie die in FHEM gebräuchlichen Readings erstellt werden. <pre> attr NETIO_WZ classdefs RFM12_2272=/opt/fhem/FHEM/rfm12_2272.classdef:RFM12_IT=/opt/fhem/FHEM/rfm12_it.classdef:LCD=/opt/fhem/FHEM/lcd.classdef:DHT22=/opt/fhem/FHEM/dht22.classdef:1WIRE=/opt/fhem/FHEM/1wire.classdef </pre> Die Definitionen für IC2272, Intertechno, HD44780-LCD, DHT22 und 1wire sind nun eingebunden. In den folgenden Abschnitten wird auf die einzelnen Devices näher eingegangen. Generell sind Pfade und IP-Adressen sowie übergebene Parameter noch entsprechend der eigenen Konfiguration anzupassen. == [[Onewire_(Deutsch) | 1-Wire Temperatursensoren]] == todo == [[DHT|DHT22 Temperatur-/Feuchtesensoren]] == [[File:DHT22.jpg|150px|thumb|right|DHT22-Sensoren]] Es werden seit 05/2014 mehrere der preiswerten, aber recht genauen DHT22 Temperatur-/Feuchtesensoren in einem Ethersex unterstützt. Die Sensoren benötigen 5V Betriebsspannung und kommunizieren über je einen Pin mit dem Prozessor. Der Preis pro Stück liegt derzeit bei etwa 3.50 Euro (ebay/China). Wer die Trägheit und Ungenauigkeit der S300TH oder TX29DTH kennt, wünscht sich vermutlich Besseres; vor allem bei Berechnung von [http://de.wikipedia.org/wiki/Taupunkt Taupunkt] und [http://de.wikipedia.org/wiki/Luftfeuchtigkeit#Absolute_Luftfeuchtigkeit absoluter Feuchte], welche von der Genauigkeit der gemessenen Eingangsgrößen sehr profitieren. Berechnungen von Hand kann man [http://www.wetterochs.de/wetter/feuchte.html hier] durchführen. Die automatische Berechnung der absoluten Feuchte in FHEM wird [http://forum.fhem.de/index.php/topic,21458.0.html im Forum] erklärt. Vor- und Nachteile der DHT22 sind bereits [[DHT#DHT11_vs_DHT22 | hier]] erklärt. '''Einbindung in FHEM''' dht22m.classdef erstellen: <pre> # Uebergabeparameter DHT22 ID 0...n params devID # Umsetzung in ECMD Befehle fuer DHT22 get DHT cmd {"dht temp %devID\n\000dht humid %devID\n"} get DHT expect "\d+.\d\n" get DHT postproc {\ s/(.*)\n(.*)\n/T: $1 H: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1;\ my $humidity = $2;\ my $state = $_;\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "humidity", $humidity, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </pre> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs DHT22M=/opt/fhem/FHEM/dht22m.classdef </pre> Die Sensoren werden definiert: <pre> define Test0 ECMDDevice DHT22M 0 attr Test0 IODev NETIO_TEST define Test1 ECMDDevice DHT22M 1 attr Test1 IODev NETIO_TEST define Test2 ECMDDevice DHT22M 2 attr Test2 IODev NETIO_TEST define Test3 ECMDDevice DHT22M 3 attr Test3 IODev NETIO_TEST </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_DHT at +*00:04 get Test0 DHT;; get Test1 DHT;; get Test2 DHT;; get Test3 DHT attr Messung_DHT verbose 0 </pre> Fünfzehn Messwerte pro Stunde genügen den allermeisten Anforderungen. == [[BMP085 | BMP085/BMP180 Luftdrucksensor]] == [[File:BMP180.jpg|150px|thumb|right|BMP180 (unten links)]] Ethersex unterstützt den BMP085 (bzw. den BMP180; der Code ist identisch) über das [[I2C_(Deutsch) | I2C]]-Interface. Da der Sensor für 3.3V Betriebsspannung ausgelegt ist, muss entweder der I2C-Pegel angepasst oder der ATMega auf 3.3V adaptiert werden. Weiterhin sollte die Höhe über Null bekannt sein. Beispiel: Eine Abfrage per [[ECMD]] mit ''bmp085 pressnn 59000'' bedeutet, das ich 590m (59000cm) über NN wohne. Die im Sensor verfügbare Temperatur wird parallel ausgelesen. '''Einbindung in FHEM''' bmp085.classdef erstellen <pre> get BMP cmd {"bmp085 temp\n\000bmp085 pressnn 59000\n"} get BMP expect ".*" get BMP postproc {\ s/(.*)\n(.*)\n/T: $1 P: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1/10;\ my $pressure = sprintf("%.1f",$2/100);\ my $state = "T: $temperature P: $pressure";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "pressure", $pressure, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </pre> Die Temperatur wird in °C mit einer Nachkommastelle gelesen, der Luftdruck in hPa bzw. mbar auf eine Nachkommastelle gerundet. Passende Readings werden erstellt. Das expect .* kann noch angepasst werden, um bei fehlerhaften Messwerten entsprechend zu reagieren. Die classdef wird in FHEM eingebunden (mehrere .classdef mit Doppelpunkt trennen: siehe [[Nutzung_in_FHEM_(Deutsch)#Grundlagen | Grundlagen]]): <pre> define NETIO_STK ECMD telnet 192.168.3.89:2701 attr NETIO_STK classdefs BMP=/opt/fhem/FHEM/bmp085.classdef </pre> Der Sensor wird definiert: <pre> define BMP180 ECMDDevice BMP attr BMP180 IODev NETIO_STK </pre> Das STATE ''kann'' mit Maßeinheiten versehen werden: <pre> attr BMP180 stateFormat { sprintf("%s°C %shPa", ReadingsVal("BMP180","temperature",0), ReadingsVal("BMP180","pressure",0)) ;; } </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_BMP at +*00:04 get BMP180 BMP attr Messung_BMP verbose 0 </pre> Dabei unterdrückt verbose 0 einen zusätzlichen (doppelten) Logeintrag des Messvorganges. == analoge Eingänge == todo == [[Porterweiterungen_%28Deutsch%29#D.2FA-Wandler_mit_LTC1257 | LTC1257 D/A-Wandler]] == todo == HD44780 Punktmatrixdisplays == todo == [[RFM12_ASK_(Deutsch) | Intertechno schalten mit RFM12]] == todo == [[RFM12_ASK_(Deutsch) | IC2272 schalten mit RFM12]] == todo [[Category:Application|Application]] 0f907c650164e292c95fc388f6a5e9b30e44371a 1309 1308 2014-08-17T13:17:44Z GooPie4o 265 /* DHT22 Temperatur-/Feuchtesensoren */ wikitext text/x-wiki {{i18n|Nutzung in FHEM}} [http://www.fhemwiki.de/wiki/Hauptseite FHEM] ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um diverse per Funk und Kabel angebundene Komponenten aus dem Bereich der Hausautomation zu steuern. Er ist lizensiert unter der GPL v2. Das [http://www.pollin.de/shop/suchergebnis.html?S_TEXT=810+058 AVR-Net-IO] von [http://www.pollin.de Pollin] mit [[Ethersex]] dient als [http://www.fhemwiki.de/wiki/AVR-NET-IO preisgünstiger Einstieg in die Hausautomatisierung]. Verwendbar ist aber auch jede andere Hardware, die von Ethersex unterstützt wird ([http://arduino.cc/en/pmwiki.php?n=Main/ArduinoBoardProMini Arduino], eigene Entwicklungen, etc.). Über [[ECMD]] lassen sich dabei theoretisch alle in [[Ethersex]] vorhandenen [[ECMD_Protocols_%28Deutsch%29 | Möglichkeiten]] nutzen, sofern in FHEM entsprechende [http://fhem.de/commandref.html#ECMD ECMD-Devices] definiert und eingebunden werden. == Grundlagen == Ausgehend von einem fertigen und per Telnet erreichbaren Ethersex muss in FHEM zuerst das entsprechende Device definiert werden. <pre> define NETIO_WZ ECMD telnet 192.168.3.81:2701 </pre> Eine serielle Anbindung kann mit ''define <name> ECMD serial <SerialDevice>[<@BaudRate>]'' alternativ erfolgen. Anschließend werden die erstellten .classdef-Konfigurationsdateien der einzelnen Funktionen dem System bekannt gemacht. In diesen .classdef-Dateien (Name und Endung sind frei wählbar!) wird die Schnittstelle zwischen FHEM und ECMD/Ethersex definiert. Dabei können mit perl übergebene Parameter und empfangene Daten bearbeitet sowie die in FHEM gebräuchlichen Readings erstellt werden. <pre> attr NETIO_WZ classdefs RFM12_2272=/opt/fhem/FHEM/rfm12_2272.classdef:RFM12_IT=/opt/fhem/FHEM/rfm12_it.classdef:LCD=/opt/fhem/FHEM/lcd.classdef:DHT22=/opt/fhem/FHEM/dht22.classdef:1WIRE=/opt/fhem/FHEM/1wire.classdef </pre> Die Definitionen für IC2272, Intertechno, HD44780-LCD, DHT22 und 1wire sind nun eingebunden. In den folgenden Abschnitten wird auf die einzelnen Devices näher eingegangen. Generell sind Pfade und IP-Adressen sowie übergebene Parameter noch entsprechend der eigenen Konfiguration anzupassen. == [[Onewire_(Deutsch) | 1-Wire Temperatursensoren]] == todo == [[DHT|DHT22 Temperatur-/Feuchtesensoren]] == [[File:DHT22.jpg|150px|thumb|right|DHT22-Sensoren]] [[Ethersex]] unterstützt die preiswerten, aber recht genauen [[DHT|DHT22]] Temperatur-/Feuchtesensoren. Die Sensoren benötigen 5V Betriebsspannung und kommunizieren über je einen Pin mit dem Prozessor. Der Preis pro Stück liegt derzeit bei etwa 3.50 Euro (ebay/China). Wer die Trägheit und Ungenauigkeit der S300TH oder TX29DTH kennt, wünscht sich vermutlich Besseres; vor allem bei Berechnung von [http://de.wikipedia.org/wiki/Taupunkt Taupunkt] und [http://de.wikipedia.org/wiki/Luftfeuchtigkeit#Absolute_Luftfeuchtigkeit absoluter Feuchte], welche von der Genauigkeit der gemessenen Eingangsgrößen sehr profitieren. Berechnungen von Hand kann man [http://www.wetterochs.de/wetter/feuchte.html hier] durchführen. Die automatische Berechnung der absoluten Feuchte in FHEM wird [http://forum.fhem.de/index.php/topic,21458.0.html im Forum] erklärt. Vor- und Nachteile der DHT22 sind bereits [[DHT#DHT11_vs_DHT22 | hier]] erklärt. '''Einbindung in FHEM''' dht22m.classdef erstellen: <pre> # Uebergabeparameter DHT22 ID 0...n params devID # Umsetzung in ECMD Befehle fuer DHT22 get DHT cmd {"dht temp %devID\n\000dht humid %devID\n"} get DHT expect "\d+.\d\n" get DHT postproc {\ s/(.*)\n(.*)\n/T: $1 H: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1;\ my $humidity = $2;\ my $state = $_;\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "humidity", $humidity, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </pre> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs DHT22M=/opt/fhem/FHEM/dht22m.classdef </pre> Die Sensoren werden definiert: <pre> define Test0 ECMDDevice DHT22M 0 attr Test0 IODev NETIO_TEST define Test1 ECMDDevice DHT22M 1 attr Test1 IODev NETIO_TEST define Test2 ECMDDevice DHT22M 2 attr Test2 IODev NETIO_TEST define Test3 ECMDDevice DHT22M 3 attr Test3 IODev NETIO_TEST </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_DHT at +*00:04 get Test0 DHT;; get Test1 DHT;; get Test2 DHT;; get Test3 DHT attr Messung_DHT verbose 0 </pre> Fünfzehn Messwerte pro Stunde genügen den allermeisten Anforderungen. == [[BMP085 | BMP085/BMP180 Luftdrucksensor]] == [[File:BMP180.jpg|150px|thumb|right|BMP180 (unten links)]] Ethersex unterstützt den BMP085 (bzw. den BMP180; der Code ist identisch) über das [[I2C_(Deutsch) | I2C]]-Interface. Da der Sensor für 3.3V Betriebsspannung ausgelegt ist, muss entweder der I2C-Pegel angepasst oder der ATMega auf 3.3V adaptiert werden. Weiterhin sollte die Höhe über Null bekannt sein. Beispiel: Eine Abfrage per [[ECMD]] mit ''bmp085 pressnn 59000'' bedeutet, das ich 590m (59000cm) über NN wohne. Die im Sensor verfügbare Temperatur wird parallel ausgelesen. '''Einbindung in FHEM''' bmp085.classdef erstellen <pre> get BMP cmd {"bmp085 temp\n\000bmp085 pressnn 59000\n"} get BMP expect ".*" get BMP postproc {\ s/(.*)\n(.*)\n/T: $1 P: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1/10;\ my $pressure = sprintf("%.1f",$2/100);\ my $state = "T: $temperature P: $pressure";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "pressure", $pressure, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </pre> Die Temperatur wird in °C mit einer Nachkommastelle gelesen, der Luftdruck in hPa bzw. mbar auf eine Nachkommastelle gerundet. Passende Readings werden erstellt. Das expect .* kann noch angepasst werden, um bei fehlerhaften Messwerten entsprechend zu reagieren. Die classdef wird in FHEM eingebunden (mehrere .classdef mit Doppelpunkt trennen: siehe [[Nutzung_in_FHEM_(Deutsch)#Grundlagen | Grundlagen]]): <pre> define NETIO_STK ECMD telnet 192.168.3.89:2701 attr NETIO_STK classdefs BMP=/opt/fhem/FHEM/bmp085.classdef </pre> Der Sensor wird definiert: <pre> define BMP180 ECMDDevice BMP attr BMP180 IODev NETIO_STK </pre> Das STATE ''kann'' mit Maßeinheiten versehen werden: <pre> attr BMP180 stateFormat { sprintf("%s°C %shPa", ReadingsVal("BMP180","temperature",0), ReadingsVal("BMP180","pressure",0)) ;; } </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_BMP at +*00:04 get BMP180 BMP attr Messung_BMP verbose 0 </pre> Dabei unterdrückt verbose 0 einen zusätzlichen (doppelten) Logeintrag des Messvorganges. == analoge Eingänge == todo == [[Porterweiterungen_%28Deutsch%29#D.2FA-Wandler_mit_LTC1257 | LTC1257 D/A-Wandler]] == todo == HD44780 Punktmatrixdisplays == todo == [[RFM12_ASK_(Deutsch) | Intertechno schalten mit RFM12]] == todo == [[RFM12_ASK_(Deutsch) | IC2272 schalten mit RFM12]] == todo [[Category:Application|Application]] 1697e65918ba6afc66f8fb607a0a4bcadc010aa2 1310 1309 2014-08-17T13:21:50Z GooPie4o 265 /* DHT22 Temperatur-/Feuchtesensoren */ wikitext text/x-wiki {{i18n|Nutzung in FHEM}} [http://www.fhemwiki.de/wiki/Hauptseite FHEM] ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um diverse per Funk und Kabel angebundene Komponenten aus dem Bereich der Hausautomation zu steuern. Er ist lizensiert unter der GPL v2. Das [http://www.pollin.de/shop/suchergebnis.html?S_TEXT=810+058 AVR-Net-IO] von [http://www.pollin.de Pollin] mit [[Ethersex]] dient als [http://www.fhemwiki.de/wiki/AVR-NET-IO preisgünstiger Einstieg in die Hausautomatisierung]. Verwendbar ist aber auch jede andere Hardware, die von Ethersex unterstützt wird ([http://arduino.cc/en/pmwiki.php?n=Main/ArduinoBoardProMini Arduino], eigene Entwicklungen, etc.). Über [[ECMD]] lassen sich dabei theoretisch alle in [[Ethersex]] vorhandenen [[ECMD_Protocols_%28Deutsch%29 | Möglichkeiten]] nutzen, sofern in FHEM entsprechende [http://fhem.de/commandref.html#ECMD ECMD-Devices] definiert und eingebunden werden. == Grundlagen == Ausgehend von einem fertigen und per Telnet erreichbaren Ethersex muss in FHEM zuerst das entsprechende Device definiert werden. <pre> define NETIO_WZ ECMD telnet 192.168.3.81:2701 </pre> Eine serielle Anbindung kann mit ''define <name> ECMD serial <SerialDevice>[<@BaudRate>]'' alternativ erfolgen. Anschließend werden die erstellten .classdef-Konfigurationsdateien der einzelnen Funktionen dem System bekannt gemacht. In diesen .classdef-Dateien (Name und Endung sind frei wählbar!) wird die Schnittstelle zwischen FHEM und ECMD/Ethersex definiert. Dabei können mit perl übergebene Parameter und empfangene Daten bearbeitet sowie die in FHEM gebräuchlichen Readings erstellt werden. <pre> attr NETIO_WZ classdefs RFM12_2272=/opt/fhem/FHEM/rfm12_2272.classdef:RFM12_IT=/opt/fhem/FHEM/rfm12_it.classdef:LCD=/opt/fhem/FHEM/lcd.classdef:DHT22=/opt/fhem/FHEM/dht22.classdef:1WIRE=/opt/fhem/FHEM/1wire.classdef </pre> Die Definitionen für IC2272, Intertechno, HD44780-LCD, DHT22 und 1wire sind nun eingebunden. In den folgenden Abschnitten wird auf die einzelnen Devices näher eingegangen. Generell sind Pfade und IP-Adressen sowie übergebene Parameter noch entsprechend der eigenen Konfiguration anzupassen. == [[Onewire_(Deutsch) | 1-Wire Temperatursensoren]] == todo == [[DHT|DHT22 Temperatur-/Feuchtesensoren]] == [[File:DHT22.jpg|150px|thumb|right|DHT22-Sensoren]] [[Ethersex]] unterstützt die preiswerten Temperatur-/Feuchtesensoren [[DHT|DHT11 und DHT22]], wobei letztere [[DHT#DHT11_vs_DHT22|um einiges genauer sind]]. Die Sensoren benötigen 5V Betriebsspannung und kommunizieren über je einen Pin mit dem Prozessor. Der Preis pro Stück liegt derzeit bei etwa 3.50 Euro (ebay/China). Wer die Trägheit und Ungenauigkeit der S300TH oder TX29DTH kennt, wünscht sich vermutlich Besseres; vor allem bei Berechnung von [http://de.wikipedia.org/wiki/Taupunkt Taupunkt] und [http://de.wikipedia.org/wiki/Luftfeuchtigkeit#Absolute_Luftfeuchtigkeit absoluter Feuchte], welche von der Genauigkeit der gemessenen Eingangsgrößen sehr profitieren. Berechnungen von Hand kann man [http://www.wetterochs.de/wetter/feuchte.html hier] durchführen. Die automatische Berechnung der absoluten Feuchte in FHEM wird [http://forum.fhem.de/index.php/topic,21458.0.html im Forum] erklärt. '''Einbindung in FHEM''' dht22m.classdef erstellen: <pre> # Uebergabeparameter DHT22 ID 0...n params devID # Umsetzung in ECMD Befehle fuer DHT22 get DHT cmd {"dht temp %devID\n\000dht humid %devID\n"} get DHT expect "\d+.\d\n" get DHT postproc {\ s/(.*)\n(.*)\n/T: $1 H: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1;\ my $humidity = $2;\ my $state = $_;\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "humidity", $humidity, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </pre> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs DHT22M=/opt/fhem/FHEM/dht22m.classdef </pre> Die Sensoren werden definiert: <pre> define Test0 ECMDDevice DHT22M 0 attr Test0 IODev NETIO_TEST define Test1 ECMDDevice DHT22M 1 attr Test1 IODev NETIO_TEST define Test2 ECMDDevice DHT22M 2 attr Test2 IODev NETIO_TEST define Test3 ECMDDevice DHT22M 3 attr Test3 IODev NETIO_TEST </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_DHT at +*00:04 get Test0 DHT;; get Test1 DHT;; get Test2 DHT;; get Test3 DHT attr Messung_DHT verbose 0 </pre> Fünfzehn Messwerte pro Stunde genügen den allermeisten Anforderungen. == [[BMP085 | BMP085/BMP180 Luftdrucksensor]] == [[File:BMP180.jpg|150px|thumb|right|BMP180 (unten links)]] Ethersex unterstützt den BMP085 (bzw. den BMP180; der Code ist identisch) über das [[I2C_(Deutsch) | I2C]]-Interface. Da der Sensor für 3.3V Betriebsspannung ausgelegt ist, muss entweder der I2C-Pegel angepasst oder der ATMega auf 3.3V adaptiert werden. Weiterhin sollte die Höhe über Null bekannt sein. Beispiel: Eine Abfrage per [[ECMD]] mit ''bmp085 pressnn 59000'' bedeutet, das ich 590m (59000cm) über NN wohne. Die im Sensor verfügbare Temperatur wird parallel ausgelesen. '''Einbindung in FHEM''' bmp085.classdef erstellen <pre> get BMP cmd {"bmp085 temp\n\000bmp085 pressnn 59000\n"} get BMP expect ".*" get BMP postproc {\ s/(.*)\n(.*)\n/T: $1 P: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1/10;\ my $pressure = sprintf("%.1f",$2/100);\ my $state = "T: $temperature P: $pressure";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "pressure", $pressure, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </pre> Die Temperatur wird in °C mit einer Nachkommastelle gelesen, der Luftdruck in hPa bzw. mbar auf eine Nachkommastelle gerundet. Passende Readings werden erstellt. Das expect .* kann noch angepasst werden, um bei fehlerhaften Messwerten entsprechend zu reagieren. Die classdef wird in FHEM eingebunden (mehrere .classdef mit Doppelpunkt trennen: siehe [[Nutzung_in_FHEM_(Deutsch)#Grundlagen | Grundlagen]]): <pre> define NETIO_STK ECMD telnet 192.168.3.89:2701 attr NETIO_STK classdefs BMP=/opt/fhem/FHEM/bmp085.classdef </pre> Der Sensor wird definiert: <pre> define BMP180 ECMDDevice BMP attr BMP180 IODev NETIO_STK </pre> Das STATE ''kann'' mit Maßeinheiten versehen werden: <pre> attr BMP180 stateFormat { sprintf("%s°C %shPa", ReadingsVal("BMP180","temperature",0), ReadingsVal("BMP180","pressure",0)) ;; } </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_BMP at +*00:04 get BMP180 BMP attr Messung_BMP verbose 0 </pre> Dabei unterdrückt verbose 0 einen zusätzlichen (doppelten) Logeintrag des Messvorganges. == analoge Eingänge == todo == [[Porterweiterungen_%28Deutsch%29#D.2FA-Wandler_mit_LTC1257 | LTC1257 D/A-Wandler]] == todo == HD44780 Punktmatrixdisplays == todo == [[RFM12_ASK_(Deutsch) | Intertechno schalten mit RFM12]] == todo == [[RFM12_ASK_(Deutsch) | IC2272 schalten mit RFM12]] == todo [[Category:Application|Application]] c83a3b7a1969df26e5cf4b765ce1c0cc97086b7f 1311 1310 2014-08-17T13:23:24Z GooPie4o 265 /* BMP085/BMP180 Luftdrucksensor */ wikitext text/x-wiki {{i18n|Nutzung in FHEM}} [http://www.fhemwiki.de/wiki/Hauptseite FHEM] ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um diverse per Funk und Kabel angebundene Komponenten aus dem Bereich der Hausautomation zu steuern. Er ist lizensiert unter der GPL v2. Das [http://www.pollin.de/shop/suchergebnis.html?S_TEXT=810+058 AVR-Net-IO] von [http://www.pollin.de Pollin] mit [[Ethersex]] dient als [http://www.fhemwiki.de/wiki/AVR-NET-IO preisgünstiger Einstieg in die Hausautomatisierung]. Verwendbar ist aber auch jede andere Hardware, die von Ethersex unterstützt wird ([http://arduino.cc/en/pmwiki.php?n=Main/ArduinoBoardProMini Arduino], eigene Entwicklungen, etc.). Über [[ECMD]] lassen sich dabei theoretisch alle in [[Ethersex]] vorhandenen [[ECMD_Protocols_%28Deutsch%29 | Möglichkeiten]] nutzen, sofern in FHEM entsprechende [http://fhem.de/commandref.html#ECMD ECMD-Devices] definiert und eingebunden werden. == Grundlagen == Ausgehend von einem fertigen und per Telnet erreichbaren Ethersex muss in FHEM zuerst das entsprechende Device definiert werden. <pre> define NETIO_WZ ECMD telnet 192.168.3.81:2701 </pre> Eine serielle Anbindung kann mit ''define <name> ECMD serial <SerialDevice>[<@BaudRate>]'' alternativ erfolgen. Anschließend werden die erstellten .classdef-Konfigurationsdateien der einzelnen Funktionen dem System bekannt gemacht. In diesen .classdef-Dateien (Name und Endung sind frei wählbar!) wird die Schnittstelle zwischen FHEM und ECMD/Ethersex definiert. Dabei können mit perl übergebene Parameter und empfangene Daten bearbeitet sowie die in FHEM gebräuchlichen Readings erstellt werden. <pre> attr NETIO_WZ classdefs RFM12_2272=/opt/fhem/FHEM/rfm12_2272.classdef:RFM12_IT=/opt/fhem/FHEM/rfm12_it.classdef:LCD=/opt/fhem/FHEM/lcd.classdef:DHT22=/opt/fhem/FHEM/dht22.classdef:1WIRE=/opt/fhem/FHEM/1wire.classdef </pre> Die Definitionen für IC2272, Intertechno, HD44780-LCD, DHT22 und 1wire sind nun eingebunden. In den folgenden Abschnitten wird auf die einzelnen Devices näher eingegangen. Generell sind Pfade und IP-Adressen sowie übergebene Parameter noch entsprechend der eigenen Konfiguration anzupassen. == [[Onewire_(Deutsch) | 1-Wire Temperatursensoren]] == todo == [[DHT|DHT22 Temperatur-/Feuchtesensoren]] == [[File:DHT22.jpg|150px|thumb|right|DHT22-Sensoren]] [[Ethersex]] unterstützt die preiswerten Temperatur-/Feuchtesensoren [[DHT|DHT11 und DHT22]], wobei letztere [[DHT#DHT11_vs_DHT22|um einiges genauer sind]]. Die Sensoren benötigen 5V Betriebsspannung und kommunizieren über je einen Pin mit dem Prozessor. Der Preis pro Stück liegt derzeit bei etwa 3.50 Euro (ebay/China). Wer die Trägheit und Ungenauigkeit der S300TH oder TX29DTH kennt, wünscht sich vermutlich Besseres; vor allem bei Berechnung von [http://de.wikipedia.org/wiki/Taupunkt Taupunkt] und [http://de.wikipedia.org/wiki/Luftfeuchtigkeit#Absolute_Luftfeuchtigkeit absoluter Feuchte], welche von der Genauigkeit der gemessenen Eingangsgrößen sehr profitieren. Berechnungen von Hand kann man [http://www.wetterochs.de/wetter/feuchte.html hier] durchführen. Die automatische Berechnung der absoluten Feuchte in FHEM wird [http://forum.fhem.de/index.php/topic,21458.0.html im Forum] erklärt. '''Einbindung in FHEM''' dht22m.classdef erstellen: <pre> # Uebergabeparameter DHT22 ID 0...n params devID # Umsetzung in ECMD Befehle fuer DHT22 get DHT cmd {"dht temp %devID\n\000dht humid %devID\n"} get DHT expect "\d+.\d\n" get DHT postproc {\ s/(.*)\n(.*)\n/T: $1 H: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1;\ my $humidity = $2;\ my $state = $_;\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "humidity", $humidity, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </pre> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs DHT22M=/opt/fhem/FHEM/dht22m.classdef </pre> Die Sensoren werden definiert: <pre> define Test0 ECMDDevice DHT22M 0 attr Test0 IODev NETIO_TEST define Test1 ECMDDevice DHT22M 1 attr Test1 IODev NETIO_TEST define Test2 ECMDDevice DHT22M 2 attr Test2 IODev NETIO_TEST define Test3 ECMDDevice DHT22M 3 attr Test3 IODev NETIO_TEST </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_DHT at +*00:04 get Test0 DHT;; get Test1 DHT;; get Test2 DHT;; get Test3 DHT attr Messung_DHT verbose 0 </pre> Fünfzehn Messwerte pro Stunde genügen den allermeisten Anforderungen. == [[BMP085 | BMP085/BMP180 Luftdrucksensor]] == [[File:BMP180.jpg|150px|thumb|right|BMP180 (unten links)]] Ethersex unterstützt den BMP085 (bzw. den BMP180; der Code ist identisch) über das [[I2C_(Deutsch) | I2C]]-Interface. Da der Sensor für 3.3V Betriebsspannung ausgelegt ist, muss entweder der I2C-Pegel angepasst oder der ATMega auf 3.3V adaptiert werden. Weiterhin sollte die Höhe über Null bekannt sein. Beispiel: Eine Abfrage per [[ECMD]] mit ''bmp085 pressnn 59000'' bedeutet, das ich 590m (59000cm) über NN wohne. Die im Sensor verfügbare Temperatur wird parallel ausgelesen. '''Einbindung in FHEM''' bmp085.classdef erstellen <source lang="perl"> get BMP cmd {"bmp085 temp\n\000bmp085 pressnn 59000\n"} get BMP expect ".*" get BMP postproc {\ s/(.*)\n(.*)\n/T: $1 P: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1/10;\ my $pressure = sprintf("%.1f",$2/100);\ my $state = "T: $temperature P: $pressure";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "pressure", $pressure, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die Temperatur wird in °C mit einer Nachkommastelle gelesen, der Luftdruck in hPa bzw. mbar auf eine Nachkommastelle gerundet. Passende Readings werden erstellt. Das expect .* kann noch angepasst werden, um bei fehlerhaften Messwerten entsprechend zu reagieren. Die classdef wird in FHEM eingebunden (mehrere .classdef mit Doppelpunkt trennen: siehe [[Nutzung_in_FHEM_(Deutsch)#Grundlagen | Grundlagen]]): <pre> define NETIO_STK ECMD telnet 192.168.3.89:2701 attr NETIO_STK classdefs BMP=/opt/fhem/FHEM/bmp085.classdef </pre> Der Sensor wird definiert: <pre> define BMP180 ECMDDevice BMP attr BMP180 IODev NETIO_STK </pre> Das STATE ''kann'' mit Maßeinheiten versehen werden: <pre> attr BMP180 stateFormat { sprintf("%s°C %shPa", ReadingsVal("BMP180","temperature",0), ReadingsVal("BMP180","pressure",0)) ;; } </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_BMP at +*00:04 get BMP180 BMP attr Messung_BMP verbose 0 </pre> Dabei unterdrückt verbose 0 einen zusätzlichen (doppelten) Logeintrag des Messvorganges. == analoge Eingänge == todo == [[Porterweiterungen_%28Deutsch%29#D.2FA-Wandler_mit_LTC1257 | LTC1257 D/A-Wandler]] == todo == HD44780 Punktmatrixdisplays == todo == [[RFM12_ASK_(Deutsch) | Intertechno schalten mit RFM12]] == todo == [[RFM12_ASK_(Deutsch) | IC2272 schalten mit RFM12]] == todo [[Category:Application|Application]] 113984f3c369c27326d75deca4f416688511538c 1312 1311 2014-08-17T14:30:16Z Kpwg 721 /* DHT22 Temperatur-/Feuchtesensoren */ wikitext text/x-wiki {{i18n|Nutzung in FHEM}} [http://www.fhemwiki.de/wiki/Hauptseite FHEM] ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um diverse per Funk und Kabel angebundene Komponenten aus dem Bereich der Hausautomation zu steuern. Er ist lizensiert unter der GPL v2. Das [http://www.pollin.de/shop/suchergebnis.html?S_TEXT=810+058 AVR-Net-IO] von [http://www.pollin.de Pollin] mit [[Ethersex]] dient als [http://www.fhemwiki.de/wiki/AVR-NET-IO preisgünstiger Einstieg in die Hausautomatisierung]. Verwendbar ist aber auch jede andere Hardware, die von Ethersex unterstützt wird ([http://arduino.cc/en/pmwiki.php?n=Main/ArduinoBoardProMini Arduino], eigene Entwicklungen, etc.). Über [[ECMD]] lassen sich dabei theoretisch alle in [[Ethersex]] vorhandenen [[ECMD_Protocols_%28Deutsch%29 | Möglichkeiten]] nutzen, sofern in FHEM entsprechende [http://fhem.de/commandref.html#ECMD ECMD-Devices] definiert und eingebunden werden. == Grundlagen == Ausgehend von einem fertigen und per Telnet erreichbaren Ethersex muss in FHEM zuerst das entsprechende Device definiert werden. <pre> define NETIO_WZ ECMD telnet 192.168.3.81:2701 </pre> Eine serielle Anbindung kann mit ''define <name> ECMD serial <SerialDevice>[<@BaudRate>]'' alternativ erfolgen. Anschließend werden die erstellten .classdef-Konfigurationsdateien der einzelnen Funktionen dem System bekannt gemacht. In diesen .classdef-Dateien (Name und Endung sind frei wählbar!) wird die Schnittstelle zwischen FHEM und ECMD/Ethersex definiert. Dabei können mit perl übergebene Parameter und empfangene Daten bearbeitet sowie die in FHEM gebräuchlichen Readings erstellt werden. <pre> attr NETIO_WZ classdefs RFM12_2272=/opt/fhem/FHEM/rfm12_2272.classdef:RFM12_IT=/opt/fhem/FHEM/rfm12_it.classdef:LCD=/opt/fhem/FHEM/lcd.classdef:DHT22=/opt/fhem/FHEM/dht22.classdef:1WIRE=/opt/fhem/FHEM/1wire.classdef </pre> Die Definitionen für IC2272, Intertechno, HD44780-LCD, DHT22 und 1wire sind nun eingebunden. In den folgenden Abschnitten wird auf die einzelnen Devices näher eingegangen. Generell sind Pfade und IP-Adressen sowie übergebene Parameter noch entsprechend der eigenen Konfiguration anzupassen. == [[Onewire_(Deutsch) | 1-Wire Temperatursensoren]] == todo == [[DHT|DHT22 Temperatur-/Feuchtesensoren]] == [[File:DHT22.jpg|150px|thumb|right|DHT22-Sensoren]] [[Ethersex]] unterstützt die preiswerten Temperatur-/Feuchtesensoren [[DHT|DHT11 und DHT22]], wobei letztere [[DHT#DHT11_vs_DHT22|um einiges genauer sind]]. Die Sensoren benötigen 5V Betriebsspannung und kommunizieren über je einen Pin mit dem Prozessor. Der Preis pro Stück liegt derzeit bei etwa 3.50 Euro (ebay/China). Wer die Trägheit und Ungenauigkeit der S300TH oder TX29DTH kennt, wünscht sich vermutlich Besseres; vor allem bei Berechnung von [http://de.wikipedia.org/wiki/Taupunkt Taupunkt] und [http://de.wikipedia.org/wiki/Luftfeuchtigkeit#Absolute_Luftfeuchtigkeit absoluter Feuchte], welche von der Genauigkeit der gemessenen Eingangsgrößen sehr profitieren. Berechnungen von Hand kann man beim [http://www.wetterochs.de/wetter/feuchte.html Wetterochs] durchführen. Die automatische Berechnung der absoluten Feuchte in FHEM wird im [http://forum.fhem.de/index.php/topic,21458.0.html Forum] erklärt. '''Einbindung in FHEM''' dht22m.classdef erstellen: <pre> # Uebergabeparameter DHT22 ID 0...n params devID # Umsetzung in ECMD Befehle fuer DHT22 get DHT cmd {"dht temp %devID\n\000dht humid %devID\n"} get DHT expect "\d+.\d\n" get DHT postproc {\ s/(.*)\n(.*)\n/T: $1 H: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1;\ my $humidity = $2;\ my $state = $_;\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "humidity", $humidity, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </pre> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs DHT22M=/opt/fhem/FHEM/dht22m.classdef </pre> Die Sensoren werden definiert: <pre> define Test0 ECMDDevice DHT22M 0 attr Test0 IODev NETIO_TEST define Test1 ECMDDevice DHT22M 1 attr Test1 IODev NETIO_TEST define Test2 ECMDDevice DHT22M 2 attr Test2 IODev NETIO_TEST define Test3 ECMDDevice DHT22M 3 attr Test3 IODev NETIO_TEST </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_DHT at +*00:04 get Test0 DHT;; get Test1 DHT;; get Test2 DHT;; get Test3 DHT attr Messung_DHT verbose 0 </pre> Fünfzehn Messwerte pro Stunde genügen den allermeisten Anforderungen. == [[BMP085 | BMP085/BMP180 Luftdrucksensor]] == [[File:BMP180.jpg|150px|thumb|right|BMP180 (unten links)]] Ethersex unterstützt den BMP085 (bzw. den BMP180; der Code ist identisch) über das [[I2C_(Deutsch) | I2C]]-Interface. Da der Sensor für 3.3V Betriebsspannung ausgelegt ist, muss entweder der I2C-Pegel angepasst oder der ATMega auf 3.3V adaptiert werden. Weiterhin sollte die Höhe über Null bekannt sein. Beispiel: Eine Abfrage per [[ECMD]] mit ''bmp085 pressnn 59000'' bedeutet, das ich 590m (59000cm) über NN wohne. Die im Sensor verfügbare Temperatur wird parallel ausgelesen. '''Einbindung in FHEM''' bmp085.classdef erstellen <source lang="perl"> get BMP cmd {"bmp085 temp\n\000bmp085 pressnn 59000\n"} get BMP expect ".*" get BMP postproc {\ s/(.*)\n(.*)\n/T: $1 P: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1/10;\ my $pressure = sprintf("%.1f",$2/100);\ my $state = "T: $temperature P: $pressure";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "pressure", $pressure, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die Temperatur wird in °C mit einer Nachkommastelle gelesen, der Luftdruck in hPa bzw. mbar auf eine Nachkommastelle gerundet. Passende Readings werden erstellt. Das expect .* kann noch angepasst werden, um bei fehlerhaften Messwerten entsprechend zu reagieren. Die classdef wird in FHEM eingebunden (mehrere .classdef mit Doppelpunkt trennen: siehe [[Nutzung_in_FHEM_(Deutsch)#Grundlagen | Grundlagen]]): <pre> define NETIO_STK ECMD telnet 192.168.3.89:2701 attr NETIO_STK classdefs BMP=/opt/fhem/FHEM/bmp085.classdef </pre> Der Sensor wird definiert: <pre> define BMP180 ECMDDevice BMP attr BMP180 IODev NETIO_STK </pre> Das STATE ''kann'' mit Maßeinheiten versehen werden: <pre> attr BMP180 stateFormat { sprintf("%s°C %shPa", ReadingsVal("BMP180","temperature",0), ReadingsVal("BMP180","pressure",0)) ;; } </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_BMP at +*00:04 get BMP180 BMP attr Messung_BMP verbose 0 </pre> Dabei unterdrückt verbose 0 einen zusätzlichen (doppelten) Logeintrag des Messvorganges. == analoge Eingänge == todo == [[Porterweiterungen_%28Deutsch%29#D.2FA-Wandler_mit_LTC1257 | LTC1257 D/A-Wandler]] == todo == HD44780 Punktmatrixdisplays == todo == [[RFM12_ASK_(Deutsch) | Intertechno schalten mit RFM12]] == todo == [[RFM12_ASK_(Deutsch) | IC2272 schalten mit RFM12]] == todo [[Category:Application|Application]] 4848fef25642c4e20cd423151017135b4e3b62b7 1313 1312 2014-08-17T14:33:32Z Kpwg 721 /* BMP085/BMP180 Luftdrucksensor */ wikitext text/x-wiki {{i18n|Nutzung in FHEM}} [http://www.fhemwiki.de/wiki/Hauptseite FHEM] ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um diverse per Funk und Kabel angebundene Komponenten aus dem Bereich der Hausautomation zu steuern. Er ist lizensiert unter der GPL v2. Das [http://www.pollin.de/shop/suchergebnis.html?S_TEXT=810+058 AVR-Net-IO] von [http://www.pollin.de Pollin] mit [[Ethersex]] dient als [http://www.fhemwiki.de/wiki/AVR-NET-IO preisgünstiger Einstieg in die Hausautomatisierung]. Verwendbar ist aber auch jede andere Hardware, die von Ethersex unterstützt wird ([http://arduino.cc/en/pmwiki.php?n=Main/ArduinoBoardProMini Arduino], eigene Entwicklungen, etc.). Über [[ECMD]] lassen sich dabei theoretisch alle in [[Ethersex]] vorhandenen [[ECMD_Protocols_%28Deutsch%29 | Möglichkeiten]] nutzen, sofern in FHEM entsprechende [http://fhem.de/commandref.html#ECMD ECMD-Devices] definiert und eingebunden werden. == Grundlagen == Ausgehend von einem fertigen und per Telnet erreichbaren Ethersex muss in FHEM zuerst das entsprechende Device definiert werden. <pre> define NETIO_WZ ECMD telnet 192.168.3.81:2701 </pre> Eine serielle Anbindung kann mit ''define <name> ECMD serial <SerialDevice>[<@BaudRate>]'' alternativ erfolgen. Anschließend werden die erstellten .classdef-Konfigurationsdateien der einzelnen Funktionen dem System bekannt gemacht. In diesen .classdef-Dateien (Name und Endung sind frei wählbar!) wird die Schnittstelle zwischen FHEM und ECMD/Ethersex definiert. Dabei können mit perl übergebene Parameter und empfangene Daten bearbeitet sowie die in FHEM gebräuchlichen Readings erstellt werden. <pre> attr NETIO_WZ classdefs RFM12_2272=/opt/fhem/FHEM/rfm12_2272.classdef:RFM12_IT=/opt/fhem/FHEM/rfm12_it.classdef:LCD=/opt/fhem/FHEM/lcd.classdef:DHT22=/opt/fhem/FHEM/dht22.classdef:1WIRE=/opt/fhem/FHEM/1wire.classdef </pre> Die Definitionen für IC2272, Intertechno, HD44780-LCD, DHT22 und 1wire sind nun eingebunden. In den folgenden Abschnitten wird auf die einzelnen Devices näher eingegangen. Generell sind Pfade und IP-Adressen sowie übergebene Parameter noch entsprechend der eigenen Konfiguration anzupassen. == [[Onewire_(Deutsch) | 1-Wire Temperatursensoren]] == todo == [[DHT|DHT22 Temperatur-/Feuchtesensoren]] == [[File:DHT22.jpg|150px|thumb|right|DHT22-Sensoren]] [[Ethersex]] unterstützt die preiswerten Temperatur-/Feuchtesensoren [[DHT|DHT11 und DHT22]], wobei letztere [[DHT#DHT11_vs_DHT22|um einiges genauer sind]]. Die Sensoren benötigen 5V Betriebsspannung und kommunizieren über je einen Pin mit dem Prozessor. Der Preis pro Stück liegt derzeit bei etwa 3.50 Euro (ebay/China). Wer die Trägheit und Ungenauigkeit der S300TH oder TX29DTH kennt, wünscht sich vermutlich Besseres; vor allem bei Berechnung von [http://de.wikipedia.org/wiki/Taupunkt Taupunkt] und [http://de.wikipedia.org/wiki/Luftfeuchtigkeit#Absolute_Luftfeuchtigkeit absoluter Feuchte], welche von der Genauigkeit der gemessenen Eingangsgrößen sehr profitieren. Berechnungen von Hand kann man beim [http://www.wetterochs.de/wetter/feuchte.html Wetterochs] durchführen. Die automatische Berechnung der absoluten Feuchte in FHEM wird im [http://forum.fhem.de/index.php/topic,21458.0.html Forum] erklärt. '''Einbindung in FHEM''' dht22m.classdef erstellen: <pre> # Uebergabeparameter DHT22 ID 0...n params devID # Umsetzung in ECMD Befehle fuer DHT22 get DHT cmd {"dht temp %devID\n\000dht humid %devID\n"} get DHT expect "\d+.\d\n" get DHT postproc {\ s/(.*)\n(.*)\n/T: $1 H: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1;\ my $humidity = $2;\ my $state = $_;\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "humidity", $humidity, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </pre> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs DHT22M=/opt/fhem/FHEM/dht22m.classdef </pre> Die Sensoren werden definiert: <pre> define Test0 ECMDDevice DHT22M 0 attr Test0 IODev NETIO_TEST define Test1 ECMDDevice DHT22M 1 attr Test1 IODev NETIO_TEST define Test2 ECMDDevice DHT22M 2 attr Test2 IODev NETIO_TEST define Test3 ECMDDevice DHT22M 3 attr Test3 IODev NETIO_TEST </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_DHT at +*00:04 get Test0 DHT;; get Test1 DHT;; get Test2 DHT;; get Test3 DHT attr Messung_DHT verbose 0 </pre> Fünfzehn Messwerte pro Stunde genügen den allermeisten Anforderungen. == [[BMP085 | BMP085/BMP180 Luftdrucksensor]] == [[File:BMP180.jpg|150px|thumb|right|BMP180 (unten links)]] Ethersex unterstützt den BMP085 (bzw. den BMP180; der Code ist identisch) über das [[I2C_(Deutsch) | I2C]]-Interface. Da der Sensor für 3.3V Betriebsspannung ausgelegt ist, muss entweder der I2C-Pegel angepasst oder der ATMega auf 3.3V adaptiert werden. Weiterhin sollte die Höhe über Null bekannt sein. Beispiel: Eine Abfrage per [[ECMD]] mit ''bmp085 pressnn 59000'' bedeutet, das ich 590m (59000cm) über NN wohne. Die im Sensor verfügbare Temperatur wird parallel ausgelesen. '''Einbindung in FHEM''' bmp085.classdef erstellen: <source lang="perl"> get BMP cmd {"bmp085 temp\n\000bmp085 pressnn 59000\n"} get BMP expect ".*" get BMP postproc {\ s/(.*)\n(.*)\n/T: $1 P: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1/10;\ my $pressure = sprintf("%.1f",$2/100);\ my $state = "T: $temperature P: $pressure";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "pressure", $pressure, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die Temperatur wird in °C mit einer Nachkommastelle gelesen, der Luftdruck in hPa bzw. mbar auf eine Nachkommastelle gerundet. Passende Readings werden erstellt. Das expect .* kann noch angepasst werden, um bei fehlerhaften Messwerten entsprechend zu reagieren. Die classdef wird in FHEM eingebunden (mehrere .classdef mit Doppelpunkt trennen: siehe [[Nutzung_in_FHEM_(Deutsch)#Grundlagen | Grundlagen]]): <pre> define NETIO_STK ECMD telnet 192.168.3.89:2701 attr NETIO_STK classdefs BMP=/opt/fhem/FHEM/bmp085.classdef </pre> Der Sensor wird definiert: <pre> define BMP180 ECMDDevice BMP attr BMP180 IODev NETIO_STK </pre> Das STATE ''kann'' mit Maßeinheiten versehen werden: <pre> attr BMP180 stateFormat { sprintf("%s°C %shPa", ReadingsVal("BMP180","temperature",0), ReadingsVal("BMP180","pressure",0)) ;; } </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_BMP at +*00:04 get BMP180 BMP attr Messung_BMP verbose 0 </pre> Dabei unterdrückt verbose 0 einen zusätzlichen (doppelten) Logeintrag des Messvorganges. == analoge Eingänge == todo == [[Porterweiterungen_%28Deutsch%29#D.2FA-Wandler_mit_LTC1257 | LTC1257 D/A-Wandler]] == todo == HD44780 Punktmatrixdisplays == todo == [[RFM12_ASK_(Deutsch) | Intertechno schalten mit RFM12]] == todo == [[RFM12_ASK_(Deutsch) | IC2272 schalten mit RFM12]] == todo [[Category:Application|Application]] e07d15a82ee01167f32eda733176fba35567d0cc 1314 1313 2014-08-17T15:19:54Z Kpwg 721 /* 1-Wire Temperatursensoren */ wikitext text/x-wiki {{i18n|Nutzung in FHEM}} [http://www.fhemwiki.de/wiki/Hauptseite FHEM] ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um diverse per Funk und Kabel angebundene Komponenten aus dem Bereich der Hausautomation zu steuern. Er ist lizensiert unter der GPL v2. Das [http://www.pollin.de/shop/suchergebnis.html?S_TEXT=810+058 AVR-Net-IO] von [http://www.pollin.de Pollin] mit [[Ethersex]] dient als [http://www.fhemwiki.de/wiki/AVR-NET-IO preisgünstiger Einstieg in die Hausautomatisierung]. Verwendbar ist aber auch jede andere Hardware, die von Ethersex unterstützt wird ([http://arduino.cc/en/pmwiki.php?n=Main/ArduinoBoardProMini Arduino], eigene Entwicklungen, etc.). Über [[ECMD]] lassen sich dabei theoretisch alle in [[Ethersex]] vorhandenen [[ECMD_Protocols_%28Deutsch%29 | Möglichkeiten]] nutzen, sofern in FHEM entsprechende [http://fhem.de/commandref.html#ECMD ECMD-Devices] definiert und eingebunden werden. == Grundlagen == Ausgehend von einem fertigen und per Telnet erreichbaren Ethersex muss in FHEM zuerst das entsprechende Device definiert werden. <pre> define NETIO_WZ ECMD telnet 192.168.3.81:2701 </pre> Eine serielle Anbindung kann mit ''define <name> ECMD serial <SerialDevice>[<@BaudRate>]'' alternativ erfolgen. Anschließend werden die erstellten .classdef-Konfigurationsdateien der einzelnen Funktionen dem System bekannt gemacht. In diesen .classdef-Dateien (Name und Endung sind frei wählbar!) wird die Schnittstelle zwischen FHEM und ECMD/Ethersex definiert. Dabei können mit perl übergebene Parameter und empfangene Daten bearbeitet sowie die in FHEM gebräuchlichen Readings erstellt werden. <pre> attr NETIO_WZ classdefs RFM12_2272=/opt/fhem/FHEM/rfm12_2272.classdef:RFM12_IT=/opt/fhem/FHEM/rfm12_it.classdef:LCD=/opt/fhem/FHEM/lcd.classdef:DHT22=/opt/fhem/FHEM/dht22.classdef:1WIRE=/opt/fhem/FHEM/1wire.classdef </pre> Die Definitionen für IC2272, Intertechno, HD44780-LCD, DHT22 und 1wire sind nun eingebunden. In den folgenden Abschnitten wird auf die einzelnen Devices näher eingegangen. Generell sind Pfade und IP-Adressen sowie übergebene Parameter noch entsprechend der eigenen Konfiguration anzupassen. == [[Onewire_(Deutsch) | 1-Wire Temperatursensoren]] == [[File:DS18B20.jpg|150px|thumb|right|DS18B20-Sensoren]] Die 1wire-Temperatursensoren DS18B20 oder DS18S20 werden im [[Onewire_(Deutsch)#Polling_Modus | Polling Modus]] abgefragt. Das macht die zyklische Abfrage aus FHEM heraus wesentlich einfacher. Eine Polling-Zeit von mindestens 30 Sekunden ist absolut ausreichend.Im Vorfeld sollte man sich die [[Onewire_(Deutsch)#Benennung_von_Sensoren | ROM-Codes der Sensoren]] notieren, da diese nachher benötigt werden. 1w-temp.classdef erstellen: <source lang="perl"> # Uebergabeparameter Onewire Rom-Code params devID # Umsetzung in ECMD Befehle 1w get = Temperatur auslesen get 1W cmd {"1w get %devID\n"} get 1W expect "\d+.\d\n" get 1W postproc {\ s/\n//g;\ my $hash = $defs{%NAME};\ my $temperature = $_;\ my $state = "T: $temperature";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die classdef wird eingebunden: <pre> define NETIO_KU ECMD telnet 192.168.3.82:2701 attr NETIO_KU classdefs 1W-TEMP=/opt/fhem/FHEM/1w-temp.classdef </pre> Die Sensoren werden anhand des ROM-Code definiert: <pre> define HZ_WW ECMDDevice 1W-TEMP 284c8820050003d4 attr HZ_WW IODev NETIO_KU define HZ_VL ECMDDevice 1W-TEMP 2890a520050003d7 attr HZ_VL IODev NETIO_KU </pre> Eine zyklische Messung pro Minute lässt sich in dieser Form auslösen: <pre> define Messung_1w at +*00:01 get HZ_WW 1W;; get HZ_VL 1W attr Messung_1w verbose 1 </pre> == [[DHT|DHT22 Temperatur-/Feuchtesensoren]] == [[File:DHT22.jpg|150px|thumb|right|DHT22-Sensoren]] [[Ethersex]] unterstützt die preiswerten Temperatur-/Feuchtesensoren [[DHT|DHT11 und DHT22]], wobei letztere [[DHT#DHT11_vs_DHT22|um einiges genauer sind]]. Die Sensoren benötigen 5V Betriebsspannung und kommunizieren über je einen Pin mit dem Prozessor. Der Preis pro Stück liegt derzeit bei etwa 3.50 Euro (ebay/China). Wer die Trägheit und Ungenauigkeit der S300TH oder TX29DTH kennt, wünscht sich vermutlich Besseres; vor allem bei Berechnung von [http://de.wikipedia.org/wiki/Taupunkt Taupunkt] und [http://de.wikipedia.org/wiki/Luftfeuchtigkeit#Absolute_Luftfeuchtigkeit absoluter Feuchte], welche von der Genauigkeit der gemessenen Eingangsgrößen sehr profitieren. Berechnungen von Hand kann man beim [http://www.wetterochs.de/wetter/feuchte.html Wetterochs] durchführen. Die automatische Berechnung der absoluten Feuchte in FHEM wird im [http://forum.fhem.de/index.php/topic,21458.0.html Forum] erklärt. '''Einbindung in FHEM''' dht22m.classdef erstellen: <pre> # Uebergabeparameter DHT22 ID 0...n params devID # Umsetzung in ECMD Befehle fuer DHT22 get DHT cmd {"dht temp %devID\n\000dht humid %devID\n"} get DHT expect "\d+.\d\n" get DHT postproc {\ s/(.*)\n(.*)\n/T: $1 H: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1;\ my $humidity = $2;\ my $state = $_;\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "humidity", $humidity, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </pre> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs DHT22M=/opt/fhem/FHEM/dht22m.classdef </pre> Die Sensoren werden definiert: <pre> define Test0 ECMDDevice DHT22M 0 attr Test0 IODev NETIO_TEST define Test1 ECMDDevice DHT22M 1 attr Test1 IODev NETIO_TEST define Test2 ECMDDevice DHT22M 2 attr Test2 IODev NETIO_TEST define Test3 ECMDDevice DHT22M 3 attr Test3 IODev NETIO_TEST </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_DHT at +*00:04 get Test0 DHT;; get Test1 DHT;; get Test2 DHT;; get Test3 DHT attr Messung_DHT verbose 0 </pre> Fünfzehn Messwerte pro Stunde genügen den allermeisten Anforderungen. == [[BMP085 | BMP085/BMP180 Luftdrucksensor]] == [[File:BMP180.jpg|150px|thumb|right|BMP180 (unten links)]] Ethersex unterstützt den BMP085 (bzw. den BMP180; der Code ist identisch) über das [[I2C_(Deutsch) | I2C]]-Interface. Da der Sensor für 3.3V Betriebsspannung ausgelegt ist, muss entweder der I2C-Pegel angepasst oder der ATMega auf 3.3V adaptiert werden. Weiterhin sollte die Höhe über Null bekannt sein. Beispiel: Eine Abfrage per [[ECMD]] mit ''bmp085 pressnn 59000'' bedeutet, das ich 590m (59000cm) über NN wohne. Die im Sensor verfügbare Temperatur wird parallel ausgelesen. '''Einbindung in FHEM''' bmp085.classdef erstellen: <source lang="perl"> get BMP cmd {"bmp085 temp\n\000bmp085 pressnn 59000\n"} get BMP expect ".*" get BMP postproc {\ s/(.*)\n(.*)\n/T: $1 P: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1/10;\ my $pressure = sprintf("%.1f",$2/100);\ my $state = "T: $temperature P: $pressure";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "pressure", $pressure, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die Temperatur wird in °C mit einer Nachkommastelle gelesen, der Luftdruck in hPa bzw. mbar auf eine Nachkommastelle gerundet. Passende Readings werden erstellt. Das expect .* kann noch angepasst werden, um bei fehlerhaften Messwerten entsprechend zu reagieren. Die classdef wird in FHEM eingebunden (mehrere .classdef mit Doppelpunkt trennen: siehe [[Nutzung_in_FHEM_(Deutsch)#Grundlagen | Grundlagen]]): <pre> define NETIO_STK ECMD telnet 192.168.3.89:2701 attr NETIO_STK classdefs BMP=/opt/fhem/FHEM/bmp085.classdef </pre> Der Sensor wird definiert: <pre> define BMP180 ECMDDevice BMP attr BMP180 IODev NETIO_STK </pre> Das STATE ''kann'' mit Maßeinheiten versehen werden: <pre> attr BMP180 stateFormat { sprintf("%s°C %shPa", ReadingsVal("BMP180","temperature",0), ReadingsVal("BMP180","pressure",0)) ;; } </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_BMP at +*00:04 get BMP180 BMP attr Messung_BMP verbose 0 </pre> Dabei unterdrückt verbose 0 einen zusätzlichen (doppelten) Logeintrag des Messvorganges. == analoge Eingänge == todo == [[Porterweiterungen_%28Deutsch%29#D.2FA-Wandler_mit_LTC1257 | LTC1257 D/A-Wandler]] == todo == HD44780 Punktmatrixdisplays == todo == [[RFM12_ASK_(Deutsch) | Intertechno schalten mit RFM12]] == todo == [[RFM12_ASK_(Deutsch) | IC2272 schalten mit RFM12]] == todo [[Category:Application|Application]] d1adab109784d93d06b60b1d919a5f0a69c03c29 1315 1314 2014-08-17T15:21:40Z Kpwg 721 /* DHT22 Temperatur-/Feuchtesensoren */ wikitext text/x-wiki {{i18n|Nutzung in FHEM}} [http://www.fhemwiki.de/wiki/Hauptseite FHEM] ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um diverse per Funk und Kabel angebundene Komponenten aus dem Bereich der Hausautomation zu steuern. Er ist lizensiert unter der GPL v2. Das [http://www.pollin.de/shop/suchergebnis.html?S_TEXT=810+058 AVR-Net-IO] von [http://www.pollin.de Pollin] mit [[Ethersex]] dient als [http://www.fhemwiki.de/wiki/AVR-NET-IO preisgünstiger Einstieg in die Hausautomatisierung]. Verwendbar ist aber auch jede andere Hardware, die von Ethersex unterstützt wird ([http://arduino.cc/en/pmwiki.php?n=Main/ArduinoBoardProMini Arduino], eigene Entwicklungen, etc.). Über [[ECMD]] lassen sich dabei theoretisch alle in [[Ethersex]] vorhandenen [[ECMD_Protocols_%28Deutsch%29 | Möglichkeiten]] nutzen, sofern in FHEM entsprechende [http://fhem.de/commandref.html#ECMD ECMD-Devices] definiert und eingebunden werden. == Grundlagen == Ausgehend von einem fertigen und per Telnet erreichbaren Ethersex muss in FHEM zuerst das entsprechende Device definiert werden. <pre> define NETIO_WZ ECMD telnet 192.168.3.81:2701 </pre> Eine serielle Anbindung kann mit ''define <name> ECMD serial <SerialDevice>[<@BaudRate>]'' alternativ erfolgen. Anschließend werden die erstellten .classdef-Konfigurationsdateien der einzelnen Funktionen dem System bekannt gemacht. In diesen .classdef-Dateien (Name und Endung sind frei wählbar!) wird die Schnittstelle zwischen FHEM und ECMD/Ethersex definiert. Dabei können mit perl übergebene Parameter und empfangene Daten bearbeitet sowie die in FHEM gebräuchlichen Readings erstellt werden. <pre> attr NETIO_WZ classdefs RFM12_2272=/opt/fhem/FHEM/rfm12_2272.classdef:RFM12_IT=/opt/fhem/FHEM/rfm12_it.classdef:LCD=/opt/fhem/FHEM/lcd.classdef:DHT22=/opt/fhem/FHEM/dht22.classdef:1WIRE=/opt/fhem/FHEM/1wire.classdef </pre> Die Definitionen für IC2272, Intertechno, HD44780-LCD, DHT22 und 1wire sind nun eingebunden. In den folgenden Abschnitten wird auf die einzelnen Devices näher eingegangen. Generell sind Pfade und IP-Adressen sowie übergebene Parameter noch entsprechend der eigenen Konfiguration anzupassen. == [[Onewire_(Deutsch) | 1-Wire Temperatursensoren]] == [[File:DS18B20.jpg|150px|thumb|right|DS18B20-Sensoren]] Die 1wire-Temperatursensoren DS18B20 oder DS18S20 werden im [[Onewire_(Deutsch)#Polling_Modus | Polling Modus]] abgefragt. Das macht die zyklische Abfrage aus FHEM heraus wesentlich einfacher. Eine Polling-Zeit von mindestens 30 Sekunden ist absolut ausreichend.Im Vorfeld sollte man sich die [[Onewire_(Deutsch)#Benennung_von_Sensoren | ROM-Codes der Sensoren]] notieren, da diese nachher benötigt werden. 1w-temp.classdef erstellen: <source lang="perl"> # Uebergabeparameter Onewire Rom-Code params devID # Umsetzung in ECMD Befehle 1w get = Temperatur auslesen get 1W cmd {"1w get %devID\n"} get 1W expect "\d+.\d\n" get 1W postproc {\ s/\n//g;\ my $hash = $defs{%NAME};\ my $temperature = $_;\ my $state = "T: $temperature";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die classdef wird eingebunden: <pre> define NETIO_KU ECMD telnet 192.168.3.82:2701 attr NETIO_KU classdefs 1W-TEMP=/opt/fhem/FHEM/1w-temp.classdef </pre> Die Sensoren werden anhand des ROM-Code definiert: <pre> define HZ_WW ECMDDevice 1W-TEMP 284c8820050003d4 attr HZ_WW IODev NETIO_KU define HZ_VL ECMDDevice 1W-TEMP 2890a520050003d7 attr HZ_VL IODev NETIO_KU </pre> Eine zyklische Messung pro Minute lässt sich in dieser Form auslösen: <pre> define Messung_1w at +*00:01 get HZ_WW 1W;; get HZ_VL 1W attr Messung_1w verbose 1 </pre> == [[DHT|DHT22 Temperatur-/Feuchtesensoren]] == [[File:DHT22.jpg|150px|thumb|right|DHT22-Sensoren]] [[Ethersex]] unterstützt die preiswerten Temperatur-/Feuchtesensoren [[DHT|DHT11 und DHT22]], wobei letztere [[DHT#DHT11_vs_DHT22|um einiges genauer sind]]. Die Sensoren benötigen 5V Betriebsspannung und kommunizieren über je einen Pin mit dem Prozessor. Der Preis pro Stück liegt derzeit bei etwa 3.50 Euro (ebay/China). Wer die Trägheit und Ungenauigkeit der S300TH oder TX29DTH kennt, wünscht sich vermutlich Besseres; vor allem bei Berechnung von [http://de.wikipedia.org/wiki/Taupunkt Taupunkt] und [http://de.wikipedia.org/wiki/Luftfeuchtigkeit#Absolute_Luftfeuchtigkeit absoluter Feuchte], welche von der Genauigkeit der gemessenen Eingangsgrößen sehr profitieren. Berechnungen von Hand kann man beim [http://www.wetterochs.de/wetter/feuchte.html Wetterochs] durchführen. Die automatische Berechnung der absoluten Feuchte in FHEM wird im [http://forum.fhem.de/index.php/topic,21458.0.html Forum] erklärt. '''Einbindung in FHEM''' dht22m.classdef erstellen: <source lang="perl"> # Uebergabeparameter DHT22 ID 0...n params devID # Umsetzung in ECMD Befehle fuer DHT22 get DHT cmd {"dht temp %devID\n\000dht humid %devID\n"} get DHT expect "\d+.\d\n" get DHT postproc {\ s/(.*)\n(.*)\n/T: $1 H: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1;\ my $humidity = $2;\ my $state = $_;\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "humidity", $humidity, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs DHT22M=/opt/fhem/FHEM/dht22m.classdef </pre> Die Sensoren werden definiert: <pre> define Test0 ECMDDevice DHT22M 0 attr Test0 IODev NETIO_TEST define Test1 ECMDDevice DHT22M 1 attr Test1 IODev NETIO_TEST define Test2 ECMDDevice DHT22M 2 attr Test2 IODev NETIO_TEST define Test3 ECMDDevice DHT22M 3 attr Test3 IODev NETIO_TEST </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_DHT at +*00:04 get Test0 DHT;; get Test1 DHT;; get Test2 DHT;; get Test3 DHT attr Messung_DHT verbose 0 </pre> Fünfzehn Messwerte pro Stunde genügen den allermeisten Anforderungen. == [[BMP085 | BMP085/BMP180 Luftdrucksensor]] == [[File:BMP180.jpg|150px|thumb|right|BMP180 (unten links)]] Ethersex unterstützt den BMP085 (bzw. den BMP180; der Code ist identisch) über das [[I2C_(Deutsch) | I2C]]-Interface. Da der Sensor für 3.3V Betriebsspannung ausgelegt ist, muss entweder der I2C-Pegel angepasst oder der ATMega auf 3.3V adaptiert werden. Weiterhin sollte die Höhe über Null bekannt sein. Beispiel: Eine Abfrage per [[ECMD]] mit ''bmp085 pressnn 59000'' bedeutet, das ich 590m (59000cm) über NN wohne. Die im Sensor verfügbare Temperatur wird parallel ausgelesen. '''Einbindung in FHEM''' bmp085.classdef erstellen: <source lang="perl"> get BMP cmd {"bmp085 temp\n\000bmp085 pressnn 59000\n"} get BMP expect ".*" get BMP postproc {\ s/(.*)\n(.*)\n/T: $1 P: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1/10;\ my $pressure = sprintf("%.1f",$2/100);\ my $state = "T: $temperature P: $pressure";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "pressure", $pressure, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die Temperatur wird in °C mit einer Nachkommastelle gelesen, der Luftdruck in hPa bzw. mbar auf eine Nachkommastelle gerundet. Passende Readings werden erstellt. Das expect .* kann noch angepasst werden, um bei fehlerhaften Messwerten entsprechend zu reagieren. Die classdef wird in FHEM eingebunden (mehrere .classdef mit Doppelpunkt trennen: siehe [[Nutzung_in_FHEM_(Deutsch)#Grundlagen | Grundlagen]]): <pre> define NETIO_STK ECMD telnet 192.168.3.89:2701 attr NETIO_STK classdefs BMP=/opt/fhem/FHEM/bmp085.classdef </pre> Der Sensor wird definiert: <pre> define BMP180 ECMDDevice BMP attr BMP180 IODev NETIO_STK </pre> Das STATE ''kann'' mit Maßeinheiten versehen werden: <pre> attr BMP180 stateFormat { sprintf("%s°C %shPa", ReadingsVal("BMP180","temperature",0), ReadingsVal("BMP180","pressure",0)) ;; } </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_BMP at +*00:04 get BMP180 BMP attr Messung_BMP verbose 0 </pre> Dabei unterdrückt verbose 0 einen zusätzlichen (doppelten) Logeintrag des Messvorganges. == analoge Eingänge == todo == [[Porterweiterungen_%28Deutsch%29#D.2FA-Wandler_mit_LTC1257 | LTC1257 D/A-Wandler]] == todo == HD44780 Punktmatrixdisplays == todo == [[RFM12_ASK_(Deutsch) | Intertechno schalten mit RFM12]] == todo == [[RFM12_ASK_(Deutsch) | IC2272 schalten mit RFM12]] == todo [[Category:Application|Application]] 9d5351aee4e207eb7558132bdbdb2be240d95a05 1316 1315 2014-08-24T18:48:51Z Kpwg 721 /* HD44780 Punktmatrixdisplays */ wikitext text/x-wiki {{i18n|Nutzung in FHEM}} [http://www.fhemwiki.de/wiki/Hauptseite FHEM] ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um diverse per Funk und Kabel angebundene Komponenten aus dem Bereich der Hausautomation zu steuern. Er ist lizensiert unter der GPL v2. Das [http://www.pollin.de/shop/suchergebnis.html?S_TEXT=810+058 AVR-Net-IO] von [http://www.pollin.de Pollin] mit [[Ethersex]] dient als [http://www.fhemwiki.de/wiki/AVR-NET-IO preisgünstiger Einstieg in die Hausautomatisierung]. Verwendbar ist aber auch jede andere Hardware, die von Ethersex unterstützt wird ([http://arduino.cc/en/pmwiki.php?n=Main/ArduinoBoardProMini Arduino], eigene Entwicklungen, etc.). Über [[ECMD]] lassen sich dabei theoretisch alle in [[Ethersex]] vorhandenen [[ECMD_Protocols_%28Deutsch%29 | Möglichkeiten]] nutzen, sofern in FHEM entsprechende [http://fhem.de/commandref.html#ECMD ECMD-Devices] definiert und eingebunden werden. == Grundlagen == Ausgehend von einem fertigen und per Telnet erreichbaren Ethersex muss in FHEM zuerst das entsprechende Device definiert werden. <pre> define NETIO_WZ ECMD telnet 192.168.3.81:2701 </pre> Eine serielle Anbindung kann mit ''define <name> ECMD serial <SerialDevice>[<@BaudRate>]'' alternativ erfolgen. Anschließend werden die erstellten .classdef-Konfigurationsdateien der einzelnen Funktionen dem System bekannt gemacht. In diesen .classdef-Dateien (Name und Endung sind frei wählbar!) wird die Schnittstelle zwischen FHEM und ECMD/Ethersex definiert. Dabei können mit perl übergebene Parameter und empfangene Daten bearbeitet sowie die in FHEM gebräuchlichen Readings erstellt werden. <pre> attr NETIO_WZ classdefs RFM12_2272=/opt/fhem/FHEM/rfm12_2272.classdef:RFM12_IT=/opt/fhem/FHEM/rfm12_it.classdef:LCD=/opt/fhem/FHEM/lcd.classdef:DHT22=/opt/fhem/FHEM/dht22.classdef:1WIRE=/opt/fhem/FHEM/1wire.classdef </pre> Die Definitionen für IC2272, Intertechno, HD44780-LCD, DHT22 und 1wire sind nun eingebunden. In den folgenden Abschnitten wird auf die einzelnen Devices näher eingegangen. Generell sind Pfade und IP-Adressen sowie übergebene Parameter noch entsprechend der eigenen Konfiguration anzupassen. == [[Onewire_(Deutsch) | 1-Wire Temperatursensoren]] == [[File:DS18B20.jpg|150px|thumb|right|DS18B20-Sensoren]] Die 1wire-Temperatursensoren DS18B20 oder DS18S20 werden im [[Onewire_(Deutsch)#Polling_Modus | Polling Modus]] abgefragt. Das macht die zyklische Abfrage aus FHEM heraus wesentlich einfacher. Eine Polling-Zeit von mindestens 30 Sekunden ist absolut ausreichend.Im Vorfeld sollte man sich die [[Onewire_(Deutsch)#Benennung_von_Sensoren | ROM-Codes der Sensoren]] notieren, da diese nachher benötigt werden. 1w-temp.classdef erstellen: <source lang="perl"> # Uebergabeparameter Onewire Rom-Code params devID # Umsetzung in ECMD Befehle 1w get = Temperatur auslesen get 1W cmd {"1w get %devID\n"} get 1W expect "\d+.\d\n" get 1W postproc {\ s/\n//g;\ my $hash = $defs{%NAME};\ my $temperature = $_;\ my $state = "T: $temperature";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die classdef wird eingebunden: <pre> define NETIO_KU ECMD telnet 192.168.3.82:2701 attr NETIO_KU classdefs 1W-TEMP=/opt/fhem/FHEM/1w-temp.classdef </pre> Die Sensoren werden anhand des ROM-Code definiert: <pre> define HZ_WW ECMDDevice 1W-TEMP 284c8820050003d4 attr HZ_WW IODev NETIO_KU define HZ_VL ECMDDevice 1W-TEMP 2890a520050003d7 attr HZ_VL IODev NETIO_KU </pre> Eine zyklische Messung pro Minute lässt sich in dieser Form auslösen: <pre> define Messung_1w at +*00:01 get HZ_WW 1W;; get HZ_VL 1W attr Messung_1w verbose 1 </pre> == [[DHT|DHT22 Temperatur-/Feuchtesensoren]] == [[File:DHT22.jpg|150px|thumb|right|DHT22-Sensoren]] [[Ethersex]] unterstützt die preiswerten Temperatur-/Feuchtesensoren [[DHT|DHT11 und DHT22]], wobei letztere [[DHT#DHT11_vs_DHT22|um einiges genauer sind]]. Die Sensoren benötigen 5V Betriebsspannung und kommunizieren über je einen Pin mit dem Prozessor. Der Preis pro Stück liegt derzeit bei etwa 3.50 Euro (ebay/China). Wer die Trägheit und Ungenauigkeit der S300TH oder TX29DTH kennt, wünscht sich vermutlich Besseres; vor allem bei Berechnung von [http://de.wikipedia.org/wiki/Taupunkt Taupunkt] und [http://de.wikipedia.org/wiki/Luftfeuchtigkeit#Absolute_Luftfeuchtigkeit absoluter Feuchte], welche von der Genauigkeit der gemessenen Eingangsgrößen sehr profitieren. Berechnungen von Hand kann man beim [http://www.wetterochs.de/wetter/feuchte.html Wetterochs] durchführen. Die automatische Berechnung der absoluten Feuchte in FHEM wird im [http://forum.fhem.de/index.php/topic,21458.0.html Forum] erklärt. '''Einbindung in FHEM''' dht22m.classdef erstellen: <source lang="perl"> # Uebergabeparameter DHT22 ID 0...n params devID # Umsetzung in ECMD Befehle fuer DHT22 get DHT cmd {"dht temp %devID\n\000dht humid %devID\n"} get DHT expect "\d+.\d\n" get DHT postproc {\ s/(.*)\n(.*)\n/T: $1 H: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1;\ my $humidity = $2;\ my $state = $_;\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "humidity", $humidity, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs DHT22M=/opt/fhem/FHEM/dht22m.classdef </pre> Die Sensoren werden definiert: <pre> define Test0 ECMDDevice DHT22M 0 attr Test0 IODev NETIO_TEST define Test1 ECMDDevice DHT22M 1 attr Test1 IODev NETIO_TEST define Test2 ECMDDevice DHT22M 2 attr Test2 IODev NETIO_TEST define Test3 ECMDDevice DHT22M 3 attr Test3 IODev NETIO_TEST </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_DHT at +*00:04 get Test0 DHT;; get Test1 DHT;; get Test2 DHT;; get Test3 DHT attr Messung_DHT verbose 0 </pre> Fünfzehn Messwerte pro Stunde genügen den allermeisten Anforderungen. == [[BMP085 | BMP085/BMP180 Luftdrucksensor]] == [[File:BMP180.jpg|150px|thumb|right|BMP180 (unten links)]] Ethersex unterstützt den BMP085 (bzw. den BMP180; der Code ist identisch) über das [[I2C_(Deutsch) | I2C]]-Interface. Da der Sensor für 3.3V Betriebsspannung ausgelegt ist, muss entweder der I2C-Pegel angepasst oder der ATMega auf 3.3V adaptiert werden. Weiterhin sollte die Höhe über Null bekannt sein. Beispiel: Eine Abfrage per [[ECMD]] mit ''bmp085 pressnn 59000'' bedeutet, das ich 590m (59000cm) über NN wohne. Die im Sensor verfügbare Temperatur wird parallel ausgelesen. '''Einbindung in FHEM''' bmp085.classdef erstellen: <source lang="perl"> get BMP cmd {"bmp085 temp\n\000bmp085 pressnn 59000\n"} get BMP expect ".*" get BMP postproc {\ s/(.*)\n(.*)\n/T: $1 P: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1/10;\ my $pressure = sprintf("%.1f",$2/100);\ my $state = "T: $temperature P: $pressure";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "pressure", $pressure, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die Temperatur wird in °C mit einer Nachkommastelle gelesen, der Luftdruck in hPa bzw. mbar auf eine Nachkommastelle gerundet. Passende Readings werden erstellt. Das expect .* kann noch angepasst werden, um bei fehlerhaften Messwerten entsprechend zu reagieren. Die classdef wird in FHEM eingebunden (mehrere .classdef mit Doppelpunkt trennen: siehe [[Nutzung_in_FHEM_(Deutsch)#Grundlagen | Grundlagen]]): <pre> define NETIO_STK ECMD telnet 192.168.3.89:2701 attr NETIO_STK classdefs BMP=/opt/fhem/FHEM/bmp085.classdef </pre> Der Sensor wird definiert: <pre> define BMP180 ECMDDevice BMP attr BMP180 IODev NETIO_STK </pre> Das STATE ''kann'' mit Maßeinheiten versehen werden: <pre> attr BMP180 stateFormat { sprintf("%s°C %shPa", ReadingsVal("BMP180","temperature",0), ReadingsVal("BMP180","pressure",0)) ;; } </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_BMP at +*00:04 get BMP180 BMP attr Messung_BMP verbose 0 </pre> Dabei unterdrückt verbose 0 einen zusätzlichen (doppelten) Logeintrag des Messvorganges. == analoge Eingänge == todo == [[Porterweiterungen_%28Deutsch%29#D.2FA-Wandler_mit_LTC1257 | LTC1257 D/A-Wandler]] == todo == HD44780 Punktmatrixdisplays == [[File:HD44780.jpg|150px|thumb|right|verschiedene HD44780 Displays (16x1 bis 40x4)]] Die beliebten Punktmatrix-Displays auf Basis [http://de.wikipedia.org/wiki/HD44780 HD44780] können vollumfänglich in FHEM beschrieben werden. Dabei wird vorrausgesetzt, das in [https://github.com/ethersex/ethersex/blob/master/hardware/lcd/hd44780.h /hardware/lcd/hd44780.h] die passende Adressierung der Zeilen und die genutzte Zeilen-/Spaltenzahl vor dem Compilieren angepasst wurde. '''Einbindung in FHEM''' lcd.classdef erstellen: <source lang="perl"> # Umsetzung der ECMD Befehle set write params line col text set write cmd {"lcd goto %line %col\n\000lcd write %text\n"} set write expect "OK\n" set write postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set clear params col set clear cmd {"lcd clear %col\n"} set clear expect "OK\n" set clear postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set clear_all cmd {"lcd clear\n"} set clear_all expect "OK\n" set clear_all postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set lcd_bl params state set lcd_bl cmd {"lcd backlight %state\n"} set lcd_bl expect "OK\n" set lcd_bl postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} </source> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs LCD=/opt/fhem/FHEM/lcd.classdef </pre> Das Display wird definiert: <pre> define WZ_LCD ECMDDevice LCD attr WZ_LCD IODev NETIO_TEST </pre> Es stehen in FHEM folgende Befehle für das LCD bereit: {| border='1' | ''Befehl'' | ''Funktion'' |- | set WZ_LCD clear [ZEILE] | löscht den Inhalt einer ZEILE (0...3) |- | set WZ_LCD clear_all | löscht den Inhalt aller Zeilen |- | set WZ_LCD lcd_bl STATE | schaltet die Hintergrundbeleuchtung ein oder aus (STATE on oder off) |- | set WZ_LCD write [ZEILE] [SPALTE] [TEXT] | schreibt einen TEXT auf Position ZEILE SPALTE (0...n) |- |} Da ein im TEXT übergebenes Leerzeichen als weiterer Befehl interpretiert wird und zu einer Fehlermeldung führt, ist eine Übergabe nur mit \x20 im Text möglich. Das gilt auch für Umlaute. Anhand der [http://de.wikipedia.org/wiki/HD44780#Schrift_und_Zeichensatz Zeichensatztabelle] lassen sich ä durch \xE1, ü durch \xF5 und ö durch \xEF darstellen. Das ß wird mit \xE2 erreicht. Die Tabelle kann für manche Displays abweichend sein.<br /> Beispiel: ''set WZ_LCD write 0 0 Fenster\x20schlie\xE2en'' schreibt ein '''Fenster schließen''' auf's LCD. == [[RFM12_ASK_(Deutsch) | Intertechno schalten mit RFM12]] == todo == [[RFM12_ASK_(Deutsch) | IC2272 schalten mit RFM12]] == todo [[Category:Application|Application]] 3b45189f21e6a3e43aa6cfca06f0ab14bc20c313 1322 1316 2014-08-31T08:00:44Z Kpwg 721 /* HD44780 Punktmatrixdisplays */ wikitext text/x-wiki {{i18n|Nutzung in FHEM}} [http://www.fhemwiki.de/wiki/Hauptseite FHEM] ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um diverse per Funk und Kabel angebundene Komponenten aus dem Bereich der Hausautomation zu steuern. Er ist lizensiert unter der GPL v2. Das [http://www.pollin.de/shop/suchergebnis.html?S_TEXT=810+058 AVR-Net-IO] von [http://www.pollin.de Pollin] mit [[Ethersex]] dient als [http://www.fhemwiki.de/wiki/AVR-NET-IO preisgünstiger Einstieg in die Hausautomatisierung]. Verwendbar ist aber auch jede andere Hardware, die von Ethersex unterstützt wird ([http://arduino.cc/en/pmwiki.php?n=Main/ArduinoBoardProMini Arduino], eigene Entwicklungen, etc.). Über [[ECMD]] lassen sich dabei theoretisch alle in [[Ethersex]] vorhandenen [[ECMD_Protocols_%28Deutsch%29 | Möglichkeiten]] nutzen, sofern in FHEM entsprechende [http://fhem.de/commandref.html#ECMD ECMD-Devices] definiert und eingebunden werden. == Grundlagen == Ausgehend von einem fertigen und per Telnet erreichbaren Ethersex muss in FHEM zuerst das entsprechende Device definiert werden. <pre> define NETIO_WZ ECMD telnet 192.168.3.81:2701 </pre> Eine serielle Anbindung kann mit ''define <name> ECMD serial <SerialDevice>[<@BaudRate>]'' alternativ erfolgen. Anschließend werden die erstellten .classdef-Konfigurationsdateien der einzelnen Funktionen dem System bekannt gemacht. In diesen .classdef-Dateien (Name und Endung sind frei wählbar!) wird die Schnittstelle zwischen FHEM und ECMD/Ethersex definiert. Dabei können mit perl übergebene Parameter und empfangene Daten bearbeitet sowie die in FHEM gebräuchlichen Readings erstellt werden. <pre> attr NETIO_WZ classdefs RFM12_2272=/opt/fhem/FHEM/rfm12_2272.classdef:RFM12_IT=/opt/fhem/FHEM/rfm12_it.classdef:LCD=/opt/fhem/FHEM/lcd.classdef:DHT22=/opt/fhem/FHEM/dht22.classdef:1WIRE=/opt/fhem/FHEM/1wire.classdef </pre> Die Definitionen für IC2272, Intertechno, HD44780-LCD, DHT22 und 1wire sind nun eingebunden. In den folgenden Abschnitten wird auf die einzelnen Devices näher eingegangen. Generell sind Pfade und IP-Adressen sowie übergebene Parameter noch entsprechend der eigenen Konfiguration anzupassen. == [[Onewire_(Deutsch) | 1-Wire Temperatursensoren]] == [[File:DS18B20.jpg|150px|thumb|right|DS18B20-Sensoren]] Die 1wire-Temperatursensoren DS18B20 oder DS18S20 werden im [[Onewire_(Deutsch)#Polling_Modus | Polling Modus]] abgefragt. Das macht die zyklische Abfrage aus FHEM heraus wesentlich einfacher. Eine Polling-Zeit von mindestens 30 Sekunden ist absolut ausreichend.Im Vorfeld sollte man sich die [[Onewire_(Deutsch)#Benennung_von_Sensoren | ROM-Codes der Sensoren]] notieren, da diese nachher benötigt werden. 1w-temp.classdef erstellen: <source lang="perl"> # Uebergabeparameter Onewire Rom-Code params devID # Umsetzung in ECMD Befehle 1w get = Temperatur auslesen get 1W cmd {"1w get %devID\n"} get 1W expect "\d+.\d\n" get 1W postproc {\ s/\n//g;\ my $hash = $defs{%NAME};\ my $temperature = $_;\ my $state = "T: $temperature";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die classdef wird eingebunden: <pre> define NETIO_KU ECMD telnet 192.168.3.82:2701 attr NETIO_KU classdefs 1W-TEMP=/opt/fhem/FHEM/1w-temp.classdef </pre> Die Sensoren werden anhand des ROM-Code definiert: <pre> define HZ_WW ECMDDevice 1W-TEMP 284c8820050003d4 attr HZ_WW IODev NETIO_KU define HZ_VL ECMDDevice 1W-TEMP 2890a520050003d7 attr HZ_VL IODev NETIO_KU </pre> Eine zyklische Messung pro Minute lässt sich in dieser Form auslösen: <pre> define Messung_1w at +*00:01 get HZ_WW 1W;; get HZ_VL 1W attr Messung_1w verbose 1 </pre> == [[DHT|DHT22 Temperatur-/Feuchtesensoren]] == [[File:DHT22.jpg|150px|thumb|right|DHT22-Sensoren]] [[Ethersex]] unterstützt die preiswerten Temperatur-/Feuchtesensoren [[DHT|DHT11 und DHT22]], wobei letztere [[DHT#DHT11_vs_DHT22|um einiges genauer sind]]. Die Sensoren benötigen 5V Betriebsspannung und kommunizieren über je einen Pin mit dem Prozessor. Der Preis pro Stück liegt derzeit bei etwa 3.50 Euro (ebay/China). Wer die Trägheit und Ungenauigkeit der S300TH oder TX29DTH kennt, wünscht sich vermutlich Besseres; vor allem bei Berechnung von [http://de.wikipedia.org/wiki/Taupunkt Taupunkt] und [http://de.wikipedia.org/wiki/Luftfeuchtigkeit#Absolute_Luftfeuchtigkeit absoluter Feuchte], welche von der Genauigkeit der gemessenen Eingangsgrößen sehr profitieren. Berechnungen von Hand kann man beim [http://www.wetterochs.de/wetter/feuchte.html Wetterochs] durchführen. Die automatische Berechnung der absoluten Feuchte in FHEM wird im [http://forum.fhem.de/index.php/topic,21458.0.html Forum] erklärt. '''Einbindung in FHEM''' dht22m.classdef erstellen: <source lang="perl"> # Uebergabeparameter DHT22 ID 0...n params devID # Umsetzung in ECMD Befehle fuer DHT22 get DHT cmd {"dht temp %devID\n\000dht humid %devID\n"} get DHT expect "\d+.\d\n" get DHT postproc {\ s/(.*)\n(.*)\n/T: $1 H: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1;\ my $humidity = $2;\ my $state = $_;\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "humidity", $humidity, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs DHT22M=/opt/fhem/FHEM/dht22m.classdef </pre> Die Sensoren werden definiert: <pre> define Test0 ECMDDevice DHT22M 0 attr Test0 IODev NETIO_TEST define Test1 ECMDDevice DHT22M 1 attr Test1 IODev NETIO_TEST define Test2 ECMDDevice DHT22M 2 attr Test2 IODev NETIO_TEST define Test3 ECMDDevice DHT22M 3 attr Test3 IODev NETIO_TEST </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_DHT at +*00:04 get Test0 DHT;; get Test1 DHT;; get Test2 DHT;; get Test3 DHT attr Messung_DHT verbose 0 </pre> Fünfzehn Messwerte pro Stunde genügen den allermeisten Anforderungen. == [[BMP085 | BMP085/BMP180 Luftdrucksensor]] == [[File:BMP180.jpg|150px|thumb|right|BMP180 (unten links)]] Ethersex unterstützt den BMP085 (bzw. den BMP180; der Code ist identisch) über das [[I2C_(Deutsch) | I2C]]-Interface. Da der Sensor für 3.3V Betriebsspannung ausgelegt ist, muss entweder der I2C-Pegel angepasst oder der ATMega auf 3.3V adaptiert werden. Weiterhin sollte die Höhe über Null bekannt sein. Beispiel: Eine Abfrage per [[ECMD]] mit ''bmp085 pressnn 59000'' bedeutet, das ich 590m (59000cm) über NN wohne. Die im Sensor verfügbare Temperatur wird parallel ausgelesen. '''Einbindung in FHEM''' bmp085.classdef erstellen: <source lang="perl"> get BMP cmd {"bmp085 temp\n\000bmp085 pressnn 59000\n"} get BMP expect ".*" get BMP postproc {\ s/(.*)\n(.*)\n/T: $1 P: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1/10;\ my $pressure = sprintf("%.1f",$2/100);\ my $state = "T: $temperature P: $pressure";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "pressure", $pressure, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die Temperatur wird in °C mit einer Nachkommastelle gelesen, der Luftdruck in hPa bzw. mbar auf eine Nachkommastelle gerundet. Passende Readings werden erstellt. Das expect .* kann noch angepasst werden, um bei fehlerhaften Messwerten entsprechend zu reagieren. Die classdef wird in FHEM eingebunden (mehrere .classdef mit Doppelpunkt trennen: siehe [[Nutzung_in_FHEM_(Deutsch)#Grundlagen | Grundlagen]]): <pre> define NETIO_STK ECMD telnet 192.168.3.89:2701 attr NETIO_STK classdefs BMP=/opt/fhem/FHEM/bmp085.classdef </pre> Der Sensor wird definiert: <pre> define BMP180 ECMDDevice BMP attr BMP180 IODev NETIO_STK </pre> Das STATE ''kann'' mit Maßeinheiten versehen werden: <pre> attr BMP180 stateFormat { sprintf("%s°C %shPa", ReadingsVal("BMP180","temperature",0), ReadingsVal("BMP180","pressure",0)) ;; } </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_BMP at +*00:04 get BMP180 BMP attr Messung_BMP verbose 0 </pre> Dabei unterdrückt verbose 0 einen zusätzlichen (doppelten) Logeintrag des Messvorganges. == analoge Eingänge == todo == [[Porterweiterungen_%28Deutsch%29#D.2FA-Wandler_mit_LTC1257 | LTC1257 D/A-Wandler]] == todo == HD44780 Punktmatrixdisplays == [[File:HD44780.jpg|150px|thumb|right|verschiedene HD44780 Displays (16x1 bis 40x4)]] Die beliebten Punktmatrix-Displays auf Basis [http://de.wikipedia.org/wiki/HD44780 HD44780] können vollumfänglich in FHEM beschrieben werden. Dabei wird vorrausgesetzt, das in [https://github.com/ethersex/ethersex/blob/master/hardware/lcd/hd44780.h /hardware/lcd/hd44780.h] die passende Adressierung der Zeilen und die genutzte Zeilen-/Spaltenzahl vor dem Compilieren angepasst wurde. '''Einbindung in FHEM''' lcd.classdef erstellen: <source lang="perl"> # Umsetzung der ECMD Befehle set write params line col text set write cmd {"lcd goto %line %col\n\000lcd write %text\n"} set write expect "OK\n" set write postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set clear params col set clear cmd {"lcd clear %col\n"} set clear expect "OK\n" set clear postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set clear_all cmd {"lcd clear\n"} set clear_all expect "OK\n" set clear_all postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set lcd_bl params state set lcd_bl cmd {"lcd backlight %state\n"} set lcd_bl expect "OK\n" set lcd_bl postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} </source> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs LCD=/opt/fhem/FHEM/lcd.classdef </pre> Das Display wird definiert: <pre> define WZ_LCD ECMDDevice LCD attr WZ_LCD IODev NETIO_TEST </pre> Es stehen in FHEM folgende Befehle für das LCD bereit: {| border='1' | ''Befehl'' | ''Funktion'' |- | set WZ_LCD clear [ZEILE] | löscht den Inhalt einer ZEILE (0...3) |- | set WZ_LCD clear_all | löscht den Inhalt aller Zeilen |- | set WZ_LCD lcd_bl STATE | schaltet die Hintergrundbeleuchtung ein oder aus (STATE on oder off) |- | set WZ_LCD write [ZEILE] [SPALTE] [TEXT] | schreibt einen TEXT auf Position ZEILE SPALTE (0...n) |- |} Da ein im TEXT übergebenes Leerzeichen als weiterer Befehl interpretiert wird und zu einer Fehlermeldung führt, ist eine Übergabe nur mit \x20 im Text möglich. Das gilt auch für Umlaute. Anhand der [http://de.wikipedia.org/wiki/HD44780#Schrift_und_Zeichensatz Zeichensatztabelle] lassen sich ä durch \xE1, ü durch \xF5 und ö durch \xEF darstellen. Das ß wird mit \xE2 erreicht. Die Tabelle kann für manche Displays abweichend sein.<br /> Beispiel: ''set WZ_LCD write 0 0 Fenster\x20schlie\xE2en'' schreibt ein '''Fenster schließen''' auf's LCD. '''Komfortable Nutzung in FHEM mit DLCD''' Mit dem DLCD-Modul ([http://www.fhemwiki.de/wiki/DLCD Wiki-Beitrag] / [http://forum.fhem.de/index.php/topic,24519.0.html Foren-Beitrag]) für FHEM lässt sich jedes Display schnell und komfortabel beschreiben. Dabei lassen sich bequem Readings von allen Devices nutzen, aufbereiten (formatieren, umrechnen, etc.) und darstellen. Eine genaue Beschreibung hält der Wiki-Beitrag bereit; hier soll ein Beispiel gezeigt werden. Ziel war es, auf einem 16x1 LCD wechselweise ''Datum/Zeit => Klimadaten Keller => Datum/Zeit => Klimadaten Garten'' darzustellen. Die Anzeige rotiert im 15-Sekunden-Takt, so das zu 50% Datum/Zeit und je 25% die Werte aus dem Garten und dem Keller angezeigt werden. Es wird bereits im Modul jedes Leerzeichen mit \x20 übersetzt. Der Außensensor ist ein [http://www.elv.de/elv-funk-kombi-wettersensor-ks-300-2-br-inkl-hochwertigem-2-m-edelstahlmast-br-und-qualitaetsbatterien.html KS300] (bzw. KS200) von ELV. Mit etwas Formatierung lässt sich eine stets gleiche Positionierung der Daten erreichen. Auszug aus der fhem.cfg: <pre> define DLCD_WZ DLCD attr DLCD_WZ dlcdBlankspaceReplace \x20 attr DLCD_WZ dlcdCols 16 attr DLCD_WZ dlcdLine1 %date_WD_ger% %date_D%.%date_M_ger% %time_h%:%time_m% attr DLCD_WZ dlcdLine2 Keller:%1%/%2% attr DLCD_WZ dlcdLine3 %date_WD_ger% %date_D%.%date_M_ger% %time_h%:%time_m% attr DLCD_WZ dlcdLine4 Garten: %3%/%4% attr DLCD_WZ dlcdPhysicalRows 1 attr DLCD_WZ dlcdPollInterval 15 attr DLCD_WZ dlcdRows 4 attr DLCD_WZ dlcdScrolling 1 attr DLCD_WZ dlcdTriggerCmd set WZ_LCD write %L% 0 %T% attr DLCD_WZ dlcdVal1 Keller:temperature attr DLCD_WZ dlcdVal1formatnum 3+1 attr DLCD_WZ dlcdVal2 Keller:humidity attr DLCD_WZ dlcdVal2formatnum 3+1 attr DLCD_WZ dlcdVal3 KS300:temperature attr DLCD_WZ dlcdVal3formatnum 3+1+- attr DLCD_WZ dlcdVal4 KS300:humidity attr DLCD_WZ dlcdVal4formatnum 2+0 </pre> Das Ergebnis kann so aussehen: <gallery> DLCD_1.jpg|Zustand 0-14 Sekunden DLCD_2.jpg|Zustand 15-29 Sekunden DLCD_3.jpg|Zustand 30-44 Sekunden DLCD_4.jpg|Zustand 45-59 Sekunden </gallery> == [[RFM12_ASK_(Deutsch) | Intertechno schalten mit RFM12]] == todo == [[RFM12_ASK_(Deutsch) | IC2272 schalten mit RFM12]] == todo [[Category:Application|Application]] 2bb99db12854b06e486bc34b4ba619e344be85fb 1323 1322 2014-08-31T15:17:05Z Kpwg 721 /* HD44780 Punktmatrixdisplays */ wikitext text/x-wiki {{i18n|Nutzung in FHEM}} [http://www.fhemwiki.de/wiki/Hauptseite FHEM] ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um diverse per Funk und Kabel angebundene Komponenten aus dem Bereich der Hausautomation zu steuern. Er ist lizensiert unter der GPL v2. Das [http://www.pollin.de/shop/suchergebnis.html?S_TEXT=810+058 AVR-Net-IO] von [http://www.pollin.de Pollin] mit [[Ethersex]] dient als [http://www.fhemwiki.de/wiki/AVR-NET-IO preisgünstiger Einstieg in die Hausautomatisierung]. Verwendbar ist aber auch jede andere Hardware, die von Ethersex unterstützt wird ([http://arduino.cc/en/pmwiki.php?n=Main/ArduinoBoardProMini Arduino], eigene Entwicklungen, etc.). Über [[ECMD]] lassen sich dabei theoretisch alle in [[Ethersex]] vorhandenen [[ECMD_Protocols_%28Deutsch%29 | Möglichkeiten]] nutzen, sofern in FHEM entsprechende [http://fhem.de/commandref.html#ECMD ECMD-Devices] definiert und eingebunden werden. == Grundlagen == Ausgehend von einem fertigen und per Telnet erreichbaren Ethersex muss in FHEM zuerst das entsprechende Device definiert werden. <pre> define NETIO_WZ ECMD telnet 192.168.3.81:2701 </pre> Eine serielle Anbindung kann mit ''define <name> ECMD serial <SerialDevice>[<@BaudRate>]'' alternativ erfolgen. Anschließend werden die erstellten .classdef-Konfigurationsdateien der einzelnen Funktionen dem System bekannt gemacht. In diesen .classdef-Dateien (Name und Endung sind frei wählbar!) wird die Schnittstelle zwischen FHEM und ECMD/Ethersex definiert. Dabei können mit perl übergebene Parameter und empfangene Daten bearbeitet sowie die in FHEM gebräuchlichen Readings erstellt werden. <pre> attr NETIO_WZ classdefs RFM12_2272=/opt/fhem/FHEM/rfm12_2272.classdef:RFM12_IT=/opt/fhem/FHEM/rfm12_it.classdef:LCD=/opt/fhem/FHEM/lcd.classdef:DHT22=/opt/fhem/FHEM/dht22.classdef:1WIRE=/opt/fhem/FHEM/1wire.classdef </pre> Die Definitionen für IC2272, Intertechno, HD44780-LCD, DHT22 und 1wire sind nun eingebunden. In den folgenden Abschnitten wird auf die einzelnen Devices näher eingegangen. Generell sind Pfade und IP-Adressen sowie übergebene Parameter noch entsprechend der eigenen Konfiguration anzupassen. == [[Onewire_(Deutsch) | 1-Wire Temperatursensoren]] == [[File:DS18B20.jpg|150px|thumb|right|DS18B20-Sensoren]] Die 1wire-Temperatursensoren DS18B20 oder DS18S20 werden im [[Onewire_(Deutsch)#Polling_Modus | Polling Modus]] abgefragt. Das macht die zyklische Abfrage aus FHEM heraus wesentlich einfacher. Eine Polling-Zeit von mindestens 30 Sekunden ist absolut ausreichend.Im Vorfeld sollte man sich die [[Onewire_(Deutsch)#Benennung_von_Sensoren | ROM-Codes der Sensoren]] notieren, da diese nachher benötigt werden. 1w-temp.classdef erstellen: <source lang="perl"> # Uebergabeparameter Onewire Rom-Code params devID # Umsetzung in ECMD Befehle 1w get = Temperatur auslesen get 1W cmd {"1w get %devID\n"} get 1W expect "\d+.\d\n" get 1W postproc {\ s/\n//g;\ my $hash = $defs{%NAME};\ my $temperature = $_;\ my $state = "T: $temperature";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die classdef wird eingebunden: <pre> define NETIO_KU ECMD telnet 192.168.3.82:2701 attr NETIO_KU classdefs 1W-TEMP=/opt/fhem/FHEM/1w-temp.classdef </pre> Die Sensoren werden anhand des ROM-Code definiert: <pre> define HZ_WW ECMDDevice 1W-TEMP 284c8820050003d4 attr HZ_WW IODev NETIO_KU define HZ_VL ECMDDevice 1W-TEMP 2890a520050003d7 attr HZ_VL IODev NETIO_KU </pre> Eine zyklische Messung pro Minute lässt sich in dieser Form auslösen: <pre> define Messung_1w at +*00:01 get HZ_WW 1W;; get HZ_VL 1W attr Messung_1w verbose 1 </pre> == [[DHT|DHT22 Temperatur-/Feuchtesensoren]] == [[File:DHT22.jpg|150px|thumb|right|DHT22-Sensoren]] [[Ethersex]] unterstützt die preiswerten Temperatur-/Feuchtesensoren [[DHT|DHT11 und DHT22]], wobei letztere [[DHT#DHT11_vs_DHT22|um einiges genauer sind]]. Die Sensoren benötigen 5V Betriebsspannung und kommunizieren über je einen Pin mit dem Prozessor. Der Preis pro Stück liegt derzeit bei etwa 3.50 Euro (ebay/China). Wer die Trägheit und Ungenauigkeit der S300TH oder TX29DTH kennt, wünscht sich vermutlich Besseres; vor allem bei Berechnung von [http://de.wikipedia.org/wiki/Taupunkt Taupunkt] und [http://de.wikipedia.org/wiki/Luftfeuchtigkeit#Absolute_Luftfeuchtigkeit absoluter Feuchte], welche von der Genauigkeit der gemessenen Eingangsgrößen sehr profitieren. Berechnungen von Hand kann man beim [http://www.wetterochs.de/wetter/feuchte.html Wetterochs] durchführen. Die automatische Berechnung der absoluten Feuchte in FHEM wird im [http://forum.fhem.de/index.php/topic,21458.0.html Forum] erklärt. '''Einbindung in FHEM''' dht22m.classdef erstellen: <source lang="perl"> # Uebergabeparameter DHT22 ID 0...n params devID # Umsetzung in ECMD Befehle fuer DHT22 get DHT cmd {"dht temp %devID\n\000dht humid %devID\n"} get DHT expect "\d+.\d\n" get DHT postproc {\ s/(.*)\n(.*)\n/T: $1 H: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1;\ my $humidity = $2;\ my $state = $_;\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "humidity", $humidity, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs DHT22M=/opt/fhem/FHEM/dht22m.classdef </pre> Die Sensoren werden definiert: <pre> define Test0 ECMDDevice DHT22M 0 attr Test0 IODev NETIO_TEST define Test1 ECMDDevice DHT22M 1 attr Test1 IODev NETIO_TEST define Test2 ECMDDevice DHT22M 2 attr Test2 IODev NETIO_TEST define Test3 ECMDDevice DHT22M 3 attr Test3 IODev NETIO_TEST </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_DHT at +*00:04 get Test0 DHT;; get Test1 DHT;; get Test2 DHT;; get Test3 DHT attr Messung_DHT verbose 0 </pre> Fünfzehn Messwerte pro Stunde genügen den allermeisten Anforderungen. == [[BMP085 | BMP085/BMP180 Luftdrucksensor]] == [[File:BMP180.jpg|150px|thumb|right|BMP180 (unten links)]] Ethersex unterstützt den BMP085 (bzw. den BMP180; der Code ist identisch) über das [[I2C_(Deutsch) | I2C]]-Interface. Da der Sensor für 3.3V Betriebsspannung ausgelegt ist, muss entweder der I2C-Pegel angepasst oder der ATMega auf 3.3V adaptiert werden. Weiterhin sollte die Höhe über Null bekannt sein. Beispiel: Eine Abfrage per [[ECMD]] mit ''bmp085 pressnn 59000'' bedeutet, das ich 590m (59000cm) über NN wohne. Die im Sensor verfügbare Temperatur wird parallel ausgelesen. '''Einbindung in FHEM''' bmp085.classdef erstellen: <source lang="perl"> get BMP cmd {"bmp085 temp\n\000bmp085 pressnn 59000\n"} get BMP expect ".*" get BMP postproc {\ s/(.*)\n(.*)\n/T: $1 P: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1/10;\ my $pressure = sprintf("%.1f",$2/100);\ my $state = "T: $temperature P: $pressure";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "pressure", $pressure, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die Temperatur wird in °C mit einer Nachkommastelle gelesen, der Luftdruck in hPa bzw. mbar auf eine Nachkommastelle gerundet. Passende Readings werden erstellt. Das expect .* kann noch angepasst werden, um bei fehlerhaften Messwerten entsprechend zu reagieren. Die classdef wird in FHEM eingebunden (mehrere .classdef mit Doppelpunkt trennen: siehe [[Nutzung_in_FHEM_(Deutsch)#Grundlagen | Grundlagen]]): <pre> define NETIO_STK ECMD telnet 192.168.3.89:2701 attr NETIO_STK classdefs BMP=/opt/fhem/FHEM/bmp085.classdef </pre> Der Sensor wird definiert: <pre> define BMP180 ECMDDevice BMP attr BMP180 IODev NETIO_STK </pre> Das STATE ''kann'' mit Maßeinheiten versehen werden: <pre> attr BMP180 stateFormat { sprintf("%s°C %shPa", ReadingsVal("BMP180","temperature",0), ReadingsVal("BMP180","pressure",0)) ;; } </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_BMP at +*00:04 get BMP180 BMP attr Messung_BMP verbose 0 </pre> Dabei unterdrückt verbose 0 einen zusätzlichen (doppelten) Logeintrag des Messvorganges. == analoge Eingänge == todo == [[Porterweiterungen_%28Deutsch%29#D.2FA-Wandler_mit_LTC1257 | LTC1257 D/A-Wandler]] == todo == HD44780 Punktmatrixdisplays == [[File:HD44780.jpg|150px|thumb|right|verschiedene HD44780 Displays (16x1 bis 40x4)]] Die beliebten Punktmatrix-Displays auf Basis [http://de.wikipedia.org/wiki/HD44780 HD44780] können vollumfänglich in FHEM beschrieben werden. Dabei wird vorrausgesetzt, das in [https://github.com/ethersex/ethersex/blob/master/hardware/lcd/hd44780.h /hardware/lcd/hd44780.h] die passende Adressierung der Zeilen und die genutzte Zeilen-/Spaltenzahl vor dem Compilieren angepasst wurde. '''Einbindung in FHEM''' lcd.classdef erstellen: <source lang="perl"> # Umsetzung der ECMD Befehle set write params line col text set write cmd {"lcd goto %line %col\n\000lcd write %text\n"} set write expect "OK\n" set write postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set clear params col set clear cmd {"lcd clear %col\n"} set clear expect "OK\n" set clear postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set clear_all cmd {"lcd clear\n"} set clear_all expect "OK\n" set clear_all postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set lcd_bl params state set lcd_bl cmd {"lcd backlight %state\n"} set lcd_bl expect "OK\n" set lcd_bl postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} </source> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs LCD=/opt/fhem/FHEM/lcd.classdef </pre> Das Display wird definiert: <pre> define WZ_LCD ECMDDevice LCD attr WZ_LCD IODev NETIO_TEST </pre> Es stehen in FHEM folgende Befehle für das LCD bereit: {| border='1' | ''Befehl'' | ''Funktion'' |- | set WZ_LCD clear [ZEILE] | löscht den Inhalt einer ZEILE (0...3) |- | set WZ_LCD clear_all | löscht den Inhalt aller Zeilen |- | set WZ_LCD lcd_bl STATE | schaltet die Hintergrundbeleuchtung ein oder aus (STATE on oder off) |- | set WZ_LCD write [ZEILE] [SPALTE] [TEXT] | schreibt einen TEXT auf Position ZEILE SPALTE (0...n) |- |} Da ein im TEXT übergebenes Leerzeichen als weiterer Befehl interpretiert wird und zu einer Fehlermeldung führt, ist eine Übergabe nur mit \x20 im Text möglich. Das gilt auch für Umlaute. Anhand der [http://de.wikipedia.org/wiki/HD44780#Schrift_und_Zeichensatz Zeichensatztabelle] lassen sich ä durch \xE1, ü durch \xF5 und ö durch \xEF darstellen. Das ß wird mit \xE2 erreicht. Die Tabelle kann für manche Displays abweichend sein.<br /> Beispiel: ''set WZ_LCD write 0 0 Fenster\x20schlie\xE2en'' schreibt ein '''Fenster schließen''' auf's LCD. '''Komfortable Nutzung in FHEM mit DLCD''' Mit dem DLCD-Modul ([http://www.fhemwiki.de/wiki/DLCD Wiki-Beitrag] / [http://forum.fhem.de/index.php/topic,24519.0.html Foren-Beitrag]) für FHEM lässt sich jedes Display auf einfache Weise beschreiben. Dabei lassen sich bequem Readings von allen Devices nutzen, aufbereiten (formatieren, umrechnen, etc.) und entsprechend darstellen. Eine genaue Beschreibung hält der Wiki-Beitrag bereit; hier soll ein Beispiel gezeigt werden. Ziel war es, auf einem 16x1 LCD wechselweise ''Datum/Zeit => Klimadaten Keller => Datum/Zeit => Klimadaten Garten'' darzustellen. Die Anzeige rotiert im 15-Sekunden-Takt, so das zu 50% Datum/Zeit und je 25% die Werte aus dem Garten und dem Keller angezeigt werden. Es wird bereits im Modul jedes Leerzeichen mit \x20 übersetzt. Der Außensensor ist ein [http://www.elv.de/elv-funk-kombi-wettersensor-ks-300-2-br-inkl-hochwertigem-2-m-edelstahlmast-br-und-qualitaetsbatterien.html KS300] (bzw. KS200) von ELV. Mit etwas Formatierung und ein paar Leerzeichen lässt sich eine stets gleiche Positionierung der Daten erreichen, da die Zeile nicht explizit gelöscht wird. Auszug aus der fhem.cfg: <pre> define DLCD_WZ DLCD attr DLCD_WZ dlcdBlankspaceReplace \x20 attr DLCD_WZ dlcdCols 16 attr DLCD_WZ dlcdLine1 %date_WD_ger% %date_D%.%date_M_ger% %time_h%:%time_m% attr DLCD_WZ dlcdLine2 Keller:%1%/%2% attr DLCD_WZ dlcdLine3 %date_WD_ger% %date_D%.%date_M_ger% %time_h%:%time_m% attr DLCD_WZ dlcdLine4 Garten: %3%/%4% attr DLCD_WZ dlcdPhysicalRows 1 attr DLCD_WZ dlcdPollInterval 15 attr DLCD_WZ dlcdRows 4 attr DLCD_WZ dlcdScrolling 1 attr DLCD_WZ dlcdTriggerCmd set WZ_LCD write %L% 0 %T% attr DLCD_WZ dlcdVal1 Keller:temperature attr DLCD_WZ dlcdVal1formatnum 3+1 attr DLCD_WZ dlcdVal2 Keller:humidity attr DLCD_WZ dlcdVal2formatnum 3+1 attr DLCD_WZ dlcdVal3 KS300:temperature attr DLCD_WZ dlcdVal3formatnum 3+1+- attr DLCD_WZ dlcdVal4 KS300:humidity attr DLCD_WZ dlcdVal4formatnum 2+0 </pre> Das Ergebnis kann so aussehen: <gallery> DLCD_1.jpg|Zustand 0-14 Sekunden DLCD_2.jpg|Zustand 15-29 Sekunden DLCD_3.jpg|Zustand 30-44 Sekunden DLCD_4.jpg|Zustand 45-59 Sekunden </gallery> == [[RFM12_ASK_(Deutsch) | Intertechno schalten mit RFM12]] == todo == [[RFM12_ASK_(Deutsch) | IC2272 schalten mit RFM12]] == todo [[Category:Application|Application]] 65d907c4c57ffa559b67c298e18cbc1c86cbfc50 1325 1323 2014-09-13T10:40:45Z Kpwg 721 /* HD44780 Punktmatrixdisplays */ wikitext text/x-wiki {{i18n|Nutzung in FHEM}} [http://www.fhemwiki.de/wiki/Hauptseite FHEM] ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um diverse per Funk und Kabel angebundene Komponenten aus dem Bereich der Hausautomation zu steuern. Er ist lizensiert unter der GPL v2. Das [http://www.pollin.de/shop/suchergebnis.html?S_TEXT=810+058 AVR-Net-IO] von [http://www.pollin.de Pollin] mit [[Ethersex]] dient als [http://www.fhemwiki.de/wiki/AVR-NET-IO preisgünstiger Einstieg in die Hausautomatisierung]. Verwendbar ist aber auch jede andere Hardware, die von Ethersex unterstützt wird ([http://arduino.cc/en/pmwiki.php?n=Main/ArduinoBoardProMini Arduino], eigene Entwicklungen, etc.). Über [[ECMD]] lassen sich dabei theoretisch alle in [[Ethersex]] vorhandenen [[ECMD_Protocols_%28Deutsch%29 | Möglichkeiten]] nutzen, sofern in FHEM entsprechende [http://fhem.de/commandref.html#ECMD ECMD-Devices] definiert und eingebunden werden. == Grundlagen == Ausgehend von einem fertigen und per Telnet erreichbaren Ethersex muss in FHEM zuerst das entsprechende Device definiert werden. <pre> define NETIO_WZ ECMD telnet 192.168.3.81:2701 </pre> Eine serielle Anbindung kann mit ''define <name> ECMD serial <SerialDevice>[<@BaudRate>]'' alternativ erfolgen. Anschließend werden die erstellten .classdef-Konfigurationsdateien der einzelnen Funktionen dem System bekannt gemacht. In diesen .classdef-Dateien (Name und Endung sind frei wählbar!) wird die Schnittstelle zwischen FHEM und ECMD/Ethersex definiert. Dabei können mit perl übergebene Parameter und empfangene Daten bearbeitet sowie die in FHEM gebräuchlichen Readings erstellt werden. <pre> attr NETIO_WZ classdefs RFM12_2272=/opt/fhem/FHEM/rfm12_2272.classdef:RFM12_IT=/opt/fhem/FHEM/rfm12_it.classdef:LCD=/opt/fhem/FHEM/lcd.classdef:DHT22=/opt/fhem/FHEM/dht22.classdef:1WIRE=/opt/fhem/FHEM/1wire.classdef </pre> Die Definitionen für IC2272, Intertechno, HD44780-LCD, DHT22 und 1wire sind nun eingebunden. In den folgenden Abschnitten wird auf die einzelnen Devices näher eingegangen. Generell sind Pfade und IP-Adressen sowie übergebene Parameter noch entsprechend der eigenen Konfiguration anzupassen. == [[Onewire_(Deutsch) | 1-Wire Temperatursensoren]] == [[File:DS18B20.jpg|150px|thumb|right|DS18B20-Sensoren]] Die 1wire-Temperatursensoren DS18B20 oder DS18S20 werden im [[Onewire_(Deutsch)#Polling_Modus | Polling Modus]] abgefragt. Das macht die zyklische Abfrage aus FHEM heraus wesentlich einfacher. Eine Polling-Zeit von mindestens 30 Sekunden ist absolut ausreichend.Im Vorfeld sollte man sich die [[Onewire_(Deutsch)#Benennung_von_Sensoren | ROM-Codes der Sensoren]] notieren, da diese nachher benötigt werden. 1w-temp.classdef erstellen: <source lang="perl"> # Uebergabeparameter Onewire Rom-Code params devID # Umsetzung in ECMD Befehle 1w get = Temperatur auslesen get 1W cmd {"1w get %devID\n"} get 1W expect "\d+.\d\n" get 1W postproc {\ s/\n//g;\ my $hash = $defs{%NAME};\ my $temperature = $_;\ my $state = "T: $temperature";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die classdef wird eingebunden: <pre> define NETIO_KU ECMD telnet 192.168.3.82:2701 attr NETIO_KU classdefs 1W-TEMP=/opt/fhem/FHEM/1w-temp.classdef </pre> Die Sensoren werden anhand des ROM-Code definiert: <pre> define HZ_WW ECMDDevice 1W-TEMP 284c8820050003d4 attr HZ_WW IODev NETIO_KU define HZ_VL ECMDDevice 1W-TEMP 2890a520050003d7 attr HZ_VL IODev NETIO_KU </pre> Eine zyklische Messung pro Minute lässt sich in dieser Form auslösen: <pre> define Messung_1w at +*00:01 get HZ_WW 1W;; get HZ_VL 1W attr Messung_1w verbose 1 </pre> == [[DHT|DHT22 Temperatur-/Feuchtesensoren]] == [[File:DHT22.jpg|150px|thumb|right|DHT22-Sensoren]] [[Ethersex]] unterstützt die preiswerten Temperatur-/Feuchtesensoren [[DHT|DHT11 und DHT22]], wobei letztere [[DHT#DHT11_vs_DHT22|um einiges genauer sind]]. Die Sensoren benötigen 5V Betriebsspannung und kommunizieren über je einen Pin mit dem Prozessor. Der Preis pro Stück liegt derzeit bei etwa 3.50 Euro (ebay/China). Wer die Trägheit und Ungenauigkeit der S300TH oder TX29DTH kennt, wünscht sich vermutlich Besseres; vor allem bei Berechnung von [http://de.wikipedia.org/wiki/Taupunkt Taupunkt] und [http://de.wikipedia.org/wiki/Luftfeuchtigkeit#Absolute_Luftfeuchtigkeit absoluter Feuchte], welche von der Genauigkeit der gemessenen Eingangsgrößen sehr profitieren. Berechnungen von Hand kann man beim [http://www.wetterochs.de/wetter/feuchte.html Wetterochs] durchführen. Die automatische Berechnung der absoluten Feuchte in FHEM wird im [http://forum.fhem.de/index.php/topic,21458.0.html Forum] erklärt. '''Einbindung in FHEM''' dht22m.classdef erstellen: <source lang="perl"> # Uebergabeparameter DHT22 ID 0...n params devID # Umsetzung in ECMD Befehle fuer DHT22 get DHT cmd {"dht temp %devID\n\000dht humid %devID\n"} get DHT expect "\d+.\d\n" get DHT postproc {\ s/(.*)\n(.*)\n/T: $1 H: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1;\ my $humidity = $2;\ my $state = $_;\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "humidity", $humidity, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs DHT22M=/opt/fhem/FHEM/dht22m.classdef </pre> Die Sensoren werden definiert: <pre> define Test0 ECMDDevice DHT22M 0 attr Test0 IODev NETIO_TEST define Test1 ECMDDevice DHT22M 1 attr Test1 IODev NETIO_TEST define Test2 ECMDDevice DHT22M 2 attr Test2 IODev NETIO_TEST define Test3 ECMDDevice DHT22M 3 attr Test3 IODev NETIO_TEST </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_DHT at +*00:04 get Test0 DHT;; get Test1 DHT;; get Test2 DHT;; get Test3 DHT attr Messung_DHT verbose 0 </pre> Fünfzehn Messwerte pro Stunde genügen den allermeisten Anforderungen. == [[BMP085 | BMP085/BMP180 Luftdrucksensor]] == [[File:BMP180.jpg|150px|thumb|right|BMP180 (unten links)]] Ethersex unterstützt den BMP085 (bzw. den BMP180; der Code ist identisch) über das [[I2C_(Deutsch) | I2C]]-Interface. Da der Sensor für 3.3V Betriebsspannung ausgelegt ist, muss entweder der I2C-Pegel angepasst oder der ATMega auf 3.3V adaptiert werden. Weiterhin sollte die Höhe über Null bekannt sein. Beispiel: Eine Abfrage per [[ECMD]] mit ''bmp085 pressnn 59000'' bedeutet, das ich 590m (59000cm) über NN wohne. Die im Sensor verfügbare Temperatur wird parallel ausgelesen. '''Einbindung in FHEM''' bmp085.classdef erstellen: <source lang="perl"> get BMP cmd {"bmp085 temp\n\000bmp085 pressnn 59000\n"} get BMP expect ".*" get BMP postproc {\ s/(.*)\n(.*)\n/T: $1 P: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1/10;\ my $pressure = sprintf("%.1f",$2/100);\ my $state = "T: $temperature P: $pressure";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "pressure", $pressure, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die Temperatur wird in °C mit einer Nachkommastelle gelesen, der Luftdruck in hPa bzw. mbar auf eine Nachkommastelle gerundet. Passende Readings werden erstellt. Das expect .* kann noch angepasst werden, um bei fehlerhaften Messwerten entsprechend zu reagieren. Die classdef wird in FHEM eingebunden (mehrere .classdef mit Doppelpunkt trennen: siehe [[Nutzung_in_FHEM_(Deutsch)#Grundlagen | Grundlagen]]): <pre> define NETIO_STK ECMD telnet 192.168.3.89:2701 attr NETIO_STK classdefs BMP=/opt/fhem/FHEM/bmp085.classdef </pre> Der Sensor wird definiert: <pre> define BMP180 ECMDDevice BMP attr BMP180 IODev NETIO_STK </pre> Das STATE ''kann'' mit Maßeinheiten versehen werden: <pre> attr BMP180 stateFormat { sprintf("%s°C %shPa", ReadingsVal("BMP180","temperature",0), ReadingsVal("BMP180","pressure",0)) ;; } </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_BMP at +*00:04 get BMP180 BMP attr Messung_BMP verbose 0 </pre> Dabei unterdrückt verbose 0 einen zusätzlichen (doppelten) Logeintrag des Messvorganges. == analoge Eingänge == todo == [[Porterweiterungen_%28Deutsch%29#D.2FA-Wandler_mit_LTC1257 | LTC1257 D/A-Wandler]] == todo == HD44780 Punktmatrixdisplays == [[File:HD44780.jpg|150px|thumb|right|verschiedene HD44780 Displays (16x1 bis 40x4)]] Die beliebten Punktmatrix-Displays auf Basis [http://de.wikipedia.org/wiki/HD44780 HD44780] können vollumfänglich in FHEM beschrieben werden. Dabei wird vorrausgesetzt, das in [https://github.com/ethersex/ethersex/blob/master/hardware/lcd/hd44780.h /hardware/lcd/hd44780.h] beim entsprechenden Modell die passende Adressierung der Zeilen und die genutzte Zeilen-/Spaltenzahl vor dem Compilieren angepasst wurde. '''Einbindung in FHEM''' lcd.classdef erstellen: <source lang="perl"> # Umsetzung der ECMD Befehle set write params line col text set write cmd {"lcd goto %line %col\n\000lcd write %text\n"} set write expect "OK\n" set write postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set clear params col set clear cmd {"lcd clear %col\n"} set clear expect "OK\n" set clear postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set clear_all cmd {"lcd clear\n"} set clear_all expect "OK\n" set clear_all postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set lcd_bl params state set lcd_bl cmd {"lcd backlight %state\n"} set lcd_bl expect "OK\n" set lcd_bl postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} </source> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs LCD=/opt/fhem/FHEM/lcd.classdef </pre> Das Display wird definiert: <pre> define WZ_LCD ECMDDevice LCD attr WZ_LCD IODev NETIO_TEST </pre> Es stehen in FHEM folgende Befehle für das LCD bereit: {| border='1' | ''Befehl'' | ''Funktion'' |- | set WZ_LCD clear [ZEILE] | löscht den Inhalt einer ZEILE (0...3) |- | set WZ_LCD clear_all | löscht den Inhalt aller Zeilen |- | set WZ_LCD lcd_bl STATE | schaltet die Hintergrundbeleuchtung ein oder aus (STATE on oder off) |- | set WZ_LCD write [ZEILE] [SPALTE] [TEXT] | schreibt einen TEXT auf Position ZEILE SPALTE (0...n) |- |} Da ein im TEXT übergebenes Leerzeichen als weiterer Befehl interpretiert wird und zu einer Fehlermeldung führt, ist eine Übergabe nur mit \x20 im Text möglich. Das gilt auch für Umlaute. Anhand der [http://de.wikipedia.org/wiki/HD44780#Schrift_und_Zeichensatz Zeichensatztabelle] lassen sich ä durch \xE1, ü durch \xF5 und ö durch \xEF darstellen. Das ß wird mit \xE2 erreicht. Die Tabelle kann für manche Displays abweichend sein.<br /> Beispiel: ''set WZ_LCD write 0 0 Fenster\x20schlie\xE2en'' schreibt ein '''Fenster schließen''' auf's LCD. '''Komfortable Nutzung in FHEM mit DLCD''' Mit dem DLCD-Modul ([http://www.fhemwiki.de/wiki/DLCD Wiki-Beitrag] / [http://forum.fhem.de/index.php/topic,24519.0.html Foren-Beitrag]) für FHEM lässt sich jedes Display auf einfache Weise beschreiben. Dabei lassen sich bequem Readings von allen Devices nutzen, aufbereiten (formatieren, umrechnen, etc.) und entsprechend darstellen. Eine genaue Beschreibung hält der Wiki-Beitrag bereit; hier soll ein Beispiel gezeigt werden. Ziel war es, auf einem 16x1 LCD wechselweise ''Datum/Zeit => Klimadaten Keller => Datum/Zeit => Klimadaten Garten'' darzustellen. Die Anzeige rotiert im 15-Sekunden-Takt, so das zu 50% Datum/Zeit und je 25% die Werte aus dem Garten und dem Keller angezeigt werden. Es wird bereits im Modul jedes Leerzeichen mit \x20 übersetzt. Der Außensensor ist ein [http://www.elv.de/elv-funk-kombi-wettersensor-ks-300-2-br-inkl-hochwertigem-2-m-edelstahlmast-br-und-qualitaetsbatterien.html KS300] (bzw. KS200) von ELV. Mit etwas Formatierung und ein paar Leerzeichen lässt sich eine stets gleiche Positionierung der Daten erreichen, da die Zeile nicht explizit gelöscht wird. Auszug aus der fhem.cfg: <pre> define DLCD_WZ DLCD attr DLCD_WZ dlcdBlankspaceReplace \x20 attr DLCD_WZ dlcdCols 16 attr DLCD_WZ dlcdLine1 %date_WD_ger% %date_D%.%date_M_ger% %time_h%:%time_m% attr DLCD_WZ dlcdLine2 Keller:%1%/%2% attr DLCD_WZ dlcdLine3 %date_WD_ger% %date_D%.%date_M_ger% %time_h%:%time_m% attr DLCD_WZ dlcdLine4 Garten: %3%/%4% attr DLCD_WZ dlcdPhysicalRows 1 attr DLCD_WZ dlcdPollInterval 15 attr DLCD_WZ dlcdRows 4 attr DLCD_WZ dlcdScrolling 1 attr DLCD_WZ dlcdTriggerCmd set WZ_LCD write %L% 0 %T% attr DLCD_WZ dlcdVal1 Keller:temperature attr DLCD_WZ dlcdVal1formatnum 3+1 attr DLCD_WZ dlcdVal2 Keller:humidity attr DLCD_WZ dlcdVal2formatnum 3+1 attr DLCD_WZ dlcdVal3 KS300:temperature attr DLCD_WZ dlcdVal3formatnum 3+1+- attr DLCD_WZ dlcdVal4 KS300:humidity attr DLCD_WZ dlcdVal4formatnum 2+0 </pre> Das Ergebnis kann so aussehen: <gallery> DLCD_1.jpg|Zustand 1.-15. Sekunde DLCD_2.jpg|Zustand 16.-30. Sekunde DLCD_3.jpg|Zustand 31.-45. Sekunde DLCD_4.jpg|Zustand 46.-60. Sekunde </gallery> Die Formatierung bewirkt eine immer identische Platzierung der Daten. Der Außensensor hat keine Zehntelwerte bei der Feuchte, muss dafür aber negative Temperaturen darstellen. Der Innensensor zeigt Zehntelwerte, womit sich Tendenzen eher erkennen lassen. == [[RFM12_ASK_(Deutsch) | Intertechno schalten mit RFM12]] == todo == [[RFM12_ASK_(Deutsch) | IC2272 schalten mit RFM12]] == todo [[Category:Application|Application]] 2897c6d79cef633993b7a7e68975a19465f0a44c 1335 1325 2014-10-05T17:00:55Z Kpwg 721 wikitext text/x-wiki {{i18n|Nutzung in FHEM}} [http://www.fhemwiki.de/wiki/Hauptseite FHEM] ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um diverse per Funk und Kabel angebundene Komponenten aus dem Bereich der Hausautomation zu steuern. Er ist lizensiert unter der GPL v2. Das [http://www.pollin.de/shop/suchergebnis.html?S_TEXT=810+058 AVR-Net-IO] von [http://www.pollin.de Pollin] mit [[Ethersex]] dient als [http://www.fhemwiki.de/wiki/AVR-NET-IO preisgünstiger Einstieg in die Hausautomatisierung]. Verwendbar ist aber auch jede andere Hardware, die von Ethersex unterstützt wird ([http://arduino.cc/en/pmwiki.php?n=Main/ArduinoBoardProMini Arduino], eigene Entwicklungen, etc.). Über [[ECMD]] lassen sich dabei theoretisch alle in [[Ethersex]] vorhandenen [[ECMD_Protocols_%28Deutsch%29 | Möglichkeiten]] nutzen, sofern in FHEM entsprechende [http://fhem.de/commandref.html#ECMD ECMD-Devices] definiert und eingebunden werden. == Grundlagen == Ausgehend von einem fertigen und per Telnet erreichbaren Ethersex muss in FHEM zuerst das entsprechende Device definiert werden. <pre> define NETIO_WZ ECMD telnet 192.168.3.81:2701 </pre> Eine serielle Anbindung kann mit ''define <name> ECMD serial <SerialDevice>[<@BaudRate>]'' alternativ erfolgen. Anschließend werden die erstellten .classdef-Konfigurationsdateien der einzelnen Funktionen dem System bekannt gemacht. In diesen .classdef-Dateien (Name und Endung sind frei wählbar!) wird die Schnittstelle zwischen FHEM und ECMD/Ethersex definiert. Dabei können mit perl übergebene Parameter und empfangene Daten bearbeitet sowie die in FHEM gebräuchlichen Readings erstellt werden. <pre> attr NETIO_WZ classdefs RFM12_2272=/opt/fhem/FHEM/rfm12_2272.classdef:RFM12_IT=/opt/fhem/FHEM/rfm12_it.classdef:LCD=/opt/fhem/FHEM/lcd.classdef:DHT22=/opt/fhem/FHEM/dht22.classdef:1WIRE=/opt/fhem/FHEM/1wire.classdef </pre> Die Definitionen für IC2272, Intertechno, HD44780-LCD, DHT22 und 1wire sind nun eingebunden. In den folgenden Abschnitten wird auf die einzelnen Devices näher eingegangen. Generell sind Pfade und IP-Adressen sowie übergebene Parameter noch entsprechend der eigenen Konfiguration anzupassen. == [[Onewire_(Deutsch) | 1-Wire Temperatursensoren]] == [[File:DS18B20.jpg|150px|thumb|right|DS18B20-Sensoren]] Die 1wire-Temperatursensoren DS18B20 oder DS18S20 werden im [[Onewire_(Deutsch)#Polling_Modus | Polling Modus]] abgefragt. Das macht die zyklische Abfrage aus FHEM heraus wesentlich einfacher. Eine Polling-Zeit von mindestens 30 Sekunden ist absolut ausreichend.Im Vorfeld sollte man sich die [[Onewire_(Deutsch)#Benennung_von_Sensoren | ROM-Codes der Sensoren]] notieren, da diese nachher benötigt werden. 1w-temp.classdef erstellen: <source lang="perl"> # Uebergabeparameter Onewire Rom-Code params devID # Umsetzung in ECMD Befehle 1w get = Temperatur auslesen get 1W cmd {"1w get %devID\n"} get 1W expect "\d+.\d\n" get 1W postproc {\ s/\n//g;\ my $hash = $defs{%NAME};\ my $temperature = $_;\ my $state = "T: $temperature";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die classdef wird eingebunden: <pre> define NETIO_KU ECMD telnet 192.168.3.82:2701 attr NETIO_KU classdefs 1W-TEMP=/opt/fhem/FHEM/1w-temp.classdef </pre> Die Sensoren werden anhand des ROM-Code definiert: <pre> define HZ_WW ECMDDevice 1W-TEMP 284c8820050003d4 attr HZ_WW IODev NETIO_KU define HZ_VL ECMDDevice 1W-TEMP 2890a520050003d7 attr HZ_VL IODev NETIO_KU </pre> Eine zyklische Messung pro Minute lässt sich in dieser Form auslösen: <pre> define Messung_1w at +*00:01 get HZ_WW 1W;; get HZ_VL 1W attr Messung_1w verbose 1 </pre> == [[DHT|DHT22 Temperatur-/Feuchtesensoren]] == [[File:DHT22.jpg|150px|thumb|right|DHT22-Sensoren]] [[Ethersex]] unterstützt die preiswerten Temperatur-/Feuchtesensoren [[DHT|DHT11 und DHT22]], wobei letztere [[DHT#DHT11_vs_DHT22|um einiges genauer sind]]. Die Sensoren benötigen 5V Betriebsspannung und kommunizieren über je einen Pin mit dem Prozessor. Der Preis pro Stück liegt derzeit bei etwa 3.50 Euro (ebay/China). Wer die Trägheit und Ungenauigkeit der S300TH oder TX29DTH kennt, wünscht sich vermutlich Besseres; vor allem bei Berechnung von [http://de.wikipedia.org/wiki/Taupunkt Taupunkt] und [http://de.wikipedia.org/wiki/Luftfeuchtigkeit#Absolute_Luftfeuchtigkeit absoluter Feuchte], welche von der Genauigkeit der gemessenen Eingangsgrößen sehr profitieren. Berechnungen von Hand kann man beim [http://www.wetterochs.de/wetter/feuchte.html Wetterochs] durchführen. Die automatische Berechnung der absoluten Feuchte in FHEM wird im [http://forum.fhem.de/index.php/topic,21458.0.html Forum] erklärt. '''Einbindung in FHEM''' dht22m.classdef erstellen: <source lang="perl"> # Uebergabeparameter DHT22 ID 0...n params devID # Umsetzung in ECMD Befehle fuer DHT22 get DHT cmd {"dht temp %devID\n\000dht humid %devID\n"} get DHT expect "\d+.\d\n" get DHT postproc {\ s/(.*)\n(.*)\n/T: $1 H: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1;\ my $humidity = $2;\ my $state = $_;\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "humidity", $humidity, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs DHT22M=/opt/fhem/FHEM/dht22m.classdef </pre> Die Sensoren werden definiert: <pre> define Test0 ECMDDevice DHT22M 0 attr Test0 IODev NETIO_TEST define Test1 ECMDDevice DHT22M 1 attr Test1 IODev NETIO_TEST define Test2 ECMDDevice DHT22M 2 attr Test2 IODev NETIO_TEST define Test3 ECMDDevice DHT22M 3 attr Test3 IODev NETIO_TEST </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_DHT at +*00:04 get Test0 DHT;; get Test1 DHT;; get Test2 DHT;; get Test3 DHT attr Messung_DHT verbose 0 </pre> Fünfzehn Messwerte pro Stunde genügen den allermeisten Anforderungen. == [[BMP085 | BMP085/BMP180 Luftdrucksensor]] == [[File:BMP180.jpg|150px|thumb|right|BMP180 (unten links)]] Ethersex unterstützt den BMP085 (bzw. den BMP180; der Code ist identisch) über das [[I2C_(Deutsch) | I2C]]-Interface. Da der Sensor für 3.3V Betriebsspannung ausgelegt ist, muss entweder der I2C-Pegel angepasst oder der ATMega auf 3.3V adaptiert werden. Weiterhin sollte die Höhe über Null bekannt sein. Beispiel: Eine Abfrage per [[ECMD]] mit ''bmp085 pressnn 59000'' bedeutet, das ich 590m (59000cm) über NN wohne. Die im Sensor verfügbare Temperatur wird parallel ausgelesen. '''Einbindung in FHEM''' bmp085.classdef erstellen: <source lang="perl"> get BMP cmd {"bmp085 temp\n\000bmp085 pressnn 59000\n"} get BMP expect ".*" get BMP postproc {\ s/(.*)\n(.*)\n/T: $1 P: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1/10;\ my $pressure = sprintf("%.1f",$2/100);\ my $state = "T: $temperature P: $pressure";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "pressure", $pressure, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die Temperatur wird in °C mit einer Nachkommastelle gelesen, der Luftdruck in hPa bzw. mbar auf eine Nachkommastelle gerundet. Passende Readings werden erstellt. Das expect .* kann noch angepasst werden, um bei fehlerhaften Messwerten entsprechend zu reagieren. Die classdef wird in FHEM eingebunden (mehrere .classdef mit Doppelpunkt trennen: siehe [[Nutzung_in_FHEM_(Deutsch)#Grundlagen | Grundlagen]]): <pre> define NETIO_STK ECMD telnet 192.168.3.89:2701 attr NETIO_STK classdefs BMP=/opt/fhem/FHEM/bmp085.classdef </pre> Der Sensor wird definiert: <pre> define BMP180 ECMDDevice BMP attr BMP180 IODev NETIO_STK </pre> Das STATE ''kann'' mit Maßeinheiten versehen werden: <pre> attr BMP180 stateFormat { sprintf("%s°C %shPa", ReadingsVal("BMP180","temperature",0), ReadingsVal("BMP180","pressure",0)) ;; } </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_BMP at +*00:04 get BMP180 BMP attr Messung_BMP verbose 0 </pre> Dabei unterdrückt verbose 0 einen zusätzlichen (doppelten) Logeintrag des Messvorganges. == analoge Eingänge == todo == digitale Eingänge - proaktiv == Kontakte, die bei Zustandsänderung sofort in FHEM eine Meldung generieren sollen, kann man nicht zeitnah mit Polling abfragen. Diese Ereignisse, welche auch aus einem Control6-Script heraus generiert sein können, sollen selbst Meldung machen. Hierbei wird die ESEND-Funktion benutzt, mit welcher auch mehrere Ethersex'e untereinander kommunizieren können. Dabei ist es nicht relevant, ob das Device in FHEM per ECMDDevice bereits eingebunden wurde. Zuerst muss FHEM auf Port 2701 für Telnet-Verbindungen empfänglich werden: <pre> define telnetECMD telnet 2701 global </pre> Mit ''Watch io changes and react'' lässt sich per menuconfig bereits auf einfache Weise eine Abfrage von Portpins mit Generierung eines ESEND-Befehles bewerkstelligen. Das Beispiel soll zeigen, wie bei entsprechender Zustandsänderung an Pin PA0 an 192.168.178.10 ein FHEM-Befehl gesendet wird: <pre> ECMDTCP(PA0, RISING, 192.168.178.10, set Lampe on\n\n) ECMDTCP(PA0, FALLING, 192.168.178.10, set Lampe off\n\n) </pre> Jede Sequenz muss mit \n\n abgeschlossen werden, damit FHEM für weitere Befehle empfangsbereit bleibt. == [[Porterweiterungen_%28Deutsch%29#D.2FA-Wandler_mit_LTC1257 | LTC1257 D/A-Wandler]] == todo == HD44780 Punktmatrixdisplays == [[File:HD44780.jpg|150px|thumb|right|verschiedene HD44780 Displays (16x1 bis 40x4)]] Die beliebten Punktmatrix-Displays auf Basis [http://de.wikipedia.org/wiki/HD44780 HD44780] können vollumfänglich in FHEM beschrieben werden. Dabei wird vorrausgesetzt, das in [https://github.com/ethersex/ethersex/blob/master/hardware/lcd/hd44780.h /hardware/lcd/hd44780.h] beim entsprechenden Modell die passende Adressierung der Zeilen und die genutzte Zeilen-/Spaltenzahl vor dem Compilieren angepasst wurde. '''Einbindung in FHEM''' lcd.classdef erstellen: <source lang="perl"> # Umsetzung der ECMD Befehle set write params line col text set write cmd {"lcd goto %line %col\n\000lcd write %text\n"} set write expect "OK\n" set write postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set clear params col set clear cmd {"lcd clear %col\n"} set clear expect "OK\n" set clear postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set clear_all cmd {"lcd clear\n"} set clear_all expect "OK\n" set clear_all postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set lcd_bl params state set lcd_bl cmd {"lcd backlight %state\n"} set lcd_bl expect "OK\n" set lcd_bl postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} </source> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs LCD=/opt/fhem/FHEM/lcd.classdef </pre> Das Display wird definiert: <pre> define WZ_LCD ECMDDevice LCD attr WZ_LCD IODev NETIO_TEST </pre> Es stehen in FHEM folgende Befehle für das LCD bereit: {| border='1' | ''Befehl'' | ''Funktion'' |- | set WZ_LCD clear [ZEILE] | löscht den Inhalt einer ZEILE (0...3) |- | set WZ_LCD clear_all | löscht den Inhalt aller Zeilen |- | set WZ_LCD lcd_bl STATE | schaltet die Hintergrundbeleuchtung ein oder aus (STATE on oder off) |- | set WZ_LCD write [ZEILE] [SPALTE] [TEXT] | schreibt einen TEXT auf Position ZEILE SPALTE (0...n) |- |} Da ein im TEXT übergebenes Leerzeichen als weiterer Befehl interpretiert wird und zu einer Fehlermeldung führt, ist eine Übergabe nur mit \x20 im Text möglich. Das gilt auch für Umlaute. Anhand der [http://de.wikipedia.org/wiki/HD44780#Schrift_und_Zeichensatz Zeichensatztabelle] lassen sich ä durch \xE1, ü durch \xF5 und ö durch \xEF darstellen. Das ß wird mit \xE2 erreicht. Die Tabelle kann für manche Displays abweichend sein.<br /> Beispiel: ''set WZ_LCD write 0 0 Fenster\x20schlie\xE2en'' schreibt ein '''Fenster schließen''' auf's LCD. '''Komfortable Nutzung in FHEM mit DLCD''' Mit dem DLCD-Modul ([http://www.fhemwiki.de/wiki/DLCD Wiki-Beitrag] / [http://forum.fhem.de/index.php/topic,24519.0.html Foren-Beitrag]) für FHEM lässt sich jedes Display auf einfache Weise beschreiben. Dabei lassen sich bequem Readings von allen Devices nutzen, aufbereiten (formatieren, umrechnen, etc.) und entsprechend darstellen. Eine genaue Beschreibung hält der Wiki-Beitrag bereit; hier soll ein Beispiel gezeigt werden. Ziel war es, auf einem 16x1 LCD wechselweise ''Datum/Zeit => Klimadaten Keller => Datum/Zeit => Klimadaten Garten'' darzustellen. Die Anzeige rotiert im 15-Sekunden-Takt, so das zu 50% Datum/Zeit und je 25% die Werte aus dem Garten und dem Keller angezeigt werden. Es wird bereits im Modul jedes Leerzeichen mit \x20 übersetzt. Der Außensensor ist ein [http://www.elv.de/elv-funk-kombi-wettersensor-ks-300-2-br-inkl-hochwertigem-2-m-edelstahlmast-br-und-qualitaetsbatterien.html KS300] (bzw. KS200) von ELV. Mit etwas Formatierung und ein paar Leerzeichen lässt sich eine stets gleiche Positionierung der Daten erreichen, da die Zeile nicht explizit gelöscht wird. Auszug aus der fhem.cfg: <pre> define DLCD_WZ DLCD attr DLCD_WZ dlcdBlankspaceReplace \x20 attr DLCD_WZ dlcdCols 16 attr DLCD_WZ dlcdLine1 %date_WD_ger% %date_D%.%date_M_ger% %time_h%:%time_m% attr DLCD_WZ dlcdLine2 Keller:%1%/%2% attr DLCD_WZ dlcdLine3 %date_WD_ger% %date_D%.%date_M_ger% %time_h%:%time_m% attr DLCD_WZ dlcdLine4 Garten: %3%/%4% attr DLCD_WZ dlcdPhysicalRows 1 attr DLCD_WZ dlcdPollInterval 15 attr DLCD_WZ dlcdRows 4 attr DLCD_WZ dlcdScrolling 1 attr DLCD_WZ dlcdTriggerCmd set WZ_LCD write %L% 0 %T% attr DLCD_WZ dlcdVal1 Keller:temperature attr DLCD_WZ dlcdVal1formatnum 3+1 attr DLCD_WZ dlcdVal2 Keller:humidity attr DLCD_WZ dlcdVal2formatnum 3+1 attr DLCD_WZ dlcdVal3 KS300:temperature attr DLCD_WZ dlcdVal3formatnum 3+1+- attr DLCD_WZ dlcdVal4 KS300:humidity attr DLCD_WZ dlcdVal4formatnum 2+0 </pre> Das Ergebnis kann so aussehen: <gallery> DLCD_1.jpg|Zustand 1.-15. Sekunde DLCD_2.jpg|Zustand 16.-30. Sekunde DLCD_3.jpg|Zustand 31.-45. Sekunde DLCD_4.jpg|Zustand 46.-60. Sekunde </gallery> Die Formatierung bewirkt eine immer identische Platzierung der Daten. Der Außensensor hat keine Zehntelwerte bei der Feuchte, muss dafür aber negative Temperaturen darstellen. Der Innensensor zeigt Zehntelwerte, womit sich Tendenzen eher erkennen lassen. == [[RFM12_ASK_(Deutsch) | Intertechno schalten mit RFM12]] == todo == [[RFM12_ASK_(Deutsch) | IC2272 schalten mit RFM12]] == todo [[Category:Application|Application]] 0e3995f0338c05c7f4f4e42358c689d1d278e10d 1336 1335 2014-10-05T18:38:31Z Kpwg 721 /* digitale Eingänge - proaktiv */ wikitext text/x-wiki {{i18n|Nutzung in FHEM}} [http://www.fhemwiki.de/wiki/Hauptseite FHEM] ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um diverse per Funk und Kabel angebundene Komponenten aus dem Bereich der Hausautomation zu steuern. Er ist lizensiert unter der GPL v2. Das [http://www.pollin.de/shop/suchergebnis.html?S_TEXT=810+058 AVR-Net-IO] von [http://www.pollin.de Pollin] mit [[Ethersex]] dient als [http://www.fhemwiki.de/wiki/AVR-NET-IO preisgünstiger Einstieg in die Hausautomatisierung]. Verwendbar ist aber auch jede andere Hardware, die von Ethersex unterstützt wird ([http://arduino.cc/en/pmwiki.php?n=Main/ArduinoBoardProMini Arduino], eigene Entwicklungen, etc.). Über [[ECMD]] lassen sich dabei theoretisch alle in [[Ethersex]] vorhandenen [[ECMD_Protocols_%28Deutsch%29 | Möglichkeiten]] nutzen, sofern in FHEM entsprechende [http://fhem.de/commandref.html#ECMD ECMD-Devices] definiert und eingebunden werden. == Grundlagen == Ausgehend von einem fertigen und per Telnet erreichbaren Ethersex muss in FHEM zuerst das entsprechende Device definiert werden. <pre> define NETIO_WZ ECMD telnet 192.168.3.81:2701 </pre> Eine serielle Anbindung kann mit ''define <name> ECMD serial <SerialDevice>[<@BaudRate>]'' alternativ erfolgen. Anschließend werden die erstellten .classdef-Konfigurationsdateien der einzelnen Funktionen dem System bekannt gemacht. In diesen .classdef-Dateien (Name und Endung sind frei wählbar!) wird die Schnittstelle zwischen FHEM und ECMD/Ethersex definiert. Dabei können mit perl übergebene Parameter und empfangene Daten bearbeitet sowie die in FHEM gebräuchlichen Readings erstellt werden. <pre> attr NETIO_WZ classdefs RFM12_2272=/opt/fhem/FHEM/rfm12_2272.classdef:RFM12_IT=/opt/fhem/FHEM/rfm12_it.classdef:LCD=/opt/fhem/FHEM/lcd.classdef:DHT22=/opt/fhem/FHEM/dht22.classdef:1WIRE=/opt/fhem/FHEM/1wire.classdef </pre> Die Definitionen für IC2272, Intertechno, HD44780-LCD, DHT22 und 1wire sind nun eingebunden. In den folgenden Abschnitten wird auf die einzelnen Devices näher eingegangen. Generell sind Pfade und IP-Adressen sowie übergebene Parameter noch entsprechend der eigenen Konfiguration anzupassen. == [[Onewire_(Deutsch) | 1-Wire Temperatursensoren]] == [[File:DS18B20.jpg|150px|thumb|right|DS18B20-Sensoren]] Die 1wire-Temperatursensoren DS18B20 oder DS18S20 werden im [[Onewire_(Deutsch)#Polling_Modus | Polling Modus]] abgefragt. Das macht die zyklische Abfrage aus FHEM heraus wesentlich einfacher. Eine Polling-Zeit von mindestens 30 Sekunden ist absolut ausreichend.Im Vorfeld sollte man sich die [[Onewire_(Deutsch)#Benennung_von_Sensoren | ROM-Codes der Sensoren]] notieren, da diese nachher benötigt werden. 1w-temp.classdef erstellen: <source lang="perl"> # Uebergabeparameter Onewire Rom-Code params devID # Umsetzung in ECMD Befehle 1w get = Temperatur auslesen get 1W cmd {"1w get %devID\n"} get 1W expect "\d+.\d\n" get 1W postproc {\ s/\n//g;\ my $hash = $defs{%NAME};\ my $temperature = $_;\ my $state = "T: $temperature";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die classdef wird eingebunden: <pre> define NETIO_KU ECMD telnet 192.168.3.82:2701 attr NETIO_KU classdefs 1W-TEMP=/opt/fhem/FHEM/1w-temp.classdef </pre> Die Sensoren werden anhand des ROM-Code definiert: <pre> define HZ_WW ECMDDevice 1W-TEMP 284c8820050003d4 attr HZ_WW IODev NETIO_KU define HZ_VL ECMDDevice 1W-TEMP 2890a520050003d7 attr HZ_VL IODev NETIO_KU </pre> Eine zyklische Messung pro Minute lässt sich in dieser Form auslösen: <pre> define Messung_1w at +*00:01 get HZ_WW 1W;; get HZ_VL 1W attr Messung_1w verbose 1 </pre> == [[DHT|DHT22 Temperatur-/Feuchtesensoren]] == [[File:DHT22.jpg|150px|thumb|right|DHT22-Sensoren]] [[Ethersex]] unterstützt die preiswerten Temperatur-/Feuchtesensoren [[DHT|DHT11 und DHT22]], wobei letztere [[DHT#DHT11_vs_DHT22|um einiges genauer sind]]. Die Sensoren benötigen 5V Betriebsspannung und kommunizieren über je einen Pin mit dem Prozessor. Der Preis pro Stück liegt derzeit bei etwa 3.50 Euro (ebay/China). Wer die Trägheit und Ungenauigkeit der S300TH oder TX29DTH kennt, wünscht sich vermutlich Besseres; vor allem bei Berechnung von [http://de.wikipedia.org/wiki/Taupunkt Taupunkt] und [http://de.wikipedia.org/wiki/Luftfeuchtigkeit#Absolute_Luftfeuchtigkeit absoluter Feuchte], welche von der Genauigkeit der gemessenen Eingangsgrößen sehr profitieren. Berechnungen von Hand kann man beim [http://www.wetterochs.de/wetter/feuchte.html Wetterochs] durchführen. Die automatische Berechnung der absoluten Feuchte in FHEM wird im [http://forum.fhem.de/index.php/topic,21458.0.html Forum] erklärt. '''Einbindung in FHEM''' dht22m.classdef erstellen: <source lang="perl"> # Uebergabeparameter DHT22 ID 0...n params devID # Umsetzung in ECMD Befehle fuer DHT22 get DHT cmd {"dht temp %devID\n\000dht humid %devID\n"} get DHT expect "\d+.\d\n" get DHT postproc {\ s/(.*)\n(.*)\n/T: $1 H: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1;\ my $humidity = $2;\ my $state = $_;\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "humidity", $humidity, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs DHT22M=/opt/fhem/FHEM/dht22m.classdef </pre> Die Sensoren werden definiert: <pre> define Test0 ECMDDevice DHT22M 0 attr Test0 IODev NETIO_TEST define Test1 ECMDDevice DHT22M 1 attr Test1 IODev NETIO_TEST define Test2 ECMDDevice DHT22M 2 attr Test2 IODev NETIO_TEST define Test3 ECMDDevice DHT22M 3 attr Test3 IODev NETIO_TEST </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_DHT at +*00:04 get Test0 DHT;; get Test1 DHT;; get Test2 DHT;; get Test3 DHT attr Messung_DHT verbose 0 </pre> Fünfzehn Messwerte pro Stunde genügen den allermeisten Anforderungen. == [[BMP085 | BMP085/BMP180 Luftdrucksensor]] == [[File:BMP180.jpg|150px|thumb|right|BMP180 (unten links)]] Ethersex unterstützt den BMP085 (bzw. den BMP180; der Code ist identisch) über das [[I2C_(Deutsch) | I2C]]-Interface. Da der Sensor für 3.3V Betriebsspannung ausgelegt ist, muss entweder der I2C-Pegel angepasst oder der ATMega auf 3.3V adaptiert werden. Weiterhin sollte die Höhe über Null bekannt sein. Beispiel: Eine Abfrage per [[ECMD]] mit ''bmp085 pressnn 59000'' bedeutet, das ich 590m (59000cm) über NN wohne. Die im Sensor verfügbare Temperatur wird parallel ausgelesen. '''Einbindung in FHEM''' bmp085.classdef erstellen: <source lang="perl"> get BMP cmd {"bmp085 temp\n\000bmp085 pressnn 59000\n"} get BMP expect ".*" get BMP postproc {\ s/(.*)\n(.*)\n/T: $1 P: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1/10;\ my $pressure = sprintf("%.1f",$2/100);\ my $state = "T: $temperature P: $pressure";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "pressure", $pressure, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die Temperatur wird in °C mit einer Nachkommastelle gelesen, der Luftdruck in hPa bzw. mbar auf eine Nachkommastelle gerundet. Passende Readings werden erstellt. Das expect .* kann noch angepasst werden, um bei fehlerhaften Messwerten entsprechend zu reagieren. Die classdef wird in FHEM eingebunden (mehrere .classdef mit Doppelpunkt trennen: siehe [[Nutzung_in_FHEM_(Deutsch)#Grundlagen | Grundlagen]]): <pre> define NETIO_STK ECMD telnet 192.168.3.89:2701 attr NETIO_STK classdefs BMP=/opt/fhem/FHEM/bmp085.classdef </pre> Der Sensor wird definiert: <pre> define BMP180 ECMDDevice BMP attr BMP180 IODev NETIO_STK </pre> Das STATE ''kann'' mit Maßeinheiten versehen werden: <pre> attr BMP180 stateFormat { sprintf("%s°C %shPa", ReadingsVal("BMP180","temperature",0), ReadingsVal("BMP180","pressure",0)) ;; } </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_BMP at +*00:04 get BMP180 BMP attr Messung_BMP verbose 0 </pre> Dabei unterdrückt verbose 0 einen zusätzlichen (doppelten) Logeintrag des Messvorganges. == analoge Eingänge == todo [[Media:Beispiel.ogg]]== digitale Eingänge - proaktiv == Kontakte, die bei Zustandsänderung sofort in FHEM eine Meldung erzeugen sollen, kann man nicht zeitnah mit Polling abfragen. Diese Ereignisse, welche auch aus einem Control6-Script heraus generiert sein können, sollen selbst Meldung machen. Hierbei wird die ESEND-Funktion benutzt, mit welcher auch mehrere Ethersex'e untereinander kommunizieren können. Dabei ist es nicht relevant, ob das Device in FHEM per ECMDDevice bereits eingebunden wurde. Zuerst muss FHEM auf Port 2701 für Telnet-Verbindungen empfänglich werden: <pre> define telnetECMD telnet 2701 global </pre> Mit ''Watch io changes and react'' lässt sich per menuconfig bereits auf einfache Weise eine Abfrage von Portpins mit Generierung eines ESEND-Befehles bewerkstelligen. Das Beispiel soll zeigen, wie bei entsprechender Zustandsänderung an Pin PA0 an 192.168.178.10 ein FHEM-Befehl gesendet wird: <pre> ECMDTCP(PA0, RISING, 192.168.178.10, set Lampe on\n\n) ECMDTCP(PA0, FALLING, 192.168.178.10, set Lampe off\n\n) </pre> Jede Sequenz muss mit \n\n abgeschlossen werden, damit FHEM für weitere Befehle empfangsbereit bleibt. Falls man in FHEM flexibler bei der Weiterverarbeitung sein möchte, bietet sich eine dummy-notify-Kombination an. == [[Porterweiterungen_%28Deutsch%29#D.2FA-Wandler_mit_LTC1257 | LTC1257 D/A-Wandler]] == todo == HD44780 Punktmatrixdisplays == [[File:HD44780.jpg|150px|thumb|right|verschiedene HD44780 Displays (16x1 bis 40x4)]] Die beliebten Punktmatrix-Displays auf Basis [http://de.wikipedia.org/wiki/HD44780 HD44780] können vollumfänglich in FHEM beschrieben werden. Dabei wird vorrausgesetzt, das in [https://github.com/ethersex/ethersex/blob/master/hardware/lcd/hd44780.h /hardware/lcd/hd44780.h] beim entsprechenden Modell die passende Adressierung der Zeilen und die genutzte Zeilen-/Spaltenzahl vor dem Compilieren angepasst wurde. '''Einbindung in FHEM''' lcd.classdef erstellen: <source lang="perl"> # Umsetzung der ECMD Befehle set write params line col text set write cmd {"lcd goto %line %col\n\000lcd write %text\n"} set write expect "OK\n" set write postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set clear params col set clear cmd {"lcd clear %col\n"} set clear expect "OK\n" set clear postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set clear_all cmd {"lcd clear\n"} set clear_all expect "OK\n" set clear_all postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set lcd_bl params state set lcd_bl cmd {"lcd backlight %state\n"} set lcd_bl expect "OK\n" set lcd_bl postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} </source> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs LCD=/opt/fhem/FHEM/lcd.classdef </pre> Das Display wird definiert: <pre> define WZ_LCD ECMDDevice LCD attr WZ_LCD IODev NETIO_TEST </pre> Es stehen in FHEM folgende Befehle für das LCD bereit: {| border='1' | ''Befehl'' | ''Funktion'' |- | set WZ_LCD clear [ZEILE] | löscht den Inhalt einer ZEILE (0...3) |- | set WZ_LCD clear_all | löscht den Inhalt aller Zeilen |- | set WZ_LCD lcd_bl STATE | schaltet die Hintergrundbeleuchtung ein oder aus (STATE on oder off) |- | set WZ_LCD write [ZEILE] [SPALTE] [TEXT] | schreibt einen TEXT auf Position ZEILE SPALTE (0...n) |- |} Da ein im TEXT übergebenes Leerzeichen als weiterer Befehl interpretiert wird und zu einer Fehlermeldung führt, ist eine Übergabe nur mit \x20 im Text möglich. Das gilt auch für Umlaute. Anhand der [http://de.wikipedia.org/wiki/HD44780#Schrift_und_Zeichensatz Zeichensatztabelle] lassen sich ä durch \xE1, ü durch \xF5 und ö durch \xEF darstellen. Das ß wird mit \xE2 erreicht. Die Tabelle kann für manche Displays abweichend sein.<br /> Beispiel: ''set WZ_LCD write 0 0 Fenster\x20schlie\xE2en'' schreibt ein '''Fenster schließen''' auf's LCD. '''Komfortable Nutzung in FHEM mit DLCD''' Mit dem DLCD-Modul ([http://www.fhemwiki.de/wiki/DLCD Wiki-Beitrag] / [http://forum.fhem.de/index.php/topic,24519.0.html Foren-Beitrag]) für FHEM lässt sich jedes Display auf einfache Weise beschreiben. Dabei lassen sich bequem Readings von allen Devices nutzen, aufbereiten (formatieren, umrechnen, etc.) und entsprechend darstellen. Eine genaue Beschreibung hält der Wiki-Beitrag bereit; hier soll ein Beispiel gezeigt werden. Ziel war es, auf einem 16x1 LCD wechselweise ''Datum/Zeit => Klimadaten Keller => Datum/Zeit => Klimadaten Garten'' darzustellen. Die Anzeige rotiert im 15-Sekunden-Takt, so das zu 50% Datum/Zeit und je 25% die Werte aus dem Garten und dem Keller angezeigt werden. Es wird bereits im Modul jedes Leerzeichen mit \x20 übersetzt. Der Außensensor ist ein [http://www.elv.de/elv-funk-kombi-wettersensor-ks-300-2-br-inkl-hochwertigem-2-m-edelstahlmast-br-und-qualitaetsbatterien.html KS300] (bzw. KS200) von ELV. Mit etwas Formatierung und ein paar Leerzeichen lässt sich eine stets gleiche Positionierung der Daten erreichen, da die Zeile nicht explizit gelöscht wird. Auszug aus der fhem.cfg: <pre> define DLCD_WZ DLCD attr DLCD_WZ dlcdBlankspaceReplace \x20 attr DLCD_WZ dlcdCols 16 attr DLCD_WZ dlcdLine1 %date_WD_ger% %date_D%.%date_M_ger% %time_h%:%time_m% attr DLCD_WZ dlcdLine2 Keller:%1%/%2% attr DLCD_WZ dlcdLine3 %date_WD_ger% %date_D%.%date_M_ger% %time_h%:%time_m% attr DLCD_WZ dlcdLine4 Garten: %3%/%4% attr DLCD_WZ dlcdPhysicalRows 1 attr DLCD_WZ dlcdPollInterval 15 attr DLCD_WZ dlcdRows 4 attr DLCD_WZ dlcdScrolling 1 attr DLCD_WZ dlcdTriggerCmd set WZ_LCD write %L% 0 %T% attr DLCD_WZ dlcdVal1 Keller:temperature attr DLCD_WZ dlcdVal1formatnum 3+1 attr DLCD_WZ dlcdVal2 Keller:humidity attr DLCD_WZ dlcdVal2formatnum 3+1 attr DLCD_WZ dlcdVal3 KS300:temperature attr DLCD_WZ dlcdVal3formatnum 3+1+- attr DLCD_WZ dlcdVal4 KS300:humidity attr DLCD_WZ dlcdVal4formatnum 2+0 </pre> Das Ergebnis kann so aussehen: <gallery> DLCD_1.jpg|Zustand 1.-15. Sekunde DLCD_2.jpg|Zustand 16.-30. Sekunde DLCD_3.jpg|Zustand 31.-45. Sekunde DLCD_4.jpg|Zustand 46.-60. Sekunde </gallery> Die Formatierung bewirkt eine immer identische Platzierung der Daten. Der Außensensor hat keine Zehntelwerte bei der Feuchte, muss dafür aber negative Temperaturen darstellen. Der Innensensor zeigt Zehntelwerte, womit sich Tendenzen eher erkennen lassen. == [[RFM12_ASK_(Deutsch) | Intertechno schalten mit RFM12]] == todo == [[RFM12_ASK_(Deutsch) | IC2272 schalten mit RFM12]] == todo [[Category:Application|Application]] d90f94e29d34815ad0ab225198417ceb0d640dfa 1337 1336 2014-10-05T18:40:59Z Kpwg 721 wikitext text/x-wiki {{i18n|Nutzung in FHEM}} [http://www.fhemwiki.de/wiki/Hauptseite FHEM] ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um diverse per Funk und Kabel angebundene Komponenten aus dem Bereich der Hausautomation zu steuern. Er ist lizensiert unter der GPL v2. Das [http://www.pollin.de/shop/suchergebnis.html?S_TEXT=810+058 AVR-Net-IO] von [http://www.pollin.de Pollin] mit [[Ethersex]] dient als [http://www.fhemwiki.de/wiki/AVR-NET-IO preisgünstiger Einstieg in die Hausautomatisierung]. Verwendbar ist aber auch jede andere Hardware, die von Ethersex unterstützt wird ([http://arduino.cc/en/pmwiki.php?n=Main/ArduinoBoardProMini Arduino], eigene Entwicklungen, etc.). Über [[ECMD]] lassen sich dabei theoretisch alle in [[Ethersex]] vorhandenen [[ECMD_Protocols_%28Deutsch%29 | Möglichkeiten]] nutzen, sofern in FHEM entsprechende [http://fhem.de/commandref.html#ECMD ECMD-Devices] definiert und eingebunden werden. == Grundlagen == Ausgehend von einem fertigen und per Telnet erreichbaren Ethersex muss in FHEM zuerst das entsprechende Device definiert werden. <pre> define NETIO_WZ ECMD telnet 192.168.3.81:2701 </pre> Eine serielle Anbindung kann mit ''define <name> ECMD serial <SerialDevice>[<@BaudRate>]'' alternativ erfolgen. Anschließend werden die erstellten .classdef-Konfigurationsdateien der einzelnen Funktionen dem System bekannt gemacht. In diesen .classdef-Dateien (Name und Endung sind frei wählbar!) wird die Schnittstelle zwischen FHEM und ECMD/Ethersex definiert. Dabei können mit perl übergebene Parameter und empfangene Daten bearbeitet sowie die in FHEM gebräuchlichen Readings erstellt werden. <pre> attr NETIO_WZ classdefs RFM12_2272=/opt/fhem/FHEM/rfm12_2272.classdef:RFM12_IT=/opt/fhem/FHEM/rfm12_it.classdef:LCD=/opt/fhem/FHEM/lcd.classdef:DHT22=/opt/fhem/FHEM/dht22.classdef:1WIRE=/opt/fhem/FHEM/1wire.classdef </pre> Die Definitionen für IC2272, Intertechno, HD44780-LCD, DHT22 und 1wire sind nun eingebunden. In den folgenden Abschnitten wird auf die einzelnen Devices näher eingegangen. Generell sind Pfade und IP-Adressen sowie übergebene Parameter noch entsprechend der eigenen Konfiguration anzupassen. == [[Onewire_(Deutsch) | 1-Wire Temperatursensoren]] == [[File:DS18B20.jpg|150px|thumb|right|DS18B20-Sensoren]] Die 1wire-Temperatursensoren DS18B20 oder DS18S20 werden im [[Onewire_(Deutsch)#Polling_Modus | Polling Modus]] abgefragt. Das macht die zyklische Abfrage aus FHEM heraus wesentlich einfacher. Eine Polling-Zeit von mindestens 30 Sekunden ist absolut ausreichend.Im Vorfeld sollte man sich die [[Onewire_(Deutsch)#Benennung_von_Sensoren | ROM-Codes der Sensoren]] notieren, da diese nachher benötigt werden. 1w-temp.classdef erstellen: <source lang="perl"> # Uebergabeparameter Onewire Rom-Code params devID # Umsetzung in ECMD Befehle 1w get = Temperatur auslesen get 1W cmd {"1w get %devID\n"} get 1W expect "\d+.\d\n" get 1W postproc {\ s/\n//g;\ my $hash = $defs{%NAME};\ my $temperature = $_;\ my $state = "T: $temperature";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die classdef wird eingebunden: <pre> define NETIO_KU ECMD telnet 192.168.3.82:2701 attr NETIO_KU classdefs 1W-TEMP=/opt/fhem/FHEM/1w-temp.classdef </pre> Die Sensoren werden anhand des ROM-Code definiert: <pre> define HZ_WW ECMDDevice 1W-TEMP 284c8820050003d4 attr HZ_WW IODev NETIO_KU define HZ_VL ECMDDevice 1W-TEMP 2890a520050003d7 attr HZ_VL IODev NETIO_KU </pre> Eine zyklische Messung pro Minute lässt sich in dieser Form auslösen: <pre> define Messung_1w at +*00:01 get HZ_WW 1W;; get HZ_VL 1W attr Messung_1w verbose 1 </pre> == [[DHT|DHT22 Temperatur-/Feuchtesensoren]] == [[File:DHT22.jpg|150px|thumb|right|DHT22-Sensoren]] [[Ethersex]] unterstützt die preiswerten Temperatur-/Feuchtesensoren [[DHT|DHT11 und DHT22]], wobei letztere [[DHT#DHT11_vs_DHT22|um einiges genauer sind]]. Die Sensoren benötigen 5V Betriebsspannung und kommunizieren über je einen Pin mit dem Prozessor. Der Preis pro Stück liegt derzeit bei etwa 3.50 Euro (ebay/China). Wer die Trägheit und Ungenauigkeit der S300TH oder TX29DTH kennt, wünscht sich vermutlich Besseres; vor allem bei Berechnung von [http://de.wikipedia.org/wiki/Taupunkt Taupunkt] und [http://de.wikipedia.org/wiki/Luftfeuchtigkeit#Absolute_Luftfeuchtigkeit absoluter Feuchte], welche von der Genauigkeit der gemessenen Eingangsgrößen sehr profitieren. Berechnungen von Hand kann man beim [http://www.wetterochs.de/wetter/feuchte.html Wetterochs] durchführen. Die automatische Berechnung der absoluten Feuchte in FHEM wird im [http://forum.fhem.de/index.php/topic,21458.0.html Forum] erklärt. '''Einbindung in FHEM''' dht22m.classdef erstellen: <source lang="perl"> # Uebergabeparameter DHT22 ID 0...n params devID # Umsetzung in ECMD Befehle fuer DHT22 get DHT cmd {"dht temp %devID\n\000dht humid %devID\n"} get DHT expect "\d+.\d\n" get DHT postproc {\ s/(.*)\n(.*)\n/T: $1 H: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1;\ my $humidity = $2;\ my $state = $_;\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "humidity", $humidity, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs DHT22M=/opt/fhem/FHEM/dht22m.classdef </pre> Die Sensoren werden definiert: <pre> define Test0 ECMDDevice DHT22M 0 attr Test0 IODev NETIO_TEST define Test1 ECMDDevice DHT22M 1 attr Test1 IODev NETIO_TEST define Test2 ECMDDevice DHT22M 2 attr Test2 IODev NETIO_TEST define Test3 ECMDDevice DHT22M 3 attr Test3 IODev NETIO_TEST </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_DHT at +*00:04 get Test0 DHT;; get Test1 DHT;; get Test2 DHT;; get Test3 DHT attr Messung_DHT verbose 0 </pre> Fünfzehn Messwerte pro Stunde genügen den allermeisten Anforderungen. == [[BMP085 | BMP085/BMP180 Luftdrucksensor]] == [[File:BMP180.jpg|150px|thumb|right|BMP180 (unten links)]] Ethersex unterstützt den BMP085 (bzw. den BMP180; der Code ist identisch) über das [[I2C_(Deutsch) | I2C]]-Interface. Da der Sensor für 3.3V Betriebsspannung ausgelegt ist, muss entweder der I2C-Pegel angepasst oder der ATMega auf 3.3V adaptiert werden. Weiterhin sollte die Höhe über Null bekannt sein. Beispiel: Eine Abfrage per [[ECMD]] mit ''bmp085 pressnn 59000'' bedeutet, das ich 590m (59000cm) über NN wohne. Die im Sensor verfügbare Temperatur wird parallel ausgelesen. '''Einbindung in FHEM''' bmp085.classdef erstellen: <source lang="perl"> get BMP cmd {"bmp085 temp\n\000bmp085 pressnn 59000\n"} get BMP expect ".*" get BMP postproc {\ s/(.*)\n(.*)\n/T: $1 P: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1/10;\ my $pressure = sprintf("%.1f",$2/100);\ my $state = "T: $temperature P: $pressure";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "pressure", $pressure, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die Temperatur wird in °C mit einer Nachkommastelle gelesen, der Luftdruck in hPa bzw. mbar auf eine Nachkommastelle gerundet. Passende Readings werden erstellt. Das expect .* kann noch angepasst werden, um bei fehlerhaften Messwerten entsprechend zu reagieren. Die classdef wird in FHEM eingebunden (mehrere .classdef mit Doppelpunkt trennen: siehe [[Nutzung_in_FHEM_(Deutsch)#Grundlagen | Grundlagen]]): <pre> define NETIO_STK ECMD telnet 192.168.3.89:2701 attr NETIO_STK classdefs BMP=/opt/fhem/FHEM/bmp085.classdef </pre> Der Sensor wird definiert: <pre> define BMP180 ECMDDevice BMP attr BMP180 IODev NETIO_STK </pre> Das STATE ''kann'' mit Maßeinheiten versehen werden: <pre> attr BMP180 stateFormat { sprintf("%s°C %shPa", ReadingsVal("BMP180","temperature",0), ReadingsVal("BMP180","pressure",0)) ;; } </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_BMP at +*00:04 get BMP180 BMP attr Messung_BMP verbose 0 </pre> Dabei unterdrückt verbose 0 einen zusätzlichen (doppelten) Logeintrag des Messvorganges. == analoge Eingänge == todo == digitale Eingänge - proaktiv == Kontakte, die bei Zustandsänderung sofort in FHEM eine Meldung erzeugen sollen, kann man nicht zeitnah mit Polling abfragen. Diese Ereignisse, welche auch aus einem Control6-Script heraus generiert sein können, sollen selbst Meldung machen. Hierbei wird die ESEND-Funktion benutzt, mit welcher auch mehrere Ethersex'e untereinander kommunizieren können. Dabei ist es nicht relevant, ob das Device in FHEM per ECMDDevice bereits eingebunden wurde. Zuerst muss FHEM auf Port 2701 für Telnet-Verbindungen empfänglich werden: <pre> define telnetECMD telnet 2701 global </pre> Mit ''Watch io changes and react'' lässt sich per menuconfig bereits auf einfache Weise eine Abfrage von Portpins mit Generierung eines ESEND-Befehles bewerkstelligen. Das Beispiel soll zeigen, wie bei entsprechender Zustandsänderung an Pin PA0 an 192.168.178.10 ein FHEM-Befehl gesendet wird: <pre> ECMDTCP(PA0, RISING, 192.168.178.10, set Lampe on\n\n) ECMDTCP(PA0, FALLING, 192.168.178.10, set Lampe off\n\n) </pre> Jede Sequenz muss mit \n\n abgeschlossen werden, damit FHEM für weitere Befehle empfangsbereit bleibt. Falls man in FHEM flexibler bei der Weiterverarbeitung sein möchte, bietet sich eine dummy-notify-Kombination an. == [[Porterweiterungen_%28Deutsch%29#D.2FA-Wandler_mit_LTC1257 | LTC1257 D/A-Wandler]] == todo == HD44780 Punktmatrixdisplays == [[File:HD44780.jpg|150px|thumb|right|verschiedene HD44780 Displays (16x1 bis 40x4)]] Die beliebten Punktmatrix-Displays auf Basis [http://de.wikipedia.org/wiki/HD44780 HD44780] können vollumfänglich in FHEM beschrieben werden. Dabei wird vorrausgesetzt, das in [https://github.com/ethersex/ethersex/blob/master/hardware/lcd/hd44780.h /hardware/lcd/hd44780.h] beim entsprechenden Modell die passende Adressierung der Zeilen und die genutzte Zeilen-/Spaltenzahl vor dem Compilieren angepasst wurde. '''Einbindung in FHEM''' lcd.classdef erstellen: <source lang="perl"> # Umsetzung der ECMD Befehle set write params line col text set write cmd {"lcd goto %line %col\n\000lcd write %text\n"} set write expect "OK\n" set write postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set clear params col set clear cmd {"lcd clear %col\n"} set clear expect "OK\n" set clear postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set clear_all cmd {"lcd clear\n"} set clear_all expect "OK\n" set clear_all postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set lcd_bl params state set lcd_bl cmd {"lcd backlight %state\n"} set lcd_bl expect "OK\n" set lcd_bl postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} </source> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs LCD=/opt/fhem/FHEM/lcd.classdef </pre> Das Display wird definiert: <pre> define WZ_LCD ECMDDevice LCD attr WZ_LCD IODev NETIO_TEST </pre> Es stehen in FHEM folgende Befehle für das LCD bereit: {| border='1' | ''Befehl'' | ''Funktion'' |- | set WZ_LCD clear [ZEILE] | löscht den Inhalt einer ZEILE (0...3) |- | set WZ_LCD clear_all | löscht den Inhalt aller Zeilen |- | set WZ_LCD lcd_bl STATE | schaltet die Hintergrundbeleuchtung ein oder aus (STATE on oder off) |- | set WZ_LCD write [ZEILE] [SPALTE] [TEXT] | schreibt einen TEXT auf Position ZEILE SPALTE (0...n) |- |} Da ein im TEXT übergebenes Leerzeichen als weiterer Befehl interpretiert wird und zu einer Fehlermeldung führt, ist eine Übergabe nur mit \x20 im Text möglich. Das gilt auch für Umlaute. Anhand der [http://de.wikipedia.org/wiki/HD44780#Schrift_und_Zeichensatz Zeichensatztabelle] lassen sich ä durch \xE1, ü durch \xF5 und ö durch \xEF darstellen. Das ß wird mit \xE2 erreicht. Die Tabelle kann für manche Displays abweichend sein.<br /> Beispiel: ''set WZ_LCD write 0 0 Fenster\x20schlie\xE2en'' schreibt ein '''Fenster schließen''' auf's LCD. '''Komfortable Nutzung in FHEM mit DLCD''' Mit dem DLCD-Modul ([http://www.fhemwiki.de/wiki/DLCD Wiki-Beitrag] / [http://forum.fhem.de/index.php/topic,24519.0.html Foren-Beitrag]) für FHEM lässt sich jedes Display auf einfache Weise beschreiben. Dabei lassen sich bequem Readings von allen Devices nutzen, aufbereiten (formatieren, umrechnen, etc.) und entsprechend darstellen. Eine genaue Beschreibung hält der Wiki-Beitrag bereit; hier soll ein Beispiel gezeigt werden. Ziel war es, auf einem 16x1 LCD wechselweise ''Datum/Zeit => Klimadaten Keller => Datum/Zeit => Klimadaten Garten'' darzustellen. Die Anzeige rotiert im 15-Sekunden-Takt, so das zu 50% Datum/Zeit und je 25% die Werte aus dem Garten und dem Keller angezeigt werden. Es wird bereits im Modul jedes Leerzeichen mit \x20 übersetzt. Der Außensensor ist ein [http://www.elv.de/elv-funk-kombi-wettersensor-ks-300-2-br-inkl-hochwertigem-2-m-edelstahlmast-br-und-qualitaetsbatterien.html KS300] (bzw. KS200) von ELV. Mit etwas Formatierung und ein paar Leerzeichen lässt sich eine stets gleiche Positionierung der Daten erreichen, da die Zeile nicht explizit gelöscht wird. Auszug aus der fhem.cfg: <pre> define DLCD_WZ DLCD attr DLCD_WZ dlcdBlankspaceReplace \x20 attr DLCD_WZ dlcdCols 16 attr DLCD_WZ dlcdLine1 %date_WD_ger% %date_D%.%date_M_ger% %time_h%:%time_m% attr DLCD_WZ dlcdLine2 Keller:%1%/%2% attr DLCD_WZ dlcdLine3 %date_WD_ger% %date_D%.%date_M_ger% %time_h%:%time_m% attr DLCD_WZ dlcdLine4 Garten: %3%/%4% attr DLCD_WZ dlcdPhysicalRows 1 attr DLCD_WZ dlcdPollInterval 15 attr DLCD_WZ dlcdRows 4 attr DLCD_WZ dlcdScrolling 1 attr DLCD_WZ dlcdTriggerCmd set WZ_LCD write %L% 0 %T% attr DLCD_WZ dlcdVal1 Keller:temperature attr DLCD_WZ dlcdVal1formatnum 3+1 attr DLCD_WZ dlcdVal2 Keller:humidity attr DLCD_WZ dlcdVal2formatnum 3+1 attr DLCD_WZ dlcdVal3 KS300:temperature attr DLCD_WZ dlcdVal3formatnum 3+1+- attr DLCD_WZ dlcdVal4 KS300:humidity attr DLCD_WZ dlcdVal4formatnum 2+0 </pre> Das Ergebnis kann so aussehen: <gallery> DLCD_1.jpg|Zustand 1.-15. Sekunde DLCD_2.jpg|Zustand 16.-30. Sekunde DLCD_3.jpg|Zustand 31.-45. Sekunde DLCD_4.jpg|Zustand 46.-60. Sekunde </gallery> Die Formatierung bewirkt eine immer identische Platzierung der Daten. Der Außensensor hat keine Zehntelwerte bei der Feuchte, muss dafür aber negative Temperaturen darstellen. Der Innensensor zeigt Zehntelwerte, womit sich Tendenzen eher erkennen lassen. == [[RFM12_ASK_(Deutsch) | Intertechno schalten mit RFM12]] == todo == [[RFM12_ASK_(Deutsch) | IC2272 schalten mit RFM12]] == todo [[Category:Application|Application]] 3c40db340e095ae5d2e3db0d093d606bd18370e1 6 397 1305 2014-08-13T21:03:36Z Coffee 722 Datei aus dem alten Wiki übertragen. wikitext text/x-wiki Datei aus dem alten Wiki übertragen. 979a453dd7b11151096a98fc7685ace0a12404c5 0 277 1306 690 2014-08-13T21:04:22Z Coffee 722 Bild aus dem alten Wiki übertragen wikitext text/x-wiki {{i18n|HTTPD}} {{Module |NAME=HTTPD |MENUCONFIG={{Applications}}->HTTP Server->HTTPD |STATUS={{stable}} |PINNING=? |ECMD=? |CONTROL6=? |DEPENDS=? |REQUIRES=? |CODE=? }} == Webserver auf dem ethersex == Der Webserver der in ethersex eingebaut ist kann von verschiedenen Orten die Daten lesen, die er ausliefern soll: * Aus einem externen Dataflash * Dateien die im Flash des Controllers nach der Firmware abgelegt sind * ECMD Befehle absetzen und die Resultate erhalten ( fuer Ajax ) Jede dieser Quellen fuer Daten kann unabhaenig von den anderen eingeschaltet werden. Die einfachste Variante ist wohl zu Beginn die Dateien im internen Flash zu halten und dynamische Inhalte ueber das Http ECMD Interface abzurufen. === Konfiguration === <pre> General Setup ---&gt; [*] VFS (Virtual File System) support ---&gt; | | [ ] Atmel SPI Dataflash | | | [*] VFS File Inlining | | | [ ] SD/MMC-Card Access | | | [ ] EEPROM (24cxx) Raw Access | | | [-] DC3840 Camera | ... Applications ---&gt; | | [*] HTTP Server | | | [ ] Basic Authentication | ... Applications ---&gt; Etherrape Control Interface (ECMD) ---&gt; | | [*] ECMD support | </pre> === Dateien einbinden === Falls die Option ''Supply Inline Files'' aktiviert ist, werden alle Dateien, die unter ''vfs/embed/'' abgelegt sind, automatisch beim Erstellen des Images mit gzip gepackt und an das Ende der Firmware angehängt. Die Dateinamen bleiben dabei unverändert, jedoch muss beachtet werden, dass die maximale Länge der Dateinamen 6 Zeichen beträgt. === Dateien mit dem C Preprocessor oder m4 vorverarbeiten === Um Dateien abhängig von den Konfigurationsoptionen einzubinden (oder nicht) bzw. nur Teile mit einzubauen, wenn eine gewisse Option aktiviert ist, kann man diese durch cpp oder m4 vorverarbeiten lassen, bevor die Ausgabe gepackt und an die Firmware angefügt wird. Dazu muss die Datei auf .cpp bzw auf .m4 enden. Bei cpp sind alle defines aus der config.h/autoconf.h erreichbar (z. B. ~np~ONEWIRE_SUPPORT~/np~). Bei m4 wird aus ~np~ONEWIRE_SUPPORT conf_ONEWIRE ~/np~. === Content Type der Dateien === Da der Webserver den Content-Type nicht dynamisch erkennen kann, muss man ihm diese Informationen etwas vorkauen. Der Content-Type wird am ersten Buchstaben des Dateinamens festgemacht: * S (z.B Sty.c): text/css * X (z.B Xow.ht): application/xhtml+xml; * Ansonsten wird alles mit text/html ausgeliefert === Dateien von SD-Card Aufrufen === Damit Datein von einer SD-Card ausgeliefert werden, kopiert man diese einfach auf die SD-Card. Sie können dann im Browser über folgende URL aufgerufen werden.(die IP, der Dateiname müssen natürlich geändert werden) <pre>http://192.168.23.244/Dateiname</pre> Wen die Datei in einem Ordner auf der SD-Card liegt ist kann sie über folgende URL aufgerufen werden.<pre>http://192.168.23.244/Ordnername/Dateiname</pre> Die Länge des Dateinamens ist bei der SD-Card nicht auf 6 Zeichen begrenzt. === ECMD-Befehle per Hand auslösen (über http) === Um die IP per ecmd abzufragen, kann man die folgende URL (die IP muss natürlich geändert werden) im Browser eingeben und man bekommt die Ausgabe per http zurück. <pre>http://192.168.23.244/ecmd?ip</pre> Möchte man Befehle verwenden, welche ein Leerzeichen beinhalten, wie z.B. "1w list", dann muss das Leerzeichen durch ein "+" bzw. "%20" ersetzt werden. Folgender Befehl listet angeschlossene 1-wire Sensoren auf, falls vorhanden. <pre>http://192.168.23.244/ecmd?1w+list</pre> oder <pre>http://192.168.23.244/ecmd?1w%20list</pre> === Startseite von Ethersex === Ist der Webserver einkompiliert sollte beim Aufruf von <nowiki>http://YOUR_ETHERSEX_IP/</nowiki> im Browser so eine Seite erscheinen: [[File:Ethersex-screen-startseite.png|600px]] === Dataflash === '''TODO''' [[Category:Ethersex]] [[Category:StepByStep]] [[Category:Network]] 9383c761b0488235f6f1a4f6b4fdbde9f5f01245 0 276 1307 1301 2014-08-13T21:25:55Z Coffee 722 Transfer image from old wiki wikitext text/x-wiki {{i18n|HTTPD}} {{Module |NAME=HTTPD |MENUCONFIG={{Applications}}->HTTP Server->HTTPD |STATUS={{stable}} |PINNING=- |ECMD=- |CONTROL6=- |DEPENDS=? |REQUIRES=? |CODE=? }} == Web server on the ethersex == The built-in web server in [[Ethersex]] can read the files it should serve from various locations: * from an external dataflash * files stored in the flash memory of the MCU right after the firmware * run ECMD commands and serve the results (for AJAX) Any of these sources for data can be enabled independent of the others. The easiest option is to initially keep the files in the internal flash memory and to access dynamic content via the HTTP ECMD interface. === Configuration === <pre> General Setup ---&gt; [*] VFS (Virtual File System) support ---&gt; | | [ ] Atmel SPI Dataflash | | | [*] VFS File Inlining | | | [ ] SD/MMC-Card Access | | | [ ] EEPROM (24cxx) Raw Access | | | [-] DC3840 Camera | ... Applications ---&gt; | | [*] HTTP Server | | | [ ] Basic Authentication | ... Applications ---&gt; Etherrape Control Interface (ECMD) ---&gt; | | [*] ECMD support | </pre> === Embedding files === If the option ''Supply Inline Files'' is enabled, all files stored in ''vfs/embed/'' will be automatically packed with gzip and appended to the end of the firmware when building the image. Filenames remain unchanged, however the maximum length of filenames is 6 characters. === Preprocess files with the C preprocessor or m4 === To include files dependent on configuration options (or not) respectively including only parts, if a certain option is enabled, they can be preprocessed by cpp or m4, before the output is packed and appended to the firmware. For that, the file must end in .cpp or .m4. When using cpp, all defines from config.h/autoconf.h are accessible (e.g. ~np~ONEWIRE_SUPPORT~/np~). When using m4, ~np~ONEWIRE_SUPPORT turns into conf_ONEWIRE ~/np~. === Content type of the files === Because the web server can not dynamically determine the content type, this information needs to be supplied in advance. The content type is determined by the first character of the file name: * S (e.g. Sty.c): text/css * X (e.g. Xow.ht): application/xhtml+xml; * everything else is served as text/html === Access files from the SD card === To serve files from an SD card, they are copied to the SD card. These can then be accessed by the browser via the following URL (IP and file name must of course be changed) <pre>http://192.168.23.244/Filename</pre> If the file is located in a folder on the SD card, it can be accessed via the following URL. <pre>http://192.168.23.244/Foldername/Filename</pre> The length of filenames is not limited to 6 characters with the SD card. === Manually triggering ECMD commands (via HTTP) === To query the IP via ECMD, the following URL (the IP must of course be changed) can be accessed with the browser, returning the output via HTTP. <pre>http://192.168.23.244/ecmd?ip</pre> In order to use commands containing spaces, e.g. "1w list", the spaces must be replaced with "+" or "%20". The following command lists 1-wire sensors, if any are present: <pre>http://192.168.23.244/ecmd?1w+list</pre> or <pre>http://192.168.23.244/ecmd?1w%20list</pre> === Ethersex start page === If the web server is compiled in, when accessing <nowiki>http://YOUR_ETHERSEX_IP/</nowiki> the browser should show such a page: [[File:Ethersex-screen-startseite.png|600px]] === Dataflash === '''TODO''' [[Category:Ethersex]] [[Category:StepByStep]] [[Category:Network]] b4f914e1310c18ccbaea671336244ca5189119c6 0 278 1317 1161 2014-08-29T18:20:19Z Michaelb 718 /* AVR Fuses */ wikitext text/x-wiki {{i18n|Quick Start Guide/Flashing}} = Flashing = After compiling the ''ethersex.hex'' you can flash it with avrdude. You can either use avrdude on the command line or call the target ''program'' from the [[Ethersex]] Makefile. == Prerequisites == * the previously selected board, e.g. AVR NET-IO, ready built and (hopefully) tested * an ISP-Programmer of your choice supported by [http://www.nongnu.org/avrdude avrdude] * an ISP connector cable that fits to your programmer and your board (either 6 or 10-pin) * an ethersex.hex compiled in the [[Quick_Start_Guide/Configuration | previous step]] If you have an ISP-Programmer with a 6-pin port and a board with a 10-pin header - like the AVR NET-IO - you can create an adapter. You can see the pin configuration in figure 4-1 at page 5 [http://www.atmel.com/dyn/resources/prod_documents/doc2521.pdf AVR042: AVR Hardware Design Considerations]. Note that Pin 4 of the 10-pin connector is not used on the AVR NET-IO. GND has to be connected to one of the other Pins (6, 8 or 10). == Flashing the image with avrdude == The following commands are just examples, the actual command line depends on your ISP-Programmer and hardware. This example is for a serial connection (e.g. the ATMEL Evaluation-Board): avrdude -v -p m32 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex This example for a real USB ISP-Programmer: avrdude -p m1284p -c avrispmkII -P usb -U flash:w:ethersex.hex For a serial programmer connected via an USB-serial-adapter this may be used: avrdude -v -p m32 -c stk500v2 -P /dev/ttyACM0 -U flash:w:ethersex.hex And this one for a parallel ISP-Cable: avrdude -p m32 -e -c stk200 -U flash:w:ethersex.hex After flashing remove the ISP-Cable and interrupt the power connection for a short time to reboot the board. * -p m32: ATMega32; -p m644: ATMega644; -p ? to list the valid parts * -v: display debug messages * -c ponyser: traditional serial programmer; -c stkk500v2 for the Atmel board * -P /dev/tty.serial the serial port your programmer is connected to; -P COM1 for windows machines; -P usb for USB * -U the command you want to execute. In our case we want to flash: -U flash:w:ethersex.hex == Using avrdude from the makefile == Since [https://github.com/ethersex/ethersex/commit/16c2a388ec775b51c049db1eeff3a8171c6ad71b 16c2a388ec] the [[Ethersex]] makefile supports two new targets, ''program'' and ''fuses'', to invoke avrdude. The target ''program'' calls avrdude with the options to flash the previously compiled ''ethersex.hex'' to the MCU. The ''fuses'' target may be used to program the MCUs fuse registers. AVRDUDE options and MCU fuse register settings may be configured via a menuconfig dialog. All settings will be saved to the current profile ''.config''. Available settings and choices on the AVRDUDE configuration page depend on the MCU and clock frequency configured on the General Setup dialog. Please go back to the [[Quick_Start_Guide/Configuration | previous step]] if you haven't done that yet. === AVRDUDE Configuration === If - and only if - the avrdude executable could be found in your ''PATH'', menuconfig's mainmenu will show an option to enter AVRDUDE configuration. [[File:avrdude_mainmenu.png|right|sub|thumb|200px|menuconfig's mainmenu with AVRDUDE Configuration selected]] The AVRDUDE configuration page allows to setup the most common options for avrdude: [[File:avrdude_menu.png|right|sub|thumb|200px|AVRDUDE configuration page]] ;Programmer Type :avrdude option '-c'. :Use the programmer configuration choosen from the list. : :Refer to the official avrdude documentation if you're in doubt about the correct choice for your programmer ([http://www.nongnu.org/avrdude/ avrdude home]). : :NB: The list of choices is generated by calling 'avrdude -c ?' and contains all the programmers your avrdude executable supports. ;Port :avrdude option '-P'. :Specify the port the programmer is connected to. Serial devices like ponyprog use for example ''/dev/ttyS0'' (= COM1 under Windows!), most modern programmers use ''usb''. : : Note that most old-style serial programmers will not work properly when connected to an USB-serial-Adapter! ; Extra verbose output :avrdude option '-v -v'. :Be more verbose. Default is '-v'. Use this, if you experience problems while flashing or simply want to see in detail whats going on... ;Do NOT verify after programming :avrdude option '-V'. :Do NOT verify flash memory after programming. Use with care and only if you're really sure that your setup is perfect. Speeds things up a bit but it's use is generally discouraged. ;Count # of erase cycles in EEPROM :avrdude option '-y'. :Tell avrdude to maintain an erase cycle counter in the last four bytes of the eeprom. The counter has to be initialized by calling avrdude with the option '-Y 1' once. : : Do not use this option if your e6 configuration uses the last four bytes of the eeprom. ;Bitclock for ISP or JTAG :avrdude option '-B'. :Specify the bit clock period for the JTAG interface or the ISP clock. :Setting a lower value means higher programming speed. Use higher values if you experience programming errors in your setup. : : The available choices depend on the MCU frequency setting and should not exceed 4/F_CPU in micro seconds: : :*4 micro seconds is required for F_CPU < 4 MHz. :*1 micro second is appropriate for F_CPU < 10 MHz. :*0.5 micro seconds is appropriate for F_CPU < 16 MHz. :*0.3 micro seconds is appropriate for F_CPU >= 16 MHz. : ;Pass extra options to avrdude :If your programmer or setup requires any extra options to avrdude you may pass them here. === AVR Fuses === The fuse registers enable/disable or control the basic functionality of the different units of the MCU. One can e. g. enable or disable the Watchdog, the JTAG interface or even the ISP Interface. Configuration of the MCUs clock source or the brown-out detector is also done via the fuse registers. '''[[WARNING:]] Programming wrong fuse values may render your MCU UNUSABLE''' (...unless you've access to a JTAG- and/or HV-Programmer.) * '''There is nothing like ''the universal correct fuse setting'' or ''default fuse setting''.''' * '''Fuse registers are MCU-specific and their correct settings heavily depend on the circuit and parts in use.''' * '''Be careful, read the datasheet for the MCU acually in use and think twice what is correct for YOUR hardware!!''' * '''Do NOT use generic settings you've found somewhere in the net...''' ;Fuse Low Byte (FLB) :AVR Fuse Low Byte, two-digit hex value. : ;Fuse High Byte (FHB) :AVR Fuse High Byte, two-digit hex value. : ;Extended Fuse Byte (EFB) :AVR Extended Fuse Byte, two-digit hex value. The necessary hex values for the fuse registers might be calculated with e.g. an online [http://www.engbedded.com/fusecalc AVR fuse calculator]. [http://www.mikrocontroller.net/articles/AVR_Fuses Article on mikrocontroller.net for reference (German).] == Writing the Bytes == * Disconnect the power from the target board * Connect your ISP cable to the programmer and the target board * Reconnect the power and connect your programmer to the PC * Execute the command you assembled earlier or type ''make program'' * Congratulations! If [[avrdude]] finished without any error you successfully flashed [[Ethersex]] to your target board! * Disconnect the power and the programmer from the target * Reconnect the power, your target should boot up with [[Ethersex]] [[Quick_Start_Guide/Configuration | previous step]] [[Category:Ethersex]] [[Category:Quick Start Guide]] [[Category:StepByStep]] 37a9e2d1baeab54d920282ddcb9276ff48372c95 6 398 1318 2014-08-31T07:28:28Z Kpwg 721 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 399 1319 2014-08-31T07:28:42Z Kpwg 721 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 400 1320 2014-08-31T07:28:54Z Kpwg 721 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 401 1321 2014-08-31T07:29:03Z Kpwg 721 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 139 1324 1170 2014-09-12T18:15:24Z Michaelb 718 /* starting functions after boot and periodically */ wikitext text/x-wiki {{i18n|own_module}} Here you can find the most relevant information in order to develop your own module. Note also the project-wide [[Contributing#Coding_Style | coding style]] and other information as described in [[define pins in ethersex]]. == License == In order to publish your module with Ethersex you have to put your code under a GPLv3-compatible license. At best include the following license header in each of your source code files (*.h, *.c): /* * * Copyright (c) 2012 by YOUR_NAME <FIRST@SIR.net> * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * as published by the Free Software Foundation; either version 3 * of the License, or (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. * * For more information on the GPL, please go to: * http://www.gnu.org/copyleft/gpl.html */ Don't forget to replace YOUR_NAME with your Name. == proper directory == You can place your module in one of the directories „hardware“, „services“ or „protocols“. If your module fulfills several of these categories, the module may be divided into smaller sub-modules. Detailed descriptions can be found in each directory in the file "content.txt". If you're not sure where to put your module, ask on the mailing list. the three categories roughly outlined: * Hardware: modules to control external hardware. * Services: modules implementing applications/daemons/services. * Protocols: modules implementing protocols. == include files in make-process == Let's assume you've added a file in a subdirectory. In order to make the file known to the make-system you need to create a Makefile, which can look like the following example: <pre> TOPDIR ?= ../.. include $(TOPDIR)/.config $(DC3840_SUPPORT)_SRC += hardware/camera/dc3840.c ############################################################################## # generic fluff include $(TOPDIR)/scripts/rules.mk </pre> Instead of the variable, which ends on _SRC, you can choose one of the following alternatives: # the file should be linked always. <pre> SRC += path/yourfile.c </pre> # the files inclusion depends on a config option in Menuconfig. <pre>${YOURBRILLIANTMODUL_SUPPORT}_SRC += path/yourfile.c </pre> # the files inclusion depends on another config option, if the ecmd parser is enabled. <pre>${YOURBRILLIANTMODUL_SUPPORT}_ECMD_SRC += path/yourfile.c </pre> Depending on the depth of the folder you have created, the path to your folder must of course adapt the number of '' ../'' to your folder. Furthermore, you have to include the directory of your module in the appropriate Makefile (/hardware/Makefile /protocols/Makefile or /services/Makefile). Example: /hardware/Makefile: SUBSUBDIRS += hardware/camera You can also add this entry in the corresponding custom.mk file (e.g. /hardware/custom.mk). This has the advantage that any changes in *custom.mk are not tracked by git. With this solution you can add own modules without committing them and still be able keep the repository up-to-date. == Menuconfig == To add your module for graphical configuration (make menuconfig), you need a file in your module folder called config.in, for example, with the following contents: dep_bool_menu 'brilliant module' YOURBRILLIANTMODUL_SUPPORT $TCP_SUPPORT This entry creates a submenu and you can activate your module only if TCP_SUPPORT is enabled. To activate your module without dependencies and without an additional menu to choose from you should use be following method: bool 'brilliant module' YOURBRILLIANTMODUL_SUPPORT Analogous to the Makefile you have to include your config.in in $(TOPDIR)/config.in: source hardware/camera/config.in == starting functions after boot and periodically == # You have developed a new module, that contains an initialization function which should be called after boot. # Your module contains a function that is constantly called if possible (or as often as possible, at least as much computing time is left over by the other application which run as a service. Therefore are the ''Ethersex Meta'' areas, maybe you've already discovered them at the end of some C-files. It basically has the following structure: <pre> / * - Ethersex META - mainloop(stella_process) init(stella_init) * / </pre> These lines, inserted at end of a file, ensure that the function ''stella_init'' is called once at the start of your modified Ethersex-Firmware and the function ''stella_process'' is called as often as possible. You can include multiple ''init'', ''mainloop'' and ... directives in the meta area. Other directives are: * '''initearly''' - works like ''init''. The functions are called just before'' init''. This is useful for dependencies, in general, you should use, however, ''init''. * '''net_init''' - to initialize network applications. The functions are called after the'' init'' functions. * '''startup''' - these functions are started before calling the mainloop. The Sendmail service for example sends the start message. * '''timer''' - Periodically (every 20ms) as in mainloop. Example: timer(50, function()) calls function() every 50*20ms, thus 1x per second. * '''header''' - header file containing the prototypes of the functions above. Included from the code generated by meta. the functions must be called in case of init without parentheses init(<fkt>) and the timer directive without brackets timer(<int> <fkt>()) . == debug output == Programming for embedded systems can be quite unnerving sometimes. Normally you do not have the necessary hardware (JTAG) for step-by-step debugging. The Ethersex core offers you some debug output functions to at least observe the program flow via syslog or the serial interface. The following debug functions are available after you include core/debug.h in your files: * void debug_printf(s, args...) // syntax like printf from the standard C library * char* debug_binary(uint8_t) // returns an 8 Byte long string of 0/1, which represents the integer The following debug functions are available after you include protocols/syslog/syslog.h in your files: * void syslog_sendf(s, args...) // syntax like printf from the standard C library [[Category:Ethersex]] [[Category:StepByStep]] [[Category:Development]] cc257fc65253b6bc21d8dd9b0318c641bd05716a 6 402 1326 2014-09-20T05:41:25Z Kpwg 721 D/A-Wandler LTC1257 mit LM358 als Verstärker wikitext text/x-wiki D/A-Wandler LTC1257 mit LM358 als Verstärker 5af554ce50ac54f20f96079986fab14beba3e176 0 145 1327 359 2014-09-21T14:30:11Z Mike73 723 /* ECMD */ wikitext text/x-wiki {{i18n|Porterweiterungen}} ==Porterweiterungen== Wenn am AVR schon viele Erweiterungen angeschlossen sind und die freien Ports langsam zur Neige gehen, kann man mit Schieberegistern arbeiten. Zwei dieser Bausteine sind bereits in der SW vorgesehen und können per menuconfig freigeschaltet werden. === 74HC165 als Eingangserweiterung === Der 74HC165 ist ein 8-bit Parallel-in/Seriell-out Schieberegister. Das kann man z.B. dazu benutzen um mehrere Schalteingänge seriell abzufragen. So könnte man z.B. 8 Taster mit nur 3 Leitungen abfragen und spart in diesem Fall 5 Portleitungen. Diese Schaltung ist kaskadierbar, so daß weitere Eingänge abgefragt werden können ohne mehr Portleitungen zu benötigen. ==== Anschluss ==== <pre> HC165_DATA: QH (erster 74HC165) HC165_CLOCK: CLOCK (alle) HC165_LOAD: Shift/Load (alle) GND: Clock Inhibit SERIAL INPUT: QH (zweiter 74HC165) </pre> Schaltbild siehe bei [http://www.mikrocontroller.net/articles/Porterweiterung_mit_SPI#Eing.C3.A4nge www.mikrocontroller.net] ==== Konfiguration ==== │ │ I/O ---> ... │ │ [*] HC165 input expansion ---> ... │ │ [ ] Inverse output │ │ (1) Number of HC165 registers In der bei "Hardware/Periphery Class" ausgewählten .m4-Datei muss angegeben werden, wo der erste 74HC165 angeschlossen ist, z.B.: <pre> pin(HC165_DATA, PC3) pin(HC165_CLOCK, PC4) pin(HC165_LOAD, PC5) </pre> ==== ECMD ==== {| border=1 | '''Syntax''' | '''Kurze Beschreibung''' |- | io get pin NUM | Liefert als Rückgabewert den Hexadezimalwert vom 74HC595. Pin 4 ist der erste, Pin 5 der zweite etc. |- |} === 74HC595 als Ausgangserweiterung === Der 74HC595 ist ein 8-bit Seriell-in/Parallel-out Schieberegister mit Latch. Das Latch braucht man, damit beim seriellen reinschieben der Bits diese nicht nacheinander an den Ausgängen erscheinen, sondern erst wenn das ganze Datenwort reingeschoben ist. Der 74HC595 ist sogar kaskadierbar, d.h. man kann theoretisch beliebig viele Ausgänge realisieren, ohne weitere Portleitungen zu benötigen. ==== Anschluss ==== <pre> HC595_DATA: Serial Data Input (SI) (erster 74HC595) HC595_CLOCK: SCK (an alle) HC595_STORE: RCK (an alle) QH* bzw. Q7*: Serial Data Input (SI) (zweiter 74HC595) </pre> [[File:Hc595_example.png|thumb|Schaltbild 74HC595]] Weitere Informationen siehe bei [http://www.mikrocontroller.net/articles/Porterweiterung_mit_SPI#Ausg.C3.A4nge www.mikrocontroller.net] ==== Konfiguration ==== │ │ I/O ---> ... │ │ [*] HC595 output expansion ---> ... │ │ (1) Number of HC595 registers In der bei "Hardware/Periphery Class" ausgewählten .m4-Datei muss angegeben werden, wo der erste 74HC595 angeschlossen ist, z.B.: <pre> pin(HC595_DATA, PC0) pin(HC595_CLOCK, PC1) pin(HC595_STORE, PC2) </pre> ==== ECMD ==== {| border=1 | '''Syntax''' | '''Kurze Beschreibung''' |- | io set port NUM HEXVALUE [MASK] | Setzt Port NUM auf den Wert HEXVALUE (ggf. wird die angegebene MASK verwendet). Port 4 ist der erste, Port 5 der zweite 74HC595 etc. |- |} Hinweis zur Portnummer: Die internen Ports (IO_HARD_PORTS) werden soweit vorhanden von 0 .. n nummeriert. Beim ATMega8 also 0..2 ( B,C,D ). Die Porterweiterungen belegen die darauf folgenden Nummern; beim m8 also ab 3. === 74HC164 als Ausgangserweiterung === Der 74HC164 ist ein 8-bit Seriell-in/Parallel-out Schieberegister. Das kann man z.B. dazu benutzen um ein handelsübliches LCD mit HD44780-Controller mit nur 3 Leitungen anzusteuern (bei direkter Ansteuerung würden 7 Portleitungen benötigt), so wird das bei U. Radig's Webserver gemacht.<br> In diesem Fall wird kein Latch benötigt, da das LCD erst beim Schalten seiner "E"-Leitung (enable) die Daten aus dem Schieberegister übernimmt. Schaltbild siehe bei [http://www.ulrichradig.de/home/index.php/software/avr-webserver-software AVR Webserver Software] { ''menuconfig todo'' } { ''pinning todo'' } ==D/A-Wandler mit LTC1257== Der LTC1257 ist ein 12bit Digital-Analog-Wandler mit seriellem Eingang und interner Referenzspannung. Zur Steuerung benötigt er lediglich 3 Portleitungen. Da er laut [http://cds.linear.com/docs/Datasheet/1257fb.pdf Datenblatt] mindestens 4,75 Volt Versorgungsspannung braucht, ist er nicht in Systemen mit 3,3 Volt einsetzbar. === Anschluss === Für eine einfache Form der Anbindung siehe Schaltbild. [[File:LTC1257.png|thumb|Schaltbild LTC1257]] === Konfiguration === │ │ I/O ---> ... │ │ [*] digital-to-analog converter (DAC) ---> ... │ │ [*] LTC1257 Output │ │ (4) LTC1257: Maximum number of devices Das nötige Pinning ist für AVR-NET-IO bereits vorhanden, in der Zuordnung <pre> pin(LTC1257_CLK, PA2, OUTPUT) pin(LTC1257_DATA, PA1, OUTPUT) pin(LTC1257_LOAD, PA0, OUTPUT) </pre> Mit <code>ltc1257_init</code> werden die Portleitungen passend initialisiert (lt. Datenblatt). Mit <code>ltc1257_delay</code> kann die interne Wartezeit in µs gesetzt werden, die zum Erkennen des Flankenwechsels durch den DAC beim Schreiben eines Bits gewartet wird (ist vor allem hilfreich, wenn der LTC1257 über Optopkoppler (z.B. CNY17) entkoppelt ist). Mit <code>ltc1257_set</code> werden die tatsächlichen Werte gesetzt, die der LTC1257 dann als Analogsignal ausgibt. Bei der Verwendung von mehreren LTC1257 im Daisy Chain muss die Reihenfolge der Werte für <code>ltc1257_set</code> in der <b>umgekehrten</b> Reihenfolge der DACs gesendet werden (d.h. das erste Argument ist für den letzten DAC). [[Category:Ethersex]] [[Category:Hardware]] 8f93e7617b128e6bd4fd54336d8af3fee86fedef 1331 1327 2014-09-22T20:53:37Z Mike73 723 /* ECMD */ wikitext text/x-wiki {{i18n|Porterweiterungen}} ==Porterweiterungen== Wenn am AVR schon viele Erweiterungen angeschlossen sind und die freien Ports langsam zur Neige gehen, kann man mit Schieberegistern arbeiten. Zwei dieser Bausteine sind bereits in der SW vorgesehen und können per menuconfig freigeschaltet werden. === 74HC165 als Eingangserweiterung === Der 74HC165 ist ein 8-bit Parallel-in/Seriell-out Schieberegister. Das kann man z.B. dazu benutzen um mehrere Schalteingänge seriell abzufragen. So könnte man z.B. 8 Taster mit nur 3 Leitungen abfragen und spart in diesem Fall 5 Portleitungen. Diese Schaltung ist kaskadierbar, so daß weitere Eingänge abgefragt werden können ohne mehr Portleitungen zu benötigen. ==== Anschluss ==== <pre> HC165_DATA: QH (erster 74HC165) HC165_CLOCK: CLOCK (alle) HC165_LOAD: Shift/Load (alle) GND: Clock Inhibit SERIAL INPUT: QH (zweiter 74HC165) </pre> Schaltbild siehe bei [http://www.mikrocontroller.net/articles/Porterweiterung_mit_SPI#Eing.C3.A4nge www.mikrocontroller.net] ==== Konfiguration ==== │ │ I/O ---> ... │ │ [*] HC165 input expansion ---> ... │ │ [ ] Inverse output │ │ (1) Number of HC165 registers In der bei "Hardware/Periphery Class" ausgewählten .m4-Datei muss angegeben werden, wo der erste 74HC165 angeschlossen ist, z.B.: <pre> pin(HC165_DATA, PC3) pin(HC165_CLOCK, PC4) pin(HC165_LOAD, PC5) </pre> ==== ECMD ==== {| border=1 | '''Syntax''' | '''Kurze Beschreibung''' |- | io get pin NUM | Liefert als Rückgabewert den Hexadezimalwert vom 74HC595. Pin 4 ist der erste, Pin 5 der zweite etc. |- |} === 74HC595 als Ausgangserweiterung === Der 74HC595 ist ein 8-bit Seriell-in/Parallel-out Schieberegister mit Latch. Das Latch braucht man, damit beim seriellen reinschieben der Bits diese nicht nacheinander an den Ausgängen erscheinen, sondern erst wenn das ganze Datenwort reingeschoben ist. Der 74HC595 ist sogar kaskadierbar, d.h. man kann theoretisch beliebig viele Ausgänge realisieren, ohne weitere Portleitungen zu benötigen. ==== Anschluss ==== <pre> HC595_DATA: Serial Data Input (SI) (erster 74HC595) HC595_CLOCK: SCK (an alle) HC595_STORE: RCK (an alle) QH* bzw. Q7*: Serial Data Input (SI) (zweiter 74HC595) </pre> [[File:Hc595_example.png|thumb|Schaltbild 74HC595]] Weitere Informationen siehe bei [http://www.mikrocontroller.net/articles/Porterweiterung_mit_SPI#Ausg.C3.A4nge www.mikrocontroller.net] ==== Konfiguration ==== │ │ I/O ---> ... │ │ [*] HC595 output expansion ---> ... │ │ (1) Number of HC595 registers In der bei "Hardware/Periphery Class" ausgewählten .m4-Datei muss angegeben werden, wo der erste 74HC595 angeschlossen ist, z.B.: <pre> pin(HC595_DATA, PC0) pin(HC595_CLOCK, PC1) pin(HC595_STORE, PC2) </pre> ==== ECMD ==== {| border=1 | '''Syntax''' | '''Kurze Beschreibung''' |- | io set port NUM HEXVALUE [MASK] | Setzt Port NUM auf den Wert HEXVALUE (ggf. wird die angegebene MASK verwendet). Port 4 ist der erste, Port 5 der zweite 74HC595 etc. |- |} Hinweis zur Portnummer: Die internen Ports (IO_HARD_PORTS) werden soweit vorhanden von 0 .. n nummeriert. Beim ATMega8 also 0..2 ( B,C,D ). Die Porterweiterungen belegen die darauf folgenden Nummern; beim m8 also ab 3. ECMD funktioniert mit den Porterweiterungen '''NUR WENN''' in der beim Konfigurieren unter I/O als "I/O abstraction model" '''Full-featured''' aktiviert wurde. === 74HC164 als Ausgangserweiterung === Der 74HC164 ist ein 8-bit Seriell-in/Parallel-out Schieberegister. Das kann man z.B. dazu benutzen um ein handelsübliches LCD mit HD44780-Controller mit nur 3 Leitungen anzusteuern (bei direkter Ansteuerung würden 7 Portleitungen benötigt), so wird das bei U. Radig's Webserver gemacht.<br> In diesem Fall wird kein Latch benötigt, da das LCD erst beim Schalten seiner "E"-Leitung (enable) die Daten aus dem Schieberegister übernimmt. Schaltbild siehe bei [http://www.ulrichradig.de/home/index.php/software/avr-webserver-software AVR Webserver Software] { ''menuconfig todo'' } { ''pinning todo'' } ==D/A-Wandler mit LTC1257== Der LTC1257 ist ein 12bit Digital-Analog-Wandler mit seriellem Eingang und interner Referenzspannung. Zur Steuerung benötigt er lediglich 3 Portleitungen. Da er laut [http://cds.linear.com/docs/Datasheet/1257fb.pdf Datenblatt] mindestens 4,75 Volt Versorgungsspannung braucht, ist er nicht in Systemen mit 3,3 Volt einsetzbar. === Anschluss === Für eine einfache Form der Anbindung siehe Schaltbild. [[File:LTC1257.png|thumb|Schaltbild LTC1257]] === Konfiguration === │ │ I/O ---> ... │ │ [*] digital-to-analog converter (DAC) ---> ... │ │ [*] LTC1257 Output │ │ (4) LTC1257: Maximum number of devices Das nötige Pinning ist für AVR-NET-IO bereits vorhanden, in der Zuordnung <pre> pin(LTC1257_CLK, PA2, OUTPUT) pin(LTC1257_DATA, PA1, OUTPUT) pin(LTC1257_LOAD, PA0, OUTPUT) </pre> Mit <code>ltc1257_init</code> werden die Portleitungen passend initialisiert (lt. Datenblatt). Mit <code>ltc1257_delay</code> kann die interne Wartezeit in µs gesetzt werden, die zum Erkennen des Flankenwechsels durch den DAC beim Schreiben eines Bits gewartet wird (ist vor allem hilfreich, wenn der LTC1257 über Optopkoppler (z.B. CNY17) entkoppelt ist). Mit <code>ltc1257_set</code> werden die tatsächlichen Werte gesetzt, die der LTC1257 dann als Analogsignal ausgibt. Bei der Verwendung von mehreren LTC1257 im Daisy Chain muss die Reihenfolge der Werte für <code>ltc1257_set</code> in der <b>umgekehrten</b> Reihenfolge der DACs gesendet werden (d.h. das erste Argument ist für den letzten DAC). [[Category:Ethersex]] [[Category:Hardware]] 8380931b18160ab75a101f5e1167e5bbea30e936 1332 1331 2014-09-22T20:54:29Z Mike73 723 /* ECMD */ wikitext text/x-wiki {{i18n|Porterweiterungen}} ==Porterweiterungen== Wenn am AVR schon viele Erweiterungen angeschlossen sind und die freien Ports langsam zur Neige gehen, kann man mit Schieberegistern arbeiten. Zwei dieser Bausteine sind bereits in der SW vorgesehen und können per menuconfig freigeschaltet werden. === 74HC165 als Eingangserweiterung === Der 74HC165 ist ein 8-bit Parallel-in/Seriell-out Schieberegister. Das kann man z.B. dazu benutzen um mehrere Schalteingänge seriell abzufragen. So könnte man z.B. 8 Taster mit nur 3 Leitungen abfragen und spart in diesem Fall 5 Portleitungen. Diese Schaltung ist kaskadierbar, so daß weitere Eingänge abgefragt werden können ohne mehr Portleitungen zu benötigen. ==== Anschluss ==== <pre> HC165_DATA: QH (erster 74HC165) HC165_CLOCK: CLOCK (alle) HC165_LOAD: Shift/Load (alle) GND: Clock Inhibit SERIAL INPUT: QH (zweiter 74HC165) </pre> Schaltbild siehe bei [http://www.mikrocontroller.net/articles/Porterweiterung_mit_SPI#Eing.C3.A4nge www.mikrocontroller.net] ==== Konfiguration ==== │ │ I/O ---> ... │ │ [*] HC165 input expansion ---> ... │ │ [ ] Inverse output │ │ (1) Number of HC165 registers In der bei "Hardware/Periphery Class" ausgewählten .m4-Datei muss angegeben werden, wo der erste 74HC165 angeschlossen ist, z.B.: <pre> pin(HC165_DATA, PC3) pin(HC165_CLOCK, PC4) pin(HC165_LOAD, PC5) </pre> ==== ECMD ==== {| border=1 | '''Syntax''' | '''Kurze Beschreibung''' |- | io get pin NUM | Liefert als Rückgabewert den Hexadezimalwert vom 74HC595. Pin 4 ist der erste, Pin 5 der zweite etc. |- |} === 74HC595 als Ausgangserweiterung === Der 74HC595 ist ein 8-bit Seriell-in/Parallel-out Schieberegister mit Latch. Das Latch braucht man, damit beim seriellen reinschieben der Bits diese nicht nacheinander an den Ausgängen erscheinen, sondern erst wenn das ganze Datenwort reingeschoben ist. Der 74HC595 ist sogar kaskadierbar, d.h. man kann theoretisch beliebig viele Ausgänge realisieren, ohne weitere Portleitungen zu benötigen. ==== Anschluss ==== <pre> HC595_DATA: Serial Data Input (SI) (erster 74HC595) HC595_CLOCK: SCK (an alle) HC595_STORE: RCK (an alle) QH* bzw. Q7*: Serial Data Input (SI) (zweiter 74HC595) </pre> [[File:Hc595_example.png|thumb|Schaltbild 74HC595]] Weitere Informationen siehe bei [http://www.mikrocontroller.net/articles/Porterweiterung_mit_SPI#Ausg.C3.A4nge www.mikrocontroller.net] ==== Konfiguration ==== │ │ I/O ---> ... │ │ [*] HC595 output expansion ---> ... │ │ (1) Number of HC595 registers In der bei "Hardware/Periphery Class" ausgewählten .m4-Datei muss angegeben werden, wo der erste 74HC595 angeschlossen ist, z.B.: <pre> pin(HC595_DATA, PC0) pin(HC595_CLOCK, PC1) pin(HC595_STORE, PC2) </pre> ==== ECMD ==== {| border=1 | '''Syntax''' | '''Kurze Beschreibung''' |- | io set port NUM HEXVALUE [MASK] | Setzt Port NUM auf den Wert HEXVALUE (ggf. wird die angegebene MASK verwendet). Port 4 ist der erste, Port 5 der zweite 74HC595 etc. |- |} Hinweis zur Portnummer: Die internen Ports (IO_HARD_PORTS) werden soweit vorhanden von 0 .. n nummeriert. Beim ATMega8 also 0..2 ( B,C,D ). Die Porterweiterungen belegen die darauf folgenden Nummern; beim m8 also ab 3. ECMD funktioniert mit den Porterweiterungen '''NUR WENN''' beim Konfigurieren ( make menuconfig ) unter I/O als "I/O abstraction model" '''Full-featured''' aktiviert wurde. === 74HC164 als Ausgangserweiterung === Der 74HC164 ist ein 8-bit Seriell-in/Parallel-out Schieberegister. Das kann man z.B. dazu benutzen um ein handelsübliches LCD mit HD44780-Controller mit nur 3 Leitungen anzusteuern (bei direkter Ansteuerung würden 7 Portleitungen benötigt), so wird das bei U. Radig's Webserver gemacht.<br> In diesem Fall wird kein Latch benötigt, da das LCD erst beim Schalten seiner "E"-Leitung (enable) die Daten aus dem Schieberegister übernimmt. Schaltbild siehe bei [http://www.ulrichradig.de/home/index.php/software/avr-webserver-software AVR Webserver Software] { ''menuconfig todo'' } { ''pinning todo'' } ==D/A-Wandler mit LTC1257== Der LTC1257 ist ein 12bit Digital-Analog-Wandler mit seriellem Eingang und interner Referenzspannung. Zur Steuerung benötigt er lediglich 3 Portleitungen. Da er laut [http://cds.linear.com/docs/Datasheet/1257fb.pdf Datenblatt] mindestens 4,75 Volt Versorgungsspannung braucht, ist er nicht in Systemen mit 3,3 Volt einsetzbar. === Anschluss === Für eine einfache Form der Anbindung siehe Schaltbild. [[File:LTC1257.png|thumb|Schaltbild LTC1257]] === Konfiguration === │ │ I/O ---> ... │ │ [*] digital-to-analog converter (DAC) ---> ... │ │ [*] LTC1257 Output │ │ (4) LTC1257: Maximum number of devices Das nötige Pinning ist für AVR-NET-IO bereits vorhanden, in der Zuordnung <pre> pin(LTC1257_CLK, PA2, OUTPUT) pin(LTC1257_DATA, PA1, OUTPUT) pin(LTC1257_LOAD, PA0, OUTPUT) </pre> Mit <code>ltc1257_init</code> werden die Portleitungen passend initialisiert (lt. Datenblatt). Mit <code>ltc1257_delay</code> kann die interne Wartezeit in µs gesetzt werden, die zum Erkennen des Flankenwechsels durch den DAC beim Schreiben eines Bits gewartet wird (ist vor allem hilfreich, wenn der LTC1257 über Optopkoppler (z.B. CNY17) entkoppelt ist). Mit <code>ltc1257_set</code> werden die tatsächlichen Werte gesetzt, die der LTC1257 dann als Analogsignal ausgibt. Bei der Verwendung von mehreren LTC1257 im Daisy Chain muss die Reihenfolge der Werte für <code>ltc1257_set</code> in der <b>umgekehrten</b> Reihenfolge der DACs gesendet werden (d.h. das erste Argument ist für den letzten DAC). [[Category:Ethersex]] [[Category:Hardware]] ea42a9bf9cb94c2377dc51e1e4d33b5f88b6ed0f 1339 1332 2014-10-11T12:08:22Z Afloria 7 wikitext text/x-wiki {{i18n|Porterweiterungen}} ==Porterweiterungen== Wenn am AVR schon viele Erweiterungen angeschlossen sind und die freien Ports langsam zur Neige gehen, kann man mit Schieberegistern arbeiten. Zwei dieser Bausteine sind bereits in der SW vorgesehen und können per menuconfig freigeschaltet werden. === 74HC165 als Eingangserweiterung === Der 74HC165 ist ein 8-bit Parallel-in/Seriell-out Schieberegister. Das kann man z.B. dazu benutzen um mehrere Schalteingänge seriell abzufragen. So könnte man z.B. 8 Taster mit nur 3 Leitungen abfragen und spart in diesem Fall 5 Portleitungen. Diese Schaltung ist kaskadierbar, so daß weitere Eingänge abgefragt werden können ohne mehr Portleitungen zu benötigen. ==== Anschluss ==== <pre> HC165_DATA: QH (erster 74HC165) HC165_CLOCK: CLOCK (alle) HC165_LOAD: Shift/Load (alle) GND: Clock Inhibit SERIAL INPUT: QH (zweiter 74HC165) </pre> Schaltbild siehe bei [http://www.mikrocontroller.net/articles/Porterweiterung_mit_SPI#Eing.C3.A4nge www.mikrocontroller.net] ==== Konfiguration ==== │ │ I/O ---> ... │ │ [*] HC165 input expansion ---> ... │ │ [ ] Inverse output │ │ (1) Number of HC165 registers In der bei "Hardware/Periphery Class" ausgewählten .m4-Datei muss angegeben werden, wo der erste 74HC165 angeschlossen ist, z.B.: <pre> pin(HC165_DATA, PC3) pin(HC165_CLOCK, PC4) pin(HC165_LOAD, PC5) </pre> ==== ECMD ==== {| border=1 | '''Syntax''' | '''Kurze Beschreibung''' |- | io get pin NUM | Liefert als Rückgabewert den Hexadezimalwert vom 74HC595. Pin 4 ist der erste, Pin 5 der zweite etc. |- |} === 74HC595 als Ausgangserweiterung === Der 74HC595 ist ein 8-bit Seriell-in/Parallel-out Schieberegister mit Latch. Das Latch braucht man, damit beim seriellen reinschieben der Bits diese nicht nacheinander an den Ausgängen erscheinen, sondern erst wenn das ganze Datenwort reingeschoben ist. Der 74HC595 ist sogar kaskadierbar, d.h. man kann theoretisch beliebig viele Ausgänge realisieren, ohne weitere Portleitungen zu benötigen. ==== Anschluss ==== <pre> HC595_DATA: Serial Data Input (SI) (erster 74HC595) HC595_CLOCK: SCK (an alle) HC595_STORE: RCK (an alle) QH* bzw. Q7*: Serial Data Input (SI) (zweiter 74HC595) </pre> [[File:Hc595_example.png|thumb|Schaltbild 74HC595]] Weitere Informationen siehe bei [http://www.mikrocontroller.net/articles/Porterweiterung_mit_SPI#Ausg.C3.A4nge www.mikrocontroller.net] ==== Konfiguration ==== │ │ I/O ---> ... │ │ [*] HC595 output expansion ---> ... │ │ (1) Number of HC595 registers In der bei "Hardware/Periphery Class" ausgewählten .m4-Datei muss angegeben werden, wo der erste 74HC595 angeschlossen ist, z.B.: <pre> pin(HC595_DATA, PC0) pin(HC595_CLOCK, PC1) pin(HC595_STORE, PC2) </pre> ==== ECMD ==== {| border=1 | '''Syntax''' | '''Kurze Beschreibung''' |- | io set port NUM HEXVALUE [MASK] | Setzt Port NUM auf den Wert HEXVALUE (ggf. wird die angegebene MASK verwendet). Port 4 ist der erste, Port 5 der zweite 74HC595 etc. |- |} Hinweis zur Portnummer: Die internen Ports (IO_HARD_PORTS) werden soweit vorhanden von 0 .. n nummeriert. Beim ATMega8 also 0..2 ( B,C,D ). Die Porterweiterungen belegen die darauf folgenden Nummern; beim m8 also ab 3. ECMD funktioniert mit den Porterweiterungen '''NUR WENN''' beim Konfigurieren ( make menuconfig ) unter I/O als "I/O abstraction model" '''Full-featured''' aktiviert wurde. === 74HC164 als Ausgangserweiterung === Der 74HC164 ist ein 8-bit Seriell-in/Parallel-out Schieberegister. Das kann man z.B. dazu benutzen um ein handelsübliches LCD mit HD44780-Controller mit nur 3 Leitungen anzusteuern (bei direkter Ansteuerung würden 7 Portleitungen benötigt), so wird das bei U. Radig's Webserver gemacht.<br> In diesem Fall wird kein Latch benötigt, da das LCD erst beim Schalten seiner "E"-Leitung (enable) die Daten aus dem Schieberegister übernimmt. <pre> -/* - * HD44780-Display über PCF8574 ansteuern. - * Belegung Pollin Add-On-Board: - * - * Pin PCF8574 Pin am LCD - * 4 (P0) -> 11 (DB4) - * 5 (P1) -> 12 (DB5) - * 6 (P2) -> 13 (DB6) - * 7 (P3) -> 14 (DB7) - * 9 (P4) -> 4 (RS) - * 10 (P5) -> 5 (R/W) nicht benutzt ! - * 11 (P6) -> 6 (EN) - * 12 (P7) -> 15 (Beleuchtung) - * - * Die LCD-Beleuchtung an Pin 12 wird über einen - * PNP-Transistor geschaltet. - * Beleuchtung an: Bit 7=0 - * Beleuchtung aus: Bit 7=1 - * Die Address-Eingänge A0 bis A2 des PCF8574 liegen alle auf GND. - * Die Basis-Addresse des Chips ist daher immer 0x20. - */ - </pre> Pinning: <pre> ifelse(value_HD44780_CONNECTION,`HD44780_I2CSUPPORT',`dnl dnl HD44780_PCF8574x_MAPPING(ADR,RS,RW,EN,DB4,DB5,DB6,DB7,BL) HD44780_PCF8574x_MAPPING(0x20, 4, 5, 6, 0, 1, 2, 3, 7) ')dnl </pre> Schaltbild siehe bei [http://www.ulrichradig.de/home/index.php/software/avr-webserver-software AVR Webserver Software] { ''menuconfig todo'' } { ''pinning todo'' } ==D/A-Wandler mit LTC1257== Der LTC1257 ist ein 12bit Digital-Analog-Wandler mit seriellem Eingang und interner Referenzspannung. Zur Steuerung benötigt er lediglich 3 Portleitungen. Da er laut [http://cds.linear.com/docs/Datasheet/1257fb.pdf Datenblatt] mindestens 4,75 Volt Versorgungsspannung braucht, ist er nicht in Systemen mit 3,3 Volt einsetzbar. === Anschluss === Für eine einfache Form der Anbindung siehe Schaltbild. [[File:LTC1257.png|thumb|Schaltbild LTC1257]] === Konfiguration === │ │ I/O ---> ... │ │ [*] digital-to-analog converter (DAC) ---> ... │ │ [*] LTC1257 Output │ │ (4) LTC1257: Maximum number of devices Das nötige Pinning ist für AVR-NET-IO bereits vorhanden, in der Zuordnung <pre> pin(LTC1257_CLK, PA2, OUTPUT) pin(LTC1257_DATA, PA1, OUTPUT) pin(LTC1257_LOAD, PA0, OUTPUT) </pre> Mit <code>ltc1257_init</code> werden die Portleitungen passend initialisiert (lt. Datenblatt). Mit <code>ltc1257_delay</code> kann die interne Wartezeit in µs gesetzt werden, die zum Erkennen des Flankenwechsels durch den DAC beim Schreiben eines Bits gewartet wird (ist vor allem hilfreich, wenn der LTC1257 über Optopkoppler (z.B. CNY17) entkoppelt ist). Mit <code>ltc1257_set</code> werden die tatsächlichen Werte gesetzt, die der LTC1257 dann als Analogsignal ausgibt. Bei der Verwendung von mehreren LTC1257 im Daisy Chain muss die Reihenfolge der Werte für <code>ltc1257_set</code> in der <b>umgekehrten</b> Reihenfolge der DACs gesendet werden (d.h. das erste Argument ist für den letzten DAC). [[Category:Ethersex]] [[Category:Hardware]] a405615e05d1f2988c25de89e1c556afb807f99a 1340 1339 2014-10-11T23:23:34Z Mike73 723 /* ECMD */ wikitext text/x-wiki {{i18n|Porterweiterungen}} ==Porterweiterungen== Wenn am AVR schon viele Erweiterungen angeschlossen sind und die freien Ports langsam zur Neige gehen, kann man mit Schieberegistern arbeiten. Zwei dieser Bausteine sind bereits in der SW vorgesehen und können per menuconfig freigeschaltet werden. === 74HC165 als Eingangserweiterung === Der 74HC165 ist ein 8-bit Parallel-in/Seriell-out Schieberegister. Das kann man z.B. dazu benutzen um mehrere Schalteingänge seriell abzufragen. So könnte man z.B. 8 Taster mit nur 3 Leitungen abfragen und spart in diesem Fall 5 Portleitungen. Diese Schaltung ist kaskadierbar, so daß weitere Eingänge abgefragt werden können ohne mehr Portleitungen zu benötigen. ==== Anschluss ==== <pre> HC165_DATA: QH (erster 74HC165) HC165_CLOCK: CLOCK (alle) HC165_LOAD: Shift/Load (alle) GND: Clock Inhibit SERIAL INPUT: QH (zweiter 74HC165) </pre> Schaltbild siehe bei [http://www.mikrocontroller.net/articles/Porterweiterung_mit_SPI#Eing.C3.A4nge www.mikrocontroller.net] ==== Konfiguration ==== │ │ I/O ---> ... │ │ [*] HC165 input expansion ---> ... │ │ [ ] Inverse output │ │ (1) Number of HC165 registers In der bei "Hardware/Periphery Class" ausgewählten .m4-Datei muss angegeben werden, wo der erste 74HC165 angeschlossen ist, z.B.: <pre> pin(HC165_DATA, PC3) pin(HC165_CLOCK, PC4) pin(HC165_LOAD, PC5) </pre> ==== ECMD ==== {| border=1 | '''Syntax''' | '''Kurze Beschreibung''' |- | io get pin NUM | Liefert als Rückgabewert den Hexadezimalwert vom 74HC164. Pin 4 ist der erste, Pin 5 der zweite etc. |- |} === 74HC595 als Ausgangserweiterung === Der 74HC595 ist ein 8-bit Seriell-in/Parallel-out Schieberegister mit Latch. Das Latch braucht man, damit beim seriellen reinschieben der Bits diese nicht nacheinander an den Ausgängen erscheinen, sondern erst wenn das ganze Datenwort reingeschoben ist. Der 74HC595 ist sogar kaskadierbar, d.h. man kann theoretisch beliebig viele Ausgänge realisieren, ohne weitere Portleitungen zu benötigen. ==== Anschluss ==== <pre> HC595_DATA: Serial Data Input (SI) (erster 74HC595) HC595_CLOCK: SCK (an alle) HC595_STORE: RCK (an alle) QH* bzw. Q7*: Serial Data Input (SI) (zweiter 74HC595) </pre> [[File:Hc595_example.png|thumb|Schaltbild 74HC595]] Weitere Informationen siehe bei [http://www.mikrocontroller.net/articles/Porterweiterung_mit_SPI#Ausg.C3.A4nge www.mikrocontroller.net] ==== Konfiguration ==== │ │ I/O ---> ... │ │ [*] HC595 output expansion ---> ... │ │ (1) Number of HC595 registers In der bei "Hardware/Periphery Class" ausgewählten .m4-Datei muss angegeben werden, wo der erste 74HC595 angeschlossen ist, z.B.: <pre> pin(HC595_DATA, PC0) pin(HC595_CLOCK, PC1) pin(HC595_STORE, PC2) </pre> ==== ECMD ==== {| border=1 | '''Syntax''' | '''Kurze Beschreibung''' |- | io set port NUM HEXVALUE [MASK] | Setzt Port NUM auf den Wert HEXVALUE (ggf. wird die angegebene MASK verwendet). Port 4 ist der erste, Port 5 der zweite 74HC595 etc. |- |} Hinweis zur Portnummer: Die internen Ports (IO_HARD_PORTS) werden soweit vorhanden von 0 .. n nummeriert. Beim ATMega8 also 0..2 ( B,C,D ). Die Porterweiterungen belegen die darauf folgenden Nummern; beim m8 also ab 3. ECMD funktioniert mit den Porterweiterungen '''NUR WENN''' beim Konfigurieren ( make menuconfig ) unter I/O als "I/O abstraction model" '''Full-featured''' aktiviert wurde. === 74HC164 als Ausgangserweiterung === Der 74HC164 ist ein 8-bit Seriell-in/Parallel-out Schieberegister. Das kann man z.B. dazu benutzen um ein handelsübliches LCD mit HD44780-Controller mit nur 3 Leitungen anzusteuern (bei direkter Ansteuerung würden 7 Portleitungen benötigt), so wird das bei U. Radig's Webserver gemacht.<br> In diesem Fall wird kein Latch benötigt, da das LCD erst beim Schalten seiner "E"-Leitung (enable) die Daten aus dem Schieberegister übernimmt. <pre> -/* - * HD44780-Display über PCF8574 ansteuern. - * Belegung Pollin Add-On-Board: - * - * Pin PCF8574 Pin am LCD - * 4 (P0) -> 11 (DB4) - * 5 (P1) -> 12 (DB5) - * 6 (P2) -> 13 (DB6) - * 7 (P3) -> 14 (DB7) - * 9 (P4) -> 4 (RS) - * 10 (P5) -> 5 (R/W) nicht benutzt ! - * 11 (P6) -> 6 (EN) - * 12 (P7) -> 15 (Beleuchtung) - * - * Die LCD-Beleuchtung an Pin 12 wird über einen - * PNP-Transistor geschaltet. - * Beleuchtung an: Bit 7=0 - * Beleuchtung aus: Bit 7=1 - * Die Address-Eingänge A0 bis A2 des PCF8574 liegen alle auf GND. - * Die Basis-Addresse des Chips ist daher immer 0x20. - */ - </pre> Pinning: <pre> ifelse(value_HD44780_CONNECTION,`HD44780_I2CSUPPORT',`dnl dnl HD44780_PCF8574x_MAPPING(ADR,RS,RW,EN,DB4,DB5,DB6,DB7,BL) HD44780_PCF8574x_MAPPING(0x20, 4, 5, 6, 0, 1, 2, 3, 7) ')dnl </pre> Schaltbild siehe bei [http://www.ulrichradig.de/home/index.php/software/avr-webserver-software AVR Webserver Software] { ''menuconfig todo'' } { ''pinning todo'' } ==D/A-Wandler mit LTC1257== Der LTC1257 ist ein 12bit Digital-Analog-Wandler mit seriellem Eingang und interner Referenzspannung. Zur Steuerung benötigt er lediglich 3 Portleitungen. Da er laut [http://cds.linear.com/docs/Datasheet/1257fb.pdf Datenblatt] mindestens 4,75 Volt Versorgungsspannung braucht, ist er nicht in Systemen mit 3,3 Volt einsetzbar. === Anschluss === Für eine einfache Form der Anbindung siehe Schaltbild. [[File:LTC1257.png|thumb|Schaltbild LTC1257]] === Konfiguration === │ │ I/O ---> ... │ │ [*] digital-to-analog converter (DAC) ---> ... │ │ [*] LTC1257 Output │ │ (4) LTC1257: Maximum number of devices Das nötige Pinning ist für AVR-NET-IO bereits vorhanden, in der Zuordnung <pre> pin(LTC1257_CLK, PA2, OUTPUT) pin(LTC1257_DATA, PA1, OUTPUT) pin(LTC1257_LOAD, PA0, OUTPUT) </pre> Mit <code>ltc1257_init</code> werden die Portleitungen passend initialisiert (lt. Datenblatt). Mit <code>ltc1257_delay</code> kann die interne Wartezeit in µs gesetzt werden, die zum Erkennen des Flankenwechsels durch den DAC beim Schreiben eines Bits gewartet wird (ist vor allem hilfreich, wenn der LTC1257 über Optopkoppler (z.B. CNY17) entkoppelt ist). Mit <code>ltc1257_set</code> werden die tatsächlichen Werte gesetzt, die der LTC1257 dann als Analogsignal ausgibt. Bei der Verwendung von mehreren LTC1257 im Daisy Chain muss die Reihenfolge der Werte für <code>ltc1257_set</code> in der <b>umgekehrten</b> Reihenfolge der DACs gesendet werden (d.h. das erste Argument ist für den letzten DAC). [[Category:Ethersex]] [[Category:Hardware]] c7812c88c7b6d8b23cb4bb7e2013c02228fd139f 1341 1340 2014-10-11T23:24:25Z Mike73 723 /* ECMD */ wikitext text/x-wiki {{i18n|Porterweiterungen}} ==Porterweiterungen== Wenn am AVR schon viele Erweiterungen angeschlossen sind und die freien Ports langsam zur Neige gehen, kann man mit Schieberegistern arbeiten. Zwei dieser Bausteine sind bereits in der SW vorgesehen und können per menuconfig freigeschaltet werden. === 74HC165 als Eingangserweiterung === Der 74HC165 ist ein 8-bit Parallel-in/Seriell-out Schieberegister. Das kann man z.B. dazu benutzen um mehrere Schalteingänge seriell abzufragen. So könnte man z.B. 8 Taster mit nur 3 Leitungen abfragen und spart in diesem Fall 5 Portleitungen. Diese Schaltung ist kaskadierbar, so daß weitere Eingänge abgefragt werden können ohne mehr Portleitungen zu benötigen. ==== Anschluss ==== <pre> HC165_DATA: QH (erster 74HC165) HC165_CLOCK: CLOCK (alle) HC165_LOAD: Shift/Load (alle) GND: Clock Inhibit SERIAL INPUT: QH (zweiter 74HC165) </pre> Schaltbild siehe bei [http://www.mikrocontroller.net/articles/Porterweiterung_mit_SPI#Eing.C3.A4nge www.mikrocontroller.net] ==== Konfiguration ==== │ │ I/O ---> ... │ │ [*] HC165 input expansion ---> ... │ │ [ ] Inverse output │ │ (1) Number of HC165 registers In der bei "Hardware/Periphery Class" ausgewählten .m4-Datei muss angegeben werden, wo der erste 74HC165 angeschlossen ist, z.B.: <pre> pin(HC165_DATA, PC3) pin(HC165_CLOCK, PC4) pin(HC165_LOAD, PC5) </pre> ==== ECMD ==== {| border=1 | '''Syntax''' | '''Kurze Beschreibung''' |- | io get pin NUM | Liefert als Rückgabewert den Hexadezimalwert vom 74HC165. Pin 4 ist der erste, Pin 5 der zweite etc. |- |} === 74HC595 als Ausgangserweiterung === Der 74HC595 ist ein 8-bit Seriell-in/Parallel-out Schieberegister mit Latch. Das Latch braucht man, damit beim seriellen reinschieben der Bits diese nicht nacheinander an den Ausgängen erscheinen, sondern erst wenn das ganze Datenwort reingeschoben ist. Der 74HC595 ist sogar kaskadierbar, d.h. man kann theoretisch beliebig viele Ausgänge realisieren, ohne weitere Portleitungen zu benötigen. ==== Anschluss ==== <pre> HC595_DATA: Serial Data Input (SI) (erster 74HC595) HC595_CLOCK: SCK (an alle) HC595_STORE: RCK (an alle) QH* bzw. Q7*: Serial Data Input (SI) (zweiter 74HC595) </pre> [[File:Hc595_example.png|thumb|Schaltbild 74HC595]] Weitere Informationen siehe bei [http://www.mikrocontroller.net/articles/Porterweiterung_mit_SPI#Ausg.C3.A4nge www.mikrocontroller.net] ==== Konfiguration ==== │ │ I/O ---> ... │ │ [*] HC595 output expansion ---> ... │ │ (1) Number of HC595 registers In der bei "Hardware/Periphery Class" ausgewählten .m4-Datei muss angegeben werden, wo der erste 74HC595 angeschlossen ist, z.B.: <pre> pin(HC595_DATA, PC0) pin(HC595_CLOCK, PC1) pin(HC595_STORE, PC2) </pre> ==== ECMD ==== {| border=1 | '''Syntax''' | '''Kurze Beschreibung''' |- | io set port NUM HEXVALUE [MASK] | Setzt Port NUM auf den Wert HEXVALUE (ggf. wird die angegebene MASK verwendet). Port 4 ist der erste, Port 5 der zweite 74HC595 etc. |- |} Hinweis zur Portnummer: Die internen Ports (IO_HARD_PORTS) werden soweit vorhanden von 0 .. n nummeriert. Beim ATMega8 also 0..2 ( B,C,D ). Die Porterweiterungen belegen die darauf folgenden Nummern; beim m8 also ab 3. ECMD funktioniert mit den Porterweiterungen '''NUR WENN''' beim Konfigurieren ( make menuconfig ) unter I/O als "I/O abstraction model" '''Full-featured''' aktiviert wurde. === 74HC164 als Ausgangserweiterung === Der 74HC164 ist ein 8-bit Seriell-in/Parallel-out Schieberegister. Das kann man z.B. dazu benutzen um ein handelsübliches LCD mit HD44780-Controller mit nur 3 Leitungen anzusteuern (bei direkter Ansteuerung würden 7 Portleitungen benötigt), so wird das bei U. Radig's Webserver gemacht.<br> In diesem Fall wird kein Latch benötigt, da das LCD erst beim Schalten seiner "E"-Leitung (enable) die Daten aus dem Schieberegister übernimmt. <pre> -/* - * HD44780-Display über PCF8574 ansteuern. - * Belegung Pollin Add-On-Board: - * - * Pin PCF8574 Pin am LCD - * 4 (P0) -> 11 (DB4) - * 5 (P1) -> 12 (DB5) - * 6 (P2) -> 13 (DB6) - * 7 (P3) -> 14 (DB7) - * 9 (P4) -> 4 (RS) - * 10 (P5) -> 5 (R/W) nicht benutzt ! - * 11 (P6) -> 6 (EN) - * 12 (P7) -> 15 (Beleuchtung) - * - * Die LCD-Beleuchtung an Pin 12 wird über einen - * PNP-Transistor geschaltet. - * Beleuchtung an: Bit 7=0 - * Beleuchtung aus: Bit 7=1 - * Die Address-Eingänge A0 bis A2 des PCF8574 liegen alle auf GND. - * Die Basis-Addresse des Chips ist daher immer 0x20. - */ - </pre> Pinning: <pre> ifelse(value_HD44780_CONNECTION,`HD44780_I2CSUPPORT',`dnl dnl HD44780_PCF8574x_MAPPING(ADR,RS,RW,EN,DB4,DB5,DB6,DB7,BL) HD44780_PCF8574x_MAPPING(0x20, 4, 5, 6, 0, 1, 2, 3, 7) ')dnl </pre> Schaltbild siehe bei [http://www.ulrichradig.de/home/index.php/software/avr-webserver-software AVR Webserver Software] { ''menuconfig todo'' } { ''pinning todo'' } ==D/A-Wandler mit LTC1257== Der LTC1257 ist ein 12bit Digital-Analog-Wandler mit seriellem Eingang und interner Referenzspannung. Zur Steuerung benötigt er lediglich 3 Portleitungen. Da er laut [http://cds.linear.com/docs/Datasheet/1257fb.pdf Datenblatt] mindestens 4,75 Volt Versorgungsspannung braucht, ist er nicht in Systemen mit 3,3 Volt einsetzbar. === Anschluss === Für eine einfache Form der Anbindung siehe Schaltbild. [[File:LTC1257.png|thumb|Schaltbild LTC1257]] === Konfiguration === │ │ I/O ---> ... │ │ [*] digital-to-analog converter (DAC) ---> ... │ │ [*] LTC1257 Output │ │ (4) LTC1257: Maximum number of devices Das nötige Pinning ist für AVR-NET-IO bereits vorhanden, in der Zuordnung <pre> pin(LTC1257_CLK, PA2, OUTPUT) pin(LTC1257_DATA, PA1, OUTPUT) pin(LTC1257_LOAD, PA0, OUTPUT) </pre> Mit <code>ltc1257_init</code> werden die Portleitungen passend initialisiert (lt. Datenblatt). Mit <code>ltc1257_delay</code> kann die interne Wartezeit in µs gesetzt werden, die zum Erkennen des Flankenwechsels durch den DAC beim Schreiben eines Bits gewartet wird (ist vor allem hilfreich, wenn der LTC1257 über Optopkoppler (z.B. CNY17) entkoppelt ist). Mit <code>ltc1257_set</code> werden die tatsächlichen Werte gesetzt, die der LTC1257 dann als Analogsignal ausgibt. Bei der Verwendung von mehreren LTC1257 im Daisy Chain muss die Reihenfolge der Werte für <code>ltc1257_set</code> in der <b>umgekehrten</b> Reihenfolge der DACs gesendet werden (d.h. das erste Argument ist für den letzten DAC). [[Category:Ethersex]] [[Category:Hardware]] f66fe426ba6034f4fd9985104986756c194dbac9 6 158 1328 391 2014-09-22T00:19:20Z Mgue 312 Mgue uploaded a new version of &quot;[[File:Ethersex-dmxUI.png]]&quot;: New elements (Dimmer, Master Switch) with Chrome 37 wikitext text/x-wiki The DMX Storage html interface in Chromium 17.0.963.56 2f3c6b5f03c2975a9ce8a7d08b9125df65b7b9bf 0 28 1329 1174 2014-09-22T00:21:38Z Mgue 312 /* Web GUI */ wikitext text/x-wiki {{i18n|DMX Storage}} {{Module |NAME=DMX Storage |MENUCONFIG={{Applications}}->DMX Storage |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] (optional) |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/services/dmx-storage https://github.com/ethersex/ethersex/tree/master/services/dmx-storage] }} Dmx Storage provides a database-like storage layer for DMX information. It forms the core of the [[Ethersex Lighting Architecture]]. == Modules (input) == The following modules change/alter the DMX data *[[Artnet]] *[[DMX]] (not yet implemented) *[[DMX FXSlot]] *[[DMX_Storage#HTML_Interface | DMX WebGUI]] == Modules (output) == The following modules display/use the dmx data *[[Artnet]] *[[DMX]] *[[Starburst]] *[[StellaLight]] == [[ECMD]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx channels | Get channels per universe |- | dmx get | Return channel value |- | dmx set | Set channel values |- | dmx universe | Get a whole universe |- | dmx universes | Get universes |- |} == Web GUI == DMX Storage Channels can also be altered via the HTTP-Server. The interface currently works in most of the Webkit-based browsers (e.g. Google Chrome) and Mozilla Firefox (Version 4+). The interface can be enabled in the [VFS] menu. Tested browsers: {| border='1' |- | Browser | Version | Works |- | Firefox | 23 | yes (see note) |- | Chromium | 28.0.1500.95 | yes |- | Konqueror | 4.10.5 | yes |- | Android Browser | Android 4.3 | yes |- |} When using Firefox with a version < 23, make sure to enable "Support <input type=range> for Firefox". [[File:Ethersex-dmxUI.png|right|500px|thumb|The HTML interface in Chromium 37.0 on Linux]] [[Category:e6la]] cef9a0cf1dd4be6e6593ed9eccf3fce4ab482a1a 1330 1329 2014-09-22T00:35:46Z Mgue 312 Documentation :) wikitext text/x-wiki {{i18n|DMX Storage}} {{Module |NAME=DMX Storage |MENUCONFIG={{Applications}}->DMX Storage |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |DEPENDS=[[ECMD]] (optional) |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/services/dmx-storage https://github.com/ethersex/ethersex/tree/master/services/dmx-storage] }} Dmx Storage provides a database-like storage layer for DMX information. It forms the core of the [[Ethersex Lighting Architecture]]. == Modules (input) == The following modules change/alter the DMX data *[[Artnet]] *[[DMX]] (not yet implemented) *[[DMX FXSlot]] *[[DMX_Storage#HTML_Interface | DMX WebGUI]] == Modules (output) == The following modules display/use the dmx data *[[Artnet]] *[[DMX]] *[[Starburst]] *[[StellaLight]] == [[ECMD]] commands == {| border='1' | ''Command syntax'' | ''Return values'' | ''Short description'' |- | dmx channels [universe] | unsigned char | Get channels per universe |- | dmx get [universe] [channel] | unsigned char | Return channel value |- | dmx set [universe] [on/off] | None | Switches the universe [on] (LIVE) or [off] (BLACKOUT] |- | dmx set [universe] dimmer [value] | None | Sets the global dimmer value for that universe (0-255) |- | dmx set [universe] [channel] [value1] [value2]...[valuen] | None | Sets the values of [universe] starting from [channel] |- | dmx universe [universe] | LIVE or BLACKOUT \n Global dimmer value (unsigned char) \n channel 0-n (unsigned char) | get all channels of [universe] with |- | dmx universes | unsigned char | Get total universes |- |} == Web GUI == DMX Storage Channels can also be altered via the HTTP-Server. The interface currently works in most of the Webkit-based browsers (e.g. Google Chrome) and Mozilla Firefox (Version 4+). The interface can be enabled in the [VFS] menu. Tested browsers: {| border='1' |- | Browser | Version | Works |- | Firefox | 23 | yes (see note) |- | Chromium | 28.0.1500.95 | yes |- | Konqueror | 4.10.5 | yes |- | Android Browser | Android 4.3 | yes |- |} When using Firefox with a version < 23, make sure to enable "Support <input type=range> for Firefox". [[File:Ethersex-dmxUI.png|right|500px|thumb|The HTML interface in Chromium 37.0 on Linux]] [[Category:e6la]] a2efb771bcca4b9dd8c3e509391f932ac42016b6 0 131 1333 308 2014-10-03T21:51:28Z Mike73 723 wikitext text/x-wiki {{i18n|Starburst}} {{Module |NAME=Starburst |MENUCONFIG={{Applications}}->Starburst |STATUS={{stable}} |PINNING=yes (optional) |ECMD=no |DEPENDS=[[DMX Storage]] [[PCA9685]] |REQUIRES= a [http://www.nxp.com/products/lighting_driver_and_controller_ics/i2c_led_display_control/series/PCA9685.html PCA9685]on the i2c bus |CODE=[https://github.com/ethersex/ethersex/tree/master/services/starburst https://github.com/ethersex/ethersex/tree/master/services/starburst] }} [[File:Pca9685pw-pcb.JPG|right|thumb|400px| A PCA9685PW (TSSOP-28 Package) soldered onto a breakout board]] Starburst uses the DMX data stored in [[DMX Storage]] and transmits it using [[I2C]] to a [http://www.nxp.com/products/automotive/display_instrumentation/led_controllers/PCA9685.html PCA9685] PWM controller. The PCA9685 is best for driving other circuits like high power LED drivers. Starburst is part of the [[Ethersex Lighting Architecture]]. == Starburst vs. [[StellaLight]] == Starburst advantages: * just needs two pins (3 pins for stroboscope) * has 12-bit PWM, thus can apply the [http://en.wikipedia.org/wiki/Stevens%27_power_law Stevens' power law] * delegates PWM generation => no load on the AVR * saves program space StellaLight advantages: * does not need an extra controller == Slave Address == Enter the [[I2C]] address of the PCA9685 in the menuconfig in decimal format. Here's how to calculate it: Fill in the values for {A0-A5} according to your layout. High: 1 Low: 0 The 7th bit has a fixed value ('''1''') This is a sample for A5=>5V ; {A4-A0}=>GND {| border="1" |fixed |A5 |A4 |A3 |A2 |A1 |A0 |- |1 |1 |0 |0 |0 |0 |0 |} to decimal => 96 == DMX layout == {| border="1" |DMX 0 |DMX 1 |DMX 2 |DMX 3 |DMX 4 |DMX 5 |DMX 6 |DMX 7 |DMX 8 |- |channel 1 |channel 2 |channel 3 |channel 4 |mode 1 |mode 2 |mode 3 |mode 4 |global strobo (optional) |} === Valid Values === '''channel n''' : 0-255 '''mode n''' : '''0''' (instant change) '''1''' (fade to target) '''global strobo''' : 1-25 (results in 1hz - 25hz) - '''0''' => no strobo == Stroboscope support == If you want to use the output enable pin, tick [*] Strobo Effect and add the pin to your hardware pinning file (in this case PORTA PIN0): PCA9685_OE(PA0) [[Category:e6la]] 23980d16bbb7219639ae19c96a39f25cb6a53614 1334 1333 2014-10-03T21:53:30Z Mike73 723 wikitext text/x-wiki {{i18n|Starburst}} {{Module |NAME=Starburst |MENUCONFIG={{Applications}}->Starburst |STATUS={{stable}} |PINNING=yes (optional) |ECMD=no |DEPENDS=[[DMX Storage]] [[PCA9685]] |REQUIRES= a [http://www.nxp.com/products/lighting_driver_and_controller_ics/i2c_led_display_control/series/PCA9685.html PCA9685]on the i2c bus |CODE=[https://github.com/ethersex/ethersex/tree/master/services/starburst https://github.com/ethersex/ethersex/tree/master/services/starburst] }} [[File:Pca9685pw-pcb.JPG|right|thumb|400px| A PCA9685PW (TSSOP-28 Package) soldered onto a breakout board]] Starburst uses the DMX data stored in [[DMX Storage]] and transmits it using [[I2C]] to a [http://www.nxp.com/products/lighting_driver_and_controller_ics/i2c_led_display_control/series/PCA9685.html PCA9685] PWM controller. The PCA9685 is best for driving other circuits like high power LED drivers. Starburst is part of the [[Ethersex Lighting Architecture]]. == Starburst vs. [[StellaLight]] == Starburst advantages: * just needs two pins (3 pins for stroboscope) * has 12-bit PWM, thus can apply the [http://en.wikipedia.org/wiki/Stevens%27_power_law Stevens' power law] * delegates PWM generation => no load on the AVR * saves program space StellaLight advantages: * does not need an extra controller == Slave Address == Enter the [[I2C]] address of the PCA9685 in the menuconfig in decimal format. Here's how to calculate it: Fill in the values for {A0-A5} according to your layout. High: 1 Low: 0 The 7th bit has a fixed value ('''1''') This is a sample for A5=>5V ; {A4-A0}=>GND {| border="1" |fixed |A5 |A4 |A3 |A2 |A1 |A0 |- |1 |1 |0 |0 |0 |0 |0 |} to decimal => 96 == DMX layout == {| border="1" |DMX 0 |DMX 1 |DMX 2 |DMX 3 |DMX 4 |DMX 5 |DMX 6 |DMX 7 |DMX 8 |- |channel 1 |channel 2 |channel 3 |channel 4 |mode 1 |mode 2 |mode 3 |mode 4 |global strobo (optional) |} === Valid Values === '''channel n''' : 0-255 '''mode n''' : '''0''' (instant change) '''1''' (fade to target) '''global strobo''' : 1-25 (results in 1hz - 25hz) - '''0''' => no strobo == Stroboscope support == If you want to use the output enable pin, tick [*] Strobo Effect and add the pin to your hardware pinning file (in this case PORTA PIN0): PCA9685_OE(PA0) [[Category:e6la]] f7d16a316b119163566e6a1c5cd2599126b503e0 2 403 1338 2014-10-09T20:51:20Z Michaelb 718 Created page with "* Michael B.s ethersex [https://github.com/michaelb42/ethersex GitHub pages] * IRC lifeform nicknamed ''berti''" wikitext text/x-wiki * Michael B.s ethersex [https://github.com/michaelb42/ethersex GitHub pages] * IRC lifeform nicknamed ''berti'' bc7e750396f2c6214c7dd8d2eb3054e28e428e59 6 404 1342 2014-10-13T18:36:58Z Kpwg 721 Pollin AVR Net-IO mit modifizierter Stromversorgung wikitext text/x-wiki Pollin AVR Net-IO mit modifizierter Stromversorgung 76980af5af5ab41e2009c766f71e5efc7138db35 6 405 1343 2014-10-13T18:41:20Z Kpwg 721 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 406 1344 2014-10-13T18:41:50Z Kpwg 721 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 407 1345 2014-10-13T18:42:10Z Kpwg 721 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 408 1346 2014-10-13T18:42:42Z Kpwg 721 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 409 1347 2014-10-13T18:43:02Z Kpwg 721 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 410 1348 2014-10-13T18:43:20Z Kpwg 721 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 411 1349 2014-10-13T18:44:39Z Kpwg 721 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 412 1350 2014-10-13T18:46:00Z Kpwg 721 Created page with "== Kommerzielle Produkte == <gallery> Bild:Etherrape.jpg | [[Etherrape]] von lochraster.org Bild:jackalope.jpg | [[Jackalope]] von lochraster.org Bild:Radig.jpg | [[AVR Webmo..." wikitext text/x-wiki == Kommerzielle Produkte == <gallery> Bild:Etherrape.jpg | [[Etherrape]] von lochraster.org Bild:jackalope.jpg | [[Jackalope]] von lochraster.org Bild:Radig.jpg | [[AVR Webmodul]] von Ulrich Radig Bild:Avr-net-io.jpg | [[AVR-NET-IO]] von Pollin Bild:Funk-avr-eval.jpg | [[Funk-AVR-Evaluationsboard]] von Pollin Bild:Conrad-probot.jpg | [[Conrad Probot]] von Conrad Bild:Fimser.jpg | [[Fimser]] vom OV Lennestadt Bild:Jeelinkv2.jpg | [[JeeLink v2]] von JeeLabs </gallery> == Eigenbau Hardware == <gallery> Bild:bw_final.jpg | [[Bettwächter]] Bild:atmega162-usb.jpg | ATmega162 mit USB Bild:usb2zbus-i2c.jpg | USB to [[ZBus]] Dongle Bild:TikiImage350.jpg | Jochens [[Pumpensteuerung]] Bild:smd.jpg | ths' ATmega64+ (SMD) Bild:usbonly_atmega32+i2c_pcf8574_auf_steckbrett.jpg | USB-Ethersex mit [[I2C]] und Porterweiterung Bild:Chaotischer-aufbau.jpeg | [[Hardware-Rayofhope|Pollins AVR-NET-IO und Erweiterungen]] Bild:Ethersex-Avrnet-GPA.jpg | [[Hardware-INPUTSAMMLER|Pollins AVR-NET-IO Steckdosenschaltzentrale]] Bild:rayofhope_h1.jpg | [[Hardware2-Rayofhope|High Power LEDs]] Bild:Resetbox_proto_01.jpg | [[Resetbox]] Bild:Habo_bulbdial_clock.jpg | [[Bulbdial Clock]] Bild:Ftdi-lochraster.jpg | [[User:Gvegidy|Atmega168p mit USB-Anschluss über FT232R]] Bild:Ehaserl-badge-eh2010.jpg | [[ehaserl]] Badge des easter(h)egg 2010 </gallery> [[Category:Ethersex]] [[Category:Hardware]] 1814aea55e17edeaef4905cc03f10ea24514ade3 1351 1350 2014-10-13T18:55:18Z Kpwg 721 /* Kommerzielle Produkte */ wikitext text/x-wiki == Kommerzielle Produkte == <gallery> Etherrape.jpg | [[Etherrape]] von lochraster.org Jackalope.jpg | [[Jackalope]] von lochraster.org Radig.jpg | [[AVR Webmodul]] von Ulrich Radig Avr-net-io.jpg | [[AVR-NET-IO]] von Pollin Funk-avr-eval.jpg | [[Funk-AVR-Evaluationsboard]] von Pollin Conrad-probot.jpg | [[Conrad Probot]] von Conrad Fimser.jpg | [[Fimser]] vom OV Lennestadt Jeelinkv2.jpg | [[JeeLink v2]] von JeeLabs </gallery> == Eigenbau Hardware == <gallery> Bild:bw_final.jpg | [[Bettwächter]] Bild:atmega162-usb.jpg | ATmega162 mit USB Bild:usb2zbus-i2c.jpg | USB to [[ZBus]] Dongle Bild:TikiImage350.jpg | Jochens [[Pumpensteuerung]] Bild:smd.jpg | ths' ATmega64+ (SMD) Bild:usbonly_atmega32+i2c_pcf8574_auf_steckbrett.jpg | USB-Ethersex mit [[I2C]] und Porterweiterung Bild:Chaotischer-aufbau.jpeg | [[Hardware-Rayofhope|Pollins AVR-NET-IO und Erweiterungen]] Bild:Ethersex-Avrnet-GPA.jpg | [[Hardware-INPUTSAMMLER|Pollins AVR-NET-IO Steckdosenschaltzentrale]] Bild:rayofhope_h1.jpg | [[Hardware2-Rayofhope|High Power LEDs]] Bild:Resetbox_proto_01.jpg | [[Resetbox]] Bild:Habo_bulbdial_clock.jpg | [[Bulbdial Clock]] Bild:Ftdi-lochraster.jpg | [[User:Gvegidy|Atmega168p mit USB-Anschluss über FT232R]] Bild:Ehaserl-badge-eh2010.jpg | [[ehaserl]] Badge des easter(h)egg 2010 </gallery> [[Category:Ethersex]] [[Category:Hardware]] a03cb4ad5d5d006d8f2ce8cd449f7d964e97d66b 6 413 1352 2014-10-13T19:04:51Z Kpwg 721 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 414 1353 2014-10-13T19:05:38Z Kpwg 721 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 415 1354 2014-10-13T19:06:10Z Kpwg 721 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 416 1355 2014-10-13T19:06:47Z Kpwg 721 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 417 1356 2014-10-13T19:10:10Z Kpwg 721 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 418 1357 2014-10-13T19:12:11Z Kpwg 721 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 419 1358 2014-10-13T19:12:42Z Kpwg 721 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 420 1359 2014-10-13T19:13:02Z Kpwg 721 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 421 1360 2014-10-13T19:16:02Z Kpwg 721 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 422 1361 2014-10-13T19:17:04Z Kpwg 721 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 423 1362 2014-10-13T19:18:17Z Kpwg 721 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 424 1363 2014-10-13T19:19:01Z Kpwg 721 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 412 1364 1351 2014-10-13T19:21:28Z Kpwg 721 /* Eigenbau Hardware */ wikitext text/x-wiki == Kommerzielle Produkte == <gallery> Etherrape.jpg | [[Etherrape]] von lochraster.org Jackalope.jpg | [[Jackalope]] von lochraster.org Radig.jpg | [[AVR Webmodul]] von Ulrich Radig Avr-net-io.jpg | [[AVR-NET-IO]] von Pollin Funk-avr-eval.jpg | [[Funk-AVR-Evaluationsboard]] von Pollin Conrad-probot.jpg | [[Conrad Probot]] von Conrad Fimser.jpg | [[Fimser]] vom OV Lennestadt Jeelinkv2.jpg | [[JeeLink v2]] von JeeLabs </gallery> == Eigenbau Hardware == <gallery> Bw_final.jpg | Bettwächter Atmega162-usb.jpg | ATmega162 mit USB Usb2zbus-i2c.jpg | USB to [[ZBus]] Dongle Pumpensteuerung.jpg | Jochens Pumpensteuerung Ethmega.jpg | ths' ATmega64+ (SMD) Usbonly_atmega32+i2c_pcf8574_auf_steckbrett.jpg | USB-Ethersex mit [[I2C]] und Porterweiterung Chaotischer-aufbau.jpg | Pollins AVR-NET-IO und Erweiterungen Ethersex-Avrnet-GPA.jpg | Pollins AVR-NET-IO Steckdosenschaltzentrale Resetbox_proto_01.jpg | [[Resetbox]] Habo_bulbdial_clock.jpg | [[Bulbdial Clock]] Ftdi-lochraster.jpg | [[User:Gvegidy|Atmega168p mit USB-Anschluss über FT232R]] Ehaserl-badge-eh2010.jpg | [[ehaserl]] Badge des easter(h)egg 2010 </gallery> [[Category:Ethersex]] [[Category:Hardware]] 99f7757c41f5fde09191bc4ea4ee9f2c12e2e4fd 1365 1364 2014-10-13T19:23:29Z Kpwg 721 wikitext text/x-wiki {{i18n|Supported Boards}} == Kommerzielle Produkte == <gallery> Etherrape.jpg | [[Etherrape]] von lochraster.org Jackalope.jpg | [[Jackalope]] von lochraster.org Radig.jpg | [[AVR Webmodul]] von Ulrich Radig Avr-net-io.jpg | [[AVR-NET-IO]] von Pollin Funk-avr-eval.jpg | [[Funk-AVR-Evaluationsboard]] von Pollin Conrad-probot.jpg | [[Conrad Probot]] von Conrad Fimser.jpg | [[Fimser]] vom OV Lennestadt Jeelinkv2.jpg | [[JeeLink v2]] von JeeLabs </gallery> == Eigenbau Hardware == <gallery> Bw_final.jpg | Bettwächter Atmega162-usb.jpg | ATmega162 mit USB Usb2zbus-i2c.jpg | USB to [[ZBus]] Dongle Pumpensteuerung.jpg | Jochens Pumpensteuerung Ethmega.jpg | ths' ATmega64+ (SMD) Usbonly_atmega32+i2c_pcf8574_auf_steckbrett.jpg | USB-Ethersex mit [[I2C]] und Porterweiterung Chaotischer-aufbau.jpg | Pollins AVR-NET-IO und Erweiterungen Ethersex-Avrnet-GPA.jpg | Pollins AVR-NET-IO Steckdosenschaltzentrale Resetbox_proto_01.jpg | [[Resetbox]] Habo_bulbdial_clock.jpg | [[Bulbdial Clock]] Ftdi-lochraster.jpg | [[User:Gvegidy|Atmega168p mit USB-Anschluss über FT232R]] Ehaserl-badge-eh2010.jpg | [[ehaserl]] Badge des easter(h)egg 2010 </gallery> [[Category:Ethersex]] [[Category:Hardware]] 1a7cab59484238c95200086e65bae6aaa36192fc 1368 1365 2014-10-14T07:52:57Z Kpwg 721 alle Links (Deutsch) korrigiert wikitext text/x-wiki {{i18n|Supported Boards}} == Kommerzielle Produkte == <gallery> Etherrape.jpg | [[Etherrape_(Deutsch) | Etherrape]] von lochraster.org Jackalope.jpg | [[Jackalope_(Deutsch) | Jackalope]] von lochraster.org Radig.jpg | [[AVR Webmodul_(Deutsch) | AVR Webmodul]] von Ulrich Radig Avr-net-io.jpg | [[AVR-NET-IO_(Deutsch) | AVR-NET-IO]] von Pollin Funk-avr-eval.jpg | [[Funk-AVR-Evaluationsboard_(Deutsch) | Funk-AVR-Evaluationsboard]] von Pollin Conrad-probot.jpg | [[Conrad Probot_(Deutsch) | Conrad Probot]] von Conrad Fimser.jpg | [[Fimser_(Deutsch) | Fimser]] vom OV Lennestadt Jeelinkv2.jpg | [[JeeLink_(Deutsch) | JeeLink]] von JeeLabs </gallery> == Eigenbau Hardware == <gallery> Bw_final.jpg | Bettwächter Atmega162-usb.jpg | ATmega162 mit USB Usb2zbus-i2c.jpg | USB to [[ZBus_(Deutsch) | ZBus]] Dongle Pumpensteuerung.jpg | Jochens Pumpensteuerung Ethmega.jpg | ths' ATmega64+ (SMD) Usbonly_atmega32+i2c_pcf8574_auf_steckbrett.jpg | USB-Ethersex mit [[I2C_(Deutsch) | I2C]] und Porterweiterung Chaotischer-aufbau.jpg | Pollins AVR-NET-IO und Erweiterungen Ethersex-Avrnet-GPA.jpg | Pollins AVR-NET-IO Steckdosenschaltzentrale Resetbox_proto_01.jpg | [[Resetbox_(Deutsch) | Resetbox]] Habo_bulbdial_clock.jpg | [[Bulbdial Clock_(Deutsch) | Bulbdial Clock]] Ftdi-lochraster.jpg | Atmega168p mit USB-Anschluss über FT232R Ehaserl-badge-eh2010.jpg | [[ehaserl_(Deutsch) | ehaserl]] Badge des easter(h)egg 2010 </gallery> [[Category:Ethersex]] [[Category:Hardware]] 77036fc7d198e57d1c0671b8e677594d7adb0ad0 1377 1368 2014-10-14T16:21:46Z Kpwg 721 wikitext text/x-wiki {{i18n|Supported Boards}} == Kommerzielle Produkte == <gallery> Etherrape.jpg | [[Etherrape_(Deutsch) | Etherrape]] von lochraster.org Jackalope.jpg | [[Jackalope_(Deutsch) | Jackalope]] von lochraster.org Radig.jpg | [[AVR Webmodul_(Deutsch) | AVR Webmodul]] von Ulrich Radig Avr-net-io.jpg | [[AVR-NET-IO_(Deutsch) | AVR-NET-IO]] von Pollin Funk-avr-eval.jpg | [[Funk-AVR-Evaluationsboard_(Deutsch) | Funk-AVR-Evaluationsboard]] von Pollin Conrad-probot.jpg | [[Conrad Probot_(Deutsch) | Conrad Probot]] von Conrad Fimser.jpg | [[Fimser_(Deutsch) | Fimser]] vom OV Lennestadt Jeelinkv2.jpg | [[JeeLink_(Deutsch) | JeeLink]] von JeeLabs </gallery> == Eigenbau Hardware == <gallery> Fhem_wz_01.jpg | [[Nutzung_in_FHEM_(Deutsch) | FHEM]] [[FHEM_Wohnzimmer_(Deutsch) | Roomnode]] Bw_final.jpg | Bettwächter Atmega162-usb.jpg | ATmega162 mit USB Usb2zbus-i2c.jpg | USB to [[ZBus_(Deutsch) | ZBus]] Dongle Pumpensteuerung.jpg | Jochens Pumpensteuerung Ethmega.jpg | ths' ATmega64+ (SMD) Usbonly_atmega32+i2c_pcf8574_auf_steckbrett.jpg | USB-Ethersex mit [[I2C_(Deutsch) | I2C]] und Porterweiterung Chaotischer-aufbau.jpg | Pollins AVR-NET-IO und Erweiterungen Ethersex-Avrnet-GPA.jpg | Pollins AVR-NET-IO Steckdosenschaltzentrale Resetbox_proto_01.jpg | [[Resetbox_(Deutsch) | Resetbox]] Habo_bulbdial_clock.jpg | [[Bulbdial Clock_(Deutsch) | Bulbdial Clock]] Ftdi-lochraster.jpg | Atmega168p mit USB-Anschluss über FT232R Ehaserl-badge-eh2010.jpg | [[ehaserl_(Deutsch) | ehaserl]] Badge des easter(h)egg 2010 </gallery> [[Category:Ethersex]] [[Category:Hardware]] 29a8b02e9136dc0341650479b3e02c650ee76f4c 1388 1377 2014-10-15T11:18:33Z Kpwg 721 wikitext text/x-wiki {{i18n|Supported Boards}} == Kommerzielle Produkte == <gallery> Etherrape.jpg | [[Etherrape_(Deutsch) | Etherrape]] von lochraster.org Jackalope.jpg | [[Jackalope_(Deutsch) | Jackalope]] von lochraster.org Radig.jpg | [[AVR Webmodul_(Deutsch) | AVR Webmodul]] von Ulrich Radig Avr-net-io.jpg | [[AVR-NET-IO_(Deutsch) | AVR-NET-IO]] von Pollin Funk-avr-eval.jpg | [[Funk-AVR-Evaluationsboard_(Deutsch) | Funk-AVR-Evaluationsboard]] von Pollin Conrad-probot.jpg | [[Conrad Probot_(Deutsch) | Conrad Probot]] von Conrad Fimser.jpg | [[Fimser_(Deutsch) | Fimser]] vom OV Lennestadt Jeelinkv2.jpg | [[JeeLink_(Deutsch) | JeeLink]] von JeeLabs </gallery> == Eigenbau Hardware == <gallery> Fhem_wz_01.jpg | [[Nutzung_in_FHEM_(Deutsch) | FHEM]] [[FHEM_Wohnzimmer_(Deutsch) | Roomnode]] Fhem_ku_01.jpg | [[Nutzung_in_FHEM_(Deutsch) | FHEM]] [[FHEM_Kueche_(Deutsch) | Roomnode]] Bw_final.jpg | Bettwächter Atmega162-usb.jpg | ATmega162 mit USB Usb2zbus-i2c.jpg | USB to [[ZBus_(Deutsch) | ZBus]] Dongle Pumpensteuerung.jpg | Jochens Pumpensteuerung Ethmega.jpg | ths' ATmega64+ (SMD) Usbonly_atmega32+i2c_pcf8574_auf_steckbrett.jpg | USB-Ethersex mit [[I2C_(Deutsch) | I2C]] und Porterweiterung Chaotischer-aufbau.jpg | Pollins AVR-NET-IO und Erweiterungen Ethersex-Avrnet-GPA.jpg | Pollins AVR-NET-IO Steckdosenschaltzentrale Resetbox_proto_01.jpg | [[Resetbox_(Deutsch) | Resetbox]] Habo_bulbdial_clock.jpg | [[Bulbdial Clock_(Deutsch) | Bulbdial Clock]] Ftdi-lochraster.jpg | Atmega168p mit USB-Anschluss über FT232R Ehaserl-badge-eh2010.jpg | [[ehaserl_(Deutsch) | ehaserl]] Badge des easter(h)egg 2010 </gallery> [[Category:Ethersex]] [[Category:Hardware]] 0a99b2cc59ae68ca8bc78af783cf61411ab339da 0 390 1366 1337 2014-10-14T06:30:17Z Kpwg 721 wikitext text/x-wiki {{i18n|Nutzung in FHEM}} [http://www.fhemwiki.de/wiki/Hauptseite FHEM] ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um diverse per Funk und Kabel angebundene Komponenten aus dem Bereich der Hausautomation zu steuern. Er ist lizensiert unter der GPL v2. Das [http://www.pollin.de/shop/suchergebnis.html?S_TEXT=810+058 AVR-Net-IO] von [http://www.pollin.de Pollin] mit [[Ethersex]] dient als [http://www.fhemwiki.de/wiki/AVR-NET-IO preisgünstiger Einstieg in die Hausautomatisierung]. Verwendbar ist aber auch jede andere [[Supported_Boards_(Deutsch) | Hardware]], die von Ethersex unterstützt wird (Arduino, eigene Entwicklungen, etc.). Über [[ECMD]] lassen sich dabei theoretisch alle in [[Ethersex]] vorhandenen [[ECMD_Protocols_%28Deutsch%29 | Möglichkeiten]] nutzen, sofern in FHEM entsprechende [http://fhem.de/commandref.html#ECMD ECMD-Devices] definiert und eingebunden werden, die passende Klassendefinition (Übersetzung ECMD <=> Perl/FHEM) exisitert (+ funktioniert) und die Aktion ausgelöst wird. == Grundlagen == Ausgehend von einem fertigen und per Telnet erreichbaren Ethersex muss in FHEM zuerst das entsprechende Device definiert werden. <pre> define NETIO_WZ ECMD telnet 192.168.3.81:2701 </pre> Eine serielle Anbindung kann mit ''define <name> ECMD serial <SerialDevice>[<@BaudRate>]'' alternativ erfolgen. Anschließend werden die erstellten .classdef-Konfigurationsdateien der einzelnen Funktionen dem System bekannt gemacht. In diesen .classdef-Dateien (Name und Endung sind frei wählbar!) wird die Schnittstelle zwischen FHEM und ECMD/Ethersex definiert. Dabei können mit perl übergebene Parameter und empfangene Daten bearbeitet sowie die in FHEM gebräuchlichen Readings erstellt werden. <pre> attr NETIO_WZ classdefs RFM12_2272=/opt/fhem/FHEM/rfm12_2272.classdef:RFM12_IT=/opt/fhem/FHEM/rfm12_it.classdef:LCD=/opt/fhem/FHEM/lcd.classdef:DHT22=/opt/fhem/FHEM/dht22.classdef:1WIRE=/opt/fhem/FHEM/1wire.classdef </pre> Die Definitionen für IC2272, Intertechno, HD44780-LCD, DHT22 und 1wire sind nun eingebunden. In den folgenden Abschnitten wird auf die einzelnen Devices näher eingegangen. Generell sind Pfade und IP-Adressen sowie übergebene Parameter noch entsprechend der eigenen Konfiguration anzupassen. == [[Onewire_(Deutsch) | 1-Wire Temperatursensoren]] == [[File:DS18B20.jpg|150px|thumb|right|DS18B20-Sensoren]] Die 1wire-Temperatursensoren DS18B20 oder DS18S20 werden im [[Onewire_(Deutsch)#Polling_Modus | Polling Modus]] abgefragt. Das macht die zyklische Abfrage aus FHEM heraus wesentlich einfacher. Eine Polling-Zeit von mindestens 30 Sekunden ist absolut ausreichend.Im Vorfeld sollte man sich die [[Onewire_(Deutsch)#Benennung_von_Sensoren | ROM-Codes der Sensoren]] notieren, da diese nachher benötigt werden. 1w-temp.classdef erstellen: <source lang="perl"> # Uebergabeparameter Onewire Rom-Code params devID # Umsetzung in ECMD Befehle 1w get = Temperatur auslesen get 1W cmd {"1w get %devID\n"} get 1W expect "\d+.\d\n" get 1W postproc {\ s/\n//g;\ my $hash = $defs{%NAME};\ my $temperature = $_;\ my $state = "T: $temperature";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die classdef wird eingebunden: <pre> define NETIO_KU ECMD telnet 192.168.3.82:2701 attr NETIO_KU classdefs 1W-TEMP=/opt/fhem/FHEM/1w-temp.classdef </pre> Die Sensoren werden anhand des ROM-Code definiert: <pre> define HZ_WW ECMDDevice 1W-TEMP 284c8820050003d4 attr HZ_WW IODev NETIO_KU define HZ_VL ECMDDevice 1W-TEMP 2890a520050003d7 attr HZ_VL IODev NETIO_KU </pre> Eine zyklische Messung pro Minute lässt sich in dieser Form auslösen: <pre> define Messung_1w at +*00:01 get HZ_WW 1W;; get HZ_VL 1W attr Messung_1w verbose 1 </pre> == [[DHT|DHT22 Temperatur-/Feuchtesensoren]] == [[File:DHT22.jpg|150px|thumb|right|DHT22-Sensoren]] [[Ethersex]] unterstützt die preiswerten Temperatur-/Feuchtesensoren [[DHT|DHT11 und DHT22]], wobei letztere [[DHT#DHT11_vs_DHT22|um einiges genauer sind]]. Die Sensoren benötigen 5V Betriebsspannung und kommunizieren über je einen Pin mit dem Prozessor. Der Preis pro Stück liegt derzeit bei etwa 3.50 Euro (ebay/China). Wer die Trägheit und Ungenauigkeit der S300TH oder TX29DTH kennt, wünscht sich vermutlich Besseres; vor allem bei Berechnung von [http://de.wikipedia.org/wiki/Taupunkt Taupunkt] und [http://de.wikipedia.org/wiki/Luftfeuchtigkeit#Absolute_Luftfeuchtigkeit absoluter Feuchte], welche von der Genauigkeit der gemessenen Eingangsgrößen sehr profitieren. Berechnungen von Hand kann man beim [http://www.wetterochs.de/wetter/feuchte.html Wetterochs] durchführen. Die automatische Berechnung der absoluten Feuchte in FHEM wird im [http://forum.fhem.de/index.php/topic,21458.0.html Forum] erklärt. '''Einbindung in FHEM''' dht22m.classdef erstellen: <source lang="perl"> # Uebergabeparameter DHT22 ID 0...n params devID # Umsetzung in ECMD Befehle fuer DHT22 get DHT cmd {"dht temp %devID\n\000dht humid %devID\n"} get DHT expect "\d+.\d\n" get DHT postproc {\ s/(.*)\n(.*)\n/T: $1 H: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1;\ my $humidity = $2;\ my $state = $_;\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "humidity", $humidity, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs DHT22M=/opt/fhem/FHEM/dht22m.classdef </pre> Die Sensoren werden definiert: <pre> define Test0 ECMDDevice DHT22M 0 attr Test0 IODev NETIO_TEST define Test1 ECMDDevice DHT22M 1 attr Test1 IODev NETIO_TEST define Test2 ECMDDevice DHT22M 2 attr Test2 IODev NETIO_TEST define Test3 ECMDDevice DHT22M 3 attr Test3 IODev NETIO_TEST </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_DHT at +*00:04 get Test0 DHT;; get Test1 DHT;; get Test2 DHT;; get Test3 DHT attr Messung_DHT verbose 0 </pre> Fünfzehn Messwerte pro Stunde genügen den allermeisten Anforderungen. == [[BMP085 | BMP085/BMP180 Luftdrucksensor]] == [[File:BMP180.jpg|150px|thumb|right|BMP180 (unten links)]] Ethersex unterstützt den BMP085 (bzw. den BMP180; der Code ist identisch) über das [[I2C_(Deutsch) | I2C]]-Interface. Da der Sensor für 3.3V Betriebsspannung ausgelegt ist, muss entweder der I2C-Pegel angepasst oder der ATMega auf 3.3V adaptiert werden. Weiterhin sollte die Höhe über Null bekannt sein. Beispiel: Eine Abfrage per [[ECMD]] mit ''bmp085 pressnn 59000'' bedeutet, das ich 590m (59000cm) über NN wohne. Die im Sensor verfügbare Temperatur wird parallel ausgelesen. '''Einbindung in FHEM''' bmp085.classdef erstellen: <source lang="perl"> get BMP cmd {"bmp085 temp\n\000bmp085 pressnn 59000\n"} get BMP expect ".*" get BMP postproc {\ s/(.*)\n(.*)\n/T: $1 P: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1/10;\ my $pressure = sprintf("%.1f",$2/100);\ my $state = "T: $temperature P: $pressure";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "pressure", $pressure, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die Temperatur wird in °C mit einer Nachkommastelle gelesen, der Luftdruck in hPa bzw. mbar auf eine Nachkommastelle gerundet. Passende Readings werden erstellt. Das expect .* kann noch angepasst werden, um bei fehlerhaften Messwerten entsprechend zu reagieren. Die classdef wird in FHEM eingebunden (mehrere .classdef mit Doppelpunkt trennen: siehe [[Nutzung_in_FHEM_(Deutsch)#Grundlagen | Grundlagen]]): <pre> define NETIO_STK ECMD telnet 192.168.3.89:2701 attr NETIO_STK classdefs BMP=/opt/fhem/FHEM/bmp085.classdef </pre> Der Sensor wird definiert: <pre> define BMP180 ECMDDevice BMP attr BMP180 IODev NETIO_STK </pre> Das STATE ''kann'' mit Maßeinheiten versehen werden: <pre> attr BMP180 stateFormat { sprintf("%s°C %shPa", ReadingsVal("BMP180","temperature",0), ReadingsVal("BMP180","pressure",0)) ;; } </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_BMP at +*00:04 get BMP180 BMP attr Messung_BMP verbose 0 </pre> Dabei unterdrückt verbose 0 einen zusätzlichen (doppelten) Logeintrag des Messvorganges. == analoge Eingänge == todo == digitale Eingänge - proaktiv == Kontakte, die bei Zustandsänderung sofort in FHEM eine Meldung erzeugen sollen, kann man nicht zeitnah mit Polling abfragen. Diese Ereignisse, welche auch aus einem Control6-Script heraus generiert sein können, sollen selbst Meldung machen. Hierbei wird die ESEND-Funktion benutzt, mit welcher auch mehrere Ethersex'e untereinander kommunizieren können. Dabei ist es nicht relevant, ob das Device in FHEM per ECMDDevice bereits eingebunden wurde. Zuerst muss FHEM auf Port 2701 für Telnet-Verbindungen empfänglich werden: <pre> define telnetECMD telnet 2701 global </pre> Mit ''Watch io changes and react'' lässt sich per menuconfig bereits auf einfache Weise eine Abfrage von Portpins mit Generierung eines ESEND-Befehles bewerkstelligen. Das Beispiel soll zeigen, wie bei entsprechender Zustandsänderung an Pin PA0 an 192.168.178.10 ein FHEM-Befehl gesendet wird: <pre> ECMDTCP(PA0, RISING, 192.168.178.10, set Lampe on\n\n) ECMDTCP(PA0, FALLING, 192.168.178.10, set Lampe off\n\n) </pre> Jede Sequenz muss mit \n\n abgeschlossen werden, damit FHEM für weitere Befehle empfangsbereit bleibt. Falls man in FHEM flexibler bei der Weiterverarbeitung sein möchte, bietet sich eine dummy-notify-Kombination an. == [[Porterweiterungen_%28Deutsch%29#D.2FA-Wandler_mit_LTC1257 | LTC1257 D/A-Wandler]] == todo == HD44780 Punktmatrixdisplays == [[File:HD44780.jpg|150px|thumb|right|verschiedene HD44780 Displays (16x1 bis 40x4)]] Die beliebten Punktmatrix-Displays auf Basis [http://de.wikipedia.org/wiki/HD44780 HD44780] können vollumfänglich in FHEM beschrieben werden. Dabei wird vorrausgesetzt, das in [https://github.com/ethersex/ethersex/blob/master/hardware/lcd/hd44780.h /hardware/lcd/hd44780.h] beim entsprechenden Modell die passende Adressierung der Zeilen und die genutzte Zeilen-/Spaltenzahl vor dem Compilieren angepasst wurde. '''Einbindung in FHEM''' lcd.classdef erstellen: <source lang="perl"> # Umsetzung der ECMD Befehle set write params line col text set write cmd {"lcd goto %line %col\n\000lcd write %text\n"} set write expect "OK\n" set write postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set clear params col set clear cmd {"lcd clear %col\n"} set clear expect "OK\n" set clear postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set clear_all cmd {"lcd clear\n"} set clear_all expect "OK\n" set clear_all postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set lcd_bl params state set lcd_bl cmd {"lcd backlight %state\n"} set lcd_bl expect "OK\n" set lcd_bl postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} </source> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs LCD=/opt/fhem/FHEM/lcd.classdef </pre> Das Display wird definiert: <pre> define WZ_LCD ECMDDevice LCD attr WZ_LCD IODev NETIO_TEST </pre> Es stehen in FHEM folgende Befehle für das LCD bereit: {| border='1' | ''Befehl'' | ''Funktion'' |- | set WZ_LCD clear [ZEILE] | löscht den Inhalt einer ZEILE (0...3) |- | set WZ_LCD clear_all | löscht den Inhalt aller Zeilen |- | set WZ_LCD lcd_bl STATE | schaltet die Hintergrundbeleuchtung ein oder aus (STATE on oder off) |- | set WZ_LCD write [ZEILE] [SPALTE] [TEXT] | schreibt einen TEXT auf Position ZEILE SPALTE (0...n) |- |} Da ein im TEXT übergebenes Leerzeichen als weiterer Befehl interpretiert wird und zu einer Fehlermeldung führt, ist eine Übergabe nur mit \x20 im Text möglich. Das gilt auch für Umlaute. Anhand der [http://de.wikipedia.org/wiki/HD44780#Schrift_und_Zeichensatz Zeichensatztabelle] lassen sich ä durch \xE1, ü durch \xF5 und ö durch \xEF darstellen. Das ß wird mit \xE2 erreicht. Die Tabelle kann für manche Displays abweichend sein.<br /> Beispiel: ''set WZ_LCD write 0 0 Fenster\x20schlie\xE2en'' schreibt ein '''Fenster schließen''' auf's LCD. '''Komfortable Nutzung in FHEM mit DLCD''' Mit dem DLCD-Modul ([http://www.fhemwiki.de/wiki/DLCD Wiki-Beitrag] / [http://forum.fhem.de/index.php/topic,24519.0.html Foren-Beitrag]) für FHEM lässt sich jedes Display auf einfache Weise beschreiben. Dabei lassen sich bequem Readings von allen Devices nutzen, aufbereiten (formatieren, umrechnen, etc.) und entsprechend darstellen. Eine genaue Beschreibung hält der Wiki-Beitrag bereit; hier soll ein Beispiel gezeigt werden. Ziel war es, auf einem 16x1 LCD wechselweise ''Datum/Zeit => Klimadaten Keller => Datum/Zeit => Klimadaten Garten'' darzustellen. Die Anzeige rotiert im 15-Sekunden-Takt, so das zu 50% Datum/Zeit und je 25% die Werte aus dem Garten und dem Keller angezeigt werden. Es wird bereits im Modul jedes Leerzeichen mit \x20 übersetzt. Der Außensensor ist ein [http://www.elv.de/elv-funk-kombi-wettersensor-ks-300-2-br-inkl-hochwertigem-2-m-edelstahlmast-br-und-qualitaetsbatterien.html KS300] (bzw. KS200) von ELV. Mit etwas Formatierung und ein paar Leerzeichen lässt sich eine stets gleiche Positionierung der Daten erreichen, da die Zeile nicht explizit gelöscht wird. Auszug aus der fhem.cfg: <pre> define DLCD_WZ DLCD attr DLCD_WZ dlcdBlankspaceReplace \x20 attr DLCD_WZ dlcdCols 16 attr DLCD_WZ dlcdLine1 %date_WD_ger% %date_D%.%date_M_ger% %time_h%:%time_m% attr DLCD_WZ dlcdLine2 Keller:%1%/%2% attr DLCD_WZ dlcdLine3 %date_WD_ger% %date_D%.%date_M_ger% %time_h%:%time_m% attr DLCD_WZ dlcdLine4 Garten: %3%/%4% attr DLCD_WZ dlcdPhysicalRows 1 attr DLCD_WZ dlcdPollInterval 15 attr DLCD_WZ dlcdRows 4 attr DLCD_WZ dlcdScrolling 1 attr DLCD_WZ dlcdTriggerCmd set WZ_LCD write %L% 0 %T% attr DLCD_WZ dlcdVal1 Keller:temperature attr DLCD_WZ dlcdVal1formatnum 3+1 attr DLCD_WZ dlcdVal2 Keller:humidity attr DLCD_WZ dlcdVal2formatnum 3+1 attr DLCD_WZ dlcdVal3 KS300:temperature attr DLCD_WZ dlcdVal3formatnum 3+1+- attr DLCD_WZ dlcdVal4 KS300:humidity attr DLCD_WZ dlcdVal4formatnum 2+0 </pre> Das Ergebnis kann so aussehen: <gallery> DLCD_1.jpg|Zustand 1.-15. Sekunde DLCD_2.jpg|Zustand 16.-30. Sekunde DLCD_3.jpg|Zustand 31.-45. Sekunde DLCD_4.jpg|Zustand 46.-60. Sekunde </gallery> Die Formatierung bewirkt eine immer identische Platzierung der Daten. Der Außensensor hat keine Zehntelwerte bei der Feuchte, muss dafür aber negative Temperaturen darstellen. Der Innensensor zeigt Zehntelwerte, womit sich Tendenzen eher erkennen lassen. == [[RFM12_ASK_(Deutsch) | Intertechno schalten mit RFM12]] == todo == [[RFM12_ASK_(Deutsch) | IC2272 schalten mit RFM12]] == todo [[Category:Application|Application]] fd5841c0b6dd2cda1368c51d8d85fc64277ef8eb 1367 1366 2014-10-14T07:13:52Z Kpwg 721 Schnickschnack/ doppelte Erklärung entfernt; Kleinigkeiten ergänzt wikitext text/x-wiki {{i18n|Nutzung in FHEM}} [http://www.fhemwiki.de/wiki/Hauptseite FHEM] ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um diverse per Funk und Kabel angebundene Komponenten aus dem Bereich der Hausautomation zu steuern. Er ist lizensiert unter der GPL v2. Das [http://www.pollin.de/shop/suchergebnis.html?S_TEXT=810+058 AVR-Net-IO] von [http://www.pollin.de Pollin] mit [[Ethersex]] dient als [http://www.fhemwiki.de/wiki/AVR-NET-IO preisgünstiger Einstieg in die Hausautomatisierung]. Verwendbar ist aber auch jede andere [[Supported_Boards_(Deutsch) | Hardware]], die von Ethersex unterstützt wird (Arduino, eigene Entwicklungen, etc.). Über [[ECMD]] lassen sich dabei theoretisch alle in [[Ethersex]] vorhandenen [[ECMD_Protocols_%28Deutsch%29 | Möglichkeiten]] nutzen, sofern in FHEM entsprechende [http://fhem.de/commandref.html#ECMD ECMD-Devices] definiert und eingebunden werden, die passende Klassendefinition exisitert und die Aktion ausgelöst wird. == Grundlagen == Ausgehend von einem fertigen und per Telnet erreichbaren Ethersex muss in FHEM zuerst das entsprechende Device definiert werden. <pre> define NETIO_WZ ECMD telnet 192.168.3.81:2701 </pre> Eine serielle Anbindung kann mit ''define <name> ECMD serial <SerialDevice>[<@BaudRate>]'' alternativ erfolgen. Anschließend werden die erstellten .classdef-Konfigurationsdateien der einzelnen Funktionen dem System bekannt gemacht. In diesen .classdef-Dateien (Name und Endung sind frei wählbar!) wird die Schnittstelle zwischen FHEM und ECMD/Ethersex definiert. Dabei können mit perl übergebene Parameter und empfangene Daten bearbeitet sowie die in FHEM gebräuchlichen Readings erstellt werden. <pre> attr NETIO_WZ classdefs RFM12_2272=/opt/fhem/FHEM/rfm12_2272.classdef:RFM12_IT=/opt/fhem/FHEM/rfm12_it.classdef:LCD=/opt/fhem/FHEM/lcd.classdef:DHT22=/opt/fhem/FHEM/dht22.classdef:1WIRE=/opt/fhem/FHEM/1wire.classdef </pre> Die Definitionen für IC2272, Intertechno, HD44780-LCD, DHT22 und 1wire sind nun eingebunden. In den folgenden Abschnitten wird auf die einzelnen Devices näher eingegangen. Generell sind Pfade und IP-Adressen sowie übergebene Parameter noch entsprechend der eigenen Konfiguration anzupassen. == [[Onewire_(Deutsch) | 1-Wire Temperatursensoren]] == [[File:DS18B20.jpg|150px|thumb|right|DS18B20-Sensoren]] Die 1wire-Temperatursensoren DS18B20 oder DS18S20 werden im [[Onewire_(Deutsch)#Polling_Modus | Polling Modus]] abgefragt. Das macht die zyklische Abfrage aus FHEM heraus wesentlich einfacher. Eine Polling-Zeit von mindestens 30 Sekunden ist absolut ausreichend.Im Vorfeld sollte man sich die [[Onewire_(Deutsch)#Benennung_von_Sensoren | ROM-Codes der Sensoren]] notieren, da diese nachher benötigt werden. 1w-temp.classdef erstellen: <source lang="perl"> # Uebergabeparameter Onewire Rom-Code params devID # Umsetzung in ECMD Befehle 1w get = Temperatur auslesen get 1W cmd {"1w get %devID\n"} get 1W expect "\d+.\d\n" get 1W postproc {\ s/\n//g;\ my $hash = $defs{%NAME};\ my $temperature = $_;\ my $state = "T: $temperature";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die classdef wird eingebunden: <pre> define NETIO_KU ECMD telnet 192.168.3.82:2701 attr NETIO_KU classdefs 1W-TEMP=/opt/fhem/FHEM/1w-temp.classdef </pre> Die Sensoren werden anhand des ROM-Code definiert: <pre> define HZ_WW ECMDDevice 1W-TEMP 284c8820050003d4 attr HZ_WW IODev NETIO_KU define HZ_VL ECMDDevice 1W-TEMP 2890a520050003d7 attr HZ_VL IODev NETIO_KU </pre> Eine zyklische Messung pro Minute lässt sich in dieser Form auslösen: <pre> define Messung_1w at +*00:01 get HZ_WW 1W;; get HZ_VL 1W attr Messung_1w verbose 1 </pre> == [[DHT|DHT22 Temperatur-/Feuchtesensoren]] == [[File:DHT22.jpg|150px|thumb|right|DHT22-Sensoren]] [[Ethersex]] unterstützt die preiswerten Temperatur-/Feuchtesensoren [[DHT|DHT11 und DHT22]], wobei letztere [[DHT#DHT11_vs_DHT22|um einiges genauer sind]]. Die Sensoren benötigen 5V Betriebsspannung und kommunizieren über je einen Pin mit dem Prozessor. Der Preis pro Stück liegt derzeit bei etwa 3.50 Euro (ebay/China). Wer die Trägheit und Ungenauigkeit der S300TH oder TX29DTH kennt, wünscht sich vermutlich Besseres; vor allem bei Berechnung von [http://de.wikipedia.org/wiki/Taupunkt Taupunkt] und [http://de.wikipedia.org/wiki/Luftfeuchtigkeit#Absolute_Luftfeuchtigkeit absoluter Feuchte], welche von der Genauigkeit der gemessenen Eingangsgrößen sehr profitieren. Berechnungen von Hand kann man beim [http://www.wetterochs.de/wetter/feuchte.html Wetterochs] durchführen. Die automatische Berechnung der absoluten Feuchte in FHEM wird im [http://forum.fhem.de/index.php/topic,21458.0.html Forum] erklärt. '''Einbindung in FHEM''' dht22m.classdef erstellen: <source lang="perl"> # Uebergabeparameter DHT22 ID 0...n params devID # Umsetzung in ECMD Befehle fuer DHT22 get DHT cmd {"dht temp %devID\n\000dht humid %devID\n"} get DHT expect "\d+.\d\n" get DHT postproc {\ s/(.*)\n(.*)\n/T: $1 H: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1;\ my $humidity = $2;\ my $state = $_;\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "humidity", $humidity, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs DHT22M=/opt/fhem/FHEM/dht22m.classdef </pre> Die Sensoren werden definiert: <pre> define Test0 ECMDDevice DHT22M 0 attr Test0 IODev NETIO_TEST define Test1 ECMDDevice DHT22M 1 attr Test1 IODev NETIO_TEST define Test2 ECMDDevice DHT22M 2 attr Test2 IODev NETIO_TEST define Test3 ECMDDevice DHT22M 3 attr Test3 IODev NETIO_TEST </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_DHT at +*00:04 get Test0 DHT;; get Test1 DHT;; get Test2 DHT;; get Test3 DHT attr Messung_DHT verbose 0 </pre> Fünfzehn Messwerte pro Stunde genügen den allermeisten Anforderungen. == [[BMP085 | BMP085/BMP180 Luftdrucksensor]] == [[File:BMP180.jpg|150px|thumb|right|BMP180 (unten links)]] Ethersex unterstützt den BMP085 (bzw. den BMP180; der Code ist identisch) über das [[I2C_(Deutsch) | I2C]]-Interface. Da der Sensor für 3.3V Betriebsspannung ausgelegt ist, muss entweder der I2C-Pegel angepasst oder der ATMega auf 3.3V adaptiert werden. Weiterhin sollte die Höhe über Null bekannt sein. Beispiel: Eine Abfrage per [[ECMD]] mit ''bmp085 pressnn 59000'' bedeutet, das ich 590m (59000cm) über NN wohne. Die im Sensor verfügbare Temperatur wird parallel ausgelesen. '''Einbindung in FHEM''' bmp085.classdef erstellen: <source lang="perl"> get BMP cmd {"bmp085 temp\n\000bmp085 pressnn 59000\n"} get BMP expect ".*" get BMP postproc {\ s/(.*)\n(.*)\n/T: $1 P: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1/10;\ my $pressure = sprintf("%.1f",$2/100);\ my $state = "T: $temperature P: $pressure";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "pressure", $pressure, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die Temperatur wird in °C mit einer Nachkommastelle gelesen, der Luftdruck in hPa bzw. mbar auf eine Nachkommastelle gerundet. Passende Readings werden erstellt. Das expect .* kann noch angepasst werden, um bei fehlerhaften Messwerten entsprechend zu reagieren. Die classdef wird in FHEM eingebunden (mehrere .classdef mit Doppelpunkt trennen: siehe [[Nutzung_in_FHEM_(Deutsch)#Grundlagen | Grundlagen]]): <pre> define NETIO_STK ECMD telnet 192.168.3.89:2701 attr NETIO_STK classdefs BMP=/opt/fhem/FHEM/bmp085.classdef </pre> Der Sensor wird definiert: <pre> define BMP180 ECMDDevice BMP attr BMP180 IODev NETIO_STK </pre> Das STATE ''kann'' mit Maßeinheiten versehen werden: <pre> attr BMP180 stateFormat { sprintf("%s°C %shPa", ReadingsVal("BMP180","temperature",0), ReadingsVal("BMP180","pressure",0)) ;; } </pre> Eine zyklische Messung alle 4 Minuten erfolgt wieder mit ''at'': <pre> define Messung_BMP at +*00:04 get BMP180 BMP attr Messung_BMP verbose 0 </pre> Dabei unterdrückt verbose 0 einen zusätzlichen (doppelten) Logeintrag des Messvorganges. == analoge Eingänge abfragen == todo == digitale Eingänge abfragen == todo == digitale Eingänge - proaktiv == Kontakte, die bei Zustandsänderung sofort in FHEM eine Meldung erzeugen sollen, kann man nicht zeitnah mit Polling abfragen. Diese Ereignisse, welche auch aus einem Control6-Script heraus generiert sein können, sollen selbst Meldung machen. Hierbei wird die ESEND-Funktion benutzt, mit welcher auch mehrere Ethersex'e untereinander kommunizieren können. Dabei ist es nicht relevant, ob das Device in FHEM per ECMDDevice bereits eingebunden wurde. Zuerst muss FHEM auf Port 2701 für Telnet-Verbindungen empfänglich werden: <pre> define telnetECMD telnet 2701 global </pre> Mit ''Watch io changes and react'' lässt sich per menuconfig bereits auf einfache Weise eine Abfrage von Portpins mit Generierung eines ESEND-Befehles bewerkstelligen. Das Beispiel soll zeigen, wie bei entsprechender Zustandsänderung an Pin PA0 an 192.168.178.10 ein FHEM-Befehl gesendet wird: <pre> ECMDTCP(PA0, RISING, 192.168.178.10, set Lampe on\n\n) ECMDTCP(PA0, FALLING, 192.168.178.10, set Lampe off\n\n) </pre> Jede Sequenz muss mit \n\n abgeschlossen werden, damit FHEM für weitere Befehle empfangsbereit bleibt. Falls man in FHEM flexibler bei der Weiterverarbeitung sein möchte, bietet sich eine dummy-notify-Kombination an. == [[Porterweiterungen_%28Deutsch%29#D.2FA-Wandler_mit_LTC1257 | LTC1257 D/A-Wandler]] == todo == HD44780 Punktmatrixdisplays == [[File:HD44780.jpg|150px|thumb|right|verschiedene HD44780 Displays (16x1 bis 40x4)]] Die beliebten Punktmatrix-Displays auf Basis [http://de.wikipedia.org/wiki/HD44780 HD44780] können vollumfänglich in FHEM beschrieben werden. Dabei wird vorrausgesetzt, das in [https://github.com/ethersex/ethersex/blob/master/hardware/lcd/hd44780.h /hardware/lcd/hd44780.h] beim entsprechenden Modell die passende Adressierung der Zeilen und die genutzte Zeilen-/Spaltenzahl vor dem Compilieren angepasst wurde. '''Einbindung in FHEM''' lcd.classdef erstellen: <source lang="perl"> # Umsetzung der ECMD Befehle set write params line col text set write cmd {"lcd goto %line %col\n\000lcd write %text\n"} set write expect "OK\n" set write postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set clear params col set clear cmd {"lcd clear %col\n"} set clear expect "OK\n" set clear postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set clear_all cmd {"lcd clear\n"} set clear_all expect "OK\n" set clear_all postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set lcd_bl params state set lcd_bl cmd {"lcd backlight %state\n"} set lcd_bl expect "OK\n" set lcd_bl postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} </source> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs LCD=/opt/fhem/FHEM/lcd.classdef </pre> Das Display wird definiert: <pre> define WZ_LCD ECMDDevice LCD attr WZ_LCD IODev NETIO_TEST </pre> Es stehen in FHEM folgende Befehle für das LCD bereit: {| border='1' | ''Befehl'' | ''Funktion'' |- | set WZ_LCD clear [ZEILE] | löscht den Inhalt einer ZEILE (0...3) |- | set WZ_LCD clear_all | löscht den Inhalt aller Zeilen |- | set WZ_LCD lcd_bl STATE | schaltet die Hintergrundbeleuchtung ein oder aus (STATE on oder off) |- | set WZ_LCD write [ZEILE] [SPALTE] [TEXT] | schreibt einen TEXT auf Position ZEILE SPALTE (0...n) |- |} Da ein im TEXT übergebenes Leerzeichen als weiterer Befehl interpretiert wird und zu einer Fehlermeldung führt, ist eine Übergabe nur mit \x20 im Text möglich. Das gilt auch für Umlaute. Anhand der [http://de.wikipedia.org/wiki/HD44780#Schrift_und_Zeichensatz Zeichensatztabelle] lassen sich ä durch \xE1, ü durch \xF5 und ö durch \xEF darstellen. Das ß wird mit \xE2 erreicht. Die Tabelle kann für manche Displays abweichend sein.<br /> Beispiel: ''set WZ_LCD write 0 0 Fenster\x20schlie\xE2en'' schreibt ein '''Fenster schließen''' auf's LCD. '''Komfortable Nutzung in FHEM mit DLCD''' Mit dem DLCD-Modul ([http://www.fhemwiki.de/wiki/DLCD Wiki-Beitrag] / [http://forum.fhem.de/index.php/topic,24519.0.html Foren-Beitrag]) für FHEM lässt sich jedes Display auf einfache Weise beschreiben. Dabei lassen sich bequem Readings von allen Devices nutzen, aufbereiten (formatieren, umrechnen, etc.) und entsprechend darstellen. Eine genaue Beschreibung hält der Wiki-Beitrag bereit; hier soll ein Beispiel gezeigt werden. Ziel war es, auf einem 16x1 LCD wechselweise ''Datum/Zeit => Klimadaten Keller => Datum/Zeit => Klimadaten Garten'' darzustellen. Die Anzeige rotiert im 15-Sekunden-Takt, so das zu 50% Datum/Zeit und je 25% die Werte aus dem Garten und dem Keller angezeigt werden. Es wird bereits im Modul jedes Leerzeichen mit \x20 übersetzt. Der Außensensor ist ein [http://www.elv.de/elv-funk-kombi-wettersensor-ks-300-2-br-inkl-hochwertigem-2-m-edelstahlmast-br-und-qualitaetsbatterien.html KS300] (bzw. KS200) von ELV. Mit etwas Formatierung und ein paar Leerzeichen lässt sich eine stets gleiche Positionierung der Daten erreichen, da die Zeile nicht explizit gelöscht wird. Auszug aus der fhem.cfg: <pre> define DLCD_WZ DLCD attr DLCD_WZ dlcdBlankspaceReplace \x20 attr DLCD_WZ dlcdCols 16 attr DLCD_WZ dlcdLine1 %date_WD_ger% %date_D%.%date_M_ger% %time_h%:%time_m% attr DLCD_WZ dlcdLine2 Keller:%1%/%2% attr DLCD_WZ dlcdLine3 %date_WD_ger% %date_D%.%date_M_ger% %time_h%:%time_m% attr DLCD_WZ dlcdLine4 Garten: %3%/%4% attr DLCD_WZ dlcdPhysicalRows 1 attr DLCD_WZ dlcdPollInterval 15 attr DLCD_WZ dlcdRows 4 attr DLCD_WZ dlcdScrolling 1 attr DLCD_WZ dlcdTriggerCmd set WZ_LCD write %L% 0 %T% attr DLCD_WZ dlcdVal1 Keller:temperature attr DLCD_WZ dlcdVal1formatnum 3+1 attr DLCD_WZ dlcdVal2 Keller:humidity attr DLCD_WZ dlcdVal2formatnum 3+1 attr DLCD_WZ dlcdVal3 KS300:temperature attr DLCD_WZ dlcdVal3formatnum 3+1+- attr DLCD_WZ dlcdVal4 KS300:humidity attr DLCD_WZ dlcdVal4formatnum 2+0 </pre> Das Ergebnis kann so aussehen: <gallery> DLCD_1.jpg|Zustand 1.-15. Sekunde DLCD_2.jpg|Zustand 16.-30. Sekunde DLCD_3.jpg|Zustand 31.-45. Sekunde DLCD_4.jpg|Zustand 46.-60. Sekunde </gallery> Die Formatierung bewirkt eine immer identische Platzierung der Daten. Der Außensensor hat keine Zehntelwerte bei der Feuchte, muss dafür aber negative Temperaturen darstellen. Der Innensensor zeigt Zehntelwerte, womit sich Tendenzen eher erkennen lassen. == [[RFM12_ASK_(Deutsch) | Intertechno schalten mit RFM12]] == todo == [[RFM12_ASK_(Deutsch) | IC2272 schalten mit RFM12]] == todo [[Category:Application|Application]] ba47eb4053fab738f924eafedfaa1e35530e2107 1403 1367 2014-10-16T15:14:44Z Kpwg 721 /* analoge Eingänge abfragen */ wikitext text/x-wiki {{i18n|Nutzung in FHEM}} [http://www.fhemwiki.de/wiki/Hauptseite FHEM] ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um diverse per Funk und Kabel angebundene Komponenten aus dem Bereich der Hausautomation zu steuern. Er ist lizensiert unter der GPL v2. Das [http://www.pollin.de/shop/suchergebnis.html?S_TEXT=810+058 AVR-Net-IO] von [http://www.pollin.de Pollin] mit [[Ethersex]] dient als [http://www.fhemwiki.de/wiki/AVR-NET-IO preisgünstiger Einstieg in die Hausautomatisierung]. Verwendbar ist aber auch jede andere [[Supported_Boards_(Deutsch) | Hardware]], die von Ethersex unterstützt wird (Arduino, eigene Entwicklungen, etc.). Über [[ECMD]] lassen sich dabei theoretisch alle in [[Ethersex]] vorhandenen [[ECMD_Protocols_%28Deutsch%29 | Möglichkeiten]] nutzen, sofern in FHEM entsprechende [http://fhem.de/commandref.html#ECMD ECMD-Devices] definiert und eingebunden werden, die passende Klassendefinition exisitert und die Aktion ausgelöst wird. == Grundlagen == Ausgehend von einem fertigen und per Telnet erreichbaren Ethersex muss in FHEM zuerst das entsprechende Device definiert werden. <pre> define NETIO_WZ ECMD telnet 192.168.3.81:2701 </pre> Eine serielle Anbindung kann mit ''define <name> ECMD serial <SerialDevice>[<@BaudRate>]'' alternativ erfolgen. Anschließend werden die erstellten .classdef-Konfigurationsdateien der einzelnen Funktionen dem System bekannt gemacht. In diesen .classdef-Dateien (Name und Endung sind frei wählbar!) wird die Schnittstelle zwischen FHEM und ECMD/Ethersex definiert. Dabei können mit perl übergebene Parameter und empfangene Daten bearbeitet sowie die in FHEM gebräuchlichen Readings erstellt werden. <pre> attr NETIO_WZ classdefs RFM12_2272=/opt/fhem/FHEM/rfm12_2272.classdef:RFM12_IT=/opt/fhem/FHEM/rfm12_it.classdef:LCD=/opt/fhem/FHEM/lcd.classdef:DHT22=/opt/fhem/FHEM/dht22.classdef:1WIRE=/opt/fhem/FHEM/1wire.classdef </pre> Die Definitionen für IC2272, Intertechno, HD44780-LCD, DHT22 und 1wire sind nun eingebunden. In den folgenden Abschnitten wird auf die einzelnen Devices näher eingegangen. Generell sind Pfade und IP-Adressen sowie übergebene Parameter noch entsprechend der eigenen Konfiguration anzupassen. == [[Onewire_(Deutsch) | 1-Wire Temperatursensoren]] == [[File:DS18B20.jpg|150px|thumb|right|DS18B20-Sensoren]] Die 1wire-Temperatursensoren DS18B20 oder DS18S20 werden im [[Onewire_(Deutsch)#Polling_Modus | Polling Modus]] abgefragt. Das macht die zyklische Abfrage aus FHEM heraus wesentlich einfacher. Eine Polling-Zeit von mindestens 30 Sekunden ist absolut ausreichend.Im Vorfeld sollte man sich die [[Onewire_(Deutsch)#Benennung_von_Sensoren | ROM-Codes der Sensoren]] notieren, da diese nachher benötigt werden. 1w-temp.classdef erstellen: <source lang="perl"> # Uebergabeparameter Onewire Rom-Code params devID # Umsetzung in ECMD Befehle 1w get = Temperatur auslesen get 1W cmd {"1w get %devID\n"} get 1W expect "\d+.\d\n" get 1W postproc {\ s/\n//g;\ my $hash = $defs{%NAME};\ my $temperature = $_;\ my $state = "T: $temperature";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die classdef wird eingebunden: <pre> define NETIO_KU ECMD telnet 192.168.3.82:2701 attr NETIO_KU classdefs 1W-TEMP=/opt/fhem/FHEM/1w-temp.classdef </pre> Die Sensoren werden anhand des ROM-Code definiert: <pre> define HZ_WW ECMDDevice 1W-TEMP 284c8820050003d4 attr HZ_WW IODev NETIO_KU define HZ_VL ECMDDevice 1W-TEMP 2890a520050003d7 attr HZ_VL IODev NETIO_KU </pre> Eine zyklische Messung pro Minute lässt sich in dieser Form auslösen: <pre> define Messung_1w at +*00:01 get HZ_WW 1W;; get HZ_VL 1W attr Messung_1w verbose 1 </pre> == [[DHT|DHT22 Temperatur-/Feuchtesensoren]] == [[File:DHT22.jpg|150px|thumb|right|DHT22-Sensoren]] [[Ethersex]] unterstützt die preiswerten Temperatur-/Feuchtesensoren [[DHT|DHT11 und DHT22]], wobei letztere [[DHT#DHT11_vs_DHT22|um einiges genauer sind]]. Die Sensoren benötigen 5V Betriebsspannung und kommunizieren über je einen Pin mit dem Prozessor. Der Preis pro Stück liegt derzeit bei etwa 3.50 Euro (ebay/China). Wer die Trägheit und Ungenauigkeit der S300TH oder TX29DTH kennt, wünscht sich vermutlich Besseres; vor allem bei Berechnung von [http://de.wikipedia.org/wiki/Taupunkt Taupunkt] und [http://de.wikipedia.org/wiki/Luftfeuchtigkeit#Absolute_Luftfeuchtigkeit absoluter Feuchte], welche von der Genauigkeit der gemessenen Eingangsgrößen sehr profitieren. Berechnungen von Hand kann man beim [http://www.wetterochs.de/wetter/feuchte.html Wetterochs] durchführen. Die automatische Berechnung der absoluten Feuchte in FHEM wird im [http://forum.fhem.de/index.php/topic,21458.0.html Forum] erklärt. '''Einbindung in FHEM''' dht22m.classdef erstellen: <source lang="perl"> # Uebergabeparameter DHT22 ID 0...n params devID # Umsetzung in ECMD Befehle fuer DHT22 get DHT cmd {"dht temp %devID\n\000dht humid %devID\n"} get DHT expect "\d+.\d\n" get DHT postproc {\ s/(.*)\n(.*)\n/T: $1 H: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1;\ my $humidity = $2;\ my $state = $_;\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "humidity", $humidity, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs DHT22M=/opt/fhem/FHEM/dht22m.classdef </pre> Die Sensoren werden definiert: <pre> define Test0 ECMDDevice DHT22M 0 attr Test0 IODev NETIO_TEST define Test1 ECMDDevice DHT22M 1 attr Test1 IODev NETIO_TEST define Test2 ECMDDevice DHT22M 2 attr Test2 IODev NETIO_TEST define Test3 ECMDDevice DHT22M 3 attr Test3 IODev NETIO_TEST </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_DHT at +*00:04 get Test0 DHT;; get Test1 DHT;; get Test2 DHT;; get Test3 DHT attr Messung_DHT verbose 0 </pre> Fünfzehn Messwerte pro Stunde genügen den allermeisten Anforderungen. == [[BMP085 | BMP085/BMP180 Luftdrucksensor]] == [[File:BMP180.jpg|150px|thumb|right|BMP180 (unten links)]] Ethersex unterstützt den BMP085 (bzw. den BMP180; der Code ist identisch) über das [[I2C_(Deutsch) | I2C]]-Interface. Da der Sensor für 3.3V Betriebsspannung ausgelegt ist, muss entweder der I2C-Pegel angepasst oder der ATMega auf 3.3V adaptiert werden. Weiterhin sollte die Höhe über Null bekannt sein. Beispiel: Eine Abfrage per [[ECMD]] mit ''bmp085 pressnn 59000'' bedeutet, das ich 590m (59000cm) über NN wohne. Die im Sensor verfügbare Temperatur wird parallel ausgelesen. '''Einbindung in FHEM''' bmp085.classdef erstellen: <source lang="perl"> get BMP cmd {"bmp085 temp\n\000bmp085 pressnn 59000\n"} get BMP expect ".*" get BMP postproc {\ s/(.*)\n(.*)\n/T: $1 P: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1/10;\ my $pressure = sprintf("%.1f",$2/100);\ my $state = "T: $temperature P: $pressure";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "pressure", $pressure, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die Temperatur wird in °C mit einer Nachkommastelle gelesen, der Luftdruck in hPa bzw. mbar auf eine Nachkommastelle gerundet. Passende Readings werden erstellt. Das expect .* kann noch angepasst werden, um bei fehlerhaften Messwerten entsprechend zu reagieren. Die classdef wird in FHEM eingebunden (mehrere .classdef mit Doppelpunkt trennen: siehe [[Nutzung_in_FHEM_(Deutsch)#Grundlagen | Grundlagen]]): <pre> define NETIO_STK ECMD telnet 192.168.3.89:2701 attr NETIO_STK classdefs BMP=/opt/fhem/FHEM/bmp085.classdef </pre> Der Sensor wird definiert: <pre> define BMP180 ECMDDevice BMP attr BMP180 IODev NETIO_STK </pre> Das STATE ''kann'' mit Maßeinheiten versehen werden: <pre> attr BMP180 stateFormat { sprintf("%s°C %shPa", ReadingsVal("BMP180","temperature",0), ReadingsVal("BMP180","pressure",0)) ;; } </pre> Eine zyklische Messung alle 4 Minuten erfolgt wieder mit ''at'': <pre> define Messung_BMP at +*00:04 get BMP180 BMP attr Messung_BMP verbose 0 </pre> Dabei unterdrückt verbose 0 einen zusätzlichen (doppelten) Logeintrag des Messvorganges. == analoge Eingänge abfragen == Die analogen Eingänge des ATMega sind recht simpel abzufragen. Dabei werden die hexadezimalen Werte gleich dezimal gewandelt, um die Weiterverarbeitung zu erleichtern. '''Einbindung in FHEM''' adc.classdef erstellen: <source lang="perl"> get value cmd {"adc get %PortID\n"} params PortID get value expect ".*" get value postproc {\ my $hexval = hex(trim("$_"));\ my $hash = $defs{%NAME};\ readingsSingleUpdate($hash, "state", $hexval, 1);\ } </source> Die classdef wird eingebunden: <pre> define NETIO_KU ECMD telnet 192.168.3.89:2701 attr NETIO_KU classdefs ADC=/opt/fhem/FHEM/adc.classdef </pre> Die Sensoren an den ersten beiden Ports werden definiert: <pre> define MP_0 ECMDDevice ADC 0 attr MP_0 IODev NETIO_KU define MP_1 ECMDDevice ADC 1 attr MP_1 IODev NETIO_KU </pre> Eine zyklische Messung alle 60 Sekunden funktioniert damit: <pre> define Messung_adc at +*00:01 get MP_0 value;; get MP_1 value attr Messung_adc verbose 0 </pre> == digitale Eingänge abfragen == todo == digitale Eingänge - proaktiv == Kontakte, die bei Zustandsänderung sofort in FHEM eine Meldung erzeugen sollen, kann man nicht zeitnah mit Polling abfragen. Diese Ereignisse, welche auch aus einem Control6-Script heraus generiert sein können, sollen selbst Meldung machen. Hierbei wird die ESEND-Funktion benutzt, mit welcher auch mehrere Ethersex'e untereinander kommunizieren können. Dabei ist es nicht relevant, ob das Device in FHEM per ECMDDevice bereits eingebunden wurde. Zuerst muss FHEM auf Port 2701 für Telnet-Verbindungen empfänglich werden: <pre> define telnetECMD telnet 2701 global </pre> Mit ''Watch io changes and react'' lässt sich per menuconfig bereits auf einfache Weise eine Abfrage von Portpins mit Generierung eines ESEND-Befehles bewerkstelligen. Das Beispiel soll zeigen, wie bei entsprechender Zustandsänderung an Pin PA0 an 192.168.178.10 ein FHEM-Befehl gesendet wird: <pre> ECMDTCP(PA0, RISING, 192.168.178.10, set Lampe on\n\n) ECMDTCP(PA0, FALLING, 192.168.178.10, set Lampe off\n\n) </pre> Jede Sequenz muss mit \n\n abgeschlossen werden, damit FHEM für weitere Befehle empfangsbereit bleibt. Falls man in FHEM flexibler bei der Weiterverarbeitung sein möchte, bietet sich eine dummy-notify-Kombination an. == [[Porterweiterungen_%28Deutsch%29#D.2FA-Wandler_mit_LTC1257 | LTC1257 D/A-Wandler]] == todo == HD44780 Punktmatrixdisplays == [[File:HD44780.jpg|150px|thumb|right|verschiedene HD44780 Displays (16x1 bis 40x4)]] Die beliebten Punktmatrix-Displays auf Basis [http://de.wikipedia.org/wiki/HD44780 HD44780] können vollumfänglich in FHEM beschrieben werden. Dabei wird vorrausgesetzt, das in [https://github.com/ethersex/ethersex/blob/master/hardware/lcd/hd44780.h /hardware/lcd/hd44780.h] beim entsprechenden Modell die passende Adressierung der Zeilen und die genutzte Zeilen-/Spaltenzahl vor dem Compilieren angepasst wurde. '''Einbindung in FHEM''' lcd.classdef erstellen: <source lang="perl"> # Umsetzung der ECMD Befehle set write params line col text set write cmd {"lcd goto %line %col\n\000lcd write %text\n"} set write expect "OK\n" set write postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set clear params col set clear cmd {"lcd clear %col\n"} set clear expect "OK\n" set clear postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set clear_all cmd {"lcd clear\n"} set clear_all expect "OK\n" set clear_all postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set lcd_bl params state set lcd_bl cmd {"lcd backlight %state\n"} set lcd_bl expect "OK\n" set lcd_bl postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} </source> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs LCD=/opt/fhem/FHEM/lcd.classdef </pre> Das Display wird definiert: <pre> define WZ_LCD ECMDDevice LCD attr WZ_LCD IODev NETIO_TEST </pre> Es stehen in FHEM folgende Befehle für das LCD bereit: {| border='1' | ''Befehl'' | ''Funktion'' |- | set WZ_LCD clear [ZEILE] | löscht den Inhalt einer ZEILE (0...3) |- | set WZ_LCD clear_all | löscht den Inhalt aller Zeilen |- | set WZ_LCD lcd_bl STATE | schaltet die Hintergrundbeleuchtung ein oder aus (STATE on oder off) |- | set WZ_LCD write [ZEILE] [SPALTE] [TEXT] | schreibt einen TEXT auf Position ZEILE SPALTE (0...n) |- |} Da ein im TEXT übergebenes Leerzeichen als weiterer Befehl interpretiert wird und zu einer Fehlermeldung führt, ist eine Übergabe nur mit \x20 im Text möglich. Das gilt auch für Umlaute. Anhand der [http://de.wikipedia.org/wiki/HD44780#Schrift_und_Zeichensatz Zeichensatztabelle] lassen sich ä durch \xE1, ü durch \xF5 und ö durch \xEF darstellen. Das ß wird mit \xE2 erreicht. Die Tabelle kann für manche Displays abweichend sein.<br /> Beispiel: ''set WZ_LCD write 0 0 Fenster\x20schlie\xE2en'' schreibt ein '''Fenster schließen''' auf's LCD. '''Komfortable Nutzung in FHEM mit DLCD''' Mit dem DLCD-Modul ([http://www.fhemwiki.de/wiki/DLCD Wiki-Beitrag] / [http://forum.fhem.de/index.php/topic,24519.0.html Foren-Beitrag]) für FHEM lässt sich jedes Display auf einfache Weise beschreiben. Dabei lassen sich bequem Readings von allen Devices nutzen, aufbereiten (formatieren, umrechnen, etc.) und entsprechend darstellen. Eine genaue Beschreibung hält der Wiki-Beitrag bereit; hier soll ein Beispiel gezeigt werden. Ziel war es, auf einem 16x1 LCD wechselweise ''Datum/Zeit => Klimadaten Keller => Datum/Zeit => Klimadaten Garten'' darzustellen. Die Anzeige rotiert im 15-Sekunden-Takt, so das zu 50% Datum/Zeit und je 25% die Werte aus dem Garten und dem Keller angezeigt werden. Es wird bereits im Modul jedes Leerzeichen mit \x20 übersetzt. Der Außensensor ist ein [http://www.elv.de/elv-funk-kombi-wettersensor-ks-300-2-br-inkl-hochwertigem-2-m-edelstahlmast-br-und-qualitaetsbatterien.html KS300] (bzw. KS200) von ELV. Mit etwas Formatierung und ein paar Leerzeichen lässt sich eine stets gleiche Positionierung der Daten erreichen, da die Zeile nicht explizit gelöscht wird. Auszug aus der fhem.cfg: <pre> define DLCD_WZ DLCD attr DLCD_WZ dlcdBlankspaceReplace \x20 attr DLCD_WZ dlcdCols 16 attr DLCD_WZ dlcdLine1 %date_WD_ger% %date_D%.%date_M_ger% %time_h%:%time_m% attr DLCD_WZ dlcdLine2 Keller:%1%/%2% attr DLCD_WZ dlcdLine3 %date_WD_ger% %date_D%.%date_M_ger% %time_h%:%time_m% attr DLCD_WZ dlcdLine4 Garten: %3%/%4% attr DLCD_WZ dlcdPhysicalRows 1 attr DLCD_WZ dlcdPollInterval 15 attr DLCD_WZ dlcdRows 4 attr DLCD_WZ dlcdScrolling 1 attr DLCD_WZ dlcdTriggerCmd set WZ_LCD write %L% 0 %T% attr DLCD_WZ dlcdVal1 Keller:temperature attr DLCD_WZ dlcdVal1formatnum 3+1 attr DLCD_WZ dlcdVal2 Keller:humidity attr DLCD_WZ dlcdVal2formatnum 3+1 attr DLCD_WZ dlcdVal3 KS300:temperature attr DLCD_WZ dlcdVal3formatnum 3+1+- attr DLCD_WZ dlcdVal4 KS300:humidity attr DLCD_WZ dlcdVal4formatnum 2+0 </pre> Das Ergebnis kann so aussehen: <gallery> DLCD_1.jpg|Zustand 1.-15. Sekunde DLCD_2.jpg|Zustand 16.-30. Sekunde DLCD_3.jpg|Zustand 31.-45. Sekunde DLCD_4.jpg|Zustand 46.-60. Sekunde </gallery> Die Formatierung bewirkt eine immer identische Platzierung der Daten. Der Außensensor hat keine Zehntelwerte bei der Feuchte, muss dafür aber negative Temperaturen darstellen. Der Innensensor zeigt Zehntelwerte, womit sich Tendenzen eher erkennen lassen. == [[RFM12_ASK_(Deutsch) | Intertechno schalten mit RFM12]] == todo == [[RFM12_ASK_(Deutsch) | IC2272 schalten mit RFM12]] == todo [[Category:Application|Application]] 2e2ca9721f741c5e3e9d517e586af154509cc2db 6 425 1369 2014-10-14T16:14:08Z Kpwg 721 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 426 1370 2014-10-14T16:14:27Z Kpwg 721 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 427 1371 2014-10-14T16:14:56Z Kpwg 721 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 428 1372 2014-10-14T16:15:15Z Kpwg 721 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 429 1373 2014-10-14T16:15:36Z Kpwg 721 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 430 1374 2014-10-14T16:16:08Z Kpwg 721 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 431 1375 2014-10-14T16:16:30Z Kpwg 721 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 432 1376 2014-10-14T16:16:54Z Kpwg 721 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 433 1378 2014-10-14T16:54:08Z Kpwg 721 Created page with "{{i18n|FHEM Roomnode Wohnzimmer}} == FHEM Roomnode Wohnzimmer == Für diverse Mess- und Schaltaufgaben im Wohnzimmer musste ein individuelles und vorzeigbares Gerät entstehen..." wikitext text/x-wiki {{i18n|FHEM Roomnode Wohnzimmer}} == FHEM Roomnode Wohnzimmer == Für diverse Mess- und Schaltaufgaben im Wohnzimmer musste ein individuelles und vorzeigbares Gerät entstehen, das diese Aufgaben übernimmt. Dabei sollen Daten über LAN an FHEM geliefert bzw. Display und Schaltaktoren mit FHEM gesteuert werden. Die wichtigsten Grundfunktionen sollen auch ohne FHEM dierekt bedienbar sein. '''Ziele''' * Messung Temperatur/Feuchte im Raum * Anzeige diverser Klimadaten und Uhrzeit * Schalten eines Intertechno Schaltaktors * Schalten einiger IC2272-Funksteckdosen (Weihnachtsbeleuchtung, etc.) * Steuerung Schrankwandbeleuchtung * Schalten eines RasPi für XBMC * Autonome Grundfunktionen ohne FHEM * vorzeigbares fertiges Gehäuse '''Ausstattung''' * DHT22 mit ca. 3m Kabel * LCD 16x1 HD44780 mit extra großen Zeichen * RFM12 433MHz mit externer Antenne * Taster mit LEDs * Schaltausgänge 12V mit PowerFET (IRLZ34) * USB-Buchse, die per Kabel den RasPi mit 5V versorgt * ATMega32 (98% Nutzung des Flash) '''Bilder''' <gallery> Fhem_wz_01.jpg|Aussenansicht (noch ohne Frontplatte) Fhem_wz_02.jpg|Platine von oben Fhem_wz_03.jpg|Stromversorgung und LAN-Modul Fhem_wz_04.jpg|Stecker Schrankwandbeleuchtung und DHT22 Fhem_wz_05.jpg|RFM12, Reed-Relais für geschaltene 5V Fhem_wz_06.jpg|zweckentfremdetes WLAN-Pigtail und 433MHz-Antenne Fhem_wz_07.jpg|Platine ohne Gehäuse für letzte Anpassungen Fhem_wz_08.jpg|Platine von unten </gallery> '''Besonderheiten/Hinweise''' * das Gehäuse stammt von einem nutzlos gewordenen ELSA Lancom 800 * mit Control6 und NamedPin sind die Grundfunktionen autonom bedienbar * die Stecker für die Schrankwandbeleuchtung entsprechen dem Original ae5c961a8ddad68bf9520aa7dcc1af31cd8bb10e 1379 1378 2014-10-14T17:50:06Z Kpwg 721 wikitext text/x-wiki {{i18n|FHEM Wohnzimmer}} == FHEM Roomnode Wohnzimmer == Für diverse Mess- und Schaltaufgaben im Wohnzimmer musste ein individuelles und vorzeigbares Gerät entstehen, das diese Aufgaben übernimmt. Dabei sollen Daten über LAN an FHEM geliefert bzw. Display und Schaltaktoren mit FHEM gesteuert werden. Die wichtigsten Grundfunktionen sollen auch ohne FHEM dierekt bedienbar sein. '''Ziele''' * Messung Temperatur/Feuchte im Raum * Anzeige diverser Klimadaten und Uhrzeit * Schalten eines Intertechno Schaltaktors * Schalten einiger IC2272-Funksteckdosen (Weihnachtsbeleuchtung, etc.) * Steuerung Schrankwandbeleuchtung * Schalten eines RasPi für XBMC * Autonome Grundfunktionen ohne FHEM * vorzeigbares fertiges Gehäuse '''Ausstattung''' * DHT22 mit ca. 3m Kabel * LCD 16x1 HD44780 mit extra großen Zeichen * RFM12 433MHz mit externer Antenne * Taster mit LEDs * Schaltausgänge 12V mit PowerFET (IRLZ34) * USB-Buchse, die per Kabel den RasPi mit 5V versorgt * ATMega32 (98% Nutzung des Flash) '''Bilder''' <gallery> Fhem_wz_01.jpg|Aussenansicht (noch ohne Frontplatte) Fhem_wz_02.jpg|Platine von oben Fhem_wz_03.jpg|Stromversorgung und LAN-Modul Fhem_wz_04.jpg|Stecker Schrankwandbeleuchtung und DHT22 Fhem_wz_05.jpg|RFM12, Reed-Relais für geschaltene 5V Fhem_wz_06.jpg|zweckentfremdetes WLAN-Pigtail und 433MHz-Antenne Fhem_wz_07.jpg|Platine ohne Gehäuse für letzte Anpassungen Fhem_wz_08.jpg|Platine von unten </gallery> '''Besonderheiten/Hinweise''' * das Gehäuse stammt von einem nutzlos gewordenen ELSA Lancom 800 * mit Control6 und NamedPin sind die Grundfunktionen autonom bedienbar * die Stecker für die Schrankwandbeleuchtung entsprechen dem Original adb86456958dd76904ed6bf2d98c39e1675a1d9d 1397 1379 2014-10-15T15:00:01Z Kpwg 721 einige Links nachgereicht wikitext text/x-wiki {{i18n|FHEM Wohnzimmer}} == FHEM Roomnode Wohnzimmer == Für diverse Mess- und Schaltaufgaben im Wohnzimmer musste ein individuelles und vorzeigbares Gerät entstehen, das diese Aufgaben übernimmt. Dabei sollen Daten über LAN an FHEM geliefert bzw. Display und Schaltaktoren mit FHEM gesteuert werden. Die wichtigsten Grundfunktionen sollen auch ohne FHEM dierekt bedienbar sein. '''Ziele''' * Messung Temperatur/Feuchte im Raum * Anzeige diverser Klimadaten und Uhrzeit * Schalten eines [[RFM12_ASK_(Deutsch)#Intertechno_.28ITS-150.29|Intertechno]] Schaltaktors * Schalten einiger [[RFM12_ASK_(Deutsch)#2272|IC2272]]-Funksteckdosen (Weihnachtsbeleuchtung, etc.) * Steuerung Schrankwandbeleuchtung * Schalten eines [http://www.raspberrypi.org/ RasPi] für [http://xbmc.org/ XBMC] * Autonome Grundfunktionen ohne FHEM * vorzeigbares fertiges Gehäuse '''Ausstattung''' * [[DHT|DHT22]] mit ca. 3m Kabel * LCD 16x1 HD44780 mit extra großen Zeichen * [[RFM12_(Deutsch)|RFM12]] 433MHz mit externer Antenne * Taster mit LEDs * Schaltausgänge 12V mit PowerFET (IRLZ34) * USB-Buchse, die per Kabel den RasPi mit 5V versorgt * ATMega32 (98% Nutzung des Flash) '''Bilder''' <gallery> Fhem_wz_01.jpg|Aussenansicht (noch ohne Frontplatte) Fhem_wz_02.jpg|Platine von oben Fhem_wz_03.jpg|Stromversorgung und LAN-Modul Fhem_wz_04.jpg|Stecker Schrankwandbeleuchtung und DHT22 Fhem_wz_05.jpg|RFM12, Reed-Relais für geschaltene 5V Fhem_wz_06.jpg|zweckentfremdetes WLAN-Pigtail und 433MHz-Antenne Fhem_wz_07.jpg|Platine ohne Gehäuse für letzte Anpassungen Fhem_wz_08.jpg|Platine von unten </gallery> '''Besonderheiten/Hinweise''' * das Gehäuse stammt von einem nutzlos gewordenen ELSA Lancom 800 * mit [[Control6_(Deutsch)|Control6]] und NamedPin sind die Grundfunktionen autonom bedienbar * die Stecker für die Schrankwandbeleuchtung entsprechen dem Original (Gewährleistung...) 54fa27d1c60a223649f3d18501dab19cfc0837cc 1399 1397 2014-10-15T15:46:44Z Kpwg 721 wikitext text/x-wiki {{i18n|FHEM Wohnzimmer}} == FHEM Roomnode Wohnzimmer == Für diverse Mess- und Schaltaufgaben im Wohnzimmer musste ein individuelles und vorzeigbares Gerät entstehen, das diese Aufgaben übernimmt. Dabei sollen Daten über LAN an FHEM geliefert bzw. Display und Schaltaktoren mit FHEM gesteuert werden. Die wichtigsten Grundfunktionen sollen auch ohne FHEM dierekt bedienbar sein. '''Ziele''' * Messung Temperatur/Feuchte im Raum * Anzeige diverser Klimadaten und Uhrzeit * Schalten eines [[RFM12_ASK_(Deutsch)#Intertechno_.28ITS-150.29|Intertechno]] Schaltaktors * Schalten einiger [[RFM12_ASK_(Deutsch)#2272|IC2272]]-Funksteckdosen (Weihnachtsbeleuchtung, etc.) * Steuerung Schrankwandbeleuchtung * Schalten eines [http://www.raspberrypi.org/ RasPi] für [http://xbmc.org/ XBMC] * Autonome Grundfunktionen ohne FHEM * vorzeigbares fertiges Gehäuse '''Ausstattung''' * [[DHT|DHT22]] mit ca. 3m Kabel * LCD 16x1 HD44780 mit extra großen Zeichen * [[RFM12_(Deutsch)|RFM12]] 433MHz mit externer Antenne * Taster mit LEDs * Schaltausgänge 12V mit PowerFET (IRLZ34) * USB-Buchse, die per Kabel den RasPi mit 5V versorgt * ATMega32 (98% Nutzung des Flash) '''Bilder''' <gallery> Fhem_wz_01.jpg|Aussenansicht (noch ohne Frontplatte) Fhem_wz_02.jpg|Platine von oben Fhem_wz_03.jpg|Stromversorgung und LAN-Modul Fhem_wz_04.jpg|Stecker Schrankwandbeleuchtung und DHT22 Fhem_wz_05.jpg|RFM12, Reed-Relais für geschaltene 5V Fhem_wz_06.jpg|zweckentfremdetes WLAN-Pigtail und 433MHz-Antenne Fhem_wz_07.jpg|Platine ohne Gehäuse für letzte Anpassungen Fhem_wz_08.jpg|Platine von unten </gallery> '''Besonderheiten/Hinweise''' * das Gehäuse stammt von einem nutzlos gewordenen ELSA Lancom 800 * mit [[Control6_(Deutsch)|Control6]] und NamedPin sind die Grundfunktionen autonom bedienbar * die Stecker für die Schrankwandbeleuchtung entsprechen dem Original (Gewährleistung...) [[Category:Hardware]] f679f6cfe8227ce497d667d0d633e707a96e8763 1401 1399 2014-10-15T15:51:10Z Kpwg 721 /* FHEM Roomnode Wohnzimmer */ wikitext text/x-wiki {{i18n|FHEM Wohnzimmer}} == [[Nutzung_in_FHEM_(Deutsch)|FHEM]] Roomnode Wohnzimmer == Für diverse Mess- und Schaltaufgaben im Wohnzimmer musste ein individuelles und vorzeigbares Gerät entstehen, das diese Aufgaben übernimmt. Dabei sollen Daten über LAN an FHEM geliefert bzw. Display und Schaltaktoren mit FHEM gesteuert werden. Die wichtigsten Grundfunktionen sollen auch ohne FHEM direkt bedienbar sein. '''Ziele''' * Messung Temperatur/Feuchte im Raum * Anzeige diverser Klimadaten und Uhrzeit * Schalten eines [[RFM12_ASK_(Deutsch)#Intertechno_.28ITS-150.29|Intertechno]] Schaltaktors * Schalten einiger [[RFM12_ASK_(Deutsch)#2272|IC2272]]-Funksteckdosen (Weihnachtsbeleuchtung, etc.) * Steuerung Schrankwandbeleuchtung * Schalten eines [http://www.raspberrypi.org/ RasPi] für [http://xbmc.org/ XBMC] * Autonome Grundfunktionen ohne FHEM * vorzeigbares fertiges Gehäuse '''Ausstattung''' * [[DHT|DHT22]] mit ca. 3m Kabel * LCD 16x1 HD44780 mit extra großen Zeichen * [[RFM12_(Deutsch)|RFM12]] 433MHz mit externer Antenne * Taster mit LEDs * Schaltausgänge 12V mit PowerFET (IRLZ34) * USB-Buchse, die per Kabel den RasPi mit 5V versorgt * ATMega32 (98% Nutzung des Flash) '''Bilder''' <gallery> Fhem_wz_01.jpg|Aussenansicht (noch ohne Frontplatte) Fhem_wz_02.jpg|Platine von oben Fhem_wz_03.jpg|Stromversorgung und LAN-Modul Fhem_wz_04.jpg|Stecker Schrankwandbeleuchtung und DHT22 Fhem_wz_05.jpg|RFM12, Reed-Relais für geschaltene 5V Fhem_wz_06.jpg|zweckentfremdetes WLAN-Pigtail und 433MHz-Antenne Fhem_wz_07.jpg|Platine ohne Gehäuse für letzte Anpassungen Fhem_wz_08.jpg|Platine von unten </gallery> '''Besonderheiten/Hinweise''' * das Gehäuse stammt von einem nutzlos gewordenen ELSA Lancom 800 * mit [[Control6_(Deutsch)|Control6]] und NamedPin sind die Grundfunktionen autonom bedienbar * die Stecker für die Schrankwandbeleuchtung entsprechen dem Original (Gewährleistung...) [[Category:Hardware]] 5f916540b8336a69524ef8da89bbe75d45789ce0 0 434 1380 2014-10-15T11:07:34Z Kpwg 721 Created page with "{{i18n|Etherrape}} == Etherrape ==" wikitext text/x-wiki {{i18n|Etherrape}} == Etherrape == c476eeabb076566ffbb6d16ee4b873e8e0730104 1398 1380 2014-10-15T15:45:47Z Kpwg 721 wikitext text/x-wiki {{i18n|Etherrape}} == Etherrape == [[File:Etherrape.jpg|thumb|right]] Das Orginal Etherrape von Alexander Neumann (fd0), mit dem alles anfing. Die Software aus der Etherrape Projekt war auch die Basis für Ethersex. Auf dem Board ist sehr viel Zeugs drauf. Man hat also vielfältige Möglichkeiten damit zu spielen. ===Features=== * ATmega644 * Microchip ENC28J60 * DataFlash * IR-Empfänger und -Sender * RS232-/RS485-Schnittstelle * [http://www.lochraster.org/etherrape/#features und Vieles mehr] Etherrape-Bausätze sind im Web-Shop unter http://www.lochraster.org/etherrape/ erhältlich. [[Category:Hardware]] 172d1aaa3e637d32dd606a70087877d5c7f20721 0 435 1381 2014-10-15T11:08:32Z Kpwg 721 Created page with "{{i18n|Jackalope}} == Jackalope ==" wikitext text/x-wiki {{i18n|Jackalope}} == Jackalope == 001556b94964c5fc0eefc779d980c3fb5378206d 0 436 1382 2014-10-15T11:10:13Z Kpwg 721 Created page with "{{i18n|AVR Webmodul}} == AVR Webmodul von Ulrich Radig ==" wikitext text/x-wiki {{i18n|AVR Webmodul}} == AVR Webmodul von Ulrich Radig == 7a73af1670d898b137e4ba6b29443f9d5e7b80cd 0 437 1383 2014-10-15T11:11:21Z Kpwg 721 Created page with "{{i18n|AVR-NET-IO}} == AVR-NET-IO ==" wikitext text/x-wiki {{i18n|AVR-NET-IO}} == AVR-NET-IO == ce79a4fe33b8f022bd2ae94a244bd5afd4e70a95 0 438 1384 2014-10-15T11:12:13Z Kpwg 721 Created page with "{{i18n|Funk-AVR-Evaluationsboard}} == Funk-AVR-Evaluationsboard ==" wikitext text/x-wiki {{i18n|Funk-AVR-Evaluationsboard}} == Funk-AVR-Evaluationsboard == c20bea02b8d02cf9601881d7f54a504be3438479 0 439 1385 2014-10-15T11:13:00Z Kpwg 721 Created page with "{{i18n|Conrad Probot}} == Conrad Probot ==" wikitext text/x-wiki {{i18n|Conrad Probot}} == Conrad Probot == 5bd6952750e5dc7ed2d14609fda1c92a73b0cd12 0 440 1386 2014-10-15T11:13:49Z Kpwg 721 Created page with "{{i18n|Fimser}} == Fimser ==" wikitext text/x-wiki {{i18n|Fimser}} == Fimser == bf8c11ffa2a79e0a39be35f7ff2485dac278a787 0 441 1387 2014-10-15T11:14:25Z Kpwg 721 Created page with "{{i18n|JeeLink}} == JeeLink ==" wikitext text/x-wiki {{i18n|JeeLink}} == JeeLink == b04bd48e787572edd340a01b141ee13fad040861 0 442 1389 2014-10-15T12:00:54Z Kpwg 721 Created page with "{{i18n|FHEM Kueche}} == FHEM Roomnode Küche == Zum Messen und perspektivischem Steuern der Junkers Therme soll in der Küche ein schlankes, vollkommen geschlossenes Gerät mi..." wikitext text/x-wiki {{i18n|FHEM Kueche}} == FHEM Roomnode Küche == Zum Messen und perspektivischem Steuern der Junkers Therme soll in der Küche ein schlankes, vollkommen geschlossenes Gerät mit Display an die Wand montiert werden. Nebenher wird das Raumklima erfasst. '''Ziele''' * Messung Temperatur/Feuchte im Raum * Anzeige diverser Klimadaten und Informationen * Messung der Regelspannung an der Therme * Messung von Vorlauf-, Rücklauf- und Warmwassertemperatur * Steuerung der Regelspannung mit Schutzschaltung * vorzeigbares Gehäuse, farblich unauffällig '''Ausstattung''' * DHT22 außen am Gehäuse * LCD 16x2 HD44780 in flacher Bauweise (daher leider unbeleuchtet) * zwei Analogeingänge zum Messen der Regelspannung an der Therme * Regelausgang analog 0-24V mit LTC1257 zum Steuern der Therme * Erfassung von Vorlauf-, Rücklauf- und Warmwassertemperatur mit je einem DS18B20 * ATMega32 '''Bilder''' <gallery> Fhem_ku_01.jpg|todo Fhem_ku_02.jpg|todo Fhem_ku_03.jpg|todo Fhem_ku_04.jpg|todo Fhem_ku_05.jpg|todo Fhem_ku_06.jpg|todo Fhem_ku_07.jpg|todo Fhem_ku_08.jpg|todo </gallery> '''Besonderheiten/Hinweise''' * das Gehäuse ist ein StrapuBox SP2063GR * vorbereitet für 1wire bzw. Zähleingang Wasseruhr 3a3243dcd6071021e9288a473cfcbd7aeedd7804 1396 1389 2014-10-15T14:50:23Z Kpwg 721 wikitext text/x-wiki {{i18n|FHEM Kueche}} == FHEM Roomnode Kueche == Zum Messen und perspektivischem Steuern der Junkers Kombitherme soll in der Küche ein schlankes, vollkommen geschlossenes Gerät mit Display an die Wand montiert werden. Nebenher wird das Raumklima erfasst. Dabei diente die [http://www.fhemwiki.de/wiki/Junkers_Therme_Stetigregelung Junkers Therme Stetigregelung] als Vorlage. '''Ziele''' * Messung Temperatur/Feuchte im Raum * Anzeige diverser Klimadaten und Informationen * Messung der Regelspannung an der Therme * Messung von Vorlauf-, Rücklauf- und Warmwassertemperatur * bedarfsweise Steuerung der Regelspannung mit Schutzschaltung * vorzeigbares Gehäuse, farblich unauffällig '''Ausstattung''' * [[DHT|DHT22]] außen am Gehäuse * LCD 16x2 HD44780 in flacher Bauweise (daher leider unbeleuchtet) * zwei Analogeingänge zum Messen der Regelspannung ''soll/ist'' an der Therme * Regelausgang analog 0-24V mit [[Porterweiterungen_(Deutsch)#D.2FA-Wandler_mit_LTC1257|LTC1257]] zum Steuern der Therme * Erfassung von Vorlauf-, Rücklauf- und Warmwassertemperatur mit je einem [[Onewire_(Deutsch) | DS18B20]] * ATMega32, ICL7660-Inverter für das Uralt-LCD '''Bilder''' <gallery> Fhem_ku_01.jpg|betriebsfertiges Gerät Fhem_ku_02.jpg|Gehäuse geöffnet; noch ohne Verkabelung Fhem_ku_03.jpg|alle Baugruppen; noch ohne Gehäuse Fhem_ku_04.jpg|Platine von unten Fhem_ku_05.jpg|DHT22 seitlich am Gehäuse Fhem_ku_06.jpg|DS18B20, verschrumpft; vorbereitet als Rohranlegefühler </gallery> '''Besonderheiten/Hinweise''' * das Gehäuse ist ein StrapuBox SP2063GR, weiß lackiert (der Ausschnitt ist "handgefeilt"!) * vorbereitet für 1wire bzw. Zähleingang Wasseruhr (befindet sich 1.5m darunter) * Platz für [[RFM12_FS20_(Deutsch) | RFM12-868]] auf der Platine, um eventuell künftig FS20 zu empfangen abda97071be2edb9b12a4b056a221a6b0bc42d87 1400 1396 2014-10-15T15:47:13Z Kpwg 721 wikitext text/x-wiki {{i18n|FHEM Kueche}} == FHEM Roomnode Kueche == Zum Messen und perspektivischem Steuern der Junkers Kombitherme soll in der Küche ein schlankes, vollkommen geschlossenes Gerät mit Display an die Wand montiert werden. Nebenher wird das Raumklima erfasst. Dabei diente die [http://www.fhemwiki.de/wiki/Junkers_Therme_Stetigregelung Junkers Therme Stetigregelung] als Vorlage. '''Ziele''' * Messung Temperatur/Feuchte im Raum * Anzeige diverser Klimadaten und Informationen * Messung der Regelspannung an der Therme * Messung von Vorlauf-, Rücklauf- und Warmwassertemperatur * bedarfsweise Steuerung der Regelspannung mit Schutzschaltung * vorzeigbares Gehäuse, farblich unauffällig '''Ausstattung''' * [[DHT|DHT22]] außen am Gehäuse * LCD 16x2 HD44780 in flacher Bauweise (daher leider unbeleuchtet) * zwei Analogeingänge zum Messen der Regelspannung ''soll/ist'' an der Therme * Regelausgang analog 0-24V mit [[Porterweiterungen_(Deutsch)#D.2FA-Wandler_mit_LTC1257|LTC1257]] zum Steuern der Therme * Erfassung von Vorlauf-, Rücklauf- und Warmwassertemperatur mit je einem [[Onewire_(Deutsch) | DS18B20]] * ATMega32, ICL7660-Inverter für das Uralt-LCD '''Bilder''' <gallery> Fhem_ku_01.jpg|betriebsfertiges Gerät Fhem_ku_02.jpg|Gehäuse geöffnet; noch ohne Verkabelung Fhem_ku_03.jpg|alle Baugruppen; noch ohne Gehäuse Fhem_ku_04.jpg|Platine von unten Fhem_ku_05.jpg|DHT22 seitlich am Gehäuse Fhem_ku_06.jpg|DS18B20, verschrumpft; vorbereitet als Rohranlegefühler </gallery> '''Besonderheiten/Hinweise''' * das Gehäuse ist ein StrapuBox SP2063GR, weiß lackiert (der Ausschnitt ist "handgefeilt"!) * vorbereitet für 1wire bzw. Zähleingang Wasseruhr (befindet sich 1.5m darunter) * Platz für [[RFM12_FS20_(Deutsch) | RFM12-868]] auf der Platine, um eventuell künftig FS20 zu empfangen [[Category:Hardware]] b2fcd6d686e5dcc3fc4d2e5caeb57db329c822de 1402 1400 2014-10-15T15:53:49Z Kpwg 721 wikitext text/x-wiki {{i18n|FHEM Kueche}} == [[Nutzung_in_FHEM_(Deutsch)|FHEM]] Roomnode Kueche == Zum Messen und perspektivischem Steuern der Junkers Kombitherme soll in der Küche ein schlankes, vollkommen geschlossenes Gerät mit Display an die Wand. Nebenbei wird das Raumklima erfasst. Dabei diente die [http://www.fhemwiki.de/wiki/Junkers_Therme_Stetigregelung Junkers Therme Stetigregelung] als Vorlage für die Ansteuerung. '''Ziele''' * Messung Temperatur/Feuchte im Raum * Anzeige diverser Klimadaten und Informationen * Messung der Regelspannung an der Therme * Messung von Vorlauf-, Rücklauf- und Warmwassertemperatur * bedarfsweise Steuerung der Regelspannung mit Schutzschaltung * vorzeigbares Gehäuse, farblich unauffällig '''Ausstattung''' * [[DHT|DHT22]] außen am Gehäuse * LCD 16x2 HD44780 in flacher Bauweise (daher leider unbeleuchtet) * zwei Analogeingänge zum Messen der Regelspannung ''soll/ist'' an der Therme * Regelausgang analog 0-24V mit [[Porterweiterungen_(Deutsch)#D.2FA-Wandler_mit_LTC1257|LTC1257]] zum Steuern der Therme * Erfassung von Vorlauf-, Rücklauf- und Warmwassertemperatur mit je einem [[Onewire_(Deutsch) | DS18B20]] * ATMega32, ICL7660-Inverter für das Uralt-LCD '''Bilder''' <gallery> Fhem_ku_01.jpg|betriebsfertiges Gerät Fhem_ku_02.jpg|Gehäuse geöffnet; noch ohne Verkabelung Fhem_ku_03.jpg|alle Baugruppen; noch ohne Gehäuse Fhem_ku_04.jpg|Platine von unten Fhem_ku_05.jpg|DHT22 seitlich am Gehäuse Fhem_ku_06.jpg|DS18B20, verschrumpft; vorbereitet als Rohranlegefühler </gallery> '''Besonderheiten/Hinweise''' * das Gehäuse ist ein StrapuBox SP2063GR, weiß lackiert (der Ausschnitt ist "handgefeilt"!) * vorbereitet für 1wire bzw. Zähleingang Wasseruhr (befindet sich 1.5m darunter) * Platz für [[RFM12_FS20_(Deutsch) | RFM12-868]] auf der Platine, um eventuell künftig FS20 zu empfangen [[Category:Hardware]] b21364518bde6bd13bdd281370d9f78606a325dd 6 443 1390 2014-10-15T13:49:04Z Kpwg 721 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 444 1391 2014-10-15T14:28:52Z Kpwg 721 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 445 1392 2014-10-15T14:29:12Z Kpwg 721 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 446 1393 2014-10-15T14:29:42Z Kpwg 721 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 447 1394 2014-10-15T14:30:05Z Kpwg 721 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 448 1395 2014-10-15T14:30:27Z Kpwg 721 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 390 1404 1403 2014-10-16T15:15:22Z Kpwg 721 /* 1-Wire Temperatursensoren */ wikitext text/x-wiki {{i18n|Nutzung in FHEM}} [http://www.fhemwiki.de/wiki/Hauptseite FHEM] ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um diverse per Funk und Kabel angebundene Komponenten aus dem Bereich der Hausautomation zu steuern. Er ist lizensiert unter der GPL v2. Das [http://www.pollin.de/shop/suchergebnis.html?S_TEXT=810+058 AVR-Net-IO] von [http://www.pollin.de Pollin] mit [[Ethersex]] dient als [http://www.fhemwiki.de/wiki/AVR-NET-IO preisgünstiger Einstieg in die Hausautomatisierung]. Verwendbar ist aber auch jede andere [[Supported_Boards_(Deutsch) | Hardware]], die von Ethersex unterstützt wird (Arduino, eigene Entwicklungen, etc.). Über [[ECMD]] lassen sich dabei theoretisch alle in [[Ethersex]] vorhandenen [[ECMD_Protocols_%28Deutsch%29 | Möglichkeiten]] nutzen, sofern in FHEM entsprechende [http://fhem.de/commandref.html#ECMD ECMD-Devices] definiert und eingebunden werden, die passende Klassendefinition exisitert und die Aktion ausgelöst wird. == Grundlagen == Ausgehend von einem fertigen und per Telnet erreichbaren Ethersex muss in FHEM zuerst das entsprechende Device definiert werden. <pre> define NETIO_WZ ECMD telnet 192.168.3.81:2701 </pre> Eine serielle Anbindung kann mit ''define <name> ECMD serial <SerialDevice>[<@BaudRate>]'' alternativ erfolgen. Anschließend werden die erstellten .classdef-Konfigurationsdateien der einzelnen Funktionen dem System bekannt gemacht. In diesen .classdef-Dateien (Name und Endung sind frei wählbar!) wird die Schnittstelle zwischen FHEM und ECMD/Ethersex definiert. Dabei können mit perl übergebene Parameter und empfangene Daten bearbeitet sowie die in FHEM gebräuchlichen Readings erstellt werden. <pre> attr NETIO_WZ classdefs RFM12_2272=/opt/fhem/FHEM/rfm12_2272.classdef:RFM12_IT=/opt/fhem/FHEM/rfm12_it.classdef:LCD=/opt/fhem/FHEM/lcd.classdef:DHT22=/opt/fhem/FHEM/dht22.classdef:1WIRE=/opt/fhem/FHEM/1wire.classdef </pre> Die Definitionen für IC2272, Intertechno, HD44780-LCD, DHT22 und 1wire sind nun eingebunden. In den folgenden Abschnitten wird auf die einzelnen Devices näher eingegangen. Generell sind Pfade und IP-Adressen sowie übergebene Parameter noch entsprechend der eigenen Konfiguration anzupassen. == [[Onewire_(Deutsch) | 1-Wire Temperatursensoren]] == [[File:DS18B20.jpg|150px|thumb|right|DS18B20-Sensoren]] Die 1wire-Temperatursensoren DS18B20 oder DS18S20 werden im [[Onewire_(Deutsch)#Polling_Modus | Polling Modus]] abgefragt. Das macht die zyklische Abfrage aus FHEM heraus wesentlich einfacher. Eine Polling-Zeit von mindestens 30 Sekunden ist absolut ausreichend.Im Vorfeld sollte man sich die [[Onewire_(Deutsch)#Benennung_von_Sensoren | ROM-Codes der Sensoren]] notieren, da diese nachher benötigt werden. 1w-temp.classdef erstellen: <source lang="perl"> # Uebergabeparameter Onewire Rom-Code params devID # Umsetzung in ECMD Befehle 1w get = Temperatur auslesen get 1W cmd {"1w get %devID\n"} get 1W expect "\d+.\d\n" get 1W postproc {\ s/\n//g;\ my $hash = $defs{%NAME};\ my $temperature = $_;\ my $state = "T: $temperature";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die classdef wird eingebunden: <pre> define NETIO_KU ECMD telnet 192.168.3.82:2701 attr NETIO_KU classdefs 1W-TEMP=/opt/fhem/FHEM/1w-temp.classdef </pre> Die Sensoren werden anhand des ROM-Code definiert: <pre> define HZ_WW ECMDDevice 1W-TEMP 284c8820050003d4 attr HZ_WW IODev NETIO_KU define HZ_VL ECMDDevice 1W-TEMP 2890a520050003d7 attr HZ_VL IODev NETIO_KU </pre> Eine zyklische Messung pro Minute lässt sich in dieser Form auslösen: <pre> define Messung_1w at +*00:01 get HZ_WW 1W;; get HZ_VL 1W attr Messung_1w verbose 0 </pre> == [[DHT|DHT22 Temperatur-/Feuchtesensoren]] == [[File:DHT22.jpg|150px|thumb|right|DHT22-Sensoren]] [[Ethersex]] unterstützt die preiswerten Temperatur-/Feuchtesensoren [[DHT|DHT11 und DHT22]], wobei letztere [[DHT#DHT11_vs_DHT22|um einiges genauer sind]]. Die Sensoren benötigen 5V Betriebsspannung und kommunizieren über je einen Pin mit dem Prozessor. Der Preis pro Stück liegt derzeit bei etwa 3.50 Euro (ebay/China). Wer die Trägheit und Ungenauigkeit der S300TH oder TX29DTH kennt, wünscht sich vermutlich Besseres; vor allem bei Berechnung von [http://de.wikipedia.org/wiki/Taupunkt Taupunkt] und [http://de.wikipedia.org/wiki/Luftfeuchtigkeit#Absolute_Luftfeuchtigkeit absoluter Feuchte], welche von der Genauigkeit der gemessenen Eingangsgrößen sehr profitieren. Berechnungen von Hand kann man beim [http://www.wetterochs.de/wetter/feuchte.html Wetterochs] durchführen. Die automatische Berechnung der absoluten Feuchte in FHEM wird im [http://forum.fhem.de/index.php/topic,21458.0.html Forum] erklärt. '''Einbindung in FHEM''' dht22m.classdef erstellen: <source lang="perl"> # Uebergabeparameter DHT22 ID 0...n params devID # Umsetzung in ECMD Befehle fuer DHT22 get DHT cmd {"dht temp %devID\n\000dht humid %devID\n"} get DHT expect "\d+.\d\n" get DHT postproc {\ s/(.*)\n(.*)\n/T: $1 H: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1;\ my $humidity = $2;\ my $state = $_;\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "humidity", $humidity, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs DHT22M=/opt/fhem/FHEM/dht22m.classdef </pre> Die Sensoren werden definiert: <pre> define Test0 ECMDDevice DHT22M 0 attr Test0 IODev NETIO_TEST define Test1 ECMDDevice DHT22M 1 attr Test1 IODev NETIO_TEST define Test2 ECMDDevice DHT22M 2 attr Test2 IODev NETIO_TEST define Test3 ECMDDevice DHT22M 3 attr Test3 IODev NETIO_TEST </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_DHT at +*00:04 get Test0 DHT;; get Test1 DHT;; get Test2 DHT;; get Test3 DHT attr Messung_DHT verbose 0 </pre> Fünfzehn Messwerte pro Stunde genügen den allermeisten Anforderungen. == [[BMP085 | BMP085/BMP180 Luftdrucksensor]] == [[File:BMP180.jpg|150px|thumb|right|BMP180 (unten links)]] Ethersex unterstützt den BMP085 (bzw. den BMP180; der Code ist identisch) über das [[I2C_(Deutsch) | I2C]]-Interface. Da der Sensor für 3.3V Betriebsspannung ausgelegt ist, muss entweder der I2C-Pegel angepasst oder der ATMega auf 3.3V adaptiert werden. Weiterhin sollte die Höhe über Null bekannt sein. Beispiel: Eine Abfrage per [[ECMD]] mit ''bmp085 pressnn 59000'' bedeutet, das ich 590m (59000cm) über NN wohne. Die im Sensor verfügbare Temperatur wird parallel ausgelesen. '''Einbindung in FHEM''' bmp085.classdef erstellen: <source lang="perl"> get BMP cmd {"bmp085 temp\n\000bmp085 pressnn 59000\n"} get BMP expect ".*" get BMP postproc {\ s/(.*)\n(.*)\n/T: $1 P: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1/10;\ my $pressure = sprintf("%.1f",$2/100);\ my $state = "T: $temperature P: $pressure";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "pressure", $pressure, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die Temperatur wird in °C mit einer Nachkommastelle gelesen, der Luftdruck in hPa bzw. mbar auf eine Nachkommastelle gerundet. Passende Readings werden erstellt. Das expect .* kann noch angepasst werden, um bei fehlerhaften Messwerten entsprechend zu reagieren. Die classdef wird in FHEM eingebunden (mehrere .classdef mit Doppelpunkt trennen: siehe [[Nutzung_in_FHEM_(Deutsch)#Grundlagen | Grundlagen]]): <pre> define NETIO_STK ECMD telnet 192.168.3.89:2701 attr NETIO_STK classdefs BMP=/opt/fhem/FHEM/bmp085.classdef </pre> Der Sensor wird definiert: <pre> define BMP180 ECMDDevice BMP attr BMP180 IODev NETIO_STK </pre> Das STATE ''kann'' mit Maßeinheiten versehen werden: <pre> attr BMP180 stateFormat { sprintf("%s°C %shPa", ReadingsVal("BMP180","temperature",0), ReadingsVal("BMP180","pressure",0)) ;; } </pre> Eine zyklische Messung alle 4 Minuten erfolgt wieder mit ''at'': <pre> define Messung_BMP at +*00:04 get BMP180 BMP attr Messung_BMP verbose 0 </pre> Dabei unterdrückt verbose 0 einen zusätzlichen (doppelten) Logeintrag des Messvorganges. == analoge Eingänge abfragen == Die analogen Eingänge des ATMega sind recht simpel abzufragen. Dabei werden die hexadezimalen Werte gleich dezimal gewandelt, um die Weiterverarbeitung zu erleichtern. '''Einbindung in FHEM''' adc.classdef erstellen: <source lang="perl"> get value cmd {"adc get %PortID\n"} params PortID get value expect ".*" get value postproc {\ my $hexval = hex(trim("$_"));\ my $hash = $defs{%NAME};\ readingsSingleUpdate($hash, "state", $hexval, 1);\ } </source> Die classdef wird eingebunden: <pre> define NETIO_KU ECMD telnet 192.168.3.89:2701 attr NETIO_KU classdefs ADC=/opt/fhem/FHEM/adc.classdef </pre> Die Sensoren an den ersten beiden Ports werden definiert: <pre> define MP_0 ECMDDevice ADC 0 attr MP_0 IODev NETIO_KU define MP_1 ECMDDevice ADC 1 attr MP_1 IODev NETIO_KU </pre> Eine zyklische Messung alle 60 Sekunden funktioniert damit: <pre> define Messung_adc at +*00:01 get MP_0 value;; get MP_1 value attr Messung_adc verbose 0 </pre> == digitale Eingänge abfragen == todo == digitale Eingänge - proaktiv == Kontakte, die bei Zustandsänderung sofort in FHEM eine Meldung erzeugen sollen, kann man nicht zeitnah mit Polling abfragen. Diese Ereignisse, welche auch aus einem Control6-Script heraus generiert sein können, sollen selbst Meldung machen. Hierbei wird die ESEND-Funktion benutzt, mit welcher auch mehrere Ethersex'e untereinander kommunizieren können. Dabei ist es nicht relevant, ob das Device in FHEM per ECMDDevice bereits eingebunden wurde. Zuerst muss FHEM auf Port 2701 für Telnet-Verbindungen empfänglich werden: <pre> define telnetECMD telnet 2701 global </pre> Mit ''Watch io changes and react'' lässt sich per menuconfig bereits auf einfache Weise eine Abfrage von Portpins mit Generierung eines ESEND-Befehles bewerkstelligen. Das Beispiel soll zeigen, wie bei entsprechender Zustandsänderung an Pin PA0 an 192.168.178.10 ein FHEM-Befehl gesendet wird: <pre> ECMDTCP(PA0, RISING, 192.168.178.10, set Lampe on\n\n) ECMDTCP(PA0, FALLING, 192.168.178.10, set Lampe off\n\n) </pre> Jede Sequenz muss mit \n\n abgeschlossen werden, damit FHEM für weitere Befehle empfangsbereit bleibt. Falls man in FHEM flexibler bei der Weiterverarbeitung sein möchte, bietet sich eine dummy-notify-Kombination an. == [[Porterweiterungen_%28Deutsch%29#D.2FA-Wandler_mit_LTC1257 | LTC1257 D/A-Wandler]] == todo == HD44780 Punktmatrixdisplays == [[File:HD44780.jpg|150px|thumb|right|verschiedene HD44780 Displays (16x1 bis 40x4)]] Die beliebten Punktmatrix-Displays auf Basis [http://de.wikipedia.org/wiki/HD44780 HD44780] können vollumfänglich in FHEM beschrieben werden. Dabei wird vorrausgesetzt, das in [https://github.com/ethersex/ethersex/blob/master/hardware/lcd/hd44780.h /hardware/lcd/hd44780.h] beim entsprechenden Modell die passende Adressierung der Zeilen und die genutzte Zeilen-/Spaltenzahl vor dem Compilieren angepasst wurde. '''Einbindung in FHEM''' lcd.classdef erstellen: <source lang="perl"> # Umsetzung der ECMD Befehle set write params line col text set write cmd {"lcd goto %line %col\n\000lcd write %text\n"} set write expect "OK\n" set write postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set clear params col set clear cmd {"lcd clear %col\n"} set clear expect "OK\n" set clear postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set clear_all cmd {"lcd clear\n"} set clear_all expect "OK\n" set clear_all postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set lcd_bl params state set lcd_bl cmd {"lcd backlight %state\n"} set lcd_bl expect "OK\n" set lcd_bl postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} </source> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs LCD=/opt/fhem/FHEM/lcd.classdef </pre> Das Display wird definiert: <pre> define WZ_LCD ECMDDevice LCD attr WZ_LCD IODev NETIO_TEST </pre> Es stehen in FHEM folgende Befehle für das LCD bereit: {| border='1' | ''Befehl'' | ''Funktion'' |- | set WZ_LCD clear [ZEILE] | löscht den Inhalt einer ZEILE (0...3) |- | set WZ_LCD clear_all | löscht den Inhalt aller Zeilen |- | set WZ_LCD lcd_bl STATE | schaltet die Hintergrundbeleuchtung ein oder aus (STATE on oder off) |- | set WZ_LCD write [ZEILE] [SPALTE] [TEXT] | schreibt einen TEXT auf Position ZEILE SPALTE (0...n) |- |} Da ein im TEXT übergebenes Leerzeichen als weiterer Befehl interpretiert wird und zu einer Fehlermeldung führt, ist eine Übergabe nur mit \x20 im Text möglich. Das gilt auch für Umlaute. Anhand der [http://de.wikipedia.org/wiki/HD44780#Schrift_und_Zeichensatz Zeichensatztabelle] lassen sich ä durch \xE1, ü durch \xF5 und ö durch \xEF darstellen. Das ß wird mit \xE2 erreicht. Die Tabelle kann für manche Displays abweichend sein.<br /> Beispiel: ''set WZ_LCD write 0 0 Fenster\x20schlie\xE2en'' schreibt ein '''Fenster schließen''' auf's LCD. '''Komfortable Nutzung in FHEM mit DLCD''' Mit dem DLCD-Modul ([http://www.fhemwiki.de/wiki/DLCD Wiki-Beitrag] / [http://forum.fhem.de/index.php/topic,24519.0.html Foren-Beitrag]) für FHEM lässt sich jedes Display auf einfache Weise beschreiben. Dabei lassen sich bequem Readings von allen Devices nutzen, aufbereiten (formatieren, umrechnen, etc.) und entsprechend darstellen. Eine genaue Beschreibung hält der Wiki-Beitrag bereit; hier soll ein Beispiel gezeigt werden. Ziel war es, auf einem 16x1 LCD wechselweise ''Datum/Zeit => Klimadaten Keller => Datum/Zeit => Klimadaten Garten'' darzustellen. Die Anzeige rotiert im 15-Sekunden-Takt, so das zu 50% Datum/Zeit und je 25% die Werte aus dem Garten und dem Keller angezeigt werden. Es wird bereits im Modul jedes Leerzeichen mit \x20 übersetzt. Der Außensensor ist ein [http://www.elv.de/elv-funk-kombi-wettersensor-ks-300-2-br-inkl-hochwertigem-2-m-edelstahlmast-br-und-qualitaetsbatterien.html KS300] (bzw. KS200) von ELV. Mit etwas Formatierung und ein paar Leerzeichen lässt sich eine stets gleiche Positionierung der Daten erreichen, da die Zeile nicht explizit gelöscht wird. Auszug aus der fhem.cfg: <pre> define DLCD_WZ DLCD attr DLCD_WZ dlcdBlankspaceReplace \x20 attr DLCD_WZ dlcdCols 16 attr DLCD_WZ dlcdLine1 %date_WD_ger% %date_D%.%date_M_ger% %time_h%:%time_m% attr DLCD_WZ dlcdLine2 Keller:%1%/%2% attr DLCD_WZ dlcdLine3 %date_WD_ger% %date_D%.%date_M_ger% %time_h%:%time_m% attr DLCD_WZ dlcdLine4 Garten: %3%/%4% attr DLCD_WZ dlcdPhysicalRows 1 attr DLCD_WZ dlcdPollInterval 15 attr DLCD_WZ dlcdRows 4 attr DLCD_WZ dlcdScrolling 1 attr DLCD_WZ dlcdTriggerCmd set WZ_LCD write %L% 0 %T% attr DLCD_WZ dlcdVal1 Keller:temperature attr DLCD_WZ dlcdVal1formatnum 3+1 attr DLCD_WZ dlcdVal2 Keller:humidity attr DLCD_WZ dlcdVal2formatnum 3+1 attr DLCD_WZ dlcdVal3 KS300:temperature attr DLCD_WZ dlcdVal3formatnum 3+1+- attr DLCD_WZ dlcdVal4 KS300:humidity attr DLCD_WZ dlcdVal4formatnum 2+0 </pre> Das Ergebnis kann so aussehen: <gallery> DLCD_1.jpg|Zustand 1.-15. Sekunde DLCD_2.jpg|Zustand 16.-30. Sekunde DLCD_3.jpg|Zustand 31.-45. Sekunde DLCD_4.jpg|Zustand 46.-60. Sekunde </gallery> Die Formatierung bewirkt eine immer identische Platzierung der Daten. Der Außensensor hat keine Zehntelwerte bei der Feuchte, muss dafür aber negative Temperaturen darstellen. Der Innensensor zeigt Zehntelwerte, womit sich Tendenzen eher erkennen lassen. == [[RFM12_ASK_(Deutsch) | Intertechno schalten mit RFM12]] == todo == [[RFM12_ASK_(Deutsch) | IC2272 schalten mit RFM12]] == todo [[Category:Application|Application]] 6766d1b1f93fe9de54a66abfe3ff490dcfdca8d0 1405 1404 2014-10-16T15:39:49Z Kpwg 721 /* LTC1257 D/A-Wandler */ wikitext text/x-wiki {{i18n|Nutzung in FHEM}} [http://www.fhemwiki.de/wiki/Hauptseite FHEM] ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um diverse per Funk und Kabel angebundene Komponenten aus dem Bereich der Hausautomation zu steuern. Er ist lizensiert unter der GPL v2. Das [http://www.pollin.de/shop/suchergebnis.html?S_TEXT=810+058 AVR-Net-IO] von [http://www.pollin.de Pollin] mit [[Ethersex]] dient als [http://www.fhemwiki.de/wiki/AVR-NET-IO preisgünstiger Einstieg in die Hausautomatisierung]. Verwendbar ist aber auch jede andere [[Supported_Boards_(Deutsch) | Hardware]], die von Ethersex unterstützt wird (Arduino, eigene Entwicklungen, etc.). Über [[ECMD]] lassen sich dabei theoretisch alle in [[Ethersex]] vorhandenen [[ECMD_Protocols_%28Deutsch%29 | Möglichkeiten]] nutzen, sofern in FHEM entsprechende [http://fhem.de/commandref.html#ECMD ECMD-Devices] definiert und eingebunden werden, die passende Klassendefinition exisitert und die Aktion ausgelöst wird. == Grundlagen == Ausgehend von einem fertigen und per Telnet erreichbaren Ethersex muss in FHEM zuerst das entsprechende Device definiert werden. <pre> define NETIO_WZ ECMD telnet 192.168.3.81:2701 </pre> Eine serielle Anbindung kann mit ''define <name> ECMD serial <SerialDevice>[<@BaudRate>]'' alternativ erfolgen. Anschließend werden die erstellten .classdef-Konfigurationsdateien der einzelnen Funktionen dem System bekannt gemacht. In diesen .classdef-Dateien (Name und Endung sind frei wählbar!) wird die Schnittstelle zwischen FHEM und ECMD/Ethersex definiert. Dabei können mit perl übergebene Parameter und empfangene Daten bearbeitet sowie die in FHEM gebräuchlichen Readings erstellt werden. <pre> attr NETIO_WZ classdefs RFM12_2272=/opt/fhem/FHEM/rfm12_2272.classdef:RFM12_IT=/opt/fhem/FHEM/rfm12_it.classdef:LCD=/opt/fhem/FHEM/lcd.classdef:DHT22=/opt/fhem/FHEM/dht22.classdef:1WIRE=/opt/fhem/FHEM/1wire.classdef </pre> Die Definitionen für IC2272, Intertechno, HD44780-LCD, DHT22 und 1wire sind nun eingebunden. In den folgenden Abschnitten wird auf die einzelnen Devices näher eingegangen. Generell sind Pfade und IP-Adressen sowie übergebene Parameter noch entsprechend der eigenen Konfiguration anzupassen. == [[Onewire_(Deutsch) | 1-Wire Temperatursensoren]] == [[File:DS18B20.jpg|150px|thumb|right|DS18B20-Sensoren]] Die 1wire-Temperatursensoren DS18B20 oder DS18S20 werden im [[Onewire_(Deutsch)#Polling_Modus | Polling Modus]] abgefragt. Das macht die zyklische Abfrage aus FHEM heraus wesentlich einfacher. Eine Polling-Zeit von mindestens 30 Sekunden ist absolut ausreichend.Im Vorfeld sollte man sich die [[Onewire_(Deutsch)#Benennung_von_Sensoren | ROM-Codes der Sensoren]] notieren, da diese nachher benötigt werden. 1w-temp.classdef erstellen: <source lang="perl"> # Uebergabeparameter Onewire Rom-Code params devID # Umsetzung in ECMD Befehle 1w get = Temperatur auslesen get 1W cmd {"1w get %devID\n"} get 1W expect "\d+.\d\n" get 1W postproc {\ s/\n//g;\ my $hash = $defs{%NAME};\ my $temperature = $_;\ my $state = "T: $temperature";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die classdef wird eingebunden: <pre> define NETIO_KU ECMD telnet 192.168.3.82:2701 attr NETIO_KU classdefs 1W-TEMP=/opt/fhem/FHEM/1w-temp.classdef </pre> Die Sensoren werden anhand des ROM-Code definiert: <pre> define HZ_WW ECMDDevice 1W-TEMP 284c8820050003d4 attr HZ_WW IODev NETIO_KU define HZ_VL ECMDDevice 1W-TEMP 2890a520050003d7 attr HZ_VL IODev NETIO_KU </pre> Eine zyklische Messung pro Minute lässt sich in dieser Form auslösen: <pre> define Messung_1w at +*00:01 get HZ_WW 1W;; get HZ_VL 1W attr Messung_1w verbose 0 </pre> == [[DHT|DHT22 Temperatur-/Feuchtesensoren]] == [[File:DHT22.jpg|150px|thumb|right|DHT22-Sensoren]] [[Ethersex]] unterstützt die preiswerten Temperatur-/Feuchtesensoren [[DHT|DHT11 und DHT22]], wobei letztere [[DHT#DHT11_vs_DHT22|um einiges genauer sind]]. Die Sensoren benötigen 5V Betriebsspannung und kommunizieren über je einen Pin mit dem Prozessor. Der Preis pro Stück liegt derzeit bei etwa 3.50 Euro (ebay/China). Wer die Trägheit und Ungenauigkeit der S300TH oder TX29DTH kennt, wünscht sich vermutlich Besseres; vor allem bei Berechnung von [http://de.wikipedia.org/wiki/Taupunkt Taupunkt] und [http://de.wikipedia.org/wiki/Luftfeuchtigkeit#Absolute_Luftfeuchtigkeit absoluter Feuchte], welche von der Genauigkeit der gemessenen Eingangsgrößen sehr profitieren. Berechnungen von Hand kann man beim [http://www.wetterochs.de/wetter/feuchte.html Wetterochs] durchführen. Die automatische Berechnung der absoluten Feuchte in FHEM wird im [http://forum.fhem.de/index.php/topic,21458.0.html Forum] erklärt. '''Einbindung in FHEM''' dht22m.classdef erstellen: <source lang="perl"> # Uebergabeparameter DHT22 ID 0...n params devID # Umsetzung in ECMD Befehle fuer DHT22 get DHT cmd {"dht temp %devID\n\000dht humid %devID\n"} get DHT expect "\d+.\d\n" get DHT postproc {\ s/(.*)\n(.*)\n/T: $1 H: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1;\ my $humidity = $2;\ my $state = $_;\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "humidity", $humidity, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs DHT22M=/opt/fhem/FHEM/dht22m.classdef </pre> Die Sensoren werden definiert: <pre> define Test0 ECMDDevice DHT22M 0 attr Test0 IODev NETIO_TEST define Test1 ECMDDevice DHT22M 1 attr Test1 IODev NETIO_TEST define Test2 ECMDDevice DHT22M 2 attr Test2 IODev NETIO_TEST define Test3 ECMDDevice DHT22M 3 attr Test3 IODev NETIO_TEST </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_DHT at +*00:04 get Test0 DHT;; get Test1 DHT;; get Test2 DHT;; get Test3 DHT attr Messung_DHT verbose 0 </pre> Fünfzehn Messwerte pro Stunde genügen den allermeisten Anforderungen. == [[BMP085 | BMP085/BMP180 Luftdrucksensor]] == [[File:BMP180.jpg|150px|thumb|right|BMP180 (unten links)]] Ethersex unterstützt den BMP085 (bzw. den BMP180; der Code ist identisch) über das [[I2C_(Deutsch) | I2C]]-Interface. Da der Sensor für 3.3V Betriebsspannung ausgelegt ist, muss entweder der I2C-Pegel angepasst oder der ATMega auf 3.3V adaptiert werden. Weiterhin sollte die Höhe über Null bekannt sein. Beispiel: Eine Abfrage per [[ECMD]] mit ''bmp085 pressnn 59000'' bedeutet, das ich 590m (59000cm) über NN wohne. Die im Sensor verfügbare Temperatur wird parallel ausgelesen. '''Einbindung in FHEM''' bmp085.classdef erstellen: <source lang="perl"> get BMP cmd {"bmp085 temp\n\000bmp085 pressnn 59000\n"} get BMP expect ".*" get BMP postproc {\ s/(.*)\n(.*)\n/T: $1 P: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1/10;\ my $pressure = sprintf("%.1f",$2/100);\ my $state = "T: $temperature P: $pressure";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "pressure", $pressure, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die Temperatur wird in °C mit einer Nachkommastelle gelesen, der Luftdruck in hPa bzw. mbar auf eine Nachkommastelle gerundet. Passende Readings werden erstellt. Das expect .* kann noch angepasst werden, um bei fehlerhaften Messwerten entsprechend zu reagieren. Die classdef wird in FHEM eingebunden (mehrere .classdef mit Doppelpunkt trennen: siehe [[Nutzung_in_FHEM_(Deutsch)#Grundlagen | Grundlagen]]): <pre> define NETIO_STK ECMD telnet 192.168.3.89:2701 attr NETIO_STK classdefs BMP=/opt/fhem/FHEM/bmp085.classdef </pre> Der Sensor wird definiert: <pre> define BMP180 ECMDDevice BMP attr BMP180 IODev NETIO_STK </pre> Das STATE ''kann'' mit Maßeinheiten versehen werden: <pre> attr BMP180 stateFormat { sprintf("%s°C %shPa", ReadingsVal("BMP180","temperature",0), ReadingsVal("BMP180","pressure",0)) ;; } </pre> Eine zyklische Messung alle 4 Minuten erfolgt wieder mit ''at'': <pre> define Messung_BMP at +*00:04 get BMP180 BMP attr Messung_BMP verbose 0 </pre> Dabei unterdrückt verbose 0 einen zusätzlichen (doppelten) Logeintrag des Messvorganges. == analoge Eingänge abfragen == Die analogen Eingänge des ATMega sind recht simpel abzufragen. Dabei werden die hexadezimalen Werte gleich dezimal gewandelt, um die Weiterverarbeitung zu erleichtern. '''Einbindung in FHEM''' adc.classdef erstellen: <source lang="perl"> get value cmd {"adc get %PortID\n"} params PortID get value expect ".*" get value postproc {\ my $hexval = hex(trim("$_"));\ my $hash = $defs{%NAME};\ readingsSingleUpdate($hash, "state", $hexval, 1);\ } </source> Die classdef wird eingebunden: <pre> define NETIO_KU ECMD telnet 192.168.3.89:2701 attr NETIO_KU classdefs ADC=/opt/fhem/FHEM/adc.classdef </pre> Die Sensoren an den ersten beiden Ports werden definiert: <pre> define MP_0 ECMDDevice ADC 0 attr MP_0 IODev NETIO_KU define MP_1 ECMDDevice ADC 1 attr MP_1 IODev NETIO_KU </pre> Eine zyklische Messung alle 60 Sekunden funktioniert damit: <pre> define Messung_adc at +*00:01 get MP_0 value;; get MP_1 value attr Messung_adc verbose 0 </pre> == digitale Eingänge abfragen == todo == digitale Eingänge - proaktiv == Kontakte, die bei Zustandsänderung sofort in FHEM eine Meldung erzeugen sollen, kann man nicht zeitnah mit Polling abfragen. Diese Ereignisse, welche auch aus einem Control6-Script heraus generiert sein können, sollen selbst Meldung machen. Hierbei wird die ESEND-Funktion benutzt, mit welcher auch mehrere Ethersex'e untereinander kommunizieren können. Dabei ist es nicht relevant, ob das Device in FHEM per ECMDDevice bereits eingebunden wurde. Zuerst muss FHEM auf Port 2701 für Telnet-Verbindungen empfänglich werden: <pre> define telnetECMD telnet 2701 global </pre> Mit ''Watch io changes and react'' lässt sich per menuconfig bereits auf einfache Weise eine Abfrage von Portpins mit Generierung eines ESEND-Befehles bewerkstelligen. Das Beispiel soll zeigen, wie bei entsprechender Zustandsänderung an Pin PA0 an 192.168.178.10 ein FHEM-Befehl gesendet wird: <pre> ECMDTCP(PA0, RISING, 192.168.178.10, set Lampe on\n\n) ECMDTCP(PA0, FALLING, 192.168.178.10, set Lampe off\n\n) </pre> Jede Sequenz muss mit \n\n abgeschlossen werden, damit FHEM für weitere Befehle empfangsbereit bleibt. Falls man in FHEM flexibler bei der Weiterverarbeitung sein möchte, bietet sich eine dummy-notify-Kombination an. == [[Porterweiterungen_%28Deutsch%29#D.2FA-Wandler_mit_LTC1257 | LTC1257 D/A-Wandler]] == [[File:LTC1257.jpg|150px|thumb|right|LTC1257 Digital-Analog-Wandler innerhalb einer Schaltung]] Die 12bit Digital-Analog-Wandler von LINEAR TECHNOLOGY werden mit drei Pins bedient. Er wandelt (bei interner Referenzspannung) einen digital übermittelten Wert in eine Spannung von 0-2,048V um. Ein nachgeschalteter OPV als nichtinvertierender Verstärker kann diesen Bereich entsprechend skalieren. ltc1257.classdef erstellen: <source lang="perl"> # Umsetzung in ECMD Befehle # Ein Uebergabeparameter -> Sollwert set setDAC params dacValue set setDAC cmd {"ltc1257_set %dacValue\n"} set setDAC expect "OK\n" # Keine Uebergabeparameter set init cmd {"ltc1257_init\n"} set init expect "OK\n" # } </source> Die classdef wird eingebunden: <pre> define NETIO_KU ECMD telnet 192.168.3.82:2701 attr NETIO_KU classdefs LTC1257=/opt/fhem/FHEM/ltc1257.classdef </pre> Der LTC wird entsprechend definiert: <pre> define HZ_DAC ECMDDevice LTC1257 attr HZ_DAC IODev NETIO_KU </pre> Nun lässt sich mit einem '''set HZ_DAC init''' der LTC initialisieren (die gemessene Ausgangsspannung sollte 0V sein) und mit '''set HZ_DAC setDAC [0...4095]''' der gewünschte Wert setzen. Hier muss vorab experimentell entsprechend der nachfolgenden Beschaltung die tatsächliche Spannung ermittelt werden. == HD44780 Punktmatrixdisplays == [[File:HD44780.jpg|150px|thumb|right|verschiedene HD44780 Displays (16x1 bis 40x4)]] Die beliebten Punktmatrix-Displays auf Basis [http://de.wikipedia.org/wiki/HD44780 HD44780] können vollumfänglich in FHEM beschrieben werden. Dabei wird vorrausgesetzt, das in [https://github.com/ethersex/ethersex/blob/master/hardware/lcd/hd44780.h /hardware/lcd/hd44780.h] beim entsprechenden Modell die passende Adressierung der Zeilen und die genutzte Zeilen-/Spaltenzahl vor dem Compilieren angepasst wurde. '''Einbindung in FHEM''' lcd.classdef erstellen: <source lang="perl"> # Umsetzung der ECMD Befehle set write params line col text set write cmd {"lcd goto %line %col\n\000lcd write %text\n"} set write expect "OK\n" set write postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set clear params col set clear cmd {"lcd clear %col\n"} set clear expect "OK\n" set clear postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set clear_all cmd {"lcd clear\n"} set clear_all expect "OK\n" set clear_all postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set lcd_bl params state set lcd_bl cmd {"lcd backlight %state\n"} set lcd_bl expect "OK\n" set lcd_bl postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} </source> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs LCD=/opt/fhem/FHEM/lcd.classdef </pre> Das Display wird definiert: <pre> define WZ_LCD ECMDDevice LCD attr WZ_LCD IODev NETIO_TEST </pre> Es stehen in FHEM folgende Befehle für das LCD bereit: {| border='1' | ''Befehl'' | ''Funktion'' |- | set WZ_LCD clear [ZEILE] | löscht den Inhalt einer ZEILE (0...3) |- | set WZ_LCD clear_all | löscht den Inhalt aller Zeilen |- | set WZ_LCD lcd_bl STATE | schaltet die Hintergrundbeleuchtung ein oder aus (STATE on oder off) |- | set WZ_LCD write [ZEILE] [SPALTE] [TEXT] | schreibt einen TEXT auf Position ZEILE SPALTE (0...n) |- |} Da ein im TEXT übergebenes Leerzeichen als weiterer Befehl interpretiert wird und zu einer Fehlermeldung führt, ist eine Übergabe nur mit \x20 im Text möglich. Das gilt auch für Umlaute. Anhand der [http://de.wikipedia.org/wiki/HD44780#Schrift_und_Zeichensatz Zeichensatztabelle] lassen sich ä durch \xE1, ü durch \xF5 und ö durch \xEF darstellen. Das ß wird mit \xE2 erreicht. Die Tabelle kann für manche Displays abweichend sein.<br /> Beispiel: ''set WZ_LCD write 0 0 Fenster\x20schlie\xE2en'' schreibt ein '''Fenster schließen''' auf's LCD. '''Komfortable Nutzung in FHEM mit DLCD''' Mit dem DLCD-Modul ([http://www.fhemwiki.de/wiki/DLCD Wiki-Beitrag] / [http://forum.fhem.de/index.php/topic,24519.0.html Foren-Beitrag]) für FHEM lässt sich jedes Display auf einfache Weise beschreiben. Dabei lassen sich bequem Readings von allen Devices nutzen, aufbereiten (formatieren, umrechnen, etc.) und entsprechend darstellen. Eine genaue Beschreibung hält der Wiki-Beitrag bereit; hier soll ein Beispiel gezeigt werden. Ziel war es, auf einem 16x1 LCD wechselweise ''Datum/Zeit => Klimadaten Keller => Datum/Zeit => Klimadaten Garten'' darzustellen. Die Anzeige rotiert im 15-Sekunden-Takt, so das zu 50% Datum/Zeit und je 25% die Werte aus dem Garten und dem Keller angezeigt werden. Es wird bereits im Modul jedes Leerzeichen mit \x20 übersetzt. Der Außensensor ist ein [http://www.elv.de/elv-funk-kombi-wettersensor-ks-300-2-br-inkl-hochwertigem-2-m-edelstahlmast-br-und-qualitaetsbatterien.html KS300] (bzw. KS200) von ELV. Mit etwas Formatierung und ein paar Leerzeichen lässt sich eine stets gleiche Positionierung der Daten erreichen, da die Zeile nicht explizit gelöscht wird. Auszug aus der fhem.cfg: <pre> define DLCD_WZ DLCD attr DLCD_WZ dlcdBlankspaceReplace \x20 attr DLCD_WZ dlcdCols 16 attr DLCD_WZ dlcdLine1 %date_WD_ger% %date_D%.%date_M_ger% %time_h%:%time_m% attr DLCD_WZ dlcdLine2 Keller:%1%/%2% attr DLCD_WZ dlcdLine3 %date_WD_ger% %date_D%.%date_M_ger% %time_h%:%time_m% attr DLCD_WZ dlcdLine4 Garten: %3%/%4% attr DLCD_WZ dlcdPhysicalRows 1 attr DLCD_WZ dlcdPollInterval 15 attr DLCD_WZ dlcdRows 4 attr DLCD_WZ dlcdScrolling 1 attr DLCD_WZ dlcdTriggerCmd set WZ_LCD write %L% 0 %T% attr DLCD_WZ dlcdVal1 Keller:temperature attr DLCD_WZ dlcdVal1formatnum 3+1 attr DLCD_WZ dlcdVal2 Keller:humidity attr DLCD_WZ dlcdVal2formatnum 3+1 attr DLCD_WZ dlcdVal3 KS300:temperature attr DLCD_WZ dlcdVal3formatnum 3+1+- attr DLCD_WZ dlcdVal4 KS300:humidity attr DLCD_WZ dlcdVal4formatnum 2+0 </pre> Das Ergebnis kann so aussehen: <gallery> DLCD_1.jpg|Zustand 1.-15. Sekunde DLCD_2.jpg|Zustand 16.-30. Sekunde DLCD_3.jpg|Zustand 31.-45. Sekunde DLCD_4.jpg|Zustand 46.-60. Sekunde </gallery> Die Formatierung bewirkt eine immer identische Platzierung der Daten. Der Außensensor hat keine Zehntelwerte bei der Feuchte, muss dafür aber negative Temperaturen darstellen. Der Innensensor zeigt Zehntelwerte, womit sich Tendenzen eher erkennen lassen. == [[RFM12_ASK_(Deutsch) | Intertechno schalten mit RFM12]] == todo == [[RFM12_ASK_(Deutsch) | IC2272 schalten mit RFM12]] == todo [[Category:Application|Application]] fa870a17c4ad7d1094ae379ff291d806175305ef 1406 1405 2014-10-16T15:46:28Z Kpwg 721 /* HD44780 Punktmatrixdisplays */ wikitext text/x-wiki {{i18n|Nutzung in FHEM}} [http://www.fhemwiki.de/wiki/Hauptseite FHEM] ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um diverse per Funk und Kabel angebundene Komponenten aus dem Bereich der Hausautomation zu steuern. Er ist lizensiert unter der GPL v2. Das [http://www.pollin.de/shop/suchergebnis.html?S_TEXT=810+058 AVR-Net-IO] von [http://www.pollin.de Pollin] mit [[Ethersex]] dient als [http://www.fhemwiki.de/wiki/AVR-NET-IO preisgünstiger Einstieg in die Hausautomatisierung]. Verwendbar ist aber auch jede andere [[Supported_Boards_(Deutsch) | Hardware]], die von Ethersex unterstützt wird (Arduino, eigene Entwicklungen, etc.). Über [[ECMD]] lassen sich dabei theoretisch alle in [[Ethersex]] vorhandenen [[ECMD_Protocols_%28Deutsch%29 | Möglichkeiten]] nutzen, sofern in FHEM entsprechende [http://fhem.de/commandref.html#ECMD ECMD-Devices] definiert und eingebunden werden, die passende Klassendefinition exisitert und die Aktion ausgelöst wird. == Grundlagen == Ausgehend von einem fertigen und per Telnet erreichbaren Ethersex muss in FHEM zuerst das entsprechende Device definiert werden. <pre> define NETIO_WZ ECMD telnet 192.168.3.81:2701 </pre> Eine serielle Anbindung kann mit ''define <name> ECMD serial <SerialDevice>[<@BaudRate>]'' alternativ erfolgen. Anschließend werden die erstellten .classdef-Konfigurationsdateien der einzelnen Funktionen dem System bekannt gemacht. In diesen .classdef-Dateien (Name und Endung sind frei wählbar!) wird die Schnittstelle zwischen FHEM und ECMD/Ethersex definiert. Dabei können mit perl übergebene Parameter und empfangene Daten bearbeitet sowie die in FHEM gebräuchlichen Readings erstellt werden. <pre> attr NETIO_WZ classdefs RFM12_2272=/opt/fhem/FHEM/rfm12_2272.classdef:RFM12_IT=/opt/fhem/FHEM/rfm12_it.classdef:LCD=/opt/fhem/FHEM/lcd.classdef:DHT22=/opt/fhem/FHEM/dht22.classdef:1WIRE=/opt/fhem/FHEM/1wire.classdef </pre> Die Definitionen für IC2272, Intertechno, HD44780-LCD, DHT22 und 1wire sind nun eingebunden. In den folgenden Abschnitten wird auf die einzelnen Devices näher eingegangen. Generell sind Pfade und IP-Adressen sowie übergebene Parameter noch entsprechend der eigenen Konfiguration anzupassen. == [[Onewire_(Deutsch) | 1-Wire Temperatursensoren]] == [[File:DS18B20.jpg|150px|thumb|right|DS18B20-Sensoren]] Die 1wire-Temperatursensoren DS18B20 oder DS18S20 werden im [[Onewire_(Deutsch)#Polling_Modus | Polling Modus]] abgefragt. Das macht die zyklische Abfrage aus FHEM heraus wesentlich einfacher. Eine Polling-Zeit von mindestens 30 Sekunden ist absolut ausreichend.Im Vorfeld sollte man sich die [[Onewire_(Deutsch)#Benennung_von_Sensoren | ROM-Codes der Sensoren]] notieren, da diese nachher benötigt werden. 1w-temp.classdef erstellen: <source lang="perl"> # Uebergabeparameter Onewire Rom-Code params devID # Umsetzung in ECMD Befehle 1w get = Temperatur auslesen get 1W cmd {"1w get %devID\n"} get 1W expect "\d+.\d\n" get 1W postproc {\ s/\n//g;\ my $hash = $defs{%NAME};\ my $temperature = $_;\ my $state = "T: $temperature";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die classdef wird eingebunden: <pre> define NETIO_KU ECMD telnet 192.168.3.82:2701 attr NETIO_KU classdefs 1W-TEMP=/opt/fhem/FHEM/1w-temp.classdef </pre> Die Sensoren werden anhand des ROM-Code definiert: <pre> define HZ_WW ECMDDevice 1W-TEMP 284c8820050003d4 attr HZ_WW IODev NETIO_KU define HZ_VL ECMDDevice 1W-TEMP 2890a520050003d7 attr HZ_VL IODev NETIO_KU </pre> Eine zyklische Messung pro Minute lässt sich in dieser Form auslösen: <pre> define Messung_1w at +*00:01 get HZ_WW 1W;; get HZ_VL 1W attr Messung_1w verbose 0 </pre> == [[DHT|DHT22 Temperatur-/Feuchtesensoren]] == [[File:DHT22.jpg|150px|thumb|right|DHT22-Sensoren]] [[Ethersex]] unterstützt die preiswerten Temperatur-/Feuchtesensoren [[DHT|DHT11 und DHT22]], wobei letztere [[DHT#DHT11_vs_DHT22|um einiges genauer sind]]. Die Sensoren benötigen 5V Betriebsspannung und kommunizieren über je einen Pin mit dem Prozessor. Der Preis pro Stück liegt derzeit bei etwa 3.50 Euro (ebay/China). Wer die Trägheit und Ungenauigkeit der S300TH oder TX29DTH kennt, wünscht sich vermutlich Besseres; vor allem bei Berechnung von [http://de.wikipedia.org/wiki/Taupunkt Taupunkt] und [http://de.wikipedia.org/wiki/Luftfeuchtigkeit#Absolute_Luftfeuchtigkeit absoluter Feuchte], welche von der Genauigkeit der gemessenen Eingangsgrößen sehr profitieren. Berechnungen von Hand kann man beim [http://www.wetterochs.de/wetter/feuchte.html Wetterochs] durchführen. Die automatische Berechnung der absoluten Feuchte in FHEM wird im [http://forum.fhem.de/index.php/topic,21458.0.html Forum] erklärt. '''Einbindung in FHEM''' dht22m.classdef erstellen: <source lang="perl"> # Uebergabeparameter DHT22 ID 0...n params devID # Umsetzung in ECMD Befehle fuer DHT22 get DHT cmd {"dht temp %devID\n\000dht humid %devID\n"} get DHT expect "\d+.\d\n" get DHT postproc {\ s/(.*)\n(.*)\n/T: $1 H: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1;\ my $humidity = $2;\ my $state = $_;\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "humidity", $humidity, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs DHT22M=/opt/fhem/FHEM/dht22m.classdef </pre> Die Sensoren werden definiert: <pre> define Test0 ECMDDevice DHT22M 0 attr Test0 IODev NETIO_TEST define Test1 ECMDDevice DHT22M 1 attr Test1 IODev NETIO_TEST define Test2 ECMDDevice DHT22M 2 attr Test2 IODev NETIO_TEST define Test3 ECMDDevice DHT22M 3 attr Test3 IODev NETIO_TEST </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_DHT at +*00:04 get Test0 DHT;; get Test1 DHT;; get Test2 DHT;; get Test3 DHT attr Messung_DHT verbose 0 </pre> Fünfzehn Messwerte pro Stunde genügen den allermeisten Anforderungen. == [[BMP085 | BMP085/BMP180 Luftdrucksensor]] == [[File:BMP180.jpg|150px|thumb|right|BMP180 (unten links)]] Ethersex unterstützt den BMP085 (bzw. den BMP180; der Code ist identisch) über das [[I2C_(Deutsch) | I2C]]-Interface. Da der Sensor für 3.3V Betriebsspannung ausgelegt ist, muss entweder der I2C-Pegel angepasst oder der ATMega auf 3.3V adaptiert werden. Weiterhin sollte die Höhe über Null bekannt sein. Beispiel: Eine Abfrage per [[ECMD]] mit ''bmp085 pressnn 59000'' bedeutet, das ich 590m (59000cm) über NN wohne. Die im Sensor verfügbare Temperatur wird parallel ausgelesen. '''Einbindung in FHEM''' bmp085.classdef erstellen: <source lang="perl"> get BMP cmd {"bmp085 temp\n\000bmp085 pressnn 59000\n"} get BMP expect ".*" get BMP postproc {\ s/(.*)\n(.*)\n/T: $1 P: $2/; $_;\ my $hash = $defs{%NAME};\ my $temperature = $1/10;\ my $pressure = sprintf("%.1f",$2/100);\ my $state = "T: $temperature P: $pressure";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "pressure", $pressure, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die Temperatur wird in °C mit einer Nachkommastelle gelesen, der Luftdruck in hPa bzw. mbar auf eine Nachkommastelle gerundet. Passende Readings werden erstellt. Das expect .* kann noch angepasst werden, um bei fehlerhaften Messwerten entsprechend zu reagieren. Die classdef wird in FHEM eingebunden (mehrere .classdef mit Doppelpunkt trennen: siehe [[Nutzung_in_FHEM_(Deutsch)#Grundlagen | Grundlagen]]): <pre> define NETIO_STK ECMD telnet 192.168.3.89:2701 attr NETIO_STK classdefs BMP=/opt/fhem/FHEM/bmp085.classdef </pre> Der Sensor wird definiert: <pre> define BMP180 ECMDDevice BMP attr BMP180 IODev NETIO_STK </pre> Das STATE ''kann'' mit Maßeinheiten versehen werden: <pre> attr BMP180 stateFormat { sprintf("%s°C %shPa", ReadingsVal("BMP180","temperature",0), ReadingsVal("BMP180","pressure",0)) ;; } </pre> Eine zyklische Messung alle 4 Minuten erfolgt wieder mit ''at'': <pre> define Messung_BMP at +*00:04 get BMP180 BMP attr Messung_BMP verbose 0 </pre> Dabei unterdrückt verbose 0 einen zusätzlichen (doppelten) Logeintrag des Messvorganges. == analoge Eingänge abfragen == Die analogen Eingänge des ATMega sind recht simpel abzufragen. Dabei werden die hexadezimalen Werte gleich dezimal gewandelt, um die Weiterverarbeitung zu erleichtern. '''Einbindung in FHEM''' adc.classdef erstellen: <source lang="perl"> get value cmd {"adc get %PortID\n"} params PortID get value expect ".*" get value postproc {\ my $hexval = hex(trim("$_"));\ my $hash = $defs{%NAME};\ readingsSingleUpdate($hash, "state", $hexval, 1);\ } </source> Die classdef wird eingebunden: <pre> define NETIO_KU ECMD telnet 192.168.3.89:2701 attr NETIO_KU classdefs ADC=/opt/fhem/FHEM/adc.classdef </pre> Die Sensoren an den ersten beiden Ports werden definiert: <pre> define MP_0 ECMDDevice ADC 0 attr MP_0 IODev NETIO_KU define MP_1 ECMDDevice ADC 1 attr MP_1 IODev NETIO_KU </pre> Eine zyklische Messung alle 60 Sekunden funktioniert damit: <pre> define Messung_adc at +*00:01 get MP_0 value;; get MP_1 value attr Messung_adc verbose 0 </pre> == digitale Eingänge abfragen == todo == digitale Eingänge - proaktiv == Kontakte, die bei Zustandsänderung sofort in FHEM eine Meldung erzeugen sollen, kann man nicht zeitnah mit Polling abfragen. Diese Ereignisse, welche auch aus einem Control6-Script heraus generiert sein können, sollen selbst Meldung machen. Hierbei wird die ESEND-Funktion benutzt, mit welcher auch mehrere Ethersex'e untereinander kommunizieren können. Dabei ist es nicht relevant, ob das Device in FHEM per ECMDDevice bereits eingebunden wurde. Zuerst muss FHEM auf Port 2701 für Telnet-Verbindungen empfänglich werden: <pre> define telnetECMD telnet 2701 global </pre> Mit ''Watch io changes and react'' lässt sich per menuconfig bereits auf einfache Weise eine Abfrage von Portpins mit Generierung eines ESEND-Befehles bewerkstelligen. Das Beispiel soll zeigen, wie bei entsprechender Zustandsänderung an Pin PA0 an 192.168.178.10 ein FHEM-Befehl gesendet wird: <pre> ECMDTCP(PA0, RISING, 192.168.178.10, set Lampe on\n\n) ECMDTCP(PA0, FALLING, 192.168.178.10, set Lampe off\n\n) </pre> Jede Sequenz muss mit \n\n abgeschlossen werden, damit FHEM für weitere Befehle empfangsbereit bleibt. Falls man in FHEM flexibler bei der Weiterverarbeitung sein möchte, bietet sich eine dummy-notify-Kombination an. == [[Porterweiterungen_%28Deutsch%29#D.2FA-Wandler_mit_LTC1257 | LTC1257 D/A-Wandler]] == [[File:LTC1257.jpg|150px|thumb|right|LTC1257 Digital-Analog-Wandler innerhalb einer Schaltung]] Die 12bit Digital-Analog-Wandler von LINEAR TECHNOLOGY werden mit drei Pins bedient. Er wandelt (bei interner Referenzspannung) einen digital übermittelten Wert in eine Spannung von 0-2,048V um. Ein nachgeschalteter OPV als nichtinvertierender Verstärker kann diesen Bereich entsprechend skalieren. ltc1257.classdef erstellen: <source lang="perl"> # Umsetzung in ECMD Befehle # Ein Uebergabeparameter -> Sollwert set setDAC params dacValue set setDAC cmd {"ltc1257_set %dacValue\n"} set setDAC expect "OK\n" # Keine Uebergabeparameter set init cmd {"ltc1257_init\n"} set init expect "OK\n" # } </source> Die classdef wird eingebunden: <pre> define NETIO_KU ECMD telnet 192.168.3.82:2701 attr NETIO_KU classdefs LTC1257=/opt/fhem/FHEM/ltc1257.classdef </pre> Der LTC wird entsprechend definiert: <pre> define HZ_DAC ECMDDevice LTC1257 attr HZ_DAC IODev NETIO_KU </pre> Nun lässt sich mit einem '''set HZ_DAC init''' der LTC initialisieren (die gemessene Ausgangsspannung sollte 0V sein) und mit '''set HZ_DAC setDAC [0...4095]''' der gewünschte Wert setzen. Hier muss vorab experimentell entsprechend der nachfolgenden Beschaltung die tatsächliche Spannung ermittelt werden. == [[LCD_(Deutsch) | HD44780 Punktmatrixdisplays]] == [[File:HD44780.jpg|150px|thumb|right|verschiedene HD44780 Displays (16x1 bis 40x4)]] Die beliebten Punktmatrix-Displays auf Basis [http://de.wikipedia.org/wiki/HD44780 HD44780] können vollumfänglich in FHEM beschrieben werden. Dabei wird vorrausgesetzt, das in [https://github.com/ethersex/ethersex/blob/master/hardware/lcd/hd44780.h /hardware/lcd/hd44780.h] beim entsprechenden Modell die passende Adressierung der Zeilen und die genutzte Zeilen-/Spaltenzahl vor dem Compilieren angepasst wurde. '''Einbindung in FHEM''' lcd.classdef erstellen: <source lang="perl"> # Umsetzung der ECMD Befehle set write params line col text set write cmd {"lcd goto %line %col\n\000lcd write %text\n"} set write expect "OK\n" set write postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set clear params col set clear cmd {"lcd clear %col\n"} set clear expect "OK\n" set clear postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set clear_all cmd {"lcd clear\n"} set clear_all expect "OK\n" set clear_all postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set lcd_bl params state set lcd_bl cmd {"lcd backlight %state\n"} set lcd_bl expect "OK\n" set lcd_bl postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} </source> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs LCD=/opt/fhem/FHEM/lcd.classdef </pre> Das Display wird definiert: <pre> define WZ_LCD ECMDDevice LCD attr WZ_LCD IODev NETIO_TEST </pre> Es stehen in FHEM folgende Befehle für das LCD bereit: {| border='1' | ''Befehl'' | ''Funktion'' |- | set WZ_LCD clear [ZEILE] | löscht den Inhalt einer ZEILE (0...3) |- | set WZ_LCD clear_all | löscht den Inhalt aller Zeilen |- | set WZ_LCD lcd_bl STATE | schaltet die Hintergrundbeleuchtung ein oder aus (STATE on oder off) |- | set WZ_LCD write [ZEILE] [SPALTE] [TEXT] | schreibt einen TEXT auf Position ZEILE SPALTE (0...n) |- |} Da ein im TEXT übergebenes Leerzeichen als weiterer Befehl interpretiert wird und zu einer Fehlermeldung führt, ist eine Übergabe nur mit \x20 im Text möglich. Das gilt auch für Umlaute. Anhand der [http://de.wikipedia.org/wiki/HD44780#Schrift_und_Zeichensatz Zeichensatztabelle] lassen sich ä durch \xE1, ü durch \xF5 und ö durch \xEF darstellen. Das ß wird mit \xE2 erreicht. Die Tabelle kann für manche Displays abweichend sein.<br /> Beispiel: ''set WZ_LCD write 0 0 Fenster\x20schlie\xE2en'' schreibt ein '''Fenster schließen''' auf's LCD. '''Komfortable Nutzung in FHEM mit DLCD''' Mit dem DLCD-Modul ([http://www.fhemwiki.de/wiki/DLCD Wiki-Beitrag] / [http://forum.fhem.de/index.php/topic,24519.0.html Foren-Beitrag]) für FHEM lässt sich jedes Display auf einfache Weise beschreiben. Dabei lassen sich bequem Readings von allen Devices nutzen, aufbereiten (formatieren, umrechnen, etc.) und entsprechend darstellen. Eine genaue Beschreibung hält der Wiki-Beitrag bereit; hier soll ein Beispiel gezeigt werden. Ziel war es, auf einem 16x1 LCD wechselweise ''Datum/Zeit => Klimadaten Keller => Datum/Zeit => Klimadaten Garten'' darzustellen. Die Anzeige rotiert im 15-Sekunden-Takt, so das zu 50% Datum/Zeit und je 25% die Werte aus dem Garten und dem Keller angezeigt werden. Es wird bereits im Modul jedes Leerzeichen mit \x20 übersetzt. Der Außensensor ist ein [http://www.elv.de/elv-funk-kombi-wettersensor-ks-300-2-br-inkl-hochwertigem-2-m-edelstahlmast-br-und-qualitaetsbatterien.html KS300] (bzw. KS200) von ELV. Mit etwas Formatierung und ein paar Leerzeichen lässt sich eine stets gleiche Positionierung der Daten erreichen, da die Zeile nicht explizit gelöscht wird. Auszug aus der fhem.cfg: <pre> define DLCD_WZ DLCD attr DLCD_WZ dlcdBlankspaceReplace \x20 attr DLCD_WZ dlcdCols 16 attr DLCD_WZ dlcdLine1 %date_WD_ger% %date_D%.%date_M_ger% %time_h%:%time_m% attr DLCD_WZ dlcdLine2 Keller:%1%/%2% attr DLCD_WZ dlcdLine3 %date_WD_ger% %date_D%.%date_M_ger% %time_h%:%time_m% attr DLCD_WZ dlcdLine4 Garten: %3%/%4% attr DLCD_WZ dlcdPhysicalRows 1 attr DLCD_WZ dlcdPollInterval 15 attr DLCD_WZ dlcdRows 4 attr DLCD_WZ dlcdScrolling 1 attr DLCD_WZ dlcdTriggerCmd set WZ_LCD write %L% 0 %T% attr DLCD_WZ dlcdVal1 Keller:temperature attr DLCD_WZ dlcdVal1formatnum 3+1 attr DLCD_WZ dlcdVal2 Keller:humidity attr DLCD_WZ dlcdVal2formatnum 3+1 attr DLCD_WZ dlcdVal3 KS300:temperature attr DLCD_WZ dlcdVal3formatnum 3+1+- attr DLCD_WZ dlcdVal4 KS300:humidity attr DLCD_WZ dlcdVal4formatnum 2+0 </pre> Das Ergebnis kann so aussehen: <gallery> DLCD_1.jpg|Zustand 1.-15. Sekunde DLCD_2.jpg|Zustand 16.-30. Sekunde DLCD_3.jpg|Zustand 31.-45. Sekunde DLCD_4.jpg|Zustand 46.-60. Sekunde </gallery> Die Formatierung bewirkt eine immer identische Platzierung der Daten. Der Außensensor hat keine Zehntelwerte bei der Feuchte, muss dafür aber negative Temperaturen darstellen. Der Innensensor zeigt Zehntelwerte, womit sich Tendenzen eher erkennen lassen. == [[RFM12_ASK_(Deutsch) | Intertechno schalten mit RFM12]] == todo == [[RFM12_ASK_(Deutsch) | IC2272 schalten mit RFM12]] == todo [[Category:Application|Application]] c1e294a33e63c1d5b6aa04b0c1de9a72c4b5340a 0 183 1407 566 2014-10-16T16:27:57Z Kpwg 721 /* Anschluss */ Links angepasst wikitext text/x-wiki {{i18n|I2C}} {{Module |NAME=I2C |MENUCONFIG={{I/O}}-{{I2C Master}} |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6= - |DEPENDS= - |REQUIRES= CONFIG_EXPERIMENTAL |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/i2c/master https://github.com/ethersex/ethersex/tree/master/hardware/i2c/master] }} Der I2C-Bus (Inter Integrated Circuit) ist ein einfacher Zweidraht-Bus, der für die Kommunikation zwischen ICs innerhalb eines größeren Systems verwendet wird. Insbesondere bietet er sich an zur Kommunikation zwischen Microcontrollern und Peripheriegeräten. Das [[Ethersex]]-System kann sowohl als Master als auch als Slave in einem I2C-Bus arbeiten. In der Atmel-Dokumentation wird I2C als TWI (Two Wire Interface) geführt. ==Master Mode== Im Master-Mode kann das Ethersex-System auf angeschlossene I2C-Slaves zugreifen. Unterstützt werden im Moment: * 24cXX EEPROMs (Als Storage Backend für das Virtuelle Dateisystem) * LM75 Temperatursensoren * PCA9531 8 bit LED Dimmer * PCF8574x Port Extension ==Slave Mode== * Kann per I2C auf die [[ECMD (Deutsch) | ECMD ]] Schnittstelle zugegriffen werden. * In menuconfig -> Protocols -> ECMD -> I2C aktivieren [[I2C/Slave Example (Deutsch) | Beispielimplementierung]] mit Ethersex (Slave) und einem zweiten AVR (Master). ==Anschluss== Die Leitungen SCL (Clock) und SDA (Data) liegen als "Alternate Function" auf I/O Leitungen der Controller. Beim ATmega32 sind dies PC0 (SCL) und PC1 (SDA). ===Etherrape=== Beim [[Etherrape_(Deutsch)|Etherrape]] ist der I2C-Bus auf einem separaten Steckverbinder herausgeführt. ===Pollin AVR-NET-IO=== Beim Pollin [[AVR-NET-IO_(Deutsch)|AVR-NET-IO]] liegen die Leitungen des Ports C auf J3, dem 25poligen SUB-D Steckverbinder. Dort lassen sich auch Versorgungsspannung und Masse für die angeschlossenen Slaves abgreifen: {|class=wikitable !Pin !Funktion |- |2 |PC0 (SCL) |- |3 |PC1 (SDA) |- |15 |5V |- |18 |GND |} ==Konfiguration== Die Leitungen sind fest vorgegeben, daher muss keine Konfiguration des Pinnings erfolgen. Die Einstellungen für den Master-Mode finden sich unter "I/O support", "I2C Master Support". == ECMD == = I2C = Mittels "i2c detect" werden die gefundenen I2C Adressen aufgelistet i2c detect detected at: 0x20 (32) detected at: 0x48 (72) detected at: 0x60 (96) Mit den allgemeinen I2C-Kommandos können alle I2C-Chips angesprochen werden. Mit dem Befehl i2c wbb 72 81 wird z. B. die Temperatur-Konvertierung auf einem DS1631 gestartet. Geschrieben wird ein Byte mit dem Wert 81 an den Chip mit der Adresse 72. Mit dem Befehl i2c rwd 72 170 wird ein Word von der Adresse 170 des Chips mit der Adresse 72 gelesen. Damit wird die Temperatur des DS1631 ausgelesen. Die Umrechung muß man dann per Hand durchführen. = LM75 = Um den LM75 Temperatursensor auszulesen (Basisadresse 0x48) muss die IC Adresse angegeben werden. In diesem Falle ist das "0" weil die IC Adresse a0 bis a2 auf Masse gesetzt werden. -> binär 000 = 0 lm75 0 21.5 = DS1631 = Ein DS1631 Temperatursensor muß nach dem Einschalten der Stromversorgung erst aktiviert werden. Der erste DS1631 mit der Adresse 0x48 hat im Befehl die Adresse 0. Mit dem folgenden Befehl wird die Temperatur-Konvertierung eingeschaltet: ds1631 convert 0 1 Jetzt kann die Temperatur ausgelesen werden. Die Genauigkeit beträgt immer die vollen 12bits. ds1631 temp 0 22.875 Wahrscheinlich können auch DS1621-Sensoren ausgelesen werden, das wurde aber noch nicht getestet! = PCF8574 = Für die Porterweiterung gilt das Schema "pcf8574x read adresse chip" wobei die adresse 0-7 sein kann, und chip "0" oder "1", je nachdem ob man den pcf8574 oder den pcf8574A benutzt. pcf8574x read 0 0 FFFF Schalten von Ausgängen mit Wert 0xF0 am PCF8574 mit Adresse 5 (Das bedeutet das a0=1 und a2=1 ist, ergo 101) d.h. die ersten 4 Ausgänge werden auf "1" die anderen 4 Ausgänge auf "0" gesetzt. pcf8574x set 5 0 F0 [[Category:Ethersex]] [[Category:StepByStep]] [[Category:I2C]] [[Category:ECMD]] 122b4ad93b8d3c1ecd25ed6efa15172589aef7b9 6 449 1408 2014-10-17T14:41:58Z Kpwg 721 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 1435 1408 2014-10-18T15:14:12Z Kpwg 721 Kpwg uploaded a new version of &quot;[[File:Fhem ke 01.jpg]]&quot; wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 450 1409 2014-10-17T14:42:46Z Kpwg 721 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 451 1410 2014-10-17T14:42:58Z Kpwg 721 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 452 1411 2014-10-17T14:43:33Z Kpwg 721 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 453 1412 2014-10-17T14:43:58Z Kpwg 721 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 454 1413 2014-10-17T14:44:26Z Kpwg 721 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 455 1414 2014-10-17T14:44:45Z Kpwg 721 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 412 1415 1388 2014-10-17T14:49:11Z Kpwg 721 /* Eigenbau Hardware */ wikitext text/x-wiki {{i18n|Supported Boards}} == Kommerzielle Produkte == <gallery> Etherrape.jpg | [[Etherrape_(Deutsch) | Etherrape]] von lochraster.org Jackalope.jpg | [[Jackalope_(Deutsch) | Jackalope]] von lochraster.org Radig.jpg | [[AVR Webmodul_(Deutsch) | AVR Webmodul]] von Ulrich Radig Avr-net-io.jpg | [[AVR-NET-IO_(Deutsch) | AVR-NET-IO]] von Pollin Funk-avr-eval.jpg | [[Funk-AVR-Evaluationsboard_(Deutsch) | Funk-AVR-Evaluationsboard]] von Pollin Conrad-probot.jpg | [[Conrad Probot_(Deutsch) | Conrad Probot]] von Conrad Fimser.jpg | [[Fimser_(Deutsch) | Fimser]] vom OV Lennestadt Jeelinkv2.jpg | [[JeeLink_(Deutsch) | JeeLink]] von JeeLabs </gallery> == Eigenbau Hardware == <gallery> Fhem_wz_01.jpg | [[Nutzung_in_FHEM_(Deutsch) | FHEM]] [[FHEM_Wohnzimmer_(Deutsch) | Roomnode #1]] Fhem_ku_01.jpg | [[Nutzung_in_FHEM_(Deutsch) | FHEM]] [[FHEM_Kueche_(Deutsch) | Roomnode #2]] Fhem_ke_01.jpg | [[Nutzung_in_FHEM_(Deutsch) | FHEM]] [[FHEM_Keller_(Deutsch) | Roomnode #3]] Bw_final.jpg | Bettwächter Atmega162-usb.jpg | ATmega162 mit USB Usb2zbus-i2c.jpg | USB to [[ZBus_(Deutsch) | ZBus]] Dongle Pumpensteuerung.jpg | Jochens Pumpensteuerung Ethmega.jpg | ths' ATmega64+ (SMD) Usbonly_atmega32+i2c_pcf8574_auf_steckbrett.jpg | USB-Ethersex mit [[I2C_(Deutsch) | I2C]] und Porterweiterung Chaotischer-aufbau.jpg | Pollins AVR-NET-IO und Erweiterungen Ethersex-Avrnet-GPA.jpg | Pollins AVR-NET-IO Steckdosenschaltzentrale Resetbox_proto_01.jpg | [[Resetbox_(Deutsch) | Resetbox]] Habo_bulbdial_clock.jpg | [[Bulbdial Clock_(Deutsch) | Bulbdial Clock]] Ftdi-lochraster.jpg | Atmega168p mit USB-Anschluss über FT232R Ehaserl-badge-eh2010.jpg | [[ehaserl_(Deutsch) | ehaserl]] Badge des easter(h)egg 2010 </gallery> [[Category:Ethersex]] [[Category:Hardware]] 4b9fd1e2627e48bba9b063e8d413677f558ef2ae 1446 1415 2014-10-26T10:44:57Z Kpwg 721 /* Eigenbau Hardware */ wikitext text/x-wiki {{i18n|Supported Boards}} == Kommerzielle Produkte == <gallery> Etherrape.jpg | [[Etherrape_(Deutsch) | Etherrape]] von lochraster.org Jackalope.jpg | [[Jackalope_(Deutsch) | Jackalope]] von lochraster.org Radig.jpg | [[AVR Webmodul_(Deutsch) | AVR Webmodul]] von Ulrich Radig Avr-net-io.jpg | [[AVR-NET-IO_(Deutsch) | AVR-NET-IO]] von Pollin Funk-avr-eval.jpg | [[Funk-AVR-Evaluationsboard_(Deutsch) | Funk-AVR-Evaluationsboard]] von Pollin Conrad-probot.jpg | [[Conrad Probot_(Deutsch) | Conrad Probot]] von Conrad Fimser.jpg | [[Fimser_(Deutsch) | Fimser]] vom OV Lennestadt Jeelinkv2.jpg | [[JeeLink_(Deutsch) | JeeLink]] von JeeLabs </gallery> == Eigenbau Hardware == <gallery> Fhem_wz_01.jpg | [[Nutzung_in_FHEM_(Deutsch) | FHEM]] [[FHEM_Wohnzimmer_(Deutsch) | Roomnode #1]] Fhem_ku_01.jpg | [[Nutzung_in_FHEM_(Deutsch) | FHEM]] [[FHEM_Kueche_(Deutsch) | Roomnode #2]] Fhem_ke_01.jpg | [[Nutzung_in_FHEM_(Deutsch) | FHEM]] [[FHEM_Keller_(Deutsch) | Roomnode #3]] Bw_final.jpg | Bettwächter Atmega162-usb.jpg | ATmega162 mit USB Usb2zbus-i2c.jpg | USB to [[ZBus_(Deutsch) | ZBus]] Dongle Pumpensteuerung.jpg | Jochens Pumpensteuerung Ethmega.jpg | ths' ATmega64+ (SMD) Usbonly_atmega32+i2c_pcf8574_auf_steckbrett.jpg | USB-Ethersex mit [[I2C_(Deutsch) | I2C]] und Porterweiterung Chaotischer-aufbau.jpg | Pollins AVR-NET-IO und Erweiterungen Ethersex-Avrnet-GPA.jpg | Pollins AVR-NET-IO Steckdosenschaltzentrale Resetbox_proto_01.jpg | [[Resetbox_(Deutsch) | Resetbox]] Habo_bulbdial_clock.jpg | [[Bulbdial Clock_(Deutsch) | Bulbdial Clock]] Ftdi-lochraster.jpg | Atmega168p mit USB-Anschluss über FT232R Ehaserl-badge-eh2010.jpg | [[ehaserl_(Deutsch) | ehaserl]] Badge des easter(h)egg 2010 Zbus_testboard.jpg | [[ZBus_(Deutsch) | ZBus]][[ZBus_Testboard_(Deutsch) | Testboard]] </gallery> [[Category:Ethersex]] [[Category:Hardware]] 04c316131c7727c7665b865096e06d81dd1311b8 10 20 1416 421 2014-10-17T18:09:52Z GooPie4o 265 wikitext text/x-wiki <noinclude>{{i18n|Template:Facts}}</noinclude> {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | style="background-color: #FFFFFF; text-align: center; border-bottom:1px solid #aaaaaa;" | '''Overview''' |- |Ethersex is a community driven firmware with network support for 8-bit AVR microcontrollers. {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- !style="width:50%" | Features !style="width:50%" | Supported Boards |- | * Support for atmega 8,16,32,64,128,644 and many more * Uses the common '''ENC28J60''' * easily customizable and expandable to suit your needs Protocols: * TCP/IP IPv4/'''IPv6''' * OpenVPN * software USB stack * RFM12 / RFM12B (433 MHz / 868 MHz) * '''i²c''' Master (numerous chips supported)/Slave * onewire * http server * can be controlled remotely using the '''Ethersex Command Protocol (ECMD)''' * [[Features|and many more]] | * NetIO (Pollin) * [[Etherrape]] (lochraster.org) * AVR Module (Ulrich Radig) * [[Jackalope]] (lochraster.org * [[Conrad_Probot|Probot]] (Conrad) * [[Fimser]] (OV Lennestadt) * [[JeeLink]] v2 (JeeLabs) * [[Funk-AVR-Evaluationsboard] (Pollin) * TODO: Custom Board * [[Supported Boards |any many more]] |} |} 15df6998b9359af6e364ce98548319d5819d94f6 1423 1416 2014-10-17T19:37:04Z GooPie4o 265 wikitext text/x-wiki <noinclude>{{i18n|Template:Facts}}</noinclude> {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | style="background-color: #FFFFFF; text-align: center; border-bottom:1px solid #aaaaaa;" | '''Overview''' |- |Ethersex is a community driven firmware with network support for 8-bit AVR microcontrollers. {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- !style="width:50%" | Features !style="width:50%" | Supported Boards |- | * Support for atmega 8,16,32,64,128,644 and many more * Uses the common '''ENC28J60''' * easily customizable and expandable to suit your needs Protocols: * TCP/IP IPv4/'''IPv6''' * OpenVPN * software USB stack * RFM12 / RFM12B (433 MHz / 868 MHz) * '''i²c''' Master (numerous chips supported)/Slave * onewire * http server * can be controlled remotely using the '''Ethersex Command Protocol (ECMD)''' * [[Features|and many more]] | * NetIO (Pollin) * [[Etherrape]] (lochraster.org) * AVR Module (Ulrich Radig) * [[Jackalope]] (lochraster.org * [[Conrad_Probot|Probot]] (Conrad) * [[Fimser]] (OV Lennestadt) * [[JeeLink]] v2 (JeeLabs) * [[Funk-AVR-Evaluationsboard] (Pollin) * AVR-NET-IO (Pollin) * [[Supported Boards |any many more]] |} |} 296965975835997f80fa459a53fa4cab94e4cf3f 1424 1423 2014-10-17T19:37:28Z GooPie4o 265 wikitext text/x-wiki <noinclude>{{i18n|Template:Facts}}</noinclude> {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | style="background-color: #FFFFFF; text-align: center; border-bottom:1px solid #aaaaaa;" | '''Overview''' |- |Ethersex is a community driven firmware with network support for 8-bit AVR microcontrollers. {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- !style="width:50%" | Features !style="width:50%" | Supported Boards |- | * Support for atmega 8,16,32,64,128,644 and many more * Uses the common '''ENC28J60''' * easily customizable and expandable to suit your needs Protocols: * TCP/IP IPv4/'''IPv6''' * OpenVPN * software USB stack * RFM12 / RFM12B (433 MHz / 868 MHz) * '''i²c''' Master (numerous chips supported)/Slave * onewire * http server * can be controlled remotely using the '''Ethersex Command Protocol (ECMD)''' * [[Features|and many more]] | * NetIO (Pollin) * [[Etherrape]] (lochraster.org) * AVR Module (Ulrich Radig) * [[Jackalope]] (lochraster.org * [[Conrad_Probot|Probot]] (Conrad) * [[Fimser]] (OV Lennestadt) * [[JeeLink]] v2 (JeeLabs) * [[Funk-AVR-Evaluationsboard]] (Pollin) * AVR-NET-IO (Pollin) * [[Supported Boards |any many more]] |} |} d09cc907d0eab6a1fe97073634bbeab2ffbdd926 1426 1424 2014-10-17T19:38:58Z GooPie4o 265 wikitext text/x-wiki <noinclude>{{i18n|Template:Facts}}</noinclude> {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | style="background-color: #FFFFFF; text-align: center; border-bottom:1px solid #aaaaaa;" | '''Overview''' |- |Ethersex is a community driven firmware with network support for 8-bit AVR microcontrollers. {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- !style="width:50%" | Features !style="width:50%" | Supported Boards |- | * Support for atmega 8,16,32,64,128,644 and many more * Uses the common '''ENC28J60''' * easily customizable and expandable to suit your needs Protocols: * TCP/IP IPv4/'''IPv6''' * OpenVPN * software USB stack * RFM12 / RFM12B (433 MHz / 868 MHz) * '''i²c''' Master (numerous chips supported)/Slave * onewire * http server * can be controlled remotely using the '''Ethersex Command Protocol (ECMD)''' * [[Features|and many more]] | * NetIO (Pollin) * [[Etherrape]] (lochraster.org) * AVR Module (Ulrich Radig) * [[Jackalope]] (lochraster.org * [[Conrad_Probot|Probot]] (Conrad) * [[Fimser]] (OV Lennestadt) * [[JeeLink]] v2 (JeeLabs) * [[Funk-AVR-Evaluationsboard]] (Pollin) * [[AVR-NET-IO]] (Pollin) * [[Supported Boards |any many more]] |} |} aacce9322b4659476fd7a9eee549c7a2d429ee3b 1428 1426 2014-10-17T19:44:58Z GooPie4o 265 wikitext text/x-wiki <noinclude>{{i18n|Template:Facts}}</noinclude> {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | style="background-color: #FFFFFF; text-align: center; border-bottom:1px solid #aaaaaa;" | '''Overview''' |- |Ethersex is a community driven firmware with network support for 8-bit AVR microcontrollers. {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- !style="width:50%" | Features !style="width:50%" | Supported Boards |- | * Support for atmega 8,16,32,64,128,644 and many more * Uses the common '''ENC28J60''' * easily customizable and expandable to suit your needs Protocols: * TCP/IP IPv4/'''IPv6''' * OpenVPN * software USB stack * RFM12 / RFM12B (433 MHz / 868 MHz) * '''i²c''' Master (numerous chips supported)/Slave * onewire * http server * can be controlled remotely using the '''Ethersex Command Protocol (ECMD)''' * [[Features|and many more]] | * [[AVR-NET-IO]] (Pollin) * [[Etherrape]] (lochraster.org) * AVR Module (Ulrich Radig) * [[Jackalope]] (lochraster.org * [[Conrad_Probot|Probot]] (Conrad) * [[Fimser]] (OV Lennestadt) * [[JeeLink]] v2 (JeeLabs) * [[Funk-AVR-Evaluationsboard]] (Pollin) * [[Supported Boards |any many more]] |} |} 7b6af58b6c3697eb72eaff376be9fe52d23f6ea0 0 434 1417 1398 2014-10-17T19:25:34Z GooPie4o 265 wikitext text/x-wiki {{i18n|Etherrape}} [[File:Etherrape.jpg|thumb|right]] Das Orginal Etherrape von Alexander Neumann (fd0), mit dem alles anfing. Die Software aus der Etherrape Projekt war auch die Basis für Ethersex. Auf dem Board ist sehr viel Zeugs drauf. Man hat also vielfältige Möglichkeiten damit zu spielen. ===Features=== * ATmega644 * Microchip ENC28J60 * DataFlash * IR-Empfänger und -Sender * RS232-/RS485-Schnittstelle * [http://www.lochraster.org/etherrape/#features und Vieles mehr] Etherrape-Bausätze sind im Web-Shop unter http://www.lochraster.org/etherrape/ erhältlich. [[Category:Hardware]] 7054992c0f4d2401bfbabb1322cedfd8992f3364 0 456 1418 2014-10-17T19:25:51Z GooPie4o 265 Created page with "{{i18n|Etherrape}} [[File:Etherrape.jpg|thumb|right]]" wikitext text/x-wiki {{i18n|Etherrape}} [[File:Etherrape.jpg|thumb|right]] e5ec0b7f812a481acc30d2e021eb2879f02df1c4 0 457 1419 2014-10-17T19:28:54Z GooPie4o 265 Created page with "{{i18n|Supported Boards}} == Commercial Products == <gallery> Etherrape.jpg | [[Etherrape_(Deutsch) | Etherrape]] von lochraster.org Jackalope.jpg | [[Jackalope_(Deutsch) | J..." wikitext text/x-wiki {{i18n|Supported Boards}} == Commercial Products == <gallery> Etherrape.jpg | [[Etherrape_(Deutsch) | Etherrape]] von lochraster.org Jackalope.jpg | [[Jackalope_(Deutsch) | Jackalope]] von lochraster.org Radig.jpg | [[AVR Webmodul_(Deutsch) | AVR Webmodul]] by lrich Radig Avr-net-io.jpg | [[AVR-NET-IO_(Deutsch) | AVR-NET-IO]] by Pollin Funk-avr-eval.jpg | [[Funk-AVR-Evaluationsboard_(Deutsch) | Funk-AVR-Evaluationsboard]] by Pollin Conrad-probot.jpg | [[Conrad Probot_(Deutsch) | Conrad Probot]] by Conrad Fimser.jpg | [[Fimser_(Deutsch) | Fimser]] by OV Lennestadt Jeelinkv2.jpg | [[JeeLink_(Deutsch) | JeeLink]] by JeeLabs </gallery> == Eigenbau Hardware == <gallery> Fhem_wz_01.jpg | [[Nutzung_in_FHEM_(Deutsch) | FHEM]] [[FHEM_Wohnzimmer | Roomnode #1]] Fhem_ku_01.jpg | [[Nutzung_in_FHEM_(Deutsch) | FHEM]] [[FHEM_Kueche | Roomnode #2]] Fhem_ke_01.jpg | [[Nutzung_in_FHEM_(Deutsch) | FHEM]] [[FHEM_Keller | Roomnode #3]] Bw_final.jpg | Bettwächter Atmega162-usb.jpg | ATmega162 mit USB Usb2zbus-i2c.jpg | USB to [[ZBus_(Deutsch) | ZBus]] Dongle Pumpensteuerung.jpg | Jochens Pumpensteuerung Ethmega.jpg | ths' ATmega64+ (SMD) Usbonly_atmega32+i2c_pcf8574_auf_steckbrett.jpg | USB-Ethersex mit [[I2C_(Deutsch) | I2C]] und Porterweiterung Chaotischer-aufbau.jpg | Pollins AVR-NET-IO und Erweiterungen Ethersex-Avrnet-GPA.jpg | Pollins AVR-NET-IO Steckdosenschaltzentrale Resetbox_proto_01.jpg | [[Resetbox_(Deutsch) | Resetbox]] Habo_bulbdial_clock.jpg | [[Bulbdial Clock_(Deutsch) | Bulbdial Clock]] Ftdi-lochraster.jpg | Atmega168p with USB connector via FT232R Ehaserl-badge-eh2010.jpg | [[ehaserl_(Deutsch) | ehaserl]] Badge des easter(h)egg 2010 </gallery> [[Category:Ethersex]] [[Category:Hardware]] 04d7145b14c3cad48b1feb6f4bf0f36c4aa69f54 1420 1419 2014-10-17T19:30:36Z GooPie4o 265 wikitext text/x-wiki {{i18n|Supported Boards}} == Commercial Products == <gallery> Etherrape.jpg | [[Etherrape | Etherrape]] by lochraster.org Jackalope.jpg | [[Jackalope | Jackalope]] by lochraster.org Radig.jpg | [[AVR Webmodul | AVR Webmodul]] by lrich Radig Avr-net-io.jpg | [[AVR-NET-IO_(Deutsch) | AVR-NET-IO]] by Pollin Funk-avr-eval.jpg | [[Funk-AVR-Evaluationsboard | Funk-AVR-Evaluationsboard]] by Pollin Conrad-probot.jpg | [[Conrad Probot | Conrad Probot]] by Conrad Fimser.jpg | [[Fimser | Fimser]] by OV Lennestadt Jeelinkv2.jpg | [[JeeLink | JeeLink]] by JeeLabs </gallery> == Eigenbau Hardware == <gallery> Fhem_wz_01.jpg | [[Nutzung_in_FHEM | FHEM]] [[FHEM_Wohnzimmer | Roomnode #1]] Fhem_ku_01.jpg | [[Nutzung_in_FHEM | FHEM]] [[FHEM_Kueche | Roomnode #2]] Fhem_ke_01.jpg | [[Nutzung_in_FHEM | FHEM]] [[FHEM_Keller | Roomnode #3]] Bw_final.jpg | Bettwächter Atmega162-usb.jpg | ATmega162 mit USB Usb2zbus-i2c.jpg | USB to [[ZBus | ZBus]] Dongle Pumpensteuerung.jpg | Jochens Pumpensteuerung Ethmega.jpg | ths' ATmega64+ (SMD) Usbonly_atmega32+i2c_pcf8574_auf_steckbrett.jpg | USB-Ethersex mit [[I2C_(Deutsch) | I2C]] und Porterweiterung Chaotischer-aufbau.jpg | Pollins AVR-NET-IO und Erweiterungen Ethersex-Avrnet-GPA.jpg | Pollins AVR-NET-IO Steckdosenschaltzentrale Resetbox_proto_01.jpg | [[Resetbox | Resetbox]] Habo_bulbdial_clock.jpg | [[Bulbdial Clock | Bulbdial Clock]] Ftdi-lochraster.jpg | Atmega168p with USB connector via FT232R Ehaserl-badge-eh2010.jpg | [[ehaserl | ehaserl]] Badge des easter(h)egg 2010 </gallery> [[Category:Ethersex]] [[Category:Hardware]] 770650db0efb6daafe7c8f577881187358ec29ff 1421 1420 2014-10-17T19:30:55Z GooPie4o 265 wikitext text/x-wiki {{i18n|Supported Boards}} == Commercial Products == <gallery> Etherrape.jpg | [[Etherrape | Etherrape]] by lochraster.org Jackalope.jpg | [[Jackalope | Jackalope]] by lochraster.org Radig.jpg | [[AVR Webmodul | AVR Webmodul]] by lrich Radig Avr-net-io.jpg | [[AVR-NET-IO | AVR-NET-IO]] by Pollin Funk-avr-eval.jpg | [[Funk-AVR-Evaluationsboard | Funk-AVR-Evaluationsboard]] by Pollin Conrad-probot.jpg | [[Conrad Probot | Conrad Probot]] by Conrad Fimser.jpg | [[Fimser | Fimser]] by OV Lennestadt Jeelinkv2.jpg | [[JeeLink | JeeLink]] by JeeLabs </gallery> == Eigenbau Hardware == <gallery> Fhem_wz_01.jpg | [[Nutzung_in_FHEM | FHEM]] [[FHEM_Wohnzimmer | Roomnode #1]] Fhem_ku_01.jpg | [[Nutzung_in_FHEM | FHEM]] [[FHEM_Kueche | Roomnode #2]] Fhem_ke_01.jpg | [[Nutzung_in_FHEM | FHEM]] [[FHEM_Keller | Roomnode #3]] Bw_final.jpg | Bettwächter Atmega162-usb.jpg | ATmega162 mit USB Usb2zbus-i2c.jpg | USB to [[ZBus | ZBus]] Dongle Pumpensteuerung.jpg | Jochens Pumpensteuerung Ethmega.jpg | ths' ATmega64+ (SMD) Usbonly_atmega32+i2c_pcf8574_auf_steckbrett.jpg | USB-Ethersex mit [[I2C_(Deutsch) | I2C]] und Porterweiterung Chaotischer-aufbau.jpg | Pollins AVR-NET-IO und Erweiterungen Ethersex-Avrnet-GPA.jpg | Pollins AVR-NET-IO Steckdosenschaltzentrale Resetbox_proto_01.jpg | [[Resetbox | Resetbox]] Habo_bulbdial_clock.jpg | [[Bulbdial Clock | Bulbdial Clock]] Ftdi-lochraster.jpg | Atmega168p with USB connector via FT232R Ehaserl-badge-eh2010.jpg | [[ehaserl | ehaserl]] Badge des easter(h)egg 2010 </gallery> [[Category:Ethersex]] [[Category:Hardware]] ed22b5900d212e4d7cba89b36ea313911d3173c7 1422 1421 2014-10-17T19:33:36Z GooPie4o 265 /* Eigenbau Hardware */ wikitext text/x-wiki {{i18n|Supported Boards}} == Commercial Products == <gallery> Etherrape.jpg | [[Etherrape | Etherrape]] by lochraster.org Jackalope.jpg | [[Jackalope | Jackalope]] by lochraster.org Radig.jpg | [[AVR Webmodul | AVR Webmodul]] by lrich Radig Avr-net-io.jpg | [[AVR-NET-IO | AVR-NET-IO]] by Pollin Funk-avr-eval.jpg | [[Funk-AVR-Evaluationsboard | Funk-AVR-Evaluationsboard]] by Pollin Conrad-probot.jpg | [[Conrad Probot | Conrad Probot]] by Conrad Fimser.jpg | [[Fimser | Fimser]] by OV Lennestadt Jeelinkv2.jpg | [[JeeLink | JeeLink]] by JeeLabs </gallery> == DIY Hardware == <gallery> Fhem_wz_01.jpg | [[Nutzung_in_FHEM | FHEM]] [[FHEM_Wohnzimmer | Roomnode #1]] Fhem_ku_01.jpg | [[Nutzung_in_FHEM | FHEM]] [[FHEM_Kueche | Roomnode #2]] Fhem_ke_01.jpg | [[Nutzung_in_FHEM | FHEM]] [[FHEM_Keller | Roomnode #3]] Bw_final.jpg | bed guard Atmega162-usb.jpg | ATmega162 with USB Usb2zbus-i2c.jpg | USB to [[ZBus | ZBus]] Dongle Pumpensteuerung.jpg | Jochen's pump control Ethmega.jpg | ths' ATmega64+ (SMD) Usbonly_atmega32+i2c_pcf8574_auf_steckbrett.jpg | USB-Ethersex with [[I2C| I2C]] and port extension Chaotischer-aufbau.jpg | Pollins AVR-NET-IO with add ons Ethersex-Avrnet-GPA.jpg | Pollins AVR-NET-IO based outlet control center Resetbox_proto_01.jpg | [[Resetbox | Resetbox]] Habo_bulbdial_clock.jpg | [[Bulbdial Clock | Bulbdial Clock]] Ftdi-lochraster.jpg | Atmega168p with USB connector via FT232R Ehaserl-badge-eh2010.jpg | [[ehaserl | ehaserl]] Badge des easter(h)egg 2010 </gallery> [[Category:Ethersex]] [[Category:Hardware]] 3a5c8fb15db25a37f1aca50889b564ddb6df5177 0 435 1425 1381 2014-10-17T19:38:17Z GooPie4o 265 wikitext text/x-wiki {{i18n|Jackalope}} 0139ae7b923c7c6f2cb27122cbf0de90ad8d8dd2 10 56 1427 427 2014-10-17T19:44:41Z GooPie4o 265 wikitext text/x-wiki <noinclude>{{i18n|Template:Facts}}</noinclude> {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | style="background-color: #FFFFFF; text-align: center; border-bottom:1px solid #aaaaaa;" | '''Überblick''' |- |Ethersex eine Firmware mit Netzwerkunterstützung für 8-bit AVR Mikrokontroller, die durch eine Community entwickelt wird. {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- !style="width:50%" | Features !style="width:50%" | Unterstützte Boards |- | * unterstützt Atmega 8,16,32,64,128,644 und viele mehr * nutzt den Ethernet-Controller '''ENC28J60''' * leicht anzupassen und zu erweitern um deine Anforderungen zu erfüllen Protokolle: * TCP/IP IPv4/'''IPv6''' * OpenVPN * Software USB stack * RFM12 / RFM12B (433 MHz / 868 MHz) * '''i²c''' Master (Untersützung zahlreicher Chips) / Slave * onewire * http server * kann mit dem '''Ethersex Command Protocol (ECMD)''' ferngesteuert werden * [[Features (Deutsch)|und viele mehr]] | * [[AVR-NET-IO_(Deutsch)|AVR-NET-IO]] (Pollin) * [[Etherrape_(Deutsch)|Etherrape]] (lochraster.org) * AVR Module (Ulrich Radig) * [[Jackalope_(Deutsch)|Jackalope]] (lochraster.org) * [[Conrad_Probot_(Deutsch)|Probot]] (Conrad) * [[Fimser_(Deutsch)|Fimser]] (OV Lennestadt) * [[JeeLink_(Deutsch)|JeeLink]] v2 (JeeLabs) * [[Funk-AVR-Evaluationsboard_(Deutsch)|Funk-AVR-Evaluationsboard]] (Pollin) * [[Supported Boards (Deutsch)|und viele mehr]] |} |} 5a95bc97a0777bf44d070cbde39a8c6535d272d0 6 458 1429 2014-10-18T08:12:38Z Kpwg 721 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 459 1430 2014-10-18T08:50:38Z Kpwg 721 Created page with "{{i18n|FHEM Keller}} == [[Nutzung_in_FHEM_(Deutsch)|FHEM]] Roomnode Keller == In einem durch nachlässiges Lüften sehr feuchten Keller sollen Temperatur/Feuchte an mehreren P..." wikitext text/x-wiki {{i18n|FHEM Keller}} == [[Nutzung_in_FHEM_(Deutsch)|FHEM]] Roomnode Keller == In einem durch nachlässiges Lüften sehr feuchten Keller sollen Temperatur/Feuchte an mehreren Punkten sowie außen am Gebäude gemessen werden. Daraus errechnet FHEM Lüftungsempfehlungen. Diese wird zusätzlich auf dem Display durch '''(auf)''' und '''(zu)''' angzeigt. Da es keine Möglichkeit gibt, per LAN in den Raum zu gelangen, musste eine Wireless-Bridge her. Damit steht zugleich LAN an der Werkbank bereit. Ein Anschluss für [[ZBus_(Deutsch) | ZBus]] lässt Platz für weitere Spielereien. '''Ziele''' * genaue Messung Temperatur/Feuchte in den Räumen und an der Außenwand * Anzeige diverser Klimadaten und Uhrzeit * pespektivisch weitere Möglichkeiten zur Steuerung/Regelung * Feuchtraum-Gehäuse '''Ausstattung''' * WLAN-Router als Wireless-Bridge * mehrere [[DHT|DHT22]] mit bis zu 6m Kabel (Cat.5-Reste) * [[LCD_(Deutsch) | LCD]] 20x4 HD44780 zur Anzeige von Datum, Uhrzeit, Klimadaten, Lüftungsempfehlung * [[ZBus_(Deutsch) | ZBus]] Interface für [[ZBus_Testboard_(Deutsch) | ZBus-Tests]] oder weitere Zbus-Roomnodes * Industrienetzteil mit Reserven für dem ZBus und Versorgung des Routers * ATMega32 '''Bilder''' <gallery> Fhem_ke_01.jpg|Aussenansicht (Klarsichtdeckel abgenommen) Fhem_ke_02.jpg|Display in Aktion Fhem_ke_03.jpg|DHT22 als Raumsensor Fhem_ke_04.jpg|Prozessorboard von oben Fhem_ke_05.jpg|Prozessorboard von unten Fhem_ke_06.jpg|Stromversorgungs-/ZBus-Board von oben Fhem_ke_07.jpg|Stromversorgungs-/ZBus-Board von unten </gallery> [[Category:Hardware]] 98568fc411595cd030309aa989cca531117904d7 1431 1430 2014-10-18T10:10:18Z Kpwg 721 wikitext text/x-wiki {{i18n|FHEM Keller}} == [[Nutzung_in_FHEM_(Deutsch)|FHEM]] Roomnode Keller == In einem durch nachlässiges Lüften sehr feuchten Keller sollen Temperatur/Feuchte an mehreren Punkten sowie außen am Gebäude gemessen werden. Daraus errechnet FHEM Lüftungsempfehlungen. Diese wird zusätzlich auf dem Display durch '''(auf)''' und '''(zu)''' angzeigt. Da es keine Möglichkeit gibt, per LAN in den Raum zu gelangen, musste eine Wireless-Bridge her. Damit steht zugleich LAN an der Werkbank bereit. Ein Anschluss für [[ZBus_(Deutsch) | ZBus]] lässt Platz für weitere Spielereien. '''Ziele''' * genaue Messung Temperatur/Feuchte in den Räumen und an der Außenwand * Anzeige diverser Klimadaten und Uhrzeit * pespektivisch weitere Möglichkeiten zur Steuerung/Regelung * Feuchtraum-Gehäuse '''Ausstattung''' * WLAN-Router als Wireless-Bridge * mehrere [[DHT|DHT22]] mit bis zu 6m Kabel (Cat.5-Reste) * [[LCD_(Deutsch) | LCD]] 20x4 HD44780 zur Anzeige von Datum, Uhrzeit, Klimadaten, Lüftungsempfehlung * [[ZBus_(Deutsch) | ZBus]] Interface mit MAX485 für [[ZBus_Testboard_(Deutsch) | ZBus-Tests]] oder weitere Zbus-Roomnodes * Industrienetzteil mit Reserven für dem ZBus und Versorgung des Routers * ATMega32 '''Bilder''' <gallery> Fhem_ke_01.jpg|Aussenansicht (Klarsichtdeckel abgenommen) Fhem_ke_02.jpg|Display in Aktion Fhem_ke_03.jpg|DHT22 als Raumsensor Fhem_ke_04.jpg|Prozessorboard von oben Fhem_ke_05.jpg|Prozessorboard von unten Fhem_ke_06.jpg|Stromversorgungs-/ZBus-Board von oben Fhem_ke_07.jpg|Stromversorgungs-/ZBus-Board von unten </gallery> [[Category:Hardware]] 8d1b59c78da642754ceef5b32f6699dfb9258a1b 0 460 1432 2014-10-18T12:39:59Z Kpwg 721 Created page with "{{i18n|ZBus Testboard}} == [[ZBus_(Deutsch) | ZBus]] Testboard == '''Wofür?''' * Hiermit lassen sich Versuche mit RS485 und ZBus anstellen um die Machbarkeit diverser Vorhab..." wikitext text/x-wiki {{i18n|ZBus Testboard}} == [[ZBus_(Deutsch) | ZBus]] Testboard == '''Wofür?''' * Hiermit lassen sich Versuche mit RS485 und ZBus anstellen um die Machbarkeit diverser Vorhaben abzuschätzen '''Ausstattung''' * Arduino ProMini Clone (hier das [http://arduino.cc/en/pmwiki.php?n=Main/ArduinoBoardProMini Original]) * MAX485 als Pegelwandler * per Jumper aktivierbare Terminierung * Verpolschutzdiode, separater Spannungsregler für MAX485 und Test-Peripherie * 6pol. ISP-Stecker '''Vorteile''' * sehr einfacher, schneller und preiswerter Aufbau * hohe Flexibilität bei Peripherie und Platzierung innerhalb des Busses * weiter Betriebsspannungsbereich '''Bilder''' <gallery> Zbus_testboard.jpg|Ansicht von oben und unten, ohne weitere Beschaltung </gallery> [[Category:Hardware]] c08f4457800fcce75f9e2af8dc5b1d7b3f3fffc2 1433 1432 2014-10-18T12:48:01Z Kpwg 721 /* ZBus Testboard */ wikitext text/x-wiki {{i18n|ZBus Testboard}} == [[ZBus_(Deutsch) | ZBus]] Testboard == '''Wofür?''' * Hiermit lassen sich Versuche mit RS485 und ZBus durchführen, um die Machbarkeit diverser Vorhaben abzuschätzen '''Ausstattung''' * Arduino ProMini Clone (hier das [http://arduino.cc/en/pmwiki.php?n=Main/ArduinoBoardProMini Original]) * MAX485 als Pegelwandler * per Jumper aktivierbare Terminierung * Verpolschutzdiode, separater Spannungsregler für MAX485 und Test-Peripherie * 6pol. ISP-Stecker '''Vorteile''' * sehr einfacher, schneller und preiswerter Aufbau (<5 Euro) * hohe Flexibilität bei Peripherie und Platzierung innerhalb des Busses * weiter Betriebsspannungsbereich '''Bilder''' <gallery> Zbus_testboard.jpg|Ansicht von oben und unten, ohne weitere Beschaltung </gallery> [[Category:Hardware]] cf8034189824dd5cae76189bd6e713820220ed58 1434 1433 2014-10-18T12:49:30Z Kpwg 721 /* ZBus Testboard */ wikitext text/x-wiki {{i18n|ZBus Testboard}} == ZBus Testboard == '''Wofür?''' * Hiermit lassen sich Versuche mit [http://de.wikipedia.org/wiki/EIA-485 RS485] und [[ZBus_(Deutsch) | ZBus]] durchführen, um die Machbarkeit diverser Vorhaben abzuschätzen '''Ausstattung''' * Arduino ProMini Clone (hier das [http://arduino.cc/en/pmwiki.php?n=Main/ArduinoBoardProMini Original]) * MAX485 als Pegelwandler * per Jumper aktivierbare Terminierung * Verpolschutzdiode, separater Spannungsregler für MAX485 und Test-Peripherie * 6pol. ISP-Stecker '''Vorteile''' * sehr einfacher, schneller und preiswerter Aufbau (<5 Euro) * hohe Flexibilität bei Peripherie und Platzierung innerhalb des Busses * weiter Betriebsspannungsbereich '''Bilder''' <gallery> Zbus_testboard.jpg|Ansicht von oben und unten, ohne weitere Beschaltung </gallery> [[Category:Hardware]] 44a6d9a56621c4ad88040ba8365a4504987187f9 1450 1434 2014-10-26T12:03:48Z Kpwg 721 /* ZBus Testboard */ wikitext text/x-wiki {{i18n|ZBus Testboard}} '''Wofür?''' * Hiermit lassen sich Versuche mit [http://de.wikipedia.org/wiki/EIA-485 RS485] und [[ZBus_(Deutsch) | ZBus]] durchführen, um die Machbarkeit diverser Vorhaben abzuschätzen '''Ausstattung''' * Arduino ProMini Clone (hier das [http://arduino.cc/en/pmwiki.php?n=Main/ArduinoBoardProMini Original]) * MAX485 als Pegelwandler * per Jumper aktivierbare Terminierung * Verpolschutzdiode, separater Spannungsregler für MAX485 und Test-Peripherie * 6pol. ISP-Stecker '''Vorteile''' * sehr einfacher, schneller und preiswerter Aufbau (<5 Euro) * hohe Flexibilität bei Peripherie und Platzierung innerhalb des Busses * weiter Betriebsspannungsbereich '''Bilder''' <gallery> Zbus_testboard.jpg|Ansicht von oben und unten, ohne weitere Beschaltung </gallery> [[Category:Hardware]] d569e65b97a4cd04360a19c44b0381cdf4ed37b5 6 461 1436 2014-10-18T15:32:07Z Kpwg 721 (c) Michaelb wikitext text/x-wiki (c) Michaelb 712623158195d55492a7288739a3b0bef5fab008 6 462 1437 2014-10-18T15:32:56Z Kpwg 721 (c) Michaelb wikitext text/x-wiki (c) Michaelb 712623158195d55492a7288739a3b0bef5fab008 6 463 1438 2014-10-18T15:33:33Z Kpwg 721 (c) Michaelb wikitext text/x-wiki (c) Michaelb 712623158195d55492a7288739a3b0bef5fab008 6 464 1439 2014-10-18T15:34:01Z Kpwg 721 (c) Michaelb wikitext text/x-wiki (c) Michaelb 712623158195d55492a7288739a3b0bef5fab008 6 465 1440 2014-10-18T15:34:54Z Kpwg 721 (c) Michaelb wikitext text/x-wiki (c) Michaelb 712623158195d55492a7288739a3b0bef5fab008 6 466 1441 2014-10-26T10:37:30Z Kpwg 721 (c) GooPie4o wikitext text/x-wiki (c) GooPie4o 20c5faa9a2e2b21593038f0a1f3f399ce1816b41 6 467 1442 2014-10-26T10:37:53Z Kpwg 721 (c) GooPie4o wikitext text/x-wiki (c) GooPie4o 20c5faa9a2e2b21593038f0a1f3f399ce1816b41 6 468 1443 2014-10-26T10:38:27Z Kpwg 721 (c) GooPie4o Relaisboard wikitext text/x-wiki (c) GooPie4o Relaisboard c248b67170e46a6b44d24448a4ee0345062c40be 6 469 1444 2014-10-26T10:38:48Z Kpwg 721 (c) GooPie4o wikitext text/x-wiki (c) GooPie4o 20c5faa9a2e2b21593038f0a1f3f399ce1816b41 0 437 1447 1383 2014-10-26T11:33:07Z Kpwg 721 /* AVR-NET-IO */ erster Entwurf wikitext text/x-wiki {{i18n|AVR-NET-IO}} == AVR-NET-IO == Das AVR-NET-IO von [http://www.pollin.de Pollin] ist ein relativ einfach gehaltenes und daher auch sehr günstiges Board. Es ist als Bausatz oder auch als Fertigmodul erhältlich. Der gelieferte ATmega32 kann einfach durch einen leistungsfähigeren ATmega644 oder ATmega1284p (Hinweise zu 128K beachten!) ausgetauscht werden. ===Features=== * Atmel ATmega32 * Microchip ENC28J60 LAN * RS232-Schnittstelle * ISP-Schnittstelle ===Errata=== [[File:Pollin_netio_03.jpg|150px|thumb|right|AVR-NET-IO Modifikationen]] Leider hat der Entwickler des Boards sich nicht an die Vorgaben von Microchip gehalten, und sich die Abblockkondensatoren an den Versorgungsspannungsanschlüssen des ENC28J60 gespart. Dadurch kann es dazu kommen, insbesondere bei hoher Netzlast, dass sich der Ethernet Controller aufhängt. Es ist daher empfehlenswert, Kondensatoren am ENC28J60 und am 3,3V Spannungsregler nachzurüsten. (Siehe Bild rechts: Platinenunterseite) Es lohnt sich auch einmal bei [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin# www.mikrocontroller.net] vorbeizuschauen. Dort gibt es sehr viele Anwender von diesem Board und viel Diskussion über Fehler und Erweiterungen. Besonders bei den Bausätzen lohnt es sich die korrekte Lieferung der Bauteile zu überprüfen. ===Beispielfotos=== <gallery> File:Pollin_netio_01.jpg|Beschreibung File:Pollin_netio_02.jpg|Beschreibung File:Pollin_netio_04.jpg|Beschreibung File:Pollin_netio_05.jpg|Beschreibung File:Pollin_netio_06.jpg|Beschreibung File:Pollin_netio_07.jpg|Beschreibung File:Pollin_netio_08.jpg|Beschreibung File:Pollin_netio-addon_01.jpg|Beschreibung </gallery> [[Category:Hardware]] f426248c5543c28663cea8f74cc3a624e5d15a58 1448 1447 2014-10-26T11:53:56Z GooPie4o 265 wikitext text/x-wiki {{i18n|AVR-NET-IO}} Das AVR-NET-IO von [http://www.pollin.de Pollin] ist ein relativ einfach gehaltenes und daher auch sehr günstiges Board. Es ist als Bausatz oder auch als Fertigmodul erhältlich. Der gelieferte ATmega32 kann einfach durch einen leistungsfähigeren ATmega644 oder ATmega1284p (Hinweise zu 128K beachten!) ausgetauscht werden. ===Features=== * Atmel ATmega32 * Microchip ENC28J60 LAN * RS232-Schnittstelle * ISP-Schnittstelle ===Errata=== [[File:Pollin_netio_03.jpg|150px|thumb|right|AVR-NET-IO Modifikationen]] Leider hat der Entwickler des Boards sich nicht an die Vorgaben von Microchip gehalten, und sich die Abblockkondensatoren an den Versorgungsspannungsanschlüssen des ENC28J60 gespart. Dadurch kann es dazu kommen, insbesondere bei hoher Netzlast, dass sich der Ethernet Controller aufhängt. Es ist daher empfehlenswert, Kondensatoren am ENC28J60 und am 3,3V Spannungsregler nachzurüsten. (Siehe Bild rechts: Platinenunterseite) Es lohnt sich auch einmal bei [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin# www.mikrocontroller.net] vorbeizuschauen. Dort gibt es sehr viele Anwender von diesem Board und viel Diskussion über Fehler und Erweiterungen. Besonders bei den Bausätzen lohnt es sich die korrekte Lieferung der Bauteile zu überprüfen. ===Beispielfotos=== <gallery> File:Pollin_netio_01.jpg|Beschreibung File:Pollin_netio_02.jpg|Beschreibung File:Pollin_netio_04.jpg|Beschreibung File:Pollin_netio_05.jpg|Beschreibung File:Pollin_netio_06.jpg|Beschreibung File:Pollin_netio_07.jpg|Beschreibung File:Pollin_netio_08.jpg|Beschreibung File:Pollin_netio-addon_01.jpg|Beschreibung </gallery> [[Category:Hardware]] 430bc6e857d37d48bd0188cf58c81fb741bc7d09 1449 1448 2014-10-26T11:54:28Z GooPie4o 265 wikitext text/x-wiki {{i18n|AVR-NET-IO}} Das AVR-NET-IO von [http://www.pollin.de Pollin] ist ein relativ einfach gehaltenes und daher auch sehr günstiges Board. Es ist als Bausatz oder auch als Fertigmodul erhältlich. Der gelieferte ATmega32 kann einfach durch einen leistungsfähigeren ATmega644 oder ATmega1284p (Hinweise zu 128K beachten!) ausgetauscht werden. ===Features=== * Atmel ATmega32 * Microchip ENC28J60 LAN * RS232-Schnittstelle * ISP-Schnittstelle ===Errata=== [[File:Pollin_netio_03.jpg|150px|thumb|right|AVR-NET-IO Modifikationen]] Leider hat der Entwickler des Boards sich nicht an die Vorgaben von Microchip gehalten, und sich die Abblockkondensatoren an den Versorgungsspannungsanschlüssen des ENC28J60 gespart. Dadurch kann es dazu kommen, insbesondere bei hoher Netzlast, dass sich der Ethernet Controller aufhängt. Es ist daher empfehlenswert, Kondensatoren am ENC28J60 und am 3,3V Spannungsregler nachzurüsten. (Siehe Bild rechts: Platinenunterseite) Es lohnt sich auch einmal bei [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin# www.mikrocontroller.net] vorbeizuschauen. Dort gibt es sehr viele Anwender von diesem Board und viel Diskussion über Fehler und Erweiterungen. Besonders bei den Bausätzen lohnt es sich die korrekte Lieferung der Bauteile zu überprüfen. ===Beispielfotos=== <gallery> File:Pollin_netio_01.jpg|Beschreibung File:Pollin_netio_02.jpg|Beschreibung File:Pollin_netio_04.jpg|Beschreibung File:Pollin_netio_05.jpg|Beschreibung File:Pollin_netio_06.jpg|Beschreibung File:Pollin_netio_07.jpg|Beschreibung File:Pollin_netio-addon_01.jpg|Beschreibung </gallery> [[Category:Hardware]] 94e5c69117c922abc7f16bc9c8726702945a229d 1454 1449 2014-10-27T18:45:08Z GooPie4o 265 wikitext text/x-wiki {{i18n|AVR-NET-IO}} Das AVR-NET-IO von [http://www.pollin.de Pollin] ist ein relativ einfach gehaltenes und daher auch sehr günstiges Board. Es ist als Bausatz oder auch als Fertigmodul erhältlich. Der gelieferte ATmega32 kann einfach durch einen leistungsfähigeren ATmega644 oder ATmega1284p (Hinweise zu 128K beachten!) ausgetauscht werden. ===Features=== * Atmel ATmega32 * Microchip ENC28J60 LAN * RS232-Schnittstelle * ISP-Schnittstelle ===Errata=== [[File:Pollin_netio_03.jpg|150px|thumb|right|AVR-NET-IO Modifikationen]] Leider hat der Entwickler des Boards sich nicht an die Vorgaben von Microchip gehalten, und sich die Abblockkondensatoren an den Versorgungsspannungsanschlüssen des ENC28J60 gespart. Dadurch kann es dazu kommen, insbesondere bei hoher Netzlast, dass sich der Ethernet Controller aufhängt. Es ist daher empfehlenswert, Kondensatoren am ENC28J60 und am 3,3V Spannungsregler nachzurüsten. (Siehe Bild rechts: Platinenunterseite) Es lohnt sich auch einmal bei [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin# www.mikrocontroller.net] vorbeizuschauen. Dort gibt es sehr viele Anwender von diesem Board und viel Diskussion über Fehler und Erweiterungen. Besonders bei den Bausätzen lohnt es sich die korrekte Lieferung der Bauteile zu überprüfen. ===Beispielfotos=== <gallery> File:Pollin_netio_01.jpg|Beschreibung File:Pollin_netio_02.jpg|Beschreibung File:Pollin_netio_04.jpg|Beschreibung File:Pollin_netio_05.jpg|Beschreibung File:Pollin_netio_06.jpg|kompatibler Nachbau der K8IO-Relaiskarte von Pollin File:Pollin_netio_07.jpg|Beschreibung File:Pollin_netio-addon_01.jpg|Beschreibung </gallery> [[Category:Hardware]] d292695151bca0cfb7ad7f4b43518bebe0a9b3ea 6 471 1451 2014-10-26T12:10:15Z Kpwg 721 (c) GooPie4o wikitext text/x-wiki (c) GooPie4o 20c5faa9a2e2b21593038f0a1f3f399ce1816b41 0 29 1452 1290 2014-10-26T12:12:43Z GooPie4o 265 wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR Receivers->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |TIMER={{occupies_timer|0}}&{{occupies_timer|2}} (RX & TX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} [[File:Irm.jpg|200px|thumb|right|IR sender/receiver module with display and USB connector]] IRMP is a port of the [http://www.mikrocontroller.net/articles/IRMP infrared multi-protocol decoder] for [[Ethersex]]. == Connection == The reception of IR signals is performed by a receiver TSOP1736 type (or similar). This may be connected to any pin. The interrogation of the pins and the decoding of the IR protocol is done in an ISR, which occupies one 8-bit timer of the ATmegas. When sending the signal with the carrier frequency of the respective IR Protocol is [[PWM]] modulated. This is another 8-bit timer of the ATmegas (OC0/OC2) is demonstrated. On the [[Etherrape]] board takes a [[NE555]] this function, ie the option ''Use external modulator for the transmitter'' is activated. It saves a timer on the [[AVR]] is set at a carrier frequency. Example of a ATMega32 from: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Meaning: * IRMP_RX - pin the IR receiver is connected to * IRMP_USE_TIMER2 - use Timer2 for receiver, Timer0 for sender (undef = reversed) * IRMP_RX_LOW_ACTIVE - the IR receiver is low-active (undef = high-active) * IRMP_RX_LED_LOW_ACTIVE - the control LED of the receiver is switched to USS (undef = switched to GND) * IRMP_TX - pin the IR sender is connected to (=output of Timer0 or Timer2, see IRMP_USE_TIMER2)<br>'''Caution: 0A to 2A if MCU with A / B channel''' Without an external modulator, pins other than OC0 or 0C2 can not be used. Trying to do so will fail without an error message. * IRMP_TX_LED_LOW_ACTIVE - the control LED of the sender is switched to USS (undef = switched to GND) == Configuration == Each supported IR protocol occupies memory of code. Therefore, one should select only the required protocols. A detailed overview of the protocols are in [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail article in the mikrocontroller forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ [ ] ORTEK │ │ [ ] TELEFUNKEN │ │ [ ] ROOMBA │ │ [ ] RCMM32 │ │ [ ] RCMM24 │ │ [ ] RCMM12 │ │ --- Network │ │ [*] Remote IRMP │ │ (10001) UDP port (default 10001) │ │ --- Debugging Flags │ │ [ ] IRMP │ │ [ ] Remote IRMP IRMP also decodes the RC5 protocol, so that the separately [[Ethersex]] contained [[RC5]] decoder is not needed any longer. == [[ECMD]] == IRMP implements an [[ECMD]] interface for reading received and decoded IR commands and send IR commands. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == === Output received characters via [[SYSLOG|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> IRMP_READ checks for received IR code and stores it in the variables IRMP_PROTOCOL, IRMP_ADDRESS, and IRMP_COMMAND IRMP_FLAGS. Return values ​​greater than zero indicate the validity of the variables. If IRMP_FLAGS = 1 it is a repetition. === Control of [[StellaLight|Stella]]/Pins by IR commands === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> The script switches the Stella channel 0 to 255 or 0, the remote control is a Denon (Protocol 8). With ''include'' access to the Stella sources granted.<br> Instead of ''"stella_setValue (STELLA_SET_IMMEDIATELY, 0, 255);"'' ''"PIN_SET (LED)"'' and ''"PIN_CLEAR (LED)"'' can be used ([[Named_PIN|named pin]]). |Named PIN]]). === Send IR commands === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 * no tx support yet dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON dnl 31 = BOSE * no tx support yet dnl 32 = A1TVBOX dnl 33 = ORTEK * no tx support yet dnl 34 = TELEFUNKEN * no tx support yet dnl 35 = ROOMBA dnl 36 = RCMM32 * no tx support yet dnl 37 = RCMM24 * no tx support yet dnl 38 = RCMM16 * no tx support yet IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Command 5678 to device 1234 will be send with one repetition using the NEC protocol. == Remote IRMP == [[File:Remote_buttler.png|200px|thumb|right|Android App]] This is an implementation of the [https://www.mikrocontroller.net/articles/Remote_IRMP Remote IRMP protocol ] in [[Ethersex]]. Control your HiFi equipment with your smartphone. 0d6f4ef5e87e51240cd7e0075f33820f7265a56a 0 30 1453 1291 2014-10-26T12:13:40Z GooPie4o 265 wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR Receivers->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |TIMER={{occupies_timer|0}}&{{occupies_timer|2}} (RX & TX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} [[File:Irm.jpg|200px|thumb|right|IR Sender/Empfänger-Modul mit LCD und USB-Anschluss]] IRMP ist eine Portierung des [http://www.mikrocontroller.net/articles/IRMP Infrarot-Multiprotokoll-Decoders] nach [[Ethersex]]. == Anschluss == Der Empfang der IR-Signale erfolgt durch einen Empfänger vom Typ TSOP1736 (oder ähnlich). Dieser kann an einem beliebigen Pin angeschlossen werden. Die Abfrage des Pins und die Dekodierung des IR-Protokolls erfolgt in einer ISR, die einen 8-Bit-Timer des ATMEGAs belegt. Beim Senden wird das Signal mit der Trägerfrequenz des jeweiligen IR-Protokolls über [[PWM_(Deutsch)|PWM]] moduliert. Dazu wird ein weiterer 8-Bit Timer des ATMEGAs (OC0/OC2) belegt. Auf dem '''[[Etherape_(Deutsch)|Etherrape]]'''-Board übernimmt ein [[NE555_(Deutsch)|NE555]] diese Funktion, d.h. die Option ''Use external modulator for sender'' ist zu aktivieren. Man spart einen Timer des [[AVR_(Deutsch)|AVR]] und ist auf eine Trägerfrequenz festgelegt. Beispiel für einen ATMega32 aus: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Bedeutung: * IRMP_RX - Pin an dem der IR-Empfänger angeschlossen ist * IRMP_USE_TIMER2 - benutze Timer2 für den Empfang, Timer0 für das Senden (undef = umgekehrt) * IRMP_RX_LOW_ACTIVE - der IR-Empfänger ist Low-Aktiv (undef = High-aktiv) * IRMP_RX_LED_LOW_ACTIVE - die Kontroll-LED des Empfängers ist gegen USS geschaltet (undef = gegen GND geschaltet) * IRMP_TX - Pin an dem der IR-Sender angeschlossen ist (= Ausgang des Timer0 oder Timer2, vgl. IRMP_USE_TIMER2)<br>'''Achtung: 0A bzw 2A bei MCU mit A/B Kanal''' Ohne einen externen Modulator sind ausschließlich OC0 oder OC2 möglich. Der Versuch einen anderen Pin zu konfigurieren wird ohne Fehlermeldung fehlschlagen. * IRMP_TX_LED_LOW_ACTIVE - die Kontroll-LED des Senders ist gegen USS geschaltet (undef = gegen GND geschaltet) == Konfiguration == Jedes unterstützte IR-Protokoll "verbrät" Speicher an Code. Deshalb sollte man nur die benötigten Protokolle auswählen. Eine detailierte Übersicht über die Protokolle gibt der [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail Artikel im Mikrocontroller Forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] SIRCS │ │ [*] NEC │ │ [ ] NEC16 │ │ [ ] NEC42 │ │ [ ] JVC │ │ [ ] SAMSUNG │ │ [ ] MATSUSHITA │ │ [ ] KASEIKYO │ │ [*] DENON │ │ [ ] RECS80 │ │ [ ] RECS80EXT │ │ [*] RC5(X) │ │ [ ] RC6 │ │ [ ] NUBERT │ │ [*] BANG&OLUFSEN │ │ [*] GRUNDIG │ │ [ ] NOKIA │ │ [*] SIEMENS │ │ [ ] FDC │ │ [ ] RCCAR │ │ [ ] NIKON │ │ [ ] RUWIDO │ │ [ ] IR60 │ │ [ ] KATHREIN │ │ [ ] NETBOX │ │ [ ] LEGO │ │ [ ] THOMSON │ │ [ ] BOSE │ │ [ ] A1TVBOX │ │ [ ] ORTEK │ │ [ ] TELEFUNKEN │ │ [ ] ROOMBA │ │ --- Network │ │ [*] Remote IRMP │ │ (10001) UDP port (default 10001) │ │ --- Debugging Flags │ │ [ ] IRMP │ │ [ ] Remote IRMP IRMP dekodiert auch das RC5-Protokoll, so dass der separat in [[Ethersex_(Deutsch)|Ethersex]] enthaltene [[RC5_(Deutsch)|RC5]]-Dekoder nicht länger benötigt wird. == [[ECMD_(Deutsch)|ECMD]] == IRMP implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle zum Auslesen empfangener und dekodierter IR-Kommandos und zum Senden von IR-Kommandos. Siehe [[ECMD_Reference|ECMD Referenz]]. == [[Control6_(Deutsch)|Control6]] == === Ausgabe empfangener IR-Zeichen via [[SYSLOG_(Deutsch)|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> Mit IRMP_READ wird auf empfangenen IR-Code geprüft und dieser in die Variablen IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND und IRMP_FLAGS gespeichert. Rückgabewerte größer Null signalisieren die Gültigkeit der Variablen. Bei IRMP_FLAGS=1 handelt es sich um eine Wiederholung. === Steuern von [[StellaLight_(Deutsch)|Stella]]/Pins durch IR-Zeichen === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> Das Script schaltet den Stella Channel 0 auf 255 oder auf 0, die Fernbedienung ist hier eine Denon (Protocol 8). Mit ''include'' wurde dem Script der Zugriff auf die Stellasourcen gestattet.<br> Statt ''"stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255);"'' kann auch ''"PIN_SET(LED)"'' und ''"PIN_CLEAR(LED)"'' verwendet werden ([[Named_PIN_(Deutsch)|Named PIN]]). === Senden von IR-Zeichen === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSHITA dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5(x) dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSUNG32 dnl 11 = APPLE dnl 12 = RECS80EXT dnl 13 = NUBERT dnl 14 = BANG&OLUFSEN dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO * no tx support yet dnl 24 = IR60 * no tx support yet dnl 25 = KATHREIN * no tx support yet dnl 26 = NETBOX * no tx support yet dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON * no tx support yet dnl 31 = BOSE dnl 32 = A1TVBOX dnl 33 = ORTEK dnl 34 = TELEFUNKEN dnl 35 = ROOMBA IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Kommando 5678 an Gerät 1234 wird mit einer Wiederholung im NEC-Protokoll gesendet. == Remote IRMP == [[File:Remote_buttler.png|200px|thumb|right|Android App]] Dies ist die Implementierung des [https://www.mikrocontroller.net/articles/Remote_IRMP Remote IRMP Protocols] in [[Ethersex]]. Damit wird es möglich, mit einer Android-App eine anlernbare IR-Fernbedienung zu realisieren. Der Anwender kann dann mehrere Geräte, die irgendwo im Haushalt verteilt sind, über das Handy steuern. Dabei sendet die App über WLAN zuvor gespeicherte IRMP-Codes an das gewünschtee Ethersex Gerät. Dieses strahlt dann die Signale über den IR-Sender aus, um damit unsere Geräte aus der Unterhaltungsindustrie zu schalten. 4e0a5f42c5e2ccc7d543ffe3b5964fab1585ff8f 0 437 1455 1454 2014-10-27T18:46:20Z GooPie4o 265 wikitext text/x-wiki {{i18n|AVR-NET-IO}} Das AVR-NET-IO von [http://www.pollin.de Pollin] ist ein relativ einfach gehaltenes und daher auch sehr günstiges Board. Es ist als Bausatz oder auch als Fertigmodul erhältlich. Der gelieferte ATmega32 kann einfach durch einen leistungsfähigeren ATmega644 oder ATmega1284p (Hinweise zu 128K beachten!) ausgetauscht werden. ===Features=== * Atmel ATmega32 * Microchip ENC28J60 LAN * RS232-Schnittstelle * ISP-Schnittstelle ===Errata=== [[File:Pollin_netio_03.jpg|150px|thumb|right|AVR-NET-IO Modifikationen]] Leider hat der Entwickler des Boards sich nicht an die Vorgaben von Microchip gehalten, und sich die Abblockkondensatoren an den Versorgungsspannungsanschlüssen des ENC28J60 gespart. Dadurch kann es dazu kommen, insbesondere bei hoher Netzlast, dass sich der Ethernet Controller aufhängt. Es ist daher empfehlenswert, Kondensatoren am ENC28J60 und am 3,3V Spannungsregler nachzurüsten. (Siehe Bild rechts: Platinenunterseite) Es lohnt sich auch einmal bei [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin# www.mikrocontroller.net] vorbeizuschauen. Dort gibt es sehr viele Anwender von diesem Board und viel Diskussion über Fehler und Erweiterungen. Besonders bei den Bausätzen lohnt es sich die korrekte Lieferung der Bauteile zu überprüfen. ===Beispielfotos=== <gallery> File:Pollin_netio_01.jpg|Beschreibung File:Pollin_netio_02.jpg|Beschreibung File:Pollin_netio_04.jpg|Beschreibung File:Pollin_netio_05.jpg|Beschreibung File:Pollin_netio_06.jpg|kompatibler Nachbau der K8IO-Relaiskarte von Pollin File:Pollin_netio_07.jpg|NETIO-Shield mit RFM12-433 und RFM12-868 für Funksteckdosen und ELV FS20 File:Pollin_netio-addon_01.jpg|Beschreibung </gallery> [[Category:Hardware]] 2263059767f6c7f6aec7befa631b169d17f84ee4 1456 1455 2014-10-27T18:46:51Z GooPie4o 265 wikitext text/x-wiki {{i18n|AVR-NET-IO}} Das AVR-NET-IO von [http://www.pollin.de Pollin] ist ein relativ einfach gehaltenes und daher auch sehr günstiges Board. Es ist als Bausatz oder auch als Fertigmodul erhältlich. Der gelieferte ATmega32 kann einfach durch einen leistungsfähigeren ATmega644 oder ATmega1284p (Hinweise zu 128K beachten!) ausgetauscht werden. ===Features=== * Atmel ATmega32 * Microchip ENC28J60 LAN * RS232-Schnittstelle * ISP-Schnittstelle ===Errata=== [[File:Pollin_netio_03.jpg|150px|thumb|right|AVR-NET-IO Modifikationen]] Leider hat der Entwickler des Boards sich nicht an die Vorgaben von Microchip gehalten, und sich die Abblockkondensatoren an den Versorgungsspannungsanschlüssen des ENC28J60 gespart. Dadurch kann es dazu kommen, insbesondere bei hoher Netzlast, dass sich der Ethernet Controller aufhängt. Es ist daher empfehlenswert, Kondensatoren am ENC28J60 und am 3,3V Spannungsregler nachzurüsten. (Siehe Bild rechts: Platinenunterseite) Es lohnt sich auch einmal bei [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin# www.mikrocontroller.net] vorbeizuschauen. Dort gibt es sehr viele Anwender von diesem Board und viel Diskussion über Fehler und Erweiterungen. Besonders bei den Bausätzen lohnt es sich die korrekte Lieferung der Bauteile zu überprüfen. ===Beispielfotos=== <gallery> File:Pollin_netio_01.jpg|Beschreibung File:Pollin_netio_02.jpg|Beschreibung File:Pollin_netio_04.jpg|Beschreibung File:Pollin_netio_05.jpg|NETIO-Shield mit SD-Kartenadapter File:Pollin_netio_06.jpg|kompatibler Nachbau der K8IO-Relaiskarte von Pollin File:Pollin_netio_07.jpg|NETIO-Shield mit RFM12-433 und RFM12-868 für Funksteckdosen und ELV FS20 File:Pollin_netio-addon_01.jpg|Beschreibung </gallery> [[Category:Hardware]] 6506b3da35eaa54a99676832181d69f083e24b7f 1457 1456 2014-10-27T18:48:20Z GooPie4o 265 wikitext text/x-wiki {{i18n|AVR-NET-IO}} Das AVR-NET-IO von [http://www.pollin.de Pollin] ist ein relativ einfach gehaltenes und daher auch sehr günstiges Board. Es ist als Bausatz oder auch als Fertigmodul erhältlich. Der gelieferte ATmega32 kann einfach durch einen leistungsfähigeren ATmega644 oder ATmega1284p (Hinweise zu 128K beachten!) ausgetauscht werden. ===Features=== * Atmel ATmega32 * Microchip ENC28J60 LAN * RS232-Schnittstelle * ISP-Schnittstelle ===Errata=== [[File:Pollin_netio_03.jpg|150px|thumb|right|AVR-NET-IO Modifikationen]] Leider hat der Entwickler des Boards sich nicht an die Vorgaben von Microchip gehalten, und sich die Abblockkondensatoren an den Versorgungsspannungsanschlüssen des ENC28J60 gespart. Dadurch kann es dazu kommen, insbesondere bei hoher Netzlast, dass sich der Ethernet Controller aufhängt. Es ist daher empfehlenswert, Kondensatoren am ENC28J60 und am 3,3V Spannungsregler nachzurüsten. (Siehe Bild rechts: Platinenunterseite) Es lohnt sich auch einmal bei [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin# www.mikrocontroller.net] vorbeizuschauen. Dort gibt es sehr viele Anwender von diesem Board und viel Diskussion über Fehler und Erweiterungen. Besonders bei den Bausätzen lohnt es sich die korrekte Lieferung der Bauteile zu überprüfen. ===Beispielfotos=== <gallery> File:Pollin_netio_01.jpg|Beschreibung File:Pollin_netio_02.jpg|Beschreibung File:Pollin_netio_04.jpg|NET-IO mit Shield und Relaiskarte File:Pollin_netio_05.jpg|NET-IO-Shield mit SD-Kartenadapter File:Pollin_netio_06.jpg|kompatibler Nachbau der K8IO-Relaiskarte von Pollin File:Pollin_netio_07.jpg|NET-IO-Shield mit RFM12-433 und RFM12-868 für Funksteckdosen und ELV FS20 File:Pollin_netio-addon_01.jpg|Beschreibung </gallery> [[Category:Hardware]] c91aa1efe6b5c6a3bdaf2f191443e9a82a82324e 1458 1457 2014-10-27T18:56:16Z GooPie4o 265 wikitext text/x-wiki {{i18n|AVR-NET-IO}} Das AVR-NET-IO von [http://www.pollin.de Pollin] ist ein relativ einfach gehaltenes und daher auch sehr günstiges Board. Es ist als Bausatz oder auch als Fertigmodul erhältlich. Der gelieferte ATmega32 kann einfach durch einen leistungsfähigeren ATmega644 oder ATmega1284p (Hinweise zu 128K beachten!) ausgetauscht werden. ===Features=== * Atmel ATmega32 * Microchip ENC28J60 LAN * RS232-Schnittstelle * ISP-Schnittstelle ===Errata=== [[File:Pollin_netio_03.jpg|150px|thumb|right|AVR-NET-IO Modifikationen]] Leider hat der Entwickler des Boards sich nicht an die Vorgaben von Microchip gehalten, und sich die Abblockkondensatoren an den Versorgungsspannungsanschlüssen des ENC28J60 gespart. Dadurch kann es dazu kommen, insbesondere bei hoher Netzlast, dass sich der Ethernet Controller aufhängt. Es ist daher empfehlenswert, Kondensatoren am ENC28J60 und am 3,3V Spannungsregler nachzurüsten. (Siehe Bild rechts: Platinenunterseite) Es lohnt sich auch einmal bei [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin# www.mikrocontroller.net] vorbeizuschauen. Dort gibt es sehr viele Anwender von diesem Board und viel Diskussion über Fehler und Erweiterungen. Besonders bei den Bausätzen lohnt es sich die korrekte Lieferung der Bauteile zu überprüfen. ===Beispielfotos=== <gallery> File:Pollin_netio_01.jpg|Beschreibung File:Pollin_netio_02.jpg|Beschreibung File:Pollin_netio_04.jpg|NET-IO mit Shield und Relaiskarte File:Pollin_netio_05.jpg|NET-IO-Shield mit SD-Kartenadapter File:Pollin_netio_06.jpg|kompatibler Nachbau der K8IO-Relaiskarte von Pollin File:Pollin_netio_07.jpg|NET-IO-Shield mit RFM12-433 und RFM12-868 für Funksteckdosen und [[RFM12_FS20|ELV FS20]] File:Pollin_netio-addon_01.jpg|Beschreibung </gallery> [[Category:Hardware]] cb7985b00e603f9315054561b1655d01dda1d2c2 1459 1458 2014-10-27T18:57:21Z GooPie4o 265 wikitext text/x-wiki {{i18n|AVR-NET-IO}} Das AVR-NET-IO von [http://www.pollin.de Pollin] ist ein relativ einfach gehaltenes und daher auch sehr günstiges Board. Es ist als Bausatz oder auch als Fertigmodul erhältlich. Der gelieferte ATmega32 kann einfach durch einen leistungsfähigeren ATmega644 oder ATmega1284p (Hinweise zu 128K beachten!) ausgetauscht werden. ===Features=== * Atmel ATmega32 * Microchip ENC28J60 LAN * RS232-Schnittstelle * ISP-Schnittstelle ===Errata=== [[File:Pollin_netio_03.jpg|150px|thumb|right|AVR-NET-IO Modifikationen]] Leider hat der Entwickler des Boards sich nicht an die Vorgaben von Microchip gehalten, und sich die Abblockkondensatoren an den Versorgungsspannungsanschlüssen des ENC28J60 gespart. Dadurch kann es dazu kommen, insbesondere bei hoher Netzlast, dass sich der Ethernet Controller aufhängt. Es ist daher empfehlenswert, Kondensatoren am ENC28J60 und am 3,3V Spannungsregler nachzurüsten. (Siehe Bild rechts: Platinenunterseite) Es lohnt sich auch einmal bei [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin# www.mikrocontroller.net] vorbeizuschauen. Dort gibt es sehr viele Anwender von diesem Board und viel Diskussion über Fehler und Erweiterungen. Besonders bei den Bausätzen lohnt es sich die korrekte Lieferung der Bauteile zu überprüfen. ===Beispielfotos=== <gallery> File:Pollin_netio_01.jpg|Beschreibung File:Pollin_netio_02.jpg|Beschreibung File:Pollin_netio_04.jpg|NET-IO mit Shield und Relaiskarte File:Pollin_netio_05.jpg|NET-IO-Shield mit SD-Kartenadapter File:Pollin_netio_06.jpg|kompatibler Nachbau der K8IO-Relaiskarte von Pollin File:Pollin_netio_07.jpg|NET-IO-Shield mit RFM12-433 und RFM12-868 für [[RFM12_ASK_(Deutsch)|Funksteckdosen]] und [[RFM12_FS20_(Deutsch)|ELV FS20]] File:Pollin_netio-addon_01.jpg|Beschreibung </gallery> [[Category:Hardware]] 8d9a6f89c9fc657fc8183b4706a12ed97d1a616d 1460 1459 2014-10-27T18:57:48Z GooPie4o 265 wikitext text/x-wiki {{i18n|AVR-NET-IO}} Das AVR-NET-IO von [http://www.pollin.de Pollin] ist ein relativ einfach gehaltenes und daher auch sehr günstiges Board. Es ist als Bausatz oder auch als Fertigmodul erhältlich. Der gelieferte ATmega32 kann einfach durch einen leistungsfähigeren ATmega644 oder ATmega1284p (Hinweise zu 128K beachten!) ausgetauscht werden. ===Features=== * Atmel ATmega32 * Microchip ENC28J60 LAN * RS232-Schnittstelle * ISP-Schnittstelle ===Errata=== [[File:Pollin_netio_03.jpg|150px|thumb|right|AVR-NET-IO Modifikationen]] Leider hat der Entwickler des Boards sich nicht an die Vorgaben von Microchip gehalten, und sich die Abblockkondensatoren an den Versorgungsspannungsanschlüssen des ENC28J60 gespart. Dadurch kann es dazu kommen, insbesondere bei hoher Netzlast, dass sich der Ethernet Controller aufhängt. Es ist daher empfehlenswert, Kondensatoren am ENC28J60 und am 3,3V Spannungsregler nachzurüsten. (Siehe Bild rechts: Platinenunterseite) Es lohnt sich auch einmal bei [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin# www.mikrocontroller.net] vorbeizuschauen. Dort gibt es sehr viele Anwender von diesem Board und viel Diskussion über Fehler und Erweiterungen. Besonders bei den Bausätzen lohnt es sich die korrekte Lieferung der Bauteile zu überprüfen. ===Beispielfotos=== <gallery> File:Pollin_netio_01.jpg|Beschreibung File:Pollin_netio_02.jpg|Beschreibung File:Pollin_netio_04.jpg|NET-IO mit Shield und Relaiskarte File:Pollin_netio_05.jpg|NET-IO-Shield mit [[SD_CARD_(Deutsch)|SD-Kartenadapter]] File:Pollin_netio_06.jpg|kompatibler Nachbau der K8IO-Relaiskarte von Pollin File:Pollin_netio_07.jpg|NET-IO-Shield mit RFM12-433 und RFM12-868 für [[RFM12_ASK_(Deutsch)|Funksteckdosen]] und [[RFM12_FS20_(Deutsch)|ELV FS20]] File:Pollin_netio-addon_01.jpg|Beschreibung </gallery> [[Category:Hardware]] dd9a4a3d91cf781c425ebd0ad133d09e6a92c3dc 1461 1460 2014-10-27T19:03:58Z Michaelb 718 Beschreibungen ergänzt wikitext text/x-wiki {{i18n|AVR-NET-IO}} Das AVR-NET-IO von [http://www.pollin.de Pollin] ist ein relativ einfach gehaltenes und daher auch sehr günstiges Board. Es ist als Bausatz oder auch als Fertigmodul erhältlich. Der gelieferte ATmega32 kann einfach durch einen leistungsfähigeren ATmega644 oder ATmega1284p (Hinweise zu 128K beachten!) ausgetauscht werden. ===Features=== * Atmel ATmega32 * Microchip ENC28J60 LAN * RS232-Schnittstelle * ISP-Schnittstelle ===Errata=== [[File:Pollin_netio_03.jpg|150px|thumb|right|AVR-NET-IO Modifikationen]] Leider hat der Entwickler des Boards sich nicht an die Vorgaben von Microchip gehalten, und sich die Abblockkondensatoren an den Versorgungsspannungsanschlüssen des ENC28J60 gespart. Dadurch kann es dazu kommen, insbesondere bei hoher Netzlast, dass sich der Ethernet Controller aufhängt. Es ist daher empfehlenswert, Kondensatoren am ENC28J60 und am 3,3V Spannungsregler nachzurüsten. (Siehe Bild rechts: Platinenunterseite) Es lohnt sich auch einmal bei [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin# www.mikrocontroller.net] vorbeizuschauen. Dort gibt es sehr viele Anwender von diesem Board und viel Diskussion über Fehler und Erweiterungen. Besonders bei den Bausätzen lohnt es sich die korrekte Lieferung der Bauteile zu überprüfen. ===Beispielfotos=== <gallery> File:Pollin_netio_01.jpg|NET-IO mit Add-On und LCD als "Sandwich" File:Pollin_netio_02.jpg|Einzelkomponenten des Sandwich File:Pollin_netio-addon_01.jpg|Add-On File:Pollin_netio_04.jpg|NET-IO mit Shield und Relaiskarte File:Pollin_netio_05.jpg|NET-IO-Shield mit [[SD_CARD_(Deutsch)|SD-Kartenadapter]] File:Pollin_netio_06.jpg|kompatibler Nachbau der K8IO-Relaiskarte von Pollin File:Pollin_netio_07.jpg|NET-IO-Shield mit RFM12-433 und RFM12-868 für [[RFM12_ASK_(Deutsch)|Funksteckdosen]] und [[RFM12_FS20_(Deutsch)|ELV FS20]] </gallery> [[Category:Hardware]] 538cb38d955e8531b79f1bbea26d1f2997cdf70e 1467 1461 2014-11-15T16:30:01Z GooPie4o 265 wikitext text/x-wiki {{i18n|AVR-NET-IO}} Das AVR-NET-IO von [http://www.pollin.de Pollin] ist ein relativ einfach gehaltenes und daher auch sehr günstiges Board. Es ist als Bausatz oder auch als Fertigmodul erhältlich. Der gelieferte ATmega32 kann einfach durch einen leistungsfähigeren ATmega644 oder ATmega1284p (Hinweise zu 128K beachten!) ausgetauscht werden. ===Features=== * Atmel ATmega32 * Microchip ENC28J60 LAN * RS232-Schnittstelle * ISP-Schnittstelle ===Errata=== [[File:Pollin_netio_03.jpg|150px|thumb|right|AVR-NET-IO Modifikationen]] Leider hat der Entwickler des Boards sich nicht an die Vorgaben von Microchip gehalten, und sich die Abblockkondensatoren an den Versorgungsspannungsanschlüssen des ENC28J60 gespart. Dadurch kann es dazu kommen, insbesondere bei hoher Netzlast, dass sich der Ethernet Controller aufhängt. Es ist daher empfehlenswert, Kondensatoren am ENC28J60 und am 3,3V Spannungsregler nachzurüsten. (Siehe Bild rechts: Platinenunterseite) Es lohnt sich auch einmal bei [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin# www.mikrocontroller.net] vorbeizuschauen. Dort gibt es sehr viele Anwender von diesem Board und viel Diskussion über Fehler und Erweiterungen. Besonders bei den Bausätzen lohnt es sich die korrekte Lieferung der Bauteile zu überprüfen. ===Beispielfotos=== <gallery> File:Pollin_netio_01.jpg|NET-IO mit Add-On und LCD als "Sandwich" File:Pollin_netio_02.jpg|Einzelkomponenten des Sandwich File:Pollin_netio-addon_01.jpg|Add-On File:Pollin_netio_04.jpg|NET-IO mit Shield und Relaiskarte File:Pollin_netio_05.jpg|NET-IO-Shield mit [[SD_CARD_(Deutsch)|SD-Kartenadapter]] File:Pollin_netio_06.jpg|kompatibler Nachbau der K8IO-Relaiskarte von Pollin File:Pollin_netio_07.jpg|NET-IO-Shield mit [[RFM12]]-433 und [[RFM12]]-868 für [[RFM12_ASK_(Deutsch)|Funksteckdosen]] und [[RFM12_FS20_(Deutsch)|ELV FS20]] </gallery> [[Category:Hardware]] 658ce2ea280a5d5d89e70bf2600ecf01235e4362 1468 1467 2014-11-15T16:31:23Z GooPie4o 265 wikitext text/x-wiki {{i18n|AVR-NET-IO}} Das AVR-NET-IO von [http://www.pollin.de Pollin] ist ein relativ einfach gehaltenes und daher auch sehr günstiges Board. Es ist als Bausatz oder auch als Fertigmodul erhältlich. Der gelieferte ATmega32 kann einfach durch einen leistungsfähigeren ATmega644 oder ATmega1284p (Hinweise zu 128K beachten!) ausgetauscht werden. ===Features=== * Atmel ATmega32 * Microchip ENC28J60 LAN * RS232-Schnittstelle * ISP-Schnittstelle ===Errata=== [[File:Pollin_netio_03.jpg|150px|thumb|right|AVR-NET-IO Modifikationen]] Leider hat der Entwickler des Boards sich nicht an die Vorgaben von Microchip gehalten, und sich die Abblockkondensatoren an den Versorgungsspannungsanschlüssen des ENC28J60 gespart. Dadurch kann es dazu kommen, insbesondere bei hoher Netzlast, dass sich der Ethernet Controller aufhängt. Es ist daher empfehlenswert, Kondensatoren am ENC28J60 und am 3,3V Spannungsregler nachzurüsten. (Siehe Bild rechts: Platinenunterseite) Es lohnt sich auch einmal bei [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin# www.mikrocontroller.net] vorbeizuschauen. Dort gibt es sehr viele Anwender von diesem Board und viel Diskussion über Fehler und Erweiterungen. Besonders bei den Bausätzen lohnt es sich die korrekte Lieferung der Bauteile zu überprüfen. ===Beispielfotos=== <gallery> File:Pollin_netio_01.jpg|NET-IO mit Add-On und LCD als "Sandwich" File:Pollin_netio_02.jpg|Einzelkomponenten des Sandwich File:Pollin_netio-addon_01.jpg|Add-On File:Pollin_netio_04.jpg|NET-IO mit Shield und Relaiskarte File:Pollin_netio_05.jpg|NET-IO-Shield mit [[SD_CARD_(Deutsch)|SD-Kartenadapter]] File:Pollin_netio_06.jpg|kompatibler Nachbau der K8IO-Relaiskarte von Pollin File:Pollin_netio_07.jpg|NET-IO-Shield mit [[RFM12_(Deutsch)|RFM12]]-433 und [[RFM12_(Deutsch)|RFM12]]-868 für [[RFM12_ASK_(Deutsch)|Funksteckdosen]] und [[RFM12_FS20_(Deutsch)|ELV FS20]] </gallery> [[Category:Hardware]] 6d38c62d7e9a70d15f9f61ee4e7cbccd1f433079 1469 1468 2014-11-19T11:19:28Z Kpwg 721 wikitext text/x-wiki {{i18n|AVR-NET-IO}} Das AVR-NET-IO von [http://www.pollin.de Pollin] ist ein relativ einfach gehaltenes und daher auch sehr günstiges Board. Es ist als Bausatz oder auch als Fertigmodul erhältlich. Der gelieferte ATmega32 kann einfach durch einen leistungsfähigeren ATmega644 oder ATmega1284p (Hinweise zu 128K beachten!) ausgetauscht werden. Eine weitere und sehr ausführliche Beschreibung der Hardware ist im [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin Microcontroller-Forum] zu finden. ===Features=== * Atmel ATmega32 Mikrocontroller * Microchip ENC28J60 Stand-Alone Ethernet Controller mit SPI Interface * RS232-Schnittstelle * 10polige ISP-Schnittstelle * konfigurierbare I/O-Pins ===Errata=== [[File:Pollin_netio_03.jpg|150px|thumb|right|AVR-NET-IO Modifikationen]] Leider hat der Entwickler des Boards sich nicht an die Vorgaben von Microchip gehalten, und sich die Abblockkondensatoren an den Versorgungsspannungsanschlüssen des ENC28J60 gespart. Dadurch kann es dazu kommen, insbesondere bei hoher Netzlast, dass sich der Ethernet Controller aufhängt. Es ist daher empfehlenswert, Kondensatoren am ENC28J60 und am 3,3V Spannungsregler nachzurüsten. (Siehe Bild rechts: Platinenunterseite) Es lohnt sich auch einmal bei [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin# www.mikrocontroller.net] vorbeizuschauen. Dort gibt es sehr viele Anwender von diesem Board und viel Diskussion über Fehler und Erweiterungen. Besonders bei den Bausätzen lohnt es sich die korrekte Lieferung der Bauteile zu überprüfen. ===Beispielfotos=== <gallery> File:Pollin_netio_01.jpg|NET-IO mit Add-On und LCD als "Sandwich" File:Pollin_netio_02.jpg|Einzelkomponenten des Sandwich File:Pollin_netio-addon_01.jpg|Add-On File:Pollin_netio_04.jpg|NET-IO mit Shield und Relaiskarte File:Pollin_netio_05.jpg|NET-IO-Shield mit [[SD_CARD_(Deutsch)|SD-Kartenadapter]] File:Pollin_netio_06.jpg|kompatibler Nachbau der K8IO-Relaiskarte von Pollin File:Pollin_netio_07.jpg|NET-IO-Shield mit [[RFM12_(Deutsch)|RFM12]]-433 und [[RFM12_(Deutsch)|RFM12]]-868 für [[RFM12_ASK_(Deutsch)|Funksteckdosen]] und [[RFM12_FS20_(Deutsch)|ELV FS20]] </gallery> [[Category:Hardware]] 30dd7ea84ec215ecd0572f6e55a404feda84dbe1 0 457 1462 1422 2014-10-27T19:14:49Z GooPie4o 265 wikitext text/x-wiki {{i18n|Supported Boards}} == Commercial Products == <gallery> Etherrape.jpg | [[Etherrape | Etherrape]] by lochraster.org Jackalope.jpg | [[Jackalope | Jackalope]] by lochraster.org Radig.jpg | [[AVR Webmodul | AVR Webmodul]] by lrich Radig Avr-net-io.jpg | [[AVR-NET-IO | AVR-NET-IO]] by Pollin Funk-avr-eval.jpg | [[Funk-AVR-Evaluationsboard | Funk-AVR-Evaluationsboard]] by Pollin Conrad-probot.jpg | [[Conrad Probot | Conrad Probot]] by Conrad Fimser.jpg | [[Fimser | Fimser]] by OV Lennestadt Jeelinkv2.jpg | [[JeeLink | JeeLink]] by JeeLabs </gallery> == DIY Hardware == <gallery> Fhem_wz_01.jpg | [[Nutzung_in_FHEM | FHEM]] [[FHEM_Wohnzimmer | Roomnode #1]] Fhem_ku_01.jpg | [[Nutzung_in_FHEM | FHEM]] [[FHEM_Kueche | Roomnode #2]] Fhem_ke_01.jpg | [[Nutzung_in_FHEM | FHEM]] [[FHEM_Keller | Roomnode #3]] Bw_final.jpg | bed guard Atmega162-usb.jpg | ATmega162 with USB Usb2zbus-i2c.jpg | USB to [[ZBus | ZBus]] Dongle Pumpensteuerung.jpg | Jochen's pump control Ethmega.jpg | ths' ATmega64+ (SMD) Usbonly_atmega32+i2c_pcf8574_auf_steckbrett.jpg | USB-Ethersex with [[I2C| I2C]] and port extension Chaotischer-aufbau.jpg | Pollins AVR-NET-IO with add ons Ethersex-Avrnet-GPA.jpg | Pollins AVR-NET-IO based outlet control center Resetbox_proto_01.jpg | [[Resetbox | Resetbox]] Habo_bulbdial_clock.jpg | [[Bulbdial Clock | Bulbdial Clock]] Ftdi-lochraster.jpg | Atmega168p with USB connector via FT232R Ehaserl-badge-eh2010.jpg | [[ehaserl | ehaserl]] Badge des easter(h)egg 2010 Zbus_testboard.jpg | [[ZBus | ZBus]][[ZBus_Testboard | Testboard]] </gallery> [[Category:Ethersex]] [[Category:Hardware]] 3dcf50ef5849898a76864ff30f0a13f6970fcd29 1463 1462 2014-10-27T19:15:24Z GooPie4o 265 wikitext text/x-wiki {{i18n|Supported Boards}} == Commercial Products == <gallery> Etherrape.jpg | [[Etherrape | Etherrape]] by lochraster.org Jackalope.jpg | [[Jackalope | Jackalope]] by lochraster.org Radig.jpg | [[AVR Webmodul | AVR Webmodul]] by lrich Radig Avr-net-io.jpg | [[AVR-NET-IO | AVR-NET-IO]] by Pollin Funk-avr-eval.jpg | [[Funk-AVR-Evaluationsboard | Funk-AVR-Evaluationsboard]] by Pollin Conrad-probot.jpg | [[Conrad Probot | Conrad Probot]] by Conrad Fimser.jpg | [[Fimser | Fimser]] by OV Lennestadt Jeelinkv2.jpg | [[JeeLink | JeeLink]] by JeeLabs </gallery> == DIY Hardware == <gallery> Fhem_wz_01.jpg | [[Nutzung_in_FHEM | FHEM]] [[FHEM_Wohnzimmer | Roomnode #1]] Fhem_ku_01.jpg | [[Nutzung_in_FHEM | FHEM]] [[FHEM_Kueche | Roomnode #2]] Fhem_ke_01.jpg | [[Nutzung_in_FHEM | FHEM]] [[FHEM_Keller | Roomnode #3]] Bw_final.jpg | bed guard Atmega162-usb.jpg | ATmega162 with USB Usb2zbus-i2c.jpg | USB to [[ZBus | ZBus]] Dongle Pumpensteuerung.jpg | Jochen's pump control Ethmega.jpg | ths' ATmega64+ (SMD) Usbonly_atmega32+i2c_pcf8574_auf_steckbrett.jpg | USB-Ethersex with [[I2C| I2C]] and port extension Chaotischer-aufbau.jpg | Pollins AVR-NET-IO with add ons Ethersex-Avrnet-GPA.jpg | Pollins AVR-NET-IO based outlet control center Resetbox_proto_01.jpg | [[Resetbox | Resetbox]] Habo_bulbdial_clock.jpg | [[Bulbdial Clock | Bulbdial Clock]] Ftdi-lochraster.jpg | Atmega168p with USB connector via FT232R Ehaserl-badge-eh2010.jpg | [[ehaserl|ehaserl]] Badge des easter(h)egg 2010 Zbus_testboard.jpg | [[ZBus|ZBus]][[ZBus_Testboard|Testboard]] </gallery> [[Category:Ethersex]] [[Category:Hardware]] 0f840ac1aae3fc1b9caf0c1dee5a657ff722b7c7 1465 1463 2014-10-28T17:33:53Z GooPie4o 265 /* DIY Hardware */ wikitext text/x-wiki {{i18n|Supported Boards}} == Commercial Products == <gallery> Etherrape.jpg | [[Etherrape | Etherrape]] by lochraster.org Jackalope.jpg | [[Jackalope | Jackalope]] by lochraster.org Radig.jpg | [[AVR Webmodul | AVR Webmodul]] by lrich Radig Avr-net-io.jpg | [[AVR-NET-IO | AVR-NET-IO]] by Pollin Funk-avr-eval.jpg | [[Funk-AVR-Evaluationsboard | Funk-AVR-Evaluationsboard]] by Pollin Conrad-probot.jpg | [[Conrad Probot | Conrad Probot]] by Conrad Fimser.jpg | [[Fimser | Fimser]] by OV Lennestadt Jeelinkv2.jpg | [[JeeLink | JeeLink]] by JeeLabs </gallery> == DIY Hardware == <gallery> Fhem_wz_01.jpg | [[Nutzung_in_FHEM | FHEM]] [[FHEM_Wohnzimmer | Roomnode #1]] Fhem_ku_01.jpg | [[Nutzung_in_FHEM | FHEM]] [[FHEM_Kueche | Roomnode #2]] Fhem_ke_01.jpg | [[Nutzung_in_FHEM | FHEM]] [[FHEM_Keller | Roomnode #3]] Bw_final.jpg | bed guard Atmega162-usb.jpg | ATmega162 with USB Usb2zbus-i2c.jpg | USB to [[ZBus | ZBus]] Dongle Pumpensteuerung.jpg | Jochen's pump control Ethmega.jpg | ths' ATmega64+ (SMD) Usbonly_atmega32+i2c_pcf8574_auf_steckbrett.jpg | USB-Ethersex with [[I2C| I2C]] and port extension Chaotischer-aufbau.jpg | Pollin AVR-NET-IO with add ons Ethersex-Avrnet-GPA.jpg | Pollin AVR-NET-IO based outlet control center Resetbox_proto_01.jpg | [[Resetbox | Resetbox]] Habo_bulbdial_clock.jpg | [[Bulbdial Clock | Bulbdial Clock]] Ftdi-lochraster.jpg | Atmega168p with USB connector via FT232R Ehaserl-badge-eh2010.jpg | [[ehaserl|ehaserl]] Badge des easter(h)egg 2010 Zbus_testboard.jpg | [[ZBus|ZBus]][[ZBus_Testboard|Testboard]] </gallery> [[Category:Ethersex]] [[Category:Hardware]] 4b00eba96d7c3b345491d7af363d0963cfbdf5a1 0 412 1464 1446 2014-10-27T19:16:09Z GooPie4o 265 wikitext text/x-wiki {{i18n|Supported Boards}} == Kommerzielle Produkte == <gallery> Etherrape.jpg | [[Etherrape_(Deutsch) | Etherrape]] von lochraster.org Jackalope.jpg | [[Jackalope_(Deutsch) | Jackalope]] von lochraster.org Radig.jpg | [[AVR Webmodul_(Deutsch) | AVR Webmodul]] von Ulrich Radig Avr-net-io.jpg | [[AVR-NET-IO_(Deutsch) | AVR-NET-IO]] von Pollin Funk-avr-eval.jpg | [[Funk-AVR-Evaluationsboard_(Deutsch) | Funk-AVR-Evaluationsboard]] von Pollin Conrad-probot.jpg | [[Conrad Probot_(Deutsch) | Conrad Probot]] von Conrad Fimser.jpg | [[Fimser_(Deutsch) | Fimser]] vom OV Lennestadt Jeelinkv2.jpg | [[JeeLink_(Deutsch) | JeeLink]] von JeeLabs </gallery> == Eigenbau Hardware == <gallery> Fhem_wz_01.jpg | [[Nutzung_in_FHEM_(Deutsch) | FHEM]] [[FHEM_Wohnzimmer_(Deutsch) | Roomnode #1]] Fhem_ku_01.jpg | [[Nutzung_in_FHEM_(Deutsch) | FHEM]] [[FHEM_Kueche_(Deutsch) | Roomnode #2]] Fhem_ke_01.jpg | [[Nutzung_in_FHEM_(Deutsch) | FHEM]] [[FHEM_Keller_(Deutsch) | Roomnode #3]] Bw_final.jpg | Bettwächter Atmega162-usb.jpg | ATmega162 mit USB Usb2zbus-i2c.jpg | USB to [[ZBus_(Deutsch) | ZBus]] Dongle Pumpensteuerung.jpg | Jochens Pumpensteuerung Ethmega.jpg | ths' ATmega64+ (SMD) Usbonly_atmega32+i2c_pcf8574_auf_steckbrett.jpg | USB-Ethersex mit [[I2C_(Deutsch) | I2C]] und Porterweiterung Chaotischer-aufbau.jpg | Pollins AVR-NET-IO und Erweiterungen Ethersex-Avrnet-GPA.jpg | Pollins AVR-NET-IO Steckdosenschaltzentrale Resetbox_proto_01.jpg | [[Resetbox_(Deutsch) | Resetbox]] Habo_bulbdial_clock.jpg | [[Bulbdial Clock_(Deutsch) | Bulbdial Clock]] Ftdi-lochraster.jpg | Atmega168p mit USB-Anschluss über FT232R Ehaserl-badge-eh2010.jpg | [[ehaserl_(Deutsch)|ehaserl]] Badge des easter(h)egg 2010 Zbus_testboard.jpg | [[ZBus_(Deutsch)|ZBus]][[ZBus_Testboard_(Deutsch)|Testboard]] </gallery> [[Category:Ethersex]] [[Category:Hardware]] cb7f411e19090006db1dcae793136c78f2c5fc3c 0 441 1466 1387 2014-10-28T17:35:30Z GooPie4o 265 wikitext text/x-wiki {{i18n|JeeLink}} 901ee70acf94e3ea07139bd0a757e9e5f271c209 0 435 1470 1425 2014-11-19T12:02:19Z Kpwg 721 wikitext text/x-wiki {{i18n|Jackalope}} [[File:Jackalope.jpg|thumb|right]] Das Jackalope von [http://wiki.lochraster.org/wiki/Jackalope lochraster.org] ist eine Ein/Ausgabe Einheit für digitale und analoge Signale. Es kann als passive I/O Einheit direkt am [[Etherrape_(Deutsch) | Etherrape]] betrieben werden oder mit eigenem Microcontroller (ATMEGA168) standalone. Beim Standalonebetrieb verfügt es über verschiedene Vernetzungsmöglichkeiten. RS-232, RS-485, 433 MHz Funk (RFM12), SPI. ===Features=== * 6x Digital Ausgang über Relaiskontakt (Schließer 60V/1A) * 8x Digital Eingang über Optokoppler 3-30 Volt * 2x Analog Eingang mit Spannungsvorteiler (Wandler 1 und 2) * 2x Analog Eingang über Operationsverstärker (Verstärkung 1-40 über Poti einstellbar) (Wandler 3 und 4) * 1x Analog Eingang über Messverstärker AD620 * 2x Analog Ausgang 0-5 Volt mit 12 Bit Auflösung Jackalope-Platinen sind im Web-Shop unter http://ws.lochraster.org/ws/index.htm erhältlich. [[Category:Hardware]] ca08aa931f9a1d4410b36974b6bf7710c73a1dd9 6 472 1471 2014-11-19T13:42:15Z Kpwg 721 taken from old wiki wikitext text/x-wiki taken from old wiki 5d2d9155505ad5afc04e47e9a12b9f122e62774c 6 473 1472 2014-11-19T13:42:45Z Kpwg 721 taken from old wiki wikitext text/x-wiki taken from old wiki 5d2d9155505ad5afc04e47e9a12b9f122e62774c 6 474 1473 2014-11-19T13:43:11Z Kpwg 721 taken from old wiki wikitext text/x-wiki taken from old wiki 5d2d9155505ad5afc04e47e9a12b9f122e62774c 6 475 1474 2014-11-19T13:43:43Z Kpwg 721 taken from old wiki wikitext text/x-wiki taken from old wiki 5d2d9155505ad5afc04e47e9a12b9f122e62774c 0 436 1475 1382 2014-11-19T13:51:49Z Kpwg 721 wikitext text/x-wiki {{i18n|AVR Webmodul}} [[File:Radig.jpg|thumb|right]] Das [http://www.ulrichradig.de/home/index.php/avr/avr-webmodule AVR Webmodul] von [http://www.ulrichradig.de Ulrich Radig] hat einen SD Slot, der von ethersex angesprochen werden kann (mit FAT als Dateisystem). ===Features=== * Atmel ATmega644 Mikrocontroller * Microchip ENC28J60 Stand-Alone Ethernet Controller mit SPI Interface * SD-Kartenleser * RS232-Schnittstelle * 10polige ISP-Schnittstelle * Entworfen zur Montage im Hutschienengehäuse === Weitere Bilder === <gallery> File:Radig-webmodul+rg-matrix.jpg | Webmodul mit Rot-Grün Matrix Anzeige File:Habos_ethersex_radig_modul_mit_rgdisplay+joystick.jpg | Webmodul mit Rot-Grün Matrix Anzeige und Joystick File:Habos_ethersex_radig_modul_mit_cam+sound.jpg | Webmodul mit PWM Sound und Kamera File:Radig_webmodul_in_hutschienengehaeuse.jpg | Webmodul im Hutschienengehäuse </gallery> [[Category:Hardware]] 247a2d8995a610538f21728372731ea3c3d64517 1476 1475 2014-11-19T13:53:52Z Kpwg 721 /* Features */ wikitext text/x-wiki {{i18n|AVR Webmodul}} [[File:Radig.jpg|thumb|right]] Das [http://www.ulrichradig.de/home/index.php/avr/avr-webmodule AVR Webmodul] von [http://www.ulrichradig.de Ulrich Radig] hat einen SD Slot, der von ethersex angesprochen werden kann (mit FAT als Dateisystem). ===Features=== * Atmel ATmega644 Mikrocontroller * Microchip ENC28J60 Stand-Alone Ethernet Controller mit SPI Interface * [[SD_CARD_(Deutsch) | SD-Kartenleser]] * RS232-Schnittstelle * 10polige ISP-Schnittstelle * Entworfen zur Montage im Hutschienengehäuse === Weitere Bilder === <gallery> File:Radig-webmodul+rg-matrix.jpg | Webmodul mit Rot-Grün Matrix Anzeige File:Habos_ethersex_radig_modul_mit_rgdisplay+joystick.jpg | Webmodul mit Rot-Grün Matrix Anzeige und Joystick File:Habos_ethersex_radig_modul_mit_cam+sound.jpg | Webmodul mit PWM Sound und Kamera File:Radig_webmodul_in_hutschienengehaeuse.jpg | Webmodul im Hutschienengehäuse </gallery> [[Category:Hardware]] 86239805b13ecb71a841d1abc3902e38da38969f 0 459 1477 1431 2014-11-19T14:01:25Z Kpwg 721 /* FHEM Roomnode Keller */ Bildbeschreibung ergänzt wikitext text/x-wiki {{i18n|FHEM Keller}} == [[Nutzung_in_FHEM_(Deutsch)|FHEM]] Roomnode Keller == In einem durch nachlässiges Lüften sehr feuchten Keller sollen Temperatur/Feuchte an mehreren Punkten sowie außen am Gebäude gemessen werden. Daraus errechnet FHEM Lüftungsempfehlungen. Diese wird zusätzlich auf dem Display durch '''(auf)''' und '''(zu)''' angzeigt. Da es keine Möglichkeit gibt, per LAN in den Raum zu gelangen, musste eine Wireless-Bridge her. Damit steht zugleich LAN an der Werkbank bereit. Ein Anschluss für [[ZBus_(Deutsch) | ZBus]] lässt Platz für weitere Spielereien. '''Ziele''' * genaue Messung Temperatur/Feuchte in den Räumen und an der Außenwand * Anzeige diverser Klimadaten und Uhrzeit * pespektivisch weitere Möglichkeiten zur Steuerung/Regelung * Feuchtraum-Gehäuse '''Ausstattung''' * WLAN-Router als Wireless-Bridge * mehrere [[DHT|DHT22]] mit bis zu 6m Kabel (Cat.5-Reste) * [[LCD_(Deutsch) | LCD]] 20x4 HD44780 zur Anzeige von Datum, Uhrzeit, Klimadaten, Lüftungsempfehlung * [[ZBus_(Deutsch) | ZBus]] Interface mit MAX485 für [[ZBus_Testboard_(Deutsch) | ZBus-Tests]] oder weitere Zbus-Roomnodes * Industrienetzteil mit Reserven für dem ZBus und Versorgung des Routers * ATMega32 '''Bilder''' <gallery> Fhem_ke_01.jpg|Aussenansicht (Klarsichtdeckel abgenommen) Fhem_ke_02.jpg|Display in Aktion (Hi=hinten; Vo=vorn; Ga=Garten; TP=Taupunkt) Fhem_ke_03.jpg|DHT22 als Raumsensor, auf einem alten Bopla-Gehäuse Fhem_ke_04.jpg|Prozessorboard von oben; LAN-modul aufgesetzt Fhem_ke_05.jpg|Prozessorboard von unten Fhem_ke_06.jpg|Stromversorgungs-/ZBus-Board von oben Fhem_ke_07.jpg|Stromversorgungs-/ZBus-Board von unten </gallery> [[Category:Hardware]] 9fb5bd38a371fbf306d7faabeb16d52943452825 1481 1477 2015-01-21T16:36:54Z Kpwg 721 wikitext text/x-wiki {{i18n|FHEM Keller}} In einem durch nachlässiges Lüften sehr feuchten Keller sollen Temperatur/Feuchte an mehreren Punkten sowie außen am Gebäude gemessen werden. Daraus errechnet [[Nutzung_in_FHEM_(Deutsch)|FHEM]] Lüftungsempfehlungen. Diese wird zusätzlich auf dem Display durch '''(auf)''' und '''(zu)''' angzeigt. Da es keine Möglichkeit gibt, per LAN in den Raum zu gelangen, musste eine Wireless-Bridge her. Damit steht zugleich LAN an der Werkbank bereit. Ein Anschluss für [[ZBus_(Deutsch) | ZBus]] lässt Platz für weitere Spielereien. '''Ziele''' * genaue Messung Temperatur/Feuchte in den Räumen und an der Außenwand * Anzeige diverser Klimadaten und Uhrzeit * pespektivisch weitere Möglichkeiten zur Steuerung/Regelung * Feuchtraum-Gehäuse '''Ausstattung''' * WLAN-Router als Wireless-Bridge * mehrere [[DHT|DHT22]] mit bis zu 6m Kabel (Cat.5-Reste) * [[LCD_(Deutsch) | LCD]] 20x4 HD44780 zur Anzeige von Datum, Uhrzeit, Klimadaten, Lüftungsempfehlung * [[ZBus_(Deutsch) | ZBus]] Interface mit MAX485 für [[ZBus_Testboard_(Deutsch) | ZBus-Tests]] oder weitere Zbus-Roomnodes * Industrienetzteil mit Reserven für dem ZBus und Versorgung des Routers * ATMega32 '''Bilder''' <gallery> Fhem_ke_01.jpg|Aussenansicht (Klarsichtdeckel abgenommen) Fhem_ke_02.jpg|Display in Aktion (Hi=hinten; Vo=vorn; Ga=Garten; TP=Taupunkt) Fhem_ke_03.jpg|DHT22 als Raumsensor, auf einem alten Bopla-Gehäuse Fhem_ke_04.jpg|Prozessorboard von oben; LAN-modul aufgesetzt Fhem_ke_05.jpg|Prozessorboard von unten Fhem_ke_06.jpg|Stromversorgungs-/ZBus-Board von oben Fhem_ke_07.jpg|Stromversorgungs-/ZBus-Board von unten </gallery> [[Category:Hardware]] bded215ac1ae0a223b4dd482a5173ea236f0c01f 0 390 1478 1406 2014-11-24T18:36:17Z Kpwg 721 Perl Fehler "useless use in a void context" behoben wikitext text/x-wiki {{i18n|Nutzung in FHEM}} [http://www.fhemwiki.de/wiki/Hauptseite FHEM] ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um diverse per Funk und Kabel angebundene Komponenten aus dem Bereich der Hausautomation zu steuern. Er ist lizensiert unter der GPL v2. Das [http://www.pollin.de/shop/suchergebnis.html?S_TEXT=810+058 AVR-Net-IO] von [http://www.pollin.de Pollin] mit [[Ethersex]] dient als [http://www.fhemwiki.de/wiki/AVR-NET-IO preisgünstiger Einstieg in die Hausautomatisierung]. Verwendbar ist aber auch jede andere [[Supported_Boards_(Deutsch) | Hardware]], die von Ethersex unterstützt wird (Arduino, eigene Entwicklungen, etc.). Über [[ECMD]] lassen sich dabei theoretisch alle in [[Ethersex]] vorhandenen [[ECMD_Protocols_%28Deutsch%29 | Möglichkeiten]] nutzen, sofern in FHEM entsprechende [http://fhem.de/commandref.html#ECMD ECMD-Devices] definiert und eingebunden werden, die passende Klassendefinition exisitert und die Aktion ausgelöst wird. == Grundlagen == Ausgehend von einem fertigen und per Telnet erreichbaren Ethersex muss in FHEM zuerst das entsprechende Device definiert werden. <pre> define NETIO_WZ ECMD telnet 192.168.3.81:2701 </pre> Eine serielle Anbindung kann mit ''define <name> ECMD serial <SerialDevice>[<@BaudRate>]'' alternativ erfolgen. Anschließend werden die erstellten .classdef-Konfigurationsdateien der einzelnen Funktionen dem System bekannt gemacht. In diesen .classdef-Dateien (Name und Endung sind frei wählbar!) wird die Schnittstelle zwischen FHEM und ECMD/Ethersex definiert. Dabei können mit perl übergebene Parameter und empfangene Daten bearbeitet sowie die in FHEM gebräuchlichen Readings erstellt werden. <pre> attr NETIO_WZ classdefs RFM12_2272=/opt/fhem/FHEM/rfm12_2272.classdef:RFM12_IT=/opt/fhem/FHEM/rfm12_it.classdef:LCD=/opt/fhem/FHEM/lcd.classdef:DHT22=/opt/fhem/FHEM/dht22.classdef:1WIRE=/opt/fhem/FHEM/1wire.classdef </pre> Die Definitionen für IC2272, Intertechno, HD44780-LCD, DHT22 und 1wire sind nun eingebunden. In den folgenden Abschnitten wird auf die einzelnen Devices näher eingegangen. Generell sind Pfade und IP-Adressen sowie übergebene Parameter noch entsprechend der eigenen Konfiguration anzupassen. == [[Onewire_(Deutsch) | 1-Wire Temperatursensoren]] == [[File:DS18B20.jpg|150px|thumb|right|DS18B20-Sensoren]] Die 1wire-Temperatursensoren DS18B20 oder DS18S20 werden im [[Onewire_(Deutsch)#Polling_Modus | Polling Modus]] abgefragt. Das macht die zyklische Abfrage aus FHEM heraus wesentlich einfacher. Eine Polling-Zeit von mindestens 30 Sekunden ist absolut ausreichend.Im Vorfeld sollte man sich die [[Onewire_(Deutsch)#Benennung_von_Sensoren | ROM-Codes der Sensoren]] notieren, da diese nachher benötigt werden. 1w-temp.classdef erstellen: <source lang="perl"> # Uebergabeparameter Onewire Rom-Code params devID # Umsetzung in ECMD Befehle 1w get = Temperatur auslesen get 1W cmd {"1w get %devID\n"} get 1W expect "\d+.\d\n" get 1W postproc {\ s/\n//g;\ my $hash = $defs{%NAME};\ my $temperature = $_;\ my $state = "T: $temperature";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die classdef wird eingebunden: <pre> define NETIO_KU ECMD telnet 192.168.3.82:2701 attr NETIO_KU classdefs 1W-TEMP=/opt/fhem/FHEM/1w-temp.classdef </pre> Die Sensoren werden anhand des ROM-Code definiert: <pre> define HZ_WW ECMDDevice 1W-TEMP 284c8820050003d4 attr HZ_WW IODev NETIO_KU define HZ_VL ECMDDevice 1W-TEMP 2890a520050003d7 attr HZ_VL IODev NETIO_KU </pre> Eine zyklische Messung pro Minute lässt sich in dieser Form auslösen: <pre> define Messung_1w at +*00:01 get HZ_WW 1W;; get HZ_VL 1W attr Messung_1w verbose 0 </pre> == [[DHT|DHT22 Temperatur-/Feuchtesensoren]] == [[File:DHT22.jpg|150px|thumb|right|DHT22-Sensoren]] [[Ethersex]] unterstützt die preiswerten Temperatur-/Feuchtesensoren [[DHT|DHT11 und DHT22]], wobei letztere [[DHT#DHT11_vs_DHT22|um einiges genauer sind]]. Die Sensoren benötigen 5V Betriebsspannung und kommunizieren über je einen Pin mit dem Prozessor. Der Preis pro Stück liegt derzeit bei etwa 3.50 Euro (ebay/China). Wer die Trägheit und Ungenauigkeit der S300TH oder TX29DTH kennt, wünscht sich vermutlich Besseres; vor allem bei Berechnung von [http://de.wikipedia.org/wiki/Taupunkt Taupunkt] und [http://de.wikipedia.org/wiki/Luftfeuchtigkeit#Absolute_Luftfeuchtigkeit absoluter Feuchte], welche von der Genauigkeit der gemessenen Eingangsgrößen sehr profitieren. Berechnungen von Hand kann man beim [http://www.wetterochs.de/wetter/feuchte.html Wetterochs] durchführen. Die automatische Berechnung der absoluten Feuchte in FHEM wird im [http://forum.fhem.de/index.php/topic,21458.0.html Forum] erklärt. '''Einbindung in FHEM''' dht22m.classdef erstellen: <source lang="perl"> # Uebergabeparameter DHT22 ID 0...n params devID # Umsetzung in ECMD Befehle fuer DHT22 get DHT cmd {"dht temp %devID\n\000dht humid %devID\n"} get DHT expect "\d+.\d\n" get DHT postproc {\ s/(.*)\n(.*)\n/T: $1 H: $2/;\ my $hash = $defs{%NAME};\ my $temperature = $1;\ my $humidity = $2;\ my $state = $_;\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "humidity", $humidity, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs DHT22M=/opt/fhem/FHEM/dht22m.classdef </pre> Die Sensoren werden definiert: <pre> define Test0 ECMDDevice DHT22M 0 attr Test0 IODev NETIO_TEST define Test1 ECMDDevice DHT22M 1 attr Test1 IODev NETIO_TEST define Test2 ECMDDevice DHT22M 2 attr Test2 IODev NETIO_TEST define Test3 ECMDDevice DHT22M 3 attr Test3 IODev NETIO_TEST </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_DHT at +*00:04 get Test0 DHT;; get Test1 DHT;; get Test2 DHT;; get Test3 DHT attr Messung_DHT verbose 0 </pre> Fünfzehn Messwerte pro Stunde genügen den allermeisten Anforderungen. == [[BMP085 | BMP085/BMP180 Luftdrucksensor]] == [[File:BMP180.jpg|150px|thumb|right|BMP180 (unten links)]] Ethersex unterstützt den BMP085 (bzw. den BMP180; der Code ist identisch) über das [[I2C_(Deutsch) | I2C]]-Interface. Da der Sensor für 3.3V Betriebsspannung ausgelegt ist, muss entweder der I2C-Pegel angepasst oder der ATMega auf 3.3V adaptiert werden. Weiterhin sollte die Höhe über Null bekannt sein. Beispiel: Eine Abfrage per [[ECMD]] mit ''bmp085 pressnn 59000'' bedeutet, das ich 590m (59000cm) über NN wohne. Die im Sensor verfügbare Temperatur wird parallel ausgelesen. '''Einbindung in FHEM''' bmp085.classdef erstellen: <source lang="perl"> get BMP cmd {"bmp085 temp\n\000bmp085 pressnn 59000\n"} get BMP expect ".*" get BMP postproc {\ s/(.*)\n(.*)\n/T: $1 P: $2/;\ my $hash = $defs{%NAME};\ my $temperature = $1/10;\ my $pressure = sprintf("%.1f",$2/100);\ my $state = "T: $temperature P: $pressure";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "pressure", $pressure, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die Temperatur wird in °C mit einer Nachkommastelle gelesen, der Luftdruck in hPa bzw. mbar auf eine Nachkommastelle gerundet. Passende Readings werden erstellt. Das expect .* kann noch angepasst werden, um bei fehlerhaften Messwerten entsprechend zu reagieren. Die classdef wird in FHEM eingebunden (mehrere .classdef mit Doppelpunkt trennen: siehe [[Nutzung_in_FHEM_(Deutsch)#Grundlagen | Grundlagen]]): <pre> define NETIO_STK ECMD telnet 192.168.3.89:2701 attr NETIO_STK classdefs BMP=/opt/fhem/FHEM/bmp085.classdef </pre> Der Sensor wird definiert: <pre> define BMP180 ECMDDevice BMP attr BMP180 IODev NETIO_STK </pre> Das STATE ''kann'' mit Maßeinheiten versehen werden: <pre> attr BMP180 stateFormat { sprintf("%s°C %shPa", ReadingsVal("BMP180","temperature",0), ReadingsVal("BMP180","pressure",0)) ;; } </pre> Eine zyklische Messung alle 4 Minuten erfolgt wieder mit ''at'': <pre> define Messung_BMP at +*00:04 get BMP180 BMP attr Messung_BMP verbose 0 </pre> Dabei unterdrückt verbose 0 einen zusätzlichen (doppelten) Logeintrag des Messvorganges. == analoge Eingänge abfragen == Die analogen Eingänge des ATMega sind recht simpel abzufragen. Dabei werden die hexadezimalen Werte gleich dezimal gewandelt, um die Weiterverarbeitung zu erleichtern. '''Einbindung in FHEM''' adc.classdef erstellen: <source lang="perl"> get value cmd {"adc get %PortID\n"} params PortID get value expect ".*" get value postproc {\ my $hexval = hex(trim("$_"));\ my $hash = $defs{%NAME};\ readingsSingleUpdate($hash, "state", $hexval, 1);\ } </source> Die classdef wird eingebunden: <pre> define NETIO_KU ECMD telnet 192.168.3.89:2701 attr NETIO_KU classdefs ADC=/opt/fhem/FHEM/adc.classdef </pre> Die Sensoren an den ersten beiden Ports werden definiert: <pre> define MP_0 ECMDDevice ADC 0 attr MP_0 IODev NETIO_KU define MP_1 ECMDDevice ADC 1 attr MP_1 IODev NETIO_KU </pre> Eine zyklische Messung alle 60 Sekunden funktioniert damit: <pre> define Messung_adc at +*00:01 get MP_0 value;; get MP_1 value attr Messung_adc verbose 0 </pre> == digitale Eingänge abfragen == todo == digitale Eingänge - proaktiv == Kontakte, die bei Zustandsänderung sofort in FHEM eine Meldung erzeugen sollen, kann man nicht zeitnah mit Polling abfragen. Diese Ereignisse, welche auch aus einem Control6-Script heraus generiert sein können, sollen selbst Meldung machen. Hierbei wird die ESEND-Funktion benutzt, mit welcher auch mehrere Ethersex'e untereinander kommunizieren können. Dabei ist es nicht relevant, ob das Device in FHEM per ECMDDevice bereits eingebunden wurde. Zuerst muss FHEM auf Port 2701 für Telnet-Verbindungen empfänglich werden: <pre> define telnetECMD telnet 2701 global </pre> Mit ''Watch io changes and react'' lässt sich per menuconfig bereits auf einfache Weise eine Abfrage von Portpins mit Generierung eines ESEND-Befehles bewerkstelligen. Das Beispiel soll zeigen, wie bei entsprechender Zustandsänderung an Pin PA0 an 192.168.178.10 ein FHEM-Befehl gesendet wird: <pre> ECMDTCP(PA0, RISING, 192.168.178.10, set Lampe on\n\n) ECMDTCP(PA0, FALLING, 192.168.178.10, set Lampe off\n\n) </pre> Jede Sequenz muss mit \n\n abgeschlossen werden, damit FHEM für weitere Befehle empfangsbereit bleibt. Falls man in FHEM flexibler bei der Weiterverarbeitung sein möchte, bietet sich eine dummy-notify-Kombination an. == [[Porterweiterungen_%28Deutsch%29#D.2FA-Wandler_mit_LTC1257 | LTC1257 D/A-Wandler]] == [[File:LTC1257.jpg|150px|thumb|right|LTC1257 Digital-Analog-Wandler innerhalb einer Schaltung]] Die 12bit Digital-Analog-Wandler von LINEAR TECHNOLOGY werden mit drei Pins bedient. Er wandelt (bei interner Referenzspannung) einen digital übermittelten Wert in eine Spannung von 0-2,048V um. Ein nachgeschalteter OPV als nichtinvertierender Verstärker kann diesen Bereich entsprechend skalieren. ltc1257.classdef erstellen: <source lang="perl"> # Umsetzung in ECMD Befehle # Ein Uebergabeparameter -> Sollwert set setDAC params dacValue set setDAC cmd {"ltc1257_set %dacValue\n"} set setDAC expect "OK\n" # Keine Uebergabeparameter set init cmd {"ltc1257_init\n"} set init expect "OK\n" # } </source> Die classdef wird eingebunden: <pre> define NETIO_KU ECMD telnet 192.168.3.82:2701 attr NETIO_KU classdefs LTC1257=/opt/fhem/FHEM/ltc1257.classdef </pre> Der LTC wird entsprechend definiert: <pre> define HZ_DAC ECMDDevice LTC1257 attr HZ_DAC IODev NETIO_KU </pre> Nun lässt sich mit einem '''set HZ_DAC init''' der LTC initialisieren (die gemessene Ausgangsspannung sollte 0V sein) und mit '''set HZ_DAC setDAC [0...4095]''' der gewünschte Wert setzen. Hier muss vorab experimentell entsprechend der nachfolgenden Beschaltung die tatsächliche Spannung ermittelt werden. == [[LCD_(Deutsch) | HD44780 Punktmatrixdisplays]] == [[File:HD44780.jpg|150px|thumb|right|verschiedene HD44780 Displays (16x1 bis 40x4)]] Die beliebten Punktmatrix-Displays auf Basis [http://de.wikipedia.org/wiki/HD44780 HD44780] können vollumfänglich in FHEM beschrieben werden. Dabei wird vorrausgesetzt, das in [https://github.com/ethersex/ethersex/blob/master/hardware/lcd/hd44780.h /hardware/lcd/hd44780.h] beim entsprechenden Modell die passende Adressierung der Zeilen und die genutzte Zeilen-/Spaltenzahl vor dem Compilieren angepasst wurde. '''Einbindung in FHEM''' lcd.classdef erstellen: <source lang="perl"> # Umsetzung der ECMD Befehle set write params line col text set write cmd {"lcd goto %line %col\n\000lcd write %text\n"} set write expect "OK\n" set write postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set clear params col set clear cmd {"lcd clear %col\n"} set clear expect "OK\n" set clear postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set clear_all cmd {"lcd clear\n"} set clear_all expect "OK\n" set clear_all postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set lcd_bl params state set lcd_bl cmd {"lcd backlight %state\n"} set lcd_bl expect "OK\n" set lcd_bl postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} </source> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs LCD=/opt/fhem/FHEM/lcd.classdef </pre> Das Display wird definiert: <pre> define WZ_LCD ECMDDevice LCD attr WZ_LCD IODev NETIO_TEST </pre> Es stehen in FHEM folgende Befehle für das LCD bereit: {| border='1' | ''Befehl'' | ''Funktion'' |- | set WZ_LCD clear [ZEILE] | löscht den Inhalt einer ZEILE (0...3) |- | set WZ_LCD clear_all | löscht den Inhalt aller Zeilen |- | set WZ_LCD lcd_bl STATE | schaltet die Hintergrundbeleuchtung ein oder aus (STATE on oder off) |- | set WZ_LCD write [ZEILE] [SPALTE] [TEXT] | schreibt einen TEXT auf Position ZEILE SPALTE (0...n) |- |} Da ein im TEXT übergebenes Leerzeichen als weiterer Befehl interpretiert wird und zu einer Fehlermeldung führt, ist eine Übergabe nur mit \x20 im Text möglich. Das gilt auch für Umlaute. Anhand der [http://de.wikipedia.org/wiki/HD44780#Schrift_und_Zeichensatz Zeichensatztabelle] lassen sich ä durch \xE1, ü durch \xF5 und ö durch \xEF darstellen. Das ß wird mit \xE2 erreicht. Die Tabelle kann für manche Displays abweichend sein.<br /> Beispiel: ''set WZ_LCD write 0 0 Fenster\x20schlie\xE2en'' schreibt ein '''Fenster schließen''' auf's LCD. '''Komfortable Nutzung in FHEM mit DLCD''' Mit dem DLCD-Modul ([http://www.fhemwiki.de/wiki/DLCD Wiki-Beitrag] / [http://forum.fhem.de/index.php/topic,24519.0.html Foren-Beitrag]) für FHEM lässt sich jedes Display auf einfache Weise beschreiben. Dabei lassen sich bequem Readings von allen Devices nutzen, aufbereiten (formatieren, umrechnen, etc.) und entsprechend darstellen. Eine genaue Beschreibung hält der Wiki-Beitrag bereit; hier soll ein Beispiel gezeigt werden. Ziel war es, auf einem 16x1 LCD wechselweise ''Datum/Zeit => Klimadaten Keller => Datum/Zeit => Klimadaten Garten'' darzustellen. Die Anzeige rotiert im 15-Sekunden-Takt, so das zu 50% Datum/Zeit und je 25% die Werte aus dem Garten und dem Keller angezeigt werden. Es wird bereits im Modul jedes Leerzeichen mit \x20 übersetzt. Der Außensensor ist ein [http://www.elv.de/elv-funk-kombi-wettersensor-ks-300-2-br-inkl-hochwertigem-2-m-edelstahlmast-br-und-qualitaetsbatterien.html KS300] (bzw. KS200) von ELV. Mit etwas Formatierung und ein paar Leerzeichen lässt sich eine stets gleiche Positionierung der Daten erreichen, da die Zeile nicht explizit gelöscht wird. Auszug aus der fhem.cfg: <pre> define DLCD_WZ DLCD attr DLCD_WZ dlcdBlankspaceReplace \x20 attr DLCD_WZ dlcdCols 16 attr DLCD_WZ dlcdLine1 %date_WD_ger% %date_D%.%date_M_ger% %time_h%:%time_m% attr DLCD_WZ dlcdLine2 Keller:%1%/%2% attr DLCD_WZ dlcdLine3 %date_WD_ger% %date_D%.%date_M_ger% %time_h%:%time_m% attr DLCD_WZ dlcdLine4 Garten: %3%/%4% attr DLCD_WZ dlcdPhysicalRows 1 attr DLCD_WZ dlcdPollInterval 15 attr DLCD_WZ dlcdRows 4 attr DLCD_WZ dlcdScrolling 1 attr DLCD_WZ dlcdTriggerCmd set WZ_LCD write %L% 0 %T% attr DLCD_WZ dlcdVal1 Keller:temperature attr DLCD_WZ dlcdVal1formatnum 3+1 attr DLCD_WZ dlcdVal2 Keller:humidity attr DLCD_WZ dlcdVal2formatnum 3+1 attr DLCD_WZ dlcdVal3 KS300:temperature attr DLCD_WZ dlcdVal3formatnum 3+1+- attr DLCD_WZ dlcdVal4 KS300:humidity attr DLCD_WZ dlcdVal4formatnum 2+0 </pre> Das Ergebnis kann so aussehen: <gallery> DLCD_1.jpg|Zustand 1.-15. Sekunde DLCD_2.jpg|Zustand 16.-30. Sekunde DLCD_3.jpg|Zustand 31.-45. Sekunde DLCD_4.jpg|Zustand 46.-60. Sekunde </gallery> Die Formatierung bewirkt eine immer identische Platzierung der Daten. Der Außensensor hat keine Zehntelwerte bei der Feuchte, muss dafür aber negative Temperaturen darstellen. Der Innensensor zeigt Zehntelwerte, womit sich Tendenzen eher erkennen lassen. == [[RFM12_ASK_(Deutsch) | Intertechno schalten mit RFM12]] == todo == [[RFM12_ASK_(Deutsch) | IC2272 schalten mit RFM12]] == todo [[Category:Application|Application]] 1d9489d8ca17b886d08be314b17de8444c38e77d 1504 1478 2015-03-12T17:31:04Z Kpwg 721 /* 1-Wire Temperatursensoren */ regexp angepasst wikitext text/x-wiki {{i18n|Nutzung in FHEM}} [http://www.fhemwiki.de/wiki/Hauptseite FHEM] ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um diverse per Funk und Kabel angebundene Komponenten aus dem Bereich der Hausautomation zu steuern. Er ist lizensiert unter der GPL v2. Das [http://www.pollin.de/shop/suchergebnis.html?S_TEXT=810+058 AVR-Net-IO] von [http://www.pollin.de Pollin] mit [[Ethersex]] dient als [http://www.fhemwiki.de/wiki/AVR-NET-IO preisgünstiger Einstieg in die Hausautomatisierung]. Verwendbar ist aber auch jede andere [[Supported_Boards_(Deutsch) | Hardware]], die von Ethersex unterstützt wird (Arduino, eigene Entwicklungen, etc.). Über [[ECMD]] lassen sich dabei theoretisch alle in [[Ethersex]] vorhandenen [[ECMD_Protocols_%28Deutsch%29 | Möglichkeiten]] nutzen, sofern in FHEM entsprechende [http://fhem.de/commandref.html#ECMD ECMD-Devices] definiert und eingebunden werden, die passende Klassendefinition exisitert und die Aktion ausgelöst wird. == Grundlagen == Ausgehend von einem fertigen und per Telnet erreichbaren Ethersex muss in FHEM zuerst das entsprechende Device definiert werden. <pre> define NETIO_WZ ECMD telnet 192.168.3.81:2701 </pre> Eine serielle Anbindung kann mit ''define <name> ECMD serial <SerialDevice>[<@BaudRate>]'' alternativ erfolgen. Anschließend werden die erstellten .classdef-Konfigurationsdateien der einzelnen Funktionen dem System bekannt gemacht. In diesen .classdef-Dateien (Name und Endung sind frei wählbar!) wird die Schnittstelle zwischen FHEM und ECMD/Ethersex definiert. Dabei können mit perl übergebene Parameter und empfangene Daten bearbeitet sowie die in FHEM gebräuchlichen Readings erstellt werden. <pre> attr NETIO_WZ classdefs RFM12_2272=/opt/fhem/FHEM/rfm12_2272.classdef:RFM12_IT=/opt/fhem/FHEM/rfm12_it.classdef:LCD=/opt/fhem/FHEM/lcd.classdef:DHT22=/opt/fhem/FHEM/dht22.classdef:1WIRE=/opt/fhem/FHEM/1wire.classdef </pre> Die Definitionen für IC2272, Intertechno, HD44780-LCD, DHT22 und 1wire sind nun eingebunden. In den folgenden Abschnitten wird auf die einzelnen Devices näher eingegangen. Generell sind Pfade und IP-Adressen sowie übergebene Parameter noch entsprechend der eigenen Konfiguration anzupassen. == [[Onewire_(Deutsch) | 1-Wire Temperatursensoren]] == [[File:DS18B20.jpg|150px|thumb|right|DS18B20-Sensoren]] Die 1wire-Temperatursensoren DS18B20 oder DS18S20 werden im [[Onewire_(Deutsch)#Polling_Modus | Polling Modus]] abgefragt. Das macht die zyklische Abfrage aus FHEM heraus wesentlich einfacher. Eine Polling-Zeit von mindestens 30 Sekunden ist absolut ausreichend.Im Vorfeld sollte man sich die [[Onewire_(Deutsch)#Benennung_von_Sensoren | ROM-Codes der Sensoren]] notieren, da diese nachher benötigt werden. 1w-temp.classdef erstellen: <source lang="perl"> # Uebergabeparameter Onewire Rom-Code params devID # Umsetzung in ECMD Befehle 1w get = Temperatur auslesen get 1W cmd {"1w get %devID\n"} get 1W expect "\d+.\d+\n" get 1W postproc {\ s/\n//g;\ my $hash = $defs{%NAME};\ my $temperature = $_;\ my $state = "T: $temperature";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die classdef wird eingebunden: <pre> define NETIO_KU ECMD telnet 192.168.3.82:2701 attr NETIO_KU classdefs 1W-TEMP=/opt/fhem/FHEM/1w-temp.classdef </pre> Die Sensoren werden anhand des ROM-Code definiert: <pre> define HZ_WW ECMDDevice 1W-TEMP 284c8820050003d4 attr HZ_WW IODev NETIO_KU define HZ_VL ECMDDevice 1W-TEMP 2890a520050003d7 attr HZ_VL IODev NETIO_KU </pre> Eine zyklische Messung pro Minute lässt sich in dieser Form auslösen: <pre> define Messung_1w at +*00:01 get HZ_WW 1W;; get HZ_VL 1W attr Messung_1w verbose 0 </pre> == [[DHT|DHT22 Temperatur-/Feuchtesensoren]] == [[File:DHT22.jpg|150px|thumb|right|DHT22-Sensoren]] [[Ethersex]] unterstützt die preiswerten Temperatur-/Feuchtesensoren [[DHT|DHT11 und DHT22]], wobei letztere [[DHT#DHT11_vs_DHT22|um einiges genauer sind]]. Die Sensoren benötigen 5V Betriebsspannung und kommunizieren über je einen Pin mit dem Prozessor. Der Preis pro Stück liegt derzeit bei etwa 3.50 Euro (ebay/China). Wer die Trägheit und Ungenauigkeit der S300TH oder TX29DTH kennt, wünscht sich vermutlich Besseres; vor allem bei Berechnung von [http://de.wikipedia.org/wiki/Taupunkt Taupunkt] und [http://de.wikipedia.org/wiki/Luftfeuchtigkeit#Absolute_Luftfeuchtigkeit absoluter Feuchte], welche von der Genauigkeit der gemessenen Eingangsgrößen sehr profitieren. Berechnungen von Hand kann man beim [http://www.wetterochs.de/wetter/feuchte.html Wetterochs] durchführen. Die automatische Berechnung der absoluten Feuchte in FHEM wird im [http://forum.fhem.de/index.php/topic,21458.0.html Forum] erklärt. '''Einbindung in FHEM''' dht22m.classdef erstellen: <source lang="perl"> # Uebergabeparameter DHT22 ID 0...n params devID # Umsetzung in ECMD Befehle fuer DHT22 get DHT cmd {"dht temp %devID\n\000dht humid %devID\n"} get DHT expect "\d+.\d\n" get DHT postproc {\ s/(.*)\n(.*)\n/T: $1 H: $2/;\ my $hash = $defs{%NAME};\ my $temperature = $1;\ my $humidity = $2;\ my $state = $_;\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "humidity", $humidity, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs DHT22M=/opt/fhem/FHEM/dht22m.classdef </pre> Die Sensoren werden definiert: <pre> define Test0 ECMDDevice DHT22M 0 attr Test0 IODev NETIO_TEST define Test1 ECMDDevice DHT22M 1 attr Test1 IODev NETIO_TEST define Test2 ECMDDevice DHT22M 2 attr Test2 IODev NETIO_TEST define Test3 ECMDDevice DHT22M 3 attr Test3 IODev NETIO_TEST </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_DHT at +*00:04 get Test0 DHT;; get Test1 DHT;; get Test2 DHT;; get Test3 DHT attr Messung_DHT verbose 0 </pre> Fünfzehn Messwerte pro Stunde genügen den allermeisten Anforderungen. == [[BMP085 | BMP085/BMP180 Luftdrucksensor]] == [[File:BMP180.jpg|150px|thumb|right|BMP180 (unten links)]] Ethersex unterstützt den BMP085 (bzw. den BMP180; der Code ist identisch) über das [[I2C_(Deutsch) | I2C]]-Interface. Da der Sensor für 3.3V Betriebsspannung ausgelegt ist, muss entweder der I2C-Pegel angepasst oder der ATMega auf 3.3V adaptiert werden. Weiterhin sollte die Höhe über Null bekannt sein. Beispiel: Eine Abfrage per [[ECMD]] mit ''bmp085 pressnn 59000'' bedeutet, das ich 590m (59000cm) über NN wohne. Die im Sensor verfügbare Temperatur wird parallel ausgelesen. '''Einbindung in FHEM''' bmp085.classdef erstellen: <source lang="perl"> get BMP cmd {"bmp085 temp\n\000bmp085 pressnn 59000\n"} get BMP expect ".*" get BMP postproc {\ s/(.*)\n(.*)\n/T: $1 P: $2/;\ my $hash = $defs{%NAME};\ my $temperature = $1/10;\ my $pressure = sprintf("%.1f",$2/100);\ my $state = "T: $temperature P: $pressure";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "pressure", $pressure, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die Temperatur wird in °C mit einer Nachkommastelle gelesen, der Luftdruck in hPa bzw. mbar auf eine Nachkommastelle gerundet. Passende Readings werden erstellt. Das expect .* kann noch angepasst werden, um bei fehlerhaften Messwerten entsprechend zu reagieren. Die classdef wird in FHEM eingebunden (mehrere .classdef mit Doppelpunkt trennen: siehe [[Nutzung_in_FHEM_(Deutsch)#Grundlagen | Grundlagen]]): <pre> define NETIO_STK ECMD telnet 192.168.3.89:2701 attr NETIO_STK classdefs BMP=/opt/fhem/FHEM/bmp085.classdef </pre> Der Sensor wird definiert: <pre> define BMP180 ECMDDevice BMP attr BMP180 IODev NETIO_STK </pre> Das STATE ''kann'' mit Maßeinheiten versehen werden: <pre> attr BMP180 stateFormat { sprintf("%s°C %shPa", ReadingsVal("BMP180","temperature",0), ReadingsVal("BMP180","pressure",0)) ;; } </pre> Eine zyklische Messung alle 4 Minuten erfolgt wieder mit ''at'': <pre> define Messung_BMP at +*00:04 get BMP180 BMP attr Messung_BMP verbose 0 </pre> Dabei unterdrückt verbose 0 einen zusätzlichen (doppelten) Logeintrag des Messvorganges. == analoge Eingänge abfragen == Die analogen Eingänge des ATMega sind recht simpel abzufragen. Dabei werden die hexadezimalen Werte gleich dezimal gewandelt, um die Weiterverarbeitung zu erleichtern. '''Einbindung in FHEM''' adc.classdef erstellen: <source lang="perl"> get value cmd {"adc get %PortID\n"} params PortID get value expect ".*" get value postproc {\ my $hexval = hex(trim("$_"));\ my $hash = $defs{%NAME};\ readingsSingleUpdate($hash, "state", $hexval, 1);\ } </source> Die classdef wird eingebunden: <pre> define NETIO_KU ECMD telnet 192.168.3.89:2701 attr NETIO_KU classdefs ADC=/opt/fhem/FHEM/adc.classdef </pre> Die Sensoren an den ersten beiden Ports werden definiert: <pre> define MP_0 ECMDDevice ADC 0 attr MP_0 IODev NETIO_KU define MP_1 ECMDDevice ADC 1 attr MP_1 IODev NETIO_KU </pre> Eine zyklische Messung alle 60 Sekunden funktioniert damit: <pre> define Messung_adc at +*00:01 get MP_0 value;; get MP_1 value attr Messung_adc verbose 0 </pre> == digitale Eingänge abfragen == todo == digitale Eingänge - proaktiv == Kontakte, die bei Zustandsänderung sofort in FHEM eine Meldung erzeugen sollen, kann man nicht zeitnah mit Polling abfragen. Diese Ereignisse, welche auch aus einem Control6-Script heraus generiert sein können, sollen selbst Meldung machen. Hierbei wird die ESEND-Funktion benutzt, mit welcher auch mehrere Ethersex'e untereinander kommunizieren können. Dabei ist es nicht relevant, ob das Device in FHEM per ECMDDevice bereits eingebunden wurde. Zuerst muss FHEM auf Port 2701 für Telnet-Verbindungen empfänglich werden: <pre> define telnetECMD telnet 2701 global </pre> Mit ''Watch io changes and react'' lässt sich per menuconfig bereits auf einfache Weise eine Abfrage von Portpins mit Generierung eines ESEND-Befehles bewerkstelligen. Das Beispiel soll zeigen, wie bei entsprechender Zustandsänderung an Pin PA0 an 192.168.178.10 ein FHEM-Befehl gesendet wird: <pre> ECMDTCP(PA0, RISING, 192.168.178.10, set Lampe on\n\n) ECMDTCP(PA0, FALLING, 192.168.178.10, set Lampe off\n\n) </pre> Jede Sequenz muss mit \n\n abgeschlossen werden, damit FHEM für weitere Befehle empfangsbereit bleibt. Falls man in FHEM flexibler bei der Weiterverarbeitung sein möchte, bietet sich eine dummy-notify-Kombination an. == [[Porterweiterungen_%28Deutsch%29#D.2FA-Wandler_mit_LTC1257 | LTC1257 D/A-Wandler]] == [[File:LTC1257.jpg|150px|thumb|right|LTC1257 Digital-Analog-Wandler innerhalb einer Schaltung]] Die 12bit Digital-Analog-Wandler von LINEAR TECHNOLOGY werden mit drei Pins bedient. Er wandelt (bei interner Referenzspannung) einen digital übermittelten Wert in eine Spannung von 0-2,048V um. Ein nachgeschalteter OPV als nichtinvertierender Verstärker kann diesen Bereich entsprechend skalieren. ltc1257.classdef erstellen: <source lang="perl"> # Umsetzung in ECMD Befehle # Ein Uebergabeparameter -> Sollwert set setDAC params dacValue set setDAC cmd {"ltc1257_set %dacValue\n"} set setDAC expect "OK\n" # Keine Uebergabeparameter set init cmd {"ltc1257_init\n"} set init expect "OK\n" # } </source> Die classdef wird eingebunden: <pre> define NETIO_KU ECMD telnet 192.168.3.82:2701 attr NETIO_KU classdefs LTC1257=/opt/fhem/FHEM/ltc1257.classdef </pre> Der LTC wird entsprechend definiert: <pre> define HZ_DAC ECMDDevice LTC1257 attr HZ_DAC IODev NETIO_KU </pre> Nun lässt sich mit einem '''set HZ_DAC init''' der LTC initialisieren (die gemessene Ausgangsspannung sollte 0V sein) und mit '''set HZ_DAC setDAC [0...4095]''' der gewünschte Wert setzen. Hier muss vorab experimentell entsprechend der nachfolgenden Beschaltung die tatsächliche Spannung ermittelt werden. == [[LCD_(Deutsch) | HD44780 Punktmatrixdisplays]] == [[File:HD44780.jpg|150px|thumb|right|verschiedene HD44780 Displays (16x1 bis 40x4)]] Die beliebten Punktmatrix-Displays auf Basis [http://de.wikipedia.org/wiki/HD44780 HD44780] können vollumfänglich in FHEM beschrieben werden. Dabei wird vorrausgesetzt, das in [https://github.com/ethersex/ethersex/blob/master/hardware/lcd/hd44780.h /hardware/lcd/hd44780.h] beim entsprechenden Modell die passende Adressierung der Zeilen und die genutzte Zeilen-/Spaltenzahl vor dem Compilieren angepasst wurde. '''Einbindung in FHEM''' lcd.classdef erstellen: <source lang="perl"> # Umsetzung der ECMD Befehle set write params line col text set write cmd {"lcd goto %line %col\n\000lcd write %text\n"} set write expect "OK\n" set write postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set clear params col set clear cmd {"lcd clear %col\n"} set clear expect "OK\n" set clear postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set clear_all cmd {"lcd clear\n"} set clear_all expect "OK\n" set clear_all postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set lcd_bl params state set lcd_bl cmd {"lcd backlight %state\n"} set lcd_bl expect "OK\n" set lcd_bl postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} </source> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs LCD=/opt/fhem/FHEM/lcd.classdef </pre> Das Display wird definiert: <pre> define WZ_LCD ECMDDevice LCD attr WZ_LCD IODev NETIO_TEST </pre> Es stehen in FHEM folgende Befehle für das LCD bereit: {| border='1' | ''Befehl'' | ''Funktion'' |- | set WZ_LCD clear [ZEILE] | löscht den Inhalt einer ZEILE (0...3) |- | set WZ_LCD clear_all | löscht den Inhalt aller Zeilen |- | set WZ_LCD lcd_bl STATE | schaltet die Hintergrundbeleuchtung ein oder aus (STATE on oder off) |- | set WZ_LCD write [ZEILE] [SPALTE] [TEXT] | schreibt einen TEXT auf Position ZEILE SPALTE (0...n) |- |} Da ein im TEXT übergebenes Leerzeichen als weiterer Befehl interpretiert wird und zu einer Fehlermeldung führt, ist eine Übergabe nur mit \x20 im Text möglich. Das gilt auch für Umlaute. Anhand der [http://de.wikipedia.org/wiki/HD44780#Schrift_und_Zeichensatz Zeichensatztabelle] lassen sich ä durch \xE1, ü durch \xF5 und ö durch \xEF darstellen. Das ß wird mit \xE2 erreicht. Die Tabelle kann für manche Displays abweichend sein.<br /> Beispiel: ''set WZ_LCD write 0 0 Fenster\x20schlie\xE2en'' schreibt ein '''Fenster schließen''' auf's LCD. '''Komfortable Nutzung in FHEM mit DLCD''' Mit dem DLCD-Modul ([http://www.fhemwiki.de/wiki/DLCD Wiki-Beitrag] / [http://forum.fhem.de/index.php/topic,24519.0.html Foren-Beitrag]) für FHEM lässt sich jedes Display auf einfache Weise beschreiben. Dabei lassen sich bequem Readings von allen Devices nutzen, aufbereiten (formatieren, umrechnen, etc.) und entsprechend darstellen. Eine genaue Beschreibung hält der Wiki-Beitrag bereit; hier soll ein Beispiel gezeigt werden. Ziel war es, auf einem 16x1 LCD wechselweise ''Datum/Zeit => Klimadaten Keller => Datum/Zeit => Klimadaten Garten'' darzustellen. Die Anzeige rotiert im 15-Sekunden-Takt, so das zu 50% Datum/Zeit und je 25% die Werte aus dem Garten und dem Keller angezeigt werden. Es wird bereits im Modul jedes Leerzeichen mit \x20 übersetzt. Der Außensensor ist ein [http://www.elv.de/elv-funk-kombi-wettersensor-ks-300-2-br-inkl-hochwertigem-2-m-edelstahlmast-br-und-qualitaetsbatterien.html KS300] (bzw. KS200) von ELV. Mit etwas Formatierung und ein paar Leerzeichen lässt sich eine stets gleiche Positionierung der Daten erreichen, da die Zeile nicht explizit gelöscht wird. Auszug aus der fhem.cfg: <pre> define DLCD_WZ DLCD attr DLCD_WZ dlcdBlankspaceReplace \x20 attr DLCD_WZ dlcdCols 16 attr DLCD_WZ dlcdLine1 %date_WD_ger% %date_D%.%date_M_ger% %time_h%:%time_m% attr DLCD_WZ dlcdLine2 Keller:%1%/%2% attr DLCD_WZ dlcdLine3 %date_WD_ger% %date_D%.%date_M_ger% %time_h%:%time_m% attr DLCD_WZ dlcdLine4 Garten: %3%/%4% attr DLCD_WZ dlcdPhysicalRows 1 attr DLCD_WZ dlcdPollInterval 15 attr DLCD_WZ dlcdRows 4 attr DLCD_WZ dlcdScrolling 1 attr DLCD_WZ dlcdTriggerCmd set WZ_LCD write %L% 0 %T% attr DLCD_WZ dlcdVal1 Keller:temperature attr DLCD_WZ dlcdVal1formatnum 3+1 attr DLCD_WZ dlcdVal2 Keller:humidity attr DLCD_WZ dlcdVal2formatnum 3+1 attr DLCD_WZ dlcdVal3 KS300:temperature attr DLCD_WZ dlcdVal3formatnum 3+1+- attr DLCD_WZ dlcdVal4 KS300:humidity attr DLCD_WZ dlcdVal4formatnum 2+0 </pre> Das Ergebnis kann so aussehen: <gallery> DLCD_1.jpg|Zustand 1.-15. Sekunde DLCD_2.jpg|Zustand 16.-30. Sekunde DLCD_3.jpg|Zustand 31.-45. Sekunde DLCD_4.jpg|Zustand 46.-60. Sekunde </gallery> Die Formatierung bewirkt eine immer identische Platzierung der Daten. Der Außensensor hat keine Zehntelwerte bei der Feuchte, muss dafür aber negative Temperaturen darstellen. Der Innensensor zeigt Zehntelwerte, womit sich Tendenzen eher erkennen lassen. == [[RFM12_ASK_(Deutsch) | Intertechno schalten mit RFM12]] == todo == [[RFM12_ASK_(Deutsch) | IC2272 schalten mit RFM12]] == todo [[Category:Application|Application]] fb73776c18901afe602b229b3389fdfc9747488e 6 454 1479 1413 2015-01-18T18:58:54Z Kpwg 721 Kpwg uploaded a new version of &quot;[[File:Fhem ke 06.jpg]]&quot;: updated with bias-resistors wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 455 1480 1414 2015-01-18T18:59:38Z Kpwg 721 Kpwg uploaded a new version of &quot;[[File:Fhem ke 07.jpg]]&quot;: updated with bias-resistors wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 476 1482 2015-01-21T16:46:10Z Kpwg 721 ATMega8, ZBUS, termination and bias-resistors wikitext text/x-wiki ATMega8, ZBUS, termination and bias-resistors de6c15787849fee9cade740fb07c3d90f84ab0dc 0 477 1483 2015-01-21T18:34:08Z Kpwg 721 Created page with "{{i18n|ZBus}} ZBus ist ein auf [[wikipedia:RS485|RS485]] basierendes Zweidraht-Bussystem, auf welchem Pakete variabler Länge übermittelt werden können. Es wurde primär f..." wikitext text/x-wiki {{i18n|ZBus}} ZBus ist ein auf [[wikipedia:RS485|RS485]] basierendes Zweidraht-Bussystem, auf welchem Pakete variabler Länge übermittelt werden können. Es wurde primär für die Datenübertragung zwischen Mikrocontrollern konzipiert, zum Beispiel zur Kommunikation von ATmega8 und ATmega644. Ethersex verwendet ZBus zur Übermittlung von IP-Paketen von einem Controller, der als Bridge fungiert, hin zu einzelnen kleineren ZBus-Geräten, die beispielsweise auf ATmega8 basieren. Der Einsatz von ZBus ermöglicht den großflächigen Einsatz von kleineren ATmega-Mikrocontrolleren, an die man in der Regel keinen ENC28J60 anschließen möchte. Zudem lässt sich zum Beispiel ein bestehendes Telefonkabelnetz verwenden, welches für LAN ungeeignet wäre. Ebendiese kleineren Controller können über eine Bridge hinweg via IP-Protokoll erreicht werden, zumindest über UDP und ICMP. Eine TCP/IP-Übertragung scheitert an den begrenzten Resourcen eines ATmega8, mit größeren Controllern ist jedoch auch TCP möglich. Als Bridge kann wahlweise ein entsprechend konfiguriertes Ethersex oder ein normaler Rechner mit serieller Schnittstelle, auf dem [[ZBus Serial Host_(Deutsch) | ZBus Serial Host]] läuft, eingesetzt werden. '''Schaltungsbeispiel / praktische Erfahrungen''' [[File:ZBUS_bias_term.JPG|thumb|right|ATMega8 mit ZBUS]] Zur Anschaltung des ZBus wird ein Pegelwandler benötigt. Dabei wird an dieser Stelle ein preiswerter und moderner MAX485 verwendet, welcher sich durch minimale Außenbeschaltung und geringen Eigenstromverbrauch (etwa 1mA) auszeichnet. Es ist damit nur Halbduplexbetrieb möglich, was jedoch in den allermeisten Fällen genügt. Besonderheiten: * es werden drei Prozessorpins benötigt (TX, RX, TX/RX-Umschaltung) * der Bus muss an beiden Enden mit 120 Ohm terminiert werden (R1), praktischerweise per Jumper für flexible Einsatzmöglichkeiten * der Bus sollte an einer Stelle mit Bias-Widerständen (R2 und R3) terminiert sein, damit definierte Pegel herrschen, wenn kein Sender aktiv ist * diese beiden identischen Widerstände sind unkritisch; Werte zwischen 390 und 680 Ohm funktionieren problemlos * es kann daher Busteilnehmer mit einem, zwei oder drei Widerständen geben; der flexibelste Busteilnehmer hat alle Widerstände mit Jumper aktivierbar * unterschiedliche Kabelarten sind zu vermeiden, da sich durch Stoßstellen die Signalqualität verschlechtert (Reflexionen) * eine Datenrate von 76,8 kbit/s erzielte die besten Ergebnisse; eine geringere Geschwindigkeit bringt bei schlechterer Signalqualität praktisch keine Verbesserung * die Masseverbindung sollte mitgeführt werden; eine Versorgungsspannung wird als abgesicherte Rohspannung (12V) ebenfalls am Bus zur Versorgung der Devices bereitgestellt * ein [[ZBus_Testboard_(Deutsch) | Testboard]] stellt zum Beispiel für diese Methode eine Minimalvariante dar; basierend auf ATMega328 (Arduino Pro Mini) mit Keramikresonator, Längsregler 7805 und MAX485 '''Mit "zbus stats" den Bus im Blick''' Der ECMD-Befehl "zbus stats" ermöglicht die schnelle Beurteilung der Übertragungsqualität. Aktiviert wird er über das ZBus-debug-flag im Menuconfig. Die Ausgabe bedeutet im Einzelnen: <pre>rx fe=4752, ov=119, pe=0, bf=0, #=57736, tx #=264</pre> {| border='1' | ''Wert'' | ''Beschreibung'' |- | rx fe | Frame Error |- | rx ov | Overflow |- | rx pe | Parity Error |- | rx bf | Buffer full |- | # | Summe empfangene Bytes |- | tx # | Summe gesendete Bytes |- |} [[Category:Hardware]] e228ff624e6b9d1b4675dc2ca4cb49fd7b372fb0 1484 1483 2015-01-24T12:34:34Z GooPie4o 265 wikitext text/x-wiki {{i18n|ZBus}} {{Module |NAME=ZBUS |MENUCONFIG=Network->ZBUS Support |STATUS={{stable}} |PINNING= - |ECMD={{has_ecmd}} |CONTROL6= - |DEPENDS=[[ECMD]] |REQUIRES= USART |TIMER= - |CODE=[https://github.com/ethersex/ethersex/tree/master/protocols/zbus https://github.com/ethersex/ethersex/tree/master/protocols/zbus] }} ZBus ist ein auf [[wikipedia:RS485|RS485]] basierendes Zweidraht-Bussystem, auf welchem Pakete variabler Länge übermittelt werden können. Es wurde primär für die Datenübertragung zwischen Mikrocontrollern konzipiert, zum Beispiel zur Kommunikation von ATmega8 und ATmega644. Ethersex verwendet ZBus zur Übermittlung von IP-Paketen von einem Controller, der als Bridge fungiert, hin zu einzelnen kleineren ZBus-Geräten, die beispielsweise auf ATmega8 basieren. Der Einsatz von ZBus ermöglicht den großflächigen Einsatz von kleineren ATmega-Mikrocontrolleren, an die man in der Regel keinen ENC28J60 anschließen möchte. Zudem lässt sich zum Beispiel ein bestehendes Telefonkabelnetz verwenden, welches für LAN ungeeignet wäre. Ebendiese kleineren Controller können über eine Bridge hinweg via IP-Protokoll erreicht werden, zumindest über UDP und ICMP. Eine TCP/IP-Übertragung scheitert an den begrenzten Resourcen eines ATmega8, mit größeren Controllern ist jedoch auch TCP möglich. Als Bridge kann wahlweise ein entsprechend konfiguriertes Ethersex oder ein normaler Rechner mit serieller Schnittstelle, auf dem [[ZBus Serial Host_(Deutsch) | ZBus Serial Host]] läuft, eingesetzt werden. '''Schaltungsbeispiel / praktische Erfahrungen''' [[File:ZBUS_bias_term.JPG|thumb|right|ATMega8 mit ZBUS]] Zur Anschaltung des ZBus wird ein Pegelwandler benötigt. Dabei wird an dieser Stelle ein preiswerter und moderner MAX485 verwendet, welcher sich durch minimale Außenbeschaltung und geringen Eigenstromverbrauch (etwa 1mA) auszeichnet. Es ist damit nur Halbduplexbetrieb möglich, was jedoch in den allermeisten Fällen genügt. Besonderheiten: * es werden drei Prozessorpins benötigt (TX, RX, TX/RX-Umschaltung) * der Bus muss an beiden Enden mit 120 Ohm terminiert werden (R1), praktischerweise per Jumper für flexible Einsatzmöglichkeiten * der Bus sollte an einer Stelle mit Bias-Widerständen (R2 und R3) terminiert sein, damit definierte Pegel herrschen, wenn kein Sender aktiv ist * diese beiden identischen Widerstände sind unkritisch; Werte zwischen 390 und 680 Ohm funktionieren problemlos * es kann daher Busteilnehmer mit einem, zwei oder drei Widerständen geben; der flexibelste Busteilnehmer hat alle Widerstände mit Jumper aktivierbar * unterschiedliche Kabelarten sind zu vermeiden, da sich durch Stoßstellen die Signalqualität verschlechtert (Reflexionen) * eine Datenrate von 76,8 kbit/s erzielte die besten Ergebnisse; eine geringere Geschwindigkeit bringt bei schlechterer Signalqualität praktisch keine Verbesserung * die Masseverbindung sollte mitgeführt werden; eine Versorgungsspannung wird als abgesicherte Rohspannung (12V) ebenfalls am Bus zur Versorgung der Devices bereitgestellt * ein [[ZBus_Testboard_(Deutsch) | Testboard]] stellt zum Beispiel für diese Methode eine Minimalvariante dar; basierend auf ATMega328 (Arduino Pro Mini) mit Keramikresonator, Längsregler 7805 und MAX485 '''Mit "zbus stats" den Bus im Blick''' Der ECMD-Befehl "zbus stats" ermöglicht die schnelle Beurteilung der Übertragungsqualität. Aktiviert wird er über das ZBus-debug-flag im Menuconfig. Die Ausgabe bedeutet im Einzelnen: <pre>rx fe=4752, ov=119, pe=0, bf=0, #=57736, tx #=264</pre> {| border='1' | ''Wert'' | ''Beschreibung'' |- | rx fe | Frame Error |- | rx ov | Overflow |- | rx pe | Parity Error |- | rx bf | Buffer full |- | # | Summe empfangene Bytes |- | tx # | Summe gesendete Bytes |- |} [[Category:Hardware]] 25996036cccbdb0352a7cb15236c4b53f5232674 1485 1484 2015-01-24T17:05:48Z Kpwg 721 wikitext text/x-wiki {{i18n|ZBus}} {{Module |NAME=ZBUS |MENUCONFIG=Network->ZBUS Support |STATUS={{stable}} |PINNING= - |ECMD={{has_ecmd}} |CONTROL6= - |DEPENDS=[[ECMD]] |REQUIRES= USART |TIMER= - |CODE=[https://github.com/ethersex/ethersex/tree/master/protocols/zbus https://github.com/ethersex/ethersex/tree/master/protocols/zbus] }} == Was ist ZBus? == ZBus ist ein auf [[wikipedia:RS485|RS485]] basierendes Zweidraht-Bussystem, auf welchem Pakete variabler Länge übermittelt werden können. Es wurde primär für die Datenübertragung zwischen Mikrocontrollern konzipiert, zum Beispiel zur Kommunikation von ATmega8 und ATmega644. Ethersex verwendet ZBus zur Übermittlung von IP-Paketen von einem Controller, der als Bridge fungiert, hin zu einzelnen kleineren ZBus-Geräten, die beispielsweise auf ATmega8 basieren. Der Einsatz von ZBus ermöglicht den großflächigen Einsatz von kleineren ATmega-Mikrocontrolleren, an die man in der Regel keinen ENC28J60 anschließen möchte. Zudem lässt sich zum Beispiel ein bestehendes Telefonkabelnetz verwenden, welches für LAN ungeeignet wäre. Ebendiese kleineren Controller können über eine Bridge hinweg via IP-Protokoll erreicht werden, zumindest über UDP und ICMP. Eine TCP/IP-Übertragung scheitert an den begrenzten Resourcen eines ATmega8, mit größeren Controllern ist jedoch auch TCP möglich. Als Bridge kann wahlweise ein entsprechend konfiguriertes Ethersex oder ein normaler Rechner mit serieller Schnittstelle, auf dem [[ZBus Serial Host_(Deutsch) | ZBus Serial Host]] läuft, eingesetzt werden. == Anschluss == [[File:ZBUS_bias_term.JPG|thumb|right|ATMega8 mit ZBUS]] ==== prozessorseitige Beschaltung ==== Zur Anschaltung des ZBus wird ein Pegelwandler benötigt. Dabei wird an dieser Stelle ein preiswerter und moderner MAX485 verwendet, welcher sich durch minimale Außenbeschaltung und geringen Eigenstromverbrauch (etwa 1mA) auszeichnet. Damit ist zwar nur Halbduplexbetrieb möglich, was jedoch in den allermeisten Fällen genügt. Es werden drei Prozessorpins benötigt: TX, RX sowie die TX/RX-Umschaltung. ==== busseitige Beschaltung ==== Der Bus muss an beiden Enden mit 120 Ohm terminiert werden (R1) und sollte an einer Stelle mit Bias-Widerständen (R2 und R3) bestückt sein, damit definierte Pegel herrschen, wenn kein Sender aktiv ist. Diese beiden identischen Widerstände sind unkritisch; Werte zwischen 390 und 820 Ohm funktionieren problemlos. Es kann daher Busteilnehmer mit einem, zwei oder drei Widerständen geben; der flexibelste Busteilnehmer hat alle Widerstände mit Jumper aktivierbar. == Konfiguration == todo == Statusmonitor == Der ECMD-Befehl "zbus stats" ermöglicht die schnelle Beurteilung der Übertragungsqualität. Aktiviert wird er über das ZBus-debug-flag im Menuconfig. Die beispielhafte Ausgabe bedeutet im Einzelnen: '''fe=2, ov=0, pe=0, bf=0, #=57736, tx #=45264''' {| border='1' | ''Wert'' | ''Beschreibung'' |- | rx fe | frame error |- | rx ov | overflow |- | rx pe | parity error |- | rx bf | buffer full |- | # | Summe empfangene Bytes |- | tx # | Summe gesendete Bytes |- |} == Hinweise / Praktische Erfahrungen == * unterschiedliche Kabelarten sind zu vermeiden, da sich durch Stoßstellen die Signalqualität verschlechtert (Reflexionen); "fe" steigt * eine Datenrate von 38,4 kbit/s erzielte die besten Ergebnisse; eine geringere Geschwindigkeit bringt bei schlechterer Signalqualität praktisch keine Verbesserung * bei zu hoher Geschwindigkeit (hier 76,8 kbit/s auf Mega32@16MHz am ZBus-Gateway) kommt es zum Pufferüberlauf; "bf" steigt deutlich bei hohem Datenaufkommen * die Masseverbindung sollte mitgeführt werden; eine Versorgungsspannung wird als abgesicherte Rohspannung (12V) ebenfalls am Bus zur Versorgung der Devices bereitgestellt * ein [[ZBus_Testboard_(Deutsch) | Testboard]] stellt zum Beispiel für diese Methode eine Minimalvariante dar; basierend auf ATMega328 (Arduino Pro Mini) mit Keramikresonator, Längsregler 7805 und MAX485 [[Category:Hardware]] 4a421561d6cc80fcda77eaa394461db7983378e4 1486 1485 2015-01-24T17:13:37Z Kpwg 721 wikitext text/x-wiki {{i18n|ZBus}} {{Module |NAME=ZBUS |MENUCONFIG=Network->ZBUS Support |STATUS={{stable}} |PINNING= - |ECMD={{has_ecmd}} |CONTROL6= - |DEPENDS=[[ECMD]] |REQUIRES= USART |TIMER= - |CODE=[https://github.com/ethersex/ethersex/tree/master/protocols/zbus https://github.com/ethersex/ethersex/tree/master/protocols/zbus] }} == Was ist ZBus? == ZBus ist ein auf [[wikipedia:RS485|RS485]] basierendes Zweidraht-Bussystem, auf welchem Pakete variabler Länge übermittelt werden können. Es wurde primär für die Datenübertragung zwischen Mikrocontrollern konzipiert, zum Beispiel zur Kommunikation von ATmega8 und ATmega644. Ethersex verwendet ZBus zur Übermittlung von IP-Paketen von einem Controller, der als Bridge fungiert, hin zu einzelnen kleineren ZBus-Geräten, die beispielsweise auf ATmega8 basieren. Der Einsatz von ZBus ermöglicht den großflächigen Einsatz von kleineren ATmega-Mikrocontrolleren, an die man in der Regel keinen ENC28J60 anschließen möchte. Zudem lässt sich zum Beispiel ein bestehendes Telefonkabelnetz verwenden, welches für LAN ungeeignet wäre. Ebendiese kleineren Controller können über eine Bridge hinweg via IP-Protokoll erreicht werden, zumindest über UDP und ICMP. Eine TCP/IP-Übertragung scheitert an den begrenzten Resourcen eines ATmega8, mit größeren Controllern ist jedoch auch TCP möglich. Als Bridge kann wahlweise ein entsprechend konfiguriertes Ethersex oder ein normaler Rechner mit serieller Schnittstelle, auf dem [[ZBus Serial Host_(Deutsch) | ZBus Serial Host]] läuft, eingesetzt werden. == Anschluss == [[File:ZBUS_bias_term.JPG|thumb|right|ATMega8 mit ZBUS]] ==== prozessorseitige Beschaltung ==== Zur Anschaltung des ZBus wird ein Pegelwandler benötigt. Dabei wird an dieser Stelle ein preiswerter und moderner MAX485 verwendet, welcher sich durch minimale Außenbeschaltung und geringen Eigenstromverbrauch (etwa 1mA) auszeichnet. Damit ist zwar nur Halbduplexbetrieb möglich, was jedoch in den allermeisten Fällen genügt. Es werden drei Prozessorpins benötigt: TX, RX sowie die TX/RX-Umschaltung. ==== busseitige Beschaltung ==== Der Bus muss an beiden Enden mit 120 Ohm terminiert werden (R1) und sollte an einer Stelle mit Bias-Widerständen (R2 und R3) bestückt sein, damit definierte Pegel herrschen, wenn kein Sender aktiv ist. Diese beiden identischen Widerstände sind unkritisch; Werte zwischen 390 und 820 Ohm funktionieren problemlos. Es kann daher Busteilnehmer mit einem, zwei oder drei Widerständen geben; der flexibelste Busteilnehmer hat alle Widerstände mit Jumper aktivierbar. == Konfiguration == todo == Statusmonitor == Der ECMD-Befehl "zbus stats" ermöglicht die schnelle Beurteilung der Übertragungsqualität. Aktiviert wird er über das Debug-flag "ZBUS ecmd" im Menuconfig. Die beispielhafte Ausgabe bedeutet im Einzelnen: '''fe=2, ov=0, pe=0, bf=0, #=57736, tx #=45264''' {| border='1' | ''Wert'' | ''Beschreibung'' |- | rx fe | frame error |- | rx ov | overflow |- | rx pe | parity error |- | rx bf | buffer full |- | # | Summe empfangene Bytes |- | tx # | Summe gesendete Bytes |- |} == Hinweise / Praktische Erfahrungen == * unterschiedliche Kabelarten sind zu vermeiden, da sich durch Stoßstellen die Signalqualität verschlechtert (Reflexionen); "fe" steigt * eine Datenrate von 38,4 kbit/s erzielte die besten Ergebnisse; eine geringere Geschwindigkeit bringt bei schlechterer Signalqualität praktisch keine Verbesserung * bei zu hoher Geschwindigkeit (hier 76,8 kbit/s auf Mega32@16MHz am ZBus-Gateway) kommt es zum Pufferüberlauf; "bf" steigt deutlich bei hohem Datenaufkommen * die Masseverbindung sollte mitgeführt werden; eine Versorgungsspannung wird als abgesicherte Rohspannung (12V) ebenfalls am Bus zur Versorgung der Devices bereitgestellt * ein [[ZBus_Testboard_(Deutsch) | Testboard]] stellt zum Beispiel für diese Methode eine Minimalvariante dar; basierend auf ATMega328 (Arduino Pro Mini) mit Keramikresonator, Längsregler 7805 und MAX485 [[Category:Hardware]] 54b340bf04ac592980bf4f797fe42fcabc7a25e8 1493 1486 2015-01-25T16:55:39Z Kpwg 721 /* Anschluss */ wikitext text/x-wiki {{i18n|ZBus}} {{Module |NAME=ZBUS |MENUCONFIG=Network->ZBUS Support |STATUS={{stable}} |PINNING= - |ECMD={{has_ecmd}} |CONTROL6= - |DEPENDS=[[ECMD]] |REQUIRES= USART |TIMER= - |CODE=[https://github.com/ethersex/ethersex/tree/master/protocols/zbus https://github.com/ethersex/ethersex/tree/master/protocols/zbus] }} == Was ist ZBus? == ZBus ist ein auf [[wikipedia:RS485|RS485]] basierendes Zweidraht-Bussystem, auf welchem Pakete variabler Länge übermittelt werden können. Es wurde primär für die Datenübertragung zwischen Mikrocontrollern konzipiert, zum Beispiel zur Kommunikation von ATmega8 und ATmega644. Ethersex verwendet ZBus zur Übermittlung von IP-Paketen von einem Controller, der als Bridge fungiert, hin zu einzelnen kleineren ZBus-Geräten, die beispielsweise auf ATmega8 basieren. Der Einsatz von ZBus ermöglicht den großflächigen Einsatz von kleineren ATmega-Mikrocontrolleren, an die man in der Regel keinen ENC28J60 anschließen möchte. Zudem lässt sich zum Beispiel ein bestehendes Telefonkabelnetz verwenden, welches für LAN ungeeignet wäre. Ebendiese kleineren Controller können über eine Bridge hinweg via IP-Protokoll erreicht werden, zumindest über UDP und ICMP. Eine TCP/IP-Übertragung scheitert an den begrenzten Resourcen eines ATmega8, mit größeren Controllern ist jedoch auch TCP möglich. Als Bridge kann wahlweise ein entsprechend konfiguriertes Ethersex oder ein normaler Rechner mit serieller Schnittstelle, auf dem [[ZBus Serial Host_(Deutsch) | ZBus Serial Host]] läuft, eingesetzt werden. == Anschluss == [[File:ZBUS_bias_term.JPG|thumb|right|ATMega8 mit ZBUS]] [[File:Zbus_ttl.jpg|thumb|right|TTL-ZBus-Adapter mit MAX485, Termination und Bias-Widerständen]] ==== prozessorseitige Beschaltung ==== Zur Anschaltung des ZBus wird ein Pegelwandler benötigt. Dabei wird an dieser Stelle ein preiswerter und moderner MAX485 verwendet, welcher sich durch minimale Außenbeschaltung und geringen Eigenstromverbrauch (etwa 1mA) auszeichnet. Damit ist zwar nur Halbduplexbetrieb möglich, was jedoch in den allermeisten Fällen genügt. Es werden drei Prozessorpins benötigt: TX, RX sowie die TX/RX-Umschaltung. ==== busseitige Beschaltung ==== Der Bus muss an beiden Enden mit 120 Ohm terminiert werden (R1) und sollte an einer Stelle mit Bias-Widerständen (R2 und R3) bestückt sein, damit definierte Pegel herrschen, wenn kein Sender aktiv ist. Diese beiden identischen Widerstände sind unkritisch; Werte zwischen 390 und 820 Ohm funktionieren problemlos. Es kann daher Busteilnehmer mit einem, zwei oder drei Widerständen geben; der flexibelste Busteilnehmer hat alle Widerstände mit Jumper aktivierbar. == Konfiguration == todo == Statusmonitor == Der ECMD-Befehl "zbus stats" ermöglicht die schnelle Beurteilung der Übertragungsqualität. Aktiviert wird er über das Debug-flag "ZBUS ecmd" im Menuconfig. Die beispielhafte Ausgabe bedeutet im Einzelnen: '''fe=2, ov=0, pe=0, bf=0, #=57736, tx #=45264''' {| border='1' | ''Wert'' | ''Beschreibung'' |- | rx fe | frame error |- | rx ov | overflow |- | rx pe | parity error |- | rx bf | buffer full |- | # | Summe empfangene Bytes |- | tx # | Summe gesendete Bytes |- |} == Hinweise / Praktische Erfahrungen == * unterschiedliche Kabelarten sind zu vermeiden, da sich durch Stoßstellen die Signalqualität verschlechtert (Reflexionen); "fe" steigt * eine Datenrate von 38,4 kbit/s erzielte die besten Ergebnisse; eine geringere Geschwindigkeit bringt bei schlechterer Signalqualität praktisch keine Verbesserung * bei zu hoher Geschwindigkeit (hier 76,8 kbit/s auf Mega32@16MHz am ZBus-Gateway) kommt es zum Pufferüberlauf; "bf" steigt deutlich bei hohem Datenaufkommen * die Masseverbindung sollte mitgeführt werden; eine Versorgungsspannung wird als abgesicherte Rohspannung (12V) ebenfalls am Bus zur Versorgung der Devices bereitgestellt * ein [[ZBus_Testboard_(Deutsch) | Testboard]] stellt zum Beispiel für diese Methode eine Minimalvariante dar; basierend auf ATMega328 (Arduino Pro Mini) mit Keramikresonator, Längsregler 7805 und MAX485 [[Category:Hardware]] 622466dccef4f758775cf7b73954eaa8708a5780 1494 1493 2015-01-25T18:17:11Z Kpwg 721 /* Anschluss */ wikitext text/x-wiki {{i18n|ZBus}} {{Module |NAME=ZBUS |MENUCONFIG=Network->ZBUS Support |STATUS={{stable}} |PINNING= - |ECMD={{has_ecmd}} |CONTROL6= - |DEPENDS=[[ECMD]] |REQUIRES= USART |TIMER= - |CODE=[https://github.com/ethersex/ethersex/tree/master/protocols/zbus https://github.com/ethersex/ethersex/tree/master/protocols/zbus] }} == Was ist ZBus? == ZBus ist ein auf [[wikipedia:RS485|RS485]] basierendes Zweidraht-Bussystem, auf welchem Pakete variabler Länge übermittelt werden können. Es wurde primär für die Datenübertragung zwischen Mikrocontrollern konzipiert, zum Beispiel zur Kommunikation von ATmega8 und ATmega644. Ethersex verwendet ZBus zur Übermittlung von IP-Paketen von einem Controller, der als Bridge fungiert, hin zu einzelnen kleineren ZBus-Geräten, die beispielsweise auf ATmega8 basieren. Der Einsatz von ZBus ermöglicht den großflächigen Einsatz von kleineren ATmega-Mikrocontrolleren, an die man in der Regel keinen ENC28J60 anschließen möchte. Zudem lässt sich zum Beispiel ein bestehendes Telefonkabelnetz verwenden, welches für LAN ungeeignet wäre. Ebendiese kleineren Controller können über eine Bridge hinweg via IP-Protokoll erreicht werden, zumindest über UDP und ICMP. Eine TCP/IP-Übertragung scheitert an den begrenzten Resourcen eines ATmega8, mit größeren Controllern ist jedoch auch TCP möglich. Als Bridge kann wahlweise ein entsprechend konfiguriertes Ethersex oder ein normaler Rechner mit serieller Schnittstelle, auf dem [[ZBus Serial Host_(Deutsch) | ZBus Serial Host]] läuft, eingesetzt werden. == Anschluss == [[File:ZBUS_bias_term.JPG|thumb|right|ATMega8 mit ZBUS]] [[File:Zbus_ttl.jpg|thumb|right|TTL-ZBus-Adapter mit MAX485, Terminierung und Bias-R's]] ==== prozessorseitige Beschaltung ==== Zur Anschaltung des ZBus wird ein Pegelwandler benötigt. Dabei wird an dieser Stelle ein preiswerter und moderner MAX485 verwendet, welcher sich durch minimale Außenbeschaltung und geringen Eigenstromverbrauch (etwa 1mA) auszeichnet. Damit ist zwar nur Halbduplexbetrieb möglich, was jedoch in den allermeisten Fällen genügt. Es werden drei Prozessorpins benötigt: TX, RX sowie die TX/RX-Umschaltung. ==== busseitige Beschaltung ==== Der Bus muss an beiden Enden mit 120 Ohm terminiert werden (R1) und sollte an einer Stelle mit Bias-Widerständen (R2 und R3) bestückt sein, damit definierte Pegel herrschen, wenn kein Sender aktiv ist. Diese beiden identischen Widerstände sind unkritisch; Werte zwischen 390 und 820 Ohm funktionieren problemlos. Es kann daher Busteilnehmer mit einem, zwei oder drei Widerständen geben; der flexibelste Busteilnehmer hat alle Widerstände mit Jumper aktivierbar. == Konfiguration == todo == Statusmonitor == Der ECMD-Befehl "zbus stats" ermöglicht die schnelle Beurteilung der Übertragungsqualität. Aktiviert wird er über das Debug-flag "ZBUS ecmd" im Menuconfig. Die beispielhafte Ausgabe bedeutet im Einzelnen: '''fe=2, ov=0, pe=0, bf=0, #=57736, tx #=45264''' {| border='1' | ''Wert'' | ''Beschreibung'' |- | rx fe | frame error |- | rx ov | overflow |- | rx pe | parity error |- | rx bf | buffer full |- | # | Summe empfangene Bytes |- | tx # | Summe gesendete Bytes |- |} == Hinweise / Praktische Erfahrungen == * unterschiedliche Kabelarten sind zu vermeiden, da sich durch Stoßstellen die Signalqualität verschlechtert (Reflexionen); "fe" steigt * eine Datenrate von 38,4 kbit/s erzielte die besten Ergebnisse; eine geringere Geschwindigkeit bringt bei schlechterer Signalqualität praktisch keine Verbesserung * bei zu hoher Geschwindigkeit (hier 76,8 kbit/s auf Mega32@16MHz am ZBus-Gateway) kommt es zum Pufferüberlauf; "bf" steigt deutlich bei hohem Datenaufkommen * die Masseverbindung sollte mitgeführt werden; eine Versorgungsspannung wird als abgesicherte Rohspannung (12V) ebenfalls am Bus zur Versorgung der Devices bereitgestellt * ein [[ZBus_Testboard_(Deutsch) | Testboard]] stellt zum Beispiel für diese Methode eine Minimalvariante dar; basierend auf ATMega328 (Arduino Pro Mini) mit Keramikresonator, Längsregler 7805 und MAX485 [[Category:Hardware]] 4486ddfd5a78bb6b7837a53b9aabfa4923116bcf 1495 1494 2015-01-30T18:47:08Z Kpwg 721 /* Hinweise / Praktische Erfahrungen */ wikitext text/x-wiki {{i18n|ZBus}} {{Module |NAME=ZBUS |MENUCONFIG=Network->ZBUS Support |STATUS={{stable}} |PINNING= - |ECMD={{has_ecmd}} |CONTROL6= - |DEPENDS=[[ECMD]] |REQUIRES= USART |TIMER= - |CODE=[https://github.com/ethersex/ethersex/tree/master/protocols/zbus https://github.com/ethersex/ethersex/tree/master/protocols/zbus] }} == Was ist ZBus? == ZBus ist ein auf [[wikipedia:RS485|RS485]] basierendes Zweidraht-Bussystem, auf welchem Pakete variabler Länge übermittelt werden können. Es wurde primär für die Datenübertragung zwischen Mikrocontrollern konzipiert, zum Beispiel zur Kommunikation von ATmega8 und ATmega644. Ethersex verwendet ZBus zur Übermittlung von IP-Paketen von einem Controller, der als Bridge fungiert, hin zu einzelnen kleineren ZBus-Geräten, die beispielsweise auf ATmega8 basieren. Der Einsatz von ZBus ermöglicht den großflächigen Einsatz von kleineren ATmega-Mikrocontrolleren, an die man in der Regel keinen ENC28J60 anschließen möchte. Zudem lässt sich zum Beispiel ein bestehendes Telefonkabelnetz verwenden, welches für LAN ungeeignet wäre. Ebendiese kleineren Controller können über eine Bridge hinweg via IP-Protokoll erreicht werden, zumindest über UDP und ICMP. Eine TCP/IP-Übertragung scheitert an den begrenzten Resourcen eines ATmega8, mit größeren Controllern ist jedoch auch TCP möglich. Als Bridge kann wahlweise ein entsprechend konfiguriertes Ethersex oder ein normaler Rechner mit serieller Schnittstelle, auf dem [[ZBus Serial Host_(Deutsch) | ZBus Serial Host]] läuft, eingesetzt werden. == Anschluss == [[File:ZBUS_bias_term.JPG|thumb|right|ATMega8 mit ZBUS]] [[File:Zbus_ttl.jpg|thumb|right|TTL-ZBus-Adapter mit MAX485, Terminierung und Bias-R's]] ==== prozessorseitige Beschaltung ==== Zur Anschaltung des ZBus wird ein Pegelwandler benötigt. Dabei wird an dieser Stelle ein preiswerter und moderner MAX485 verwendet, welcher sich durch minimale Außenbeschaltung und geringen Eigenstromverbrauch (etwa 1mA) auszeichnet. Damit ist zwar nur Halbduplexbetrieb möglich, was jedoch in den allermeisten Fällen genügt. Es werden drei Prozessorpins benötigt: TX, RX sowie die TX/RX-Umschaltung. ==== busseitige Beschaltung ==== Der Bus muss an beiden Enden mit 120 Ohm terminiert werden (R1) und sollte an einer Stelle mit Bias-Widerständen (R2 und R3) bestückt sein, damit definierte Pegel herrschen, wenn kein Sender aktiv ist. Diese beiden identischen Widerstände sind unkritisch; Werte zwischen 390 und 820 Ohm funktionieren problemlos. Es kann daher Busteilnehmer mit einem, zwei oder drei Widerständen geben; der flexibelste Busteilnehmer hat alle Widerstände mit Jumper aktivierbar. == Konfiguration == todo == Statusmonitor == Der ECMD-Befehl "zbus stats" ermöglicht die schnelle Beurteilung der Übertragungsqualität. Aktiviert wird er über das Debug-flag "ZBUS ecmd" im Menuconfig. Die beispielhafte Ausgabe bedeutet im Einzelnen: '''fe=2, ov=0, pe=0, bf=0, #=57736, tx #=45264''' {| border='1' | ''Wert'' | ''Beschreibung'' |- | rx fe | frame error |- | rx ov | overflow |- | rx pe | parity error |- | rx bf | buffer full |- | # | Summe empfangene Bytes |- | tx # | Summe gesendete Bytes |- |} == Hinweise / Praktische Erfahrungen == * unterschiedliche Kabelarten sind zu vermeiden, da sich durch Stoßstellen die Signalqualität verschlechtert (Reflexionen); "fe" steigt * die Beschaltung der Terminierung und der Bias-R's muss experimentell ermittelt werden- hier sind deutliche Qualitätssteigerungen möglich * "Network Buffer Size" sollte maximiert werden; vor allem beim ZBus-LAN-Gateway (m328p=384, m32=500, m644p=1500) hilft viel Speicher * eine Datenrate von 38,4 kbit/s erzielte hier die besten Ergebnisse; eine geringere Geschwindigkeit bringt bei schlechterer Signalqualität praktisch keine Verbesserung * bei zu hoher Geschwindigkeit (hier 76,8 kbit/s auf Mega32@16MHz am ZBus-Gateway) kommt es zum Pufferüberlauf; "bf" steigt deutlich bei hohem Datenaufkommen * ein Mega644p@16MHz mit buffers=1500 läuft problemlos mit 115,2 kbit/s, sofern die anderen Busteilnehmer mitspielen * die Masseverbindung sollte mitgeführt werden; eine Versorgungsspannung wird als abgesicherte Rohspannung (12V) ebenfalls am Bus zur Versorgung der Devices bereitgestellt * ein [[ZBus_Testboard_(Deutsch) | Testboard]] stellt zum Beispiel für diese Methode eine Minimalvariante dar; basierend auf ATMega328 (Arduino Pro Mini) mit Keramikresonator, Längsregler 7805 und MAX485 [[Category:Hardware]] 33c4e6302c8bc7bef5b7716795d1bb4bbbd05ca5 1497 1495 2015-01-31T12:49:09Z Kpwg 721 Bild hinzugefügt wikitext text/x-wiki {{i18n|ZBus}} {{Module |NAME=ZBUS |MENUCONFIG=Network->ZBUS Support |STATUS={{stable}} |PINNING= - |ECMD={{has_ecmd}} |CONTROL6= - |DEPENDS=[[ECMD]] |REQUIRES= USART |TIMER= - |CODE=[https://github.com/ethersex/ethersex/tree/master/protocols/zbus https://github.com/ethersex/ethersex/tree/master/protocols/zbus] }} == Was ist ZBus? == ZBus ist ein auf [[wikipedia:RS485|RS485]] basierendes Zweidraht-Bussystem, auf welchem Pakete variabler Länge übermittelt werden können. Es wurde primär für die Datenübertragung zwischen Mikrocontrollern konzipiert, zum Beispiel zur Kommunikation von ATmega8 und ATmega644. Ethersex verwendet ZBus zur Übermittlung von IP-Paketen von einem Controller, der als Bridge fungiert, hin zu einzelnen kleineren ZBus-Geräten, die beispielsweise auf ATmega8 basieren. Der Einsatz von ZBus ermöglicht den großflächigen Einsatz von kleineren ATmega-Mikrocontrolleren, an die man in der Regel keinen ENC28J60 anschließen möchte. Zudem lässt sich zum Beispiel ein bestehendes Telefonkabelnetz verwenden, welches für LAN ungeeignet wäre. Ebendiese kleineren Controller können über eine Bridge hinweg via IP-Protokoll erreicht werden, zumindest über UDP und ICMP. Eine TCP/IP-Übertragung scheitert an den begrenzten Resourcen eines ATmega8, mit größeren Controllern ist jedoch auch TCP möglich. Als Bridge kann wahlweise ein entsprechend konfiguriertes Ethersex oder ein normaler Rechner mit serieller Schnittstelle, auf dem [[ZBus Serial Host_(Deutsch) | ZBus Serial Host]] läuft, eingesetzt werden. == Anschluss == [[File:ZBUS_bias_term.JPG|thumb|right|ATMega8 mit ZBUS]] [[File:Zbus_ttl.jpg|thumb|right|TTL-ZBus-Adapter mit MAX485, Terminierung und Bias-R's]] ==== prozessorseitige Beschaltung ==== Zur Anschaltung des ZBus wird ein Pegelwandler benötigt. Dabei wird an dieser Stelle ein preiswerter und moderner MAX485 verwendet, welcher sich durch minimale Außenbeschaltung und geringen Eigenstromverbrauch (etwa 1mA) auszeichnet. Damit ist zwar nur Halbduplexbetrieb möglich, was jedoch in den allermeisten Fällen genügt. Es werden drei Prozessorpins benötigt: TX, RX sowie die TX/RX-Umschaltung. ==== busseitige Beschaltung ==== Der Bus muss an beiden Enden mit 120 Ohm terminiert werden (R1) und sollte an einer Stelle mit Bias-Widerständen (R2 und R3) bestückt sein, damit definierte Pegel herrschen, wenn kein Sender aktiv ist. Diese beiden identischen Widerstände sind unkritisch; Werte zwischen 390 und 820 Ohm funktionieren problemlos. Es kann daher Busteilnehmer mit einem, zwei oder drei Widerständen geben; der flexibelste Busteilnehmer hat alle Widerstände mit Jumper aktivierbar. == Konfiguration == todo == Statusmonitor == Der ECMD-Befehl "zbus stats" ermöglicht die schnelle Beurteilung der Übertragungsqualität. Aktiviert wird er über das Debug-flag "ZBUS ecmd" im Menuconfig. Die beispielhafte Ausgabe bedeutet im Einzelnen: '''fe=2, ov=0, pe=0, bf=0, #=57736, tx #=45264''' {| border='1' | ''Wert'' | ''Beschreibung'' |- | rx fe | frame error |- | rx ov | overflow |- | rx pe | parity error |- | rx bf | buffer full |- | # | Summe empfangene Bytes |- | tx # | Summe gesendete Bytes |- |} == Hinweise / Praktische Erfahrungen == [[File:ZBus_Test.jpg|thumb|right|ZBus Testumgebung mit Gateway und Client]] * unterschiedliche Kabelarten sind zu vermeiden, da sich durch Stoßstellen die Signalqualität verschlechtert (Reflexionen); "fe" steigt * die Beschaltung der Terminierung und der Bias-R's muss experimentell ermittelt werden- hier sind deutliche Qualitätssteigerungen möglich * "Network Buffer Size" sollte maximiert werden; vor allem beim ZBus-LAN-Gateway (m328p=384, m32=500, m644p=1500) hilft viel Speicher * eine Datenrate von 38,4 kbit/s erzielte hier die besten Ergebnisse; eine geringere Geschwindigkeit bringt bei schlechterer Signalqualität praktisch keine Verbesserung * bei zu hoher Geschwindigkeit (hier 76,8 kbit/s auf Mega32@16MHz am ZBus-Gateway) kommt es zum Pufferüberlauf; "bf" steigt deutlich bei hohem Datenaufkommen * ein Mega644p@16MHz mit buffers=1500 läuft problemlos mit 115,2 kbit/s, sofern die anderen Busteilnehmer mitspielen * die Masseverbindung sollte mitgeführt werden; eine Versorgungsspannung wird als abgesicherte Rohspannung (12V) ebenfalls am Bus zur Versorgung der Devices bereitgestellt * ein [[ZBus_Testboard_(Deutsch) | Testboard]] stellt zum Beispiel für diese Methode eine Minimalvariante dar; basierend auf ATMega328 (Arduino Pro Mini) mit Keramikresonator, Längsregler 7805 und MAX485 [[Category:Hardware]] 528050c0e4b55ff9ef1e1c465b807a9f94c23112 1498 1497 2015-02-01T07:23:56Z Kpwg 721 /* Hinweise / Praktische Erfahrungen */ wikitext text/x-wiki {{i18n|ZBus}} {{Module |NAME=ZBUS |MENUCONFIG=Network->ZBUS Support |STATUS={{stable}} |PINNING= - |ECMD={{has_ecmd}} |CONTROL6= - |DEPENDS=[[ECMD]] |REQUIRES= USART |TIMER= - |CODE=[https://github.com/ethersex/ethersex/tree/master/protocols/zbus https://github.com/ethersex/ethersex/tree/master/protocols/zbus] }} == Was ist ZBus? == ZBus ist ein auf [[wikipedia:RS485|RS485]] basierendes Zweidraht-Bussystem, auf welchem Pakete variabler Länge übermittelt werden können. Es wurde primär für die Datenübertragung zwischen Mikrocontrollern konzipiert, zum Beispiel zur Kommunikation von ATmega8 und ATmega644. Ethersex verwendet ZBus zur Übermittlung von IP-Paketen von einem Controller, der als Bridge fungiert, hin zu einzelnen kleineren ZBus-Geräten, die beispielsweise auf ATmega8 basieren. Der Einsatz von ZBus ermöglicht den großflächigen Einsatz von kleineren ATmega-Mikrocontrolleren, an die man in der Regel keinen ENC28J60 anschließen möchte. Zudem lässt sich zum Beispiel ein bestehendes Telefonkabelnetz verwenden, welches für LAN ungeeignet wäre. Ebendiese kleineren Controller können über eine Bridge hinweg via IP-Protokoll erreicht werden, zumindest über UDP und ICMP. Eine TCP/IP-Übertragung scheitert an den begrenzten Resourcen eines ATmega8, mit größeren Controllern ist jedoch auch TCP möglich. Als Bridge kann wahlweise ein entsprechend konfiguriertes Ethersex oder ein normaler Rechner mit serieller Schnittstelle, auf dem [[ZBus Serial Host_(Deutsch) | ZBus Serial Host]] läuft, eingesetzt werden. == Anschluss == [[File:ZBUS_bias_term.JPG|thumb|right|ATMega8 mit ZBUS]] [[File:Zbus_ttl.jpg|thumb|right|TTL-ZBus-Adapter mit MAX485, Terminierung und Bias-R's]] ==== prozessorseitige Beschaltung ==== Zur Anschaltung des ZBus wird ein Pegelwandler benötigt. Dabei wird an dieser Stelle ein preiswerter und moderner MAX485 verwendet, welcher sich durch minimale Außenbeschaltung und geringen Eigenstromverbrauch (etwa 1mA) auszeichnet. Damit ist zwar nur Halbduplexbetrieb möglich, was jedoch in den allermeisten Fällen genügt. Es werden drei Prozessorpins benötigt: TX, RX sowie die TX/RX-Umschaltung. ==== busseitige Beschaltung ==== Der Bus muss an beiden Enden mit 120 Ohm terminiert werden (R1) und sollte an einer Stelle mit Bias-Widerständen (R2 und R3) bestückt sein, damit definierte Pegel herrschen, wenn kein Sender aktiv ist. Diese beiden identischen Widerstände sind unkritisch; Werte zwischen 390 und 820 Ohm funktionieren problemlos. Es kann daher Busteilnehmer mit einem, zwei oder drei Widerständen geben; der flexibelste Busteilnehmer hat alle Widerstände mit Jumper aktivierbar. == Konfiguration == todo == Statusmonitor == Der ECMD-Befehl "zbus stats" ermöglicht die schnelle Beurteilung der Übertragungsqualität. Aktiviert wird er über das Debug-flag "ZBUS ecmd" im Menuconfig. Die beispielhafte Ausgabe bedeutet im Einzelnen: '''fe=2, ov=0, pe=0, bf=0, #=57736, tx #=45264''' {| border='1' | ''Wert'' | ''Beschreibung'' |- | rx fe | frame error |- | rx ov | overflow |- | rx pe | parity error |- | rx bf | buffer full |- | # | Summe empfangene Bytes |- | tx # | Summe gesendete Bytes |- |} == Hinweise / Praktische Erfahrungen == [[File:ZBus_Test.jpg|thumb|right|ZBus Testumgebung mit Gateway und Client]] * unterschiedliche Kabelarten sind zu vermeiden, da sich durch Stoßstellen die Signalqualität verschlechtert (Reflexionen); "fe" steigt * die Beschaltung der Terminierung und der Bias-R's muss experimentell ermittelt werden- hier sind deutliche Qualitätssteigerungen möglich * "Network Buffer Size" sollte maximiert werden; vor allem beim ZBus-LAN-Gateway hilft viel Speicher bzw. ein größerer Controller (m328p=384, m32=500, m644p=1500) * eine Datenrate von 38,4 kbit/s erzielte hier die besten Ergebnisse; eine geringere Geschwindigkeit bringt bei schlechterer Signalqualität praktisch keine Verbesserung * bei zu hoher Geschwindigkeit (hier 76,8 kbit/s auf Mega32@16MHz am ZBus-Gateway) kommt es zum Pufferüberlauf; "bf" steigt deutlich bei hohem Datenaufkommen * ein Mega644p@16MHz mit buffers=1500 läuft problemlos mit 115,2 kbit/s, sofern die anderen Busteilnehmer mitspielen * die Masseverbindung sollte mitgeführt werden; eine Versorgungsspannung wird als abgesicherte Rohspannung (12V) ebenfalls am Bus zur Versorgung der Devices bereitgestellt * ein [[ZBus_Testboard_(Deutsch) | ZBus-Testboard]] stellt zum Beispiel eine Minimalvariante dar; basierend auf ATMega328 (Arduino Pro Mini) mit Keramikresonator, Längsregler 7805 und MAX485 [[Category:Hardware]] 667f157019174dfa21cf6a8f7137bb5a817ebaee 6 458 1487 1429 2015-01-25T10:46:30Z Kpwg 721 Kpwg uploaded a new version of &quot;[[File:Zbus testboard.jpg]]&quot;: updated with onewire and zbus status LED's wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 478 1488 2015-01-25T10:48:09Z Kpwg 721 top view wikitext text/x-wiki top view 6c82692decc048b8dda55755047900188d35d208 6 479 1489 2015-01-25T10:49:29Z Kpwg 721 bottom view wikitext text/x-wiki bottom view 0edffffba4fb0881551b858e17f23de2f919dd6e 0 460 1490 1450 2015-01-25T10:53:31Z Kpwg 721 wikitext text/x-wiki {{i18n|ZBus Testboard}} '''Wofür?''' * Hiermit lassen sich Versuche mit [http://de.wikipedia.org/wiki/EIA-485 RS485] und [[ZBus_(Deutsch) | ZBus]] durchführen, um die Machbarkeit diverser Vorhaben abzuschätzen '''Ausstattung''' * Arduino ProMini Clone (hier das [http://arduino.cc/en/pmwiki.php?n=Main/ArduinoBoardProMini Original]) * MAX485 als Pegelwandler * per Jumper aktivierbare Terminierung * Verpolschutzdiode, separater Spannungsregler für MAX485 und Test-Peripherie * Status-LEDs für ZBus TX/RX * ein DS18B20 Temperatursensor, damit es auch was zu messen gibt * 6pol. ISP-Stecker '''Vorteile''' * sehr einfacher, schneller und preiswerter Aufbau (<6 Euro) * hohe Flexibilität bei Peripherie und Platzierung innerhalb des Busses * weiter Betriebsspannungsbereich '''Bilder''' <gallery> Zbus_testboard.jpg|Gesamtansicht Zbus_testboard2.jpg|Ansicht von oben Zbus_testboard3.jpg|Ansicht von unten </gallery> [[Category:Hardware]] 2cab54644599989d534a9005ecb2ca47417b7550 1499 1490 2015-02-01T07:38:49Z Kpwg 721 Ergänzungen wikitext text/x-wiki {{i18n|ZBus Testboard}} '''Wofür?''' * Hiermit lassen sich Versuche mit [http://de.wikipedia.org/wiki/EIA-485 RS485] und [[ZBus_(Deutsch) | ZBus]] durchführen, um die Machbarkeit diverser Vorhaben abzuschätzen '''Ausstattung''' * Arduino ProMini Clone (hier das [http://arduino.cc/en/pmwiki.php?n=Main/ArduinoBoardProMini Original]) * MAX485 als Pegelwandler * per Jumper aktivierbare Terminierung * Verpolschutzdiode, separater Spannungsregler für MAX485 und Test-Peripherie * Status-LEDs für ZBus TX/RX * ein DS18B20 Temperatursensor, damit es auch was zu messen gibt * 6pol. ISP-Stecker '''praktische Eigenschaften''' * sehr einfacher, schneller und preiswerter Aufbau (<6 Euro; Recycling aus der Bastelkiste) * hohe Flexibilität bei Peripherie und Platzierung innerhalb des Busses * weiter Betriebsspannungsbereich * bester Datendurchsatz mit 38,4 kbit/s bei ECMD (buffers=384) * 20-25mA Stromaufnahme an 12V '''Bilder''' <gallery> Zbus_testboard.jpg|Gesamtansicht Zbus_testboard2.jpg|Ansicht von oben Zbus_testboard3.jpg|Ansicht von unten </gallery> [[Category:Hardware]] a2cb986a09ac7fcdfef9dd7b02069d69c193d6ff 1 480 1491 2015-01-25T16:27:24Z GooPie4o 265 Created page with "Schaltung?" wikitext text/x-wiki Schaltung? bcef95a2ad08dfd6d6fad5d5bb1cc512e3ef8aee 6 481 1492 2015-01-25T16:46:00Z Kpwg 721 minimum zbus-ttl adapter board with configurable bias- and termination-resistors wikitext text/x-wiki minimum zbus-ttl adapter board with configurable bias- and termination-resistors caf5568c06d76b63cffb325166ce86e3fa9d1b91 6 482 1496 2015-01-31T12:45:55Z Kpwg 721 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 483 1500 2015-03-09T18:42:47Z Kpwg 721 Upgrade with ZBus wikitext text/x-wiki Upgrade with ZBus f8c7eca517bc444325389868ba803c4ba4389b66 6 484 1501 2015-03-09T18:43:39Z Kpwg 721 Upgrade with ZBus wikitext text/x-wiki Upgrade with ZBus f8c7eca517bc444325389868ba803c4ba4389b66 6 485 1502 2015-03-09T18:44:45Z Kpwg 721 LAN-ZBus-Y-cable wikitext text/x-wiki LAN-ZBus-Y-cable 6d10766f57a17382346d0ad131fcaeabc4d436ad 0 433 1503 1401 2015-03-09T18:55:02Z Kpwg 721 wikitext text/x-wiki {{i18n|FHEM Wohnzimmer}} == [[Nutzung_in_FHEM_(Deutsch)|FHEM]] Roomnode Wohnzimmer == Für diverse Mess- und Schaltaufgaben im Wohnzimmer musste ein individuelles und vorzeigbares Gerät entstehen, das diese Aufgaben übernimmt. Dabei sollen Daten über LAN an FHEM geliefert bzw. Display und Schaltaktoren mit FHEM gesteuert werden. Die wichtigsten Grundfunktionen sollen auch ohne FHEM direkt bedienbar sein. '''Ziele''' * Messung Temperatur/Feuchte im Raum * Anzeige diverser Klimadaten und Uhrzeit * Schalten eines [[RFM12_ASK_(Deutsch)#Intertechno_.28ITS-150.29|Intertechno]] Schaltaktors * Schalten einiger [[RFM12_ASK_(Deutsch)#2272|IC2272]]-Funksteckdosen (Weihnachtsbeleuchtung, etc.) * Steuerung Schrankwandbeleuchtung * Schalten eines [http://www.raspberrypi.org/ RasPi] für [http://xbmc.org/ XBMC] * Autonome Grundfunktionen ohne FHEM * vorzeigbares fertiges Gehäuse '''Ausstattung''' * [[DHT|DHT22]] mit ca. 3m Kabel * LCD 16x1 HD44780 mit extra großen Zeichen * [[RFM12_(Deutsch)|RFM12]] 433MHz mit externer Antenne * Taster mit LEDs * Schaltausgänge 12V mit PowerFET (IRLZ34) * USB-Buchse, die per Kabel den RasPi mit 5V versorgt * ATMega32 (98% Nutzung des Flash) '''Bilder''' <gallery> Fhem_wz_01.jpg|Aussenansicht (noch ohne Frontplatte) Fhem_wz_02.jpg|Platine von oben Fhem_wz_03.jpg|Stromversorgung und LAN-Modul Fhem_wz_04.jpg|Stecker Schrankwandbeleuchtung und DHT22 Fhem_wz_05.jpg|RFM12, Reed-Relais für geschaltene 5V Fhem_wz_06.jpg|zweckentfremdetes WLAN-Pigtail und 433MHz-Antenne Fhem_wz_07.jpg|Platine ohne Gehäuse für letzte Anpassungen Fhem_wz_08.jpg|Platine von unten </gallery> '''Update ZBus''' * Ersatz des Mega32 durch einen Mega644p * Einbau eines MAX485 mit Abschluss- und Bias-Widerständen sowie einer RJ10-Buchse für den ZBus-Anschluss * Fertigung eines Y-Kabels zur Übertragung des ZBus auf den ungenutzten LAN-Paaren <gallery> Fhem_wz_09.jpg|Platine mit Mega644 und MAX485 Fhem_wz_10.jpg|Rückseite mit RJ10 Buchse Fhem_wz_11.jpg|LAN-ZBus-Y-Kabel </gallery> '''Besonderheiten/Hinweise''' * das Gehäuse stammt von einem nutzlos gewordenen ELSA Lancom 800 * mit [[Control6_(Deutsch)|Control6]] und NamedPin sind die Grundfunktionen autonom bedienbar * die Stecker für die Schrankwandbeleuchtung entsprechen dem Original (Gewährleistung...) [[Category:Hardware]] 88d696773cfe220c2b046963959848dc3e4f6705 6 486 1505 2015-04-02T15:53:34Z Kpwg 721 ZBus Board; front view wikitext text/x-wiki ZBus Board; front view 72c1a9d5bdc5cca93ec9451fa4aa24d7d93f1c07 6 487 1506 2015-04-02T15:54:51Z Kpwg 721 ZBus Board; rear view wikitext text/x-wiki ZBus Board; rear view 2e3402ed0f065f7077740785af582585a247940b 6 488 1507 2015-04-02T15:56:56Z Kpwg 721 ZBus Board; mounted on a HD44780 LCD wikitext text/x-wiki ZBus Board; mounted on a HD44780 LCD e22ef23c0c6be4d4ebc0fcfb744a165df075a5c0 6 489 1508 2015-04-02T15:58:17Z Kpwg 721 ZBus Board; prepared for DHT22 wikitext text/x-wiki ZBus Board; prepared for DHT22 6e866f3cf0e64ac94ca56d1b71edebcde9204974 6 490 1509 2015-04-02T16:56:24Z Kpwg 721 ZBus Board; pcb wikitext text/x-wiki ZBus Board; pcb 516d4c6ef74a9911d8733d0f5c31344433297ca6 6 491 1510 2015-04-02T16:56:55Z Kpwg 721 ZBus Board; schematic wikitext text/x-wiki ZBus Board; schematic 4f1c58162c9c6335cd87c867974d6dcfee4be027 0 412 1511 1464 2015-04-02T17:26:35Z Kpwg 721 /* Eigenbau Hardware */ wikitext text/x-wiki {{i18n|Supported Boards}} == Kommerzielle Produkte == <gallery> Etherrape.jpg | [[Etherrape_(Deutsch) | Etherrape]] von lochraster.org Jackalope.jpg | [[Jackalope_(Deutsch) | Jackalope]] von lochraster.org Radig.jpg | [[AVR Webmodul_(Deutsch) | AVR Webmodul]] von Ulrich Radig Avr-net-io.jpg | [[AVR-NET-IO_(Deutsch) | AVR-NET-IO]] von Pollin Funk-avr-eval.jpg | [[Funk-AVR-Evaluationsboard_(Deutsch) | Funk-AVR-Evaluationsboard]] von Pollin Conrad-probot.jpg | [[Conrad Probot_(Deutsch) | Conrad Probot]] von Conrad Fimser.jpg | [[Fimser_(Deutsch) | Fimser]] vom OV Lennestadt Jeelinkv2.jpg | [[JeeLink_(Deutsch) | JeeLink]] von JeeLabs </gallery> == Eigenbau Hardware == <gallery> Fhem_wz_01.jpg | [[Nutzung_in_FHEM_(Deutsch) | FHEM]] [[FHEM_Wohnzimmer_(Deutsch) | Roomnode #1]] Fhem_ku_01.jpg | [[Nutzung_in_FHEM_(Deutsch) | FHEM]] [[FHEM_Kueche_(Deutsch) | Roomnode #2]] Fhem_ke_01.jpg | [[Nutzung_in_FHEM_(Deutsch) | FHEM]] [[FHEM_Keller_(Deutsch) | Roomnode #3]] Zbus_testboard.jpg | [[ZBus_(Deutsch)|ZBus]][[ZBus_Testboard_(Deutsch) | Testboard]] ZBus-Board 01.jpg | [[ZBus_(Deutsch)|ZBus]][[ZBus_Board_1_0_(Deutsch) | Board 1.0]] Bw_final.jpg | Bettwächter Atmega162-usb.jpg | ATmega162 mit USB Usb2zbus-i2c.jpg | USB to [[ZBus_(Deutsch) | ZBus]] Dongle Pumpensteuerung.jpg | Jochens Pumpensteuerung Ethmega.jpg | ths' ATmega64+ (SMD) Usbonly_atmega32+i2c_pcf8574_auf_steckbrett.jpg | USB-Ethersex mit [[I2C_(Deutsch) | I2C]] und Porterweiterung Chaotischer-aufbau.jpg | Pollins AVR-NET-IO und Erweiterungen Ethersex-Avrnet-GPA.jpg | Pollins AVR-NET-IO Steckdosenschaltzentrale Resetbox_proto_01.jpg | [[Resetbox_(Deutsch) | Resetbox]] Habo_bulbdial_clock.jpg | [[Bulbdial Clock_(Deutsch) | Bulbdial Clock]] Ftdi-lochraster.jpg | Atmega168p mit USB-Anschluss über FT232R Ehaserl-badge-eh2010.jpg | [[ehaserl_(Deutsch)|ehaserl]] Badge des easter(h)egg 2010 </gallery> [[Category:Ethersex]] [[Category:Hardware]] 5d2a761dddf523ea1821ef766db519a5335b0e87 0 457 1512 1465 2015-04-02T17:29:48Z Kpwg 721 /* DIY Hardware */ wikitext text/x-wiki {{i18n|Supported Boards}} == Commercial Products == <gallery> Etherrape.jpg | [[Etherrape | Etherrape]] by lochraster.org Jackalope.jpg | [[Jackalope | Jackalope]] by lochraster.org Radig.jpg | [[AVR Webmodul | AVR Webmodul]] by lrich Radig Avr-net-io.jpg | [[AVR-NET-IO | AVR-NET-IO]] by Pollin Funk-avr-eval.jpg | [[Funk-AVR-Evaluationsboard | Funk-AVR-Evaluationsboard]] by Pollin Conrad-probot.jpg | [[Conrad Probot | Conrad Probot]] by Conrad Fimser.jpg | [[Fimser | Fimser]] by OV Lennestadt Jeelinkv2.jpg | [[JeeLink | JeeLink]] by JeeLabs </gallery> == DIY Hardware == <gallery> Fhem_wz_01.jpg | [[Nutzung_in_FHEM | FHEM]] [[FHEM_Wohnzimmer | Roomnode #1]] Fhem_ku_01.jpg | [[Nutzung_in_FHEM | FHEM]] [[FHEM_Kueche | Roomnode #2]] Fhem_ke_01.jpg | [[Nutzung_in_FHEM | FHEM]] [[FHEM_Keller | Roomnode #3]] Zbus_testboard.jpg | [[ZBus|ZBus]][[ZBus_Testboard | Testboard]] ZBus-Board 01.jpg | [[ZBus|ZBus]][[ZBus_Board_1_0 | Board 1.0]] Bw_final.jpg | bed guard Atmega162-usb.jpg | ATmega162 with USB Usb2zbus-i2c.jpg | USB to [[ZBus | ZBus]] Dongle Pumpensteuerung.jpg | Jochen's pump control Ethmega.jpg | ths' ATmega64+ (SMD) Usbonly_atmega32+i2c_pcf8574_auf_steckbrett.jpg | USB-Ethersex with [[I2C| I2C]] and port extension Chaotischer-aufbau.jpg | Pollin AVR-NET-IO with add ons Ethersex-Avrnet-GPA.jpg | Pollin AVR-NET-IO based outlet control center Resetbox_proto_01.jpg | [[Resetbox | Resetbox]] Habo_bulbdial_clock.jpg | [[Bulbdial Clock | Bulbdial Clock]] Ftdi-lochraster.jpg | Atmega168p with USB connector via FT232R Ehaserl-badge-eh2010.jpg | [[ehaserl|ehaserl]] Badge des easter(h)egg 2010 </gallery> [[Category:Ethersex]] [[Category:Hardware]] 788ef02fb27d062b362369d2551cb00a150f2539 0 492 1513 2015-04-02T18:09:38Z Kpwg 721 Created page with "{{i18n|ZBus Board 1.0}} [[File:ZBus-Board_06.jpg|thumb|right|Schaltbild]] '''Motivation''' * Test eines kommerziellen Platinenherstellers mit einem preiswerten, aber sinnvolle..." wikitext text/x-wiki {{i18n|ZBus Board 1.0}} [[File:ZBus-Board_06.jpg|thumb|right|Schaltbild]] '''Motivation''' * Test eines kommerziellen Platinenherstellers mit einem preiswerten, aber sinnvollen Projekt * einseitige Platine, um auch selbst ätzen zu können; leicht verfügbare Bauteile * günstiger [[ZBus_(Deutsch) | ZBus]]-Client für kleine Aufgaben und geringsten Platzbedarf * direkte Verbindung zu einem LCD (rückseitig auflötbar) * direkte Anschaltung eines DHT22 oder I2C [[File:ZBus-Board_05.jpg|thumb|right|Platine]] '''Ausstattung''' * ATMega 328p mit 16MHz Quarz * MAX485 als Pegelwandler * Terminierung optional bestückbar * Verpolschutzdiode, kleiner Spannungsregler * Status-LEDs für ZBus TX/RX oder andere Aufgaben * 16pol. Pinreihe für direkten Anschluß eines HD44780-LCD inkl. Kontrastregler und schaltbarer Hintergrundbeleuchtung * 4pol. Pinreihe für DHT22, I2C oder Onewire * 6pol. ISP-Stecker * alle Pinreihen sind zueinander im 2.54mm-Raster, um eine Lochrasterplatine für weitere Aufgaben anlöten zu können '''Einsatzbeispiele''' * Roomnode mit LCD und abgesetztem DHT22 im schlanken Gehäuse * mit optionalem Sensorboard (Lochraster) zum Messen und Schalten '''Bilder''' <gallery> ZBus-Board_01.jpg|bestückte Platine ZBus-Board_02.jpg|Rückseite ZBus-Board_03.jpg|aufgesteckt auf HD44780-LCD ZBus-Board_04.jpg|Schnittstelle für DHT22 oder I2C </gallery> [[Category:Hardware]] 0a131c6cda8527b2f96b2f537f77cf682d68c0cb 1514 1513 2015-04-02T18:20:25Z Kpwg 721 wikitext text/x-wiki {{i18n|ZBus_Board_1_0}} [[File:ZBus-Board_06.jpg|thumb|right|Schaltbild]] '''Motivation''' * Test eines kommerziellen Platinenherstellers mit einem preiswerten, aber sinnvollen Projekt * einseitige Platine, um auch selbst ätzen zu können; leicht verfügbare Bauteile * günstiger [[ZBus_(Deutsch) | ZBus]]-Client für kleine Aufgaben und geringsten Platzbedarf * direkte Verbindung zu einem LCD (rückseitig auflötbar) * direkte Anschaltung eines DHT22 oder I2C [[File:ZBus-Board_05.jpg|thumb|right|Platine]] '''Ausstattung''' * ATMega 328p mit 16MHz Quarz * MAX485 als Pegelwandler * Terminierung optional bestückbar * Verpolschutzdiode, kleiner Spannungsregler * Status-LEDs für ZBus TX/RX oder andere Aufgaben * 16pol. Pinreihe für direkten Anschluß eines HD44780-LCD inkl. Kontrastregler und schaltbarer Hintergrundbeleuchtung * 4pol. Pinreihe für DHT22, I2C oder Onewire * 6pol. ISP-Stecker * alle Pinreihen sind zueinander im 2.54mm-Raster, um eine Lochrasterplatine für weitere Aufgaben anlöten zu können '''Einsatzbeispiele''' * Roomnode mit LCD und abgesetztem DHT22 im schlanken Gehäuse * mit optionalem Sensorboard (Lochraster) zum Messen und Schalten '''Bilder''' <gallery> ZBus-Board_01.jpg|bestückte Platine ZBus-Board_02.jpg|Rückseite ZBus-Board_03.jpg|aufgesteckt auf HD44780-LCD ZBus-Board_04.jpg|Schnittstelle für DHT22 oder I2C </gallery> [[Category:Hardware]] 34d724c74d9de1d76bbc1ab4175213d80db0e4e9 0 338 1515 1247 2015-10-11T15:42:15Z GooPie4o 265 Smoke detectors wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{Protocols}}->Radio->Radio outlets (433MHz) |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/protocols/radio/ask https://github.com/ethersex/ethersex/tree/master/protocols/radio/ask] }} In ASK mode the RFM12 module is used to switch radio outlets. Alternatively you can also receive the radio transmission between the transmitter and radio socket outlet. Currently, the following systems are supported: * Self-learning systems (drive "tevion") * Systems based on the chips or PT2262/PT2272 HX2262/2272 (driver "2272") * Concealed remote dimmer with the transmitter located HS1527 chip (driver "1527") * Transmitter type Intertechno ITS-150 * Oase Inscenio FM Master system * Flamingo FA20RF/ELRO KD101 smoke detectors == Connection == The RFM12 is connected to the AVRlike in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FFIT signal (Pin 4) is connected to one of the INT pins of the AVR. This modul does not work in interrupt mode, so the output nRQ signal (Pin 2) can be left unconnected. The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_ASK_SENSE_USE_INT(0) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_ASK_SENSE_USE_INT defines whether FFIT is connected to INT0, INT1 or INT2 of the AVR. == Configuration == | | I/O ---> | | ... | | Radio ---> | | ... | | [*] RFM12 ASK ---> | | ... | | [*] 433MHz | | | | (0) RFM12 select | | | | Protocols ---> | | ... | | Radio ---> | | | | [*] Radio outlets (433MHz) ---> | | ... | | (RFM12) Transmitter hardware | | | | [ ] Pollin/Kangtai Powerswitch (IC 2272) | | | | [ ] Pollin Powerswitch buried (IC 1527) | | | | [*] Tevion Powerswitch | | | | [ ] Intertechno ITS-150 | | | | [*] Oase FM Master | | | | [ ] Flamingo FA20RF/ELRO KD101 | | == [[ECMD]] == RFM12 ASK implements an [[ECMD]] interface to control to switch radio outlets. See [[ECMD_Reference|ECMD reference]]. [[Category:RFM12]] 8c4ce297e896a94e3af259e4c80d72fd4810a215 0 156 1516 1248 2015-10-11T15:48:17Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{Protocols}}->Radio->Radio outlets (433MHz) |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/protocols/radio/ask https://github.com/ethersex/ethersex/tree/master/protocols/radio/ask] }} RFM12 ASK schaltet Funksteckdosen verschiedener Hersteller. == Unterstützte Systeme == ===Tevion=== Funksteckdosen mit einer 'Anlern-Taste' können mit Hilfe des LERN-Buttons auf der embeded Website des etherrapes */rf.ht auf den gesendeten Hauscode programmiert werden. Erstaunlicherweise können mit diesem Modul auch die Codes der X10 Fernbedienung von Pollin gesendet werden. Eine Code-Sammlung gibts [[X10-codes|hier]]. [[Category:RFM12]] Getestet: * Tevion * MMANDOLYN LIBRA GmbH, Model No. WRC001 * X10 Pollin Best.Nr. 721 379 ===Intertechno (ITS-150)=== Bei Sender vom Typ Intertechno ITS-150 wird über einen Drehschalter auf der Rückseite der Familiencode eingestellt. Auf der Vorderseite gibt es einen Schieberegler für die Auswahl von Gruppe 1-4 sowie Ein/Aus Knöpfe für die Geräte 1-4 (siehe Bild). Die zusätzlich vorhandenen Gruppentaste funktioniert mit den Empfängern Intertechno CMR-500 nicht (deshalb nicht implementiert). [[Image:Intertechno-its150.jpg|150px]] ===2272=== Diese Steckdosen werden üblicherweise über einen Block von 10 DIP-Switches konfiguriert. Dabei wird mit den ersten fünf Schaltern der Hauscode gesetzt. Es ergeben sich also 32 mögliche Einstellungen. Die übrigen fünf Schalter geben die Adresse der Steckdose an. Bei Verwendung des mitgelieferten Senders wird jeweils einer der Adressschalter auf "1" gesetzt: In Dose A setzt man Dip 6 auf '1'; in Dose B Dip 7 auf '1'... Bei Ansteuerung mit dem Ethersex-System besteht diese Einschränkung nicht, so dass hier 32 verschiedene Adressen möglich sind. Getestet: {|class=wikitable |[http://www.elro.eu/uploads/products/img/_w200/AB440RA_1.jpg] |[[Image:Duewiaktor.jpg|134px]] |[[Image:Globusaktoren.jpg|134px]] |[[Image:Kangtai2605.jpg|101px]] |[[Image:Kangtai6899s.jpg|100px]] |- |valign=top|ELRO AB440R |valign=top|Düwi Modell 0369-3 |valign=top|Kangtai<br>v. Globus |valign=top|Kangtai<br>Model 2605 |valign=top|Kangtai<br>Model 6899s<br>[[Warnung vor Kangtai 6899s|'''Warnung!''']] |- |Delay 100 |Delay 60 |Delay 72 |Delay 72 |Delay 72 |} ====Funkleuchten lassen sich auch schalten!==== Neben den hier aufgeführten Funksteckdosen, lassen sich mit diesem Modul auch wunderbar diverse "neumodische" Funk-Leuchten, wie man sie aus Einrichtungshäusern kennt schalten. Die Fernbedienungen der Leuchten arbeiten dabei nicht mit dem 2262 Codierchip, sondern mit dem W0369DGP Codierchip. Dieser codiert genau wie der 2262 jedoch ist die Aufteilung der Codierbits (DIP-Schalter; in meinem Fall Lötbrücken) auf Hauscode und Gerätecode anders als bei den Funk Steckdosen. Die ersten 8 Codierbits sind sowohl in der Fernbedienung als auch in der Leuchte als Geräteadresse über Lötbrücken fest codiert. Dabei ist zu beachten, dass nur diese 8 Bits tri-state sind, also den Zustand "0", "1" oder "f" haben dürfen. Die weiteren 4 Bits sind die Schaltbefehle. WICHTIG: Die 4 Schalt-Bits können nur "0" oder "1" sein. === 1527 === Anlernbare Unterputz-Dimmer (zB. Pollin Funkdimmerset FD-UP003) mit Fernbedienung. Die mitgelieferte Fernbedienung besitzt einen HS1527 Encoder (baugleich RT1527/ EV1527/FP1527/SC1527). Der gesendete Code bestehtaus 24 Bits, welche per ASK gesendet werden. Davon sind die ersten 20 Bits fest programmiert - der Hauscode sozusagen. Die letzten 4 Bits sind der eigentliche Schalt-Befehl. Getestet: {|class=wikitable |[[Image:FD-UP003.jpg‎|150px|Pollin Electronic FD-UP003]] |- |valign=top|Pollin FD-UP003<br>[[Hinweis FD-UP003|'''Hinweis!''']] |} === Oase Inscenio FM Master === Das Baukastensystem für Gartensteckdosen der Serie [http://www.oase-livingwater.com/de_DE/wasser-garten/produkte/illumination-und-strom/strommanagement/inscenio.html InScenio] organisiert die gesamte Garten- und Teichtechnik. === Flamingo FA20RF/ELRO KD101 Rauchmelder === Die Rauchmelder Flamingo FA20RF, ELRO KD101 haben folgendes Verhalten: * Wenn der Sensor selbst Rauch feststellt, kann man diesen Alarm über Funk nicht stoppen. Er sendet seine ID über Funk. * Wenn man die ID über Funk an einen Rauchmelder sendet, dauert der Alarm nur wenige Sekunden. Für einen dauerhaften Alarm muss man also die ID immer wieder senden. * Wenn man die Sensoren pairt, bekommen alle gepairten Sensoren dieselbe ID. * Wenn einer Rauch erkennt, triggert er alle Sensoren mit derselben ID (also die gepairten). * Ein Sensor sendet kein Keepalive-Signal. Man kann also nur testen, ob ein Rauchmelder noch funktioniert, indem man die Test-Taste drückt. Mittels [[Ethersex]] kann man die ID an einen/eine Gruppe senden und damit für einige Sekunden einen Alarm auslösen. == Anschluss == == Konfiguration == == [[ECMD]] == RFM12 ASK implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle zur Steuerung von Funksteckdosen. Siehe [[ECMD_Reference|ECMD Referenz]]. 78daf6ef8ef1780da195f9938f5504868a708af5 2 116 1517 263 2015-10-11T16:58:07Z GooPie4o 265 Blanked the page wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 183 1518 1407 2016-01-24T13:13:41Z Djmaster 255 /* LM75 */ wikitext text/x-wiki {{i18n|I2C}} {{Module |NAME=I2C |MENUCONFIG={{I/O}}-{{I2C Master}} |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6= - |DEPENDS= - |REQUIRES= CONFIG_EXPERIMENTAL |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/i2c/master https://github.com/ethersex/ethersex/tree/master/hardware/i2c/master] }} Der I2C-Bus (Inter Integrated Circuit) ist ein einfacher Zweidraht-Bus, der für die Kommunikation zwischen ICs innerhalb eines größeren Systems verwendet wird. Insbesondere bietet er sich an zur Kommunikation zwischen Microcontrollern und Peripheriegeräten. Das [[Ethersex]]-System kann sowohl als Master als auch als Slave in einem I2C-Bus arbeiten. In der Atmel-Dokumentation wird I2C als TWI (Two Wire Interface) geführt. ==Master Mode== Im Master-Mode kann das Ethersex-System auf angeschlossene I2C-Slaves zugreifen. Unterstützt werden im Moment: * 24cXX EEPROMs (Als Storage Backend für das Virtuelle Dateisystem) * LM75 Temperatursensoren * PCA9531 8 bit LED Dimmer * PCF8574x Port Extension ==Slave Mode== * Kann per I2C auf die [[ECMD (Deutsch) | ECMD ]] Schnittstelle zugegriffen werden. * In menuconfig -> Protocols -> ECMD -> I2C aktivieren [[I2C/Slave Example (Deutsch) | Beispielimplementierung]] mit Ethersex (Slave) und einem zweiten AVR (Master). ==Anschluss== Die Leitungen SCL (Clock) und SDA (Data) liegen als "Alternate Function" auf I/O Leitungen der Controller. Beim ATmega32 sind dies PC0 (SCL) und PC1 (SDA). ===Etherrape=== Beim [[Etherrape_(Deutsch)|Etherrape]] ist der I2C-Bus auf einem separaten Steckverbinder herausgeführt. ===Pollin AVR-NET-IO=== Beim Pollin [[AVR-NET-IO_(Deutsch)|AVR-NET-IO]] liegen die Leitungen des Ports C auf J3, dem 25poligen SUB-D Steckverbinder. Dort lassen sich auch Versorgungsspannung und Masse für die angeschlossenen Slaves abgreifen: {|class=wikitable !Pin !Funktion |- |2 |PC0 (SCL) |- |3 |PC1 (SDA) |- |15 |5V |- |18 |GND |} ==Konfiguration== Die Leitungen sind fest vorgegeben, daher muss keine Konfiguration des Pinnings erfolgen. Die Einstellungen für den Master-Mode finden sich unter "I/O support", "I2C Master Support". == ECMD == = I2C = Mittels "i2c detect" werden die gefundenen I2C Adressen aufgelistet i2c detect detected at: 0x20 (32) detected at: 0x48 (72) detected at: 0x60 (96) Mit den allgemeinen I2C-Kommandos können alle I2C-Chips angesprochen werden. Mit dem Befehl i2c wbb 72 81 wird z. B. die Temperatur-Konvertierung auf einem DS1631 gestartet. Geschrieben wird ein Byte mit dem Wert 81 an den Chip mit der Adresse 72. Mit dem Befehl i2c rwd 72 170 wird ein Word von der Adresse 170 des Chips mit der Adresse 72 gelesen. Damit wird die Temperatur des DS1631 ausgelesen. Die Umrechung muß man dann per Hand durchführen. = TSL2561 Licht/Digital-Wandler = (tested commit e927b0e) I/O --> I2C--> [*]I2C master --> [*] I2C detection support [*] I2C TSL2561 light sensor <b>Abfrage via http ecmd:</b> /ecmd?i2c detect // detected at: 0x39 (57), funktioniert und wird erkannt. /ecmd?tsl2561 raw // parse error, funktioniert derzeit nicht?. 24.01.2016 /ecmd?tsl2561 lux // parse error, funktioniert derzeit nicht?. 24.01.2016 = DS1631 = Ein DS1631 Temperatursensor muß nach dem Einschalten der Stromversorgung erst aktiviert werden. Der erste DS1631 mit der Adresse 0x48 hat im Befehl die Adresse 0. Mit dem folgenden Befehl wird die Temperatur-Konvertierung eingeschaltet: ds1631 convert 0 1 Jetzt kann die Temperatur ausgelesen werden. Die Genauigkeit beträgt immer die vollen 12bits. ds1631 temp 0 22.875 Wahrscheinlich können auch DS1621-Sensoren ausgelesen werden, das wurde aber noch nicht getestet! = PCF8574 = Für die Porterweiterung gilt das Schema "pcf8574x read adresse chip" wobei die adresse 0-7 sein kann, und chip "0" oder "1", je nachdem ob man den pcf8574 oder den pcf8574A benutzt. pcf8574x read 0 0 FFFF Schalten von Ausgängen mit Wert 0xF0 am PCF8574 mit Adresse 5 (Das bedeutet das a0=1 und a2=1 ist, ergo 101) d.h. die ersten 4 Ausgänge werden auf "1" die anderen 4 Ausgänge auf "0" gesetzt. pcf8574x set 5 0 F0 [[Category:Ethersex]] [[Category:StepByStep]] [[Category:I2C]] [[Category:ECMD]] 9ddfd72b8000f6467479bcc4de6f04b86b5d2d9e 1519 1518 2016-01-24T13:15:46Z Djmaster 255 /* TSL2561 Licht/Digital-Wandler */ wikitext text/x-wiki {{i18n|I2C}} {{Module |NAME=I2C |MENUCONFIG={{I/O}}-{{I2C Master}} |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6= - |DEPENDS= - |REQUIRES= CONFIG_EXPERIMENTAL |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/i2c/master https://github.com/ethersex/ethersex/tree/master/hardware/i2c/master] }} Der I2C-Bus (Inter Integrated Circuit) ist ein einfacher Zweidraht-Bus, der für die Kommunikation zwischen ICs innerhalb eines größeren Systems verwendet wird. Insbesondere bietet er sich an zur Kommunikation zwischen Microcontrollern und Peripheriegeräten. Das [[Ethersex]]-System kann sowohl als Master als auch als Slave in einem I2C-Bus arbeiten. In der Atmel-Dokumentation wird I2C als TWI (Two Wire Interface) geführt. ==Master Mode== Im Master-Mode kann das Ethersex-System auf angeschlossene I2C-Slaves zugreifen. Unterstützt werden im Moment: * 24cXX EEPROMs (Als Storage Backend für das Virtuelle Dateisystem) * LM75 Temperatursensoren * PCA9531 8 bit LED Dimmer * PCF8574x Port Extension ==Slave Mode== * Kann per I2C auf die [[ECMD (Deutsch) | ECMD ]] Schnittstelle zugegriffen werden. * In menuconfig -> Protocols -> ECMD -> I2C aktivieren [[I2C/Slave Example (Deutsch) | Beispielimplementierung]] mit Ethersex (Slave) und einem zweiten AVR (Master). ==Anschluss== Die Leitungen SCL (Clock) und SDA (Data) liegen als "Alternate Function" auf I/O Leitungen der Controller. Beim ATmega32 sind dies PC0 (SCL) und PC1 (SDA). ===Etherrape=== Beim [[Etherrape_(Deutsch)|Etherrape]] ist der I2C-Bus auf einem separaten Steckverbinder herausgeführt. ===Pollin AVR-NET-IO=== Beim Pollin [[AVR-NET-IO_(Deutsch)|AVR-NET-IO]] liegen die Leitungen des Ports C auf J3, dem 25poligen SUB-D Steckverbinder. Dort lassen sich auch Versorgungsspannung und Masse für die angeschlossenen Slaves abgreifen: {|class=wikitable !Pin !Funktion |- |2 |PC0 (SCL) |- |3 |PC1 (SDA) |- |15 |5V |- |18 |GND |} ==Konfiguration== Die Leitungen sind fest vorgegeben, daher muss keine Konfiguration des Pinnings erfolgen. Die Einstellungen für den Master-Mode finden sich unter "I/O support", "I2C Master Support". == ECMD == = I2C = Mittels "i2c detect" werden die gefundenen I2C Adressen aufgelistet i2c detect detected at: 0x20 (32) detected at: 0x48 (72) detected at: 0x60 (96) Mit den allgemeinen I2C-Kommandos können alle I2C-Chips angesprochen werden. Mit dem Befehl i2c wbb 72 81 wird z. B. die Temperatur-Konvertierung auf einem DS1631 gestartet. Geschrieben wird ein Byte mit dem Wert 81 an den Chip mit der Adresse 72. Mit dem Befehl i2c rwd 72 170 wird ein Word von der Adresse 170 des Chips mit der Adresse 72 gelesen. Damit wird die Temperatur des DS1631 ausgelesen. Die Umrechung muß man dann per Hand durchführen. = LM75 = Um den LM75 Temperatursensor auszulesen (Basisadresse 0x48) muss die IC Adresse angegeben werden. In diesem Falle ist das "0" weil die IC Adresse a0 bis a2 auf Masse gesetzt werden. -> binär 000 = 0 lm75 0 21.5 = DS1631 = Ein DS1631 Temperatursensor muß nach dem Einschalten der Stromversorgung erst aktiviert werden. Der erste DS1631 mit der Adresse 0x48 hat im Befehl die Adresse 0. Mit dem folgenden Befehl wird die Temperatur-Konvertierung eingeschaltet: ds1631 convert 0 1 Jetzt kann die Temperatur ausgelesen werden. Die Genauigkeit beträgt immer die vollen 12bits. ds1631 temp 0 22.875 Wahrscheinlich können auch DS1621-Sensoren ausgelesen werden, das wurde aber noch nicht getestet! = PCF8574 = Für die Porterweiterung gilt das Schema "pcf8574x read adresse chip" wobei die adresse 0-7 sein kann, und chip "0" oder "1", je nachdem ob man den pcf8574 oder den pcf8574A benutzt. pcf8574x read 0 0 FFFF Schalten von Ausgängen mit Wert 0xF0 am PCF8574 mit Adresse 5 (Das bedeutet das a0=1 und a2=1 ist, ergo 101) d.h. die ersten 4 Ausgänge werden auf "1" die anderen 4 Ausgänge auf "0" gesetzt. pcf8574x set 5 0 F0 [[Category:Ethersex]] [[Category:StepByStep]] [[Category:I2C]] [[Category:ECMD]] 122b4ad93b8d3c1ecd25ed6efa15172589aef7b9 1520 1519 2016-01-24T13:16:28Z Djmaster 255 wikitext text/x-wiki {{i18n|I2C}} {{Module |NAME=I2C |MENUCONFIG={{I/O}}-{{I2C Master}} |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6= - |DEPENDS= - |REQUIRES= CONFIG_EXPERIMENTAL |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/i2c/master https://github.com/ethersex/ethersex/tree/master/hardware/i2c/master] }} Der I2C-Bus (Inter Integrated Circuit) ist ein einfacher Zweidraht-Bus, der für die Kommunikation zwischen ICs innerhalb eines größeren Systems verwendet wird. Insbesondere bietet er sich an zur Kommunikation zwischen Microcontrollern und Peripheriegeräten. Das [[Ethersex]]-System kann sowohl als Master als auch als Slave in einem I2C-Bus arbeiten. In der Atmel-Dokumentation wird I2C als TWI (Two Wire Interface) geführt. ==Master Mode== Im Master-Mode kann das Ethersex-System auf angeschlossene I2C-Slaves zugreifen. Unterstützt werden im Moment: * 24cXX EEPROMs (Als Storage Backend für das Virtuelle Dateisystem) * LM75 Temperatursensoren * PCA9531 8 bit LED Dimmer * PCF8574x Port Extension ==Slave Mode== * Kann per I2C auf die [[ECMD (Deutsch) | ECMD ]] Schnittstelle zugegriffen werden. * In menuconfig -> Protocols -> ECMD -> I2C aktivieren [[I2C/Slave Example (Deutsch) | Beispielimplementierung]] mit Ethersex (Slave) und einem zweiten AVR (Master). ==Anschluss== Die Leitungen SCL (Clock) und SDA (Data) liegen als "Alternate Function" auf I/O Leitungen der Controller. Beim ATmega32 sind dies PC0 (SCL) und PC1 (SDA). ===Etherrape=== Beim [[Etherrape_(Deutsch)|Etherrape]] ist der I2C-Bus auf einem separaten Steckverbinder herausgeführt. ===Pollin AVR-NET-IO=== Beim Pollin [[AVR-NET-IO_(Deutsch)|AVR-NET-IO]] liegen die Leitungen des Ports C auf J3, dem 25poligen SUB-D Steckverbinder. Dort lassen sich auch Versorgungsspannung und Masse für die angeschlossenen Slaves abgreifen: {|class=wikitable !Pin !Funktion |- |2 |PC0 (SCL) |- |3 |PC1 (SDA) |- |15 |5V |- |18 |GND |} ==Konfiguration== Die Leitungen sind fest vorgegeben, daher muss keine Konfiguration des Pinnings erfolgen. Die Einstellungen für den Master-Mode finden sich unter "I/O support", "I2C Master Support". == ECMD == = I2C = Mittels "i2c detect" werden die gefundenen I2C Adressen aufgelistet i2c detect detected at: 0x20 (32) detected at: 0x48 (72) detected at: 0x60 (96) Mit den allgemeinen I2C-Kommandos können alle I2C-Chips angesprochen werden. Mit dem Befehl i2c wbb 72 81 wird z. B. die Temperatur-Konvertierung auf einem DS1631 gestartet. Geschrieben wird ein Byte mit dem Wert 81 an den Chip mit der Adresse 72. Mit dem Befehl i2c rwd 72 170 wird ein Word von der Adresse 170 des Chips mit der Adresse 72 gelesen. Damit wird die Temperatur des DS1631 ausgelesen. Die Umrechung muß man dann per Hand durchführen. = LM75 = Um den LM75 Temperatursensor auszulesen (Basisadresse 0x48) muss die IC Adresse angegeben werden. In diesem Falle ist das "0" weil die IC Adresse a0 bis a2 auf Masse gesetzt werden. -> binär 000 = 0 lm75 0 21.5 = DS1631 = Ein DS1631 Temperatursensor muß nach dem Einschalten der Stromversorgung erst aktiviert werden. Der erste DS1631 mit der Adresse 0x48 hat im Befehl die Adresse 0. Mit dem folgenden Befehl wird die Temperatur-Konvertierung eingeschaltet: ds1631 convert 0 1 Jetzt kann die Temperatur ausgelesen werden. Die Genauigkeit beträgt immer die vollen 12bits. ds1631 temp 0 22.875 Wahrscheinlich können auch DS1621-Sensoren ausgelesen werden, das wurde aber noch nicht getestet! = PCF8574 = Für die Porterweiterung gilt das Schema "pcf8574x read adresse chip" wobei die adresse 0-7 sein kann, und chip "0" oder "1", je nachdem ob man den pcf8574 oder den pcf8574A benutzt. pcf8574x read 0 0 FFFF Schalten von Ausgängen mit Wert 0xF0 am PCF8574 mit Adresse 5 (Das bedeutet das a0=1 und a2=1 ist, ergo 101) d.h. die ersten 4 Ausgänge werden auf "1" die anderen 4 Ausgänge auf "0" gesetzt. pcf8574x set 5 0 F0 = TSL2561 Licht/Digital-Wandler = (tested commit e927b0e) I/O --> I2C--> [*]I2C master --> [*] I2C detection support [*] I2C TSL2561 light sensor <b>Abfrage via http ecmd:</b> /ecmd?i2c detect // detected at: 0x39 (57), funktioniert und wird erkannt. /ecmd?tsl2561 raw // parse error, funktioniert derzeit nicht?. 24.01.2016 /ecmd?tsl2561 lux // parse error, funktioniert derzeit nicht?. 24.01.2016 [[Category:Ethersex]] [[Category:StepByStep]] [[Category:I2C]] [[Category:ECMD]] 3f0ca9d8c42a473e71bfdb44a5b97dd9d1ce91c6 1521 1520 2016-01-24T13:26:08Z Djmaster 255 /* Konfiguration */ wikitext text/x-wiki {{i18n|I2C}} {{Module |NAME=I2C |MENUCONFIG={{I/O}}-{{I2C Master}} |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6= - |DEPENDS= - |REQUIRES= CONFIG_EXPERIMENTAL |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/i2c/master https://github.com/ethersex/ethersex/tree/master/hardware/i2c/master] }} Der I2C-Bus (Inter Integrated Circuit) ist ein einfacher Zweidraht-Bus, der für die Kommunikation zwischen ICs innerhalb eines größeren Systems verwendet wird. Insbesondere bietet er sich an zur Kommunikation zwischen Microcontrollern und Peripheriegeräten. Das [[Ethersex]]-System kann sowohl als Master als auch als Slave in einem I2C-Bus arbeiten. In der Atmel-Dokumentation wird I2C als TWI (Two Wire Interface) geführt. ==Master Mode== Im Master-Mode kann das Ethersex-System auf angeschlossene I2C-Slaves zugreifen. Unterstützt werden im Moment: * 24cXX EEPROMs (Als Storage Backend für das Virtuelle Dateisystem) * LM75 Temperatursensoren * PCA9531 8 bit LED Dimmer * PCF8574x Port Extension ==Slave Mode== * Kann per I2C auf die [[ECMD (Deutsch) | ECMD ]] Schnittstelle zugegriffen werden. * In menuconfig -> Protocols -> ECMD -> I2C aktivieren [[I2C/Slave Example (Deutsch) | Beispielimplementierung]] mit Ethersex (Slave) und einem zweiten AVR (Master). ==Anschluss== Die Leitungen SCL (Clock) und SDA (Data) liegen als "Alternate Function" auf I/O Leitungen der Controller. Beim ATmega32 sind dies PC0 (SCL) und PC1 (SDA). ===Etherrape=== Beim [[Etherrape_(Deutsch)|Etherrape]] ist der I2C-Bus auf einem separaten Steckverbinder herausgeführt. ===Pollin AVR-NET-IO=== Beim Pollin [[AVR-NET-IO_(Deutsch)|AVR-NET-IO]] liegen die Leitungen des Ports C auf J3, dem 25poligen SUB-D Steckverbinder. Dort lassen sich auch Versorgungsspannung und Masse für die angeschlossenen Slaves abgreifen: {|class=wikitable !Pin !Funktion |- |2 |PC0 (SCL) |- |3 |PC1 (SDA) |- |15 |5V |- |18 |GND |} ==Konfiguration== Die Leitungen sind fest vorgegeben, daher muss <b>keine<b> Konfiguration des Pinnings erfolgen. Die Einstellungen für den Master-Mode finden sich unter: │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ Network ---> │ │ I/O ---> │ │ I2C ---> │ │ [*] I2C master ---> │ │ [*] I2C detection support == ECMD == = I2C = Mittels "i2c detect" werden die gefundenen I2C Adressen aufgelistet i2c detect detected at: 0x20 (32) detected at: 0x48 (72) detected at: 0x60 (96) Mit den allgemeinen I2C-Kommandos können alle I2C-Chips angesprochen werden. Mit dem Befehl i2c wbb 72 81 wird z. B. die Temperatur-Konvertierung auf einem DS1631 gestartet. Geschrieben wird ein Byte mit dem Wert 81 an den Chip mit der Adresse 72. Mit dem Befehl i2c rwd 72 170 wird ein Word von der Adresse 170 des Chips mit der Adresse 72 gelesen. Damit wird die Temperatur des DS1631 ausgelesen. Die Umrechung muß man dann per Hand durchführen. = LM75 = Um den LM75 Temperatursensor auszulesen (Basisadresse 0x48) muss die IC Adresse angegeben werden. In diesem Falle ist das "0" weil die IC Adresse a0 bis a2 auf Masse gesetzt werden. -> binär 000 = 0 lm75 0 21.5 = DS1631 = Ein DS1631 Temperatursensor muß nach dem Einschalten der Stromversorgung erst aktiviert werden. Der erste DS1631 mit der Adresse 0x48 hat im Befehl die Adresse 0. Mit dem folgenden Befehl wird die Temperatur-Konvertierung eingeschaltet: ds1631 convert 0 1 Jetzt kann die Temperatur ausgelesen werden. Die Genauigkeit beträgt immer die vollen 12bits. ds1631 temp 0 22.875 Wahrscheinlich können auch DS1621-Sensoren ausgelesen werden, das wurde aber noch nicht getestet! = PCF8574 = Für die Porterweiterung gilt das Schema "pcf8574x read adresse chip" wobei die adresse 0-7 sein kann, und chip "0" oder "1", je nachdem ob man den pcf8574 oder den pcf8574A benutzt. pcf8574x read 0 0 FFFF Schalten von Ausgängen mit Wert 0xF0 am PCF8574 mit Adresse 5 (Das bedeutet das a0=1 und a2=1 ist, ergo 101) d.h. die ersten 4 Ausgänge werden auf "1" die anderen 4 Ausgänge auf "0" gesetzt. pcf8574x set 5 0 F0 = TSL2561 Licht/Digital-Wandler = (tested commit e927b0e) I/O --> I2C--> [*]I2C master --> [*] I2C detection support [*] I2C TSL2561 light sensor <b>Abfrage via http ecmd:</b> /ecmd?i2c detect // detected at: 0x39 (57), funktioniert und wird erkannt. /ecmd?tsl2561 raw // parse error, funktioniert derzeit nicht?. 24.01.2016 /ecmd?tsl2561 lux // parse error, funktioniert derzeit nicht?. 24.01.2016 [[Category:Ethersex]] [[Category:StepByStep]] [[Category:I2C]] [[Category:ECMD]] 2a810a607ed250271d52d12581fd96657c132b07 1522 1521 2016-01-24T13:31:20Z Djmaster 255 wikitext text/x-wiki {{i18n|I2C}} {{Module |NAME=I2C |MENUCONFIG={{I/O}}-{{I2C Master}} |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6= - |DEPENDS= - |REQUIRES= CONFIG_EXPERIMENTAL |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/i2c/master https://github.com/ethersex/ethersex/tree/master/hardware/i2c/master] }} Der I2C-Bus (Inter Integrated Circuit) ist ein einfacher Zweidraht-Bus, der für die Kommunikation zwischen ICs innerhalb eines größeren Systems verwendet wird. Insbesondere bietet er sich an zur Kommunikation zwischen Microcontrollern und Peripheriegeräten. Das [[Ethersex]]-System kann sowohl als Master als auch als Slave in einem I2C-Bus arbeiten. In der Atmel-Dokumentation wird I2C als TWI (Two Wire Interface) geführt. =Allgemeines= ==Master Mode== Im Master-Mode kann das Ethersex-System auf angeschlossene I2C-Slaves zugreifen. Unterstützt werden im Moment: * 24cXX EEPROMs (Als Storage Backend für das Virtuelle Dateisystem) * LM75 Temperatursensoren * PCA9531 8 bit LED Dimmer * PCF8574x Port Extension ==Slave Mode== * Kann per I2C auf die [[ECMD (Deutsch) | ECMD ]] Schnittstelle zugegriffen werden. * In menuconfig -> Protocols -> ECMD -> I2C aktivieren [[I2C/Slave Example (Deutsch) | Beispielimplementierung]] mit Ethersex (Slave) und einem zweiten AVR (Master). ==Anschluss== Die Leitungen SCL (Clock) und SDA (Data) liegen als "Alternate Function" auf I/O Leitungen der Controller. Beim ATmega32 sind dies PC0 (SCL) und PC1 (SDA). =Etherrape= Beim [[Etherrape_(Deutsch)|Etherrape]] ist der I2C-Bus auf einem separaten Steckverbinder herausgeführt. =Pollin AVR-NET-IO= Beim Pollin [[AVR-NET-IO_(Deutsch)|AVR-NET-IO]] liegen die Leitungen des Ports C auf J3, dem 25poligen SUB-D Steckverbinder. Dort lassen sich auch Versorgungsspannung und Masse für die angeschlossenen Slaves abgreifen: {|class=wikitable !Pin !Funktion |- |2 |PC0 (SCL) |- |3 |PC1 (SDA) |- |15 |5V |- |18 |GND |} =Konfiguration= Die Leitungen sind fest vorgegeben, daher muss <b>keine</b> Konfiguration des Pinnings erfolgen. Die Einstellungen für den Master-Mode finden sich unter: │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ Network ---> │ │ I/O ---> │ │ I2C ---> │ │ [*] I2C master ---> │ │ [*] I2C detection support = ECMD = == I2C == Mittels "i2c detect" werden die gefundenen I2C Adressen aufgelistet i2c detect detected at: 0x20 (32) detected at: 0x48 (72) detected at: 0x60 (96) Mit den allgemeinen I2C-Kommandos können alle I2C-Chips angesprochen werden. Mit dem Befehl i2c wbb 72 81 wird z. B. die Temperatur-Konvertierung auf einem DS1631 gestartet. Geschrieben wird ein Byte mit dem Wert 81 an den Chip mit der Adresse 72. Mit dem Befehl i2c rwd 72 170 wird ein Word von der Adresse 170 des Chips mit der Adresse 72 gelesen. Damit wird die Temperatur des DS1631 ausgelesen. Die Umrechung muß man dann per Hand durchführen. =I2C Sensoren= == LM75 == Um den LM75 Temperatursensor auszulesen (Basisadresse 0x48) muss die IC Adresse angegeben werden. In diesem Falle ist das "0" weil die IC Adresse a0 bis a2 auf Masse gesetzt werden. -> binär 000 = 0 lm75 0 21.5 == DS1631 == Ein DS1631 Temperatursensor muß nach dem Einschalten der Stromversorgung erst aktiviert werden. Der erste DS1631 mit der Adresse 0x48 hat im Befehl die Adresse 0. Mit dem folgenden Befehl wird die Temperatur-Konvertierung eingeschaltet: ds1631 convert 0 1 Jetzt kann die Temperatur ausgelesen werden. Die Genauigkeit beträgt immer die vollen 12bits. ds1631 temp 0 22.875 Wahrscheinlich können auch DS1621-Sensoren ausgelesen werden, das wurde aber noch nicht getestet! == PCF8574 == Für die Porterweiterung gilt das Schema "pcf8574x read adresse chip" wobei die adresse 0-7 sein kann, und chip "0" oder "1", je nachdem ob man den pcf8574 oder den pcf8574A benutzt. pcf8574x read 0 0 FFFF Schalten von Ausgängen mit Wert 0xF0 am PCF8574 mit Adresse 5 (Das bedeutet das a0=1 und a2=1 ist, ergo 101) d.h. die ersten 4 Ausgänge werden auf "1" die anderen 4 Ausgänge auf "0" gesetzt. pcf8574x set 5 0 F0 == TSL2561 Licht/Digital-Wandler == (tested commit e927b0e) I/O --> I2C--> [*]I2C master --> [*] I2C detection support [*] I2C TSL2561 light sensor <b>Abfrage via http ecmd:</b> /ecmd?i2c detect // detected at: 0x39 (57), funktioniert und wird erkannt. /ecmd?tsl2561 raw // parse error, funktioniert derzeit nicht?. 24.01.2016 /ecmd?tsl2561 lux // parse error, funktioniert derzeit nicht?. 24.01.2016 [[Category:Ethersex]] [[Category:StepByStep]] [[Category:I2C]] [[Category:ECMD]] 3b4e6dad817da96d33533c78a7f4d4dd25b3cb6f 1523 1522 2016-01-24T13:31:52Z Djmaster 255 /* Anschluss */ wikitext text/x-wiki {{i18n|I2C}} {{Module |NAME=I2C |MENUCONFIG={{I/O}}-{{I2C Master}} |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6= - |DEPENDS= - |REQUIRES= CONFIG_EXPERIMENTAL |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/i2c/master https://github.com/ethersex/ethersex/tree/master/hardware/i2c/master] }} Der I2C-Bus (Inter Integrated Circuit) ist ein einfacher Zweidraht-Bus, der für die Kommunikation zwischen ICs innerhalb eines größeren Systems verwendet wird. Insbesondere bietet er sich an zur Kommunikation zwischen Microcontrollern und Peripheriegeräten. Das [[Ethersex]]-System kann sowohl als Master als auch als Slave in einem I2C-Bus arbeiten. In der Atmel-Dokumentation wird I2C als TWI (Two Wire Interface) geführt. =Allgemeines= ==Master Mode== Im Master-Mode kann das Ethersex-System auf angeschlossene I2C-Slaves zugreifen. Unterstützt werden im Moment: * 24cXX EEPROMs (Als Storage Backend für das Virtuelle Dateisystem) * LM75 Temperatursensoren * PCA9531 8 bit LED Dimmer * PCF8574x Port Extension ==Slave Mode== * Kann per I2C auf die [[ECMD (Deutsch) | ECMD ]] Schnittstelle zugegriffen werden. * In menuconfig -> Protocols -> ECMD -> I2C aktivieren [[I2C/Slave Example (Deutsch) | Beispielimplementierung]] mit Ethersex (Slave) und einem zweiten AVR (Master). ==Anschluss== Die Leitungen SCL (Clock) und SDA (Data) liegen als "Alternate Function" auf I/O Leitungen der Controller. Beim ATmega32/644/644p sind dies PC0 (SCL) und PC1 (SDA). =Etherrape= Beim [[Etherrape_(Deutsch)|Etherrape]] ist der I2C-Bus auf einem separaten Steckverbinder herausgeführt. =Pollin AVR-NET-IO= Beim Pollin [[AVR-NET-IO_(Deutsch)|AVR-NET-IO]] liegen die Leitungen des Ports C auf J3, dem 25poligen SUB-D Steckverbinder. Dort lassen sich auch Versorgungsspannung und Masse für die angeschlossenen Slaves abgreifen: {|class=wikitable !Pin !Funktion |- |2 |PC0 (SCL) |- |3 |PC1 (SDA) |- |15 |5V |- |18 |GND |} =Konfiguration= Die Leitungen sind fest vorgegeben, daher muss <b>keine</b> Konfiguration des Pinnings erfolgen. Die Einstellungen für den Master-Mode finden sich unter: │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ Network ---> │ │ I/O ---> │ │ I2C ---> │ │ [*] I2C master ---> │ │ [*] I2C detection support = ECMD = == I2C == Mittels "i2c detect" werden die gefundenen I2C Adressen aufgelistet i2c detect detected at: 0x20 (32) detected at: 0x48 (72) detected at: 0x60 (96) Mit den allgemeinen I2C-Kommandos können alle I2C-Chips angesprochen werden. Mit dem Befehl i2c wbb 72 81 wird z. B. die Temperatur-Konvertierung auf einem DS1631 gestartet. Geschrieben wird ein Byte mit dem Wert 81 an den Chip mit der Adresse 72. Mit dem Befehl i2c rwd 72 170 wird ein Word von der Adresse 170 des Chips mit der Adresse 72 gelesen. Damit wird die Temperatur des DS1631 ausgelesen. Die Umrechung muß man dann per Hand durchführen. =I2C Sensoren= == LM75 == Um den LM75 Temperatursensor auszulesen (Basisadresse 0x48) muss die IC Adresse angegeben werden. In diesem Falle ist das "0" weil die IC Adresse a0 bis a2 auf Masse gesetzt werden. -> binär 000 = 0 lm75 0 21.5 == DS1631 == Ein DS1631 Temperatursensor muß nach dem Einschalten der Stromversorgung erst aktiviert werden. Der erste DS1631 mit der Adresse 0x48 hat im Befehl die Adresse 0. Mit dem folgenden Befehl wird die Temperatur-Konvertierung eingeschaltet: ds1631 convert 0 1 Jetzt kann die Temperatur ausgelesen werden. Die Genauigkeit beträgt immer die vollen 12bits. ds1631 temp 0 22.875 Wahrscheinlich können auch DS1621-Sensoren ausgelesen werden, das wurde aber noch nicht getestet! == PCF8574 == Für die Porterweiterung gilt das Schema "pcf8574x read adresse chip" wobei die adresse 0-7 sein kann, und chip "0" oder "1", je nachdem ob man den pcf8574 oder den pcf8574A benutzt. pcf8574x read 0 0 FFFF Schalten von Ausgängen mit Wert 0xF0 am PCF8574 mit Adresse 5 (Das bedeutet das a0=1 und a2=1 ist, ergo 101) d.h. die ersten 4 Ausgänge werden auf "1" die anderen 4 Ausgänge auf "0" gesetzt. pcf8574x set 5 0 F0 == TSL2561 Licht/Digital-Wandler == (tested commit e927b0e) I/O --> I2C--> [*]I2C master --> [*] I2C detection support [*] I2C TSL2561 light sensor <b>Abfrage via http ecmd:</b> /ecmd?i2c detect // detected at: 0x39 (57), funktioniert und wird erkannt. /ecmd?tsl2561 raw // parse error, funktioniert derzeit nicht?. 24.01.2016 /ecmd?tsl2561 lux // parse error, funktioniert derzeit nicht?. 24.01.2016 [[Category:Ethersex]] [[Category:StepByStep]] [[Category:I2C]] [[Category:ECMD]] ed9fbf9adeee681e43b4316bd5fbc0b80159377a 1524 1523 2016-01-24T13:34:11Z Djmaster 255 wikitext text/x-wiki {{i18n|I2C}} {{Module |NAME=I2C |MENUCONFIG={{I/O}}-{{I2C Master}} |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6= - |DEPENDS= - |REQUIRES= CONFIG_EXPERIMENTAL |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/i2c/master https://github.com/ethersex/ethersex/tree/master/hardware/i2c/master] }} Der I2C-Bus (Inter Integrated Circuit) ist ein einfacher Zweidraht-Bus, der für die Kommunikation zwischen ICs innerhalb eines größeren Systems verwendet wird. Insbesondere bietet er sich an zur Kommunikation zwischen Microcontrollern und Peripheriegeräten. Das [[Ethersex]]-System kann sowohl als Master als auch als Slave in einem I2C-Bus arbeiten. In der Atmel-Dokumentation wird I2C als TWI (Two Wire Interface) geführt. =Allgemeines= ==Master Mode== Im Master-Mode kann das Ethersex-System auf angeschlossene I2C-Slaves zugreifen. Unterstützt werden im Moment: * 24cXX EEPROMs (Als Storage Backend für das Virtuelle Dateisystem) * LM75 Temperatursensoren * PCA9531 8 bit LED Dimmer * PCF8574x Port Extension ==Slave Mode== * Kann per I2C auf die [[ECMD (Deutsch) | ECMD ]] Schnittstelle zugegriffen werden. * In menuconfig -> Protocols -> ECMD -> I2C aktivieren [[I2C/Slave Example (Deutsch) | Beispielimplementierung]] mit Ethersex (Slave) und einem zweiten AVR (Master). ==Anschluss== Die Leitungen SCL (Clock) und SDA (Data) liegen als "Alternate Function" auf I/O Leitungen der Controller. Beim ATmega32/644/644p sind dies PC0 (SCL) und PC1 (SDA). ==Levelshifter 3,3V 5V== Link/djmaster =Etherrape= Beim [[Etherrape_(Deutsch)|Etherrape]] ist der I2C-Bus auf einem separaten Steckverbinder herausgeführt. =Pollin AVR-NET-IO= Beim Pollin [[AVR-NET-IO_(Deutsch)|AVR-NET-IO]] liegen die Leitungen des Ports C auf J3, dem 25poligen SUB-D Steckverbinder. Dort lassen sich auch Versorgungsspannung und Masse für die angeschlossenen Slaves abgreifen: {|class=wikitable !Pin !Funktion |- |2 |PC0 (SCL) |- |3 |PC1 (SDA) |- |15 |5V |- |18 |GND |} =Konfiguration= Die Leitungen sind fest vorgegeben, daher muss <b>keine</b> Konfiguration des Pinnings erfolgen. Die Einstellungen für den Master-Mode finden sich unter: │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ Network ---> │ │ I/O ---> │ │ I2C ---> │ │ [*] I2C master ---> │ │ [*] I2C detection support = ECMD = == I2C == Mittels "i2c detect" werden die gefundenen I2C Adressen aufgelistet i2c detect detected at: 0x20 (32) detected at: 0x48 (72) detected at: 0x60 (96) Mit den allgemeinen I2C-Kommandos können alle I2C-Chips angesprochen werden. Mit dem Befehl i2c wbb 72 81 wird z. B. die Temperatur-Konvertierung auf einem DS1631 gestartet. Geschrieben wird ein Byte mit dem Wert 81 an den Chip mit der Adresse 72. Mit dem Befehl i2c rwd 72 170 wird ein Word von der Adresse 170 des Chips mit der Adresse 72 gelesen. Damit wird die Temperatur des DS1631 ausgelesen. Die Umrechung muß man dann per Hand durchführen. =I2C Sensoren= == DS1631 == Ein DS1631 Temperatursensor muß nach dem Einschalten der Stromversorgung erst aktiviert werden. Der erste DS1631 mit der Adresse 0x48 hat im Befehl die Adresse 0. Mit dem folgenden Befehl wird die Temperatur-Konvertierung eingeschaltet: ds1631 convert 0 1 Jetzt kann die Temperatur ausgelesen werden. Die Genauigkeit beträgt immer die vollen 12bits. ds1631 temp 0 22.875 Wahrscheinlich können auch DS1621-Sensoren ausgelesen werden, das wurde aber noch nicht getestet! == LM75 == Um den LM75 Temperatursensor auszulesen (Basisadresse 0x48) muss die IC Adresse angegeben werden. In diesem Falle ist das "0" weil die IC Adresse a0 bis a2 auf Masse gesetzt werden. -> binär 000 = 0 lm75 0 21.5 == PCF8574 == Für die Porterweiterung gilt das Schema "pcf8574x read adresse chip" wobei die adresse 0-7 sein kann, und chip "0" oder "1", je nachdem ob man den pcf8574 oder den pcf8574A benutzt. pcf8574x read 0 0 FFFF Schalten von Ausgängen mit Wert 0xF0 am PCF8574 mit Adresse 5 (Das bedeutet das a0=1 und a2=1 ist, ergo 101) d.h. die ersten 4 Ausgänge werden auf "1" die anderen 4 Ausgänge auf "0" gesetzt. pcf8574x set 5 0 F0 == TSL2561 Licht/Digital-Wandler == (tested commit e927b0e) I/O --> I2C--> [*]I2C master --> [*] I2C detection support [*] I2C TSL2561 light sensor <b>Abfrage via http ecmd:</b> /ecmd?i2c detect // detected at: 0x39 (57), funktioniert und wird erkannt. /ecmd?tsl2561 raw // parse error, funktioniert derzeit nicht?. 24.01.2016 /ecmd?tsl2561 lux // parse error, funktioniert derzeit nicht?. 24.01.2016 [[Category:Ethersex]] [[Category:StepByStep]] [[Category:I2C]] [[Category:ECMD]] 043ed5922b04ed198e1692289fc5977ae0e6d8c0 1527 1524 2016-01-24T13:50:01Z Djmaster 255 /* Levelshifter 3,3V 5V */ wikitext text/x-wiki {{i18n|I2C}} {{Module |NAME=I2C |MENUCONFIG={{I/O}}-{{I2C Master}} |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6= - |DEPENDS= - |REQUIRES= CONFIG_EXPERIMENTAL |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/i2c/master https://github.com/ethersex/ethersex/tree/master/hardware/i2c/master] }} Der I2C-Bus (Inter Integrated Circuit) ist ein einfacher Zweidraht-Bus, der für die Kommunikation zwischen ICs innerhalb eines größeren Systems verwendet wird. Insbesondere bietet er sich an zur Kommunikation zwischen Microcontrollern und Peripheriegeräten. Das [[Ethersex]]-System kann sowohl als Master als auch als Slave in einem I2C-Bus arbeiten. In der Atmel-Dokumentation wird I2C als TWI (Two Wire Interface) geführt. =Allgemeines= ==Master Mode== Im Master-Mode kann das Ethersex-System auf angeschlossene I2C-Slaves zugreifen. Unterstützt werden im Moment: * 24cXX EEPROMs (Als Storage Backend für das Virtuelle Dateisystem) * LM75 Temperatursensoren * PCA9531 8 bit LED Dimmer * PCF8574x Port Extension ==Slave Mode== * Kann per I2C auf die [[ECMD (Deutsch) | ECMD ]] Schnittstelle zugegriffen werden. * In menuconfig -> Protocols -> ECMD -> I2C aktivieren [[I2C/Slave Example (Deutsch) | Beispielimplementierung]] mit Ethersex (Slave) und einem zweiten AVR (Master). ==Anschluss== Die Leitungen SCL (Clock) und SDA (Data) liegen als "Alternate Function" auf I/O Leitungen der Controller. Beim ATmega32/644/644p sind dies PC0 (SCL) und PC1 (SDA). ==Levelshifter 3,3V 5V== Link: [[User:Djmaster#Levelshifter_3.3V_5V|Levelshifter 3,3V 5V]] =Etherrape= Beim [[Etherrape_(Deutsch)|Etherrape]] ist der I2C-Bus auf einem separaten Steckverbinder herausgeführt. =Pollin AVR-NET-IO= Beim Pollin [[AVR-NET-IO_(Deutsch)|AVR-NET-IO]] liegen die Leitungen des Ports C auf J3, dem 25poligen SUB-D Steckverbinder. Dort lassen sich auch Versorgungsspannung und Masse für die angeschlossenen Slaves abgreifen: {|class=wikitable !Pin !Funktion |- |2 |PC0 (SCL) |- |3 |PC1 (SDA) |- |15 |5V |- |18 |GND |} =Konfiguration= Die Leitungen sind fest vorgegeben, daher muss <b>keine</b> Konfiguration des Pinnings erfolgen. Die Einstellungen für den Master-Mode finden sich unter: │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ Network ---> │ │ I/O ---> │ │ I2C ---> │ │ [*] I2C master ---> │ │ [*] I2C detection support = ECMD = == I2C == Mittels "i2c detect" werden die gefundenen I2C Adressen aufgelistet i2c detect detected at: 0x20 (32) detected at: 0x48 (72) detected at: 0x60 (96) Mit den allgemeinen I2C-Kommandos können alle I2C-Chips angesprochen werden. Mit dem Befehl i2c wbb 72 81 wird z. B. die Temperatur-Konvertierung auf einem DS1631 gestartet. Geschrieben wird ein Byte mit dem Wert 81 an den Chip mit der Adresse 72. Mit dem Befehl i2c rwd 72 170 wird ein Word von der Adresse 170 des Chips mit der Adresse 72 gelesen. Damit wird die Temperatur des DS1631 ausgelesen. Die Umrechung muß man dann per Hand durchführen. =I2C Sensoren= == DS1631 == Ein DS1631 Temperatursensor muß nach dem Einschalten der Stromversorgung erst aktiviert werden. Der erste DS1631 mit der Adresse 0x48 hat im Befehl die Adresse 0. Mit dem folgenden Befehl wird die Temperatur-Konvertierung eingeschaltet: ds1631 convert 0 1 Jetzt kann die Temperatur ausgelesen werden. Die Genauigkeit beträgt immer die vollen 12bits. ds1631 temp 0 22.875 Wahrscheinlich können auch DS1621-Sensoren ausgelesen werden, das wurde aber noch nicht getestet! == LM75 == Um den LM75 Temperatursensor auszulesen (Basisadresse 0x48) muss die IC Adresse angegeben werden. In diesem Falle ist das "0" weil die IC Adresse a0 bis a2 auf Masse gesetzt werden. -> binär 000 = 0 lm75 0 21.5 == PCF8574 == Für die Porterweiterung gilt das Schema "pcf8574x read adresse chip" wobei die adresse 0-7 sein kann, und chip "0" oder "1", je nachdem ob man den pcf8574 oder den pcf8574A benutzt. pcf8574x read 0 0 FFFF Schalten von Ausgängen mit Wert 0xF0 am PCF8574 mit Adresse 5 (Das bedeutet das a0=1 und a2=1 ist, ergo 101) d.h. die ersten 4 Ausgänge werden auf "1" die anderen 4 Ausgänge auf "0" gesetzt. pcf8574x set 5 0 F0 == TSL2561 Licht/Digital-Wandler == (tested commit e927b0e) I/O --> I2C--> [*]I2C master --> [*] I2C detection support [*] I2C TSL2561 light sensor <b>Abfrage via http ecmd:</b> /ecmd?i2c detect // detected at: 0x39 (57), funktioniert und wird erkannt. /ecmd?tsl2561 raw // parse error, funktioniert derzeit nicht?. 24.01.2016 /ecmd?tsl2561 lux // parse error, funktioniert derzeit nicht?. 24.01.2016 [[Category:Ethersex]] [[Category:StepByStep]] [[Category:I2C]] [[Category:ECMD]] f50d029be1b1bc7e0d409d3a7331c3ac44730aa8 6 493 1525 2016-01-24T13:44:32Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 2 329 1526 1173 2016-01-24T13:48:02Z Djmaster 255 wikitext text/x-wiki [[File:RJ45Buchse_Pinout.png|400px|thumb|RJ45 Buchse]] ==Person== Nick im IRC: djmaster oder djmaster2<br> Web: http://wiki.senseye.org/ ==Bauteile== Für [http://www.lochraster.org/etherrape/ Etherrape] Module {| | {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%;" |- ! Bauteil !! Hersteller !! HerstellerNr !! Lieferant !! Bestellnummer !! Dokumente !! Sonstiges |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/products/en?q=6605424-1 6605424-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154361/ 615-4361] || [http://www.te.com/catalog/pn/en/6605424-1?RQPN=6605424-1 Link] || Netzwerkbuchse ohne LED, Verriegelung Unten |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/pn/en/5-6605308-1 5-6605308-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154383/ 615-4383] || [http://www.te.com/catalog/pn/en/5-6605308-1?RQPN=5-6605308-1 Link] || Netzwerkbuchse mit LED, Verriegelung Unten |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/products/en?q=6605759-1 6605759-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154399/ 615-4399] || [http://www.te.com/catalog/pn/en/6605759-1?RQPN=6605759-1 Link] || Netzwerkbuchse ohne LED, Verriegelung Oben |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/products/en?q=5-6605758-1 5-6605758-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154412/ 615-4412] || [http://www.te.com/catalog/pn/en/5-6605758-1?RQPN=5-6605758-1 Link] || Netzwerkbuchse mit LED, Verriegelung Oben |- align="right" | Hutschienen Gehäuse || Axxatronic || [http://www.axxatronic.de/serie-cnmb.html CNMB-4-KIT-CON] || Conrad || [http://www.conrad.at/ce/de/product/531443/Axxatronic-Hutschienen-Gehaeuse-CNMB-4-KIT-CON-Polycarbonat-L-x-B-x-H-90-x-710-x-58-mm 531443 - 62] || [http://www.axxatronic.de/serie-cnmb.html Link] || (L x B x H) 90 x 71.0 x 58 mm |- align="right" | DS2450 || Maxim || [http://www.maximintegrated.com/datasheet/index.mvp/id/2921 DS2450] || RS-Components || [http://at.rs-online.com/web/p/products/07327557/ 732-7557] || [http://datasheets.maximintegrated.com/en/ds/DS2450.pdf Link] || Onewire quad AD Converter |- align="right" | HIH4000-001 || Honeywell || [http://sensing.honeywell.com/product%20page?pr_id=53944 HIH4000-001] || RS-Components || [http://at.rs-online.com/web/p/products/05283171/ 528-3171] || [http://sensing.honeywell.com/product%20page?pr_id=53944 Link] || Luftfeuchte Sensor von Honeywell |- align="right" | MPXH6115AC6U || Freescale || xx || RS-Components || [http://at.rs-online.com/web/p/products/07176536/ 717-6536] || [http://www.freescale.com/files/sensors/doc/data_sheet/MPXA6115A.pdf Link] || Luftdruck Sensor von Freescale |} ==Die Software== [[File:Ethersex det ssr.png|400px|thumb|die Theorie]] [[File:Hausbus v1.JPG|400px|thumb|die Praxis]] ===TFTP-Bootloader & Fuses=== Menuconfig: │ │ Load a Default Configuration ---> │ │ [*] Ethernet Bootloader │ │ Network ---> │ │ [*] Ethernet (ENC28J60) support ---> │ │ Etherrape IP address: "192.168.12.220" │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ Applications ---> │ │ [*] TFTP support ---> │ │ Bootloader configuration ---> │ │ [*] TFTP-o-matic │ │ --- TFTP-o-matic configuration │ │ TFTP IP address: "192.168.12.120" │ │ TFTP image to load: "ethersex.bin" make clean && make --> ethersex.hex =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 6064/65536 bytes (9.25%) [==----------------------------] Program (.text + .data) : 6064 bytes Data (.data + .bss) : 826 bytes =================================== sudo avrdude -cusbasp -pm644 -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m sudo avrdude -cusbasp -pm644 -U flash:w:ethersex.hex sudo avrdude -cusbasp -pm644 -U lock:w:0x0F:m Achtung bei den SMD Typen vom mega644, ich habe mega644P bekommen, wobei ich jetzt nicht weiß ob die SMD immer P Typen sind. Egal das Problem ist man sollte avrdude genau lesen und auch "-p m644p" anhängen da der P Type eine andere Signatur aufweist. Hat mich ne Stunde gekostet. ;) ==Bilder== ===Testsystem=== <gallery perrow=7> File:1_stella_all_off.jpg File:2_stella_all_on.jpg File:3_mosfets.jpg File:4_schaltung_fet.png File:IMG_5286.JPG File:IMG_6592.JPG File:IMG_6594.JPG File:S0-zaehler_img.JPG File:Esex sensor1.JPG </gallery><br> ==Probleme== 25.1.2011 - ethersex mit m644 und 32khz uhrenquarz.<br> datenblatt mega644 seite 101 - http://www.atmel.com/dyn/resources/prod_documents/doc2593.pdf<br> services/clock/clock.c - zeile 64<br> <obiflix> du könntest https://github.com/ethersex/ethersex/commit/da511f074940423e8e8ef7ee67ca20e6d91f608c rückgängig machen <obiflix> möglicherweise bekommst du dann probleme mit dcf77, falls du das nutzen möchtest, aber einen versuch ist es wert ;) Notiz: Hat funktioniert für den MEGA644<br> Update#1<br> 26.1.2011 - Problem sollte nun behoben sein, Danke an eku! master Erik Kunze * ae3ef98 (2 files in 1 dirs): use timer makros for prescaler 64 (32768Hz/256/64=2Hz) - http://bit.ly/eG2d4c --- DCF muss noch getestet werden ==Notizzettel== schnell mal notiert ein script zum email versenden wenn zb..PIN_LOW... <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include <util/delay.h> CONTROL_START CLOCK_USED() ECMD_GLOBAL(t1, 0, uint16_t); ECMD_GLOBAL(var1, 0); ECMD_GLOBAL(var2, 0); ECMD_GLOBAL(aqua_mail_sent, 0, uint8_t) THREAD(start) if (!PIN_HIGH(WTR)) t1++; else t1=0; if (t1 > 10) var1=1; else var1 = 0; if (t1 > 400) var2=1; else var2 = 0; if (var1 == 1) PIN_CLEAR(LED1); else PIN_SET(LED1); if (var2 == 1){ if (aqua_mail_sent == 0){ PIN_CLEAR(LED2); mail_send(); aqua_mail_sent = 1; } var2 = 0; }else{ PIN_SET(LED2); } THREAD_END(start) ON STARTUP DO THREAD_START(start) END CONTROL_END </source> ==Levelshifter 3.3V 5V== <gallery perrow=1> File:Levelshifter.png </gallery><br> Source: http://wiki.senseye.org/rpi-ips/levelshifter/levelshifter.sch e53de4d53aeac3c37f04ecf34a7ed6d622f9fe59 0 494 1528 2016-01-25T06:08:52Z Djmaster 255 Created page with "{{i18n|BOOTP}} {{Module |NAME=BOOTP |MENUCONFIG={{Protocol}}->BOOTP |STATUS={{In_Development}} |PINNING=no |ECMD=no |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/eth..." wikitext text/x-wiki {{i18n|BOOTP}} {{Module |NAME=BOOTP |MENUCONFIG={{Protocol}}->BOOTP |STATUS={{In_Development}} |PINNING=no |ECMD=no |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/protocols/bootp https://github.com/ethersex/ethersex/tree/master/protocols/bootp] }} == Warum BOOTP? == Jeder kennt das Problem, wenn man eine Firmware erstellt hat, muss sie irgendwie in die Hardware kommen. Der gängige Weg, man [http://www.ethersex.de/index.php/Wie_flasht_man_ein_AVR-NET-IO flasht] die Hardware mit einem Programmieradapter über [[SPI]] oder [http://de.wikipedia.org/wiki/Joint_Test_Action_Group JTAG] ([http://www.atmel.com/dyn/resources/prod_documents/doc2475.pdf ATMEL]). In der Firmware muss die [http://de.wikipedia.org/wiki/MAC-Adresse MAC]- Adresse und die [http://de.wikipedia.org/wiki/IP-Adresse IP-Adresse] für die Hardware (µC) einkompiliert sein. Sie ist damit erstmal fix und kann nur nachträglich über das [[ECMD]]-Kommandos ip geändert werden. Schön wäre es, wenn man sich um die IP- Adresse nicht kümmern müsste und sie selbständig zum Bootzeitpunkt geladen wird. Und noch schöner wäre es, wenn der µC sich auch gleich die aktuelle Firmware selbst laden und flashen würde. Genau dies macht jetzt BOOTP.<br /> === BOOTP Startsequenz === [http://de.wikipedia.org/wiki/Bootstrap_Protocol BOOTP] ist der Vorläufer von [http://de.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol DHCP] mit dem einem Netzwerkgerät wie z.B. unserem µC eine IP-Adresse zugeordnet werden kann. Falls das Netzwerkgerät nicht über einen eigenen Festspeicher verfügt, kann auch die Firmware oder das Betriebssystem auf Anfrage des Netzwerkgerätes übertragen werden. Damit BOOTP funktioniert, muss ein Minimalprogramm mit dem BOOTP-Client auf dem Netzwerkgerät als Bootloader gespeicher sein. Bei einem PC liegt dieses Programm in der Netzwerkkarte. Auf unserem µC muss der Ethernet Bootloader geflasht sein. Dieser enthält eine eindeutige MAC-Adresse für das Netzwerkgerät, damit es adressiert werden kann.<br /> Zum Bootzeitpunkt verfügt der µC nur über die MAC-Adresse. Er stellt also als erstes eine Broadcast-Anfrage an alle Netzwerkteilnehmer mit der Bitte ihm eine IP-Adresse zu geben. Gibt es im Netzwerk einen anderen Rechner, der einen BOOTP- oder DHCP-Server enthält, so antwortet dieser Server und gibt ihm, sofern erlaubt, eine IP-Adresse, die Netmask und das Gateway. Ab nun an kann der µC unter dieser Adresse erreicht werden. Als nächstes fragt der µC den BOOTP-Server nach einer aktuellen Firmware. Dieser teilt ihm den Server und den Port mit, von dem die Firmware per [http://de.wikipedia.org/wiki/Trivial_File_Transfer_Protocol TFTP] geladen werden kann. Mit dieser Art des bootens, kann sehr elegant der µC geflasht und gleichzeitig eine IP-Adresse zugeordnet werden. Das eigentliche flashen der Firmware macht der µC damit selbständig. Mit dem Ethernet Bootloader und BOOTP ist es möglich, beliebige Firmware zu laden ohne ein Programmieradapter zu benutzen. Es muss lediglich die aktuelle Firmware auf dem BOOTP-Server hinterlegt sein und einmal der µC neu gestartet werden und schon flasht er sich selbständig ohne weiteres zutun nur über das Netzwerk. Diese Art des "flashens" geht schneller als mit einem Programmieradapter. In gut 10s ist die Firmware (ca. 50kB) geladen, geflasht und gestartet.<br /> === Voraussetzungen === Damit BOOTP benutzt werden kann müssen bestimmte Voraussetzungen erfüllt sein: * Nur mit einem ATMEGA644 oder größer läßt sich der 8KB Ethernet Bootloader flashen * Der Bootloader mit BOOTP belegt die letzten 8KB ab Adresse xE000 des Programmspeichers, die nicht mehr genutzt werden können * Die Programmgröße (Firmware) ist auf 56 KB beschränkt * Die Securebits sollten gesetzt sein, damit der Bootloader sich nicht selbst überschreiben kann * Es muss ein BOOTP- und TFTP- Server wie z.B. HahneDHCP o.ä. im Netzwerk erreichbar sein * Die Firmware muss als ethersex.bin auf dem TFTP-Server hinterlegt sein * In der Firmware muss die selbe MAC-Adresse verwendet werden wie im Bootloader von BOOTP == Konfiguration in menuconfig == Als Basis kann in nenuconfig die Option "Bootloader BOOTP" gewählt werden. Es ist zu beachten, dass '''keine spezifischen Einstellungen''' außer CPU-Typ und MCU frequency für die jeweilige Hardware im Bootloader durchgeführt werden. Die hardwarespezifischen Einstellungen werden in der Firmware vorgenommen. Folgende Optionen sollten in '''menuconfig''' aktiviert sein: * '''config-File''' ** Load a Default Configuration ---> *** (x) Ethernet Bootloader ** General Setup *** ATMEGA644 *** 16000000 MCU frequency (für AVR-NET-IO) *** (x) Build a bootloader *** (x) Teensy build ** Network ---> *** Ethernet (ENC28J60) support **** Etherrape MAC address 00:11:22:33:44:55 (bitte ändern!) *** (x) UDP support *** (x) UDP broadcast support *** (x) BOOTP (DHCP like) support ** Applications -> *** (x) TFTP support '''Wichtig!''' Die MAC-Adresse muss gesetzt sein. Die selbe MAC-Adresse muss in der Firmware später auch benutzt werden. Hier ist eine [http://www.phw-magdeburg.de/ethersex/BOOTP.config Konfigurationsdatei] für das Pollin AVR-NET-IO mit Addon (MAC: AC:DE:48:CE:23:C8 ): Damit man nun nicht jedes mal die MAC-Adresse neu einkompilieren muss, kann man sie auch händisch mit einem Texteditor in [http://www.phw-magdeburg.de/ethersex/ethersex.hex ''ethersex.hex''] ändern. <source lang="perl"> :10E000003EC0000066C0000064C0000062C00000A6 :10E0100060C000005EC000005CC000005AC000008C :10E0200058C0000056C0000054C0000052C000009C :10E0300050C0000014C100004CC000004AC00000E5 :10E0400048C0000046C0000044C0000042C00000BC :10E0500040C000003EC000003CC000003AC00000CC :10E0600038C0000036C0000034C0000032C00000DC :10E07000"ACDE48CE23C8"006F63746574000014BE24 :10E0800088E10FB6F89480936000109260000FBE94 :10E0900010926E0010926F001092700011241FBE3B :10E0A000CFEFD0E1DEBFCDBF11E0A0E0B1E0E8EE00 </source> == Flashen des Bootloaders == Nach der Konfiguration mit menuconfig den Bootloader mit ''make clean'' und ''make'' compilieren und mit einem Programmieradapter die Datei ''ethersex.hex'' flashen. Wenn eine alte Vorlage benutzt wird, muss ggf. die MAC-Adresse noch einmal geändert werden. Damit der Bootloader nicht durch die Firmware überschrieben wird, müssen die Lock-Bits folgendermaßen gesetzt sein: Für ATmega644: ''avrdude -p m644 -c ponyser -P /dev/ttyS0 -U lock:w:0x0F:m'' oder in Ponyprog: *(x) BootLock02 *(x) BootLock01 *(x) Lock2 *(x) Lock1 '''Achtung!''' Sollte der Bootloader neu geflasht werden, so müssen die Lock-Bits nach dem flashen immer wieder neu gesetzt werden. Wer keine Lust hat den Ethernet-Bootloader zu kompilieren, kann hier für das AVR-NET-IO mit Addon die Datei [http://www.phw-magdeburg.de/ethersex/ethersex.hex ''ethersex.hex''] verwenden. == BOOTP-Server konfigurieren (Windows) == Als BOOTP-Server verwende ich unter Windows '''hahneWin DHCP Server'''. Als Beispielkonfiguration ist bei mir folgendes eingestellt: * Kein DHCP sondern nur BOOTP aktiviert (zur Problemvermeidung bei bestehendem DHCP-Server) * 192.168.0.0 Netzwerk für BOOTP * 192.168.0.1 Rechner mit hahneWin DHCP Server und TFTP auf Port 69 * statische Adressvergabe über MAC-Adressen fest zugewiesen * 192.168.0.88 AVR-NET-IO mit MAC AC:DE:48:CE:23:C8 * 255.255.255.0 Netmask * 192.168.0.251 Gateway * 192.168.0.251 DNS-Server [[Datei:Hahne_DHCP.jpg]] Abb.: hahneWin DHCP Server Alle weiteren Einstellungen zum hahneWin DHCP Server können den nachfolgenden Links entnommen werden: Grundsätzlich werden als erstes unter ''Optionen->Einstellungen'' die Grundeinstellungen vorgenommen. * [http://www.phw-magdeburg.de/ethersex/Einstellungen_Allgemein.JPG Einstellungen Allgemein] * [http://www.phw-magdeburg.de/ethersex/Einstellungen_Schnittstellen.JPG Einstellungen Schnittstellen] * [http://www.phw-magdeburg.de/ethersex/Einstellungen_DHCP.JPG Einstellungen DHCP] * [http://www.phw-magdeburg.de/ethersex/Einstellungen_TFTP.JPG Einstellungen TFTP] * [http://www.phw-magdeburg.de/ethersex/Einstellungen_TFTP_Optionen.JPG Einstellungen TFTP Optionen] Im zweiten Schritt werden unter ''Optionen->Konfigurationsprofile verwalten'' das betreffende Netzwerk ausgewählt und mit ''Bearbeiten'' angepaßt. Im meinem Beispiel wurde der Profilname durch Ethersex ersetzt. Vorher stand dort If-2_0.1. * [http://www.phw-magdeburg.de/ethersex/Konfigurationsprofile.JPG Konfigurationsprofile] * [http://www.phw-magdeburg.de/ethersex/Ethersex_Basiskonfiguration.JPG Basiskonfiguration] * [http://www.phw-magdeburg.de/ethersex/Ethersex_DNS.JPG DNS] * [http://www.phw-magdeburg.de/ethersex/Ethersex_Boot.JPG Boot] Als letztes wird dann noch ein neuer statischer Eintrag über den Schaltknopf ''Hinzufügen'' für den µC erstellt. * [http://www.phw-magdeburg.de/ethersex/Statische_Eintraege.JPG Statische Einträge] Alle nicht aufgeführten Seiten enthalten die Standardeinstellungen und müssen nicht weiter modifiziert werden. So, nun sollte der BOOTP-Server laufen. Den Server kann man unter ''Datei->Server starten/beenden'' in den jeweiligen Zustand setzen. === Hahne BOOTP-Server verwenden === Wird jetzt der µC gebootet, so bezieht er seine Netzwerkeinstellungen vom BOOTP-Server, läd danach die Firmware und startet diese. Im Logfile des BOOTP-Server können die Aktivitäten verfolgt werden. Sobald dem µC eine IP-Adresse vergeben wurde erscheint ein grünes Häkchen vor der MAC-Adresse in der Hauptansicht. Folgende Bedingungen müssen beachtet werden: * hat der µC noch keine Firmware geladen, so wird diese per TFTP im BOOTP-Prozess geladen und geflasht * ist schon eine Firmware im µC geflasht, so werden nur die Netzwerkparameter nach einem Reboot oder Power on/off geladen und die vorhandene Firmware gestartet * um die Firmware erleut zu laden, muss mit dem [[ECMD]] Kommando ''wdreset'' oder ''bootloader'' der µC "resettet" werden == BOOTP-Server konfigurieren (Linux) == Als BOOTP-Server verwende ich unter Linux '''dhcpd3'''. Als Beispielkonfiguration ist bei mir folgendes eingestellt: * Kein DHCP sondern nur BOOTP aktiviert (zur Problemvermeidung bei bestehendem DHCP-Server) * 192.168.30.0 Netzwerk für BOOTP * 192.168.30.134 Rechner mit DHCPD3 Server und TFTP auf Port 69 * statische Adressvergabe über MAC-Adressen fest zugewiesen * 192.168.30.10 AVR-NET-IO mit MAC AC:DE:48:CE:23:C8 * 255.255.255.0 Netmask * 192.168.30.1 Gateway * 192.168.30.1 DNS-Server Die folgende Konfiguration verfügt nicht über eine dynamische IP-Range. Dies bedeutet, dass diese Konfiguration nicht mit einem bereits vorhanden DHCP Server ins Gehege kommt. Dem ethersex wird zum Starten eine feste IP zugewiesen. Der Ablauf: #DHCP Server und TFTP Server müssen gestartet sein #Dann das AVR Net-IO in die Steckdose #Ethersex fragt mit seiner Netzwerkadresse ac:de:48:ce:23:c8 per bootp nach einer IP-Adresse #Der DHCP Server schaut in seiner Liste nach ac:de:48:ce:23:c8, findet diese und die IP 192.168.30.10 zusammen mit der TFTP Server IP 192.168.30.134 und dem Dateinamen ethersex.bin zurück an Ethersex #Ethersex kann nun eine IP Verbindung zum TFTP Server 192.168.30.134 aufbauen und lädt die Datei ethersex.bin #Anschlißend startet Ethersex mit der ethersex.bin ===DHCP-Server konfigurieren === sudo apt-get install dhcp3-server Anschließend muss die Konfigurationsdatei /etc/dhcp3/dhcpd.conf, wie folgt bearbeitet werden. Die IP Adressen musst Du an Deine Gegebenheiten anpassen. <pre> default-lease-time 86400; max-lease-time 2592000; authoritative; subnet 192.168.30.0 netmask 255.255.255.0 { option subnet-mask 255.255.255.0; # subnet maske option routers 192.168.30.1; # Gateway option domain-name-servers 192.168.30.1; # DNS Server ddns-update-style none; # Neue Clients werden dem DNS Server nicht mitgeteilt next-server 192.168.30.134; # TFTP Server host netio { hardware ethernet ac:de:48:ce:23:c8; # mac adresse des pollin net io fixed-address 192.168.30.10; # Eine freie IP-Adresse im lokalen Netz filename "ethersex.bin"; # bootfile (Achtung das ethersex.bin file nehmen!) } } </pre> Anschließend kann der DHCP Server gestartet/neu gestartet werden: sudo /etc/init.d/dhcp3-server restart ===TFTP Server konfigurieren=== Die Konfiguration des TFTP Servers ist ziemlich einfach. Dieser muss nur installiert und gestartet werden: sudo apt-get install tftpd-hpa Die vom Makefile generierte ethersex.bin Datei muss dann nur noch nach /var/lib/tftpboot kopiert werden. Den TFTP Server startetn/neu starten sudo /etc/init.d/tftpd-hpa restart == Bekannte Probleme == Ist im µC bereits eine Firmware geflasht, so sollten durch den BOOTP-Mechanismus die Netzwerkparameter wie IP, Gateway, DNS und Gateway bezogen werden. Laut Logfile vom haneWin DHCP Server erfolgt dies auch. Danach sollte dann die Firmware mit genau diesen Netzwerkparametern gestartet werden. Dies geschiet aber nicht, da vermutlich die Netzwerkparameter nicht an die Firmware weitergereicht werden. Es werden die alten Netzwerkparameter geladen trotz der Einstellung in ''menuconfig'', dass BOOTP verwendet werden soll. Man erkennt mit dem Kommando ''arp -a'' in der Windows-Konsole, dass nach dem Booten die neuen Netzwerkparameter mit der IP vom BOOTP-Server vergeben wurden. Im zweiten Schritt, wenn der µC die Firmware läd, jedoch die alte letzte IP-Adresse benutzt. Daher muss man mit ''arp -d'' die ARP-Tabelle löschen und sich unter der alten IP in den µC mit telnet (siehe [[ECMD Protocols]]) einloggen und mit den Befehlen ''ip, netmask, gw, dns server'' manuell auf die neuen Werte setzen. Alternativ kann man den µC zwingen die neue Firmware zu laden, die dann aber intern die gleichen Netzwerkparameter wie der BOOTP-Server haben muss. Schade eigentlich, so hätte man sehr elegant mit dem BOOTP-Server die Netzwerkparameter zur Bootzeit vergeben können. Ich habe gerade noch einmal in den Quellen nachgesehen, dort werden die Netzwerkparameter von BOOTP nur im EEPROM des µC gespeichert, wenn ''Write BOOTP data to EEPROM'' in ''menuconfig'' ausgewählt ist. Damit lassen sich die Netzwerkparameter zwischenspeichern und stehen nach dem Start der Firmware als Default zur Verfügung. Per Default wird diese Option nicht geladen. Das Problem sollte sich damit beheben lassen. Das habe ich aber bisher noch nicht getestet. Wenn dem so ist, sollte die Default-Konfiguration des ''Ethernet Bootloader'' entsprechend angepasst werden. Ist die zu ladende Firmware größer als 56kB, so wird die Firmware nicht richtig geflasht, da ab xE000 der Ethernet-Bootloader den Bereich mit gesetzten Secure-Bits blockiert. == Nützliche Links == * [http://www.atmel.com/dyn/resources/prod_documents/doc2475.pdf ATMEL JTAG-Interface-Beschreibung] * [http://www.atmel.com/dyn/resources/prod_documents/doc2593.pdf Datenblatt zum ATMEGA644] 6cffc4ac8076c2122fd9d1d318eb19b9217dda28 1530 1528 2016-01-25T06:17:35Z Djmaster 255 wikitext text/x-wiki {{i18n|BOOTP}} {{Module |NAME=BOOTP |MENUCONFIG={{Protocol}}->BOOTP |STATUS={{In_Development}} |PINNING=no |ECMD=no |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/protocols/bootp https://github.com/ethersex/ethersex/tree/master/protocols/bootp] }} * <b>Direktkopie von old.ethersex.wiki.. Überarbeite ich die Tage. 25.01.2016</b> [User:Djmaster] == Warum BOOTP? == Jeder kennt das Problem, wenn man eine Firmware erstellt hat, muss sie irgendwie in die Hardware kommen. Der gängige Weg, man [http://www.ethersex.de/index.php/Wie_flasht_man_ein_AVR-NET-IO flasht] die Hardware mit einem Programmieradapter über [[SPI]] oder [http://de.wikipedia.org/wiki/Joint_Test_Action_Group JTAG] ([http://www.atmel.com/dyn/resources/prod_documents/doc2475.pdf ATMEL]). In der Firmware muss die [http://de.wikipedia.org/wiki/MAC-Adresse MAC]- Adresse und die [http://de.wikipedia.org/wiki/IP-Adresse IP-Adresse] für die Hardware (µC) einkompiliert sein. Sie ist damit erstmal fix und kann nur nachträglich über das [[ECMD]]-Kommandos ip geändert werden. Schön wäre es, wenn man sich um die IP- Adresse nicht kümmern müsste und sie selbständig zum Bootzeitpunkt geladen wird. Und noch schöner wäre es, wenn der µC sich auch gleich die aktuelle Firmware selbst laden und flashen würde. Genau dies macht jetzt BOOTP.<br /> === BOOTP Startsequenz === [http://de.wikipedia.org/wiki/Bootstrap_Protocol BOOTP] ist der Vorläufer von [http://de.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol DHCP] mit dem einem Netzwerkgerät wie z.B. unserem µC eine IP-Adresse zugeordnet werden kann. Falls das Netzwerkgerät nicht über einen eigenen Festspeicher verfügt, kann auch die Firmware oder das Betriebssystem auf Anfrage des Netzwerkgerätes übertragen werden. Damit BOOTP funktioniert, muss ein Minimalprogramm mit dem BOOTP-Client auf dem Netzwerkgerät als Bootloader gespeicher sein. Bei einem PC liegt dieses Programm in der Netzwerkkarte. Auf unserem µC muss der Ethernet Bootloader geflasht sein. Dieser enthält eine eindeutige MAC-Adresse für das Netzwerkgerät, damit es adressiert werden kann.<br /> Zum Bootzeitpunkt verfügt der µC nur über die MAC-Adresse. Er stellt also als erstes eine Broadcast-Anfrage an alle Netzwerkteilnehmer mit der Bitte ihm eine IP-Adresse zu geben. Gibt es im Netzwerk einen anderen Rechner, der einen BOOTP- oder DHCP-Server enthält, so antwortet dieser Server und gibt ihm, sofern erlaubt, eine IP-Adresse, die Netmask und das Gateway. Ab nun an kann der µC unter dieser Adresse erreicht werden. Als nächstes fragt der µC den BOOTP-Server nach einer aktuellen Firmware. Dieser teilt ihm den Server und den Port mit, von dem die Firmware per [http://de.wikipedia.org/wiki/Trivial_File_Transfer_Protocol TFTP] geladen werden kann. Mit dieser Art des bootens, kann sehr elegant der µC geflasht und gleichzeitig eine IP-Adresse zugeordnet werden. Das eigentliche flashen der Firmware macht der µC damit selbständig. Mit dem Ethernet Bootloader und BOOTP ist es möglich, beliebige Firmware zu laden ohne ein Programmieradapter zu benutzen. Es muss lediglich die aktuelle Firmware auf dem BOOTP-Server hinterlegt sein und einmal der µC neu gestartet werden und schon flasht er sich selbständig ohne weiteres zutun nur über das Netzwerk. Diese Art des "flashens" geht schneller als mit einem Programmieradapter. In gut 10s ist die Firmware (ca. 50kB) geladen, geflasht und gestartet.<br /> === Voraussetzungen === Damit BOOTP benutzt werden kann müssen bestimmte Voraussetzungen erfüllt sein: * Nur mit einem ATMEGA644 oder größer läßt sich der 8KB Ethernet Bootloader flashen * Der Bootloader mit BOOTP belegt die letzten 8KB ab Adresse xE000 des Programmspeichers, die nicht mehr genutzt werden können * Die Programmgröße (Firmware) ist auf 56 KB beschränkt * Die Securebits sollten gesetzt sein, damit der Bootloader sich nicht selbst überschreiben kann * Es muss ein BOOTP- und TFTP- Server wie z.B. HahneDHCP o.ä. im Netzwerk erreichbar sein * Die Firmware muss als ethersex.bin auf dem TFTP-Server hinterlegt sein * In der Firmware muss die selbe MAC-Adresse verwendet werden wie im Bootloader von BOOTP == Konfiguration in menuconfig == Als Basis kann in nenuconfig die Option "Bootloader BOOTP" gewählt werden. Es ist zu beachten, dass '''keine spezifischen Einstellungen''' außer CPU-Typ und MCU frequency für die jeweilige Hardware im Bootloader durchgeführt werden. Die hardwarespezifischen Einstellungen werden in der Firmware vorgenommen. Folgende Optionen sollten in '''menuconfig''' aktiviert sein: * '''config-File''' ** Load a Default Configuration ---> *** (x) Ethernet Bootloader ** General Setup *** ATMEGA644 *** 16000000 MCU frequency (für AVR-NET-IO) *** (x) Build a bootloader *** (x) Teensy build ** Network ---> *** Ethernet (ENC28J60) support **** Etherrape MAC address 00:11:22:33:44:55 (bitte ändern!) *** (x) UDP support *** (x) UDP broadcast support *** (x) BOOTP (DHCP like) support ** Applications -> *** (x) TFTP support '''Wichtig!''' Die MAC-Adresse muss gesetzt sein. Die selbe MAC-Adresse muss in der Firmware später auch benutzt werden. Hier ist eine [http://www.phw-magdeburg.de/ethersex/BOOTP.config Konfigurationsdatei] für das Pollin AVR-NET-IO mit Addon (MAC: AC:DE:48:CE:23:C8 ): Damit man nun nicht jedes mal die MAC-Adresse neu einkompilieren muss, kann man sie auch händisch mit einem Texteditor in [http://www.phw-magdeburg.de/ethersex/ethersex.hex ''ethersex.hex''] ändern. <source lang="perl"> :10E000003EC0000066C0000064C0000062C00000A6 :10E0100060C000005EC000005CC000005AC000008C :10E0200058C0000056C0000054C0000052C000009C :10E0300050C0000014C100004CC000004AC00000E5 :10E0400048C0000046C0000044C0000042C00000BC :10E0500040C000003EC000003CC000003AC00000CC :10E0600038C0000036C0000034C0000032C00000DC :10E07000"ACDE48CE23C8"006F63746574000014BE24 :10E0800088E10FB6F89480936000109260000FBE94 :10E0900010926E0010926F001092700011241FBE3B :10E0A000CFEFD0E1DEBFCDBF11E0A0E0B1E0E8EE00 </source> == Flashen des Bootloaders == Nach der Konfiguration mit menuconfig den Bootloader mit ''make clean'' und ''make'' compilieren und mit einem Programmieradapter die Datei ''ethersex.hex'' flashen. Wenn eine alte Vorlage benutzt wird, muss ggf. die MAC-Adresse noch einmal geändert werden. Damit der Bootloader nicht durch die Firmware überschrieben wird, müssen die Lock-Bits folgendermaßen gesetzt sein: Für ATmega644: ''avrdude -p m644 -c ponyser -P /dev/ttyS0 -U lock:w:0x0F:m'' oder in Ponyprog: *(x) BootLock02 *(x) BootLock01 *(x) Lock2 *(x) Lock1 '''Achtung!''' Sollte der Bootloader neu geflasht werden, so müssen die Lock-Bits nach dem flashen immer wieder neu gesetzt werden. Wer keine Lust hat den Ethernet-Bootloader zu kompilieren, kann hier für das AVR-NET-IO mit Addon die Datei [http://www.phw-magdeburg.de/ethersex/ethersex.hex ''ethersex.hex''] verwenden. == BOOTP-Server konfigurieren (Windows) == Als BOOTP-Server verwende ich unter Windows '''hahneWin DHCP Server'''. Als Beispielkonfiguration ist bei mir folgendes eingestellt: * Kein DHCP sondern nur BOOTP aktiviert (zur Problemvermeidung bei bestehendem DHCP-Server) * 192.168.0.0 Netzwerk für BOOTP * 192.168.0.1 Rechner mit hahneWin DHCP Server und TFTP auf Port 69 * statische Adressvergabe über MAC-Adressen fest zugewiesen * 192.168.0.88 AVR-NET-IO mit MAC AC:DE:48:CE:23:C8 * 255.255.255.0 Netmask * 192.168.0.251 Gateway * 192.168.0.251 DNS-Server [[Datei:Hahne_DHCP.jpg]] Abb.: hahneWin DHCP Server Alle weiteren Einstellungen zum hahneWin DHCP Server können den nachfolgenden Links entnommen werden: Grundsätzlich werden als erstes unter ''Optionen->Einstellungen'' die Grundeinstellungen vorgenommen. * [http://www.phw-magdeburg.de/ethersex/Einstellungen_Allgemein.JPG Einstellungen Allgemein] * [http://www.phw-magdeburg.de/ethersex/Einstellungen_Schnittstellen.JPG Einstellungen Schnittstellen] * [http://www.phw-magdeburg.de/ethersex/Einstellungen_DHCP.JPG Einstellungen DHCP] * [http://www.phw-magdeburg.de/ethersex/Einstellungen_TFTP.JPG Einstellungen TFTP] * [http://www.phw-magdeburg.de/ethersex/Einstellungen_TFTP_Optionen.JPG Einstellungen TFTP Optionen] Im zweiten Schritt werden unter ''Optionen->Konfigurationsprofile verwalten'' das betreffende Netzwerk ausgewählt und mit ''Bearbeiten'' angepaßt. Im meinem Beispiel wurde der Profilname durch Ethersex ersetzt. Vorher stand dort If-2_0.1. * [http://www.phw-magdeburg.de/ethersex/Konfigurationsprofile.JPG Konfigurationsprofile] * [http://www.phw-magdeburg.de/ethersex/Ethersex_Basiskonfiguration.JPG Basiskonfiguration] * [http://www.phw-magdeburg.de/ethersex/Ethersex_DNS.JPG DNS] * [http://www.phw-magdeburg.de/ethersex/Ethersex_Boot.JPG Boot] Als letztes wird dann noch ein neuer statischer Eintrag über den Schaltknopf ''Hinzufügen'' für den µC erstellt. * [http://www.phw-magdeburg.de/ethersex/Statische_Eintraege.JPG Statische Einträge] Alle nicht aufgeführten Seiten enthalten die Standardeinstellungen und müssen nicht weiter modifiziert werden. So, nun sollte der BOOTP-Server laufen. Den Server kann man unter ''Datei->Server starten/beenden'' in den jeweiligen Zustand setzen. === Hahne BOOTP-Server verwenden === Wird jetzt der µC gebootet, so bezieht er seine Netzwerkeinstellungen vom BOOTP-Server, läd danach die Firmware und startet diese. Im Logfile des BOOTP-Server können die Aktivitäten verfolgt werden. Sobald dem µC eine IP-Adresse vergeben wurde erscheint ein grünes Häkchen vor der MAC-Adresse in der Hauptansicht. Folgende Bedingungen müssen beachtet werden: * hat der µC noch keine Firmware geladen, so wird diese per TFTP im BOOTP-Prozess geladen und geflasht * ist schon eine Firmware im µC geflasht, so werden nur die Netzwerkparameter nach einem Reboot oder Power on/off geladen und die vorhandene Firmware gestartet * um die Firmware erleut zu laden, muss mit dem [[ECMD]] Kommando ''wdreset'' oder ''bootloader'' der µC "resettet" werden == BOOTP-Server konfigurieren (Linux) == Als BOOTP-Server verwende ich unter Linux '''dhcpd3'''. Als Beispielkonfiguration ist bei mir folgendes eingestellt: * Kein DHCP sondern nur BOOTP aktiviert (zur Problemvermeidung bei bestehendem DHCP-Server) * 192.168.30.0 Netzwerk für BOOTP * 192.168.30.134 Rechner mit DHCPD3 Server und TFTP auf Port 69 * statische Adressvergabe über MAC-Adressen fest zugewiesen * 192.168.30.10 AVR-NET-IO mit MAC AC:DE:48:CE:23:C8 * 255.255.255.0 Netmask * 192.168.30.1 Gateway * 192.168.30.1 DNS-Server Die folgende Konfiguration verfügt nicht über eine dynamische IP-Range. Dies bedeutet, dass diese Konfiguration nicht mit einem bereits vorhanden DHCP Server ins Gehege kommt. Dem ethersex wird zum Starten eine feste IP zugewiesen. Der Ablauf: #DHCP Server und TFTP Server müssen gestartet sein #Dann das AVR Net-IO in die Steckdose #Ethersex fragt mit seiner Netzwerkadresse ac:de:48:ce:23:c8 per bootp nach einer IP-Adresse #Der DHCP Server schaut in seiner Liste nach ac:de:48:ce:23:c8, findet diese und die IP 192.168.30.10 zusammen mit der TFTP Server IP 192.168.30.134 und dem Dateinamen ethersex.bin zurück an Ethersex #Ethersex kann nun eine IP Verbindung zum TFTP Server 192.168.30.134 aufbauen und lädt die Datei ethersex.bin #Anschlißend startet Ethersex mit der ethersex.bin ===DHCP-Server konfigurieren === sudo apt-get install dhcp3-server Anschließend muss die Konfigurationsdatei /etc/dhcp3/dhcpd.conf, wie folgt bearbeitet werden. Die IP Adressen musst Du an Deine Gegebenheiten anpassen. <pre> default-lease-time 86400; max-lease-time 2592000; authoritative; subnet 192.168.30.0 netmask 255.255.255.0 { option subnet-mask 255.255.255.0; # subnet maske option routers 192.168.30.1; # Gateway option domain-name-servers 192.168.30.1; # DNS Server ddns-update-style none; # Neue Clients werden dem DNS Server nicht mitgeteilt next-server 192.168.30.134; # TFTP Server host netio { hardware ethernet ac:de:48:ce:23:c8; # mac adresse des pollin net io fixed-address 192.168.30.10; # Eine freie IP-Adresse im lokalen Netz filename "ethersex.bin"; # bootfile (Achtung das ethersex.bin file nehmen!) } } </pre> Anschließend kann der DHCP Server gestartet/neu gestartet werden: sudo /etc/init.d/dhcp3-server restart ===TFTP Server konfigurieren=== Die Konfiguration des TFTP Servers ist ziemlich einfach. Dieser muss nur installiert und gestartet werden: sudo apt-get install tftpd-hpa Die vom Makefile generierte ethersex.bin Datei muss dann nur noch nach /var/lib/tftpboot kopiert werden. Den TFTP Server startetn/neu starten sudo /etc/init.d/tftpd-hpa restart == Bekannte Probleme == Ist im µC bereits eine Firmware geflasht, so sollten durch den BOOTP-Mechanismus die Netzwerkparameter wie IP, Gateway, DNS und Gateway bezogen werden. Laut Logfile vom haneWin DHCP Server erfolgt dies auch. Danach sollte dann die Firmware mit genau diesen Netzwerkparametern gestartet werden. Dies geschiet aber nicht, da vermutlich die Netzwerkparameter nicht an die Firmware weitergereicht werden. Es werden die alten Netzwerkparameter geladen trotz der Einstellung in ''menuconfig'', dass BOOTP verwendet werden soll. Man erkennt mit dem Kommando ''arp -a'' in der Windows-Konsole, dass nach dem Booten die neuen Netzwerkparameter mit der IP vom BOOTP-Server vergeben wurden. Im zweiten Schritt, wenn der µC die Firmware läd, jedoch die alte letzte IP-Adresse benutzt. Daher muss man mit ''arp -d'' die ARP-Tabelle löschen und sich unter der alten IP in den µC mit telnet (siehe [[ECMD Protocols]]) einloggen und mit den Befehlen ''ip, netmask, gw, dns server'' manuell auf die neuen Werte setzen. Alternativ kann man den µC zwingen die neue Firmware zu laden, die dann aber intern die gleichen Netzwerkparameter wie der BOOTP-Server haben muss. Schade eigentlich, so hätte man sehr elegant mit dem BOOTP-Server die Netzwerkparameter zur Bootzeit vergeben können. Ich habe gerade noch einmal in den Quellen nachgesehen, dort werden die Netzwerkparameter von BOOTP nur im EEPROM des µC gespeichert, wenn ''Write BOOTP data to EEPROM'' in ''menuconfig'' ausgewählt ist. Damit lassen sich die Netzwerkparameter zwischenspeichern und stehen nach dem Start der Firmware als Default zur Verfügung. Per Default wird diese Option nicht geladen. Das Problem sollte sich damit beheben lassen. Das habe ich aber bisher noch nicht getestet. Wenn dem so ist, sollte die Default-Konfiguration des ''Ethernet Bootloader'' entsprechend angepasst werden. Ist die zu ladende Firmware größer als 56kB, so wird die Firmware nicht richtig geflasht, da ab xE000 der Ethernet-Bootloader den Bereich mit gesetzten Secure-Bits blockiert. == Nützliche Links == * [http://www.atmel.com/dyn/resources/prod_documents/doc2475.pdf ATMEL JTAG-Interface-Beschreibung] * [http://www.atmel.com/dyn/resources/prod_documents/doc2593.pdf Datenblatt zum ATMEGA644] bbdf26a9137c93431cbf3096fbcbfc17eed0b7d8 1533 1530 2016-01-25T06:22:33Z Djmaster 255 /* BOOTP-Server konfigurieren (Windows) */ wikitext text/x-wiki {{i18n|BOOTP}} {{Module |NAME=BOOTP |MENUCONFIG={{Protocol}}->BOOTP |STATUS={{In_Development}} |PINNING=no |ECMD=no |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/protocols/bootp https://github.com/ethersex/ethersex/tree/master/protocols/bootp] }} * <b>Direktkopie von old.ethersex.wiki.. Überarbeite ich die Tage. 25.01.2016</b> [User:Djmaster] == Warum BOOTP? == Jeder kennt das Problem, wenn man eine Firmware erstellt hat, muss sie irgendwie in die Hardware kommen. Der gängige Weg, man [http://www.ethersex.de/index.php/Wie_flasht_man_ein_AVR-NET-IO flasht] die Hardware mit einem Programmieradapter über [[SPI]] oder [http://de.wikipedia.org/wiki/Joint_Test_Action_Group JTAG] ([http://www.atmel.com/dyn/resources/prod_documents/doc2475.pdf ATMEL]). In der Firmware muss die [http://de.wikipedia.org/wiki/MAC-Adresse MAC]- Adresse und die [http://de.wikipedia.org/wiki/IP-Adresse IP-Adresse] für die Hardware (µC) einkompiliert sein. Sie ist damit erstmal fix und kann nur nachträglich über das [[ECMD]]-Kommandos ip geändert werden. Schön wäre es, wenn man sich um die IP- Adresse nicht kümmern müsste und sie selbständig zum Bootzeitpunkt geladen wird. Und noch schöner wäre es, wenn der µC sich auch gleich die aktuelle Firmware selbst laden und flashen würde. Genau dies macht jetzt BOOTP.<br /> === BOOTP Startsequenz === [http://de.wikipedia.org/wiki/Bootstrap_Protocol BOOTP] ist der Vorläufer von [http://de.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol DHCP] mit dem einem Netzwerkgerät wie z.B. unserem µC eine IP-Adresse zugeordnet werden kann. Falls das Netzwerkgerät nicht über einen eigenen Festspeicher verfügt, kann auch die Firmware oder das Betriebssystem auf Anfrage des Netzwerkgerätes übertragen werden. Damit BOOTP funktioniert, muss ein Minimalprogramm mit dem BOOTP-Client auf dem Netzwerkgerät als Bootloader gespeicher sein. Bei einem PC liegt dieses Programm in der Netzwerkkarte. Auf unserem µC muss der Ethernet Bootloader geflasht sein. Dieser enthält eine eindeutige MAC-Adresse für das Netzwerkgerät, damit es adressiert werden kann.<br /> Zum Bootzeitpunkt verfügt der µC nur über die MAC-Adresse. Er stellt also als erstes eine Broadcast-Anfrage an alle Netzwerkteilnehmer mit der Bitte ihm eine IP-Adresse zu geben. Gibt es im Netzwerk einen anderen Rechner, der einen BOOTP- oder DHCP-Server enthält, so antwortet dieser Server und gibt ihm, sofern erlaubt, eine IP-Adresse, die Netmask und das Gateway. Ab nun an kann der µC unter dieser Adresse erreicht werden. Als nächstes fragt der µC den BOOTP-Server nach einer aktuellen Firmware. Dieser teilt ihm den Server und den Port mit, von dem die Firmware per [http://de.wikipedia.org/wiki/Trivial_File_Transfer_Protocol TFTP] geladen werden kann. Mit dieser Art des bootens, kann sehr elegant der µC geflasht und gleichzeitig eine IP-Adresse zugeordnet werden. Das eigentliche flashen der Firmware macht der µC damit selbständig. Mit dem Ethernet Bootloader und BOOTP ist es möglich, beliebige Firmware zu laden ohne ein Programmieradapter zu benutzen. Es muss lediglich die aktuelle Firmware auf dem BOOTP-Server hinterlegt sein und einmal der µC neu gestartet werden und schon flasht er sich selbständig ohne weiteres zutun nur über das Netzwerk. Diese Art des "flashens" geht schneller als mit einem Programmieradapter. In gut 10s ist die Firmware (ca. 50kB) geladen, geflasht und gestartet.<br /> === Voraussetzungen === Damit BOOTP benutzt werden kann müssen bestimmte Voraussetzungen erfüllt sein: * Nur mit einem ATMEGA644 oder größer läßt sich der 8KB Ethernet Bootloader flashen * Der Bootloader mit BOOTP belegt die letzten 8KB ab Adresse xE000 des Programmspeichers, die nicht mehr genutzt werden können * Die Programmgröße (Firmware) ist auf 56 KB beschränkt * Die Securebits sollten gesetzt sein, damit der Bootloader sich nicht selbst überschreiben kann * Es muss ein BOOTP- und TFTP- Server wie z.B. HahneDHCP o.ä. im Netzwerk erreichbar sein * Die Firmware muss als ethersex.bin auf dem TFTP-Server hinterlegt sein * In der Firmware muss die selbe MAC-Adresse verwendet werden wie im Bootloader von BOOTP == Konfiguration in menuconfig == Als Basis kann in nenuconfig die Option "Bootloader BOOTP" gewählt werden. Es ist zu beachten, dass '''keine spezifischen Einstellungen''' außer CPU-Typ und MCU frequency für die jeweilige Hardware im Bootloader durchgeführt werden. Die hardwarespezifischen Einstellungen werden in der Firmware vorgenommen. Folgende Optionen sollten in '''menuconfig''' aktiviert sein: * '''config-File''' ** Load a Default Configuration ---> *** (x) Ethernet Bootloader ** General Setup *** ATMEGA644 *** 16000000 MCU frequency (für AVR-NET-IO) *** (x) Build a bootloader *** (x) Teensy build ** Network ---> *** Ethernet (ENC28J60) support **** Etherrape MAC address 00:11:22:33:44:55 (bitte ändern!) *** (x) UDP support *** (x) UDP broadcast support *** (x) BOOTP (DHCP like) support ** Applications -> *** (x) TFTP support '''Wichtig!''' Die MAC-Adresse muss gesetzt sein. Die selbe MAC-Adresse muss in der Firmware später auch benutzt werden. Hier ist eine [http://www.phw-magdeburg.de/ethersex/BOOTP.config Konfigurationsdatei] für das Pollin AVR-NET-IO mit Addon (MAC: AC:DE:48:CE:23:C8 ): Damit man nun nicht jedes mal die MAC-Adresse neu einkompilieren muss, kann man sie auch händisch mit einem Texteditor in [http://www.phw-magdeburg.de/ethersex/ethersex.hex ''ethersex.hex''] ändern. <source lang="perl"> :10E000003EC0000066C0000064C0000062C00000A6 :10E0100060C000005EC000005CC000005AC000008C :10E0200058C0000056C0000054C0000052C000009C :10E0300050C0000014C100004CC000004AC00000E5 :10E0400048C0000046C0000044C0000042C00000BC :10E0500040C000003EC000003CC000003AC00000CC :10E0600038C0000036C0000034C0000032C00000DC :10E07000"ACDE48CE23C8"006F63746574000014BE24 :10E0800088E10FB6F89480936000109260000FBE94 :10E0900010926E0010926F001092700011241FBE3B :10E0A000CFEFD0E1DEBFCDBF11E0A0E0B1E0E8EE00 </source> == Flashen des Bootloaders == Nach der Konfiguration mit menuconfig den Bootloader mit ''make clean'' und ''make'' compilieren und mit einem Programmieradapter die Datei ''ethersex.hex'' flashen. Wenn eine alte Vorlage benutzt wird, muss ggf. die MAC-Adresse noch einmal geändert werden. Damit der Bootloader nicht durch die Firmware überschrieben wird, müssen die Lock-Bits folgendermaßen gesetzt sein: Für ATmega644: ''avrdude -p m644 -c ponyser -P /dev/ttyS0 -U lock:w:0x0F:m'' oder in Ponyprog: *(x) BootLock02 *(x) BootLock01 *(x) Lock2 *(x) Lock1 '''Achtung!''' Sollte der Bootloader neu geflasht werden, so müssen die Lock-Bits nach dem flashen immer wieder neu gesetzt werden. Wer keine Lust hat den Ethernet-Bootloader zu kompilieren, kann hier für das AVR-NET-IO mit Addon die Datei [http://www.phw-magdeburg.de/ethersex/ethersex.hex ''ethersex.hex''] verwenden. == BOOTP-Server konfigurieren (Windows) == Als BOOTP-Server verwende ich unter Windows '''hahneWin DHCP Server'''. Als Beispielkonfiguration ist bei mir folgendes eingestellt: * Kein DHCP sondern nur BOOTP aktiviert (zur Problemvermeidung bei bestehendem DHCP-Server) * 192.168.0.0 Netzwerk für BOOTP * 192.168.0.1 Rechner mit hahneWin DHCP Server und TFTP auf Port 69 * statische Adressvergabe über MAC-Adressen fest zugewiesen * 192.168.0.88 AVR-NET-IO mit MAC AC:DE:48:CE:23:C8 * 255.255.255.0 Netmask * 192.168.0.251 Gateway * 192.168.0.251 DNS-Server [[File:Hahne_DHCP.jpg]] Abb.: hahneWin DHCP Server Alle weiteren Einstellungen zum hahneWin DHCP Server können den nachfolgenden Links entnommen werden: Grundsätzlich werden als erstes unter ''Optionen->Einstellungen'' die Grundeinstellungen vorgenommen. * [http://www.phw-magdeburg.de/ethersex/Einstellungen_Allgemein.JPG Einstellungen Allgemein] * [http://www.phw-magdeburg.de/ethersex/Einstellungen_Schnittstellen.JPG Einstellungen Schnittstellen] * [http://www.phw-magdeburg.de/ethersex/Einstellungen_DHCP.JPG Einstellungen DHCP] * [http://www.phw-magdeburg.de/ethersex/Einstellungen_TFTP.JPG Einstellungen TFTP] * [http://www.phw-magdeburg.de/ethersex/Einstellungen_TFTP_Optionen.JPG Einstellungen TFTP Optionen] Im zweiten Schritt werden unter ''Optionen->Konfigurationsprofile verwalten'' das betreffende Netzwerk ausgewählt und mit ''Bearbeiten'' angepaßt. Im meinem Beispiel wurde der Profilname durch Ethersex ersetzt. Vorher stand dort If-2_0.1. * [http://www.phw-magdeburg.de/ethersex/Konfigurationsprofile.JPG Konfigurationsprofile] * [http://www.phw-magdeburg.de/ethersex/Ethersex_Basiskonfiguration.JPG Basiskonfiguration] * [http://www.phw-magdeburg.de/ethersex/Ethersex_DNS.JPG DNS] * [http://www.phw-magdeburg.de/ethersex/Ethersex_Boot.JPG Boot] Als letztes wird dann noch ein neuer statischer Eintrag über den Schaltknopf ''Hinzufügen'' für den µC erstellt. * [http://www.phw-magdeburg.de/ethersex/Statische_Eintraege.JPG Statische Einträge] Alle nicht aufgeführten Seiten enthalten die Standardeinstellungen und müssen nicht weiter modifiziert werden. So, nun sollte der BOOTP-Server laufen. Den Server kann man unter ''Datei->Server starten/beenden'' in den jeweiligen Zustand setzen. === Hahne BOOTP-Server verwenden === Wird jetzt der µC gebootet, so bezieht er seine Netzwerkeinstellungen vom BOOTP-Server, läd danach die Firmware und startet diese. Im Logfile des BOOTP-Server können die Aktivitäten verfolgt werden. Sobald dem µC eine IP-Adresse vergeben wurde erscheint ein grünes Häkchen vor der MAC-Adresse in der Hauptansicht. Folgende Bedingungen müssen beachtet werden: * hat der µC noch keine Firmware geladen, so wird diese per TFTP im BOOTP-Prozess geladen und geflasht * ist schon eine Firmware im µC geflasht, so werden nur die Netzwerkparameter nach einem Reboot oder Power on/off geladen und die vorhandene Firmware gestartet * um die Firmware erleut zu laden, muss mit dem [[ECMD]] Kommando ''wdreset'' oder ''bootloader'' der µC "resettet" werden == BOOTP-Server konfigurieren (Linux) == Als BOOTP-Server verwende ich unter Linux '''dhcpd3'''. Als Beispielkonfiguration ist bei mir folgendes eingestellt: * Kein DHCP sondern nur BOOTP aktiviert (zur Problemvermeidung bei bestehendem DHCP-Server) * 192.168.30.0 Netzwerk für BOOTP * 192.168.30.134 Rechner mit DHCPD3 Server und TFTP auf Port 69 * statische Adressvergabe über MAC-Adressen fest zugewiesen * 192.168.30.10 AVR-NET-IO mit MAC AC:DE:48:CE:23:C8 * 255.255.255.0 Netmask * 192.168.30.1 Gateway * 192.168.30.1 DNS-Server Die folgende Konfiguration verfügt nicht über eine dynamische IP-Range. Dies bedeutet, dass diese Konfiguration nicht mit einem bereits vorhanden DHCP Server ins Gehege kommt. Dem ethersex wird zum Starten eine feste IP zugewiesen. Der Ablauf: #DHCP Server und TFTP Server müssen gestartet sein #Dann das AVR Net-IO in die Steckdose #Ethersex fragt mit seiner Netzwerkadresse ac:de:48:ce:23:c8 per bootp nach einer IP-Adresse #Der DHCP Server schaut in seiner Liste nach ac:de:48:ce:23:c8, findet diese und die IP 192.168.30.10 zusammen mit der TFTP Server IP 192.168.30.134 und dem Dateinamen ethersex.bin zurück an Ethersex #Ethersex kann nun eine IP Verbindung zum TFTP Server 192.168.30.134 aufbauen und lädt die Datei ethersex.bin #Anschlißend startet Ethersex mit der ethersex.bin ===DHCP-Server konfigurieren === sudo apt-get install dhcp3-server Anschließend muss die Konfigurationsdatei /etc/dhcp3/dhcpd.conf, wie folgt bearbeitet werden. Die IP Adressen musst Du an Deine Gegebenheiten anpassen. <pre> default-lease-time 86400; max-lease-time 2592000; authoritative; subnet 192.168.30.0 netmask 255.255.255.0 { option subnet-mask 255.255.255.0; # subnet maske option routers 192.168.30.1; # Gateway option domain-name-servers 192.168.30.1; # DNS Server ddns-update-style none; # Neue Clients werden dem DNS Server nicht mitgeteilt next-server 192.168.30.134; # TFTP Server host netio { hardware ethernet ac:de:48:ce:23:c8; # mac adresse des pollin net io fixed-address 192.168.30.10; # Eine freie IP-Adresse im lokalen Netz filename "ethersex.bin"; # bootfile (Achtung das ethersex.bin file nehmen!) } } </pre> Anschließend kann der DHCP Server gestartet/neu gestartet werden: sudo /etc/init.d/dhcp3-server restart ===TFTP Server konfigurieren=== Die Konfiguration des TFTP Servers ist ziemlich einfach. Dieser muss nur installiert und gestartet werden: sudo apt-get install tftpd-hpa Die vom Makefile generierte ethersex.bin Datei muss dann nur noch nach /var/lib/tftpboot kopiert werden. Den TFTP Server startetn/neu starten sudo /etc/init.d/tftpd-hpa restart == Bekannte Probleme == Ist im µC bereits eine Firmware geflasht, so sollten durch den BOOTP-Mechanismus die Netzwerkparameter wie IP, Gateway, DNS und Gateway bezogen werden. Laut Logfile vom haneWin DHCP Server erfolgt dies auch. Danach sollte dann die Firmware mit genau diesen Netzwerkparametern gestartet werden. Dies geschiet aber nicht, da vermutlich die Netzwerkparameter nicht an die Firmware weitergereicht werden. Es werden die alten Netzwerkparameter geladen trotz der Einstellung in ''menuconfig'', dass BOOTP verwendet werden soll. Man erkennt mit dem Kommando ''arp -a'' in der Windows-Konsole, dass nach dem Booten die neuen Netzwerkparameter mit der IP vom BOOTP-Server vergeben wurden. Im zweiten Schritt, wenn der µC die Firmware läd, jedoch die alte letzte IP-Adresse benutzt. Daher muss man mit ''arp -d'' die ARP-Tabelle löschen und sich unter der alten IP in den µC mit telnet (siehe [[ECMD Protocols]]) einloggen und mit den Befehlen ''ip, netmask, gw, dns server'' manuell auf die neuen Werte setzen. Alternativ kann man den µC zwingen die neue Firmware zu laden, die dann aber intern die gleichen Netzwerkparameter wie der BOOTP-Server haben muss. Schade eigentlich, so hätte man sehr elegant mit dem BOOTP-Server die Netzwerkparameter zur Bootzeit vergeben können. Ich habe gerade noch einmal in den Quellen nachgesehen, dort werden die Netzwerkparameter von BOOTP nur im EEPROM des µC gespeichert, wenn ''Write BOOTP data to EEPROM'' in ''menuconfig'' ausgewählt ist. Damit lassen sich die Netzwerkparameter zwischenspeichern und stehen nach dem Start der Firmware als Default zur Verfügung. Per Default wird diese Option nicht geladen. Das Problem sollte sich damit beheben lassen. Das habe ich aber bisher noch nicht getestet. Wenn dem so ist, sollte die Default-Konfiguration des ''Ethernet Bootloader'' entsprechend angepasst werden. Ist die zu ladende Firmware größer als 56kB, so wird die Firmware nicht richtig geflasht, da ab xE000 der Ethernet-Bootloader den Bereich mit gesetzten Secure-Bits blockiert. == Nützliche Links == * [http://www.atmel.com/dyn/resources/prod_documents/doc2475.pdf ATMEL JTAG-Interface-Beschreibung] * [http://www.atmel.com/dyn/resources/prod_documents/doc2593.pdf Datenblatt zum ATMEGA644] daea909b29765d2ec924ccdbc2f37d9fb63e44e5 1534 1533 2016-01-25T06:25:20Z Djmaster 255 wikitext text/x-wiki {{i18n|BOOTP}} {{Module |NAME=BOOTP |MENUCONFIG={{Protocol}}->BOOTP |STATUS={{In_Development}} |PINNING=no |ECMD=no |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/protocols/bootp https://github.com/ethersex/ethersex/tree/master/protocols/bootp] }} * <b>Direktkopie von old.ethersex.wiki.. Überarbeite ich die Tage. 25.01.2016</b> [User:Djmaster] == Warum BOOTP? == Jeder kennt das Problem, wenn man eine Firmware erstellt hat, muss sie irgendwie in die Hardware kommen. Der gängige Weg, man flasht die Hardware mit einem Programmieradapter über SPI oder [http://de.wikipedia.org/wiki/Joint_Test_Action_Group JTAG] ([http://www.atmel.com/dyn/resources/prod_documents/doc2475.pdf ATMEL]). In der Firmware muss die [http://de.wikipedia.org/wiki/MAC-Adresse MAC]- Adresse und die [http://de.wikipedia.org/wiki/IP-Adresse IP-Adresse] für die Hardware (µC) einkompiliert sein. Sie ist damit erstmals fix und kann nur nachträglich über das ECMD-Kommandos ip geändert werden. Schön wäre es, wenn man sich um die IP-Adresse nicht kümmern müsste und sie selbständig zum Bootzeitpunkt geladen wird. Und noch schöner wäre es, wenn der µC sich auch gleich die aktuelle Firmware selbst laden und flashen würde. Genau dies macht jetzt BOOTP.<br /> === BOOTP Startsequenz === [http://de.wikipedia.org/wiki/Bootstrap_Protocol BOOTP] ist der Vorläufer von [http://de.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol DHCP] mit dem einem Netzwerkgerät wie z.B. unserem µC eine IP-Adresse zugeordnet werden kann. Falls das Netzwerkgerät nicht über einen eigenen Festspeicher verfügt, kann auch die Firmware oder das Betriebssystem auf Anfrage des Netzwerkgerätes übertragen werden. Damit BOOTP funktioniert, muss ein Minimalprogramm mit dem BOOTP-Client auf dem Netzwerkgerät als Bootloader gespeicher sein. Bei einem PC liegt dieses Programm in der Netzwerkkarte. Auf unserem µC muss der Ethernet Bootloader geflasht sein. Dieser enthält eine eindeutige MAC-Adresse für das Netzwerkgerät, damit es adressiert werden kann.<br /> Zum Bootzeitpunkt verfügt der µC nur über die MAC-Adresse. Er stellt also als erstes eine Broadcast-Anfrage an alle Netzwerkteilnehmer mit der Bitte ihm eine IP-Adresse zu geben. Gibt es im Netzwerk einen anderen Rechner, der einen BOOTP- oder DHCP-Server enthält, so antwortet dieser Server und gibt ihm, sofern erlaubt, eine IP-Adresse, die Netmask und das Gateway. Ab nun an kann der µC unter dieser Adresse erreicht werden. Als nächstes fragt der µC den BOOTP-Server nach einer aktuellen Firmware. Dieser teilt ihm den Server und den Port mit, von dem die Firmware per [http://de.wikipedia.org/wiki/Trivial_File_Transfer_Protocol TFTP] geladen werden kann. Mit dieser Art des bootens, kann sehr elegant der µC geflasht und gleichzeitig eine IP-Adresse zugeordnet werden. Das eigentliche flashen der Firmware macht der µC damit selbständig. Mit dem Ethernet Bootloader und BOOTP ist es möglich, beliebige Firmware zu laden ohne ein Programmieradapter zu benutzen. Es muss lediglich die aktuelle Firmware auf dem BOOTP-Server hinterlegt sein und einmal der µC neu gestartet werden und schon flasht er sich selbständig ohne weiteres zutun nur über das Netzwerk. Diese Art des "flashens" geht schneller als mit einem Programmieradapter. In gut 10s ist die Firmware (ca. 50kB) geladen, geflasht und gestartet.<br /> === Voraussetzungen === Damit BOOTP benutzt werden kann müssen bestimmte Voraussetzungen erfüllt sein: * Nur mit einem ATMEGA644 oder größer läßt sich der 8KB Ethernet Bootloader flashen * Der Bootloader mit BOOTP belegt die letzten 8KB ab Adresse xE000 des Programmspeichers, die nicht mehr genutzt werden können * Die Programmgröße (Firmware) ist auf 56 KB beschränkt * Die Securebits sollten gesetzt sein, damit der Bootloader sich nicht selbst überschreiben kann * Es muss ein BOOTP- und TFTP- Server wie z.B. HahneDHCP o.ä. im Netzwerk erreichbar sein * Die Firmware muss als ethersex.bin auf dem TFTP-Server hinterlegt sein * In der Firmware muss die selbe MAC-Adresse verwendet werden wie im Bootloader von BOOTP == Konfiguration in menuconfig == Als Basis kann in nenuconfig die Option "Bootloader BOOTP" gewählt werden. Es ist zu beachten, dass '''keine spezifischen Einstellungen''' außer CPU-Typ und MCU frequency für die jeweilige Hardware im Bootloader durchgeführt werden. Die hardwarespezifischen Einstellungen werden in der Firmware vorgenommen. Folgende Optionen sollten in '''menuconfig''' aktiviert sein: * '''config-File''' ** Load a Default Configuration ---> *** (x) Ethernet Bootloader ** General Setup *** ATMEGA644 *** 16000000 MCU frequency (für AVR-NET-IO) *** (x) Build a bootloader *** (x) Teensy build ** Network ---> *** Ethernet (ENC28J60) support **** Etherrape MAC address 00:11:22:33:44:55 (bitte ändern!) *** (x) UDP support *** (x) UDP broadcast support *** (x) BOOTP (DHCP like) support ** Applications -> *** (x) TFTP support '''Wichtig!''' Die MAC-Adresse muss gesetzt sein. Die selbe MAC-Adresse muss in der Firmware später auch benutzt werden. Hier ist eine [http://www.phw-magdeburg.de/ethersex/BOOTP.config Konfigurationsdatei] für das Pollin AVR-NET-IO mit Addon (MAC: AC:DE:48:CE:23:C8 ): Damit man nun nicht jedes mal die MAC-Adresse neu einkompilieren muss, kann man sie auch händisch mit einem Texteditor in [http://www.phw-magdeburg.de/ethersex/ethersex.hex ''ethersex.hex''] ändern. <source lang="perl"> :10E000003EC0000066C0000064C0000062C00000A6 :10E0100060C000005EC000005CC000005AC000008C :10E0200058C0000056C0000054C0000052C000009C :10E0300050C0000014C100004CC000004AC00000E5 :10E0400048C0000046C0000044C0000042C00000BC :10E0500040C000003EC000003CC000003AC00000CC :10E0600038C0000036C0000034C0000032C00000DC :10E07000"ACDE48CE23C8"006F63746574000014BE24 :10E0800088E10FB6F89480936000109260000FBE94 :10E0900010926E0010926F001092700011241FBE3B :10E0A000CFEFD0E1DEBFCDBF11E0A0E0B1E0E8EE00 </source> == Flashen des Bootloaders == Nach der Konfiguration mit menuconfig den Bootloader mit ''make clean'' und ''make'' compilieren und mit einem Programmieradapter die Datei ''ethersex.hex'' flashen. Wenn eine alte Vorlage benutzt wird, muss ggf. die MAC-Adresse noch einmal geändert werden. Damit der Bootloader nicht durch die Firmware überschrieben wird, müssen die Lock-Bits folgendermaßen gesetzt sein: Für ATmega644: ''avrdude -p m644 -c ponyser -P /dev/ttyS0 -U lock:w:0x0F:m'' oder in Ponyprog: *(x) BootLock02 *(x) BootLock01 *(x) Lock2 *(x) Lock1 '''Achtung!''' Sollte der Bootloader neu geflasht werden, so müssen die Lock-Bits nach dem flashen immer wieder neu gesetzt werden. Wer keine Lust hat den Ethernet-Bootloader zu kompilieren, kann hier für das AVR-NET-IO mit Addon die Datei [http://www.phw-magdeburg.de/ethersex/ethersex.hex ''ethersex.hex''] verwenden. == BOOTP-Server konfigurieren (Windows) == Als BOOTP-Server verwende ich unter Windows '''hahneWin DHCP Server'''. Als Beispielkonfiguration ist bei mir folgendes eingestellt: * Kein DHCP sondern nur BOOTP aktiviert (zur Problemvermeidung bei bestehendem DHCP-Server) * 192.168.0.0 Netzwerk für BOOTP * 192.168.0.1 Rechner mit hahneWin DHCP Server und TFTP auf Port 69 * statische Adressvergabe über MAC-Adressen fest zugewiesen * 192.168.0.88 AVR-NET-IO mit MAC AC:DE:48:CE:23:C8 * 255.255.255.0 Netmask * 192.168.0.251 Gateway * 192.168.0.251 DNS-Server [[File:Hahne_DHCP.jpg]] Abb.: hahneWin DHCP Server Alle weiteren Einstellungen zum hahneWin DHCP Server können den nachfolgenden Links entnommen werden: Grundsätzlich werden als erstes unter ''Optionen->Einstellungen'' die Grundeinstellungen vorgenommen. * [http://www.phw-magdeburg.de/ethersex/Einstellungen_Allgemein.JPG Einstellungen Allgemein] * [http://www.phw-magdeburg.de/ethersex/Einstellungen_Schnittstellen.JPG Einstellungen Schnittstellen] * [http://www.phw-magdeburg.de/ethersex/Einstellungen_DHCP.JPG Einstellungen DHCP] * [http://www.phw-magdeburg.de/ethersex/Einstellungen_TFTP.JPG Einstellungen TFTP] * [http://www.phw-magdeburg.de/ethersex/Einstellungen_TFTP_Optionen.JPG Einstellungen TFTP Optionen] Im zweiten Schritt werden unter ''Optionen->Konfigurationsprofile verwalten'' das betreffende Netzwerk ausgewählt und mit ''Bearbeiten'' angepaßt. Im meinem Beispiel wurde der Profilname durch Ethersex ersetzt. Vorher stand dort If-2_0.1. * [http://www.phw-magdeburg.de/ethersex/Konfigurationsprofile.JPG Konfigurationsprofile] * [http://www.phw-magdeburg.de/ethersex/Ethersex_Basiskonfiguration.JPG Basiskonfiguration] * [http://www.phw-magdeburg.de/ethersex/Ethersex_DNS.JPG DNS] * [http://www.phw-magdeburg.de/ethersex/Ethersex_Boot.JPG Boot] Als letztes wird dann noch ein neuer statischer Eintrag über den Schaltknopf ''Hinzufügen'' für den µC erstellt. * [http://www.phw-magdeburg.de/ethersex/Statische_Eintraege.JPG Statische Einträge] Alle nicht aufgeführten Seiten enthalten die Standardeinstellungen und müssen nicht weiter modifiziert werden. So, nun sollte der BOOTP-Server laufen. Den Server kann man unter ''Datei->Server starten/beenden'' in den jeweiligen Zustand setzen. === Hahne BOOTP-Server verwenden === Wird jetzt der µC gebootet, so bezieht er seine Netzwerkeinstellungen vom BOOTP-Server, läd danach die Firmware und startet diese. Im Logfile des BOOTP-Server können die Aktivitäten verfolgt werden. Sobald dem µC eine IP-Adresse vergeben wurde erscheint ein grünes Häkchen vor der MAC-Adresse in der Hauptansicht. Folgende Bedingungen müssen beachtet werden: * hat der µC noch keine Firmware geladen, so wird diese per TFTP im BOOTP-Prozess geladen und geflasht * ist schon eine Firmware im µC geflasht, so werden nur die Netzwerkparameter nach einem Reboot oder Power on/off geladen und die vorhandene Firmware gestartet * um die Firmware erleut zu laden, muss mit dem [[ECMD]] Kommando ''wdreset'' oder ''bootloader'' der µC "resettet" werden == BOOTP-Server konfigurieren (Linux) == Als BOOTP-Server verwende ich unter Linux '''dhcpd3'''. Als Beispielkonfiguration ist bei mir folgendes eingestellt: * Kein DHCP sondern nur BOOTP aktiviert (zur Problemvermeidung bei bestehendem DHCP-Server) * 192.168.30.0 Netzwerk für BOOTP * 192.168.30.134 Rechner mit DHCPD3 Server und TFTP auf Port 69 * statische Adressvergabe über MAC-Adressen fest zugewiesen * 192.168.30.10 AVR-NET-IO mit MAC AC:DE:48:CE:23:C8 * 255.255.255.0 Netmask * 192.168.30.1 Gateway * 192.168.30.1 DNS-Server Die folgende Konfiguration verfügt nicht über eine dynamische IP-Range. Dies bedeutet, dass diese Konfiguration nicht mit einem bereits vorhanden DHCP Server ins Gehege kommt. Dem ethersex wird zum Starten eine feste IP zugewiesen. Der Ablauf: #DHCP Server und TFTP Server müssen gestartet sein #Dann das AVR Net-IO in die Steckdose #Ethersex fragt mit seiner Netzwerkadresse ac:de:48:ce:23:c8 per bootp nach einer IP-Adresse #Der DHCP Server schaut in seiner Liste nach ac:de:48:ce:23:c8, findet diese und die IP 192.168.30.10 zusammen mit der TFTP Server IP 192.168.30.134 und dem Dateinamen ethersex.bin zurück an Ethersex #Ethersex kann nun eine IP Verbindung zum TFTP Server 192.168.30.134 aufbauen und lädt die Datei ethersex.bin #Anschlißend startet Ethersex mit der ethersex.bin ===DHCP-Server konfigurieren === sudo apt-get install dhcp3-server Anschließend muss die Konfigurationsdatei /etc/dhcp3/dhcpd.conf, wie folgt bearbeitet werden. Die IP Adressen musst Du an Deine Gegebenheiten anpassen. <pre> default-lease-time 86400; max-lease-time 2592000; authoritative; subnet 192.168.30.0 netmask 255.255.255.0 { option subnet-mask 255.255.255.0; # subnet maske option routers 192.168.30.1; # Gateway option domain-name-servers 192.168.30.1; # DNS Server ddns-update-style none; # Neue Clients werden dem DNS Server nicht mitgeteilt next-server 192.168.30.134; # TFTP Server host netio { hardware ethernet ac:de:48:ce:23:c8; # mac adresse des pollin net io fixed-address 192.168.30.10; # Eine freie IP-Adresse im lokalen Netz filename "ethersex.bin"; # bootfile (Achtung das ethersex.bin file nehmen!) } } </pre> Anschließend kann der DHCP Server gestartet/neu gestartet werden: sudo /etc/init.d/dhcp3-server restart ===TFTP Server konfigurieren=== Die Konfiguration des TFTP Servers ist ziemlich einfach. Dieser muss nur installiert und gestartet werden: sudo apt-get install tftpd-hpa Die vom Makefile generierte ethersex.bin Datei muss dann nur noch nach /var/lib/tftpboot kopiert werden. Den TFTP Server startetn/neu starten sudo /etc/init.d/tftpd-hpa restart == Bekannte Probleme == Ist im µC bereits eine Firmware geflasht, so sollten durch den BOOTP-Mechanismus die Netzwerkparameter wie IP, Gateway, DNS und Gateway bezogen werden. Laut Logfile vom haneWin DHCP Server erfolgt dies auch. Danach sollte dann die Firmware mit genau diesen Netzwerkparametern gestartet werden. Dies geschiet aber nicht, da vermutlich die Netzwerkparameter nicht an die Firmware weitergereicht werden. Es werden die alten Netzwerkparameter geladen trotz der Einstellung in ''menuconfig'', dass BOOTP verwendet werden soll. Man erkennt mit dem Kommando ''arp -a'' in der Windows-Konsole, dass nach dem Booten die neuen Netzwerkparameter mit der IP vom BOOTP-Server vergeben wurden. Im zweiten Schritt, wenn der µC die Firmware läd, jedoch die alte letzte IP-Adresse benutzt. Daher muss man mit ''arp -d'' die ARP-Tabelle löschen und sich unter der alten IP in den µC mit telnet (siehe [[ECMD Protocols]]) einloggen und mit den Befehlen ''ip, netmask, gw, dns server'' manuell auf die neuen Werte setzen. Alternativ kann man den µC zwingen die neue Firmware zu laden, die dann aber intern die gleichen Netzwerkparameter wie der BOOTP-Server haben muss. Schade eigentlich, so hätte man sehr elegant mit dem BOOTP-Server die Netzwerkparameter zur Bootzeit vergeben können. Ich habe gerade noch einmal in den Quellen nachgesehen, dort werden die Netzwerkparameter von BOOTP nur im EEPROM des µC gespeichert, wenn ''Write BOOTP data to EEPROM'' in ''menuconfig'' ausgewählt ist. Damit lassen sich die Netzwerkparameter zwischenspeichern und stehen nach dem Start der Firmware als Default zur Verfügung. Per Default wird diese Option nicht geladen. Das Problem sollte sich damit beheben lassen. Das habe ich aber bisher noch nicht getestet. Wenn dem so ist, sollte die Default-Konfiguration des ''Ethernet Bootloader'' entsprechend angepasst werden. Ist die zu ladende Firmware größer als 56kB, so wird die Firmware nicht richtig geflasht, da ab xE000 der Ethernet-Bootloader den Bereich mit gesetzten Secure-Bits blockiert. == Nützliche Links == * [http://www.atmel.com/dyn/resources/prod_documents/doc2475.pdf ATMEL JTAG-Interface-Beschreibung] * [http://www.atmel.com/dyn/resources/prod_documents/doc2593.pdf Datenblatt zum ATMEGA644] baa739c6989d3377bd88ba4c5e17fbd91857cc61 1535 1534 2016-01-25T06:26:06Z Djmaster 255 wikitext text/x-wiki {{i18n|BOOTP}} {{Module |NAME=BOOTP |MENUCONFIG={{Protocol}}->BOOTP |STATUS={{In_Development}} |PINNING=no |ECMD=no |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/protocols/bootp https://github.com/ethersex/ethersex/tree/master/protocols/bootp] }} * <b>Direktkopie von old.ethersex.wiki.. Überarbeite ich die Tage. 25.01.2016</b> [[User_talk:Djmaster]] == Warum BOOTP? == Jeder kennt das Problem, wenn man eine Firmware erstellt hat, muss sie irgendwie in die Hardware kommen. Der gängige Weg, man flasht die Hardware mit einem Programmieradapter über SPI oder [http://de.wikipedia.org/wiki/Joint_Test_Action_Group JTAG] ([http://www.atmel.com/dyn/resources/prod_documents/doc2475.pdf ATMEL]). In der Firmware muss die [http://de.wikipedia.org/wiki/MAC-Adresse MAC]- Adresse und die [http://de.wikipedia.org/wiki/IP-Adresse IP-Adresse] für die Hardware (µC) einkompiliert sein. Sie ist damit erstmals fix und kann nur nachträglich über das ECMD-Kommandos ip geändert werden. Schön wäre es, wenn man sich um die IP-Adresse nicht kümmern müsste und sie selbständig zum Bootzeitpunkt geladen wird. Und noch schöner wäre es, wenn der µC sich auch gleich die aktuelle Firmware selbst laden und flashen würde. Genau dies macht jetzt BOOTP.<br /> === BOOTP Startsequenz === [http://de.wikipedia.org/wiki/Bootstrap_Protocol BOOTP] ist der Vorläufer von [http://de.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol DHCP] mit dem einem Netzwerkgerät wie z.B. unserem µC eine IP-Adresse zugeordnet werden kann. Falls das Netzwerkgerät nicht über einen eigenen Festspeicher verfügt, kann auch die Firmware oder das Betriebssystem auf Anfrage des Netzwerkgerätes übertragen werden. Damit BOOTP funktioniert, muss ein Minimalprogramm mit dem BOOTP-Client auf dem Netzwerkgerät als Bootloader gespeicher sein. Bei einem PC liegt dieses Programm in der Netzwerkkarte. Auf unserem µC muss der Ethernet Bootloader geflasht sein. Dieser enthält eine eindeutige MAC-Adresse für das Netzwerkgerät, damit es adressiert werden kann.<br /> Zum Bootzeitpunkt verfügt der µC nur über die MAC-Adresse. Er stellt also als erstes eine Broadcast-Anfrage an alle Netzwerkteilnehmer mit der Bitte ihm eine IP-Adresse zu geben. Gibt es im Netzwerk einen anderen Rechner, der einen BOOTP- oder DHCP-Server enthält, so antwortet dieser Server und gibt ihm, sofern erlaubt, eine IP-Adresse, die Netmask und das Gateway. Ab nun an kann der µC unter dieser Adresse erreicht werden. Als nächstes fragt der µC den BOOTP-Server nach einer aktuellen Firmware. Dieser teilt ihm den Server und den Port mit, von dem die Firmware per [http://de.wikipedia.org/wiki/Trivial_File_Transfer_Protocol TFTP] geladen werden kann. Mit dieser Art des bootens, kann sehr elegant der µC geflasht und gleichzeitig eine IP-Adresse zugeordnet werden. Das eigentliche flashen der Firmware macht der µC damit selbständig. Mit dem Ethernet Bootloader und BOOTP ist es möglich, beliebige Firmware zu laden ohne ein Programmieradapter zu benutzen. Es muss lediglich die aktuelle Firmware auf dem BOOTP-Server hinterlegt sein und einmal der µC neu gestartet werden und schon flasht er sich selbständig ohne weiteres zutun nur über das Netzwerk. Diese Art des "flashens" geht schneller als mit einem Programmieradapter. In gut 10s ist die Firmware (ca. 50kB) geladen, geflasht und gestartet.<br /> === Voraussetzungen === Damit BOOTP benutzt werden kann müssen bestimmte Voraussetzungen erfüllt sein: * Nur mit einem ATMEGA644 oder größer läßt sich der 8KB Ethernet Bootloader flashen * Der Bootloader mit BOOTP belegt die letzten 8KB ab Adresse xE000 des Programmspeichers, die nicht mehr genutzt werden können * Die Programmgröße (Firmware) ist auf 56 KB beschränkt * Die Securebits sollten gesetzt sein, damit der Bootloader sich nicht selbst überschreiben kann * Es muss ein BOOTP- und TFTP- Server wie z.B. HahneDHCP o.ä. im Netzwerk erreichbar sein * Die Firmware muss als ethersex.bin auf dem TFTP-Server hinterlegt sein * In der Firmware muss die selbe MAC-Adresse verwendet werden wie im Bootloader von BOOTP == Konfiguration in menuconfig == Als Basis kann in nenuconfig die Option "Bootloader BOOTP" gewählt werden. Es ist zu beachten, dass '''keine spezifischen Einstellungen''' außer CPU-Typ und MCU frequency für die jeweilige Hardware im Bootloader durchgeführt werden. Die hardwarespezifischen Einstellungen werden in der Firmware vorgenommen. Folgende Optionen sollten in '''menuconfig''' aktiviert sein: * '''config-File''' ** Load a Default Configuration ---> *** (x) Ethernet Bootloader ** General Setup *** ATMEGA644 *** 16000000 MCU frequency (für AVR-NET-IO) *** (x) Build a bootloader *** (x) Teensy build ** Network ---> *** Ethernet (ENC28J60) support **** Etherrape MAC address 00:11:22:33:44:55 (bitte ändern!) *** (x) UDP support *** (x) UDP broadcast support *** (x) BOOTP (DHCP like) support ** Applications -> *** (x) TFTP support '''Wichtig!''' Die MAC-Adresse muss gesetzt sein. Die selbe MAC-Adresse muss in der Firmware später auch benutzt werden. Hier ist eine [http://www.phw-magdeburg.de/ethersex/BOOTP.config Konfigurationsdatei] für das Pollin AVR-NET-IO mit Addon (MAC: AC:DE:48:CE:23:C8 ): Damit man nun nicht jedes mal die MAC-Adresse neu einkompilieren muss, kann man sie auch händisch mit einem Texteditor in [http://www.phw-magdeburg.de/ethersex/ethersex.hex ''ethersex.hex''] ändern. <source lang="perl"> :10E000003EC0000066C0000064C0000062C00000A6 :10E0100060C000005EC000005CC000005AC000008C :10E0200058C0000056C0000054C0000052C000009C :10E0300050C0000014C100004CC000004AC00000E5 :10E0400048C0000046C0000044C0000042C00000BC :10E0500040C000003EC000003CC000003AC00000CC :10E0600038C0000036C0000034C0000032C00000DC :10E07000"ACDE48CE23C8"006F63746574000014BE24 :10E0800088E10FB6F89480936000109260000FBE94 :10E0900010926E0010926F001092700011241FBE3B :10E0A000CFEFD0E1DEBFCDBF11E0A0E0B1E0E8EE00 </source> == Flashen des Bootloaders == Nach der Konfiguration mit menuconfig den Bootloader mit ''make clean'' und ''make'' compilieren und mit einem Programmieradapter die Datei ''ethersex.hex'' flashen. Wenn eine alte Vorlage benutzt wird, muss ggf. die MAC-Adresse noch einmal geändert werden. Damit der Bootloader nicht durch die Firmware überschrieben wird, müssen die Lock-Bits folgendermaßen gesetzt sein: Für ATmega644: ''avrdude -p m644 -c ponyser -P /dev/ttyS0 -U lock:w:0x0F:m'' oder in Ponyprog: *(x) BootLock02 *(x) BootLock01 *(x) Lock2 *(x) Lock1 '''Achtung!''' Sollte der Bootloader neu geflasht werden, so müssen die Lock-Bits nach dem flashen immer wieder neu gesetzt werden. Wer keine Lust hat den Ethernet-Bootloader zu kompilieren, kann hier für das AVR-NET-IO mit Addon die Datei [http://www.phw-magdeburg.de/ethersex/ethersex.hex ''ethersex.hex''] verwenden. == BOOTP-Server konfigurieren (Windows) == Als BOOTP-Server verwende ich unter Windows '''hahneWin DHCP Server'''. Als Beispielkonfiguration ist bei mir folgendes eingestellt: * Kein DHCP sondern nur BOOTP aktiviert (zur Problemvermeidung bei bestehendem DHCP-Server) * 192.168.0.0 Netzwerk für BOOTP * 192.168.0.1 Rechner mit hahneWin DHCP Server und TFTP auf Port 69 * statische Adressvergabe über MAC-Adressen fest zugewiesen * 192.168.0.88 AVR-NET-IO mit MAC AC:DE:48:CE:23:C8 * 255.255.255.0 Netmask * 192.168.0.251 Gateway * 192.168.0.251 DNS-Server [[File:Hahne_DHCP.jpg]] Abb.: hahneWin DHCP Server Alle weiteren Einstellungen zum hahneWin DHCP Server können den nachfolgenden Links entnommen werden: Grundsätzlich werden als erstes unter ''Optionen->Einstellungen'' die Grundeinstellungen vorgenommen. * [http://www.phw-magdeburg.de/ethersex/Einstellungen_Allgemein.JPG Einstellungen Allgemein] * [http://www.phw-magdeburg.de/ethersex/Einstellungen_Schnittstellen.JPG Einstellungen Schnittstellen] * [http://www.phw-magdeburg.de/ethersex/Einstellungen_DHCP.JPG Einstellungen DHCP] * [http://www.phw-magdeburg.de/ethersex/Einstellungen_TFTP.JPG Einstellungen TFTP] * [http://www.phw-magdeburg.de/ethersex/Einstellungen_TFTP_Optionen.JPG Einstellungen TFTP Optionen] Im zweiten Schritt werden unter ''Optionen->Konfigurationsprofile verwalten'' das betreffende Netzwerk ausgewählt und mit ''Bearbeiten'' angepaßt. Im meinem Beispiel wurde der Profilname durch Ethersex ersetzt. Vorher stand dort If-2_0.1. * [http://www.phw-magdeburg.de/ethersex/Konfigurationsprofile.JPG Konfigurationsprofile] * [http://www.phw-magdeburg.de/ethersex/Ethersex_Basiskonfiguration.JPG Basiskonfiguration] * [http://www.phw-magdeburg.de/ethersex/Ethersex_DNS.JPG DNS] * [http://www.phw-magdeburg.de/ethersex/Ethersex_Boot.JPG Boot] Als letztes wird dann noch ein neuer statischer Eintrag über den Schaltknopf ''Hinzufügen'' für den µC erstellt. * [http://www.phw-magdeburg.de/ethersex/Statische_Eintraege.JPG Statische Einträge] Alle nicht aufgeführten Seiten enthalten die Standardeinstellungen und müssen nicht weiter modifiziert werden. So, nun sollte der BOOTP-Server laufen. Den Server kann man unter ''Datei->Server starten/beenden'' in den jeweiligen Zustand setzen. === Hahne BOOTP-Server verwenden === Wird jetzt der µC gebootet, so bezieht er seine Netzwerkeinstellungen vom BOOTP-Server, läd danach die Firmware und startet diese. Im Logfile des BOOTP-Server können die Aktivitäten verfolgt werden. Sobald dem µC eine IP-Adresse vergeben wurde erscheint ein grünes Häkchen vor der MAC-Adresse in der Hauptansicht. Folgende Bedingungen müssen beachtet werden: * hat der µC noch keine Firmware geladen, so wird diese per TFTP im BOOTP-Prozess geladen und geflasht * ist schon eine Firmware im µC geflasht, so werden nur die Netzwerkparameter nach einem Reboot oder Power on/off geladen und die vorhandene Firmware gestartet * um die Firmware erleut zu laden, muss mit dem [[ECMD]] Kommando ''wdreset'' oder ''bootloader'' der µC "resettet" werden == BOOTP-Server konfigurieren (Linux) == Als BOOTP-Server verwende ich unter Linux '''dhcpd3'''. Als Beispielkonfiguration ist bei mir folgendes eingestellt: * Kein DHCP sondern nur BOOTP aktiviert (zur Problemvermeidung bei bestehendem DHCP-Server) * 192.168.30.0 Netzwerk für BOOTP * 192.168.30.134 Rechner mit DHCPD3 Server und TFTP auf Port 69 * statische Adressvergabe über MAC-Adressen fest zugewiesen * 192.168.30.10 AVR-NET-IO mit MAC AC:DE:48:CE:23:C8 * 255.255.255.0 Netmask * 192.168.30.1 Gateway * 192.168.30.1 DNS-Server Die folgende Konfiguration verfügt nicht über eine dynamische IP-Range. Dies bedeutet, dass diese Konfiguration nicht mit einem bereits vorhanden DHCP Server ins Gehege kommt. Dem ethersex wird zum Starten eine feste IP zugewiesen. Der Ablauf: #DHCP Server und TFTP Server müssen gestartet sein #Dann das AVR Net-IO in die Steckdose #Ethersex fragt mit seiner Netzwerkadresse ac:de:48:ce:23:c8 per bootp nach einer IP-Adresse #Der DHCP Server schaut in seiner Liste nach ac:de:48:ce:23:c8, findet diese und die IP 192.168.30.10 zusammen mit der TFTP Server IP 192.168.30.134 und dem Dateinamen ethersex.bin zurück an Ethersex #Ethersex kann nun eine IP Verbindung zum TFTP Server 192.168.30.134 aufbauen und lädt die Datei ethersex.bin #Anschlißend startet Ethersex mit der ethersex.bin ===DHCP-Server konfigurieren === sudo apt-get install dhcp3-server Anschließend muss die Konfigurationsdatei /etc/dhcp3/dhcpd.conf, wie folgt bearbeitet werden. Die IP Adressen musst Du an Deine Gegebenheiten anpassen. <pre> default-lease-time 86400; max-lease-time 2592000; authoritative; subnet 192.168.30.0 netmask 255.255.255.0 { option subnet-mask 255.255.255.0; # subnet maske option routers 192.168.30.1; # Gateway option domain-name-servers 192.168.30.1; # DNS Server ddns-update-style none; # Neue Clients werden dem DNS Server nicht mitgeteilt next-server 192.168.30.134; # TFTP Server host netio { hardware ethernet ac:de:48:ce:23:c8; # mac adresse des pollin net io fixed-address 192.168.30.10; # Eine freie IP-Adresse im lokalen Netz filename "ethersex.bin"; # bootfile (Achtung das ethersex.bin file nehmen!) } } </pre> Anschließend kann der DHCP Server gestartet/neu gestartet werden: sudo /etc/init.d/dhcp3-server restart ===TFTP Server konfigurieren=== Die Konfiguration des TFTP Servers ist ziemlich einfach. Dieser muss nur installiert und gestartet werden: sudo apt-get install tftpd-hpa Die vom Makefile generierte ethersex.bin Datei muss dann nur noch nach /var/lib/tftpboot kopiert werden. Den TFTP Server startetn/neu starten sudo /etc/init.d/tftpd-hpa restart == Bekannte Probleme == Ist im µC bereits eine Firmware geflasht, so sollten durch den BOOTP-Mechanismus die Netzwerkparameter wie IP, Gateway, DNS und Gateway bezogen werden. Laut Logfile vom haneWin DHCP Server erfolgt dies auch. Danach sollte dann die Firmware mit genau diesen Netzwerkparametern gestartet werden. Dies geschiet aber nicht, da vermutlich die Netzwerkparameter nicht an die Firmware weitergereicht werden. Es werden die alten Netzwerkparameter geladen trotz der Einstellung in ''menuconfig'', dass BOOTP verwendet werden soll. Man erkennt mit dem Kommando ''arp -a'' in der Windows-Konsole, dass nach dem Booten die neuen Netzwerkparameter mit der IP vom BOOTP-Server vergeben wurden. Im zweiten Schritt, wenn der µC die Firmware läd, jedoch die alte letzte IP-Adresse benutzt. Daher muss man mit ''arp -d'' die ARP-Tabelle löschen und sich unter der alten IP in den µC mit telnet (siehe [[ECMD Protocols]]) einloggen und mit den Befehlen ''ip, netmask, gw, dns server'' manuell auf die neuen Werte setzen. Alternativ kann man den µC zwingen die neue Firmware zu laden, die dann aber intern die gleichen Netzwerkparameter wie der BOOTP-Server haben muss. Schade eigentlich, so hätte man sehr elegant mit dem BOOTP-Server die Netzwerkparameter zur Bootzeit vergeben können. Ich habe gerade noch einmal in den Quellen nachgesehen, dort werden die Netzwerkparameter von BOOTP nur im EEPROM des µC gespeichert, wenn ''Write BOOTP data to EEPROM'' in ''menuconfig'' ausgewählt ist. Damit lassen sich die Netzwerkparameter zwischenspeichern und stehen nach dem Start der Firmware als Default zur Verfügung. Per Default wird diese Option nicht geladen. Das Problem sollte sich damit beheben lassen. Das habe ich aber bisher noch nicht getestet. Wenn dem so ist, sollte die Default-Konfiguration des ''Ethernet Bootloader'' entsprechend angepasst werden. Ist die zu ladende Firmware größer als 56kB, so wird die Firmware nicht richtig geflasht, da ab xE000 der Ethernet-Bootloader den Bereich mit gesetzten Secure-Bits blockiert. == Nützliche Links == * [http://www.atmel.com/dyn/resources/prod_documents/doc2475.pdf ATMEL JTAG-Interface-Beschreibung] * [http://www.atmel.com/dyn/resources/prod_documents/doc2593.pdf Datenblatt zum ATMEGA644] d45942afb7a1f79ef3cbf216507dff2c21adc8b7 3 495 1529 2016-01-25T06:13:48Z Djmaster 255 Created page with "=Todo Liste zum übernehmen aus old wiki.= *http://www.ethersex.de/index.php/BOOTP_%28Deutsch%29 ** Links / Bilder prüfen ** Text anpassen an aktuelle rel." wikitext text/x-wiki =Todo Liste zum übernehmen aus old wiki.= *http://www.ethersex.de/index.php/BOOTP_%28Deutsch%29 ** Links / Bilder prüfen ** Text anpassen an aktuelle rel. 797ef6fc7898102aeca388223e71a3b0f81c56f9 1536 1529 2016-01-25T06:27:30Z Djmaster 255 wikitext text/x-wiki =Todo Liste zum übernehmen aus old wiki.= *[[BOOTP_%28Deutsch%29]] ** Links / Bilder prüfen ** Text anpassen an aktuelle rel. *[[I2C_%28Deutsch%29]] **Levelshifter **Aufteilung 2fe6329eb451acfb7f588f409fed1a73a85402e0 1537 1536 2016-01-25T06:28:39Z Djmaster 255 /* Todo Liste zum übernehmen aus old wiki. */ wikitext text/x-wiki =Todo Liste zum übernehmen aus old wiki.= *[[BOOTP_%28Deutsch%29]] ** Links prüfen ** <s>Bilder prüfen</s> ** Text anpassen an aktuelle rel. *[[I2C_%28Deutsch%29]] **Levelshifter **Aufteilung 8c591f357b97de1e04aca8f684704ef37c9172d5 1538 1537 2016-01-25T15:51:32Z Djmaster 255 wikitext text/x-wiki =Todo Liste zum übernehmen aus old wiki.= *[[BOOTP_%28Deutsch%29]] ** Links prüfen ** <s>Bilder prüfen</s> ** Text anpassen an aktuelle rel. *[[I2C_%28Deutsch%29]] **Levelshifter **Aufteilung -BOOTP -HOWTO -ETHERNET LOADER a3b7ab4d14d38ebdce55d6da21b03ee49448691d 0 319 1531 1200 2016-01-25T06:19:12Z Djmaster 255 /* Network Protocols */ wikitext text/x-wiki {{i18n|Features}} == Supported Network Hardware == * Ethernet [[ENC28J60 | Microchip's ENC28J60]] with IEEE 802.1q VLAN tagging * [[USB]] * [[RFM12]] * [[ZBUS]] == Network Protocols == * IPv4, IPv4 * TCP/IP, UDP/IP and ICMP * DNS * mDNS (Avahi) * [[BOOTP_(Deutsch)]] * [[DHCP]] * TFTP (can be used in combination with the [[Ethernet Loader]]) * SYSLOG * [[SNMP]] * SMTP * [[NTP]] (Client and Server) * DynDNS * MySQL (Client) * IRC (Client) * [[XMPP | XMPP / Jabber Client]] * MPD (Music Player Daemon) * [[SOAP]]/XMLRPC * [[UPnP]] * [[Artnet]] == Hardware Drivers == * [[Onewire]] * [[I2C]] Master / Slave * [[ADC input]] * [[PWM Generator]] * [[RFM12 FS20]] * [[RFM12 ASK]] * [[Generic ASK Modules]] * [[Bluetooth|Bluetooth SPP]] * [[USB]] * [[PS/2 Keyboard]] * [[Button Input]] * [[HC595]] * [[HC165]] * [[IRMP | IR Receivers]] * [[SRAM]] == Software Modules == * [[Ethersex Lighting Architecture]] ** [[Starburst]] ** [[StellaLight]] ** [[DMX Storage]] ** [[DMX FXSlot]] * [[Cron | Cron Daemon]] * [[System Clock | Clock ]] * [[VNC Server]] * [[lome6]] * [[Frequency Counter]] 05ed340695f44b957a8c60dc457e7d52703a410b 1541 1531 2016-01-25T16:36:42Z Djmaster 255 /* Network Protocols */ wikitext text/x-wiki {{i18n|Features}} == Supported Network Hardware == * Ethernet [[ENC28J60 | Microchip's ENC28J60]] with IEEE 802.1q VLAN tagging * [[USB]] * [[RFM12]] * [[ZBUS]] == Network Protocols == * IPv4, IPv4 * TCP/IP, UDP/IP and ICMP * DNS * mDNS (Avahi) * [[BOOTP]] | [[BOOTP_(Deutsch)]] * [[DHCP]] * TFTP (can be used in combination with the [[Ethernet Loader]]) * SYSLOG * [[SNMP]] * SMTP * [[NTP]] (Client and Server) * DynDNS * MySQL (Client) * IRC (Client) * [[XMPP | XMPP / Jabber Client]] * MPD (Music Player Daemon) * [[SOAP]]/XMLRPC * [[UPnP]] * [[Artnet]] == Hardware Drivers == * [[Onewire]] * [[I2C]] Master / Slave * [[ADC input]] * [[PWM Generator]] * [[RFM12 FS20]] * [[RFM12 ASK]] * [[Generic ASK Modules]] * [[Bluetooth|Bluetooth SPP]] * [[USB]] * [[PS/2 Keyboard]] * [[Button Input]] * [[HC595]] * [[HC165]] * [[IRMP | IR Receivers]] * [[SRAM]] == Software Modules == * [[Ethersex Lighting Architecture]] ** [[Starburst]] ** [[StellaLight]] ** [[DMX Storage]] ** [[DMX FXSlot]] * [[Cron | Cron Daemon]] * [[System Clock | Clock ]] * [[VNC Server]] * [[lome6]] * [[Frequency Counter]] 2e8fd61d827ebbf57db99e93aba3579db0b841eb 1543 1541 2016-01-25T16:43:03Z Djmaster 255 wikitext text/x-wiki {{i18n|Features}} == Supported Network Hardware == * Ethernet [[ENC28J60 | Microchip's ENC28J60]] with IEEE 802.1q VLAN tagging * [[USB]] * [[RFM12]] | [[RFM12_(Deutsch)]] * [[ZBUS]] == Network Protocols == * IPv4, IPv4 * TCP/IP, UDP/IP and ICMP * DNS * mDNS (Avahi) * [[BOOTP]] | [[BOOTP_(Deutsch)]] * [[DHCP]] * TFTP (can be used in combination with the [[Ethernet Loader]]) * SYSLOG * [[SNMP]] * SMTP * [[NTP]] (Client and Server) * DynDNS * MySQL (Client) * IRC (Client) * [[XMPP | XMPP / Jabber Client]] * MPD (Music Player Daemon) * [[SOAP]] | [[SOAP_(Deutsch)]] / XMLRPC * [[UPnP]] * [[Artnet]] == Hardware Drivers == * [[Onewire]] | [[Onewire_(Deutsch)]] * [[I2C]] | [[I2C_(Deutsch)]] Master / Slave * [[ADC input]] * [[PWM Generator]] * [[RFM12 FS20]] * [[RFM12 ASK]] * [[Generic ASK Modules]] * [[Bluetooth|Bluetooth SPP]] * [[USB]] * [[PS/2 Keyboard]] * [[Button Input]] * [[HC595]] * [[HC165]] * [[IRMP | IR Receivers]] * [[SRAM]] == Software Modules == * [[Ethersex Lighting Architecture]] ** [[Starburst]] ** [[StellaLight]] ** [[DMX Storage]] ** [[DMX FXSlot]] * [[Cron | Cron Daemon]] * [[System Clock | Clock ]] * [[VNC Server]] * [[lome6]] * [[Frequency Counter]] ad7cfb46b58622678005e8372472663552dc621e 1544 1543 2016-01-25T16:46:19Z Djmaster 255 /* Hardware Drivers */ wikitext text/x-wiki {{i18n|Features}} == Supported Network Hardware == * Ethernet [[ENC28J60 | Microchip's ENC28J60]] with IEEE 802.1q VLAN tagging * [[USB]] * [[RFM12]] | [[RFM12_(Deutsch)]] * [[ZBUS]] == Network Protocols == * IPv4, IPv4 * TCP/IP, UDP/IP and ICMP * DNS * mDNS (Avahi) * [[BOOTP]] | [[BOOTP_(Deutsch)]] * [[DHCP]] * TFTP (can be used in combination with the [[Ethernet Loader]]) * SYSLOG * [[SNMP]] * SMTP * [[NTP]] (Client and Server) * DynDNS * MySQL (Client) * IRC (Client) * [[XMPP | XMPP / Jabber Client]] * MPD (Music Player Daemon) * [[SOAP]] | [[SOAP_(Deutsch)]] / XMLRPC * [[UPnP]] * [[Artnet]] == Hardware Drivers == * [[Onewire]] | [[Onewire_(Deutsch)]] * [[I2C]] | [[I2C_(Deutsch)]] Master / Slave * [[ADC input]] * [[PWM Generator]] * [[RFM12_FS20]] | [[RFM12_FS20_(Deutsch)]] * [[RFM12_ASK]] | [[RFM12_ASK_(Deutsch)]] * [[Generic ASK Modules]] * [[Bluetooth|Bluetooth SPP]] * [[USB]] * [[PS/2 Keyboard]] * [[Button Input]] * [[HC595]] * [[HC165]] * [[IRMP | IR Receivers]] | [[IRMP_(Deutsch) | IR Receivers_(Deutsch)]] * [[SRAM]] == Software Modules == * [[Ethersex Lighting Architecture]] ** [[Starburst]] ** [[StellaLight]] ** [[DMX Storage]] ** [[DMX FXSlot]] * [[Cron | Cron Daemon]] * [[System Clock | Clock ]] * [[VNC Server]] * [[lome6]] * [[Frequency Counter]] eda21e300a8ec0fd46078e1b9b1363c7d79b3326 1545 1544 2016-01-25T16:48:20Z Djmaster 255 /* Software Modules */ wikitext text/x-wiki {{i18n|Features}} == Supported Network Hardware == * Ethernet [[ENC28J60 | Microchip's ENC28J60]] with IEEE 802.1q VLAN tagging * [[USB]] * [[RFM12]] | [[RFM12_(Deutsch)]] * [[ZBUS]] == Network Protocols == * IPv4, IPv4 * TCP/IP, UDP/IP and ICMP * DNS * mDNS (Avahi) * [[BOOTP]] | [[BOOTP_(Deutsch)]] * [[DHCP]] * TFTP (can be used in combination with the [[Ethernet Loader]]) * SYSLOG * [[SNMP]] * SMTP * [[NTP]] (Client and Server) * DynDNS * MySQL (Client) * IRC (Client) * [[XMPP | XMPP / Jabber Client]] * MPD (Music Player Daemon) * [[SOAP]] | [[SOAP_(Deutsch)]] / XMLRPC * [[UPnP]] * [[Artnet]] == Hardware Drivers == * [[Onewire]] | [[Onewire_(Deutsch)]] * [[I2C]] | [[I2C_(Deutsch)]] Master / Slave * [[ADC input]] * [[PWM Generator]] * [[RFM12_FS20]] | [[RFM12_FS20_(Deutsch)]] * [[RFM12_ASK]] | [[RFM12_ASK_(Deutsch)]] * [[Generic ASK Modules]] * [[Bluetooth|Bluetooth SPP]] * [[USB]] * [[PS/2 Keyboard]] * [[Button Input]] * [[HC595]] * [[HC165]] * [[IRMP | IR Receivers]] | [[IRMP_(Deutsch) | IR Receivers_(Deutsch)]] * [[SRAM]] == Software Modules == * [[Ethersex Lighting Architecture]] ** [[Starburst]] ** [[StellaLight]] ** [[DMX Storage]] ** [[DMX FXSlot]] * [[Cron | Cron Daemon]] | [[Cron_(Deutsch) | Cron Daemon_(Deutsch)]] * [[System Clock | Clock ]] * [[VNC Server]] * [[lome6]] * [[Frequency Counter]] ca322da146dc5d3f7c35c71f633709359bcf8e24 1547 1545 2016-01-26T05:12:11Z Djmaster 255 wikitext text/x-wiki {{i18n|Features}} == Supported Network Hardware == * Ethernet [[ENC28J60 | Microchip's ENC28J60]] with IEEE 802.1q VLAN tagging * [[USB]] * [[RFM12]] * [[ZBUS]] == Network Protocols == * IPv4, IPv4 * TCP/IP, UDP/IP and ICMP * DNS * mDNS (Avahi) * [[BOOTP]] * [[DHCP]] * TFTP (can be used in combination with the [[Ethernet Loader]]) * SYSLOG * [[SNMP]] * SMTP * [[NTP]] (Client and Server) * DynDNS * MySQL (Client) * IRC (Client) * [[XMPP | XMPP / Jabber Client]] * MPD (Music Player Daemon) * [[SOAP]] / XMLRPC * [[UPnP]] * [[Artnet]] == Hardware Drivers == * [[Onewire]] * [[I2C]] Master / Slave * [[ADC input]] * [[PWM Generator]] * [[RFM12_FS20]] * [[RFM12_ASK]] * [[Generic ASK Modules]] * [[Bluetooth|Bluetooth SPP]] * [[USB]] * [[PS/2 Keyboard]] * [[Button Input]] * [[HC595]] * [[HC165]] * [[IRMP | IR Receivers]] * [[SRAM]] == Software Modules == * [[Ethersex Lighting Architecture]] ** [[Starburst]] ** [[StellaLight]] ** [[DMX Storage]] ** [[DMX FXSlot]] * [[Cron | Cron Daemon]] * [[System Clock | Clock ]] * [[VNC Server]] * [[lome6]] * [[Frequency Counter]] 9a334d75e680965a55d27d3b15feedd6096aa274 1548 1547 2016-01-26T05:19:34Z Djmaster 255 /* Hardware Drivers */ wikitext text/x-wiki {{i18n|Features}} == Supported Network Hardware == * Ethernet [[ENC28J60 | Microchip's ENC28J60]] with IEEE 802.1q VLAN tagging * [[USB]] * [[RFM12]] * [[ZBUS]] == Network Protocols == * IPv4, IPv4 * TCP/IP, UDP/IP and ICMP * DNS * mDNS (Avahi) * [[BOOTP]] * [[DHCP]] * TFTP (can be used in combination with the [[Ethernet Loader]]) * SYSLOG * [[SNMP]] * SMTP * [[NTP]] (Client and Server) * DynDNS * MySQL (Client) * IRC (Client) * [[XMPP | XMPP / Jabber Client]] * MPD (Music Player Daemon) * [[SOAP]] / XMLRPC * [[UPnP]] * [[Artnet]] == Hardware Drivers == * [[Onewire]] * [[I2C | I2C Master / Slave]] * [[ADC input]] * [[PWM Generator]] * [[RFM12_FS20]] * [[RFM12_ASK]] * [[Generic ASK Modules]] * [[Bluetooth|Bluetooth SPP]] * [[USB]] * [[PS/2 Keyboard]] * [[Button Input]] * [[HC595]] * [[HC165]] * [[IRMP | IR Receivers]] * [[SRAM]] == Software Modules == * [[Ethersex Lighting Architecture]] ** [[Starburst]] ** [[StellaLight]] ** [[DMX Storage]] ** [[DMX FXSlot]] * [[Cron | Cron Daemon]] * [[System Clock | Clock ]] * [[VNC Server]] * [[lome6]] * [[Frequency Counter]] 15bf1e02f5a855e138322dcf5bb2603e5c2f88ff 6 496 1532 2016-01-25T06:21:32Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 5 1539 1133 2016-01-25T16:26:25Z GooPie4o 265 Removed protection from "[[Ethersex]]" wikitext text/x-wiki {{i18n|Ethersex}} {{NewWiki}} == Welcome to ethersex.de - the universal AVR firmware == {|style="width:100%;" |style="width:33%;"|{{Facts}} |style="width:33%;vertical-align:baseline;height:100%"|{{Getting Started}} |style="width:33%;vertical-align:baseline;height:100%"|{{Documentation}} |- |} 28facb6ff3f2d3dbc8fb3adb28a61a9cb43ade2b 0 57 1540 1136 2016-01-25T16:26:50Z GooPie4o 265 Removed protection from "[[Ethersex (Deutsch)]]" wikitext text/x-wiki {{i18n|Ethersex}} {{NewWiki (Deutsch)}} == Willkommen bei ethersex.de - der universalen AVR Firmware == {|style="width:100%;" |style="width:33%;"|{{Facts (Deutsch)}} |style="width:33%;vertical-align:baseline;height:100%"|{{Getting Started (Deutsch)}} |style="width:33%;vertical-align:baseline;height:100%"|{{Documentation (Deutsch)}} |- |} 589ab6bc70eba695550dd60534099c919c5b2059 10 56 1542 1427 2016-01-25T16:37:53Z Djmaster 255 wikitext text/x-wiki <noinclude>{{i18n|Template:Facts}}</noinclude> {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | style="background-color: #FFFFFF; text-align: center; border-bottom:1px solid #aaaaaa;" | '''Überblick''' |- |Ethersex eine Firmware mit Netzwerkunterstützung für 8-bit AVR Mikrokontroller, die durch eine Community entwickelt wird. {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- !style="width:50%" | Features !style="width:50%" | Unterstützte Boards |- | * unterstützt Atmega 8,16,32,64,128,644 und viele mehr * nutzt den Ethernet-Controller '''ENC28J60''' * leicht anzupassen und zu erweitern um deine Anforderungen zu erfüllen Protokolle: * TCP/IP IPv4/'''IPv6''' * OpenVPN * Software USB stack * RFM12 / RFM12B (433 MHz / 868 MHz) * '''i²c''' Master (Untersützung zahlreicher Chips) / Slave * onewire * http server * kann mit dem '''Ethersex Command Protocol (ECMD)''' ferngesteuert werden * [[Features|und viele mehr]] | * [[AVR-NET-IO_(Deutsch)|AVR-NET-IO]] (Pollin) * [[Etherrape_(Deutsch)|Etherrape]] (lochraster.org) * AVR Module (Ulrich Radig) * [[Jackalope_(Deutsch)|Jackalope]] (lochraster.org) * [[Conrad_Probot_(Deutsch)|Probot]] (Conrad) * [[Fimser_(Deutsch)|Fimser]] (OV Lennestadt) * [[JeeLink_(Deutsch)|JeeLink]] v2 (JeeLabs) * [[Funk-AVR-Evaluationsboard_(Deutsch)|Funk-AVR-Evaluationsboard]] (Pollin) * [[Supported Boards (Deutsch)|und viele mehr]] |} |} ab001c7123607df977d3f0cf41bbb9bf66894a27 1550 1542 2016-01-26T05:44:14Z Djmaster 255 wikitext text/x-wiki <noinclude>{{i18n|Template:Facts}}</noinclude> {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | style="background-color: #FFFFFF; text-align: center; border-bottom:1px solid #aaaaaa;" | '''Überblick''' |- |Ethersex eine Firmware mit Netzwerkunterstützung für 8-bit AVR Mikrokontroller, die durch eine Community entwickelt wird. {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- !style="width:50%" | Features !style="width:50%" | Unterstützte Boards |- | * unterstützt Atmega 8,16,32,64,128,644 und viele mehr * nutzt den Ethernet-Controller '''ENC28J60''' * leicht anzupassen und zu erweitern um deine Anforderungen zu erfüllen Protokolle: * TCP/IP IPv4/'''IPv6''' * OpenVPN * Software USB stack * RFM12 / RFM12B (433 MHz / 868 MHz) * '''i²c''' Master (Untersützung zahlreicher Chips) / Slave * onewire * http server * kann mit dem '''Ethersex Command Protocol (ECMD)''' ferngesteuert werden * [[Features_(Deutsch)|und viele mehr]] | * [[AVR-NET-IO_(Deutsch)|AVR-NET-IO]] (Pollin) * [[Etherrape_(Deutsch)|Etherrape]] (lochraster.org) * AVR Module (Ulrich Radig) * [[Jackalope_(Deutsch)|Jackalope]] (lochraster.org) * [[Conrad_Probot_(Deutsch)|Probot]] (Conrad) * [[Fimser_(Deutsch)|Fimser]] (OV Lennestadt) * [[JeeLink_(Deutsch)|JeeLink]] v2 (JeeLabs) * [[Funk-AVR-Evaluationsboard_(Deutsch)|Funk-AVR-Evaluationsboard]] (Pollin) * [[Supported Boards (Deutsch)|und viele mehr]] |} |} 8ae3f73ad220eae26e03f0800316cd2bc707586d 0 497 1546 2016-01-26T05:10:40Z Djmaster 255 Created page with "{{i18n|Features}} == Supported Network Hardware == * Ethernet [[ENC28J60 | Microchip's ENC28J60]] with IEEE 802.1q VLAN tagging * [[USB]] * [[RFM12_(Deutsch)]] * [[ZBUS]] ..." wikitext text/x-wiki {{i18n|Features}} == Supported Network Hardware == * Ethernet [[ENC28J60 | Microchip's ENC28J60]] with IEEE 802.1q VLAN tagging * [[USB]] * [[RFM12_(Deutsch)]] * [[ZBUS]] == Network Protocols == * IPv4, IPv4 * TCP/IP, UDP/IP and ICMP * DNS * mDNS (Avahi) * [[BOOTP_(Deutsch)]] * [[DHCP]] * TFTP (can be used in combination with the [[Ethernet Loader]]) * SYSLOG * [[SNMP]] * SMTP * [[NTP]] (Client and Server) * DynDNS * MySQL (Client) * IRC (Client) * [[XMPP | XMPP / Jabber Client]] * MPD (Music Player Daemon) * [[SOAP_(Deutsch)]] / XMLRPC * [[UPnP]] * [[Artnet]] == Hardware Drivers == * [[Onewire_(Deutsch)]] * [[I2C_(Deutsch)]] Master / Slave * [[ADC input]] * [[PWM Generator]] * [[RFM12_FS20_(Deutsch)]] * [[RFM12_ASK_(Deutsch)]] * [[Generic ASK Modules]] * [[Bluetooth|Bluetooth SPP]] * [[USB]] * [[PS/2 Keyboard]] * [[Button Input]] * [[HC595]] * [[HC165]] * [[IRMP_(Deutsch) | IR Receivers_(Deutsch)]] * [[SRAM]] == Software Modules == * [[Ethersex Lighting Architecture]] ** [[Starburst]] ** [[StellaLight]] ** [[DMX Storage]] ** [[DMX FXSlot]] * [[Cron_(Deutsch) | Cron Daemon_(Deutsch)]] * [[System Clock | Clock ]] * [[VNC Server]] * [[lome6]] * [[Frequency Counter]] c8366ef1f6794d713357889f8cb15df1fdee1159 1549 1546 2016-01-26T05:21:21Z Djmaster 255 /* Hardware Drivers */ wikitext text/x-wiki {{i18n|Features}} == Supported Network Hardware == * Ethernet [[ENC28J60 | Microchip's ENC28J60]] with IEEE 802.1q VLAN tagging * [[USB]] * [[RFM12_(Deutsch)]] * [[ZBUS]] == Network Protocols == * IPv4, IPv4 * TCP/IP, UDP/IP and ICMP * DNS * mDNS (Avahi) * [[BOOTP_(Deutsch)]] * [[DHCP]] * TFTP (can be used in combination with the [[Ethernet Loader]]) * SYSLOG * [[SNMP]] * SMTP * [[NTP]] (Client and Server) * DynDNS * MySQL (Client) * IRC (Client) * [[XMPP | XMPP / Jabber Client]] * MPD (Music Player Daemon) * [[SOAP_(Deutsch)]] / XMLRPC * [[UPnP]] * [[Artnet]] == Hardware Drivers == * [[Onewire_(Deutsch)]] * [[I2C_(Deutsch) | I2C_(Deutsch) Master / Slave]] * [[ADC input]] * [[PWM Generator]] * [[RFM12_FS20_(Deutsch)]] * [[RFM12_ASK_(Deutsch)]] * [[Generic ASK Modules]] * [[Bluetooth|Bluetooth SPP]] * [[USB]] * [[PS/2 Keyboard]] * [[Button Input]] * [[HC595]] * [[HC165]] * [[IRMP_(Deutsch) | IR Receivers_(Deutsch)]] * [[SRAM]] == Software Modules == * [[Ethersex Lighting Architecture]] ** [[Starburst]] ** [[StellaLight]] ** [[DMX Storage]] ** [[DMX FXSlot]] * [[Cron_(Deutsch) | Cron Daemon_(Deutsch)]] * [[System Clock | Clock ]] * [[VNC Server]] * [[lome6]] * [[Frequency Counter]] 3cd73b527985ebdac262e135861625973c35f54d 10 53 1551 426 2016-01-27T18:01:02Z Djmaster 255 wikitext text/x-wiki <noinclude>{{i18n|Template:Getting Started}}</noinclude> {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | style="background-color: #FFFFFF; text-align: center; border-bottom:1px solid #aaaaaa;" | '''Einstieg''' |- | * [[Quick Start Guide (Deutsch)|Erste Schritte]] * [[Community (Deutsch)|Community]] * [[Contributing (Deutsch)|Mitmachen]] ---- [[:Category:Tutorials|'''Für Anfänger''']] * [[Temperaturmesssystem_(Deutsch)|einfache Temperaturmessung im Netzwerk]] |} 5b12547ec50e92504a653686fba30b7d05ea3c58 0 498 1552 2016-01-27T18:03:59Z Djmaster 255 Created page with "=PROJEKT Temperaturmessung= Platzhalter [[Category:Tutorials]]" wikitext text/x-wiki =PROJEKT Temperaturmessung= Platzhalter [[Category:Tutorials]] 419f1bdde45c73cec97de7655e0901e0acaf169f 1554 1552 2016-01-27T18:36:46Z Djmaster 255 wikitext text/x-wiki =PROJEKT Temperaturmessung= ===Einleitung=== * ZIEL: Eine einfache Temperaturmessung mit dem DS1820. * ZIEL: Die Ausgabe einer Temperaturvariable via integrierten Webbrowser. * ZIEL: Die Firmware muss via Netzwerk neu flashbar sein. * Abgeändertes vereinfachtes [http://www.lochraster.org/etherrape/ etherrape] Board. * Zwei Spannungsregler, ein atmega644p, ein enc28j60, und etwas 0805 Hühnerfutter. ===Software=== Ethersex (Linux) - https://github.com/ethersex/ethersex Avrdude (Windows) - http://download.savannah.gnu.org/releases/avrdude/ (avrdude-6.1-mingw32.zip) tftpd (Windows) - http://tftpd32.jounin.net/tftpd32_download.html ===Firmware/Bootloader=== Die ethersex Firmware selbst wird für zwei Sachen verwendet. Den <b>Bootloader</b> UND die <b>Firmware</b>. Der Bootloader wird sozusagen einmal in den ersten Bereich des Mikrocontrollers geschrieben und bleibt dort auch. Er wird später die Firmware via Netzwerk entgegennehmen und in den Controller schreiben. Somit befindet sich in den ersten 10% unser Bootloader und in den restlichen 90% der Code den wir wollen. Das zu Verstehen war für mich an Anfang der schwierigste Teil, ist aber dann doch sehr einfach. Ich kann somit ohne ISP-Programmer eine Firmware in den Controller schreiben. Hier grob noch die nächsten Schritte: * Als erstes ist der Bootloader zu konfigurieren, dann via ISP zu programmieren. * Der ISP-Programmer wegräumen. ;) * Als zweites ist die Firmware zu konfigurieren, dann holt sich der Bootloader unsere Firmware via Netzerk/tftpd. =BOOTLOADER= ==Bootloader bauen== Ab nun befinde ich mich auf einem <b>virtuellen Debian Rechner</b> wo ich die Firmware herunterlade und daraus den Bootloader erstelle.<br> <b>WICHTIG:</b> Die IP und MAC-Adresse müssen natürlich verändert werden. Die selbe IP und MAC-Adresse müssen in der Firmware später auch benutzt werden. <br> * Bei einem neuen Debian System müssen mit "apt-get" ein paar Sachen nachinstalliert werden. Hier zu finden [[Preparation_(Deutsch)]] * So eine art DHCP wäre auch möglich, nennt sich [[BOOTP_(Deutsch) | BOOTP]]. Darauf gehe ich hier nicht ein. # cd /home/avr/ # mkdir ethersex_IP_60 // Mein "Arbeitsordner" # cd ethersex_IP_60/ // Ordner für das Board mit der IP 192.168.123.60 # git clone git://github.com/ethersex/ethersex.git // ethersex Firmware herunterladen Cloning into ethersex... remote: Counting objects: 37366, done. remote: Total 37366 (delta 0), reused 0 (delta 0), pack-reused 37366 Receiving objects: 100% (37366/37366), 11.27 MiB | 1.22 MiB/s, done. Resolving deltas: 100% (26538/26538), done. # cp -r ethersex bootloader // Ich kopiere den ethersex Ordner zu dem bootloader Ordner. 1:1 Kopie # cd bootloader/ // In den Bootloader Ordner wechseln # make menuconfig // Einstellungen für Bootloader im nächsten Schritt │ │ Load a Default Configuration ---> │ │ (*) Ethernet Bootloader │ │ General Setup ---> │ │ (ATmega644) Target MCU │ │ (20000000) MCU frequency │ │ [*] Build a bootloader │ │ [*] Teensy build │ │ Network ---> │ │ Hostname: "esex060" // Hostname ändern │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" // MAC ändern mit "Randomize MAC address" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" // Wenn IP nicht vorhanden BOOTP deaktivieren! │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ [ ] BOOTP (DHCP-like) support // BOOTP deaktivieren! │ │ Applications ---> │ │ [*] TFTP support ---> │ │ [*] TFTP-o-matic │ │ TFTP-server IPv4 address: "192.168.123.10" // Server wo TFTPD läuft │ │ TFTP image to load: "esex060.bin" // Diesen Dateinamen ladet später unser Board via Netzwerk/tftpd jetzt noch EXIT und SPEICHERN. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 5902/8192 bytes (72.4%) [=====================---------] Program (.text + .data) : 5902 bytes Data (.data + .bss) : 1902 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.hex</b> ==Bootloader flashen via ISP== Ich flashe hier einfacher weise mit meinem Windows 7 Notebook. Ich habe avrdude einfach unter C:\ liegen. Dort kopiere ich nun die ethersex.hex hin.<br> Somit kann man mit dem flashen den Bootloaders loslegen. avrdude -cusbasp -pm644p -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m avrdude -cusbasp -pm644p -U flash:w:ethersex.hex avrdude -cusbasp -pm644p -U lock:w:0x0F:m Der Mikrocontrollerboard ist nun vorbereitet für die eigentliche Firmware. Der ISP-Programmer kann nun bei Seite gelegt werden und wird soweit alles richtig konfiguriert ist auch nicht mehr benötigt.<br> Nun erfolgt das Erstellen der Firmware. =FIRMWARE= ==Firmware bauen== * <b>WICHTIG:</b> IP, MAC Adresse, Gateway, Netmask, Hostname <b>MUSS</b> gleich sein wie bei dem Bootloader! * Der integrierte Webserver ist in der original Firmware schon aktiviert. ( Applications --> [*] HTTP Server ) # cd /home/avr/ethersex_IP_60/ # cd ethersex/ # make menuconfig │ │ Load a Default Configuration ---> │ │ (*) Etherrape │ │ General Setup ---> │ │ (ATmega644) Target MCU // atmega644p bei mir │ │ (20000000) MCU frequency // 20MHz Quarz │ │ [ ] VFS (Virtual File System) support // Benötige ich hier nicht. │ │ [*] control6 script // Hier wird unsere DS1820 Temperatur in eine Variable geschrieben für den implementieren Webserver. │ │ Network ---> // WICHTIG: IP, MAC Adresse, Gateway, Netmask, Hostname MUSS gleich sein wie bei dem Bootloader! │ │ Hostname: "esex060" │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" │ │ Netmask: "255.255.255.0" │ │ │ │ Default gateway: "192.168.123.10" │ │ I/O ---> │ │ [*] Onewire support ---> // Die allgemeine Onewire Unterstützung. │ │ [*] Onewire device detection support // Automatische Bauteilerkennung In der etherrape.m4 Datei wird nun noch der Pin des atmega geändert wo der DS1820 angeschlossen ist. Im NANO Editor wird mit "STRG-O dann Enter" gespeichert und mit STRG-X beendet. # nano pinning/hardware/etherrape.m4 // editieren der m4 Datei ----- ONEWIRE PIN ändern bei "ONEWIRE_PORT_RANGE(PD6, PD6)" zb. auf PD0 ----- Nun schreiben wir uns ein Script welches den Temperatursensor regelmäßig abfragt und in eine Globale Variable schiebt. # rm control6/control6.src // Original Datei löschen # nano control6/control6.src // Anlegen der c6 Datei. Die Datei ist nun neu und leer. C6_HEADER(`/* This will be in control6.h */') CONTROL_START ECMD_GLOBAL(temp01, 0, uint16_t); THREAD(start) temp01 = ONEWIRE_GET(1054698802080017); WAIT(5) THREAD_END(start) ON STARTUP DO THREAD_START(start) END CONTROL_END Kompilieren der eigentlichen Firmware. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 24072/65536 bytes (36.73%) [===========-------------------] Program (.text + .data) : 24072 bytes Data (.data + .bss) : 2250 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.bin</b> Die eigentliche Firmware ist nun kompiliert und fertig um via Netzwerk/tftpd aufgespielt zu werden. Ich verwende im folgenden Schritt Windows 7. Beschreibung folgt. ==Firmware flashen via TFTPD== Platzhalter..folgt in ein paar Tagen mit Fotos. 27-01-2015 [[Category:Tutorials]] 14a7b0a36f8729a135e27bf9dea347e5b6cb5edc 14 499 1553 2016-01-27T18:04:40Z Djmaster 255 Created page with "Tutorials für Anfänger komplett erklärt und beschrieben" wikitext text/x-wiki Tutorials für Anfänger komplett erklärt und beschrieben 2d0ddcd6ae609eb21cbbf41782837a949ed49c7a 6 500 1555 2016-01-27T18:50:05Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 501 1556 2016-01-27T18:51:57Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 502 1557 2016-01-27T18:52:19Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 503 1558 2016-01-27T18:52:42Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 504 1559 2016-01-27T18:53:20Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 505 1560 2016-01-27T18:53:48Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 506 1561 2016-01-27T18:54:12Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 1588 1561 2016-01-29T17:20:07Z Djmaster 255 Djmaster uploaded a new version of &quot;[[File:Putty bootl tempmess07.png]]&quot; wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 507 1562 2016-01-27T18:54:34Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 498 1563 1554 2016-01-27T18:54:51Z Djmaster 255 /* BOOTLOADER */ wikitext text/x-wiki =PROJEKT Temperaturmessung= ===Einleitung=== * ZIEL: Eine einfache Temperaturmessung mit dem DS1820. * ZIEL: Die Ausgabe einer Temperaturvariable via integrierten Webbrowser. * ZIEL: Die Firmware muss via Netzwerk neu flashbar sein. * Abgeändertes vereinfachtes [http://www.lochraster.org/etherrape/ etherrape] Board. * Zwei Spannungsregler, ein atmega644p, ein enc28j60, und etwas 0805 Hühnerfutter. ===Software=== Ethersex (Linux) - https://github.com/ethersex/ethersex Avrdude (Windows) - http://download.savannah.gnu.org/releases/avrdude/ (avrdude-6.1-mingw32.zip) tftpd (Windows) - http://tftpd32.jounin.net/tftpd32_download.html ===Firmware/Bootloader=== Die ethersex Firmware selbst wird für zwei Sachen verwendet. Den <b>Bootloader</b> UND die <b>Firmware</b>. Der Bootloader wird sozusagen einmal in den ersten Bereich des Mikrocontrollers geschrieben und bleibt dort auch. Er wird später die Firmware via Netzwerk entgegennehmen und in den Controller schreiben. Somit befindet sich in den ersten 10% unser Bootloader und in den restlichen 90% der Code den wir wollen. Das zu Verstehen war für mich an Anfang der schwierigste Teil, ist aber dann doch sehr einfach. Ich kann somit ohne ISP-Programmer eine Firmware in den Controller schreiben. Hier grob noch die nächsten Schritte: * Als erstes ist der Bootloader zu konfigurieren, dann via ISP zu programmieren. * Der ISP-Programmer wegräumen. ;) * Als zweites ist die Firmware zu konfigurieren, dann holt sich der Bootloader unsere Firmware via Netzerk/tftpd. =BOOTLOADER= <gallery perrow=7> File:Putty_bootl_tempmess01.png File:Putty_bootl_tempmess02.png File:Putty_bootl_tempmess03.png File:Putty_bootl_tempmess04.png File:Putty_bootl_tempmess05.png File:Putty_bootl_tempmess06.png File:Putty_bootl_tempmess07.png File:Putty_bootl_tempmess08.png </gallery><br> ==Bootloader bauen== Ab nun befinde ich mich auf einem <b>virtuellen Debian Rechner</b> wo ich die Firmware herunterlade und daraus den Bootloader erstelle.<br> <b>WICHTIG:</b> Die IP und MAC-Adresse müssen natürlich verändert werden. Die selbe IP und MAC-Adresse müssen in der Firmware später auch benutzt werden. <br> * Bei einem neuen Debian System müssen mit "apt-get" ein paar Sachen nachinstalliert werden. Hier zu finden [[Preparation_(Deutsch)]] * So eine art DHCP wäre auch möglich, nennt sich [[BOOTP_(Deutsch) | BOOTP]]. Darauf gehe ich hier nicht ein. # cd /home/avr/ # mkdir ethersex_IP_60 // Mein "Arbeitsordner" # cd ethersex_IP_60/ // Ordner für das Board mit der IP 192.168.123.60 # git clone git://github.com/ethersex/ethersex.git // ethersex Firmware herunterladen Cloning into ethersex... remote: Counting objects: 37366, done. remote: Total 37366 (delta 0), reused 0 (delta 0), pack-reused 37366 Receiving objects: 100% (37366/37366), 11.27 MiB | 1.22 MiB/s, done. Resolving deltas: 100% (26538/26538), done. # cp -r ethersex bootloader // Ich kopiere den ethersex Ordner zu dem bootloader Ordner. 1:1 Kopie # cd bootloader/ // In den Bootloader Ordner wechseln # make menuconfig // Einstellungen für Bootloader im nächsten Schritt │ │ Load a Default Configuration ---> │ │ (*) Ethernet Bootloader │ │ General Setup ---> │ │ (ATmega644) Target MCU │ │ (20000000) MCU frequency │ │ [*] Build a bootloader │ │ [*] Teensy build │ │ Network ---> │ │ Hostname: "esex060" // Hostname ändern │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" // MAC ändern mit "Randomize MAC address" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" // Wenn IP nicht vorhanden BOOTP deaktivieren! │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ [ ] BOOTP (DHCP-like) support // BOOTP deaktivieren! │ │ Applications ---> │ │ [*] TFTP support ---> │ │ [*] TFTP-o-matic │ │ TFTP-server IPv4 address: "192.168.123.10" // Server wo TFTPD läuft │ │ TFTP image to load: "esex060.bin" // Diesen Dateinamen ladet später unser Board via Netzwerk/tftpd jetzt noch EXIT und SPEICHERN. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 5902/8192 bytes (72.4%) [=====================---------] Program (.text + .data) : 5902 bytes Data (.data + .bss) : 1902 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.hex</b> ==Bootloader flashen via ISP== Ich flashe hier einfacher weise mit meinem Windows 7 Notebook. Ich habe avrdude einfach unter C:\ liegen. Dort kopiere ich nun die ethersex.hex hin.<br> Somit kann man mit dem flashen den Bootloaders loslegen. avrdude -cusbasp -pm644p -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m avrdude -cusbasp -pm644p -U flash:w:ethersex.hex avrdude -cusbasp -pm644p -U lock:w:0x0F:m Der Mikrocontrollerboard ist nun vorbereitet für die eigentliche Firmware. Der ISP-Programmer kann nun bei Seite gelegt werden und wird soweit alles richtig konfiguriert ist auch nicht mehr benötigt.<br> Nun erfolgt das Erstellen der Firmware. =FIRMWARE= ==Firmware bauen== * <b>WICHTIG:</b> IP, MAC Adresse, Gateway, Netmask, Hostname <b>MUSS</b> gleich sein wie bei dem Bootloader! * Der integrierte Webserver ist in der original Firmware schon aktiviert. ( Applications --> [*] HTTP Server ) # cd /home/avr/ethersex_IP_60/ # cd ethersex/ # make menuconfig │ │ Load a Default Configuration ---> │ │ (*) Etherrape │ │ General Setup ---> │ │ (ATmega644) Target MCU // atmega644p bei mir │ │ (20000000) MCU frequency // 20MHz Quarz │ │ [ ] VFS (Virtual File System) support // Benötige ich hier nicht. │ │ [*] control6 script // Hier wird unsere DS1820 Temperatur in eine Variable geschrieben für den implementieren Webserver. │ │ Network ---> // WICHTIG: IP, MAC Adresse, Gateway, Netmask, Hostname MUSS gleich sein wie bei dem Bootloader! │ │ Hostname: "esex060" │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" │ │ Netmask: "255.255.255.0" │ │ │ │ Default gateway: "192.168.123.10" │ │ I/O ---> │ │ [*] Onewire support ---> // Die allgemeine Onewire Unterstützung. │ │ [*] Onewire device detection support // Automatische Bauteilerkennung In der etherrape.m4 Datei wird nun noch der Pin des atmega geändert wo der DS1820 angeschlossen ist. Im NANO Editor wird mit "STRG-O dann Enter" gespeichert und mit STRG-X beendet. # nano pinning/hardware/etherrape.m4 // editieren der m4 Datei ----- ONEWIRE PIN ändern bei "ONEWIRE_PORT_RANGE(PD6, PD6)" zb. auf PD0 ----- Nun schreiben wir uns ein Script welches den Temperatursensor regelmäßig abfragt und in eine Globale Variable schiebt. # rm control6/control6.src // Original Datei löschen # nano control6/control6.src // Anlegen der c6 Datei. Die Datei ist nun neu und leer. C6_HEADER(`/* This will be in control6.h */') CONTROL_START ECMD_GLOBAL(temp01, 0, uint16_t); THREAD(start) temp01 = ONEWIRE_GET(1054698802080017); WAIT(5) THREAD_END(start) ON STARTUP DO THREAD_START(start) END CONTROL_END Kompilieren der eigentlichen Firmware. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 24072/65536 bytes (36.73%) [===========-------------------] Program (.text + .data) : 24072 bytes Data (.data + .bss) : 2250 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.bin</b> Die eigentliche Firmware ist nun kompiliert und fertig um via Netzwerk/tftpd aufgespielt zu werden. Ich verwende im folgenden Schritt Windows 7. Beschreibung folgt. ==Firmware flashen via TFTPD== Platzhalter..folgt in ein paar Tagen mit Fotos. 27-01-2015 [[Category:Tutorials]] 6b4339f4791c6f222d2ace7b05c00e5b8cd3ddbb 1564 1563 2016-01-27T19:00:59Z Djmaster 255 /* BOOTLOADER */ wikitext text/x-wiki =PROJEKT Temperaturmessung= ===Einleitung=== * ZIEL: Eine einfache Temperaturmessung mit dem DS1820. * ZIEL: Die Ausgabe einer Temperaturvariable via integrierten Webbrowser. * ZIEL: Die Firmware muss via Netzwerk neu flashbar sein. * Abgeändertes vereinfachtes [http://www.lochraster.org/etherrape/ etherrape] Board. * Zwei Spannungsregler, ein atmega644p, ein enc28j60, und etwas 0805 Hühnerfutter. ===Software=== Ethersex (Linux) - https://github.com/ethersex/ethersex Avrdude (Windows) - http://download.savannah.gnu.org/releases/avrdude/ (avrdude-6.1-mingw32.zip) tftpd (Windows) - http://tftpd32.jounin.net/tftpd32_download.html ===Firmware/Bootloader=== Die ethersex Firmware selbst wird für zwei Sachen verwendet. Den <b>Bootloader</b> UND die <b>Firmware</b>. Der Bootloader wird sozusagen einmal in den ersten Bereich des Mikrocontrollers geschrieben und bleibt dort auch. Er wird später die Firmware via Netzwerk entgegennehmen und in den Controller schreiben. Somit befindet sich in den ersten 10% unser Bootloader und in den restlichen 90% der Code den wir wollen. Das zu Verstehen war für mich an Anfang der schwierigste Teil, ist aber dann doch sehr einfach. Ich kann somit ohne ISP-Programmer eine Firmware in den Controller schreiben. Hier grob noch die nächsten Schritte: * Als erstes ist der Bootloader zu konfigurieren, dann via ISP zu programmieren. * Der ISP-Programmer wegräumen. ;) * Als zweites ist die Firmware zu konfigurieren, dann holt sich der Bootloader unsere Firmware via Netzerk/tftpd. =BOOTLOADER= <gallery perrow=8> File:Putty_bootl_tempmess01.png File:Putty_bootl_tempmess02.png File:Putty_bootl_tempmess03.png File:Putty_bootl_tempmess04.png File:Putty_bootl_tempmess05.png File:Putty_bootl_tempmess06.png File:Putty_bootl_tempmess07.png File:Putty_bootl_tempmess08.png </gallery><br> ==Bootloader bauen== Ab nun befinde ich mich auf einem <b>virtuellen Debian Rechner</b> wo ich die Firmware herunterlade und daraus den Bootloader erstelle.<br> <b>WICHTIG:</b> Die IP und MAC-Adresse müssen natürlich verändert werden. Die selbe IP und MAC-Adresse müssen in der Firmware später auch benutzt werden. <br> * Bei einem neuen Debian System müssen mit "apt-get" ein paar Sachen nachinstalliert werden. Hier zu finden [[Preparation_(Deutsch)]] * So eine art DHCP wäre auch möglich, nennt sich [[BOOTP_(Deutsch) | BOOTP]]. Darauf gehe ich hier nicht ein. # cd /home/avr/ # mkdir ethersex_IP_60 // Mein "Arbeitsordner" # cd ethersex_IP_60/ // Ordner für das Board mit der IP 192.168.123.60 # git clone git://github.com/ethersex/ethersex.git // ethersex Firmware herunterladen Cloning into ethersex... remote: Counting objects: 37366, done. remote: Total 37366 (delta 0), reused 0 (delta 0), pack-reused 37366 Receiving objects: 100% (37366/37366), 11.27 MiB | 1.22 MiB/s, done. Resolving deltas: 100% (26538/26538), done. # cp -r ethersex bootloader // Ich kopiere den ethersex Ordner zu dem bootloader Ordner. 1:1 Kopie # cd bootloader/ // In den Bootloader Ordner wechseln # make menuconfig // Einstellungen für Bootloader im nächsten Schritt │ │ Load a Default Configuration ---> │ │ (*) Ethernet Bootloader │ │ General Setup ---> │ │ (ATmega644) Target MCU │ │ (20000000) MCU frequency │ │ [*] Build a bootloader │ │ [*] Teensy build │ │ Network ---> │ │ Hostname: "esex060" // Hostname ändern │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" // MAC ändern mit "Randomize MAC address" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" // Wenn IP nicht vorhanden BOOTP deaktivieren! │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ [ ] BOOTP (DHCP-like) support // BOOTP deaktivieren! │ │ Applications ---> │ │ [*] TFTP support ---> │ │ [*] TFTP-o-matic │ │ TFTP-server IPv4 address: "192.168.123.10" // Server wo TFTPD läuft │ │ TFTP image to load: "esex060.bin" // Diesen Dateinamen ladet später unser Board via Netzwerk/tftpd jetzt noch EXIT und SPEICHERN. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 5902/8192 bytes (72.4%) [=====================---------] Program (.text + .data) : 5902 bytes Data (.data + .bss) : 1902 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.hex</b> ==Bootloader flashen via ISP== Ich flashe hier einfacher weise mit meinem Windows 7 Notebook. Ich habe avrdude einfach unter C:\ liegen. Dort kopiere ich nun die ethersex.hex hin.<br> Somit kann man mit dem flashen den Bootloaders loslegen. avrdude -cusbasp -pm644p -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m avrdude -cusbasp -pm644p -U flash:w:ethersex.hex avrdude -cusbasp -pm644p -U lock:w:0x0F:m Der Mikrocontrollerboard ist nun vorbereitet für die eigentliche Firmware. Der ISP-Programmer kann nun bei Seite gelegt werden und wird soweit alles richtig konfiguriert ist auch nicht mehr benötigt.<br> Nun erfolgt das Erstellen der Firmware. =FIRMWARE= ==Firmware bauen== * <b>WICHTIG:</b> IP, MAC Adresse, Gateway, Netmask, Hostname <b>MUSS</b> gleich sein wie bei dem Bootloader! * Der integrierte Webserver ist in der original Firmware schon aktiviert. ( Applications --> [*] HTTP Server ) # cd /home/avr/ethersex_IP_60/ # cd ethersex/ # make menuconfig │ │ Load a Default Configuration ---> │ │ (*) Etherrape │ │ General Setup ---> │ │ (ATmega644) Target MCU // atmega644p bei mir │ │ (20000000) MCU frequency // 20MHz Quarz │ │ [ ] VFS (Virtual File System) support // Benötige ich hier nicht. │ │ [*] control6 script // Hier wird unsere DS1820 Temperatur in eine Variable geschrieben für den implementieren Webserver. │ │ Network ---> // WICHTIG: IP, MAC Adresse, Gateway, Netmask, Hostname MUSS gleich sein wie bei dem Bootloader! │ │ Hostname: "esex060" │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" │ │ Netmask: "255.255.255.0" │ │ │ │ Default gateway: "192.168.123.10" │ │ I/O ---> │ │ [*] Onewire support ---> // Die allgemeine Onewire Unterstützung. │ │ [*] Onewire device detection support // Automatische Bauteilerkennung In der etherrape.m4 Datei wird nun noch der Pin des atmega geändert wo der DS1820 angeschlossen ist. Im NANO Editor wird mit "STRG-O dann Enter" gespeichert und mit STRG-X beendet. # nano pinning/hardware/etherrape.m4 // editieren der m4 Datei ----- ONEWIRE PIN ändern bei "ONEWIRE_PORT_RANGE(PD6, PD6)" zb. auf PD0 ----- Nun schreiben wir uns ein Script welches den Temperatursensor regelmäßig abfragt und in eine Globale Variable schiebt. # rm control6/control6.src // Original Datei löschen # nano control6/control6.src // Anlegen der c6 Datei. Die Datei ist nun neu und leer. C6_HEADER(`/* This will be in control6.h */') CONTROL_START ECMD_GLOBAL(temp01, 0, uint16_t); THREAD(start) temp01 = ONEWIRE_GET(1054698802080017); WAIT(5) THREAD_END(start) ON STARTUP DO THREAD_START(start) END CONTROL_END Kompilieren der eigentlichen Firmware. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 24072/65536 bytes (36.73%) [===========-------------------] Program (.text + .data) : 24072 bytes Data (.data + .bss) : 2250 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.bin</b> Die eigentliche Firmware ist nun kompiliert und fertig um via Netzwerk/tftpd aufgespielt zu werden. Ich verwende im folgenden Schritt Windows 7. Beschreibung folgt. ==Firmware flashen via TFTPD== Platzhalter..folgt in ein paar Tagen mit Fotos. 27-01-2015 [[Category:Tutorials]] 6abe94b76b9683f6ff2fea7a73ee97b92f64f965 1568 1564 2016-01-27T19:02:35Z Djmaster 255 /* FIRMWARE */ wikitext text/x-wiki =PROJEKT Temperaturmessung= ===Einleitung=== * ZIEL: Eine einfache Temperaturmessung mit dem DS1820. * ZIEL: Die Ausgabe einer Temperaturvariable via integrierten Webbrowser. * ZIEL: Die Firmware muss via Netzwerk neu flashbar sein. * Abgeändertes vereinfachtes [http://www.lochraster.org/etherrape/ etherrape] Board. * Zwei Spannungsregler, ein atmega644p, ein enc28j60, und etwas 0805 Hühnerfutter. ===Software=== Ethersex (Linux) - https://github.com/ethersex/ethersex Avrdude (Windows) - http://download.savannah.gnu.org/releases/avrdude/ (avrdude-6.1-mingw32.zip) tftpd (Windows) - http://tftpd32.jounin.net/tftpd32_download.html ===Firmware/Bootloader=== Die ethersex Firmware selbst wird für zwei Sachen verwendet. Den <b>Bootloader</b> UND die <b>Firmware</b>. Der Bootloader wird sozusagen einmal in den ersten Bereich des Mikrocontrollers geschrieben und bleibt dort auch. Er wird später die Firmware via Netzwerk entgegennehmen und in den Controller schreiben. Somit befindet sich in den ersten 10% unser Bootloader und in den restlichen 90% der Code den wir wollen. Das zu Verstehen war für mich an Anfang der schwierigste Teil, ist aber dann doch sehr einfach. Ich kann somit ohne ISP-Programmer eine Firmware in den Controller schreiben. Hier grob noch die nächsten Schritte: * Als erstes ist der Bootloader zu konfigurieren, dann via ISP zu programmieren. * Der ISP-Programmer wegräumen. ;) * Als zweites ist die Firmware zu konfigurieren, dann holt sich der Bootloader unsere Firmware via Netzerk/tftpd. =BOOTLOADER= <gallery perrow=8> File:Putty_bootl_tempmess01.png File:Putty_bootl_tempmess02.png File:Putty_bootl_tempmess03.png File:Putty_bootl_tempmess04.png File:Putty_bootl_tempmess05.png File:Putty_bootl_tempmess06.png File:Putty_bootl_tempmess07.png File:Putty_bootl_tempmess08.png </gallery><br> ==Bootloader bauen== Ab nun befinde ich mich auf einem <b>virtuellen Debian Rechner</b> wo ich die Firmware herunterlade und daraus den Bootloader erstelle.<br> <b>WICHTIG:</b> Die IP und MAC-Adresse müssen natürlich verändert werden. Die selbe IP und MAC-Adresse müssen in der Firmware später auch benutzt werden. <br> * Bei einem neuen Debian System müssen mit "apt-get" ein paar Sachen nachinstalliert werden. Hier zu finden [[Preparation_(Deutsch)]] * So eine art DHCP wäre auch möglich, nennt sich [[BOOTP_(Deutsch) | BOOTP]]. Darauf gehe ich hier nicht ein. # cd /home/avr/ # mkdir ethersex_IP_60 // Mein "Arbeitsordner" # cd ethersex_IP_60/ // Ordner für das Board mit der IP 192.168.123.60 # git clone git://github.com/ethersex/ethersex.git // ethersex Firmware herunterladen Cloning into ethersex... remote: Counting objects: 37366, done. remote: Total 37366 (delta 0), reused 0 (delta 0), pack-reused 37366 Receiving objects: 100% (37366/37366), 11.27 MiB | 1.22 MiB/s, done. Resolving deltas: 100% (26538/26538), done. # cp -r ethersex bootloader // Ich kopiere den ethersex Ordner zu dem bootloader Ordner. 1:1 Kopie # cd bootloader/ // In den Bootloader Ordner wechseln # make menuconfig // Einstellungen für Bootloader im nächsten Schritt │ │ Load a Default Configuration ---> │ │ (*) Ethernet Bootloader │ │ General Setup ---> │ │ (ATmega644) Target MCU │ │ (20000000) MCU frequency │ │ [*] Build a bootloader │ │ [*] Teensy build │ │ Network ---> │ │ Hostname: "esex060" // Hostname ändern │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" // MAC ändern mit "Randomize MAC address" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" // Wenn IP nicht vorhanden BOOTP deaktivieren! │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ [ ] BOOTP (DHCP-like) support // BOOTP deaktivieren! │ │ Applications ---> │ │ [*] TFTP support ---> │ │ [*] TFTP-o-matic │ │ TFTP-server IPv4 address: "192.168.123.10" // Server wo TFTPD läuft │ │ TFTP image to load: "esex060.bin" // Diesen Dateinamen ladet später unser Board via Netzwerk/tftpd jetzt noch EXIT und SPEICHERN. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 5902/8192 bytes (72.4%) [=====================---------] Program (.text + .data) : 5902 bytes Data (.data + .bss) : 1902 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.hex</b> ==Bootloader flashen via ISP== Ich flashe hier einfacher weise mit meinem Windows 7 Notebook. Ich habe avrdude einfach unter C:\ liegen. Dort kopiere ich nun die ethersex.hex hin.<br> Somit kann man mit dem flashen den Bootloaders loslegen. avrdude -cusbasp -pm644p -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m avrdude -cusbasp -pm644p -U flash:w:ethersex.hex avrdude -cusbasp -pm644p -U lock:w:0x0F:m Der Mikrocontrollerboard ist nun vorbereitet für die eigentliche Firmware. Der ISP-Programmer kann nun bei Seite gelegt werden und wird soweit alles richtig konfiguriert ist auch nicht mehr benötigt.<br> Nun erfolgt das Erstellen der Firmware. =FIRMWARE= <gallery perrow=3> File:Putty_c6_m4_tempmess01.png File:Putty_c6_m4_tempmess02.png File:Putty_c6_m4_tempmess03.png </gallery><br> ==Firmware bauen== * <b>WICHTIG:</b> IP, MAC Adresse, Gateway, Netmask, Hostname <b>MUSS</b> gleich sein wie bei dem Bootloader! * Der integrierte Webserver ist in der original Firmware schon aktiviert. ( Applications --> [*] HTTP Server ) # cd /home/avr/ethersex_IP_60/ # cd ethersex/ # make menuconfig │ │ Load a Default Configuration ---> │ │ (*) Etherrape │ │ General Setup ---> │ │ (ATmega644) Target MCU // atmega644p bei mir │ │ (20000000) MCU frequency // 20MHz Quarz │ │ [ ] VFS (Virtual File System) support // Benötige ich hier nicht. │ │ [*] control6 script // Hier wird unsere DS1820 Temperatur in eine Variable geschrieben für den implementieren Webserver. │ │ Network ---> // WICHTIG: IP, MAC Adresse, Gateway, Netmask, Hostname MUSS gleich sein wie bei dem Bootloader! │ │ Hostname: "esex060" │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" │ │ Netmask: "255.255.255.0" │ │ │ │ Default gateway: "192.168.123.10" │ │ I/O ---> │ │ [*] Onewire support ---> // Die allgemeine Onewire Unterstützung. │ │ [*] Onewire device detection support // Automatische Bauteilerkennung In der etherrape.m4 Datei wird nun noch der Pin des atmega geändert wo der DS1820 angeschlossen ist. Im NANO Editor wird mit "STRG-O dann Enter" gespeichert und mit STRG-X beendet. # nano pinning/hardware/etherrape.m4 // editieren der m4 Datei ----- ONEWIRE PIN ändern bei "ONEWIRE_PORT_RANGE(PD6, PD6)" zb. auf PD0 ----- Nun schreiben wir uns ein Script welches den Temperatursensor regelmäßig abfragt und in eine Globale Variable schiebt. # rm control6/control6.src // Original Datei löschen # nano control6/control6.src // Anlegen der c6 Datei. Die Datei ist nun neu und leer. C6_HEADER(`/* This will be in control6.h */') CONTROL_START ECMD_GLOBAL(temp01, 0, uint16_t); THREAD(start) temp01 = ONEWIRE_GET(1054698802080017); WAIT(5) THREAD_END(start) ON STARTUP DO THREAD_START(start) END CONTROL_END Kompilieren der eigentlichen Firmware. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 24072/65536 bytes (36.73%) [===========-------------------] Program (.text + .data) : 24072 bytes Data (.data + .bss) : 2250 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.bin</b> Die eigentliche Firmware ist nun kompiliert und fertig um via Netzwerk/tftpd aufgespielt zu werden. Ich verwende im folgenden Schritt Windows 7. Beschreibung folgt. ==Firmware flashen via TFTPD== Platzhalter..folgt in ein paar Tagen mit Fotos. 27-01-2015 [[Category:Tutorials]] 54f8a89a3a706a276aba01b85707df4ced81a8f4 1569 1568 2016-01-27T19:06:17Z Djmaster 255 /* BOOTLOADER */ wikitext text/x-wiki =PROJEKT Temperaturmessung= ===Einleitung=== * ZIEL: Eine einfache Temperaturmessung mit dem DS1820. * ZIEL: Die Ausgabe einer Temperaturvariable via integrierten Webbrowser. * ZIEL: Die Firmware muss via Netzwerk neu flashbar sein. * Abgeändertes vereinfachtes [http://www.lochraster.org/etherrape/ etherrape] Board. * Zwei Spannungsregler, ein atmega644p, ein enc28j60, und etwas 0805 Hühnerfutter. ===Software=== Ethersex (Linux) - https://github.com/ethersex/ethersex Avrdude (Windows) - http://download.savannah.gnu.org/releases/avrdude/ (avrdude-6.1-mingw32.zip) tftpd (Windows) - http://tftpd32.jounin.net/tftpd32_download.html ===Firmware/Bootloader=== Die ethersex Firmware selbst wird für zwei Sachen verwendet. Den <b>Bootloader</b> UND die <b>Firmware</b>. Der Bootloader wird sozusagen einmal in den ersten Bereich des Mikrocontrollers geschrieben und bleibt dort auch. Er wird später die Firmware via Netzwerk entgegennehmen und in den Controller schreiben. Somit befindet sich in den ersten 10% unser Bootloader und in den restlichen 90% der Code den wir wollen. Das zu Verstehen war für mich an Anfang der schwierigste Teil, ist aber dann doch sehr einfach. Ich kann somit ohne ISP-Programmer eine Firmware in den Controller schreiben. Hier grob noch die nächsten Schritte: * Als erstes ist der Bootloader zu konfigurieren, dann via ISP zu programmieren. * Der ISP-Programmer wegräumen. ;) * Als zweites ist die Firmware zu konfigurieren, dann holt sich der Bootloader unsere Firmware via Netzerk/tftpd. =BOOTLOADER= <gallery> File:Putty_bootl_tempmess01.png File:Putty_bootl_tempmess02.png File:Putty_bootl_tempmess03.png File:Putty_bootl_tempmess04.png File:Putty_bootl_tempmess05.png File:Putty_bootl_tempmess06.png File:Putty_bootl_tempmess07.png File:Putty_bootl_tempmess08.png </gallery> ==Bootloader bauen== Ab nun befinde ich mich auf einem <b>virtuellen Debian Rechner</b> wo ich die Firmware herunterlade und daraus den Bootloader erstelle.<br> <b>WICHTIG:</b> Die IP und MAC-Adresse müssen natürlich verändert werden. Die selbe IP und MAC-Adresse müssen in der Firmware später auch benutzt werden. <br> * Bei einem neuen Debian System müssen mit "apt-get" ein paar Sachen nachinstalliert werden. Hier zu finden [[Preparation_(Deutsch)]] * So eine art DHCP wäre auch möglich, nennt sich [[BOOTP_(Deutsch) | BOOTP]]. Darauf gehe ich hier nicht ein. # cd /home/avr/ # mkdir ethersex_IP_60 // Mein "Arbeitsordner" # cd ethersex_IP_60/ // Ordner für das Board mit der IP 192.168.123.60 # git clone git://github.com/ethersex/ethersex.git // ethersex Firmware herunterladen Cloning into ethersex... remote: Counting objects: 37366, done. remote: Total 37366 (delta 0), reused 0 (delta 0), pack-reused 37366 Receiving objects: 100% (37366/37366), 11.27 MiB | 1.22 MiB/s, done. Resolving deltas: 100% (26538/26538), done. # cp -r ethersex bootloader // Ich kopiere den ethersex Ordner zu dem bootloader Ordner. 1:1 Kopie # cd bootloader/ // In den Bootloader Ordner wechseln # make menuconfig // Einstellungen für Bootloader im nächsten Schritt │ │ Load a Default Configuration ---> │ │ (*) Ethernet Bootloader │ │ General Setup ---> │ │ (ATmega644) Target MCU │ │ (20000000) MCU frequency │ │ [*] Build a bootloader │ │ [*] Teensy build │ │ Network ---> │ │ Hostname: "esex060" // Hostname ändern │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" // MAC ändern mit "Randomize MAC address" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" // Wenn IP nicht vorhanden BOOTP deaktivieren! │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ [ ] BOOTP (DHCP-like) support // BOOTP deaktivieren! │ │ Applications ---> │ │ [*] TFTP support ---> │ │ [*] TFTP-o-matic │ │ TFTP-server IPv4 address: "192.168.123.10" // Server wo TFTPD läuft │ │ TFTP image to load: "esex060.bin" // Diesen Dateinamen ladet später unser Board via Netzwerk/tftpd jetzt noch EXIT und SPEICHERN. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 5902/8192 bytes (72.4%) [=====================---------] Program (.text + .data) : 5902 bytes Data (.data + .bss) : 1902 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.hex</b> ==Bootloader flashen via ISP== Ich flashe hier einfacher weise mit meinem Windows 7 Notebook. Ich habe avrdude einfach unter C:\ liegen. Dort kopiere ich nun die ethersex.hex hin.<br> Somit kann man mit dem flashen den Bootloaders loslegen. avrdude -cusbasp -pm644p -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m avrdude -cusbasp -pm644p -U flash:w:ethersex.hex avrdude -cusbasp -pm644p -U lock:w:0x0F:m Der Mikrocontrollerboard ist nun vorbereitet für die eigentliche Firmware. Der ISP-Programmer kann nun bei Seite gelegt werden und wird soweit alles richtig konfiguriert ist auch nicht mehr benötigt.<br> Nun erfolgt das Erstellen der Firmware. =FIRMWARE= <gallery perrow=3> File:Putty_c6_m4_tempmess01.png File:Putty_c6_m4_tempmess02.png File:Putty_c6_m4_tempmess03.png </gallery><br> ==Firmware bauen== * <b>WICHTIG:</b> IP, MAC Adresse, Gateway, Netmask, Hostname <b>MUSS</b> gleich sein wie bei dem Bootloader! * Der integrierte Webserver ist in der original Firmware schon aktiviert. ( Applications --> [*] HTTP Server ) # cd /home/avr/ethersex_IP_60/ # cd ethersex/ # make menuconfig │ │ Load a Default Configuration ---> │ │ (*) Etherrape │ │ General Setup ---> │ │ (ATmega644) Target MCU // atmega644p bei mir │ │ (20000000) MCU frequency // 20MHz Quarz │ │ [ ] VFS (Virtual File System) support // Benötige ich hier nicht. │ │ [*] control6 script // Hier wird unsere DS1820 Temperatur in eine Variable geschrieben für den implementieren Webserver. │ │ Network ---> // WICHTIG: IP, MAC Adresse, Gateway, Netmask, Hostname MUSS gleich sein wie bei dem Bootloader! │ │ Hostname: "esex060" │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" │ │ Netmask: "255.255.255.0" │ │ │ │ Default gateway: "192.168.123.10" │ │ I/O ---> │ │ [*] Onewire support ---> // Die allgemeine Onewire Unterstützung. │ │ [*] Onewire device detection support // Automatische Bauteilerkennung In der etherrape.m4 Datei wird nun noch der Pin des atmega geändert wo der DS1820 angeschlossen ist. Im NANO Editor wird mit "STRG-O dann Enter" gespeichert und mit STRG-X beendet. # nano pinning/hardware/etherrape.m4 // editieren der m4 Datei ----- ONEWIRE PIN ändern bei "ONEWIRE_PORT_RANGE(PD6, PD6)" zb. auf PD0 ----- Nun schreiben wir uns ein Script welches den Temperatursensor regelmäßig abfragt und in eine Globale Variable schiebt. # rm control6/control6.src // Original Datei löschen # nano control6/control6.src // Anlegen der c6 Datei. Die Datei ist nun neu und leer. C6_HEADER(`/* This will be in control6.h */') CONTROL_START ECMD_GLOBAL(temp01, 0, uint16_t); THREAD(start) temp01 = ONEWIRE_GET(1054698802080017); WAIT(5) THREAD_END(start) ON STARTUP DO THREAD_START(start) END CONTROL_END Kompilieren der eigentlichen Firmware. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 24072/65536 bytes (36.73%) [===========-------------------] Program (.text + .data) : 24072 bytes Data (.data + .bss) : 2250 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.bin</b> Die eigentliche Firmware ist nun kompiliert und fertig um via Netzwerk/tftpd aufgespielt zu werden. Ich verwende im folgenden Schritt Windows 7. Beschreibung folgt. ==Firmware flashen via TFTPD== Platzhalter..folgt in ein paar Tagen mit Fotos. 27-01-2015 [[Category:Tutorials]] 745f47fb46cfe1149c997b7d73c55afd71e57efe 1570 1569 2016-01-27T19:06:32Z Djmaster 255 /* FIRMWARE */ wikitext text/x-wiki =PROJEKT Temperaturmessung= ===Einleitung=== * ZIEL: Eine einfache Temperaturmessung mit dem DS1820. * ZIEL: Die Ausgabe einer Temperaturvariable via integrierten Webbrowser. * ZIEL: Die Firmware muss via Netzwerk neu flashbar sein. * Abgeändertes vereinfachtes [http://www.lochraster.org/etherrape/ etherrape] Board. * Zwei Spannungsregler, ein atmega644p, ein enc28j60, und etwas 0805 Hühnerfutter. ===Software=== Ethersex (Linux) - https://github.com/ethersex/ethersex Avrdude (Windows) - http://download.savannah.gnu.org/releases/avrdude/ (avrdude-6.1-mingw32.zip) tftpd (Windows) - http://tftpd32.jounin.net/tftpd32_download.html ===Firmware/Bootloader=== Die ethersex Firmware selbst wird für zwei Sachen verwendet. Den <b>Bootloader</b> UND die <b>Firmware</b>. Der Bootloader wird sozusagen einmal in den ersten Bereich des Mikrocontrollers geschrieben und bleibt dort auch. Er wird später die Firmware via Netzwerk entgegennehmen und in den Controller schreiben. Somit befindet sich in den ersten 10% unser Bootloader und in den restlichen 90% der Code den wir wollen. Das zu Verstehen war für mich an Anfang der schwierigste Teil, ist aber dann doch sehr einfach. Ich kann somit ohne ISP-Programmer eine Firmware in den Controller schreiben. Hier grob noch die nächsten Schritte: * Als erstes ist der Bootloader zu konfigurieren, dann via ISP zu programmieren. * Der ISP-Programmer wegräumen. ;) * Als zweites ist die Firmware zu konfigurieren, dann holt sich der Bootloader unsere Firmware via Netzerk/tftpd. =BOOTLOADER= <gallery> File:Putty_bootl_tempmess01.png File:Putty_bootl_tempmess02.png File:Putty_bootl_tempmess03.png File:Putty_bootl_tempmess04.png File:Putty_bootl_tempmess05.png File:Putty_bootl_tempmess06.png File:Putty_bootl_tempmess07.png File:Putty_bootl_tempmess08.png </gallery> ==Bootloader bauen== Ab nun befinde ich mich auf einem <b>virtuellen Debian Rechner</b> wo ich die Firmware herunterlade und daraus den Bootloader erstelle.<br> <b>WICHTIG:</b> Die IP und MAC-Adresse müssen natürlich verändert werden. Die selbe IP und MAC-Adresse müssen in der Firmware später auch benutzt werden. <br> * Bei einem neuen Debian System müssen mit "apt-get" ein paar Sachen nachinstalliert werden. Hier zu finden [[Preparation_(Deutsch)]] * So eine art DHCP wäre auch möglich, nennt sich [[BOOTP_(Deutsch) | BOOTP]]. Darauf gehe ich hier nicht ein. # cd /home/avr/ # mkdir ethersex_IP_60 // Mein "Arbeitsordner" # cd ethersex_IP_60/ // Ordner für das Board mit der IP 192.168.123.60 # git clone git://github.com/ethersex/ethersex.git // ethersex Firmware herunterladen Cloning into ethersex... remote: Counting objects: 37366, done. remote: Total 37366 (delta 0), reused 0 (delta 0), pack-reused 37366 Receiving objects: 100% (37366/37366), 11.27 MiB | 1.22 MiB/s, done. Resolving deltas: 100% (26538/26538), done. # cp -r ethersex bootloader // Ich kopiere den ethersex Ordner zu dem bootloader Ordner. 1:1 Kopie # cd bootloader/ // In den Bootloader Ordner wechseln # make menuconfig // Einstellungen für Bootloader im nächsten Schritt │ │ Load a Default Configuration ---> │ │ (*) Ethernet Bootloader │ │ General Setup ---> │ │ (ATmega644) Target MCU │ │ (20000000) MCU frequency │ │ [*] Build a bootloader │ │ [*] Teensy build │ │ Network ---> │ │ Hostname: "esex060" // Hostname ändern │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" // MAC ändern mit "Randomize MAC address" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" // Wenn IP nicht vorhanden BOOTP deaktivieren! │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ [ ] BOOTP (DHCP-like) support // BOOTP deaktivieren! │ │ Applications ---> │ │ [*] TFTP support ---> │ │ [*] TFTP-o-matic │ │ TFTP-server IPv4 address: "192.168.123.10" // Server wo TFTPD läuft │ │ TFTP image to load: "esex060.bin" // Diesen Dateinamen ladet später unser Board via Netzwerk/tftpd jetzt noch EXIT und SPEICHERN. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 5902/8192 bytes (72.4%) [=====================---------] Program (.text + .data) : 5902 bytes Data (.data + .bss) : 1902 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.hex</b> ==Bootloader flashen via ISP== Ich flashe hier einfacher weise mit meinem Windows 7 Notebook. Ich habe avrdude einfach unter C:\ liegen. Dort kopiere ich nun die ethersex.hex hin.<br> Somit kann man mit dem flashen den Bootloaders loslegen. avrdude -cusbasp -pm644p -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m avrdude -cusbasp -pm644p -U flash:w:ethersex.hex avrdude -cusbasp -pm644p -U lock:w:0x0F:m Der Mikrocontrollerboard ist nun vorbereitet für die eigentliche Firmware. Der ISP-Programmer kann nun bei Seite gelegt werden und wird soweit alles richtig konfiguriert ist auch nicht mehr benötigt.<br> Nun erfolgt das Erstellen der Firmware. =FIRMWARE= <gallery> File:Putty_c6_m4_tempmess01.png File:Putty_c6_m4_tempmess02.png File:Putty_c6_m4_tempmess03.png </gallery> ==Firmware bauen== * <b>WICHTIG:</b> IP, MAC Adresse, Gateway, Netmask, Hostname <b>MUSS</b> gleich sein wie bei dem Bootloader! * Der integrierte Webserver ist in der original Firmware schon aktiviert. ( Applications --> [*] HTTP Server ) # cd /home/avr/ethersex_IP_60/ # cd ethersex/ # make menuconfig │ │ Load a Default Configuration ---> │ │ (*) Etherrape │ │ General Setup ---> │ │ (ATmega644) Target MCU // atmega644p bei mir │ │ (20000000) MCU frequency // 20MHz Quarz │ │ [ ] VFS (Virtual File System) support // Benötige ich hier nicht. │ │ [*] control6 script // Hier wird unsere DS1820 Temperatur in eine Variable geschrieben für den implementieren Webserver. │ │ Network ---> // WICHTIG: IP, MAC Adresse, Gateway, Netmask, Hostname MUSS gleich sein wie bei dem Bootloader! │ │ Hostname: "esex060" │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" │ │ Netmask: "255.255.255.0" │ │ │ │ Default gateway: "192.168.123.10" │ │ I/O ---> │ │ [*] Onewire support ---> // Die allgemeine Onewire Unterstützung. │ │ [*] Onewire device detection support // Automatische Bauteilerkennung In der etherrape.m4 Datei wird nun noch der Pin des atmega geändert wo der DS1820 angeschlossen ist. Im NANO Editor wird mit "STRG-O dann Enter" gespeichert und mit STRG-X beendet. # nano pinning/hardware/etherrape.m4 // editieren der m4 Datei ----- ONEWIRE PIN ändern bei "ONEWIRE_PORT_RANGE(PD6, PD6)" zb. auf PD0 ----- Nun schreiben wir uns ein Script welches den Temperatursensor regelmäßig abfragt und in eine Globale Variable schiebt. # rm control6/control6.src // Original Datei löschen # nano control6/control6.src // Anlegen der c6 Datei. Die Datei ist nun neu und leer. C6_HEADER(`/* This will be in control6.h */') CONTROL_START ECMD_GLOBAL(temp01, 0, uint16_t); THREAD(start) temp01 = ONEWIRE_GET(1054698802080017); WAIT(5) THREAD_END(start) ON STARTUP DO THREAD_START(start) END CONTROL_END Kompilieren der eigentlichen Firmware. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 24072/65536 bytes (36.73%) [===========-------------------] Program (.text + .data) : 24072 bytes Data (.data + .bss) : 2250 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.bin</b> Die eigentliche Firmware ist nun kompiliert und fertig um via Netzwerk/tftpd aufgespielt zu werden. Ich verwende im folgenden Schritt Windows 7. Beschreibung folgt. ==Firmware flashen via TFTPD== Platzhalter..folgt in ein paar Tagen mit Fotos. 27-01-2015 [[Category:Tutorials]] eccc51d3a2966b2eef571b02434a918f5ae792a9 1571 1570 2016-01-27T19:17:24Z Djmaster 255 /* Bootloader flashen via ISP */ wikitext text/x-wiki =PROJEKT Temperaturmessung= ===Einleitung=== * ZIEL: Eine einfache Temperaturmessung mit dem DS1820. * ZIEL: Die Ausgabe einer Temperaturvariable via integrierten Webbrowser. * ZIEL: Die Firmware muss via Netzwerk neu flashbar sein. * Abgeändertes vereinfachtes [http://www.lochraster.org/etherrape/ etherrape] Board. * Zwei Spannungsregler, ein atmega644p, ein enc28j60, und etwas 0805 Hühnerfutter. ===Software=== Ethersex (Linux) - https://github.com/ethersex/ethersex Avrdude (Windows) - http://download.savannah.gnu.org/releases/avrdude/ (avrdude-6.1-mingw32.zip) tftpd (Windows) - http://tftpd32.jounin.net/tftpd32_download.html ===Firmware/Bootloader=== Die ethersex Firmware selbst wird für zwei Sachen verwendet. Den <b>Bootloader</b> UND die <b>Firmware</b>. Der Bootloader wird sozusagen einmal in den ersten Bereich des Mikrocontrollers geschrieben und bleibt dort auch. Er wird später die Firmware via Netzwerk entgegennehmen und in den Controller schreiben. Somit befindet sich in den ersten 10% unser Bootloader und in den restlichen 90% der Code den wir wollen. Das zu Verstehen war für mich an Anfang der schwierigste Teil, ist aber dann doch sehr einfach. Ich kann somit ohne ISP-Programmer eine Firmware in den Controller schreiben. Hier grob noch die nächsten Schritte: * Als erstes ist der Bootloader zu konfigurieren, dann via ISP zu programmieren. * Der ISP-Programmer wegräumen. ;) * Als zweites ist die Firmware zu konfigurieren, dann holt sich der Bootloader unsere Firmware via Netzerk/tftpd. =BOOTLOADER= <gallery> File:Putty_bootl_tempmess01.png File:Putty_bootl_tempmess02.png File:Putty_bootl_tempmess03.png File:Putty_bootl_tempmess04.png File:Putty_bootl_tempmess05.png File:Putty_bootl_tempmess06.png File:Putty_bootl_tempmess07.png File:Putty_bootl_tempmess08.png </gallery> ==Bootloader bauen== Ab nun befinde ich mich auf einem <b>virtuellen Debian Rechner</b> wo ich die Firmware herunterlade und daraus den Bootloader erstelle.<br> <b>WICHTIG:</b> Die IP und MAC-Adresse müssen natürlich verändert werden. Die selbe IP und MAC-Adresse müssen in der Firmware später auch benutzt werden. <br> * Bei einem neuen Debian System müssen mit "apt-get" ein paar Sachen nachinstalliert werden. Hier zu finden [[Preparation_(Deutsch)]] * So eine art DHCP wäre auch möglich, nennt sich [[BOOTP_(Deutsch) | BOOTP]]. Darauf gehe ich hier nicht ein. # cd /home/avr/ # mkdir ethersex_IP_60 // Mein "Arbeitsordner" # cd ethersex_IP_60/ // Ordner für das Board mit der IP 192.168.123.60 # git clone git://github.com/ethersex/ethersex.git // ethersex Firmware herunterladen Cloning into ethersex... remote: Counting objects: 37366, done. remote: Total 37366 (delta 0), reused 0 (delta 0), pack-reused 37366 Receiving objects: 100% (37366/37366), 11.27 MiB | 1.22 MiB/s, done. Resolving deltas: 100% (26538/26538), done. # cp -r ethersex bootloader // Ich kopiere den ethersex Ordner zu dem bootloader Ordner. 1:1 Kopie # cd bootloader/ // In den Bootloader Ordner wechseln # make menuconfig // Einstellungen für Bootloader im nächsten Schritt │ │ Load a Default Configuration ---> │ │ (*) Ethernet Bootloader │ │ General Setup ---> │ │ (ATmega644) Target MCU │ │ (20000000) MCU frequency │ │ [*] Build a bootloader │ │ [*] Teensy build │ │ Network ---> │ │ Hostname: "esex060" // Hostname ändern │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" // MAC ändern mit "Randomize MAC address" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" // Wenn IP nicht vorhanden BOOTP deaktivieren! │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ [ ] BOOTP (DHCP-like) support // BOOTP deaktivieren! │ │ Applications ---> │ │ [*] TFTP support ---> │ │ [*] TFTP-o-matic │ │ TFTP-server IPv4 address: "192.168.123.10" // Server wo TFTPD läuft │ │ TFTP image to load: "esex060.bin" // Diesen Dateinamen ladet später unser Board via Netzwerk/tftpd jetzt noch EXIT und SPEICHERN. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 5902/8192 bytes (72.4%) [=====================---------] Program (.text + .data) : 5902 bytes Data (.data + .bss) : 1902 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.hex</b> ==Bootloader flashen via ISP== Ich flashe hier einfacher weise mit meinem Windows 7 Notebook. Ich habe avrdude einfach unter C:\ liegen. Dort kopiere ich nun die ethersex.hex hin.<br> Somit kann man mit dem flashen den Bootloaders loslegen. avrdude -cusbasp -pm644p -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m // gilt nur für atmega644p und vermutlich auch 644 avrdude -cusbasp -pm644p -U flash:w:ethersex.hex avrdude -cusbasp -pm644p -U lock:w:0x0F:m Der Mikrocontrollerboard ist nun vorbereitet für die eigentliche Firmware. Der ISP-Programmer kann nun bei Seite gelegt werden und wird soweit alles richtig konfiguriert ist auch nicht mehr benötigt.<br> Nun erfolgt das Erstellen der Firmware. =FIRMWARE= <gallery> File:Putty_c6_m4_tempmess01.png File:Putty_c6_m4_tempmess02.png File:Putty_c6_m4_tempmess03.png </gallery> ==Firmware bauen== * <b>WICHTIG:</b> IP, MAC Adresse, Gateway, Netmask, Hostname <b>MUSS</b> gleich sein wie bei dem Bootloader! * Der integrierte Webserver ist in der original Firmware schon aktiviert. ( Applications --> [*] HTTP Server ) # cd /home/avr/ethersex_IP_60/ # cd ethersex/ # make menuconfig │ │ Load a Default Configuration ---> │ │ (*) Etherrape │ │ General Setup ---> │ │ (ATmega644) Target MCU // atmega644p bei mir │ │ (20000000) MCU frequency // 20MHz Quarz │ │ [ ] VFS (Virtual File System) support // Benötige ich hier nicht. │ │ [*] control6 script // Hier wird unsere DS1820 Temperatur in eine Variable geschrieben für den implementieren Webserver. │ │ Network ---> // WICHTIG: IP, MAC Adresse, Gateway, Netmask, Hostname MUSS gleich sein wie bei dem Bootloader! │ │ Hostname: "esex060" │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" │ │ Netmask: "255.255.255.0" │ │ │ │ Default gateway: "192.168.123.10" │ │ I/O ---> │ │ [*] Onewire support ---> // Die allgemeine Onewire Unterstützung. │ │ [*] Onewire device detection support // Automatische Bauteilerkennung In der etherrape.m4 Datei wird nun noch der Pin des atmega geändert wo der DS1820 angeschlossen ist. Im NANO Editor wird mit "STRG-O dann Enter" gespeichert und mit STRG-X beendet. # nano pinning/hardware/etherrape.m4 // editieren der m4 Datei ----- ONEWIRE PIN ändern bei "ONEWIRE_PORT_RANGE(PD6, PD6)" zb. auf PD0 ----- Nun schreiben wir uns ein Script welches den Temperatursensor regelmäßig abfragt und in eine Globale Variable schiebt. # rm control6/control6.src // Original Datei löschen # nano control6/control6.src // Anlegen der c6 Datei. Die Datei ist nun neu und leer. C6_HEADER(`/* This will be in control6.h */') CONTROL_START ECMD_GLOBAL(temp01, 0, uint16_t); THREAD(start) temp01 = ONEWIRE_GET(1054698802080017); WAIT(5) THREAD_END(start) ON STARTUP DO THREAD_START(start) END CONTROL_END Kompilieren der eigentlichen Firmware. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 24072/65536 bytes (36.73%) [===========-------------------] Program (.text + .data) : 24072 bytes Data (.data + .bss) : 2250 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.bin</b> Die eigentliche Firmware ist nun kompiliert und fertig um via Netzwerk/tftpd aufgespielt zu werden. Ich verwende im folgenden Schritt Windows 7. Beschreibung folgt. ==Firmware flashen via TFTPD== Platzhalter..folgt in ein paar Tagen mit Fotos. 27-01-2015 [[Category:Tutorials]] 562af9b5f0008cec23cd2e144dfeaaa40f37beea 1574 1571 2016-01-27T20:06:24Z Djmaster 255 wikitext text/x-wiki {{i18n|Template:i18n}} =PROJEKT Temperaturmessung= ===Einleitung=== * ZIEL: Eine einfache Temperaturmessung mit dem DS1820. * ZIEL: Die Ausgabe einer Temperaturvariable via integrierten Webbrowser. * ZIEL: Die Firmware muss via Netzwerk neu flashbar sein. * Abgeändertes vereinfachtes [http://www.lochraster.org/etherrape/ etherrape] Board. * Zwei Spannungsregler, ein atmega644p, ein enc28j60, und etwas 0805 Hühnerfutter. ===Software=== Ethersex (Linux) - https://github.com/ethersex/ethersex Avrdude (Windows) - http://download.savannah.gnu.org/releases/avrdude/ (avrdude-6.1-mingw32.zip) tftpd (Windows) - http://tftpd32.jounin.net/tftpd32_download.html ===Firmware/Bootloader=== Die ethersex Firmware selbst wird für zwei Sachen verwendet. Den <b>Bootloader</b> UND die <b>Firmware</b>. Der Bootloader wird sozusagen einmal in den ersten Bereich des Mikrocontrollers geschrieben und bleibt dort auch. Er wird später die Firmware via Netzwerk entgegennehmen und in den Controller schreiben. Somit befindet sich in den ersten 10% unser Bootloader und in den restlichen 90% der Code den wir wollen. Das zu Verstehen war für mich an Anfang der schwierigste Teil, ist aber dann doch sehr einfach. Ich kann somit ohne ISP-Programmer eine Firmware in den Controller schreiben. Hier grob noch die nächsten Schritte: * Als erstes ist der Bootloader zu konfigurieren, dann via ISP zu programmieren. * Der ISP-Programmer wegräumen. ;) * Als zweites ist die Firmware zu konfigurieren, dann holt sich der Bootloader unsere Firmware via Netzerk/tftpd. =BOOTLOADER= <gallery> File:Putty_bootl_tempmess01.png File:Putty_bootl_tempmess02.png File:Putty_bootl_tempmess03.png File:Putty_bootl_tempmess04.png File:Putty_bootl_tempmess05.png File:Putty_bootl_tempmess06.png File:Putty_bootl_tempmess07.png File:Putty_bootl_tempmess08.png </gallery> ==Bootloader bauen== Ab nun befinde ich mich auf einem <b>virtuellen Debian Rechner</b> wo ich die Firmware herunterlade und daraus den Bootloader erstelle.<br> <b>WICHTIG:</b> Die IP und MAC-Adresse müssen natürlich verändert werden. Die selbe IP und MAC-Adresse müssen in der Firmware später auch benutzt werden. <br> * Bei einem neuen Debian System müssen mit "apt-get" ein paar Sachen nachinstalliert werden. Hier zu finden [[Preparation_(Deutsch)]] * So eine art DHCP wäre auch möglich, nennt sich [[BOOTP_(Deutsch) | BOOTP]]. Darauf gehe ich hier nicht ein. # cd /home/avr/ # mkdir ethersex_IP_60 // Mein "Arbeitsordner" # cd ethersex_IP_60/ // Ordner für das Board mit der IP 192.168.123.60 # git clone git://github.com/ethersex/ethersex.git // ethersex Firmware herunterladen Cloning into ethersex... remote: Counting objects: 37366, done. remote: Total 37366 (delta 0), reused 0 (delta 0), pack-reused 37366 Receiving objects: 100% (37366/37366), 11.27 MiB | 1.22 MiB/s, done. Resolving deltas: 100% (26538/26538), done. # cp -r ethersex bootloader // Ich kopiere den ethersex Ordner zu dem bootloader Ordner. 1:1 Kopie # cd bootloader/ // In den Bootloader Ordner wechseln # make menuconfig // Einstellungen für Bootloader im nächsten Schritt │ │ Load a Default Configuration ---> │ │ (*) Ethernet Bootloader │ │ General Setup ---> │ │ (ATmega644) Target MCU │ │ (20000000) MCU frequency │ │ [*] Build a bootloader │ │ [*] Teensy build │ │ Network ---> │ │ Hostname: "esex060" // Hostname ändern │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" // MAC ändern mit "Randomize MAC address" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" // Wenn IP nicht vorhanden BOOTP deaktivieren! │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ [ ] BOOTP (DHCP-like) support // BOOTP deaktivieren! │ │ Applications ---> │ │ [*] TFTP support ---> │ │ [*] TFTP-o-matic │ │ TFTP-server IPv4 address: "192.168.123.10" // Server wo TFTPD läuft │ │ TFTP image to load: "esex060.bin" // Diesen Dateinamen ladet später unser Board via Netzwerk/tftpd jetzt noch EXIT und SPEICHERN. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 5902/8192 bytes (72.4%) [=====================---------] Program (.text + .data) : 5902 bytes Data (.data + .bss) : 1902 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.hex</b> ==Bootloader flashen via ISP== Ich flashe hier einfacher weise mit meinem Windows 7 Notebook. Ich habe avrdude einfach unter C:\ liegen. Dort kopiere ich nun die ethersex.hex hin.<br> Somit kann man mit dem flashen den Bootloaders loslegen. avrdude -cusbasp -pm644p -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m // gilt nur für atmega644p und vermutlich auch 644 avrdude -cusbasp -pm644p -U flash:w:ethersex.hex avrdude -cusbasp -pm644p -U lock:w:0x0F:m Der Mikrocontrollerboard ist nun vorbereitet für die eigentliche Firmware. Der ISP-Programmer kann nun bei Seite gelegt werden und wird soweit alles richtig konfiguriert ist auch nicht mehr benötigt.<br> Nun erfolgt das Erstellen der Firmware. =FIRMWARE= <gallery> File:Putty_c6_m4_tempmess01.png File:Putty_c6_m4_tempmess02.png File:Putty_c6_m4_tempmess03.png </gallery> ==Firmware bauen== * <b>WICHTIG:</b> IP, MAC Adresse, Gateway, Netmask, Hostname <b>MUSS</b> gleich sein wie bei dem Bootloader! * Der integrierte Webserver ist in der original Firmware schon aktiviert. ( Applications --> [*] HTTP Server ) # cd /home/avr/ethersex_IP_60/ # cd ethersex/ # make menuconfig │ │ Load a Default Configuration ---> │ │ (*) Etherrape │ │ General Setup ---> │ │ (ATmega644) Target MCU // atmega644p bei mir │ │ (20000000) MCU frequency // 20MHz Quarz │ │ [ ] VFS (Virtual File System) support // Benötige ich hier nicht. │ │ [*] control6 script // Hier wird unsere DS1820 Temperatur in eine Variable geschrieben für den implementieren Webserver. │ │ Network ---> // WICHTIG: IP, MAC Adresse, Gateway, Netmask, Hostname MUSS gleich sein wie bei dem Bootloader! │ │ Hostname: "esex060" │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" │ │ Netmask: "255.255.255.0" │ │ │ │ Default gateway: "192.168.123.10" │ │ I/O ---> │ │ [*] Onewire support ---> // Die allgemeine Onewire Unterstützung. │ │ [*] Onewire device detection support // Automatische Bauteilerkennung In der etherrape.m4 Datei wird nun noch der Pin des atmega geändert wo der DS1820 angeschlossen ist. Im NANO Editor wird mit "STRG-O dann Enter" gespeichert und mit STRG-X beendet. # nano pinning/hardware/etherrape.m4 // editieren der m4 Datei ----- ONEWIRE PIN ändern bei "ONEWIRE_PORT_RANGE(PD6, PD6)" zb. auf PD0 ----- Nun schreiben wir uns ein Script welches den Temperatursensor regelmäßig abfragt und in eine Globale Variable schiebt. # rm control6/control6.src // Original Datei löschen # nano control6/control6.src // Anlegen der c6 Datei. Die Datei ist nun neu und leer. C6_HEADER(`/* This will be in control6.h */') CONTROL_START ECMD_GLOBAL(temp01, 0, uint16_t); THREAD(start) temp01 = ONEWIRE_GET(1054698802080017); WAIT(5) THREAD_END(start) ON STARTUP DO THREAD_START(start) END CONTROL_END Kompilieren der eigentlichen Firmware. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 24072/65536 bytes (36.73%) [===========-------------------] Program (.text + .data) : 24072 bytes Data (.data + .bss) : 2250 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.bin</b> Die eigentliche Firmware ist nun kompiliert und fertig um via Netzwerk/tftpd aufgespielt zu werden. Ich verwende im folgenden Schritt Windows 7. Beschreibung folgt. ==Firmware flashen via TFTPD== Platzhalter..folgt in ein paar Tagen mit Fotos. 27-01-2015 [[Category:Tutorials]] 579f8c6683ad879783359469f6c8ef508d6620dd 1575 1574 2016-01-27T20:06:42Z Djmaster 255 wikitext text/x-wiki =PROJEKT Temperaturmessung= ===Einleitung=== * ZIEL: Eine einfache Temperaturmessung mit dem DS1820. * ZIEL: Die Ausgabe einer Temperaturvariable via integrierten Webbrowser. * ZIEL: Die Firmware muss via Netzwerk neu flashbar sein. * Abgeändertes vereinfachtes [http://www.lochraster.org/etherrape/ etherrape] Board. * Zwei Spannungsregler, ein atmega644p, ein enc28j60, und etwas 0805 Hühnerfutter. ===Software=== Ethersex (Linux) - https://github.com/ethersex/ethersex Avrdude (Windows) - http://download.savannah.gnu.org/releases/avrdude/ (avrdude-6.1-mingw32.zip) tftpd (Windows) - http://tftpd32.jounin.net/tftpd32_download.html ===Firmware/Bootloader=== Die ethersex Firmware selbst wird für zwei Sachen verwendet. Den <b>Bootloader</b> UND die <b>Firmware</b>. Der Bootloader wird sozusagen einmal in den ersten Bereich des Mikrocontrollers geschrieben und bleibt dort auch. Er wird später die Firmware via Netzwerk entgegennehmen und in den Controller schreiben. Somit befindet sich in den ersten 10% unser Bootloader und in den restlichen 90% der Code den wir wollen. Das zu Verstehen war für mich an Anfang der schwierigste Teil, ist aber dann doch sehr einfach. Ich kann somit ohne ISP-Programmer eine Firmware in den Controller schreiben. Hier grob noch die nächsten Schritte: * Als erstes ist der Bootloader zu konfigurieren, dann via ISP zu programmieren. * Der ISP-Programmer wegräumen. ;) * Als zweites ist die Firmware zu konfigurieren, dann holt sich der Bootloader unsere Firmware via Netzerk/tftpd. =BOOTLOADER= <gallery> File:Putty_bootl_tempmess01.png File:Putty_bootl_tempmess02.png File:Putty_bootl_tempmess03.png File:Putty_bootl_tempmess04.png File:Putty_bootl_tempmess05.png File:Putty_bootl_tempmess06.png File:Putty_bootl_tempmess07.png File:Putty_bootl_tempmess08.png </gallery> ==Bootloader bauen== Ab nun befinde ich mich auf einem <b>virtuellen Debian Rechner</b> wo ich die Firmware herunterlade und daraus den Bootloader erstelle.<br> <b>WICHTIG:</b> Die IP und MAC-Adresse müssen natürlich verändert werden. Die selbe IP und MAC-Adresse müssen in der Firmware später auch benutzt werden. <br> * Bei einem neuen Debian System müssen mit "apt-get" ein paar Sachen nachinstalliert werden. Hier zu finden [[Preparation_(Deutsch)]] * So eine art DHCP wäre auch möglich, nennt sich [[BOOTP_(Deutsch) | BOOTP]]. Darauf gehe ich hier nicht ein. # cd /home/avr/ # mkdir ethersex_IP_60 // Mein "Arbeitsordner" # cd ethersex_IP_60/ // Ordner für das Board mit der IP 192.168.123.60 # git clone git://github.com/ethersex/ethersex.git // ethersex Firmware herunterladen Cloning into ethersex... remote: Counting objects: 37366, done. remote: Total 37366 (delta 0), reused 0 (delta 0), pack-reused 37366 Receiving objects: 100% (37366/37366), 11.27 MiB | 1.22 MiB/s, done. Resolving deltas: 100% (26538/26538), done. # cp -r ethersex bootloader // Ich kopiere den ethersex Ordner zu dem bootloader Ordner. 1:1 Kopie # cd bootloader/ // In den Bootloader Ordner wechseln # make menuconfig // Einstellungen für Bootloader im nächsten Schritt │ │ Load a Default Configuration ---> │ │ (*) Ethernet Bootloader │ │ General Setup ---> │ │ (ATmega644) Target MCU │ │ (20000000) MCU frequency │ │ [*] Build a bootloader │ │ [*] Teensy build │ │ Network ---> │ │ Hostname: "esex060" // Hostname ändern │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" // MAC ändern mit "Randomize MAC address" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" // Wenn IP nicht vorhanden BOOTP deaktivieren! │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ [ ] BOOTP (DHCP-like) support // BOOTP deaktivieren! │ │ Applications ---> │ │ [*] TFTP support ---> │ │ [*] TFTP-o-matic │ │ TFTP-server IPv4 address: "192.168.123.10" // Server wo TFTPD läuft │ │ TFTP image to load: "esex060.bin" // Diesen Dateinamen ladet später unser Board via Netzwerk/tftpd jetzt noch EXIT und SPEICHERN. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 5902/8192 bytes (72.4%) [=====================---------] Program (.text + .data) : 5902 bytes Data (.data + .bss) : 1902 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.hex</b> ==Bootloader flashen via ISP== Ich flashe hier einfacher weise mit meinem Windows 7 Notebook. Ich habe avrdude einfach unter C:\ liegen. Dort kopiere ich nun die ethersex.hex hin.<br> Somit kann man mit dem flashen den Bootloaders loslegen. avrdude -cusbasp -pm644p -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m // gilt nur für atmega644p und vermutlich auch 644 avrdude -cusbasp -pm644p -U flash:w:ethersex.hex avrdude -cusbasp -pm644p -U lock:w:0x0F:m Der Mikrocontrollerboard ist nun vorbereitet für die eigentliche Firmware. Der ISP-Programmer kann nun bei Seite gelegt werden und wird soweit alles richtig konfiguriert ist auch nicht mehr benötigt.<br> Nun erfolgt das Erstellen der Firmware. =FIRMWARE= <gallery> File:Putty_c6_m4_tempmess01.png File:Putty_c6_m4_tempmess02.png File:Putty_c6_m4_tempmess03.png </gallery> ==Firmware bauen== * <b>WICHTIG:</b> IP, MAC Adresse, Gateway, Netmask, Hostname <b>MUSS</b> gleich sein wie bei dem Bootloader! * Der integrierte Webserver ist in der original Firmware schon aktiviert. ( Applications --> [*] HTTP Server ) # cd /home/avr/ethersex_IP_60/ # cd ethersex/ # make menuconfig │ │ Load a Default Configuration ---> │ │ (*) Etherrape │ │ General Setup ---> │ │ (ATmega644) Target MCU // atmega644p bei mir │ │ (20000000) MCU frequency // 20MHz Quarz │ │ [ ] VFS (Virtual File System) support // Benötige ich hier nicht. │ │ [*] control6 script // Hier wird unsere DS1820 Temperatur in eine Variable geschrieben für den implementieren Webserver. │ │ Network ---> // WICHTIG: IP, MAC Adresse, Gateway, Netmask, Hostname MUSS gleich sein wie bei dem Bootloader! │ │ Hostname: "esex060" │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" │ │ Netmask: "255.255.255.0" │ │ │ │ Default gateway: "192.168.123.10" │ │ I/O ---> │ │ [*] Onewire support ---> // Die allgemeine Onewire Unterstützung. │ │ [*] Onewire device detection support // Automatische Bauteilerkennung In der etherrape.m4 Datei wird nun noch der Pin des atmega geändert wo der DS1820 angeschlossen ist. Im NANO Editor wird mit "STRG-O dann Enter" gespeichert und mit STRG-X beendet. # nano pinning/hardware/etherrape.m4 // editieren der m4 Datei ----- ONEWIRE PIN ändern bei "ONEWIRE_PORT_RANGE(PD6, PD6)" zb. auf PD0 ----- Nun schreiben wir uns ein Script welches den Temperatursensor regelmäßig abfragt und in eine Globale Variable schiebt. # rm control6/control6.src // Original Datei löschen # nano control6/control6.src // Anlegen der c6 Datei. Die Datei ist nun neu und leer. C6_HEADER(`/* This will be in control6.h */') CONTROL_START ECMD_GLOBAL(temp01, 0, uint16_t); THREAD(start) temp01 = ONEWIRE_GET(1054698802080017); WAIT(5) THREAD_END(start) ON STARTUP DO THREAD_START(start) END CONTROL_END Kompilieren der eigentlichen Firmware. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 24072/65536 bytes (36.73%) [===========-------------------] Program (.text + .data) : 24072 bytes Data (.data + .bss) : 2250 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.bin</b> Die eigentliche Firmware ist nun kompiliert und fertig um via Netzwerk/tftpd aufgespielt zu werden. Ich verwende im folgenden Schritt Windows 7. Beschreibung folgt. ==Firmware flashen via TFTPD== Platzhalter..folgt in ein paar Tagen mit Fotos. 27-01-2015 [[Category:Tutorials]] 17b2cdfb65d25586f373b399e666942bfa865a27 1576 1575 2016-01-27T20:08:37Z Djmaster 255 wikitext text/x-wiki {{i18n|Temperaturmesssystem}} =PROJEKT Temperaturmessung= ===Einleitung=== * ZIEL: Eine einfache Temperaturmessung mit dem DS1820. * ZIEL: Die Ausgabe einer Temperaturvariable via integrierten Webbrowser. * ZIEL: Die Firmware muss via Netzwerk neu flashbar sein. * Abgeändertes vereinfachtes [http://www.lochraster.org/etherrape/ etherrape] Board. * Zwei Spannungsregler, ein atmega644p, ein enc28j60, und etwas 0805 Hühnerfutter. ===Software=== Ethersex (Linux) - https://github.com/ethersex/ethersex Avrdude (Windows) - http://download.savannah.gnu.org/releases/avrdude/ (avrdude-6.1-mingw32.zip) tftpd (Windows) - http://tftpd32.jounin.net/tftpd32_download.html ===Firmware/Bootloader=== Die ethersex Firmware selbst wird für zwei Sachen verwendet. Den <b>Bootloader</b> UND die <b>Firmware</b>. Der Bootloader wird sozusagen einmal in den ersten Bereich des Mikrocontrollers geschrieben und bleibt dort auch. Er wird später die Firmware via Netzwerk entgegennehmen und in den Controller schreiben. Somit befindet sich in den ersten 10% unser Bootloader und in den restlichen 90% der Code den wir wollen. Das zu Verstehen war für mich an Anfang der schwierigste Teil, ist aber dann doch sehr einfach. Ich kann somit ohne ISP-Programmer eine Firmware in den Controller schreiben. Hier grob noch die nächsten Schritte: * Als erstes ist der Bootloader zu konfigurieren, dann via ISP zu programmieren. * Der ISP-Programmer wegräumen. ;) * Als zweites ist die Firmware zu konfigurieren, dann holt sich der Bootloader unsere Firmware via Netzerk/tftpd. =BOOTLOADER= <gallery> File:Putty_bootl_tempmess01.png File:Putty_bootl_tempmess02.png File:Putty_bootl_tempmess03.png File:Putty_bootl_tempmess04.png File:Putty_bootl_tempmess05.png File:Putty_bootl_tempmess06.png File:Putty_bootl_tempmess07.png File:Putty_bootl_tempmess08.png </gallery> ==Bootloader bauen== Ab nun befinde ich mich auf einem <b>virtuellen Debian Rechner</b> wo ich die Firmware herunterlade und daraus den Bootloader erstelle.<br> <b>WICHTIG:</b> Die IP und MAC-Adresse müssen natürlich verändert werden. Die selbe IP und MAC-Adresse müssen in der Firmware später auch benutzt werden. <br> * Bei einem neuen Debian System müssen mit "apt-get" ein paar Sachen nachinstalliert werden. Hier zu finden [[Preparation_(Deutsch)]] * So eine art DHCP wäre auch möglich, nennt sich [[BOOTP_(Deutsch) | BOOTP]]. Darauf gehe ich hier nicht ein. # cd /home/avr/ # mkdir ethersex_IP_60 // Mein "Arbeitsordner" # cd ethersex_IP_60/ // Ordner für das Board mit der IP 192.168.123.60 # git clone git://github.com/ethersex/ethersex.git // ethersex Firmware herunterladen Cloning into ethersex... remote: Counting objects: 37366, done. remote: Total 37366 (delta 0), reused 0 (delta 0), pack-reused 37366 Receiving objects: 100% (37366/37366), 11.27 MiB | 1.22 MiB/s, done. Resolving deltas: 100% (26538/26538), done. # cp -r ethersex bootloader // Ich kopiere den ethersex Ordner zu dem bootloader Ordner. 1:1 Kopie # cd bootloader/ // In den Bootloader Ordner wechseln # make menuconfig // Einstellungen für Bootloader im nächsten Schritt │ │ Load a Default Configuration ---> │ │ (*) Ethernet Bootloader │ │ General Setup ---> │ │ (ATmega644) Target MCU │ │ (20000000) MCU frequency │ │ [*] Build a bootloader │ │ [*] Teensy build │ │ Network ---> │ │ Hostname: "esex060" // Hostname ändern │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" // MAC ändern mit "Randomize MAC address" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" // Wenn IP nicht vorhanden BOOTP deaktivieren! │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ [ ] BOOTP (DHCP-like) support // BOOTP deaktivieren! │ │ Applications ---> │ │ [*] TFTP support ---> │ │ [*] TFTP-o-matic │ │ TFTP-server IPv4 address: "192.168.123.10" // Server wo TFTPD läuft │ │ TFTP image to load: "esex060.bin" // Diesen Dateinamen ladet später unser Board via Netzwerk/tftpd jetzt noch EXIT und SPEICHERN. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 5902/8192 bytes (72.4%) [=====================---------] Program (.text + .data) : 5902 bytes Data (.data + .bss) : 1902 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.hex</b> ==Bootloader flashen via ISP== Ich flashe hier einfacher weise mit meinem Windows 7 Notebook. Ich habe avrdude einfach unter C:\ liegen. Dort kopiere ich nun die ethersex.hex hin.<br> Somit kann man mit dem flashen den Bootloaders loslegen. avrdude -cusbasp -pm644p -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m // gilt nur für atmega644p und vermutlich auch 644 avrdude -cusbasp -pm644p -U flash:w:ethersex.hex avrdude -cusbasp -pm644p -U lock:w:0x0F:m Der Mikrocontrollerboard ist nun vorbereitet für die eigentliche Firmware. Der ISP-Programmer kann nun bei Seite gelegt werden und wird soweit alles richtig konfiguriert ist auch nicht mehr benötigt.<br> Nun erfolgt das Erstellen der Firmware. =FIRMWARE= <gallery> File:Putty_c6_m4_tempmess01.png File:Putty_c6_m4_tempmess02.png File:Putty_c6_m4_tempmess03.png </gallery> ==Firmware bauen== * <b>WICHTIG:</b> IP, MAC Adresse, Gateway, Netmask, Hostname <b>MUSS</b> gleich sein wie bei dem Bootloader! * Der integrierte Webserver ist in der original Firmware schon aktiviert. ( Applications --> [*] HTTP Server ) # cd /home/avr/ethersex_IP_60/ # cd ethersex/ # make menuconfig │ │ Load a Default Configuration ---> │ │ (*) Etherrape │ │ General Setup ---> │ │ (ATmega644) Target MCU // atmega644p bei mir │ │ (20000000) MCU frequency // 20MHz Quarz │ │ [ ] VFS (Virtual File System) support // Benötige ich hier nicht. │ │ [*] control6 script // Hier wird unsere DS1820 Temperatur in eine Variable geschrieben für den implementieren Webserver. │ │ Network ---> // WICHTIG: IP, MAC Adresse, Gateway, Netmask, Hostname MUSS gleich sein wie bei dem Bootloader! │ │ Hostname: "esex060" │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" │ │ Netmask: "255.255.255.0" │ │ │ │ Default gateway: "192.168.123.10" │ │ I/O ---> │ │ [*] Onewire support ---> // Die allgemeine Onewire Unterstützung. │ │ [*] Onewire device detection support // Automatische Bauteilerkennung In der etherrape.m4 Datei wird nun noch der Pin des atmega geändert wo der DS1820 angeschlossen ist. Im NANO Editor wird mit "STRG-O dann Enter" gespeichert und mit STRG-X beendet. # nano pinning/hardware/etherrape.m4 // editieren der m4 Datei ----- ONEWIRE PIN ändern bei "ONEWIRE_PORT_RANGE(PD6, PD6)" zb. auf PD0 ----- Nun schreiben wir uns ein Script welches den Temperatursensor regelmäßig abfragt und in eine Globale Variable schiebt. # rm control6/control6.src // Original Datei löschen # nano control6/control6.src // Anlegen der c6 Datei. Die Datei ist nun neu und leer. C6_HEADER(`/* This will be in control6.h */') CONTROL_START ECMD_GLOBAL(temp01, 0, uint16_t); THREAD(start) temp01 = ONEWIRE_GET(1054698802080017); WAIT(5) THREAD_END(start) ON STARTUP DO THREAD_START(start) END CONTROL_END Kompilieren der eigentlichen Firmware. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 24072/65536 bytes (36.73%) [===========-------------------] Program (.text + .data) : 24072 bytes Data (.data + .bss) : 2250 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.bin</b> Die eigentliche Firmware ist nun kompiliert und fertig um via Netzwerk/tftpd aufgespielt zu werden. Ich verwende im folgenden Schritt Windows 7. Beschreibung folgt. ==Firmware flashen via TFTPD== Platzhalter..folgt in ein paar Tagen mit Fotos. 27-01-2015 [[Category:Tutorials]] 2d240febf38ade5b8f18541c7876b6d3748d473d 1579 1576 2016-01-28T19:11:23Z Djmaster 255 /* Einleitung */ wikitext text/x-wiki {{i18n|Temperaturmesssystem}} =PROJEKT Temperaturmessung= ===Einleitung=== * ZIEL: Eine einfache Temperaturmessung mit dem DS1820. * ZIEL: Die Ausgabe einer Temperaturvariable via integrierten Webbrowser. * ZIEL: Die Firmware muss via Netzwerk neu flashbar sein. * Abgeändertes vereinfachtes [http://www.lochraster.org/etherrape/ etherrape] Board. * Zwei Spannungsregler, ein atmega644p, ein enc28j60, und etwas 0805 Hühnerfutter. ===Schaltung=== <gallery> File:Sch_tempmess.png File:Pcb_tempmess.png </gallery> * Erstellt mit Eagle Version 7.1.0 für Windows * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_schematic_001.pdf PDF Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_layout_001.pdf PDF Layout gespiegelt] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.sch Eagle Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.brd Eagle Layout] ===Software=== Ethersex (Linux) - https://github.com/ethersex/ethersex Avrdude (Windows) - http://download.savannah.gnu.org/releases/avrdude/ (avrdude-6.1-mingw32.zip) tftpd (Windows) - http://tftpd32.jounin.net/tftpd32_download.html ===Firmware/Bootloader=== Die ethersex Firmware selbst wird für zwei Sachen verwendet. Den <b>Bootloader</b> UND die <b>Firmware</b>. Der Bootloader wird sozusagen einmal in den ersten Bereich des Mikrocontrollers geschrieben und bleibt dort auch. Er wird später die Firmware via Netzwerk entgegennehmen und in den Controller schreiben. Somit befindet sich in den ersten 10% unser Bootloader und in den restlichen 90% der Code den wir wollen. Das zu Verstehen war für mich an Anfang der schwierigste Teil, ist aber dann doch sehr einfach. Ich kann somit ohne ISP-Programmer eine Firmware in den Controller schreiben. Hier grob noch die nächsten Schritte: * Als erstes ist der Bootloader zu konfigurieren, dann via ISP zu programmieren. * Der ISP-Programmer wegräumen. ;) * Als zweites ist die Firmware zu konfigurieren, dann holt sich der Bootloader unsere Firmware via Netzerk/tftpd. =BOOTLOADER= <gallery> File:Putty_bootl_tempmess01.png File:Putty_bootl_tempmess02.png File:Putty_bootl_tempmess03.png File:Putty_bootl_tempmess04.png File:Putty_bootl_tempmess05.png File:Putty_bootl_tempmess06.png File:Putty_bootl_tempmess07.png File:Putty_bootl_tempmess08.png </gallery> ==Bootloader bauen== Ab nun befinde ich mich auf einem <b>virtuellen Debian Rechner</b> wo ich die Firmware herunterlade und daraus den Bootloader erstelle.<br> <b>WICHTIG:</b> Die IP und MAC-Adresse müssen natürlich verändert werden. Die selbe IP und MAC-Adresse müssen in der Firmware später auch benutzt werden. <br> * Bei einem neuen Debian System müssen mit "apt-get" ein paar Sachen nachinstalliert werden. Hier zu finden [[Preparation_(Deutsch)]] * So eine art DHCP wäre auch möglich, nennt sich [[BOOTP_(Deutsch) | BOOTP]]. Darauf gehe ich hier nicht ein. # cd /home/avr/ # mkdir ethersex_IP_60 // Mein "Arbeitsordner" # cd ethersex_IP_60/ // Ordner für das Board mit der IP 192.168.123.60 # git clone git://github.com/ethersex/ethersex.git // ethersex Firmware herunterladen Cloning into ethersex... remote: Counting objects: 37366, done. remote: Total 37366 (delta 0), reused 0 (delta 0), pack-reused 37366 Receiving objects: 100% (37366/37366), 11.27 MiB | 1.22 MiB/s, done. Resolving deltas: 100% (26538/26538), done. # cp -r ethersex bootloader // Ich kopiere den ethersex Ordner zu dem bootloader Ordner. 1:1 Kopie # cd bootloader/ // In den Bootloader Ordner wechseln # make menuconfig // Einstellungen für Bootloader im nächsten Schritt │ │ Load a Default Configuration ---> │ │ (*) Ethernet Bootloader │ │ General Setup ---> │ │ (ATmega644) Target MCU │ │ (20000000) MCU frequency │ │ [*] Build a bootloader │ │ [*] Teensy build │ │ Network ---> │ │ Hostname: "esex060" // Hostname ändern │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" // MAC ändern mit "Randomize MAC address" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" // Wenn IP nicht vorhanden BOOTP deaktivieren! │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ [ ] BOOTP (DHCP-like) support // BOOTP deaktivieren! │ │ Applications ---> │ │ [*] TFTP support ---> │ │ [*] TFTP-o-matic │ │ TFTP-server IPv4 address: "192.168.123.10" // Server wo TFTPD läuft │ │ TFTP image to load: "esex060.bin" // Diesen Dateinamen ladet später unser Board via Netzwerk/tftpd jetzt noch EXIT und SPEICHERN. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 5902/8192 bytes (72.4%) [=====================---------] Program (.text + .data) : 5902 bytes Data (.data + .bss) : 1902 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.hex</b> ==Bootloader flashen via ISP== Ich flashe hier einfacher weise mit meinem Windows 7 Notebook. Ich habe avrdude einfach unter C:\ liegen. Dort kopiere ich nun die ethersex.hex hin.<br> Somit kann man mit dem flashen den Bootloaders loslegen. avrdude -cusbasp -pm644p -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m // gilt nur für atmega644p und vermutlich auch 644 avrdude -cusbasp -pm644p -U flash:w:ethersex.hex avrdude -cusbasp -pm644p -U lock:w:0x0F:m Der Mikrocontrollerboard ist nun vorbereitet für die eigentliche Firmware. Der ISP-Programmer kann nun bei Seite gelegt werden und wird soweit alles richtig konfiguriert ist auch nicht mehr benötigt.<br> Nun erfolgt das Erstellen der Firmware. =FIRMWARE= <gallery> File:Putty_c6_m4_tempmess01.png File:Putty_c6_m4_tempmess02.png File:Putty_c6_m4_tempmess03.png </gallery> ==Firmware bauen== * <b>WICHTIG:</b> IP, MAC Adresse, Gateway, Netmask, Hostname <b>MUSS</b> gleich sein wie bei dem Bootloader! * Der integrierte Webserver ist in der original Firmware schon aktiviert. ( Applications --> [*] HTTP Server ) # cd /home/avr/ethersex_IP_60/ # cd ethersex/ # make menuconfig │ │ Load a Default Configuration ---> │ │ (*) Etherrape │ │ General Setup ---> │ │ (ATmega644) Target MCU // atmega644p bei mir │ │ (20000000) MCU frequency // 20MHz Quarz │ │ [ ] VFS (Virtual File System) support // Benötige ich hier nicht. │ │ [*] control6 script // Hier wird unsere DS1820 Temperatur in eine Variable geschrieben für den implementieren Webserver. │ │ Network ---> // WICHTIG: IP, MAC Adresse, Gateway, Netmask, Hostname MUSS gleich sein wie bei dem Bootloader! │ │ Hostname: "esex060" │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" │ │ Netmask: "255.255.255.0" │ │ │ │ Default gateway: "192.168.123.10" │ │ I/O ---> │ │ [*] Onewire support ---> // Die allgemeine Onewire Unterstützung. │ │ [*] Onewire device detection support // Automatische Bauteilerkennung In der etherrape.m4 Datei wird nun noch der Pin des atmega geändert wo der DS1820 angeschlossen ist. Im NANO Editor wird mit "STRG-O dann Enter" gespeichert und mit STRG-X beendet. # nano pinning/hardware/etherrape.m4 // editieren der m4 Datei ----- ONEWIRE PIN ändern bei "ONEWIRE_PORT_RANGE(PD6, PD6)" zb. auf PD0 ----- Nun schreiben wir uns ein Script welches den Temperatursensor regelmäßig abfragt und in eine Globale Variable schiebt. # rm control6/control6.src // Original Datei löschen # nano control6/control6.src // Anlegen der c6 Datei. Die Datei ist nun neu und leer. C6_HEADER(`/* This will be in control6.h */') CONTROL_START ECMD_GLOBAL(temp01, 0, uint16_t); THREAD(start) temp01 = ONEWIRE_GET(1054698802080017); WAIT(5) THREAD_END(start) ON STARTUP DO THREAD_START(start) END CONTROL_END Kompilieren der eigentlichen Firmware. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 24072/65536 bytes (36.73%) [===========-------------------] Program (.text + .data) : 24072 bytes Data (.data + .bss) : 2250 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.bin</b> Die eigentliche Firmware ist nun kompiliert und fertig um via Netzwerk/tftpd aufgespielt zu werden. Ich verwende im folgenden Schritt Windows 7. Beschreibung folgt. ==Firmware flashen via TFTPD== Platzhalter..folgt in ein paar Tagen mit Fotos. 27-01-2015 [[Category:Tutorials]] 8fa8cf09f0eecf4959b0d56142224062c311e48f 1580 1579 2016-01-28T19:20:38Z Djmaster 255 /* Schaltung */ wikitext text/x-wiki {{i18n|Temperaturmesssystem}} =PROJEKT Temperaturmessung= ===Einleitung=== * ZIEL: Eine einfache Temperaturmessung mit dem DS1820. * ZIEL: Die Ausgabe einer Temperaturvariable via integrierten Webbrowser. * ZIEL: Die Firmware muss via Netzwerk neu flashbar sein. * Abgeändertes vereinfachtes [http://www.lochraster.org/etherrape/ etherrape] Board. * Zwei Spannungsregler, ein atmega644p, ein enc28j60, und etwas 0805 Hühnerfutter. ===Schaltung=== Das Layout passt in folgendes Gehäuse. Vorher am besten nochmal genau nachmessen. ;)<br> Conrad Bestell-Nr.: [https://www.conrad.at/de/hutschienen-gehaeuse-90-x-360-x-58-polycarbonat-axxatronic-cnmb-2-kit-con-1-st-531441.html 531441] / Axxatronic CNMB-2-KIT-CON <gallery> File:Sch_tempmess.png File:Pcb_tempmess.png </gallery> * Erstellt mit Eagle Version 7.1.0 für Windows * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_schematic_001.pdf PDF Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_layout_001.pdf PDF Layout gespiegelt] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.sch Eagle Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.brd Eagle Layout] ===Software=== Ethersex (Linux) - https://github.com/ethersex/ethersex Avrdude (Windows) - http://download.savannah.gnu.org/releases/avrdude/ (avrdude-6.1-mingw32.zip) tftpd (Windows) - http://tftpd32.jounin.net/tftpd32_download.html ===Firmware/Bootloader=== Die ethersex Firmware selbst wird für zwei Sachen verwendet. Den <b>Bootloader</b> UND die <b>Firmware</b>. Der Bootloader wird sozusagen einmal in den ersten Bereich des Mikrocontrollers geschrieben und bleibt dort auch. Er wird später die Firmware via Netzwerk entgegennehmen und in den Controller schreiben. Somit befindet sich in den ersten 10% unser Bootloader und in den restlichen 90% der Code den wir wollen. Das zu Verstehen war für mich an Anfang der schwierigste Teil, ist aber dann doch sehr einfach. Ich kann somit ohne ISP-Programmer eine Firmware in den Controller schreiben. Hier grob noch die nächsten Schritte: * Als erstes ist der Bootloader zu konfigurieren, dann via ISP zu programmieren. * Der ISP-Programmer wegräumen. ;) * Als zweites ist die Firmware zu konfigurieren, dann holt sich der Bootloader unsere Firmware via Netzerk/tftpd. =BOOTLOADER= <gallery> File:Putty_bootl_tempmess01.png File:Putty_bootl_tempmess02.png File:Putty_bootl_tempmess03.png File:Putty_bootl_tempmess04.png File:Putty_bootl_tempmess05.png File:Putty_bootl_tempmess06.png File:Putty_bootl_tempmess07.png File:Putty_bootl_tempmess08.png </gallery> ==Bootloader bauen== Ab nun befinde ich mich auf einem <b>virtuellen Debian Rechner</b> wo ich die Firmware herunterlade und daraus den Bootloader erstelle.<br> <b>WICHTIG:</b> Die IP und MAC-Adresse müssen natürlich verändert werden. Die selbe IP und MAC-Adresse müssen in der Firmware später auch benutzt werden. <br> * Bei einem neuen Debian System müssen mit "apt-get" ein paar Sachen nachinstalliert werden. Hier zu finden [[Preparation_(Deutsch)]] * So eine art DHCP wäre auch möglich, nennt sich [[BOOTP_(Deutsch) | BOOTP]]. Darauf gehe ich hier nicht ein. # cd /home/avr/ # mkdir ethersex_IP_60 // Mein "Arbeitsordner" # cd ethersex_IP_60/ // Ordner für das Board mit der IP 192.168.123.60 # git clone git://github.com/ethersex/ethersex.git // ethersex Firmware herunterladen Cloning into ethersex... remote: Counting objects: 37366, done. remote: Total 37366 (delta 0), reused 0 (delta 0), pack-reused 37366 Receiving objects: 100% (37366/37366), 11.27 MiB | 1.22 MiB/s, done. Resolving deltas: 100% (26538/26538), done. # cp -r ethersex bootloader // Ich kopiere den ethersex Ordner zu dem bootloader Ordner. 1:1 Kopie # cd bootloader/ // In den Bootloader Ordner wechseln # make menuconfig // Einstellungen für Bootloader im nächsten Schritt │ │ Load a Default Configuration ---> │ │ (*) Ethernet Bootloader │ │ General Setup ---> │ │ (ATmega644) Target MCU │ │ (20000000) MCU frequency │ │ [*] Build a bootloader │ │ [*] Teensy build │ │ Network ---> │ │ Hostname: "esex060" // Hostname ändern │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" // MAC ändern mit "Randomize MAC address" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" // Wenn IP nicht vorhanden BOOTP deaktivieren! │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ [ ] BOOTP (DHCP-like) support // BOOTP deaktivieren! │ │ Applications ---> │ │ [*] TFTP support ---> │ │ [*] TFTP-o-matic │ │ TFTP-server IPv4 address: "192.168.123.10" // Server wo TFTPD läuft │ │ TFTP image to load: "esex060.bin" // Diesen Dateinamen ladet später unser Board via Netzwerk/tftpd jetzt noch EXIT und SPEICHERN. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 5902/8192 bytes (72.4%) [=====================---------] Program (.text + .data) : 5902 bytes Data (.data + .bss) : 1902 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.hex</b> ==Bootloader flashen via ISP== Ich flashe hier einfacher weise mit meinem Windows 7 Notebook. Ich habe avrdude einfach unter C:\ liegen. Dort kopiere ich nun die ethersex.hex hin.<br> Somit kann man mit dem flashen den Bootloaders loslegen. avrdude -cusbasp -pm644p -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m // gilt nur für atmega644p und vermutlich auch 644 avrdude -cusbasp -pm644p -U flash:w:ethersex.hex avrdude -cusbasp -pm644p -U lock:w:0x0F:m Der Mikrocontrollerboard ist nun vorbereitet für die eigentliche Firmware. Der ISP-Programmer kann nun bei Seite gelegt werden und wird soweit alles richtig konfiguriert ist auch nicht mehr benötigt.<br> Nun erfolgt das Erstellen der Firmware. =FIRMWARE= <gallery> File:Putty_c6_m4_tempmess01.png File:Putty_c6_m4_tempmess02.png File:Putty_c6_m4_tempmess03.png </gallery> ==Firmware bauen== * <b>WICHTIG:</b> IP, MAC Adresse, Gateway, Netmask, Hostname <b>MUSS</b> gleich sein wie bei dem Bootloader! * Der integrierte Webserver ist in der original Firmware schon aktiviert. ( Applications --> [*] HTTP Server ) # cd /home/avr/ethersex_IP_60/ # cd ethersex/ # make menuconfig │ │ Load a Default Configuration ---> │ │ (*) Etherrape │ │ General Setup ---> │ │ (ATmega644) Target MCU // atmega644p bei mir │ │ (20000000) MCU frequency // 20MHz Quarz │ │ [ ] VFS (Virtual File System) support // Benötige ich hier nicht. │ │ [*] control6 script // Hier wird unsere DS1820 Temperatur in eine Variable geschrieben für den implementieren Webserver. │ │ Network ---> // WICHTIG: IP, MAC Adresse, Gateway, Netmask, Hostname MUSS gleich sein wie bei dem Bootloader! │ │ Hostname: "esex060" │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" │ │ Netmask: "255.255.255.0" │ │ │ │ Default gateway: "192.168.123.10" │ │ I/O ---> │ │ [*] Onewire support ---> // Die allgemeine Onewire Unterstützung. │ │ [*] Onewire device detection support // Automatische Bauteilerkennung In der etherrape.m4 Datei wird nun noch der Pin des atmega geändert wo der DS1820 angeschlossen ist. Im NANO Editor wird mit "STRG-O dann Enter" gespeichert und mit STRG-X beendet. # nano pinning/hardware/etherrape.m4 // editieren der m4 Datei ----- ONEWIRE PIN ändern bei "ONEWIRE_PORT_RANGE(PD6, PD6)" zb. auf PD0 ----- Nun schreiben wir uns ein Script welches den Temperatursensor regelmäßig abfragt und in eine Globale Variable schiebt. # rm control6/control6.src // Original Datei löschen # nano control6/control6.src // Anlegen der c6 Datei. Die Datei ist nun neu und leer. C6_HEADER(`/* This will be in control6.h */') CONTROL_START ECMD_GLOBAL(temp01, 0, uint16_t); THREAD(start) temp01 = ONEWIRE_GET(1054698802080017); WAIT(5) THREAD_END(start) ON STARTUP DO THREAD_START(start) END CONTROL_END Kompilieren der eigentlichen Firmware. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 24072/65536 bytes (36.73%) [===========-------------------] Program (.text + .data) : 24072 bytes Data (.data + .bss) : 2250 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.bin</b> Die eigentliche Firmware ist nun kompiliert und fertig um via Netzwerk/tftpd aufgespielt zu werden. Ich verwende im folgenden Schritt Windows 7. Beschreibung folgt. ==Firmware flashen via TFTPD== Platzhalter..folgt in ein paar Tagen mit Fotos. 27-01-2015 [[Category:Tutorials]] 9853aa000608d69fd4016bfebd4f84b4e5085cf8 1581 1580 2016-01-28T19:25:32Z Djmaster 255 /* Einleitung */ wikitext text/x-wiki {{i18n|Temperaturmesssystem}} =PROJEKT Temperaturmessung= ===Einleitung=== * ZIEL: Eine einfache Temperaturmessung mit dem [[Onewire_(Deutsch)#Anschluss_AVR-NET-IO | DS1820 im parasitären Modus]]. * ZIEL: Die Ausgabe einer Temperaturvariable via integrierten Webbrowser. * ZIEL: Die Firmware muss via Netzwerk neu flashbar sein. * Abgeändertes vereinfachtes [http://www.lochraster.org/etherrape/ etherrape] Board. * Zwei Spannungsregler, ein atmega644p, ein enc28j60, und etwas 0805 Hühnerfutter. ===Schaltung=== Das Layout passt in folgendes Gehäuse. Vorher am besten nochmal genau nachmessen. ;)<br> Conrad Bestell-Nr.: [https://www.conrad.at/de/hutschienen-gehaeuse-90-x-360-x-58-polycarbonat-axxatronic-cnmb-2-kit-con-1-st-531441.html 531441] / Axxatronic CNMB-2-KIT-CON <gallery> File:Sch_tempmess.png File:Pcb_tempmess.png </gallery> * Erstellt mit Eagle Version 7.1.0 für Windows * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_schematic_001.pdf PDF Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_layout_001.pdf PDF Layout gespiegelt] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.sch Eagle Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.brd Eagle Layout] ===Software=== Ethersex (Linux) - https://github.com/ethersex/ethersex Avrdude (Windows) - http://download.savannah.gnu.org/releases/avrdude/ (avrdude-6.1-mingw32.zip) tftpd (Windows) - http://tftpd32.jounin.net/tftpd32_download.html ===Firmware/Bootloader=== Die ethersex Firmware selbst wird für zwei Sachen verwendet. Den <b>Bootloader</b> UND die <b>Firmware</b>. Der Bootloader wird sozusagen einmal in den ersten Bereich des Mikrocontrollers geschrieben und bleibt dort auch. Er wird später die Firmware via Netzwerk entgegennehmen und in den Controller schreiben. Somit befindet sich in den ersten 10% unser Bootloader und in den restlichen 90% der Code den wir wollen. Das zu Verstehen war für mich an Anfang der schwierigste Teil, ist aber dann doch sehr einfach. Ich kann somit ohne ISP-Programmer eine Firmware in den Controller schreiben. Hier grob noch die nächsten Schritte: * Als erstes ist der Bootloader zu konfigurieren, dann via ISP zu programmieren. * Der ISP-Programmer wegräumen. ;) * Als zweites ist die Firmware zu konfigurieren, dann holt sich der Bootloader unsere Firmware via Netzerk/tftpd. =BOOTLOADER= <gallery> File:Putty_bootl_tempmess01.png File:Putty_bootl_tempmess02.png File:Putty_bootl_tempmess03.png File:Putty_bootl_tempmess04.png File:Putty_bootl_tempmess05.png File:Putty_bootl_tempmess06.png File:Putty_bootl_tempmess07.png File:Putty_bootl_tempmess08.png </gallery> ==Bootloader bauen== Ab nun befinde ich mich auf einem <b>virtuellen Debian Rechner</b> wo ich die Firmware herunterlade und daraus den Bootloader erstelle.<br> <b>WICHTIG:</b> Die IP und MAC-Adresse müssen natürlich verändert werden. Die selbe IP und MAC-Adresse müssen in der Firmware später auch benutzt werden. <br> * Bei einem neuen Debian System müssen mit "apt-get" ein paar Sachen nachinstalliert werden. Hier zu finden [[Preparation_(Deutsch)]] * So eine art DHCP wäre auch möglich, nennt sich [[BOOTP_(Deutsch) | BOOTP]]. Darauf gehe ich hier nicht ein. # cd /home/avr/ # mkdir ethersex_IP_60 // Mein "Arbeitsordner" # cd ethersex_IP_60/ // Ordner für das Board mit der IP 192.168.123.60 # git clone git://github.com/ethersex/ethersex.git // ethersex Firmware herunterladen Cloning into ethersex... remote: Counting objects: 37366, done. remote: Total 37366 (delta 0), reused 0 (delta 0), pack-reused 37366 Receiving objects: 100% (37366/37366), 11.27 MiB | 1.22 MiB/s, done. Resolving deltas: 100% (26538/26538), done. # cp -r ethersex bootloader // Ich kopiere den ethersex Ordner zu dem bootloader Ordner. 1:1 Kopie # cd bootloader/ // In den Bootloader Ordner wechseln # make menuconfig // Einstellungen für Bootloader im nächsten Schritt │ │ Load a Default Configuration ---> │ │ (*) Ethernet Bootloader │ │ General Setup ---> │ │ (ATmega644) Target MCU │ │ (20000000) MCU frequency │ │ [*] Build a bootloader │ │ [*] Teensy build │ │ Network ---> │ │ Hostname: "esex060" // Hostname ändern │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" // MAC ändern mit "Randomize MAC address" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" // Wenn IP nicht vorhanden BOOTP deaktivieren! │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ [ ] BOOTP (DHCP-like) support // BOOTP deaktivieren! │ │ Applications ---> │ │ [*] TFTP support ---> │ │ [*] TFTP-o-matic │ │ TFTP-server IPv4 address: "192.168.123.10" // Server wo TFTPD läuft │ │ TFTP image to load: "esex060.bin" // Diesen Dateinamen ladet später unser Board via Netzwerk/tftpd jetzt noch EXIT und SPEICHERN. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 5902/8192 bytes (72.4%) [=====================---------] Program (.text + .data) : 5902 bytes Data (.data + .bss) : 1902 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.hex</b> ==Bootloader flashen via ISP== Ich flashe hier einfacher weise mit meinem Windows 7 Notebook. Ich habe avrdude einfach unter C:\ liegen. Dort kopiere ich nun die ethersex.hex hin.<br> Somit kann man mit dem flashen den Bootloaders loslegen. avrdude -cusbasp -pm644p -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m // gilt nur für atmega644p und vermutlich auch 644 avrdude -cusbasp -pm644p -U flash:w:ethersex.hex avrdude -cusbasp -pm644p -U lock:w:0x0F:m Der Mikrocontrollerboard ist nun vorbereitet für die eigentliche Firmware. Der ISP-Programmer kann nun bei Seite gelegt werden und wird soweit alles richtig konfiguriert ist auch nicht mehr benötigt.<br> Nun erfolgt das Erstellen der Firmware. =FIRMWARE= <gallery> File:Putty_c6_m4_tempmess01.png File:Putty_c6_m4_tempmess02.png File:Putty_c6_m4_tempmess03.png </gallery> ==Firmware bauen== * <b>WICHTIG:</b> IP, MAC Adresse, Gateway, Netmask, Hostname <b>MUSS</b> gleich sein wie bei dem Bootloader! * Der integrierte Webserver ist in der original Firmware schon aktiviert. ( Applications --> [*] HTTP Server ) # cd /home/avr/ethersex_IP_60/ # cd ethersex/ # make menuconfig │ │ Load a Default Configuration ---> │ │ (*) Etherrape │ │ General Setup ---> │ │ (ATmega644) Target MCU // atmega644p bei mir │ │ (20000000) MCU frequency // 20MHz Quarz │ │ [ ] VFS (Virtual File System) support // Benötige ich hier nicht. │ │ [*] control6 script // Hier wird unsere DS1820 Temperatur in eine Variable geschrieben für den implementieren Webserver. │ │ Network ---> // WICHTIG: IP, MAC Adresse, Gateway, Netmask, Hostname MUSS gleich sein wie bei dem Bootloader! │ │ Hostname: "esex060" │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" │ │ Netmask: "255.255.255.0" │ │ │ │ Default gateway: "192.168.123.10" │ │ I/O ---> │ │ [*] Onewire support ---> // Die allgemeine Onewire Unterstützung. │ │ [*] Onewire device detection support // Automatische Bauteilerkennung In der etherrape.m4 Datei wird nun noch der Pin des atmega geändert wo der DS1820 angeschlossen ist. Im NANO Editor wird mit "STRG-O dann Enter" gespeichert und mit STRG-X beendet. # nano pinning/hardware/etherrape.m4 // editieren der m4 Datei ----- ONEWIRE PIN ändern bei "ONEWIRE_PORT_RANGE(PD6, PD6)" zb. auf PD0 ----- Nun schreiben wir uns ein Script welches den Temperatursensor regelmäßig abfragt und in eine Globale Variable schiebt. # rm control6/control6.src // Original Datei löschen # nano control6/control6.src // Anlegen der c6 Datei. Die Datei ist nun neu und leer. C6_HEADER(`/* This will be in control6.h */') CONTROL_START ECMD_GLOBAL(temp01, 0, uint16_t); THREAD(start) temp01 = ONEWIRE_GET(1054698802080017); WAIT(5) THREAD_END(start) ON STARTUP DO THREAD_START(start) END CONTROL_END Kompilieren der eigentlichen Firmware. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 24072/65536 bytes (36.73%) [===========-------------------] Program (.text + .data) : 24072 bytes Data (.data + .bss) : 2250 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.bin</b> Die eigentliche Firmware ist nun kompiliert und fertig um via Netzwerk/tftpd aufgespielt zu werden. Ich verwende im folgenden Schritt Windows 7. Beschreibung folgt. ==Firmware flashen via TFTPD== Platzhalter..folgt in ein paar Tagen mit Fotos. 27-01-2015 [[Category:Tutorials]] 356a0607b378fcd40555f117bde17fb66010a429 1582 1581 2016-01-28T19:29:05Z Djmaster 255 /* Einleitung */ wikitext text/x-wiki {{i18n|Temperaturmesssystem}} =PROJEKT Temperaturmessung= ===Einleitung=== * ZIEL: Eine einfache Temperaturmessung mit dem [[Onewire_(Deutsch)#Anschluss_AVR-NET-IO | DS1820 im parasitären Modus]]. * ZIEL: Die Ausgabe einer Temperaturvariable via integrierten Webbrowser oder telnet. * ZIEL: Die Firmware muss via Netzwerk neu flashbar sein. * Abgeändertes vereinfachtes [http://www.lochraster.org/etherrape/ etherrape] Board. * Zwei Spannungsregler, ein atmega644p, ein enc28j60, und etwas 0805 Hühnerfutter. ===Schaltung=== Das Layout passt in folgendes Gehäuse. Vorher am besten nochmal genau nachmessen. ;)<br> Conrad Bestell-Nr.: [https://www.conrad.at/de/hutschienen-gehaeuse-90-x-360-x-58-polycarbonat-axxatronic-cnmb-2-kit-con-1-st-531441.html 531441] / Axxatronic CNMB-2-KIT-CON <gallery> File:Sch_tempmess.png File:Pcb_tempmess.png </gallery> * Erstellt mit Eagle Version 7.1.0 für Windows * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_schematic_001.pdf PDF Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_layout_001.pdf PDF Layout gespiegelt] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.sch Eagle Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.brd Eagle Layout] ===Software=== Ethersex (Linux) - https://github.com/ethersex/ethersex Avrdude (Windows) - http://download.savannah.gnu.org/releases/avrdude/ (avrdude-6.1-mingw32.zip) tftpd (Windows) - http://tftpd32.jounin.net/tftpd32_download.html ===Firmware/Bootloader=== Die ethersex Firmware selbst wird für zwei Sachen verwendet. Den <b>Bootloader</b> UND die <b>Firmware</b>. Der Bootloader wird sozusagen einmal in den ersten Bereich des Mikrocontrollers geschrieben und bleibt dort auch. Er wird später die Firmware via Netzwerk entgegennehmen und in den Controller schreiben. Somit befindet sich in den ersten 10% unser Bootloader und in den restlichen 90% der Code den wir wollen. Das zu Verstehen war für mich an Anfang der schwierigste Teil, ist aber dann doch sehr einfach. Ich kann somit ohne ISP-Programmer eine Firmware in den Controller schreiben. Hier grob noch die nächsten Schritte: * Als erstes ist der Bootloader zu konfigurieren, dann via ISP zu programmieren. * Der ISP-Programmer wegräumen. ;) * Als zweites ist die Firmware zu konfigurieren, dann holt sich der Bootloader unsere Firmware via Netzerk/tftpd. =BOOTLOADER= <gallery> File:Putty_bootl_tempmess01.png File:Putty_bootl_tempmess02.png File:Putty_bootl_tempmess03.png File:Putty_bootl_tempmess04.png File:Putty_bootl_tempmess05.png File:Putty_bootl_tempmess06.png File:Putty_bootl_tempmess07.png File:Putty_bootl_tempmess08.png </gallery> ==Bootloader bauen== Ab nun befinde ich mich auf einem <b>virtuellen Debian Rechner</b> wo ich die Firmware herunterlade und daraus den Bootloader erstelle.<br> <b>WICHTIG:</b> Die IP und MAC-Adresse müssen natürlich verändert werden. Die selbe IP und MAC-Adresse müssen in der Firmware später auch benutzt werden. <br> * Bei einem neuen Debian System müssen mit "apt-get" ein paar Sachen nachinstalliert werden. Hier zu finden [[Preparation_(Deutsch)]] * So eine art DHCP wäre auch möglich, nennt sich [[BOOTP_(Deutsch) | BOOTP]]. Darauf gehe ich hier nicht ein. # cd /home/avr/ # mkdir ethersex_IP_60 // Mein "Arbeitsordner" # cd ethersex_IP_60/ // Ordner für das Board mit der IP 192.168.123.60 # git clone git://github.com/ethersex/ethersex.git // ethersex Firmware herunterladen Cloning into ethersex... remote: Counting objects: 37366, done. remote: Total 37366 (delta 0), reused 0 (delta 0), pack-reused 37366 Receiving objects: 100% (37366/37366), 11.27 MiB | 1.22 MiB/s, done. Resolving deltas: 100% (26538/26538), done. # cp -r ethersex bootloader // Ich kopiere den ethersex Ordner zu dem bootloader Ordner. 1:1 Kopie # cd bootloader/ // In den Bootloader Ordner wechseln # make menuconfig // Einstellungen für Bootloader im nächsten Schritt │ │ Load a Default Configuration ---> │ │ (*) Ethernet Bootloader │ │ General Setup ---> │ │ (ATmega644) Target MCU │ │ (20000000) MCU frequency │ │ [*] Build a bootloader │ │ [*] Teensy build │ │ Network ---> │ │ Hostname: "esex060" // Hostname ändern │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" // MAC ändern mit "Randomize MAC address" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" // Wenn IP nicht vorhanden BOOTP deaktivieren! │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ [ ] BOOTP (DHCP-like) support // BOOTP deaktivieren! │ │ Applications ---> │ │ [*] TFTP support ---> │ │ [*] TFTP-o-matic │ │ TFTP-server IPv4 address: "192.168.123.10" // Server wo TFTPD läuft │ │ TFTP image to load: "esex060.bin" // Diesen Dateinamen ladet später unser Board via Netzwerk/tftpd jetzt noch EXIT und SPEICHERN. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 5902/8192 bytes (72.4%) [=====================---------] Program (.text + .data) : 5902 bytes Data (.data + .bss) : 1902 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.hex</b> ==Bootloader flashen via ISP== Ich flashe hier einfacher weise mit meinem Windows 7 Notebook. Ich habe avrdude einfach unter C:\ liegen. Dort kopiere ich nun die ethersex.hex hin.<br> Somit kann man mit dem flashen den Bootloaders loslegen. avrdude -cusbasp -pm644p -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m // gilt nur für atmega644p und vermutlich auch 644 avrdude -cusbasp -pm644p -U flash:w:ethersex.hex avrdude -cusbasp -pm644p -U lock:w:0x0F:m Der Mikrocontrollerboard ist nun vorbereitet für die eigentliche Firmware. Der ISP-Programmer kann nun bei Seite gelegt werden und wird soweit alles richtig konfiguriert ist auch nicht mehr benötigt.<br> Nun erfolgt das Erstellen der Firmware. =FIRMWARE= <gallery> File:Putty_c6_m4_tempmess01.png File:Putty_c6_m4_tempmess02.png File:Putty_c6_m4_tempmess03.png </gallery> ==Firmware bauen== * <b>WICHTIG:</b> IP, MAC Adresse, Gateway, Netmask, Hostname <b>MUSS</b> gleich sein wie bei dem Bootloader! * Der integrierte Webserver ist in der original Firmware schon aktiviert. ( Applications --> [*] HTTP Server ) # cd /home/avr/ethersex_IP_60/ # cd ethersex/ # make menuconfig │ │ Load a Default Configuration ---> │ │ (*) Etherrape │ │ General Setup ---> │ │ (ATmega644) Target MCU // atmega644p bei mir │ │ (20000000) MCU frequency // 20MHz Quarz │ │ [ ] VFS (Virtual File System) support // Benötige ich hier nicht. │ │ [*] control6 script // Hier wird unsere DS1820 Temperatur in eine Variable geschrieben für den implementieren Webserver. │ │ Network ---> // WICHTIG: IP, MAC Adresse, Gateway, Netmask, Hostname MUSS gleich sein wie bei dem Bootloader! │ │ Hostname: "esex060" │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" │ │ Netmask: "255.255.255.0" │ │ │ │ Default gateway: "192.168.123.10" │ │ I/O ---> │ │ [*] Onewire support ---> // Die allgemeine Onewire Unterstützung. │ │ [*] Onewire device detection support // Automatische Bauteilerkennung In der etherrape.m4 Datei wird nun noch der Pin des atmega geändert wo der DS1820 angeschlossen ist. Im NANO Editor wird mit "STRG-O dann Enter" gespeichert und mit STRG-X beendet. # nano pinning/hardware/etherrape.m4 // editieren der m4 Datei ----- ONEWIRE PIN ändern bei "ONEWIRE_PORT_RANGE(PD6, PD6)" zb. auf PD0 ----- Nun schreiben wir uns ein Script welches den Temperatursensor regelmäßig abfragt und in eine Globale Variable schiebt. # rm control6/control6.src // Original Datei löschen # nano control6/control6.src // Anlegen der c6 Datei. Die Datei ist nun neu und leer. C6_HEADER(`/* This will be in control6.h */') CONTROL_START ECMD_GLOBAL(temp01, 0, uint16_t); THREAD(start) temp01 = ONEWIRE_GET(1054698802080017); WAIT(5) THREAD_END(start) ON STARTUP DO THREAD_START(start) END CONTROL_END Kompilieren der eigentlichen Firmware. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 24072/65536 bytes (36.73%) [===========-------------------] Program (.text + .data) : 24072 bytes Data (.data + .bss) : 2250 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.bin</b> Die eigentliche Firmware ist nun kompiliert und fertig um via Netzwerk/tftpd aufgespielt zu werden. Ich verwende im folgenden Schritt Windows 7. Beschreibung folgt. ==Firmware flashen via TFTPD== Platzhalter..folgt in ein paar Tagen mit Fotos. 27-01-2015 [[Category:Tutorials]] 0f0397c359345c0403e237aebc411463996e4d9d 1584 1582 2016-01-28T19:49:05Z Djmaster 255 /* Firmware flashen via TFTPD */ wikitext text/x-wiki {{i18n|Temperaturmesssystem}} =PROJEKT Temperaturmessung= ===Einleitung=== * ZIEL: Eine einfache Temperaturmessung mit dem [[Onewire_(Deutsch)#Anschluss_AVR-NET-IO | DS1820 im parasitären Modus]]. * ZIEL: Die Ausgabe einer Temperaturvariable via integrierten Webbrowser oder telnet. * ZIEL: Die Firmware muss via Netzwerk neu flashbar sein. * Abgeändertes vereinfachtes [http://www.lochraster.org/etherrape/ etherrape] Board. * Zwei Spannungsregler, ein atmega644p, ein enc28j60, und etwas 0805 Hühnerfutter. ===Schaltung=== Das Layout passt in folgendes Gehäuse. Vorher am besten nochmal genau nachmessen. ;)<br> Conrad Bestell-Nr.: [https://www.conrad.at/de/hutschienen-gehaeuse-90-x-360-x-58-polycarbonat-axxatronic-cnmb-2-kit-con-1-st-531441.html 531441] / Axxatronic CNMB-2-KIT-CON <gallery> File:Sch_tempmess.png File:Pcb_tempmess.png </gallery> * Erstellt mit Eagle Version 7.1.0 für Windows * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_schematic_001.pdf PDF Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_layout_001.pdf PDF Layout gespiegelt] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.sch Eagle Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.brd Eagle Layout] ===Software=== Ethersex (Linux) - https://github.com/ethersex/ethersex Avrdude (Windows) - http://download.savannah.gnu.org/releases/avrdude/ (avrdude-6.1-mingw32.zip) tftpd (Windows) - http://tftpd32.jounin.net/tftpd32_download.html ===Firmware/Bootloader=== Die ethersex Firmware selbst wird für zwei Sachen verwendet. Den <b>Bootloader</b> UND die <b>Firmware</b>. Der Bootloader wird sozusagen einmal in den ersten Bereich des Mikrocontrollers geschrieben und bleibt dort auch. Er wird später die Firmware via Netzwerk entgegennehmen und in den Controller schreiben. Somit befindet sich in den ersten 10% unser Bootloader und in den restlichen 90% der Code den wir wollen. Das zu Verstehen war für mich an Anfang der schwierigste Teil, ist aber dann doch sehr einfach. Ich kann somit ohne ISP-Programmer eine Firmware in den Controller schreiben. Hier grob noch die nächsten Schritte: * Als erstes ist der Bootloader zu konfigurieren, dann via ISP zu programmieren. * Der ISP-Programmer wegräumen. ;) * Als zweites ist die Firmware zu konfigurieren, dann holt sich der Bootloader unsere Firmware via Netzerk/tftpd. =BOOTLOADER= <gallery> File:Putty_bootl_tempmess01.png File:Putty_bootl_tempmess02.png File:Putty_bootl_tempmess03.png File:Putty_bootl_tempmess04.png File:Putty_bootl_tempmess05.png File:Putty_bootl_tempmess06.png File:Putty_bootl_tempmess07.png File:Putty_bootl_tempmess08.png </gallery> ==Bootloader bauen== Ab nun befinde ich mich auf einem <b>virtuellen Debian Rechner</b> wo ich die Firmware herunterlade und daraus den Bootloader erstelle.<br> <b>WICHTIG:</b> Die IP und MAC-Adresse müssen natürlich verändert werden. Die selbe IP und MAC-Adresse müssen in der Firmware später auch benutzt werden. <br> * Bei einem neuen Debian System müssen mit "apt-get" ein paar Sachen nachinstalliert werden. Hier zu finden [[Preparation_(Deutsch)]] * So eine art DHCP wäre auch möglich, nennt sich [[BOOTP_(Deutsch) | BOOTP]]. Darauf gehe ich hier nicht ein. # cd /home/avr/ # mkdir ethersex_IP_60 // Mein "Arbeitsordner" # cd ethersex_IP_60/ // Ordner für das Board mit der IP 192.168.123.60 # git clone git://github.com/ethersex/ethersex.git // ethersex Firmware herunterladen Cloning into ethersex... remote: Counting objects: 37366, done. remote: Total 37366 (delta 0), reused 0 (delta 0), pack-reused 37366 Receiving objects: 100% (37366/37366), 11.27 MiB | 1.22 MiB/s, done. Resolving deltas: 100% (26538/26538), done. # cp -r ethersex bootloader // Ich kopiere den ethersex Ordner zu dem bootloader Ordner. 1:1 Kopie # cd bootloader/ // In den Bootloader Ordner wechseln # make menuconfig // Einstellungen für Bootloader im nächsten Schritt │ │ Load a Default Configuration ---> │ │ (*) Ethernet Bootloader │ │ General Setup ---> │ │ (ATmega644) Target MCU │ │ (20000000) MCU frequency │ │ [*] Build a bootloader │ │ [*] Teensy build │ │ Network ---> │ │ Hostname: "esex060" // Hostname ändern │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" // MAC ändern mit "Randomize MAC address" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" // Wenn IP nicht vorhanden BOOTP deaktivieren! │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ [ ] BOOTP (DHCP-like) support // BOOTP deaktivieren! │ │ Applications ---> │ │ [*] TFTP support ---> │ │ [*] TFTP-o-matic │ │ TFTP-server IPv4 address: "192.168.123.10" // Server wo TFTPD läuft │ │ TFTP image to load: "esex060.bin" // Diesen Dateinamen ladet später unser Board via Netzwerk/tftpd jetzt noch EXIT und SPEICHERN. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 5902/8192 bytes (72.4%) [=====================---------] Program (.text + .data) : 5902 bytes Data (.data + .bss) : 1902 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.hex</b> ==Bootloader flashen via ISP== Ich flashe hier einfacher weise mit meinem Windows 7 Notebook. Ich habe avrdude einfach unter C:\ liegen. Dort kopiere ich nun die ethersex.hex hin.<br> Somit kann man mit dem flashen den Bootloaders loslegen. avrdude -cusbasp -pm644p -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m // gilt nur für atmega644p und vermutlich auch 644 avrdude -cusbasp -pm644p -U flash:w:ethersex.hex avrdude -cusbasp -pm644p -U lock:w:0x0F:m Der Mikrocontrollerboard ist nun vorbereitet für die eigentliche Firmware. Der ISP-Programmer kann nun bei Seite gelegt werden und wird soweit alles richtig konfiguriert ist auch nicht mehr benötigt.<br> Nun erfolgt das Erstellen der Firmware. =FIRMWARE= <gallery> File:Putty_c6_m4_tempmess01.png File:Putty_c6_m4_tempmess02.png File:Putty_c6_m4_tempmess03.png </gallery> ==Firmware bauen== * <b>WICHTIG:</b> IP, MAC Adresse, Gateway, Netmask, Hostname <b>MUSS</b> gleich sein wie bei dem Bootloader! * Der integrierte Webserver ist in der original Firmware schon aktiviert. ( Applications --> [*] HTTP Server ) # cd /home/avr/ethersex_IP_60/ # cd ethersex/ # make menuconfig │ │ Load a Default Configuration ---> │ │ (*) Etherrape │ │ General Setup ---> │ │ (ATmega644) Target MCU // atmega644p bei mir │ │ (20000000) MCU frequency // 20MHz Quarz │ │ [ ] VFS (Virtual File System) support // Benötige ich hier nicht. │ │ [*] control6 script // Hier wird unsere DS1820 Temperatur in eine Variable geschrieben für den implementieren Webserver. │ │ Network ---> // WICHTIG: IP, MAC Adresse, Gateway, Netmask, Hostname MUSS gleich sein wie bei dem Bootloader! │ │ Hostname: "esex060" │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" │ │ Netmask: "255.255.255.0" │ │ │ │ Default gateway: "192.168.123.10" │ │ I/O ---> │ │ [*] Onewire support ---> // Die allgemeine Onewire Unterstützung. │ │ [*] Onewire device detection support // Automatische Bauteilerkennung In der etherrape.m4 Datei wird nun noch der Pin des atmega geändert wo der DS1820 angeschlossen ist. Im NANO Editor wird mit "STRG-O dann Enter" gespeichert und mit STRG-X beendet. # nano pinning/hardware/etherrape.m4 // editieren der m4 Datei ----- ONEWIRE PIN ändern bei "ONEWIRE_PORT_RANGE(PD6, PD6)" zb. auf PD0 ----- Nun schreiben wir uns ein Script welches den Temperatursensor regelmäßig abfragt und in eine Globale Variable schiebt. # rm control6/control6.src // Original Datei löschen # nano control6/control6.src // Anlegen der c6 Datei. Die Datei ist nun neu und leer. C6_HEADER(`/* This will be in control6.h */') CONTROL_START ECMD_GLOBAL(temp01, 0, uint16_t); THREAD(start) temp01 = ONEWIRE_GET(1054698802080017); WAIT(5) THREAD_END(start) ON STARTUP DO THREAD_START(start) END CONTROL_END Kompilieren der eigentlichen Firmware. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 24072/65536 bytes (36.73%) [===========-------------------] Program (.text + .data) : 24072 bytes Data (.data + .bss) : 2250 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.bin</b> Die eigentliche Firmware ist nun kompiliert und fertig um via Netzwerk/tftpd aufgespielt zu werden. Ich verwende im folgenden Schritt Windows 7. Beschreibung folgt. ==Firmware flashen via TFTPD== Platzhalter, [[User_talk:Djmaster#1 | Todoliste]] 28-01-2016 [[Category:Tutorials]] f970f54a3da9a1140589ad393b77e53dc41e1a5e 1589 1584 2016-01-29T17:21:18Z Djmaster 255 /* Bootloader bauen */ wikitext text/x-wiki {{i18n|Temperaturmesssystem}} =PROJEKT Temperaturmessung= ===Einleitung=== * ZIEL: Eine einfache Temperaturmessung mit dem [[Onewire_(Deutsch)#Anschluss_AVR-NET-IO | DS1820 im parasitären Modus]]. * ZIEL: Die Ausgabe einer Temperaturvariable via integrierten Webbrowser oder telnet. * ZIEL: Die Firmware muss via Netzwerk neu flashbar sein. * Abgeändertes vereinfachtes [http://www.lochraster.org/etherrape/ etherrape] Board. * Zwei Spannungsregler, ein atmega644p, ein enc28j60, und etwas 0805 Hühnerfutter. ===Schaltung=== Das Layout passt in folgendes Gehäuse. Vorher am besten nochmal genau nachmessen. ;)<br> Conrad Bestell-Nr.: [https://www.conrad.at/de/hutschienen-gehaeuse-90-x-360-x-58-polycarbonat-axxatronic-cnmb-2-kit-con-1-st-531441.html 531441] / Axxatronic CNMB-2-KIT-CON <gallery> File:Sch_tempmess.png File:Pcb_tempmess.png </gallery> * Erstellt mit Eagle Version 7.1.0 für Windows * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_schematic_001.pdf PDF Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_layout_001.pdf PDF Layout gespiegelt] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.sch Eagle Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.brd Eagle Layout] ===Software=== Ethersex (Linux) - https://github.com/ethersex/ethersex Avrdude (Windows) - http://download.savannah.gnu.org/releases/avrdude/ (avrdude-6.1-mingw32.zip) tftpd (Windows) - http://tftpd32.jounin.net/tftpd32_download.html ===Firmware/Bootloader=== Die ethersex Firmware selbst wird für zwei Sachen verwendet. Den <b>Bootloader</b> UND die <b>Firmware</b>. Der Bootloader wird sozusagen einmal in den ersten Bereich des Mikrocontrollers geschrieben und bleibt dort auch. Er wird später die Firmware via Netzwerk entgegennehmen und in den Controller schreiben. Somit befindet sich in den ersten 10% unser Bootloader und in den restlichen 90% der Code den wir wollen. Das zu Verstehen war für mich an Anfang der schwierigste Teil, ist aber dann doch sehr einfach. Ich kann somit ohne ISP-Programmer eine Firmware in den Controller schreiben. Hier grob noch die nächsten Schritte: * Als erstes ist der Bootloader zu konfigurieren, dann via ISP zu programmieren. * Der ISP-Programmer wegräumen. ;) * Als zweites ist die Firmware zu konfigurieren, dann holt sich der Bootloader unsere Firmware via Netzerk/tftpd. =BOOTLOADER= <gallery> File:Putty_bootl_tempmess01.png File:Putty_bootl_tempmess02.png File:Putty_bootl_tempmess03.png File:Putty_bootl_tempmess04.png File:Putty_bootl_tempmess05.png File:Putty_bootl_tempmess06.png File:Putty_bootl_tempmess07.png File:Putty_bootl_tempmess08.png </gallery> ==Bootloader bauen== Ab nun befinde ich mich auf einem <b>virtuellen Debian Rechner</b> wo ich die Firmware herunterlade und daraus den Bootloader erstelle.<br> <b>WICHTIG:</b> Die IP und MAC-Adresse müssen natürlich verändert werden. Die selbe IP und MAC-Adresse müssen in der Firmware später auch benutzt werden. <br> * Bei einem neuen Debian System müssen mit "apt-get" ein paar Sachen nachinstalliert werden. Hier zu finden [[Preparation_(Deutsch)]] * So eine art DHCP wäre auch möglich, nennt sich [[BOOTP_(Deutsch) | BOOTP]]. Darauf gehe ich hier nicht ein. # cd /home/avr/ # mkdir ethersex_IP_60 // Mein "Arbeitsordner" # cd ethersex_IP_60/ // Ordner für das Board mit der IP 192.168.123.60 # git clone git://github.com/ethersex/ethersex.git // ethersex Firmware herunterladen Cloning into ethersex... remote: Counting objects: 37366, done. remote: Total 37366 (delta 0), reused 0 (delta 0), pack-reused 37366 Receiving objects: 100% (37366/37366), 11.27 MiB | 1.22 MiB/s, done. Resolving deltas: 100% (26538/26538), done. # cp -r ethersex bootloader // Ich kopiere den ethersex Ordner zu dem bootloader Ordner. 1:1 Kopie # cd bootloader/ // In den Bootloader Ordner wechseln # make menuconfig // Einstellungen für Bootloader im nächsten Schritt │ │ Load a Default Configuration ---> │ │ (*) Ethernet Bootloader │ │ General Setup ---> │ │ (ATmega644) Target MCU │ │ (20000000) MCU frequency │ │ [*] Build a bootloader │ │ [*] Teensy build │ │ Network ---> │ │ Hostname: "esex060" // Hostname ändern │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" // MAC ändern mit "Randomize MAC address" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" // Wenn IP nicht vorhanden BOOTP deaktivieren! │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ [ ] BOOTP (DHCP-like) support // BOOTP deaktivieren! │ │ Applications ---> │ │ [*] TFTP support ---> │ │ [*] TFTP-o-matic │ │ TFTP-server IPv4 address: "192.168.123.233" // Server wo TFTPD läuft │ │ TFTP image to load: "esex060.bin" // Diesen Dateinamen ladet später unser Board via Netzwerk/tftpd jetzt noch EXIT und SPEICHERN. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 5902/8192 bytes (72.4%) [=====================---------] Program (.text + .data) : 5902 bytes Data (.data + .bss) : 1902 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.hex</b> ==Bootloader flashen via ISP== Ich flashe hier einfacher weise mit meinem Windows 7 Notebook. Ich habe avrdude einfach unter C:\ liegen. Dort kopiere ich nun die ethersex.hex hin.<br> Somit kann man mit dem flashen den Bootloaders loslegen. avrdude -cusbasp -pm644p -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m // gilt nur für atmega644p und vermutlich auch 644 avrdude -cusbasp -pm644p -U flash:w:ethersex.hex avrdude -cusbasp -pm644p -U lock:w:0x0F:m Der Mikrocontrollerboard ist nun vorbereitet für die eigentliche Firmware. Der ISP-Programmer kann nun bei Seite gelegt werden und wird soweit alles richtig konfiguriert ist auch nicht mehr benötigt.<br> Nun erfolgt das Erstellen der Firmware. =FIRMWARE= <gallery> File:Putty_c6_m4_tempmess01.png File:Putty_c6_m4_tempmess02.png File:Putty_c6_m4_tempmess03.png </gallery> ==Firmware bauen== * <b>WICHTIG:</b> IP, MAC Adresse, Gateway, Netmask, Hostname <b>MUSS</b> gleich sein wie bei dem Bootloader! * Der integrierte Webserver ist in der original Firmware schon aktiviert. ( Applications --> [*] HTTP Server ) # cd /home/avr/ethersex_IP_60/ # cd ethersex/ # make menuconfig │ │ Load a Default Configuration ---> │ │ (*) Etherrape │ │ General Setup ---> │ │ (ATmega644) Target MCU // atmega644p bei mir │ │ (20000000) MCU frequency // 20MHz Quarz │ │ [ ] VFS (Virtual File System) support // Benötige ich hier nicht. │ │ [*] control6 script // Hier wird unsere DS1820 Temperatur in eine Variable geschrieben für den implementieren Webserver. │ │ Network ---> // WICHTIG: IP, MAC Adresse, Gateway, Netmask, Hostname MUSS gleich sein wie bei dem Bootloader! │ │ Hostname: "esex060" │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" │ │ Netmask: "255.255.255.0" │ │ │ │ Default gateway: "192.168.123.10" │ │ I/O ---> │ │ [*] Onewire support ---> // Die allgemeine Onewire Unterstützung. │ │ [*] Onewire device detection support // Automatische Bauteilerkennung In der etherrape.m4 Datei wird nun noch der Pin des atmega geändert wo der DS1820 angeschlossen ist. Im NANO Editor wird mit "STRG-O dann Enter" gespeichert und mit STRG-X beendet. # nano pinning/hardware/etherrape.m4 // editieren der m4 Datei ----- ONEWIRE PIN ändern bei "ONEWIRE_PORT_RANGE(PD6, PD6)" zb. auf PD0 ----- Nun schreiben wir uns ein Script welches den Temperatursensor regelmäßig abfragt und in eine Globale Variable schiebt. # rm control6/control6.src // Original Datei löschen # nano control6/control6.src // Anlegen der c6 Datei. Die Datei ist nun neu und leer. C6_HEADER(`/* This will be in control6.h */') CONTROL_START ECMD_GLOBAL(temp01, 0, uint16_t); THREAD(start) temp01 = ONEWIRE_GET(1054698802080017); WAIT(5) THREAD_END(start) ON STARTUP DO THREAD_START(start) END CONTROL_END Kompilieren der eigentlichen Firmware. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 24072/65536 bytes (36.73%) [===========-------------------] Program (.text + .data) : 24072 bytes Data (.data + .bss) : 2250 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.bin</b> Die eigentliche Firmware ist nun kompiliert und fertig um via Netzwerk/tftpd aufgespielt zu werden. Ich verwende im folgenden Schritt Windows 7. Beschreibung folgt. ==Firmware flashen via TFTPD== Platzhalter, [[User_talk:Djmaster#1 | Todoliste]] 28-01-2016 [[Category:Tutorials]] 4a871caa2a868dd52105d19bc3b95cfc55e0bdc2 1590 1589 2016-01-29T17:21:53Z Djmaster 255 /* BOOTLOADER */ wikitext text/x-wiki {{i18n|Temperaturmesssystem}} =PROJEKT Temperaturmessung= ===Einleitung=== * ZIEL: Eine einfache Temperaturmessung mit dem [[Onewire_(Deutsch)#Anschluss_AVR-NET-IO | DS1820 im parasitären Modus]]. * ZIEL: Die Ausgabe einer Temperaturvariable via integrierten Webbrowser oder telnet. * ZIEL: Die Firmware muss via Netzwerk neu flashbar sein. * Abgeändertes vereinfachtes [http://www.lochraster.org/etherrape/ etherrape] Board. * Zwei Spannungsregler, ein atmega644p, ein enc28j60, und etwas 0805 Hühnerfutter. ===Schaltung=== Das Layout passt in folgendes Gehäuse. Vorher am besten nochmal genau nachmessen. ;)<br> Conrad Bestell-Nr.: [https://www.conrad.at/de/hutschienen-gehaeuse-90-x-360-x-58-polycarbonat-axxatronic-cnmb-2-kit-con-1-st-531441.html 531441] / Axxatronic CNMB-2-KIT-CON <gallery> File:Sch_tempmess.png File:Pcb_tempmess.png </gallery> * Erstellt mit Eagle Version 7.1.0 für Windows * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_schematic_001.pdf PDF Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_layout_001.pdf PDF Layout gespiegelt] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.sch Eagle Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.brd Eagle Layout] ===Software=== Ethersex (Linux) - https://github.com/ethersex/ethersex Avrdude (Windows) - http://download.savannah.gnu.org/releases/avrdude/ (avrdude-6.1-mingw32.zip) tftpd (Windows) - http://tftpd32.jounin.net/tftpd32_download.html ===Firmware/Bootloader=== Die ethersex Firmware selbst wird für zwei Sachen verwendet. Den <b>Bootloader</b> UND die <b>Firmware</b>. Der Bootloader wird sozusagen einmal in den ersten Bereich des Mikrocontrollers geschrieben und bleibt dort auch. Er wird später die Firmware via Netzwerk entgegennehmen und in den Controller schreiben. Somit befindet sich in den ersten 10% unser Bootloader und in den restlichen 90% der Code den wir wollen. Das zu Verstehen war für mich an Anfang der schwierigste Teil, ist aber dann doch sehr einfach. Ich kann somit ohne ISP-Programmer eine Firmware in den Controller schreiben. Hier grob noch die nächsten Schritte: * Als erstes ist der Bootloader zu konfigurieren, dann via ISP zu programmieren. * Der ISP-Programmer wegräumen. ;) * Als zweites ist die Firmware zu konfigurieren, dann holt sich der Bootloader unsere Firmware via Netzerk/tftpd. =BOOTLOADER= ==Bootloader bauen== <gallery> File:Putty_bootl_tempmess01.png File:Putty_bootl_tempmess02.png File:Putty_bootl_tempmess03.png File:Putty_bootl_tempmess04.png File:Putty_bootl_tempmess05.png File:Putty_bootl_tempmess06.png File:Putty_bootl_tempmess07.png File:Putty_bootl_tempmess08.png </gallery> Ab nun befinde ich mich auf einem <b>virtuellen Debian Rechner</b> wo ich die Firmware herunterlade und daraus den Bootloader erstelle.<br> <b>WICHTIG:</b> Die IP und MAC-Adresse müssen natürlich verändert werden. Die selbe IP und MAC-Adresse müssen in der Firmware später auch benutzt werden. <br> * Bei einem neuen Debian System müssen mit "apt-get" ein paar Sachen nachinstalliert werden. Hier zu finden [[Preparation_(Deutsch)]] * So eine art DHCP wäre auch möglich, nennt sich [[BOOTP_(Deutsch) | BOOTP]]. Darauf gehe ich hier nicht ein. # cd /home/avr/ # mkdir ethersex_IP_60 // Mein "Arbeitsordner" # cd ethersex_IP_60/ // Ordner für das Board mit der IP 192.168.123.60 # git clone git://github.com/ethersex/ethersex.git // ethersex Firmware herunterladen Cloning into ethersex... remote: Counting objects: 37366, done. remote: Total 37366 (delta 0), reused 0 (delta 0), pack-reused 37366 Receiving objects: 100% (37366/37366), 11.27 MiB | 1.22 MiB/s, done. Resolving deltas: 100% (26538/26538), done. # cp -r ethersex bootloader // Ich kopiere den ethersex Ordner zu dem bootloader Ordner. 1:1 Kopie # cd bootloader/ // In den Bootloader Ordner wechseln # make menuconfig // Einstellungen für Bootloader im nächsten Schritt │ │ Load a Default Configuration ---> │ │ (*) Ethernet Bootloader │ │ General Setup ---> │ │ (ATmega644) Target MCU │ │ (20000000) MCU frequency │ │ [*] Build a bootloader │ │ [*] Teensy build │ │ Network ---> │ │ Hostname: "esex060" // Hostname ändern │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" // MAC ändern mit "Randomize MAC address" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" // Wenn IP nicht vorhanden BOOTP deaktivieren! │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ [ ] BOOTP (DHCP-like) support // BOOTP deaktivieren! │ │ Applications ---> │ │ [*] TFTP support ---> │ │ [*] TFTP-o-matic │ │ TFTP-server IPv4 address: "192.168.123.233" // Server wo TFTPD läuft │ │ TFTP image to load: "esex060.bin" // Diesen Dateinamen ladet später unser Board via Netzwerk/tftpd jetzt noch EXIT und SPEICHERN. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 5902/8192 bytes (72.4%) [=====================---------] Program (.text + .data) : 5902 bytes Data (.data + .bss) : 1902 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.hex</b> ==Bootloader flashen via ISP== Ich flashe hier einfacher weise mit meinem Windows 7 Notebook. Ich habe avrdude einfach unter C:\ liegen. Dort kopiere ich nun die ethersex.hex hin.<br> Somit kann man mit dem flashen den Bootloaders loslegen. avrdude -cusbasp -pm644p -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m // gilt nur für atmega644p und vermutlich auch 644 avrdude -cusbasp -pm644p -U flash:w:ethersex.hex avrdude -cusbasp -pm644p -U lock:w:0x0F:m Der Mikrocontrollerboard ist nun vorbereitet für die eigentliche Firmware. Der ISP-Programmer kann nun bei Seite gelegt werden und wird soweit alles richtig konfiguriert ist auch nicht mehr benötigt.<br> Nun erfolgt das Erstellen der Firmware. =FIRMWARE= <gallery> File:Putty_c6_m4_tempmess01.png File:Putty_c6_m4_tempmess02.png File:Putty_c6_m4_tempmess03.png </gallery> ==Firmware bauen== * <b>WICHTIG:</b> IP, MAC Adresse, Gateway, Netmask, Hostname <b>MUSS</b> gleich sein wie bei dem Bootloader! * Der integrierte Webserver ist in der original Firmware schon aktiviert. ( Applications --> [*] HTTP Server ) # cd /home/avr/ethersex_IP_60/ # cd ethersex/ # make menuconfig │ │ Load a Default Configuration ---> │ │ (*) Etherrape │ │ General Setup ---> │ │ (ATmega644) Target MCU // atmega644p bei mir │ │ (20000000) MCU frequency // 20MHz Quarz │ │ [ ] VFS (Virtual File System) support // Benötige ich hier nicht. │ │ [*] control6 script // Hier wird unsere DS1820 Temperatur in eine Variable geschrieben für den implementieren Webserver. │ │ Network ---> // WICHTIG: IP, MAC Adresse, Gateway, Netmask, Hostname MUSS gleich sein wie bei dem Bootloader! │ │ Hostname: "esex060" │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" │ │ Netmask: "255.255.255.0" │ │ │ │ Default gateway: "192.168.123.10" │ │ I/O ---> │ │ [*] Onewire support ---> // Die allgemeine Onewire Unterstützung. │ │ [*] Onewire device detection support // Automatische Bauteilerkennung In der etherrape.m4 Datei wird nun noch der Pin des atmega geändert wo der DS1820 angeschlossen ist. Im NANO Editor wird mit "STRG-O dann Enter" gespeichert und mit STRG-X beendet. # nano pinning/hardware/etherrape.m4 // editieren der m4 Datei ----- ONEWIRE PIN ändern bei "ONEWIRE_PORT_RANGE(PD6, PD6)" zb. auf PD0 ----- Nun schreiben wir uns ein Script welches den Temperatursensor regelmäßig abfragt und in eine Globale Variable schiebt. # rm control6/control6.src // Original Datei löschen # nano control6/control6.src // Anlegen der c6 Datei. Die Datei ist nun neu und leer. C6_HEADER(`/* This will be in control6.h */') CONTROL_START ECMD_GLOBAL(temp01, 0, uint16_t); THREAD(start) temp01 = ONEWIRE_GET(1054698802080017); WAIT(5) THREAD_END(start) ON STARTUP DO THREAD_START(start) END CONTROL_END Kompilieren der eigentlichen Firmware. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 24072/65536 bytes (36.73%) [===========-------------------] Program (.text + .data) : 24072 bytes Data (.data + .bss) : 2250 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.bin</b> Die eigentliche Firmware ist nun kompiliert und fertig um via Netzwerk/tftpd aufgespielt zu werden. Ich verwende im folgenden Schritt Windows 7. Beschreibung folgt. ==Firmware flashen via TFTPD== Platzhalter, [[User_talk:Djmaster#1 | Todoliste]] 28-01-2016 [[Category:Tutorials]] 6db7981340b8a5ba0a50948e4c78ac28ebb5fedd 1591 1590 2016-01-29T17:22:50Z Djmaster 255 /* FIRMWARE */ wikitext text/x-wiki {{i18n|Temperaturmesssystem}} =PROJEKT Temperaturmessung= ===Einleitung=== * ZIEL: Eine einfache Temperaturmessung mit dem [[Onewire_(Deutsch)#Anschluss_AVR-NET-IO | DS1820 im parasitären Modus]]. * ZIEL: Die Ausgabe einer Temperaturvariable via integrierten Webbrowser oder telnet. * ZIEL: Die Firmware muss via Netzwerk neu flashbar sein. * Abgeändertes vereinfachtes [http://www.lochraster.org/etherrape/ etherrape] Board. * Zwei Spannungsregler, ein atmega644p, ein enc28j60, und etwas 0805 Hühnerfutter. ===Schaltung=== Das Layout passt in folgendes Gehäuse. Vorher am besten nochmal genau nachmessen. ;)<br> Conrad Bestell-Nr.: [https://www.conrad.at/de/hutschienen-gehaeuse-90-x-360-x-58-polycarbonat-axxatronic-cnmb-2-kit-con-1-st-531441.html 531441] / Axxatronic CNMB-2-KIT-CON <gallery> File:Sch_tempmess.png File:Pcb_tempmess.png </gallery> * Erstellt mit Eagle Version 7.1.0 für Windows * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_schematic_001.pdf PDF Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_layout_001.pdf PDF Layout gespiegelt] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.sch Eagle Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.brd Eagle Layout] ===Software=== Ethersex (Linux) - https://github.com/ethersex/ethersex Avrdude (Windows) - http://download.savannah.gnu.org/releases/avrdude/ (avrdude-6.1-mingw32.zip) tftpd (Windows) - http://tftpd32.jounin.net/tftpd32_download.html ===Firmware/Bootloader=== Die ethersex Firmware selbst wird für zwei Sachen verwendet. Den <b>Bootloader</b> UND die <b>Firmware</b>. Der Bootloader wird sozusagen einmal in den ersten Bereich des Mikrocontrollers geschrieben und bleibt dort auch. Er wird später die Firmware via Netzwerk entgegennehmen und in den Controller schreiben. Somit befindet sich in den ersten 10% unser Bootloader und in den restlichen 90% der Code den wir wollen. Das zu Verstehen war für mich an Anfang der schwierigste Teil, ist aber dann doch sehr einfach. Ich kann somit ohne ISP-Programmer eine Firmware in den Controller schreiben. Hier grob noch die nächsten Schritte: * Als erstes ist der Bootloader zu konfigurieren, dann via ISP zu programmieren. * Der ISP-Programmer wegräumen. ;) * Als zweites ist die Firmware zu konfigurieren, dann holt sich der Bootloader unsere Firmware via Netzerk/tftpd. =BOOTLOADER= ==Bootloader bauen== <gallery> File:Putty_bootl_tempmess01.png File:Putty_bootl_tempmess02.png File:Putty_bootl_tempmess03.png File:Putty_bootl_tempmess04.png File:Putty_bootl_tempmess05.png File:Putty_bootl_tempmess06.png File:Putty_bootl_tempmess07.png File:Putty_bootl_tempmess08.png </gallery> Ab nun befinde ich mich auf einem <b>virtuellen Debian Rechner</b> wo ich die Firmware herunterlade und daraus den Bootloader erstelle.<br> <b>WICHTIG:</b> Die IP und MAC-Adresse müssen natürlich verändert werden. Die selbe IP und MAC-Adresse müssen in der Firmware später auch benutzt werden. <br> * Bei einem neuen Debian System müssen mit "apt-get" ein paar Sachen nachinstalliert werden. Hier zu finden [[Preparation_(Deutsch)]] * So eine art DHCP wäre auch möglich, nennt sich [[BOOTP_(Deutsch) | BOOTP]]. Darauf gehe ich hier nicht ein. # cd /home/avr/ # mkdir ethersex_IP_60 // Mein "Arbeitsordner" # cd ethersex_IP_60/ // Ordner für das Board mit der IP 192.168.123.60 # git clone git://github.com/ethersex/ethersex.git // ethersex Firmware herunterladen Cloning into ethersex... remote: Counting objects: 37366, done. remote: Total 37366 (delta 0), reused 0 (delta 0), pack-reused 37366 Receiving objects: 100% (37366/37366), 11.27 MiB | 1.22 MiB/s, done. Resolving deltas: 100% (26538/26538), done. # cp -r ethersex bootloader // Ich kopiere den ethersex Ordner zu dem bootloader Ordner. 1:1 Kopie # cd bootloader/ // In den Bootloader Ordner wechseln # make menuconfig // Einstellungen für Bootloader im nächsten Schritt │ │ Load a Default Configuration ---> │ │ (*) Ethernet Bootloader │ │ General Setup ---> │ │ (ATmega644) Target MCU │ │ (20000000) MCU frequency │ │ [*] Build a bootloader │ │ [*] Teensy build │ │ Network ---> │ │ Hostname: "esex060" // Hostname ändern │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" // MAC ändern mit "Randomize MAC address" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" // Wenn IP nicht vorhanden BOOTP deaktivieren! │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ [ ] BOOTP (DHCP-like) support // BOOTP deaktivieren! │ │ Applications ---> │ │ [*] TFTP support ---> │ │ [*] TFTP-o-matic │ │ TFTP-server IPv4 address: "192.168.123.233" // Server wo TFTPD läuft │ │ TFTP image to load: "esex060.bin" // Diesen Dateinamen ladet später unser Board via Netzwerk/tftpd jetzt noch EXIT und SPEICHERN. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 5902/8192 bytes (72.4%) [=====================---------] Program (.text + .data) : 5902 bytes Data (.data + .bss) : 1902 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.hex</b> ==Bootloader flashen via ISP== Ich flashe hier einfacher weise mit meinem Windows 7 Notebook. Ich habe avrdude einfach unter C:\ liegen. Dort kopiere ich nun die ethersex.hex hin.<br> Somit kann man mit dem flashen den Bootloaders loslegen. avrdude -cusbasp -pm644p -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m // gilt nur für atmega644p und vermutlich auch 644 avrdude -cusbasp -pm644p -U flash:w:ethersex.hex avrdude -cusbasp -pm644p -U lock:w:0x0F:m Der Mikrocontrollerboard ist nun vorbereitet für die eigentliche Firmware. Der ISP-Programmer kann nun bei Seite gelegt werden und wird soweit alles richtig konfiguriert ist auch nicht mehr benötigt.<br> Nun erfolgt das Erstellen der Firmware. =FIRMWARE= ==Firmware bauen== <gallery> File:Putty_c6_m4_tempmess01.png File:Putty_c6_m4_tempmess02.png File:Putty_c6_m4_tempmess03.png </gallery> * <b>WICHTIG:</b> IP, MAC Adresse, Gateway, Netmask, Hostname <b>MUSS</b> gleich sein wie bei dem Bootloader! * Der integrierte Webserver ist in der original Firmware schon aktiviert. ( Applications --> [*] HTTP Server ) # cd /home/avr/ethersex_IP_60/ # cd ethersex/ # make menuconfig │ │ Load a Default Configuration ---> │ │ (*) Etherrape │ │ General Setup ---> │ │ (ATmega644) Target MCU // atmega644p bei mir │ │ (20000000) MCU frequency // 20MHz Quarz │ │ [ ] VFS (Virtual File System) support // Benötige ich hier nicht. │ │ [*] control6 script // Hier wird unsere DS1820 Temperatur in eine Variable geschrieben für den implementieren Webserver. │ │ Network ---> // WICHTIG: IP, MAC Adresse, Gateway, Netmask, Hostname MUSS gleich sein wie bei dem Bootloader! │ │ Hostname: "esex060" │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" │ │ Netmask: "255.255.255.0" │ │ │ │ Default gateway: "192.168.123.10" │ │ I/O ---> │ │ [*] Onewire support ---> // Die allgemeine Onewire Unterstützung. │ │ [*] Onewire device detection support // Automatische Bauteilerkennung In der etherrape.m4 Datei wird nun noch der Pin des atmega geändert wo der DS1820 angeschlossen ist. Im NANO Editor wird mit "STRG-O dann Enter" gespeichert und mit STRG-X beendet. # nano pinning/hardware/etherrape.m4 // editieren der m4 Datei ----- ONEWIRE PIN ändern bei "ONEWIRE_PORT_RANGE(PD6, PD6)" zb. auf PD0 ----- Nun schreiben wir uns ein Script welches den Temperatursensor regelmäßig abfragt und in eine Globale Variable schiebt. # rm control6/control6.src // Original Datei löschen # nano control6/control6.src // Anlegen der c6 Datei. Die Datei ist nun neu und leer. C6_HEADER(`/* This will be in control6.h */') CONTROL_START ECMD_GLOBAL(temp01, 0, uint16_t); THREAD(start) temp01 = ONEWIRE_GET(1054698802080017); WAIT(5) THREAD_END(start) ON STARTUP DO THREAD_START(start) END CONTROL_END Kompilieren der eigentlichen Firmware. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 24072/65536 bytes (36.73%) [===========-------------------] Program (.text + .data) : 24072 bytes Data (.data + .bss) : 2250 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.bin</b> Die eigentliche Firmware ist nun kompiliert und fertig um via Netzwerk/tftpd aufgespielt zu werden. Ich verwende im folgenden Schritt Windows 7. Beschreibung folgt. ==Firmware flashen via TFTPD== Platzhalter, [[User_talk:Djmaster#1 | Todoliste]] 28-01-2016 [[Category:Tutorials]] d1b8b8623784acfb3e742a34da13f8f3eea48c7d 1596 1591 2016-01-29T17:25:22Z Djmaster 255 /* BOOTLOADER */ wikitext text/x-wiki {{i18n|Temperaturmesssystem}} =PROJEKT Temperaturmessung= ===Einleitung=== * ZIEL: Eine einfache Temperaturmessung mit dem [[Onewire_(Deutsch)#Anschluss_AVR-NET-IO | DS1820 im parasitären Modus]]. * ZIEL: Die Ausgabe einer Temperaturvariable via integrierten Webbrowser oder telnet. * ZIEL: Die Firmware muss via Netzwerk neu flashbar sein. * Abgeändertes vereinfachtes [http://www.lochraster.org/etherrape/ etherrape] Board. * Zwei Spannungsregler, ein atmega644p, ein enc28j60, und etwas 0805 Hühnerfutter. ===Schaltung=== Das Layout passt in folgendes Gehäuse. Vorher am besten nochmal genau nachmessen. ;)<br> Conrad Bestell-Nr.: [https://www.conrad.at/de/hutschienen-gehaeuse-90-x-360-x-58-polycarbonat-axxatronic-cnmb-2-kit-con-1-st-531441.html 531441] / Axxatronic CNMB-2-KIT-CON <gallery> File:Sch_tempmess.png File:Pcb_tempmess.png </gallery> * Erstellt mit Eagle Version 7.1.0 für Windows * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_schematic_001.pdf PDF Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_layout_001.pdf PDF Layout gespiegelt] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.sch Eagle Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.brd Eagle Layout] ===Software=== Ethersex (Linux) - https://github.com/ethersex/ethersex Avrdude (Windows) - http://download.savannah.gnu.org/releases/avrdude/ (avrdude-6.1-mingw32.zip) tftpd (Windows) - http://tftpd32.jounin.net/tftpd32_download.html ===Firmware/Bootloader=== Die ethersex Firmware selbst wird für zwei Sachen verwendet. Den <b>Bootloader</b> UND die <b>Firmware</b>. Der Bootloader wird sozusagen einmal in den ersten Bereich des Mikrocontrollers geschrieben und bleibt dort auch. Er wird später die Firmware via Netzwerk entgegennehmen und in den Controller schreiben. Somit befindet sich in den ersten 10% unser Bootloader und in den restlichen 90% der Code den wir wollen. Das zu Verstehen war für mich an Anfang der schwierigste Teil, ist aber dann doch sehr einfach. Ich kann somit ohne ISP-Programmer eine Firmware in den Controller schreiben. Hier grob noch die nächsten Schritte: * Als erstes ist der Bootloader zu konfigurieren, dann via ISP zu programmieren. * Der ISP-Programmer wegräumen. ;) * Als zweites ist die Firmware zu konfigurieren, dann holt sich der Bootloader unsere Firmware via Netzerk/tftpd. =BOOTLOADER= ==Bootloader bauen== <gallery> File:Putty_bootl_tempmess01.png File:Putty_bootl_tempmess02.png File:Putty_bootl_tempmess03.png File:Putty_bootl_tempmess04.png File:Putty_bootl_tempmess05.png File:Putty_bootl_tempmess06.png File:Putty_bootl_tempmess07.png File:Putty_bootl_tempmess08.png </gallery> Ab nun befinde ich mich auf einem <b>virtuellen Debian Rechner</b> wo ich die Firmware herunterlade und daraus den Bootloader erstelle.<br> <b>WICHTIG:</b> Die IP und MAC-Adresse müssen natürlich verändert werden. Die selbe IP und MAC-Adresse müssen in der Firmware später auch benutzt werden. <br> * Bei einem neuen Debian System müssen mit "apt-get" ein paar Sachen nachinstalliert werden. Hier zu finden [[Preparation_(Deutsch)]] * So eine art DHCP wäre auch möglich, nennt sich [[BOOTP_(Deutsch) | BOOTP]]. Darauf gehe ich hier nicht ein. # cd /home/avr/ # mkdir ethersex_IP_60 // Mein "Arbeitsordner" # cd ethersex_IP_60/ // Ordner für das Board mit der IP 192.168.123.60 # git clone git://github.com/ethersex/ethersex.git // ethersex Firmware herunterladen Cloning into ethersex... remote: Counting objects: 37366, done. remote: Total 37366 (delta 0), reused 0 (delta 0), pack-reused 37366 Receiving objects: 100% (37366/37366), 11.27 MiB | 1.22 MiB/s, done. Resolving deltas: 100% (26538/26538), done. # cp -r ethersex bootloader // Ich kopiere den ethersex Ordner zu dem bootloader Ordner. 1:1 Kopie # cd bootloader/ // In den Bootloader Ordner wechseln # make menuconfig // Einstellungen für Bootloader im nächsten Schritt │ │ Load a Default Configuration ---> │ │ (*) Ethernet Bootloader │ │ General Setup ---> │ │ (ATmega644) Target MCU │ │ (20000000) MCU frequency │ │ [*] Build a bootloader │ │ [*] Teensy build │ │ Network ---> │ │ Hostname: "esex060" // Hostname ändern │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" // MAC ändern mit "Randomize MAC address" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" // Wenn IP nicht vorhanden BOOTP deaktivieren! │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ [ ] BOOTP (DHCP-like) support // BOOTP deaktivieren! │ │ Applications ---> │ │ [*] TFTP support ---> │ │ [*] TFTP-o-matic │ │ TFTP-server IPv4 address: "192.168.123.233" // Server wo TFTPD läuft │ │ TFTP image to load: "esex060.bin" // Diesen Dateinamen ladet später unser Board via Netzwerk/tftpd jetzt noch EXIT und SPEICHERN. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 5902/8192 bytes (72.4%) [=====================---------] Program (.text + .data) : 5902 bytes Data (.data + .bss) : 1902 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.hex</b> ==Bootloader flashen via ISP== <gallery> File:Avrdude tempmess01.png File:Avrdude tempmess02.png File:Avrdude tempmess03.png File:Avrdude tempmess04.png </gallery> Ich flashe hier einfacher weise mit meinem Windows 7 Notebook. Ich habe avrdude einfach unter C:\ liegen. Dort kopiere ich nun die ethersex.hex hin.<br> Somit kann man mit dem flashen den Bootloaders loslegen. avrdude -cusbasp -pm644p -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m // gilt nur für atmega644p und vermutlich auch 644 avrdude -cusbasp -pm644p -U flash:w:ethersex.hex avrdude -cusbasp -pm644p -U lock:w:0x0F:m Der Mikrocontrollerboard ist nun vorbereitet für die eigentliche Firmware. Der ISP-Programmer kann nun bei Seite gelegt werden und wird soweit alles richtig konfiguriert ist auch nicht mehr benötigt.<br> Nun erfolgt das Erstellen der Firmware. =FIRMWARE= ==Firmware bauen== <gallery> File:Putty_c6_m4_tempmess01.png File:Putty_c6_m4_tempmess02.png File:Putty_c6_m4_tempmess03.png </gallery> * <b>WICHTIG:</b> IP, MAC Adresse, Gateway, Netmask, Hostname <b>MUSS</b> gleich sein wie bei dem Bootloader! * Der integrierte Webserver ist in der original Firmware schon aktiviert. ( Applications --> [*] HTTP Server ) # cd /home/avr/ethersex_IP_60/ # cd ethersex/ # make menuconfig │ │ Load a Default Configuration ---> │ │ (*) Etherrape │ │ General Setup ---> │ │ (ATmega644) Target MCU // atmega644p bei mir │ │ (20000000) MCU frequency // 20MHz Quarz │ │ [ ] VFS (Virtual File System) support // Benötige ich hier nicht. │ │ [*] control6 script // Hier wird unsere DS1820 Temperatur in eine Variable geschrieben für den implementieren Webserver. │ │ Network ---> // WICHTIG: IP, MAC Adresse, Gateway, Netmask, Hostname MUSS gleich sein wie bei dem Bootloader! │ │ Hostname: "esex060" │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" │ │ Netmask: "255.255.255.0" │ │ │ │ Default gateway: "192.168.123.10" │ │ I/O ---> │ │ [*] Onewire support ---> // Die allgemeine Onewire Unterstützung. │ │ [*] Onewire device detection support // Automatische Bauteilerkennung In der etherrape.m4 Datei wird nun noch der Pin des atmega geändert wo der DS1820 angeschlossen ist. Im NANO Editor wird mit "STRG-O dann Enter" gespeichert und mit STRG-X beendet. # nano pinning/hardware/etherrape.m4 // editieren der m4 Datei ----- ONEWIRE PIN ändern bei "ONEWIRE_PORT_RANGE(PD6, PD6)" zb. auf PD0 ----- Nun schreiben wir uns ein Script welches den Temperatursensor regelmäßig abfragt und in eine Globale Variable schiebt. # rm control6/control6.src // Original Datei löschen # nano control6/control6.src // Anlegen der c6 Datei. Die Datei ist nun neu und leer. C6_HEADER(`/* This will be in control6.h */') CONTROL_START ECMD_GLOBAL(temp01, 0, uint16_t); THREAD(start) temp01 = ONEWIRE_GET(1054698802080017); WAIT(5) THREAD_END(start) ON STARTUP DO THREAD_START(start) END CONTROL_END Kompilieren der eigentlichen Firmware. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 24072/65536 bytes (36.73%) [===========-------------------] Program (.text + .data) : 24072 bytes Data (.data + .bss) : 2250 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.bin</b> Die eigentliche Firmware ist nun kompiliert und fertig um via Netzwerk/tftpd aufgespielt zu werden. Ich verwende im folgenden Schritt Windows 7. Beschreibung folgt. ==Firmware flashen via TFTPD== Platzhalter, [[User_talk:Djmaster#1 | Todoliste]] 28-01-2016 [[Category:Tutorials]] 9e11794a24649c9e3b4d8f014d03176de6b6b5a6 1601 1596 2016-01-29T17:27:50Z Djmaster 255 /* Firmware flashen via TFTPD */ wikitext text/x-wiki {{i18n|Temperaturmesssystem}} =PROJEKT Temperaturmessung= ===Einleitung=== * ZIEL: Eine einfache Temperaturmessung mit dem [[Onewire_(Deutsch)#Anschluss_AVR-NET-IO | DS1820 im parasitären Modus]]. * ZIEL: Die Ausgabe einer Temperaturvariable via integrierten Webbrowser oder telnet. * ZIEL: Die Firmware muss via Netzwerk neu flashbar sein. * Abgeändertes vereinfachtes [http://www.lochraster.org/etherrape/ etherrape] Board. * Zwei Spannungsregler, ein atmega644p, ein enc28j60, und etwas 0805 Hühnerfutter. ===Schaltung=== Das Layout passt in folgendes Gehäuse. Vorher am besten nochmal genau nachmessen. ;)<br> Conrad Bestell-Nr.: [https://www.conrad.at/de/hutschienen-gehaeuse-90-x-360-x-58-polycarbonat-axxatronic-cnmb-2-kit-con-1-st-531441.html 531441] / Axxatronic CNMB-2-KIT-CON <gallery> File:Sch_tempmess.png File:Pcb_tempmess.png </gallery> * Erstellt mit Eagle Version 7.1.0 für Windows * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_schematic_001.pdf PDF Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_layout_001.pdf PDF Layout gespiegelt] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.sch Eagle Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.brd Eagle Layout] ===Software=== Ethersex (Linux) - https://github.com/ethersex/ethersex Avrdude (Windows) - http://download.savannah.gnu.org/releases/avrdude/ (avrdude-6.1-mingw32.zip) tftpd (Windows) - http://tftpd32.jounin.net/tftpd32_download.html ===Firmware/Bootloader=== Die ethersex Firmware selbst wird für zwei Sachen verwendet. Den <b>Bootloader</b> UND die <b>Firmware</b>. Der Bootloader wird sozusagen einmal in den ersten Bereich des Mikrocontrollers geschrieben und bleibt dort auch. Er wird später die Firmware via Netzwerk entgegennehmen und in den Controller schreiben. Somit befindet sich in den ersten 10% unser Bootloader und in den restlichen 90% der Code den wir wollen. Das zu Verstehen war für mich an Anfang der schwierigste Teil, ist aber dann doch sehr einfach. Ich kann somit ohne ISP-Programmer eine Firmware in den Controller schreiben. Hier grob noch die nächsten Schritte: * Als erstes ist der Bootloader zu konfigurieren, dann via ISP zu programmieren. * Der ISP-Programmer wegräumen. ;) * Als zweites ist die Firmware zu konfigurieren, dann holt sich der Bootloader unsere Firmware via Netzerk/tftpd. =BOOTLOADER= ==Bootloader bauen== <gallery> File:Putty_bootl_tempmess01.png File:Putty_bootl_tempmess02.png File:Putty_bootl_tempmess03.png File:Putty_bootl_tempmess04.png File:Putty_bootl_tempmess05.png File:Putty_bootl_tempmess06.png File:Putty_bootl_tempmess07.png File:Putty_bootl_tempmess08.png </gallery> Ab nun befinde ich mich auf einem <b>virtuellen Debian Rechner</b> wo ich die Firmware herunterlade und daraus den Bootloader erstelle.<br> <b>WICHTIG:</b> Die IP und MAC-Adresse müssen natürlich verändert werden. Die selbe IP und MAC-Adresse müssen in der Firmware später auch benutzt werden. <br> * Bei einem neuen Debian System müssen mit "apt-get" ein paar Sachen nachinstalliert werden. Hier zu finden [[Preparation_(Deutsch)]] * So eine art DHCP wäre auch möglich, nennt sich [[BOOTP_(Deutsch) | BOOTP]]. Darauf gehe ich hier nicht ein. # cd /home/avr/ # mkdir ethersex_IP_60 // Mein "Arbeitsordner" # cd ethersex_IP_60/ // Ordner für das Board mit der IP 192.168.123.60 # git clone git://github.com/ethersex/ethersex.git // ethersex Firmware herunterladen Cloning into ethersex... remote: Counting objects: 37366, done. remote: Total 37366 (delta 0), reused 0 (delta 0), pack-reused 37366 Receiving objects: 100% (37366/37366), 11.27 MiB | 1.22 MiB/s, done. Resolving deltas: 100% (26538/26538), done. # cp -r ethersex bootloader // Ich kopiere den ethersex Ordner zu dem bootloader Ordner. 1:1 Kopie # cd bootloader/ // In den Bootloader Ordner wechseln # make menuconfig // Einstellungen für Bootloader im nächsten Schritt │ │ Load a Default Configuration ---> │ │ (*) Ethernet Bootloader │ │ General Setup ---> │ │ (ATmega644) Target MCU │ │ (20000000) MCU frequency │ │ [*] Build a bootloader │ │ [*] Teensy build │ │ Network ---> │ │ Hostname: "esex060" // Hostname ändern │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" // MAC ändern mit "Randomize MAC address" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" // Wenn IP nicht vorhanden BOOTP deaktivieren! │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ [ ] BOOTP (DHCP-like) support // BOOTP deaktivieren! │ │ Applications ---> │ │ [*] TFTP support ---> │ │ [*] TFTP-o-matic │ │ TFTP-server IPv4 address: "192.168.123.233" // Server wo TFTPD läuft │ │ TFTP image to load: "esex060.bin" // Diesen Dateinamen ladet später unser Board via Netzwerk/tftpd jetzt noch EXIT und SPEICHERN. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 5902/8192 bytes (72.4%) [=====================---------] Program (.text + .data) : 5902 bytes Data (.data + .bss) : 1902 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.hex</b> ==Bootloader flashen via ISP== <gallery> File:Avrdude tempmess01.png File:Avrdude tempmess02.png File:Avrdude tempmess03.png File:Avrdude tempmess04.png </gallery> Ich flashe hier einfacher weise mit meinem Windows 7 Notebook. Ich habe avrdude einfach unter C:\ liegen. Dort kopiere ich nun die ethersex.hex hin.<br> Somit kann man mit dem flashen den Bootloaders loslegen. avrdude -cusbasp -pm644p -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m // gilt nur für atmega644p und vermutlich auch 644 avrdude -cusbasp -pm644p -U flash:w:ethersex.hex avrdude -cusbasp -pm644p -U lock:w:0x0F:m Der Mikrocontrollerboard ist nun vorbereitet für die eigentliche Firmware. Der ISP-Programmer kann nun bei Seite gelegt werden und wird soweit alles richtig konfiguriert ist auch nicht mehr benötigt.<br> Nun erfolgt das Erstellen der Firmware. =FIRMWARE= ==Firmware bauen== <gallery> File:Putty_c6_m4_tempmess01.png File:Putty_c6_m4_tempmess02.png File:Putty_c6_m4_tempmess03.png </gallery> * <b>WICHTIG:</b> IP, MAC Adresse, Gateway, Netmask, Hostname <b>MUSS</b> gleich sein wie bei dem Bootloader! * Der integrierte Webserver ist in der original Firmware schon aktiviert. ( Applications --> [*] HTTP Server ) # cd /home/avr/ethersex_IP_60/ # cd ethersex/ # make menuconfig │ │ Load a Default Configuration ---> │ │ (*) Etherrape │ │ General Setup ---> │ │ (ATmega644) Target MCU // atmega644p bei mir │ │ (20000000) MCU frequency // 20MHz Quarz │ │ [ ] VFS (Virtual File System) support // Benötige ich hier nicht. │ │ [*] control6 script // Hier wird unsere DS1820 Temperatur in eine Variable geschrieben für den implementieren Webserver. │ │ Network ---> // WICHTIG: IP, MAC Adresse, Gateway, Netmask, Hostname MUSS gleich sein wie bei dem Bootloader! │ │ Hostname: "esex060" │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" │ │ Netmask: "255.255.255.0" │ │ │ │ Default gateway: "192.168.123.10" │ │ I/O ---> │ │ [*] Onewire support ---> // Die allgemeine Onewire Unterstützung. │ │ [*] Onewire device detection support // Automatische Bauteilerkennung In der etherrape.m4 Datei wird nun noch der Pin des atmega geändert wo der DS1820 angeschlossen ist. Im NANO Editor wird mit "STRG-O dann Enter" gespeichert und mit STRG-X beendet. # nano pinning/hardware/etherrape.m4 // editieren der m4 Datei ----- ONEWIRE PIN ändern bei "ONEWIRE_PORT_RANGE(PD6, PD6)" zb. auf PD0 ----- Nun schreiben wir uns ein Script welches den Temperatursensor regelmäßig abfragt und in eine Globale Variable schiebt. # rm control6/control6.src // Original Datei löschen # nano control6/control6.src // Anlegen der c6 Datei. Die Datei ist nun neu und leer. C6_HEADER(`/* This will be in control6.h */') CONTROL_START ECMD_GLOBAL(temp01, 0, uint16_t); THREAD(start) temp01 = ONEWIRE_GET(1054698802080017); WAIT(5) THREAD_END(start) ON STARTUP DO THREAD_START(start) END CONTROL_END Kompilieren der eigentlichen Firmware. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 24072/65536 bytes (36.73%) [===========-------------------] Program (.text + .data) : 24072 bytes Data (.data + .bss) : 2250 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.bin</b> Die eigentliche Firmware ist nun kompiliert und fertig um via Netzwerk/tftpd aufgespielt zu werden. Ich verwende im folgenden Schritt Windows 7. Beschreibung folgt. ==Firmware flashen via TFTPD== Platzhalter, [[User_talk:Djmaster#1 | Todoliste]] 28-01-2016 <gallery> File:Tftpd_tempmess01.png File:Tftpd_tempmess02.png File:Tftpd_tempmess03.png File:Tftpd_tempmess04.png </gallery> [[Category:Tutorials]] 89ee9dc25cd0902e7d5181c328dc008652a02336 6 508 1565 2016-01-27T19:01:32Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 509 1566 2016-01-27T19:01:53Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 510 1567 2016-01-27T19:02:16Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 10 37 1572 422 2016-01-27T19:59:36Z Djmaster 255 wikitext text/x-wiki <noinclude>{{i18n|Template:Getting Started}}</noinclude> {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | style="background-color: #FFFFFF; text-align: center; border-bottom:1px solid #aaaaaa;" | '''Getting started''' |- | * [[Quick Start Guide]] * [[Community]] * [[Contributing]] ---- [[:Category:Tutorials|'''For Beginners''']] * [[Temperaturmesssystem|easy network temperature measurement]] |} 39496a2669cd7105857540a70a093d69d22c1a65 1573 1572 2016-01-27T19:59:59Z Djmaster 255 wikitext text/x-wiki <noinclude>{{i18n|Template:Getting Started}}</noinclude> {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%; color:black; width:100%;" |- | style="background-color: #FFFFFF; text-align: center; border-bottom:1px solid #aaaaaa;" | '''Getting started''' |- | * [[Quick Start Guide]] * [[Community]] * [[Contributing]] ---- [[:Category:Tutorials|'''For Beginners''']] * [[Temperaturmesssystem|Easy network temperature measurement]] |} 044f100be0825830b4e659f1ee20ebfc4f433b8c 6 511 1577 2016-01-28T18:57:24Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 512 1578 2016-01-28T18:57:50Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 3 495 1583 1538 2016-01-28T19:47:28Z Djmaster 255 wikitext text/x-wiki =Todo Liste= ==1== *[[Temperaturmesssystem_(Deutsch)]] ** Paar Bilder und tftpd win32 ** ds1820 id herausbekommen und 4k7 pullup anfügen ** [ ] jump bootloader???? Anm.: Voraussetzung für das ECMD "bootloader" sind die Optionen "General Setup -> Prompt all possible options" (CONFIG_EXPERT) und "General Setup -> Enable bootloader jump" (BOOTLOADER_JUMP) im menuconfig. Per Telnet sich mit dem ethersex verbinden (telnet <IP-Ethersex> 2701). Dort "bootloader" oder "wdreset" eingeben. ==2== *[[BOOTP_%28Deutsch%29]] ** Links prüfen ** <s>Bilder prüfen</s> ** Text anpassen an aktuelle rel. ==3== *[[I2C_%28Deutsch%29]] **Levelshifter **Aufteilung ==4== *ETHERNET LOADER??? old wiki 976e70279a1bd144038ee0a495147ce4ca832ea7 1585 1583 2016-01-29T15:30:33Z Djmaster 255 wikitext text/x-wiki =Todo Liste= ==1== *[[Temperaturmesssystem_(Deutsch)]] ** make clean && make ** Paar Bilder und tftpd win32 ** ds1820 id herausbekommen und 4k7 pullup anfügen ** [ ] jump bootloader???? Anm.: Voraussetzung für das ECMD "bootloader" sind die Optionen "General Setup -> Prompt all possible options" (CONFIG_EXPERT) und "General Setup -> Enable bootloader jump" (BOOTLOADER_JUMP) im menuconfig. Per Telnet sich mit dem ethersex verbinden (telnet <IP-Ethersex> 2701). Dort "bootloader" oder "wdreset" eingeben. ==2== *[[BOOTP_%28Deutsch%29]] ** Links prüfen ** <s>Bilder prüfen</s> ** Text anpassen an aktuelle rel. ==3== *[[I2C_%28Deutsch%29]] **Levelshifter **Aufteilung ==4== *ETHERNET LOADER??? old wiki f644b6afc4b310984b6dd7d4bd6ed6bb52fed158 0 5 1586 1539 2016-01-29T16:30:07Z GooPie4o 265 Protected "[[Ethersex]]" (‎[edit=sysop] (indefinite) ‎[move=sysop] (indefinite)) wikitext text/x-wiki {{i18n|Ethersex}} {{NewWiki}} == Welcome to ethersex.de - the universal AVR firmware == {|style="width:100%;" |style="width:33%;"|{{Facts}} |style="width:33%;vertical-align:baseline;height:100%"|{{Getting Started}} |style="width:33%;vertical-align:baseline;height:100%"|{{Documentation}} |- |} 28facb6ff3f2d3dbc8fb3adb28a61a9cb43ade2b 0 57 1587 1540 2016-01-29T16:30:17Z GooPie4o 265 Protected "[[Ethersex (Deutsch)]]" (‎[edit=sysop] (indefinite) ‎[move=sysop] (indefinite)) wikitext text/x-wiki {{i18n|Ethersex}} {{NewWiki (Deutsch)}} == Willkommen bei ethersex.de - der universalen AVR Firmware == {|style="width:100%;" |style="width:33%;"|{{Facts (Deutsch)}} |style="width:33%;vertical-align:baseline;height:100%"|{{Getting Started (Deutsch)}} |style="width:33%;vertical-align:baseline;height:100%"|{{Documentation (Deutsch)}} |- |} 589ab6bc70eba695550dd60534099c919c5b2059 6 513 1592 2016-01-29T17:23:07Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 514 1593 2016-01-29T17:24:26Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 515 1594 2016-01-29T17:24:40Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 516 1595 2016-01-29T17:24:50Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 517 1597 2016-01-29T17:26:26Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 518 1598 2016-01-29T17:26:52Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 519 1599 2016-01-29T17:27:05Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 520 1600 2016-01-29T17:27:18Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 494 1602 1535 2016-01-29T17:30:31Z Djmaster 255 wikitext text/x-wiki {{i18n|BOOTP}} {{Module |NAME=BOOTP |MENUCONFIG={{Protocol}}->BOOTP |STATUS={{In_Development}} |PINNING=no |ECMD=no |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/protocols/bootp https://github.com/ethersex/ethersex/tree/master/protocols/bootp] }} * <b>Direktkopie von old.ethersex.wiki.. 25.01.2016</b> == Warum BOOTP? == Jeder kennt das Problem, wenn man eine Firmware erstellt hat, muss sie irgendwie in die Hardware kommen. Der gängige Weg, man flasht die Hardware mit einem Programmieradapter über SPI oder [http://de.wikipedia.org/wiki/Joint_Test_Action_Group JTAG] ([http://www.atmel.com/dyn/resources/prod_documents/doc2475.pdf ATMEL]). In der Firmware muss die [http://de.wikipedia.org/wiki/MAC-Adresse MAC]- Adresse und die [http://de.wikipedia.org/wiki/IP-Adresse IP-Adresse] für die Hardware (µC) einkompiliert sein. Sie ist damit erstmals fix und kann nur nachträglich über das ECMD-Kommandos ip geändert werden. Schön wäre es, wenn man sich um die IP-Adresse nicht kümmern müsste und sie selbständig zum Bootzeitpunkt geladen wird. Und noch schöner wäre es, wenn der µC sich auch gleich die aktuelle Firmware selbst laden und flashen würde. Genau dies macht jetzt BOOTP.<br /> === BOOTP Startsequenz === [http://de.wikipedia.org/wiki/Bootstrap_Protocol BOOTP] ist der Vorläufer von [http://de.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol DHCP] mit dem einem Netzwerkgerät wie z.B. unserem µC eine IP-Adresse zugeordnet werden kann. Falls das Netzwerkgerät nicht über einen eigenen Festspeicher verfügt, kann auch die Firmware oder das Betriebssystem auf Anfrage des Netzwerkgerätes übertragen werden. Damit BOOTP funktioniert, muss ein Minimalprogramm mit dem BOOTP-Client auf dem Netzwerkgerät als Bootloader gespeicher sein. Bei einem PC liegt dieses Programm in der Netzwerkkarte. Auf unserem µC muss der Ethernet Bootloader geflasht sein. Dieser enthält eine eindeutige MAC-Adresse für das Netzwerkgerät, damit es adressiert werden kann.<br /> Zum Bootzeitpunkt verfügt der µC nur über die MAC-Adresse. Er stellt also als erstes eine Broadcast-Anfrage an alle Netzwerkteilnehmer mit der Bitte ihm eine IP-Adresse zu geben. Gibt es im Netzwerk einen anderen Rechner, der einen BOOTP- oder DHCP-Server enthält, so antwortet dieser Server und gibt ihm, sofern erlaubt, eine IP-Adresse, die Netmask und das Gateway. Ab nun an kann der µC unter dieser Adresse erreicht werden. Als nächstes fragt der µC den BOOTP-Server nach einer aktuellen Firmware. Dieser teilt ihm den Server und den Port mit, von dem die Firmware per [http://de.wikipedia.org/wiki/Trivial_File_Transfer_Protocol TFTP] geladen werden kann. Mit dieser Art des bootens, kann sehr elegant der µC geflasht und gleichzeitig eine IP-Adresse zugeordnet werden. Das eigentliche flashen der Firmware macht der µC damit selbständig. Mit dem Ethernet Bootloader und BOOTP ist es möglich, beliebige Firmware zu laden ohne ein Programmieradapter zu benutzen. Es muss lediglich die aktuelle Firmware auf dem BOOTP-Server hinterlegt sein und einmal der µC neu gestartet werden und schon flasht er sich selbständig ohne weiteres zutun nur über das Netzwerk. Diese Art des "flashens" geht schneller als mit einem Programmieradapter. In gut 10s ist die Firmware (ca. 50kB) geladen, geflasht und gestartet.<br /> === Voraussetzungen === Damit BOOTP benutzt werden kann müssen bestimmte Voraussetzungen erfüllt sein: * Nur mit einem ATMEGA644 oder größer läßt sich der 8KB Ethernet Bootloader flashen * Der Bootloader mit BOOTP belegt die letzten 8KB ab Adresse xE000 des Programmspeichers, die nicht mehr genutzt werden können * Die Programmgröße (Firmware) ist auf 56 KB beschränkt * Die Securebits sollten gesetzt sein, damit der Bootloader sich nicht selbst überschreiben kann * Es muss ein BOOTP- und TFTP- Server wie z.B. HahneDHCP o.ä. im Netzwerk erreichbar sein * Die Firmware muss als ethersex.bin auf dem TFTP-Server hinterlegt sein * In der Firmware muss die selbe MAC-Adresse verwendet werden wie im Bootloader von BOOTP == Konfiguration in menuconfig == Als Basis kann in nenuconfig die Option "Bootloader BOOTP" gewählt werden. Es ist zu beachten, dass '''keine spezifischen Einstellungen''' außer CPU-Typ und MCU frequency für die jeweilige Hardware im Bootloader durchgeführt werden. Die hardwarespezifischen Einstellungen werden in der Firmware vorgenommen. Folgende Optionen sollten in '''menuconfig''' aktiviert sein: * '''config-File''' ** Load a Default Configuration ---> *** (x) Ethernet Bootloader ** General Setup *** ATMEGA644 *** 16000000 MCU frequency (für AVR-NET-IO) *** (x) Build a bootloader *** (x) Teensy build ** Network ---> *** Ethernet (ENC28J60) support **** Etherrape MAC address 00:11:22:33:44:55 (bitte ändern!) *** (x) UDP support *** (x) UDP broadcast support *** (x) BOOTP (DHCP like) support ** Applications -> *** (x) TFTP support '''Wichtig!''' Die MAC-Adresse muss gesetzt sein. Die selbe MAC-Adresse muss in der Firmware später auch benutzt werden. Hier ist eine [http://www.phw-magdeburg.de/ethersex/BOOTP.config Konfigurationsdatei] für das Pollin AVR-NET-IO mit Addon (MAC: AC:DE:48:CE:23:C8 ): Damit man nun nicht jedes mal die MAC-Adresse neu einkompilieren muss, kann man sie auch händisch mit einem Texteditor in [http://www.phw-magdeburg.de/ethersex/ethersex.hex ''ethersex.hex''] ändern. <source lang="perl"> :10E000003EC0000066C0000064C0000062C00000A6 :10E0100060C000005EC000005CC000005AC000008C :10E0200058C0000056C0000054C0000052C000009C :10E0300050C0000014C100004CC000004AC00000E5 :10E0400048C0000046C0000044C0000042C00000BC :10E0500040C000003EC000003CC000003AC00000CC :10E0600038C0000036C0000034C0000032C00000DC :10E07000"ACDE48CE23C8"006F63746574000014BE24 :10E0800088E10FB6F89480936000109260000FBE94 :10E0900010926E0010926F001092700011241FBE3B :10E0A000CFEFD0E1DEBFCDBF11E0A0E0B1E0E8EE00 </source> == Flashen des Bootloaders == Nach der Konfiguration mit menuconfig den Bootloader mit ''make clean'' und ''make'' compilieren und mit einem Programmieradapter die Datei ''ethersex.hex'' flashen. Wenn eine alte Vorlage benutzt wird, muss ggf. die MAC-Adresse noch einmal geändert werden. Damit der Bootloader nicht durch die Firmware überschrieben wird, müssen die Lock-Bits folgendermaßen gesetzt sein: Für ATmega644: ''avrdude -p m644 -c ponyser -P /dev/ttyS0 -U lock:w:0x0F:m'' oder in Ponyprog: *(x) BootLock02 *(x) BootLock01 *(x) Lock2 *(x) Lock1 '''Achtung!''' Sollte der Bootloader neu geflasht werden, so müssen die Lock-Bits nach dem flashen immer wieder neu gesetzt werden. Wer keine Lust hat den Ethernet-Bootloader zu kompilieren, kann hier für das AVR-NET-IO mit Addon die Datei [http://www.phw-magdeburg.de/ethersex/ethersex.hex ''ethersex.hex''] verwenden. == BOOTP-Server konfigurieren (Windows) == Als BOOTP-Server verwende ich unter Windows '''hahneWin DHCP Server'''. Als Beispielkonfiguration ist bei mir folgendes eingestellt: * Kein DHCP sondern nur BOOTP aktiviert (zur Problemvermeidung bei bestehendem DHCP-Server) * 192.168.0.0 Netzwerk für BOOTP * 192.168.0.1 Rechner mit hahneWin DHCP Server und TFTP auf Port 69 * statische Adressvergabe über MAC-Adressen fest zugewiesen * 192.168.0.88 AVR-NET-IO mit MAC AC:DE:48:CE:23:C8 * 255.255.255.0 Netmask * 192.168.0.251 Gateway * 192.168.0.251 DNS-Server [[File:Hahne_DHCP.jpg]] Abb.: hahneWin DHCP Server Alle weiteren Einstellungen zum hahneWin DHCP Server können den nachfolgenden Links entnommen werden: Grundsätzlich werden als erstes unter ''Optionen->Einstellungen'' die Grundeinstellungen vorgenommen. * [http://www.phw-magdeburg.de/ethersex/Einstellungen_Allgemein.JPG Einstellungen Allgemein] * [http://www.phw-magdeburg.de/ethersex/Einstellungen_Schnittstellen.JPG Einstellungen Schnittstellen] * [http://www.phw-magdeburg.de/ethersex/Einstellungen_DHCP.JPG Einstellungen DHCP] * [http://www.phw-magdeburg.de/ethersex/Einstellungen_TFTP.JPG Einstellungen TFTP] * [http://www.phw-magdeburg.de/ethersex/Einstellungen_TFTP_Optionen.JPG Einstellungen TFTP Optionen] Im zweiten Schritt werden unter ''Optionen->Konfigurationsprofile verwalten'' das betreffende Netzwerk ausgewählt und mit ''Bearbeiten'' angepaßt. Im meinem Beispiel wurde der Profilname durch Ethersex ersetzt. Vorher stand dort If-2_0.1. * [http://www.phw-magdeburg.de/ethersex/Konfigurationsprofile.JPG Konfigurationsprofile] * [http://www.phw-magdeburg.de/ethersex/Ethersex_Basiskonfiguration.JPG Basiskonfiguration] * [http://www.phw-magdeburg.de/ethersex/Ethersex_DNS.JPG DNS] * [http://www.phw-magdeburg.de/ethersex/Ethersex_Boot.JPG Boot] Als letztes wird dann noch ein neuer statischer Eintrag über den Schaltknopf ''Hinzufügen'' für den µC erstellt. * [http://www.phw-magdeburg.de/ethersex/Statische_Eintraege.JPG Statische Einträge] Alle nicht aufgeführten Seiten enthalten die Standardeinstellungen und müssen nicht weiter modifiziert werden. So, nun sollte der BOOTP-Server laufen. Den Server kann man unter ''Datei->Server starten/beenden'' in den jeweiligen Zustand setzen. === Hahne BOOTP-Server verwenden === Wird jetzt der µC gebootet, so bezieht er seine Netzwerkeinstellungen vom BOOTP-Server, läd danach die Firmware und startet diese. Im Logfile des BOOTP-Server können die Aktivitäten verfolgt werden. Sobald dem µC eine IP-Adresse vergeben wurde erscheint ein grünes Häkchen vor der MAC-Adresse in der Hauptansicht. Folgende Bedingungen müssen beachtet werden: * hat der µC noch keine Firmware geladen, so wird diese per TFTP im BOOTP-Prozess geladen und geflasht * ist schon eine Firmware im µC geflasht, so werden nur die Netzwerkparameter nach einem Reboot oder Power on/off geladen und die vorhandene Firmware gestartet * um die Firmware erleut zu laden, muss mit dem [[ECMD]] Kommando ''wdreset'' oder ''bootloader'' der µC "resettet" werden == BOOTP-Server konfigurieren (Linux) == Als BOOTP-Server verwende ich unter Linux '''dhcpd3'''. Als Beispielkonfiguration ist bei mir folgendes eingestellt: * Kein DHCP sondern nur BOOTP aktiviert (zur Problemvermeidung bei bestehendem DHCP-Server) * 192.168.30.0 Netzwerk für BOOTP * 192.168.30.134 Rechner mit DHCPD3 Server und TFTP auf Port 69 * statische Adressvergabe über MAC-Adressen fest zugewiesen * 192.168.30.10 AVR-NET-IO mit MAC AC:DE:48:CE:23:C8 * 255.255.255.0 Netmask * 192.168.30.1 Gateway * 192.168.30.1 DNS-Server Die folgende Konfiguration verfügt nicht über eine dynamische IP-Range. Dies bedeutet, dass diese Konfiguration nicht mit einem bereits vorhanden DHCP Server ins Gehege kommt. Dem ethersex wird zum Starten eine feste IP zugewiesen. Der Ablauf: #DHCP Server und TFTP Server müssen gestartet sein #Dann das AVR Net-IO in die Steckdose #Ethersex fragt mit seiner Netzwerkadresse ac:de:48:ce:23:c8 per bootp nach einer IP-Adresse #Der DHCP Server schaut in seiner Liste nach ac:de:48:ce:23:c8, findet diese und die IP 192.168.30.10 zusammen mit der TFTP Server IP 192.168.30.134 und dem Dateinamen ethersex.bin zurück an Ethersex #Ethersex kann nun eine IP Verbindung zum TFTP Server 192.168.30.134 aufbauen und lädt die Datei ethersex.bin #Anschlißend startet Ethersex mit der ethersex.bin ===DHCP-Server konfigurieren === sudo apt-get install dhcp3-server Anschließend muss die Konfigurationsdatei /etc/dhcp3/dhcpd.conf, wie folgt bearbeitet werden. Die IP Adressen musst Du an Deine Gegebenheiten anpassen. <pre> default-lease-time 86400; max-lease-time 2592000; authoritative; subnet 192.168.30.0 netmask 255.255.255.0 { option subnet-mask 255.255.255.0; # subnet maske option routers 192.168.30.1; # Gateway option domain-name-servers 192.168.30.1; # DNS Server ddns-update-style none; # Neue Clients werden dem DNS Server nicht mitgeteilt next-server 192.168.30.134; # TFTP Server host netio { hardware ethernet ac:de:48:ce:23:c8; # mac adresse des pollin net io fixed-address 192.168.30.10; # Eine freie IP-Adresse im lokalen Netz filename "ethersex.bin"; # bootfile (Achtung das ethersex.bin file nehmen!) } } </pre> Anschließend kann der DHCP Server gestartet/neu gestartet werden: sudo /etc/init.d/dhcp3-server restart ===TFTP Server konfigurieren=== Die Konfiguration des TFTP Servers ist ziemlich einfach. Dieser muss nur installiert und gestartet werden: sudo apt-get install tftpd-hpa Die vom Makefile generierte ethersex.bin Datei muss dann nur noch nach /var/lib/tftpboot kopiert werden. Den TFTP Server startetn/neu starten sudo /etc/init.d/tftpd-hpa restart == Bekannte Probleme == Ist im µC bereits eine Firmware geflasht, so sollten durch den BOOTP-Mechanismus die Netzwerkparameter wie IP, Gateway, DNS und Gateway bezogen werden. Laut Logfile vom haneWin DHCP Server erfolgt dies auch. Danach sollte dann die Firmware mit genau diesen Netzwerkparametern gestartet werden. Dies geschiet aber nicht, da vermutlich die Netzwerkparameter nicht an die Firmware weitergereicht werden. Es werden die alten Netzwerkparameter geladen trotz der Einstellung in ''menuconfig'', dass BOOTP verwendet werden soll. Man erkennt mit dem Kommando ''arp -a'' in der Windows-Konsole, dass nach dem Booten die neuen Netzwerkparameter mit der IP vom BOOTP-Server vergeben wurden. Im zweiten Schritt, wenn der µC die Firmware läd, jedoch die alte letzte IP-Adresse benutzt. Daher muss man mit ''arp -d'' die ARP-Tabelle löschen und sich unter der alten IP in den µC mit telnet (siehe [[ECMD Protocols]]) einloggen und mit den Befehlen ''ip, netmask, gw, dns server'' manuell auf die neuen Werte setzen. Alternativ kann man den µC zwingen die neue Firmware zu laden, die dann aber intern die gleichen Netzwerkparameter wie der BOOTP-Server haben muss. Schade eigentlich, so hätte man sehr elegant mit dem BOOTP-Server die Netzwerkparameter zur Bootzeit vergeben können. Ich habe gerade noch einmal in den Quellen nachgesehen, dort werden die Netzwerkparameter von BOOTP nur im EEPROM des µC gespeichert, wenn ''Write BOOTP data to EEPROM'' in ''menuconfig'' ausgewählt ist. Damit lassen sich die Netzwerkparameter zwischenspeichern und stehen nach dem Start der Firmware als Default zur Verfügung. Per Default wird diese Option nicht geladen. Das Problem sollte sich damit beheben lassen. Das habe ich aber bisher noch nicht getestet. Wenn dem so ist, sollte die Default-Konfiguration des ''Ethernet Bootloader'' entsprechend angepasst werden. Ist die zu ladende Firmware größer als 56kB, so wird die Firmware nicht richtig geflasht, da ab xE000 der Ethernet-Bootloader den Bereich mit gesetzten Secure-Bits blockiert. == Nützliche Links == * [http://www.atmel.com/dyn/resources/prod_documents/doc2475.pdf ATMEL JTAG-Interface-Beschreibung] * [http://www.atmel.com/dyn/resources/prod_documents/doc2593.pdf Datenblatt zum ATMEGA644] a395ae59b7b4ec649717da15006917cd6f015cac 6 521 1603 2016-01-29T17:44:32Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 522 1604 2016-01-29T17:48:47Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 498 1605 1601 2016-01-29T17:50:05Z Djmaster 255 wikitext text/x-wiki {{i18n|Temperaturmesssystem}} [[File:Tempmess_pcb_01.jpg|thumb|280px|meine Testplatine, Layout stimmt bis auf Kleinigkeiten überein]] [[File:Tempmess_pcb_02.jpg|thumb|280px|Testplatine beim Programmieren mit avrdude via ISP]] =PROJEKT Temperaturmessung= ===Einleitung=== * ZIEL: Eine einfache Temperaturmessung mit dem [[Onewire_(Deutsch)#Anschluss_AVR-NET-IO | DS1820 im parasitären Modus]]. * ZIEL: Die Ausgabe einer Temperaturvariable via integrierten Webbrowser oder telnet. * ZIEL: Die Firmware muss via Netzwerk neu flashbar sein. * Abgeändertes vereinfachtes [http://www.lochraster.org/etherrape/ etherrape] Board. * Zwei Spannungsregler, ein atmega644p, ein enc28j60, und etwas 0805 Hühnerfutter. ===Schaltung=== Das Layout passt in folgendes Gehäuse. Vorher am besten nochmal genau nachmessen. ;)<br> Conrad Bestell-Nr.: [https://www.conrad.at/de/hutschienen-gehaeuse-90-x-360-x-58-polycarbonat-axxatronic-cnmb-2-kit-con-1-st-531441.html 531441] / Axxatronic CNMB-2-KIT-CON <gallery> File:Sch_tempmess.png File:Pcb_tempmess.png </gallery> * Erstellt mit Eagle Version 7.1.0 für Windows * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_schematic_001.pdf PDF Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_layout_001.pdf PDF Layout gespiegelt] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.sch Eagle Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.brd Eagle Layout] ===Software=== Ethersex (Linux) - https://github.com/ethersex/ethersex Avrdude (Windows) - http://download.savannah.gnu.org/releases/avrdude/ (avrdude-6.1-mingw32.zip) tftpd (Windows) - http://tftpd32.jounin.net/tftpd32_download.html ===Firmware/Bootloader=== Die ethersex Firmware selbst wird für zwei Sachen verwendet. Den <b>Bootloader</b> UND die <b>Firmware</b>. Der Bootloader wird sozusagen einmal in den ersten Bereich des Mikrocontrollers geschrieben und bleibt dort auch. Er wird später die Firmware via Netzwerk entgegennehmen und in den Controller schreiben. Somit befindet sich in den ersten 10% unser Bootloader und in den restlichen 90% der Code den wir wollen. Das zu Verstehen war für mich an Anfang der schwierigste Teil, ist aber dann doch sehr einfach. Ich kann somit ohne ISP-Programmer eine Firmware in den Controller schreiben. Hier grob noch die nächsten Schritte: * Als erstes ist der Bootloader zu konfigurieren, dann via ISP zu programmieren. * Der ISP-Programmer wegräumen. ;) * Als zweites ist die Firmware zu konfigurieren, dann holt sich der Bootloader unsere Firmware via Netzerk/tftpd. =BOOTLOADER= ==Bootloader bauen== <gallery> File:Putty_bootl_tempmess01.png File:Putty_bootl_tempmess02.png File:Putty_bootl_tempmess03.png File:Putty_bootl_tempmess04.png File:Putty_bootl_tempmess05.png File:Putty_bootl_tempmess06.png File:Putty_bootl_tempmess07.png File:Putty_bootl_tempmess08.png </gallery> Ab nun befinde ich mich auf einem <b>virtuellen Debian Rechner</b> wo ich die Firmware herunterlade und daraus den Bootloader erstelle.<br> <b>WICHTIG:</b> Die IP und MAC-Adresse müssen natürlich verändert werden. Die selbe IP und MAC-Adresse müssen in der Firmware später auch benutzt werden. <br> * Bei einem neuen Debian System müssen mit "apt-get" ein paar Sachen nachinstalliert werden. Hier zu finden [[Preparation_(Deutsch)]] * So eine art DHCP wäre auch möglich, nennt sich [[BOOTP_(Deutsch) | BOOTP]]. Darauf gehe ich hier nicht ein. # cd /home/avr/ # mkdir ethersex_IP_60 // Mein "Arbeitsordner" # cd ethersex_IP_60/ // Ordner für das Board mit der IP 192.168.123.60 # git clone git://github.com/ethersex/ethersex.git // ethersex Firmware herunterladen Cloning into ethersex... remote: Counting objects: 37366, done. remote: Total 37366 (delta 0), reused 0 (delta 0), pack-reused 37366 Receiving objects: 100% (37366/37366), 11.27 MiB | 1.22 MiB/s, done. Resolving deltas: 100% (26538/26538), done. # cp -r ethersex bootloader // Ich kopiere den ethersex Ordner zu dem bootloader Ordner. 1:1 Kopie # cd bootloader/ // In den Bootloader Ordner wechseln # make menuconfig // Einstellungen für Bootloader im nächsten Schritt │ │ Load a Default Configuration ---> │ │ (*) Ethernet Bootloader │ │ General Setup ---> │ │ (ATmega644) Target MCU │ │ (20000000) MCU frequency │ │ [*] Build a bootloader │ │ [*] Teensy build │ │ Network ---> │ │ Hostname: "esex060" // Hostname ändern │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" // MAC ändern mit "Randomize MAC address" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" // Wenn IP nicht vorhanden BOOTP deaktivieren! │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ [ ] BOOTP (DHCP-like) support // BOOTP deaktivieren! │ │ Applications ---> │ │ [*] TFTP support ---> │ │ [*] TFTP-o-matic │ │ TFTP-server IPv4 address: "192.168.123.233" // Server wo TFTPD läuft │ │ TFTP image to load: "esex060.bin" // Diesen Dateinamen ladet später unser Board via Netzwerk/tftpd jetzt noch EXIT und SPEICHERN. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 5902/8192 bytes (72.4%) [=====================---------] Program (.text + .data) : 5902 bytes Data (.data + .bss) : 1902 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.hex</b> ==Bootloader flashen via ISP== <gallery> File:Avrdude tempmess01.png File:Avrdude tempmess02.png File:Avrdude tempmess03.png File:Avrdude tempmess04.png </gallery> Ich flashe hier einfacher weise mit meinem Windows 7 Notebook. Ich habe avrdude einfach unter C:\ liegen. Dort kopiere ich nun die ethersex.hex hin.<br> Somit kann man mit dem flashen den Bootloaders loslegen. avrdude -cusbasp -pm644p -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m // gilt nur für atmega644p und vermutlich auch 644 avrdude -cusbasp -pm644p -U flash:w:ethersex.hex avrdude -cusbasp -pm644p -U lock:w:0x0F:m Der Mikrocontrollerboard ist nun vorbereitet für die eigentliche Firmware. Der ISP-Programmer kann nun bei Seite gelegt werden und wird soweit alles richtig konfiguriert ist auch nicht mehr benötigt.<br> Nun erfolgt das Erstellen der Firmware. =FIRMWARE= ==Firmware bauen== <gallery> File:Putty_c6_m4_tempmess01.png File:Putty_c6_m4_tempmess02.png File:Putty_c6_m4_tempmess03.png </gallery> * <b>WICHTIG:</b> IP, MAC Adresse, Gateway, Netmask, Hostname <b>MUSS</b> gleich sein wie bei dem Bootloader! * Der integrierte Webserver ist in der original Firmware schon aktiviert. ( Applications --> [*] HTTP Server ) # cd /home/avr/ethersex_IP_60/ # cd ethersex/ # make menuconfig │ │ Load a Default Configuration ---> │ │ (*) Etherrape │ │ General Setup ---> │ │ (ATmega644) Target MCU // atmega644p bei mir │ │ (20000000) MCU frequency // 20MHz Quarz │ │ [ ] VFS (Virtual File System) support // Benötige ich hier nicht. │ │ [*] control6 script // Hier wird unsere DS1820 Temperatur in eine Variable geschrieben für den implementieren Webserver. │ │ Network ---> // WICHTIG: IP, MAC Adresse, Gateway, Netmask, Hostname MUSS gleich sein wie bei dem Bootloader! │ │ Hostname: "esex060" │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" │ │ Netmask: "255.255.255.0" │ │ │ │ Default gateway: "192.168.123.10" │ │ I/O ---> │ │ [*] Onewire support ---> // Die allgemeine Onewire Unterstützung. │ │ [*] Onewire device detection support // Automatische Bauteilerkennung In der etherrape.m4 Datei wird nun noch der Pin des atmega geändert wo der DS1820 angeschlossen ist. Im NANO Editor wird mit "STRG-O dann Enter" gespeichert und mit STRG-X beendet. # nano pinning/hardware/etherrape.m4 // editieren der m4 Datei ----- ONEWIRE PIN ändern bei "ONEWIRE_PORT_RANGE(PD6, PD6)" zb. auf PD0 ----- Nun schreiben wir uns ein Script welches den Temperatursensor regelmäßig abfragt und in eine Globale Variable schiebt. # rm control6/control6.src // Original Datei löschen # nano control6/control6.src // Anlegen der c6 Datei. Die Datei ist nun neu und leer. C6_HEADER(`/* This will be in control6.h */') CONTROL_START ECMD_GLOBAL(temp01, 0, uint16_t); THREAD(start) temp01 = ONEWIRE_GET(1054698802080017); WAIT(5) THREAD_END(start) ON STARTUP DO THREAD_START(start) END CONTROL_END Kompilieren der eigentlichen Firmware. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 24072/65536 bytes (36.73%) [===========-------------------] Program (.text + .data) : 24072 bytes Data (.data + .bss) : 2250 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.bin</b> Die eigentliche Firmware ist nun kompiliert und fertig um via Netzwerk/tftpd aufgespielt zu werden. Ich verwende im folgenden Schritt Windows 7. Beschreibung folgt. ==Firmware flashen via TFTPD== Platzhalter, [[User_talk:Djmaster#1 | Todoliste]] 28-01-2016 <gallery> File:Tftpd_tempmess01.png File:Tftpd_tempmess02.png File:Tftpd_tempmess03.png File:Tftpd_tempmess04.png </gallery> [[Category:Tutorials]] 0cdbf90659d23edc0ff26080a419e26efe3420b6 1606 1605 2016-01-29T17:50:32Z Djmaster 255 wikitext text/x-wiki {{i18n|Temperaturmesssystem}} [[File:Tempmess_pcb_01.jpg|thumb|250px|meine Testplatine, Layout stimmt bis auf Kleinigkeiten überein]] [[File:Tempmess_pcb_02.jpg|thumb|250px|Testplatine beim Programmieren mit avrdude via ISP]] =PROJEKT Temperaturmessung= ===Einleitung=== * ZIEL: Eine einfache Temperaturmessung mit dem [[Onewire_(Deutsch)#Anschluss_AVR-NET-IO | DS1820 im parasitären Modus]]. * ZIEL: Die Ausgabe einer Temperaturvariable via integrierten Webbrowser oder telnet. * ZIEL: Die Firmware muss via Netzwerk neu flashbar sein. * Abgeändertes vereinfachtes [http://www.lochraster.org/etherrape/ etherrape] Board. * Zwei Spannungsregler, ein atmega644p, ein enc28j60, und etwas 0805 Hühnerfutter. ===Schaltung=== Das Layout passt in folgendes Gehäuse. Vorher am besten nochmal genau nachmessen. ;)<br> Conrad Bestell-Nr.: [https://www.conrad.at/de/hutschienen-gehaeuse-90-x-360-x-58-polycarbonat-axxatronic-cnmb-2-kit-con-1-st-531441.html 531441] / Axxatronic CNMB-2-KIT-CON <gallery> File:Sch_tempmess.png File:Pcb_tempmess.png </gallery> * Erstellt mit Eagle Version 7.1.0 für Windows * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_schematic_001.pdf PDF Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_layout_001.pdf PDF Layout gespiegelt] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.sch Eagle Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.brd Eagle Layout] ===Software=== Ethersex (Linux) - https://github.com/ethersex/ethersex Avrdude (Windows) - http://download.savannah.gnu.org/releases/avrdude/ (avrdude-6.1-mingw32.zip) tftpd (Windows) - http://tftpd32.jounin.net/tftpd32_download.html ===Firmware/Bootloader=== Die ethersex Firmware selbst wird für zwei Sachen verwendet. Den <b>Bootloader</b> UND die <b>Firmware</b>. Der Bootloader wird sozusagen einmal in den ersten Bereich des Mikrocontrollers geschrieben und bleibt dort auch. Er wird später die Firmware via Netzwerk entgegennehmen und in den Controller schreiben. Somit befindet sich in den ersten 10% unser Bootloader und in den restlichen 90% der Code den wir wollen. Das zu Verstehen war für mich an Anfang der schwierigste Teil, ist aber dann doch sehr einfach. Ich kann somit ohne ISP-Programmer eine Firmware in den Controller schreiben. Hier grob noch die nächsten Schritte: * Als erstes ist der Bootloader zu konfigurieren, dann via ISP zu programmieren. * Der ISP-Programmer wegräumen. ;) * Als zweites ist die Firmware zu konfigurieren, dann holt sich der Bootloader unsere Firmware via Netzerk/tftpd. =BOOTLOADER= ==Bootloader bauen== <gallery> File:Putty_bootl_tempmess01.png File:Putty_bootl_tempmess02.png File:Putty_bootl_tempmess03.png File:Putty_bootl_tempmess04.png File:Putty_bootl_tempmess05.png File:Putty_bootl_tempmess06.png File:Putty_bootl_tempmess07.png File:Putty_bootl_tempmess08.png </gallery> Ab nun befinde ich mich auf einem <b>virtuellen Debian Rechner</b> wo ich die Firmware herunterlade und daraus den Bootloader erstelle.<br> <b>WICHTIG:</b> Die IP und MAC-Adresse müssen natürlich verändert werden. Die selbe IP und MAC-Adresse müssen in der Firmware später auch benutzt werden. <br> * Bei einem neuen Debian System müssen mit "apt-get" ein paar Sachen nachinstalliert werden. Hier zu finden [[Preparation_(Deutsch)]] * So eine art DHCP wäre auch möglich, nennt sich [[BOOTP_(Deutsch) | BOOTP]]. Darauf gehe ich hier nicht ein. # cd /home/avr/ # mkdir ethersex_IP_60 // Mein "Arbeitsordner" # cd ethersex_IP_60/ // Ordner für das Board mit der IP 192.168.123.60 # git clone git://github.com/ethersex/ethersex.git // ethersex Firmware herunterladen Cloning into ethersex... remote: Counting objects: 37366, done. remote: Total 37366 (delta 0), reused 0 (delta 0), pack-reused 37366 Receiving objects: 100% (37366/37366), 11.27 MiB | 1.22 MiB/s, done. Resolving deltas: 100% (26538/26538), done. # cp -r ethersex bootloader // Ich kopiere den ethersex Ordner zu dem bootloader Ordner. 1:1 Kopie # cd bootloader/ // In den Bootloader Ordner wechseln # make menuconfig // Einstellungen für Bootloader im nächsten Schritt │ │ Load a Default Configuration ---> │ │ (*) Ethernet Bootloader │ │ General Setup ---> │ │ (ATmega644) Target MCU │ │ (20000000) MCU frequency │ │ [*] Build a bootloader │ │ [*] Teensy build │ │ Network ---> │ │ Hostname: "esex060" // Hostname ändern │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" // MAC ändern mit "Randomize MAC address" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" // Wenn IP nicht vorhanden BOOTP deaktivieren! │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ [ ] BOOTP (DHCP-like) support // BOOTP deaktivieren! │ │ Applications ---> │ │ [*] TFTP support ---> │ │ [*] TFTP-o-matic │ │ TFTP-server IPv4 address: "192.168.123.233" // Server wo TFTPD läuft │ │ TFTP image to load: "esex060.bin" // Diesen Dateinamen ladet später unser Board via Netzwerk/tftpd jetzt noch EXIT und SPEICHERN. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 5902/8192 bytes (72.4%) [=====================---------] Program (.text + .data) : 5902 bytes Data (.data + .bss) : 1902 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.hex</b> ==Bootloader flashen via ISP== <gallery> File:Avrdude tempmess01.png File:Avrdude tempmess02.png File:Avrdude tempmess03.png File:Avrdude tempmess04.png </gallery> Ich flashe hier einfacher weise mit meinem Windows 7 Notebook. Ich habe avrdude einfach unter C:\ liegen. Dort kopiere ich nun die ethersex.hex hin.<br> Somit kann man mit dem flashen den Bootloaders loslegen. avrdude -cusbasp -pm644p -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m // gilt nur für atmega644p und vermutlich auch 644 avrdude -cusbasp -pm644p -U flash:w:ethersex.hex avrdude -cusbasp -pm644p -U lock:w:0x0F:m Der Mikrocontrollerboard ist nun vorbereitet für die eigentliche Firmware. Der ISP-Programmer kann nun bei Seite gelegt werden und wird soweit alles richtig konfiguriert ist auch nicht mehr benötigt.<br> Nun erfolgt das Erstellen der Firmware. =FIRMWARE= ==Firmware bauen== <gallery> File:Putty_c6_m4_tempmess01.png File:Putty_c6_m4_tempmess02.png File:Putty_c6_m4_tempmess03.png </gallery> * <b>WICHTIG:</b> IP, MAC Adresse, Gateway, Netmask, Hostname <b>MUSS</b> gleich sein wie bei dem Bootloader! * Der integrierte Webserver ist in der original Firmware schon aktiviert. ( Applications --> [*] HTTP Server ) # cd /home/avr/ethersex_IP_60/ # cd ethersex/ # make menuconfig │ │ Load a Default Configuration ---> │ │ (*) Etherrape │ │ General Setup ---> │ │ (ATmega644) Target MCU // atmega644p bei mir │ │ (20000000) MCU frequency // 20MHz Quarz │ │ [ ] VFS (Virtual File System) support // Benötige ich hier nicht. │ │ [*] control6 script // Hier wird unsere DS1820 Temperatur in eine Variable geschrieben für den implementieren Webserver. │ │ Network ---> // WICHTIG: IP, MAC Adresse, Gateway, Netmask, Hostname MUSS gleich sein wie bei dem Bootloader! │ │ Hostname: "esex060" │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" │ │ Netmask: "255.255.255.0" │ │ │ │ Default gateway: "192.168.123.10" │ │ I/O ---> │ │ [*] Onewire support ---> // Die allgemeine Onewire Unterstützung. │ │ [*] Onewire device detection support // Automatische Bauteilerkennung In der etherrape.m4 Datei wird nun noch der Pin des atmega geändert wo der DS1820 angeschlossen ist. Im NANO Editor wird mit "STRG-O dann Enter" gespeichert und mit STRG-X beendet. # nano pinning/hardware/etherrape.m4 // editieren der m4 Datei ----- ONEWIRE PIN ändern bei "ONEWIRE_PORT_RANGE(PD6, PD6)" zb. auf PD0 ----- Nun schreiben wir uns ein Script welches den Temperatursensor regelmäßig abfragt und in eine Globale Variable schiebt. # rm control6/control6.src // Original Datei löschen # nano control6/control6.src // Anlegen der c6 Datei. Die Datei ist nun neu und leer. C6_HEADER(`/* This will be in control6.h */') CONTROL_START ECMD_GLOBAL(temp01, 0, uint16_t); THREAD(start) temp01 = ONEWIRE_GET(1054698802080017); WAIT(5) THREAD_END(start) ON STARTUP DO THREAD_START(start) END CONTROL_END Kompilieren der eigentlichen Firmware. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 24072/65536 bytes (36.73%) [===========-------------------] Program (.text + .data) : 24072 bytes Data (.data + .bss) : 2250 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.bin</b> Die eigentliche Firmware ist nun kompiliert und fertig um via Netzwerk/tftpd aufgespielt zu werden. Ich verwende im folgenden Schritt Windows 7. Beschreibung folgt. ==Firmware flashen via TFTPD== Platzhalter, [[User_talk:Djmaster#1 | Todoliste]] 28-01-2016 <gallery> File:Tftpd_tempmess01.png File:Tftpd_tempmess02.png File:Tftpd_tempmess03.png File:Tftpd_tempmess04.png </gallery> [[Category:Tutorials]] 6c2fef1de35a3d50350fc81f4c8664b9740a5200 1637 1606 2016-01-30T16:26:56Z Djmaster 255 /* Software */ wikitext text/x-wiki {{i18n|Temperaturmesssystem}} [[File:Tempmess_pcb_01.jpg|thumb|250px|meine Testplatine, Layout stimmt bis auf Kleinigkeiten überein]] [[File:Tempmess_pcb_02.jpg|thumb|250px|Testplatine beim Programmieren mit avrdude via ISP]] =PROJEKT Temperaturmessung= ===Einleitung=== * ZIEL: Eine einfache Temperaturmessung mit dem [[Onewire_(Deutsch)#Anschluss_AVR-NET-IO | DS1820 im parasitären Modus]]. * ZIEL: Die Ausgabe einer Temperaturvariable via integrierten Webbrowser oder telnet. * ZIEL: Die Firmware muss via Netzwerk neu flashbar sein. * Abgeändertes vereinfachtes [http://www.lochraster.org/etherrape/ etherrape] Board. * Zwei Spannungsregler, ein atmega644p, ein enc28j60, und etwas 0805 Hühnerfutter. ===Schaltung=== Das Layout passt in folgendes Gehäuse. Vorher am besten nochmal genau nachmessen. ;)<br> Conrad Bestell-Nr.: [https://www.conrad.at/de/hutschienen-gehaeuse-90-x-360-x-58-polycarbonat-axxatronic-cnmb-2-kit-con-1-st-531441.html 531441] / Axxatronic CNMB-2-KIT-CON <gallery> File:Sch_tempmess.png File:Pcb_tempmess.png </gallery> * Erstellt mit Eagle Version 7.1.0 für Windows * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_schematic_001.pdf PDF Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_layout_001.pdf PDF Layout gespiegelt] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.sch Eagle Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.brd Eagle Layout] ===Software=== Ethersex (Linux) - https://github.com/ethersex/ethersex Avrdude (Windows) - http://download.savannah.gnu.org/releases/avrdude/ (avrdude-6.1-mingw32.zip) tftpd (Windows) - http://tftpd32.jounin.net/tftpd32_download.html (v4.52 tftpd64 standard edition (zip)) ===Firmware/Bootloader=== Die ethersex Firmware selbst wird für zwei Sachen verwendet. Den <b>Bootloader</b> UND die <b>Firmware</b>. Der Bootloader wird sozusagen einmal in den ersten Bereich des Mikrocontrollers geschrieben und bleibt dort auch. Er wird später die Firmware via Netzwerk entgegennehmen und in den Controller schreiben. Somit befindet sich in den ersten 10% unser Bootloader und in den restlichen 90% der Code den wir wollen. Das zu Verstehen war für mich an Anfang der schwierigste Teil, ist aber dann doch sehr einfach. Ich kann somit ohne ISP-Programmer eine Firmware in den Controller schreiben. Hier grob noch die nächsten Schritte: * Als erstes ist der Bootloader zu konfigurieren, dann via ISP zu programmieren. * Der ISP-Programmer wegräumen. ;) * Als zweites ist die Firmware zu konfigurieren, dann holt sich der Bootloader unsere Firmware via Netzerk/tftpd. =BOOTLOADER= ==Bootloader bauen== <gallery> File:Putty_bootl_tempmess01.png File:Putty_bootl_tempmess02.png File:Putty_bootl_tempmess03.png File:Putty_bootl_tempmess04.png File:Putty_bootl_tempmess05.png File:Putty_bootl_tempmess06.png File:Putty_bootl_tempmess07.png File:Putty_bootl_tempmess08.png </gallery> Ab nun befinde ich mich auf einem <b>virtuellen Debian Rechner</b> wo ich die Firmware herunterlade und daraus den Bootloader erstelle.<br> <b>WICHTIG:</b> Die IP und MAC-Adresse müssen natürlich verändert werden. Die selbe IP und MAC-Adresse müssen in der Firmware später auch benutzt werden. <br> * Bei einem neuen Debian System müssen mit "apt-get" ein paar Sachen nachinstalliert werden. Hier zu finden [[Preparation_(Deutsch)]] * So eine art DHCP wäre auch möglich, nennt sich [[BOOTP_(Deutsch) | BOOTP]]. Darauf gehe ich hier nicht ein. # cd /home/avr/ # mkdir ethersex_IP_60 // Mein "Arbeitsordner" # cd ethersex_IP_60/ // Ordner für das Board mit der IP 192.168.123.60 # git clone git://github.com/ethersex/ethersex.git // ethersex Firmware herunterladen Cloning into ethersex... remote: Counting objects: 37366, done. remote: Total 37366 (delta 0), reused 0 (delta 0), pack-reused 37366 Receiving objects: 100% (37366/37366), 11.27 MiB | 1.22 MiB/s, done. Resolving deltas: 100% (26538/26538), done. # cp -r ethersex bootloader // Ich kopiere den ethersex Ordner zu dem bootloader Ordner. 1:1 Kopie # cd bootloader/ // In den Bootloader Ordner wechseln # make menuconfig // Einstellungen für Bootloader im nächsten Schritt │ │ Load a Default Configuration ---> │ │ (*) Ethernet Bootloader │ │ General Setup ---> │ │ (ATmega644) Target MCU │ │ (20000000) MCU frequency │ │ [*] Build a bootloader │ │ [*] Teensy build │ │ Network ---> │ │ Hostname: "esex060" // Hostname ändern │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" // MAC ändern mit "Randomize MAC address" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" // Wenn IP nicht vorhanden BOOTP deaktivieren! │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ [ ] BOOTP (DHCP-like) support // BOOTP deaktivieren! │ │ Applications ---> │ │ [*] TFTP support ---> │ │ [*] TFTP-o-matic │ │ TFTP-server IPv4 address: "192.168.123.233" // Server wo TFTPD läuft │ │ TFTP image to load: "esex060.bin" // Diesen Dateinamen ladet später unser Board via Netzwerk/tftpd jetzt noch EXIT und SPEICHERN. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 5902/8192 bytes (72.4%) [=====================---------] Program (.text + .data) : 5902 bytes Data (.data + .bss) : 1902 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.hex</b> ==Bootloader flashen via ISP== <gallery> File:Avrdude tempmess01.png File:Avrdude tempmess02.png File:Avrdude tempmess03.png File:Avrdude tempmess04.png </gallery> Ich flashe hier einfacher weise mit meinem Windows 7 Notebook. Ich habe avrdude einfach unter C:\ liegen. Dort kopiere ich nun die ethersex.hex hin.<br> Somit kann man mit dem flashen den Bootloaders loslegen. avrdude -cusbasp -pm644p -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m // gilt nur für atmega644p und vermutlich auch 644 avrdude -cusbasp -pm644p -U flash:w:ethersex.hex avrdude -cusbasp -pm644p -U lock:w:0x0F:m Der Mikrocontrollerboard ist nun vorbereitet für die eigentliche Firmware. Der ISP-Programmer kann nun bei Seite gelegt werden und wird soweit alles richtig konfiguriert ist auch nicht mehr benötigt.<br> Nun erfolgt das Erstellen der Firmware. =FIRMWARE= ==Firmware bauen== <gallery> File:Putty_c6_m4_tempmess01.png File:Putty_c6_m4_tempmess02.png File:Putty_c6_m4_tempmess03.png </gallery> * <b>WICHTIG:</b> IP, MAC Adresse, Gateway, Netmask, Hostname <b>MUSS</b> gleich sein wie bei dem Bootloader! * Der integrierte Webserver ist in der original Firmware schon aktiviert. ( Applications --> [*] HTTP Server ) # cd /home/avr/ethersex_IP_60/ # cd ethersex/ # make menuconfig │ │ Load a Default Configuration ---> │ │ (*) Etherrape │ │ General Setup ---> │ │ (ATmega644) Target MCU // atmega644p bei mir │ │ (20000000) MCU frequency // 20MHz Quarz │ │ [ ] VFS (Virtual File System) support // Benötige ich hier nicht. │ │ [*] control6 script // Hier wird unsere DS1820 Temperatur in eine Variable geschrieben für den implementieren Webserver. │ │ Network ---> // WICHTIG: IP, MAC Adresse, Gateway, Netmask, Hostname MUSS gleich sein wie bei dem Bootloader! │ │ Hostname: "esex060" │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" │ │ Netmask: "255.255.255.0" │ │ │ │ Default gateway: "192.168.123.10" │ │ I/O ---> │ │ [*] Onewire support ---> // Die allgemeine Onewire Unterstützung. │ │ [*] Onewire device detection support // Automatische Bauteilerkennung In der etherrape.m4 Datei wird nun noch der Pin des atmega geändert wo der DS1820 angeschlossen ist. Im NANO Editor wird mit "STRG-O dann Enter" gespeichert und mit STRG-X beendet. # nano pinning/hardware/etherrape.m4 // editieren der m4 Datei ----- ONEWIRE PIN ändern bei "ONEWIRE_PORT_RANGE(PD6, PD6)" zb. auf PD0 ----- Nun schreiben wir uns ein Script welches den Temperatursensor regelmäßig abfragt und in eine Globale Variable schiebt. # rm control6/control6.src // Original Datei löschen # nano control6/control6.src // Anlegen der c6 Datei. Die Datei ist nun neu und leer. C6_HEADER(`/* This will be in control6.h */') CONTROL_START ECMD_GLOBAL(temp01, 0, uint16_t); THREAD(start) temp01 = ONEWIRE_GET(1054698802080017); WAIT(5) THREAD_END(start) ON STARTUP DO THREAD_START(start) END CONTROL_END Kompilieren der eigentlichen Firmware. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 24072/65536 bytes (36.73%) [===========-------------------] Program (.text + .data) : 24072 bytes Data (.data + .bss) : 2250 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.bin</b> Die eigentliche Firmware ist nun kompiliert und fertig um via Netzwerk/tftpd aufgespielt zu werden. Ich verwende im folgenden Schritt Windows 7. Beschreibung folgt. ==Firmware flashen via TFTPD== Platzhalter, [[User_talk:Djmaster#1 | Todoliste]] 28-01-2016 <gallery> File:Tftpd_tempmess01.png File:Tftpd_tempmess02.png File:Tftpd_tempmess03.png File:Tftpd_tempmess04.png </gallery> [[Category:Tutorials]] 202f5783c5a0e14af33ba3c976813b73324b9744 1640 1637 2016-01-30T16:40:33Z Djmaster 255 wikitext text/x-wiki {{i18n|Temperaturmesssystem}} [[File:Tempmess_pcb_01.jpg|thumb|250px|meine Testplatine, Layout stimmt bis auf Kleinigkeiten überein]] [[File:Tempmess_pcb_02.jpg|thumb|250px|Testplatine beim Programmieren mit avrdude via ISP]] =PROJEKT Temperaturmessung= ===Einleitung=== * ZIEL: Eine einfache Temperaturmessung mit dem [[Onewire_(Deutsch)#Anschluss_AVR-NET-IO | DS1820 im parasitären Modus]]. * ZIEL: Die Ausgabe einer Temperaturvariable via integrierten Webbrowser oder telnet. * ZIEL: Die Firmware muss via Netzwerk neu flashbar sein. * Abgeändertes vereinfachtes [http://www.lochraster.org/etherrape/ etherrape] Board. * Zwei Spannungsregler, ein atmega644p, ein enc28j60, und etwas 0805 Hühnerfutter. ===Schaltung=== Das Layout passt in folgendes Gehäuse. Vorher am besten nochmal genau nachmessen. ;)<br> Conrad Bestell-Nr.: [https://www.conrad.at/de/hutschienen-gehaeuse-90-x-360-x-58-polycarbonat-axxatronic-cnmb-2-kit-con-1-st-531441.html 531441] / Axxatronic CNMB-2-KIT-CON <gallery> File:Sch_tempmess.png File:Pcb_tempmess.png </gallery> * Erstellt mit Eagle Version 7.1.0 für Windows * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_schematic_001.pdf PDF Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_layout_001.pdf PDF Layout gespiegelt] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.sch Eagle Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.brd Eagle Layout] ===Software=== Ethersex (Linux) - https://github.com/ethersex/ethersex Avrdude (Windows) - http://download.savannah.gnu.org/releases/avrdude/ (avrdude-6.1-mingw32.zip) tftpd (Windows) - http://tftpd32.jounin.net/tftpd32_download.html (v4.52 tftpd64 standard edition (zip)) ===Firmware/Bootloader=== Die ethersex Firmware selbst wird für zwei Sachen verwendet. Den <b>Bootloader</b> UND die <b>Firmware</b>. Der Bootloader wird sozusagen einmal in den ersten Bereich des Mikrocontrollers geschrieben und bleibt dort auch. Er wird später die Firmware via Netzwerk entgegennehmen und in den Controller schreiben. Somit befindet sich in den ersten 10% unser Bootloader und in den restlichen 90% der Code den wir wollen. Das zu Verstehen war für mich an Anfang der schwierigste Teil, ist aber dann doch sehr einfach. Ich kann somit ohne ISP-Programmer eine Firmware in den Controller schreiben. Hier grob noch die nächsten Schritte: * Als erstes ist der Bootloader zu konfigurieren, dann via ISP zu programmieren. * Der ISP-Programmer wegräumen. ;) * Als zweites ist die Firmware zu konfigurieren, dann holt sich der Bootloader unsere Firmware via Netzerk/tftpd. =BOOTLOADER= ==Bootloader bauen== <gallery> File:Putty_bootl_tempmess01.png File:Putty_bootl_tempmess02.png File:Putty_bootl_tempmess03.png File:Putty_bootl_tempmess04.png File:Putty_bootl_tempmess05.png File:Putty_bootl_tempmess06.png File:Putty_bootl_tempmess07.png File:Putty_bootl_tempmess08.png </gallery> Ab nun befinde ich mich auf einem <b>virtuellen Debian Rechner</b> wo ich die Firmware herunterlade und daraus den Bootloader erstelle.<br> <b>WICHTIG:</b> Die IP und MAC-Adresse müssen natürlich verändert werden. Die selbe IP und MAC-Adresse müssen in der Firmware später auch benutzt werden. <br> * Bei einem neuen Debian System müssen mit "apt-get" ein paar Sachen nachinstalliert werden. Hier zu finden [[Preparation_(Deutsch)]] * So eine art DHCP wäre auch möglich, nennt sich [[BOOTP_(Deutsch) | BOOTP]]. Darauf gehe ich hier nicht ein. # cd /home/avr/ # mkdir ethersex_IP_60 // Mein "Arbeitsordner" # cd ethersex_IP_60/ // Ordner für das Board mit der IP 192.168.123.60 # git clone git://github.com/ethersex/ethersex.git // ethersex Firmware herunterladen Cloning into ethersex... remote: Counting objects: 37366, done. remote: Total 37366 (delta 0), reused 0 (delta 0), pack-reused 37366 Receiving objects: 100% (37366/37366), 11.27 MiB | 1.22 MiB/s, done. Resolving deltas: 100% (26538/26538), done. # cp -r ethersex bootloader // Ich kopiere den ethersex Ordner zu dem bootloader Ordner. 1:1 Kopie # cd bootloader/ // In den Bootloader Ordner wechseln # make menuconfig // Einstellungen für Bootloader im nächsten Schritt │ │ Load a Default Configuration ---> │ │ (*) Ethernet Bootloader │ │ General Setup ---> │ │ (ATmega644) Target MCU │ │ (20000000) MCU frequency │ │ [*] Build a bootloader │ │ [*] Teensy build │ │ Network ---> │ │ Hostname: "esex060" // Hostname ändern │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" // MAC ändern mit "Randomize MAC address" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" // Wenn IP nicht vorhanden BOOTP deaktivieren! │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ [ ] BOOTP (DHCP-like) support // BOOTP deaktivieren! │ │ Applications ---> │ │ [*] TFTP support ---> │ │ [*] TFTP-o-matic │ │ TFTP-server IPv4 address: "192.168.123.233" // Server wo TFTPD läuft │ │ TFTP image to load: "esex060.bin" // Diesen Dateinamen ladet später unser Board via Netzwerk/tftpd jetzt noch EXIT und SPEICHERN. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 5902/8192 bytes (72.4%) [=====================---------] Program (.text + .data) : 5902 bytes Data (.data + .bss) : 1902 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.hex</b> ==Bootloader flashen via ISP== <gallery> File:Avrdude tempmess01.png File:Avrdude tempmess02.png File:Avrdude tempmess03.png File:Avrdude tempmess04.png </gallery> Ich flashe hier einfacher weise mit meinem Windows 7 Notebook. Ich habe avrdude einfach unter C:\ liegen. Dort kopiere ich nun die ethersex.hex hin.<br> Somit kann man mit dem flashen den Bootloaders loslegen. avrdude -cusbasp -pm644p -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m // gilt nur für atmega644p und vermutlich auch 644 avrdude -cusbasp -pm644p -U flash:w:ethersex.hex avrdude -cusbasp -pm644p -U lock:w:0x0F:m Der Mikrocontrollerboard ist nun vorbereitet für die eigentliche Firmware. Der ISP-Programmer kann nun bei Seite gelegt werden und wird soweit alles richtig konfiguriert ist auch nicht mehr benötigt.<br> Nun erfolgt das Erstellen der Firmware. =FIRMWARE= ==Firmware bauen== <gallery> File:Putty_c6_m4_tempmess01.png File:Putty_c6_m4_tempmess02.png File:Putty_c6_m4_tempmess03.png </gallery> * <b>WICHTIG:</b> IP, MAC Adresse, Gateway, Netmask, Hostname <b>MUSS</b> gleich sein wie bei dem Bootloader! * Der integrierte Webserver ist in der original Firmware schon aktiviert. ( Applications --> [*] HTTP Server ) # cd /home/avr/ethersex_IP_60/ # cd ethersex/ # make menuconfig │ │ Load a Default Configuration ---> │ │ (*) Etherrape │ │ General Setup ---> │ │ (ATmega644) Target MCU // atmega644p bei mir │ │ (20000000) MCU frequency // 20MHz Quarz │ │ [ ] VFS (Virtual File System) support // Benötige ich hier nicht. │ │ [*] control6 script // Hier wird unsere DS1820 Temperatur in eine Variable geschrieben für den implementieren Webserver. │ │ Network ---> // WICHTIG: IP, MAC Adresse, Gateway, Netmask, Hostname MUSS gleich sein wie bei dem Bootloader! │ │ Hostname: "esex060" │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" │ │ Netmask: "255.255.255.0" │ │ │ │ Default gateway: "192.168.123.10" │ │ I/O ---> │ │ [*] Onewire support ---> // Die allgemeine Onewire Unterstützung. │ │ [*] Onewire device detection support // Automatische Bauteilerkennung In der etherrape.m4 Datei wird nun noch der Pin des atmega geändert wo der DS1820 angeschlossen ist. Im NANO Editor wird mit "STRG-O dann Enter" gespeichert und mit STRG-X beendet. # nano pinning/hardware/etherrape.m4 // editieren der m4 Datei ----- ONEWIRE PIN ändern bei "ONEWIRE_PORT_RANGE(PD6, PD6)" zb. auf PD0 ----- Nun schreiben wir uns ein Script welches den Temperatursensor regelmäßig abfragt und in eine Globale Variable schiebt. # rm control6/control6.src // Original Datei löschen # nano control6/control6.src // Anlegen der c6 Datei. Die Datei ist nun neu und leer. C6_HEADER(`/* This will be in control6.h */') CONTROL_START ECMD_GLOBAL(temp01, 0, uint16_t); THREAD(start) temp01 = ONEWIRE_GET(1054698802080017); WAIT(5) THREAD_END(start) ON STARTUP DO THREAD_START(start) END CONTROL_END Kompilieren der eigentlichen Firmware. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 24072/65536 bytes (36.73%) [===========-------------------] Program (.text + .data) : 24072 bytes Data (.data + .bss) : 2250 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.bin</b> Die eigentliche Firmware ist nun kompiliert und fertig um via Netzwerk/tftpd aufgespielt zu werden. Ich verwende im folgenden Schritt Windows 7. Beschreibung folgt. ==Firmware flashen via TFTPD== <gallery> File:Tftpd_tempmess01.png File:Tftpd_tempmess02.png File:Tftpd_tempmess03.png File:Tftpd_tempmess04.png </gallery> Nun ladet ihr euch [http://tftpd32.jounin.net/tftpd32_download.html tftpd] herunter und entpackt es. Ich habe dazu einen Ordner Namens "tftpd" in mein Benutzerverzeichnis "C:\Users\BANANE\tftpd\". Dort wird alles hinein kopiert.<br> Es muss eigentlich nicht viel eingestellt werden. Unter <b>GLOBAL</b> muss TFTP aktiviert sein und unter <b>TFTP</b> sollte das "Base Directory" angepasst werden. Eventuell noch die Bind IP berichtigen. Seht Ihr ja auf den Fotos. Jetzt das Programm noch einmal neu starten. [[User_talk:Djmaster#1 | Todoliste]] [[Category:Tutorials]] 796829ec65a1f2c6d01c0d2f4e8605fc5815660c 1641 1640 2016-01-30T16:53:17Z Djmaster 255 /* Firmware flashen via TFTPD */ wikitext text/x-wiki {{i18n|Temperaturmesssystem}} [[File:Tempmess_pcb_01.jpg|thumb|250px|meine Testplatine, Layout stimmt bis auf Kleinigkeiten überein]] [[File:Tempmess_pcb_02.jpg|thumb|250px|Testplatine beim Programmieren mit avrdude via ISP]] =PROJEKT Temperaturmessung= ===Einleitung=== * ZIEL: Eine einfache Temperaturmessung mit dem [[Onewire_(Deutsch)#Anschluss_AVR-NET-IO | DS1820 im parasitären Modus]]. * ZIEL: Die Ausgabe einer Temperaturvariable via integrierten Webbrowser oder telnet. * ZIEL: Die Firmware muss via Netzwerk neu flashbar sein. * Abgeändertes vereinfachtes [http://www.lochraster.org/etherrape/ etherrape] Board. * Zwei Spannungsregler, ein atmega644p, ein enc28j60, und etwas 0805 Hühnerfutter. ===Schaltung=== Das Layout passt in folgendes Gehäuse. Vorher am besten nochmal genau nachmessen. ;)<br> Conrad Bestell-Nr.: [https://www.conrad.at/de/hutschienen-gehaeuse-90-x-360-x-58-polycarbonat-axxatronic-cnmb-2-kit-con-1-st-531441.html 531441] / Axxatronic CNMB-2-KIT-CON <gallery> File:Sch_tempmess.png File:Pcb_tempmess.png </gallery> * Erstellt mit Eagle Version 7.1.0 für Windows * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_schematic_001.pdf PDF Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_layout_001.pdf PDF Layout gespiegelt] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.sch Eagle Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.brd Eagle Layout] ===Software=== Ethersex (Linux) - https://github.com/ethersex/ethersex Avrdude (Windows) - http://download.savannah.gnu.org/releases/avrdude/ (avrdude-6.1-mingw32.zip) tftpd (Windows) - http://tftpd32.jounin.net/tftpd32_download.html (v4.52 tftpd64 standard edition (zip)) ===Firmware/Bootloader=== Die ethersex Firmware selbst wird für zwei Sachen verwendet. Den <b>Bootloader</b> UND die <b>Firmware</b>. Der Bootloader wird sozusagen einmal in den ersten Bereich des Mikrocontrollers geschrieben und bleibt dort auch. Er wird später die Firmware via Netzwerk entgegennehmen und in den Controller schreiben. Somit befindet sich in den ersten 10% unser Bootloader und in den restlichen 90% der Code den wir wollen. Das zu Verstehen war für mich an Anfang der schwierigste Teil, ist aber dann doch sehr einfach. Ich kann somit ohne ISP-Programmer eine Firmware in den Controller schreiben. Hier grob noch die nächsten Schritte: * Als erstes ist der Bootloader zu konfigurieren, dann via ISP zu programmieren. * Der ISP-Programmer wegräumen. ;) * Als zweites ist die Firmware zu konfigurieren, dann holt sich der Bootloader unsere Firmware via Netzerk/tftpd. =BOOTLOADER= ==Bootloader bauen== <gallery> File:Putty_bootl_tempmess01.png File:Putty_bootl_tempmess02.png File:Putty_bootl_tempmess03.png File:Putty_bootl_tempmess04.png File:Putty_bootl_tempmess05.png File:Putty_bootl_tempmess06.png File:Putty_bootl_tempmess07.png File:Putty_bootl_tempmess08.png </gallery> Ab nun befinde ich mich auf einem <b>virtuellen Debian Rechner</b> wo ich die Firmware herunterlade und daraus den Bootloader erstelle.<br> <b>WICHTIG:</b> Die IP und MAC-Adresse müssen natürlich verändert werden. Die selbe IP und MAC-Adresse müssen in der Firmware später auch benutzt werden. <br> * Bei einem neuen Debian System müssen mit "apt-get" ein paar Sachen nachinstalliert werden. Hier zu finden [[Preparation_(Deutsch)]] * So eine art DHCP wäre auch möglich, nennt sich [[BOOTP_(Deutsch) | BOOTP]]. Darauf gehe ich hier nicht ein. # cd /home/avr/ # mkdir ethersex_IP_60 // Mein "Arbeitsordner" # cd ethersex_IP_60/ // Ordner für das Board mit der IP 192.168.123.60 # git clone git://github.com/ethersex/ethersex.git // ethersex Firmware herunterladen Cloning into ethersex... remote: Counting objects: 37366, done. remote: Total 37366 (delta 0), reused 0 (delta 0), pack-reused 37366 Receiving objects: 100% (37366/37366), 11.27 MiB | 1.22 MiB/s, done. Resolving deltas: 100% (26538/26538), done. # cp -r ethersex bootloader // Ich kopiere den ethersex Ordner zu dem bootloader Ordner. 1:1 Kopie # cd bootloader/ // In den Bootloader Ordner wechseln # make menuconfig // Einstellungen für Bootloader im nächsten Schritt │ │ Load a Default Configuration ---> │ │ (*) Ethernet Bootloader │ │ General Setup ---> │ │ (ATmega644) Target MCU │ │ (20000000) MCU frequency │ │ [*] Build a bootloader │ │ [*] Teensy build │ │ Network ---> │ │ Hostname: "esex060" // Hostname ändern │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" // MAC ändern mit "Randomize MAC address" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" // Wenn IP nicht vorhanden BOOTP deaktivieren! │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ [ ] BOOTP (DHCP-like) support // BOOTP deaktivieren! │ │ Applications ---> │ │ [*] TFTP support ---> │ │ [*] TFTP-o-matic │ │ TFTP-server IPv4 address: "192.168.123.233" // Server wo TFTPD läuft │ │ TFTP image to load: "esex060.bin" // Diesen Dateinamen ladet später unser Board via Netzwerk/tftpd jetzt noch EXIT und SPEICHERN. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 5902/8192 bytes (72.4%) [=====================---------] Program (.text + .data) : 5902 bytes Data (.data + .bss) : 1902 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.hex</b> ==Bootloader flashen via ISP== <gallery> File:Avrdude tempmess01.png File:Avrdude tempmess02.png File:Avrdude tempmess03.png File:Avrdude tempmess04.png </gallery> Ich flashe hier einfacher weise mit meinem Windows 7 Notebook. Ich habe avrdude einfach unter C:\ liegen. Dort kopiere ich nun die ethersex.hex hin.<br> Somit kann man mit dem flashen den Bootloaders loslegen. avrdude -cusbasp -pm644p -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m // gilt nur für atmega644p und vermutlich auch 644 avrdude -cusbasp -pm644p -U flash:w:ethersex.hex avrdude -cusbasp -pm644p -U lock:w:0x0F:m Der Mikrocontrollerboard ist nun vorbereitet für die eigentliche Firmware. Der ISP-Programmer kann nun bei Seite gelegt werden und wird soweit alles richtig konfiguriert ist auch nicht mehr benötigt.<br> Nun erfolgt das Erstellen der Firmware. =FIRMWARE= ==Firmware bauen== <gallery> File:Putty_c6_m4_tempmess01.png File:Putty_c6_m4_tempmess02.png File:Putty_c6_m4_tempmess03.png </gallery> * <b>WICHTIG:</b> IP, MAC Adresse, Gateway, Netmask, Hostname <b>MUSS</b> gleich sein wie bei dem Bootloader! * Der integrierte Webserver ist in der original Firmware schon aktiviert. ( Applications --> [*] HTTP Server ) # cd /home/avr/ethersex_IP_60/ # cd ethersex/ # make menuconfig │ │ Load a Default Configuration ---> │ │ (*) Etherrape │ │ General Setup ---> │ │ (ATmega644) Target MCU // atmega644p bei mir │ │ (20000000) MCU frequency // 20MHz Quarz │ │ [ ] VFS (Virtual File System) support // Benötige ich hier nicht. │ │ [*] control6 script // Hier wird unsere DS1820 Temperatur in eine Variable geschrieben für den implementieren Webserver. │ │ Network ---> // WICHTIG: IP, MAC Adresse, Gateway, Netmask, Hostname MUSS gleich sein wie bei dem Bootloader! │ │ Hostname: "esex060" │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" │ │ Netmask: "255.255.255.0" │ │ │ │ Default gateway: "192.168.123.10" │ │ I/O ---> │ │ [*] Onewire support ---> // Die allgemeine Onewire Unterstützung. │ │ [*] Onewire device detection support // Automatische Bauteilerkennung In der etherrape.m4 Datei wird nun noch der Pin des atmega geändert wo der DS1820 angeschlossen ist. Im NANO Editor wird mit "STRG-O dann Enter" gespeichert und mit STRG-X beendet. # nano pinning/hardware/etherrape.m4 // editieren der m4 Datei ----- ONEWIRE PIN ändern bei "ONEWIRE_PORT_RANGE(PD6, PD6)" zb. auf PD0 ----- Nun schreiben wir uns ein Script welches den Temperatursensor regelmäßig abfragt und in eine Globale Variable schiebt. # rm control6/control6.src // Original Datei löschen # nano control6/control6.src // Anlegen der c6 Datei. Die Datei ist nun neu und leer. C6_HEADER(`/* This will be in control6.h */') CONTROL_START ECMD_GLOBAL(temp01, 0, uint16_t); THREAD(start) temp01 = ONEWIRE_GET(1054698802080017); WAIT(5) THREAD_END(start) ON STARTUP DO THREAD_START(start) END CONTROL_END Kompilieren der eigentlichen Firmware. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 24072/65536 bytes (36.73%) [===========-------------------] Program (.text + .data) : 24072 bytes Data (.data + .bss) : 2250 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.bin</b> Die eigentliche Firmware ist nun kompiliert und fertig um via Netzwerk/tftpd aufgespielt zu werden. Ich verwende im folgenden Schritt Windows 7. Beschreibung folgt. ==Firmware flashen via TFTPD== <gallery> File:Tftpd_tempmess01.png | tftpd Bild 01 File:Tftpd_tempmess02.png File:Tftpd_tempmess03.png File:Tftpd_tempmess04.png </gallery> Nun ladet ihr euch [http://tftpd32.jounin.net/tftpd32_download.html tftpd] herunter und entpackt es. Ich habe dazu einen Ordner Namens "tftpd" in mein Benutzerverzeichnis "C:\Users\BANANE\tftpd\". Dort wird alles hinein kopiert.<br> Es muss eigentlich nicht viel eingestellt werden. Unter <b>GLOBAL</b> muss TFTP aktiviert sein und unter <b>TFTP</b> sollte das "Base Directory" angepasst werden. Eventuell noch die Bind IP berichtigen. Seht Ihr ja auf den Fotos. Jetzt das Programm noch einmal neu starten. * Mikrocontrollerplatine ist <b>abgesteckt</b>. * tftpd starten * die Datei vom vorigen Schritt in den tftpd Ordner kopieren. <b>ethersex.bin</b> * ethersex.bin umbenennen in "<b>esex060.bin</b>". * Mikrocontrollerplatine Einstecken. Jetzt sollte auch schon was passieren. ''- Bei meiner Firewall musste ich tftpd noch akzeptieren. tftpd hing beim ersten mal in einer Schleife.'' <br> ''- Und nochmals via Netzwerk wird die .bin geflasht, nicht die .hex Datei!'' [[User_talk:Djmaster#1 | Todoliste]] [[Category:Tutorials]] c7d8db7bc0984779646239930e958fa35213f939 1642 1641 2016-01-30T16:55:42Z Djmaster 255 /* Firmware flashen via TFTPD */ wikitext text/x-wiki {{i18n|Temperaturmesssystem}} [[File:Tempmess_pcb_01.jpg|thumb|250px|meine Testplatine, Layout stimmt bis auf Kleinigkeiten überein]] [[File:Tempmess_pcb_02.jpg|thumb|250px|Testplatine beim Programmieren mit avrdude via ISP]] =PROJEKT Temperaturmessung= ===Einleitung=== * ZIEL: Eine einfache Temperaturmessung mit dem [[Onewire_(Deutsch)#Anschluss_AVR-NET-IO | DS1820 im parasitären Modus]]. * ZIEL: Die Ausgabe einer Temperaturvariable via integrierten Webbrowser oder telnet. * ZIEL: Die Firmware muss via Netzwerk neu flashbar sein. * Abgeändertes vereinfachtes [http://www.lochraster.org/etherrape/ etherrape] Board. * Zwei Spannungsregler, ein atmega644p, ein enc28j60, und etwas 0805 Hühnerfutter. ===Schaltung=== Das Layout passt in folgendes Gehäuse. Vorher am besten nochmal genau nachmessen. ;)<br> Conrad Bestell-Nr.: [https://www.conrad.at/de/hutschienen-gehaeuse-90-x-360-x-58-polycarbonat-axxatronic-cnmb-2-kit-con-1-st-531441.html 531441] / Axxatronic CNMB-2-KIT-CON <gallery> File:Sch_tempmess.png File:Pcb_tempmess.png </gallery> * Erstellt mit Eagle Version 7.1.0 für Windows * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_schematic_001.pdf PDF Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_layout_001.pdf PDF Layout gespiegelt] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.sch Eagle Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.brd Eagle Layout] ===Software=== Ethersex (Linux) - https://github.com/ethersex/ethersex Avrdude (Windows) - http://download.savannah.gnu.org/releases/avrdude/ (avrdude-6.1-mingw32.zip) tftpd (Windows) - http://tftpd32.jounin.net/tftpd32_download.html (v4.52 tftpd64 standard edition (zip)) ===Firmware/Bootloader=== Die ethersex Firmware selbst wird für zwei Sachen verwendet. Den <b>Bootloader</b> UND die <b>Firmware</b>. Der Bootloader wird sozusagen einmal in den ersten Bereich des Mikrocontrollers geschrieben und bleibt dort auch. Er wird später die Firmware via Netzwerk entgegennehmen und in den Controller schreiben. Somit befindet sich in den ersten 10% unser Bootloader und in den restlichen 90% der Code den wir wollen. Das zu Verstehen war für mich an Anfang der schwierigste Teil, ist aber dann doch sehr einfach. Ich kann somit ohne ISP-Programmer eine Firmware in den Controller schreiben. Hier grob noch die nächsten Schritte: * Als erstes ist der Bootloader zu konfigurieren, dann via ISP zu programmieren. * Der ISP-Programmer wegräumen. ;) * Als zweites ist die Firmware zu konfigurieren, dann holt sich der Bootloader unsere Firmware via Netzerk/tftpd. =BOOTLOADER= ==Bootloader bauen== <gallery> File:Putty_bootl_tempmess01.png File:Putty_bootl_tempmess02.png File:Putty_bootl_tempmess03.png File:Putty_bootl_tempmess04.png File:Putty_bootl_tempmess05.png File:Putty_bootl_tempmess06.png File:Putty_bootl_tempmess07.png File:Putty_bootl_tempmess08.png </gallery> Ab nun befinde ich mich auf einem <b>virtuellen Debian Rechner</b> wo ich die Firmware herunterlade und daraus den Bootloader erstelle.<br> <b>WICHTIG:</b> Die IP und MAC-Adresse müssen natürlich verändert werden. Die selbe IP und MAC-Adresse müssen in der Firmware später auch benutzt werden. <br> * Bei einem neuen Debian System müssen mit "apt-get" ein paar Sachen nachinstalliert werden. Hier zu finden [[Preparation_(Deutsch)]] * So eine art DHCP wäre auch möglich, nennt sich [[BOOTP_(Deutsch) | BOOTP]]. Darauf gehe ich hier nicht ein. # cd /home/avr/ # mkdir ethersex_IP_60 // Mein "Arbeitsordner" # cd ethersex_IP_60/ // Ordner für das Board mit der IP 192.168.123.60 # git clone git://github.com/ethersex/ethersex.git // ethersex Firmware herunterladen Cloning into ethersex... remote: Counting objects: 37366, done. remote: Total 37366 (delta 0), reused 0 (delta 0), pack-reused 37366 Receiving objects: 100% (37366/37366), 11.27 MiB | 1.22 MiB/s, done. Resolving deltas: 100% (26538/26538), done. # cp -r ethersex bootloader // Ich kopiere den ethersex Ordner zu dem bootloader Ordner. 1:1 Kopie # cd bootloader/ // In den Bootloader Ordner wechseln # make menuconfig // Einstellungen für Bootloader im nächsten Schritt │ │ Load a Default Configuration ---> │ │ (*) Ethernet Bootloader │ │ General Setup ---> │ │ (ATmega644) Target MCU │ │ (20000000) MCU frequency │ │ [*] Build a bootloader │ │ [*] Teensy build │ │ Network ---> │ │ Hostname: "esex060" // Hostname ändern │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" // MAC ändern mit "Randomize MAC address" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" // Wenn IP nicht vorhanden BOOTP deaktivieren! │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ [ ] BOOTP (DHCP-like) support // BOOTP deaktivieren! │ │ Applications ---> │ │ [*] TFTP support ---> │ │ [*] TFTP-o-matic │ │ TFTP-server IPv4 address: "192.168.123.233" // Server wo TFTPD läuft │ │ TFTP image to load: "esex060.bin" // Diesen Dateinamen ladet später unser Board via Netzwerk/tftpd jetzt noch EXIT und SPEICHERN. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 5902/8192 bytes (72.4%) [=====================---------] Program (.text + .data) : 5902 bytes Data (.data + .bss) : 1902 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.hex</b> ==Bootloader flashen via ISP== <gallery> File:Avrdude tempmess01.png File:Avrdude tempmess02.png File:Avrdude tempmess03.png File:Avrdude tempmess04.png </gallery> Ich flashe hier einfacher weise mit meinem Windows 7 Notebook. Ich habe avrdude einfach unter C:\ liegen. Dort kopiere ich nun die ethersex.hex hin.<br> Somit kann man mit dem flashen den Bootloaders loslegen. avrdude -cusbasp -pm644p -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m // gilt nur für atmega644p und vermutlich auch 644 avrdude -cusbasp -pm644p -U flash:w:ethersex.hex avrdude -cusbasp -pm644p -U lock:w:0x0F:m Der Mikrocontrollerboard ist nun vorbereitet für die eigentliche Firmware. Der ISP-Programmer kann nun bei Seite gelegt werden und wird soweit alles richtig konfiguriert ist auch nicht mehr benötigt.<br> Nun erfolgt das Erstellen der Firmware. =FIRMWARE= ==Firmware bauen== <gallery> File:Putty_c6_m4_tempmess01.png File:Putty_c6_m4_tempmess02.png File:Putty_c6_m4_tempmess03.png </gallery> * <b>WICHTIG:</b> IP, MAC Adresse, Gateway, Netmask, Hostname <b>MUSS</b> gleich sein wie bei dem Bootloader! * Der integrierte Webserver ist in der original Firmware schon aktiviert. ( Applications --> [*] HTTP Server ) # cd /home/avr/ethersex_IP_60/ # cd ethersex/ # make menuconfig │ │ Load a Default Configuration ---> │ │ (*) Etherrape │ │ General Setup ---> │ │ (ATmega644) Target MCU // atmega644p bei mir │ │ (20000000) MCU frequency // 20MHz Quarz │ │ [ ] VFS (Virtual File System) support // Benötige ich hier nicht. │ │ [*] control6 script // Hier wird unsere DS1820 Temperatur in eine Variable geschrieben für den implementieren Webserver. │ │ Network ---> // WICHTIG: IP, MAC Adresse, Gateway, Netmask, Hostname MUSS gleich sein wie bei dem Bootloader! │ │ Hostname: "esex060" │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" │ │ Netmask: "255.255.255.0" │ │ │ │ Default gateway: "192.168.123.10" │ │ I/O ---> │ │ [*] Onewire support ---> // Die allgemeine Onewire Unterstützung. │ │ [*] Onewire device detection support // Automatische Bauteilerkennung In der etherrape.m4 Datei wird nun noch der Pin des atmega geändert wo der DS1820 angeschlossen ist. Im NANO Editor wird mit "STRG-O dann Enter" gespeichert und mit STRG-X beendet. # nano pinning/hardware/etherrape.m4 // editieren der m4 Datei ----- ONEWIRE PIN ändern bei "ONEWIRE_PORT_RANGE(PD6, PD6)" zb. auf PD0 ----- Nun schreiben wir uns ein Script welches den Temperatursensor regelmäßig abfragt und in eine Globale Variable schiebt. # rm control6/control6.src // Original Datei löschen # nano control6/control6.src // Anlegen der c6 Datei. Die Datei ist nun neu und leer. C6_HEADER(`/* This will be in control6.h */') CONTROL_START ECMD_GLOBAL(temp01, 0, uint16_t); THREAD(start) temp01 = ONEWIRE_GET(1054698802080017); WAIT(5) THREAD_END(start) ON STARTUP DO THREAD_START(start) END CONTROL_END Kompilieren der eigentlichen Firmware. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 24072/65536 bytes (36.73%) [===========-------------------] Program (.text + .data) : 24072 bytes Data (.data + .bss) : 2250 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.bin</b> Die eigentliche Firmware ist nun kompiliert und fertig um via Netzwerk/tftpd aufgespielt zu werden. Ich verwende im folgenden Schritt Windows 7. Beschreibung folgt. ==Firmware flashen via TFTPD== <div><ul> <li style="display: inline-block;"> [[File:Tftpd_tempmess01.png|thumb|none|130px|tftpd Bild 1]] </li> <li style="display: inline-block;"> [[File:Tftpd_tempmess02.png|thumb|none|130px|tftpd Bild 2]] </li> <li style="display: inline-block;"> [[File:Tftpd_tempmess03.png|thumb|none|200px|tftpd Bild 3]] </li> <li style="display: inline-block;"> [[File:Tftpd_tempmess04.png|thumb|none|180px|tftpd Bild 4]] </li> </ul></div> Nun ladet ihr euch [http://tftpd32.jounin.net/tftpd32_download.html tftpd] herunter und entpackt es. Ich habe dazu einen Ordner Namens "tftpd" in mein Benutzerverzeichnis "C:\Users\BANANE\tftpd\". Dort wird alles hinein kopiert.<br> Es muss eigentlich nicht viel eingestellt werden. Unter <b>GLOBAL</b> muss TFTP aktiviert sein und unter <b>TFTP</b> sollte das "Base Directory" angepasst werden. Eventuell noch die Bind IP berichtigen. Seht Ihr ja auf den Fotos. Jetzt das Programm noch einmal neu starten. * Mikrocontrollerplatine ist <b>abgesteckt</b>. * tftpd starten * die Datei vom vorigen Schritt in den tftpd Ordner kopieren. <b>ethersex.bin</b> * ethersex.bin umbenennen in "<b>esex060.bin</b>". * Mikrocontrollerplatine Einstecken. Jetzt sollte auch schon was passieren. ''- Bei meiner Firewall musste ich tftpd noch akzeptieren. tftpd hing beim ersten mal in einer Schleife.'' <br> ''- Und nochmals via Netzwerk wird die .bin geflasht, nicht die .hex Datei!'' [[User_talk:Djmaster#1 | Todoliste]] [[Category:Tutorials]] a7c2b01168445507b6bc61eee36653082478024e 1643 1642 2016-01-30T16:56:14Z Djmaster 255 /* Firmware flashen via TFTPD */ wikitext text/x-wiki {{i18n|Temperaturmesssystem}} [[File:Tempmess_pcb_01.jpg|thumb|250px|meine Testplatine, Layout stimmt bis auf Kleinigkeiten überein]] [[File:Tempmess_pcb_02.jpg|thumb|250px|Testplatine beim Programmieren mit avrdude via ISP]] =PROJEKT Temperaturmessung= ===Einleitung=== * ZIEL: Eine einfache Temperaturmessung mit dem [[Onewire_(Deutsch)#Anschluss_AVR-NET-IO | DS1820 im parasitären Modus]]. * ZIEL: Die Ausgabe einer Temperaturvariable via integrierten Webbrowser oder telnet. * ZIEL: Die Firmware muss via Netzwerk neu flashbar sein. * Abgeändertes vereinfachtes [http://www.lochraster.org/etherrape/ etherrape] Board. * Zwei Spannungsregler, ein atmega644p, ein enc28j60, und etwas 0805 Hühnerfutter. ===Schaltung=== Das Layout passt in folgendes Gehäuse. Vorher am besten nochmal genau nachmessen. ;)<br> Conrad Bestell-Nr.: [https://www.conrad.at/de/hutschienen-gehaeuse-90-x-360-x-58-polycarbonat-axxatronic-cnmb-2-kit-con-1-st-531441.html 531441] / Axxatronic CNMB-2-KIT-CON <gallery> File:Sch_tempmess.png File:Pcb_tempmess.png </gallery> * Erstellt mit Eagle Version 7.1.0 für Windows * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_schematic_001.pdf PDF Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_layout_001.pdf PDF Layout gespiegelt] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.sch Eagle Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.brd Eagle Layout] ===Software=== Ethersex (Linux) - https://github.com/ethersex/ethersex Avrdude (Windows) - http://download.savannah.gnu.org/releases/avrdude/ (avrdude-6.1-mingw32.zip) tftpd (Windows) - http://tftpd32.jounin.net/tftpd32_download.html (v4.52 tftpd64 standard edition (zip)) ===Firmware/Bootloader=== Die ethersex Firmware selbst wird für zwei Sachen verwendet. Den <b>Bootloader</b> UND die <b>Firmware</b>. Der Bootloader wird sozusagen einmal in den ersten Bereich des Mikrocontrollers geschrieben und bleibt dort auch. Er wird später die Firmware via Netzwerk entgegennehmen und in den Controller schreiben. Somit befindet sich in den ersten 10% unser Bootloader und in den restlichen 90% der Code den wir wollen. Das zu Verstehen war für mich an Anfang der schwierigste Teil, ist aber dann doch sehr einfach. Ich kann somit ohne ISP-Programmer eine Firmware in den Controller schreiben. Hier grob noch die nächsten Schritte: * Als erstes ist der Bootloader zu konfigurieren, dann via ISP zu programmieren. * Der ISP-Programmer wegräumen. ;) * Als zweites ist die Firmware zu konfigurieren, dann holt sich der Bootloader unsere Firmware via Netzerk/tftpd. =BOOTLOADER= ==Bootloader bauen== <gallery> File:Putty_bootl_tempmess01.png File:Putty_bootl_tempmess02.png File:Putty_bootl_tempmess03.png File:Putty_bootl_tempmess04.png File:Putty_bootl_tempmess05.png File:Putty_bootl_tempmess06.png File:Putty_bootl_tempmess07.png File:Putty_bootl_tempmess08.png </gallery> Ab nun befinde ich mich auf einem <b>virtuellen Debian Rechner</b> wo ich die Firmware herunterlade und daraus den Bootloader erstelle.<br> <b>WICHTIG:</b> Die IP und MAC-Adresse müssen natürlich verändert werden. Die selbe IP und MAC-Adresse müssen in der Firmware später auch benutzt werden. <br> * Bei einem neuen Debian System müssen mit "apt-get" ein paar Sachen nachinstalliert werden. Hier zu finden [[Preparation_(Deutsch)]] * So eine art DHCP wäre auch möglich, nennt sich [[BOOTP_(Deutsch) | BOOTP]]. Darauf gehe ich hier nicht ein. # cd /home/avr/ # mkdir ethersex_IP_60 // Mein "Arbeitsordner" # cd ethersex_IP_60/ // Ordner für das Board mit der IP 192.168.123.60 # git clone git://github.com/ethersex/ethersex.git // ethersex Firmware herunterladen Cloning into ethersex... remote: Counting objects: 37366, done. remote: Total 37366 (delta 0), reused 0 (delta 0), pack-reused 37366 Receiving objects: 100% (37366/37366), 11.27 MiB | 1.22 MiB/s, done. Resolving deltas: 100% (26538/26538), done. # cp -r ethersex bootloader // Ich kopiere den ethersex Ordner zu dem bootloader Ordner. 1:1 Kopie # cd bootloader/ // In den Bootloader Ordner wechseln # make menuconfig // Einstellungen für Bootloader im nächsten Schritt │ │ Load a Default Configuration ---> │ │ (*) Ethernet Bootloader │ │ General Setup ---> │ │ (ATmega644) Target MCU │ │ (20000000) MCU frequency │ │ [*] Build a bootloader │ │ [*] Teensy build │ │ Network ---> │ │ Hostname: "esex060" // Hostname ändern │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" // MAC ändern mit "Randomize MAC address" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" // Wenn IP nicht vorhanden BOOTP deaktivieren! │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ [ ] BOOTP (DHCP-like) support // BOOTP deaktivieren! │ │ Applications ---> │ │ [*] TFTP support ---> │ │ [*] TFTP-o-matic │ │ TFTP-server IPv4 address: "192.168.123.233" // Server wo TFTPD läuft │ │ TFTP image to load: "esex060.bin" // Diesen Dateinamen ladet später unser Board via Netzwerk/tftpd jetzt noch EXIT und SPEICHERN. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 5902/8192 bytes (72.4%) [=====================---------] Program (.text + .data) : 5902 bytes Data (.data + .bss) : 1902 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.hex</b> ==Bootloader flashen via ISP== <gallery> File:Avrdude tempmess01.png File:Avrdude tempmess02.png File:Avrdude tempmess03.png File:Avrdude tempmess04.png </gallery> Ich flashe hier einfacher weise mit meinem Windows 7 Notebook. Ich habe avrdude einfach unter C:\ liegen. Dort kopiere ich nun die ethersex.hex hin.<br> Somit kann man mit dem flashen den Bootloaders loslegen. avrdude -cusbasp -pm644p -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m // gilt nur für atmega644p und vermutlich auch 644 avrdude -cusbasp -pm644p -U flash:w:ethersex.hex avrdude -cusbasp -pm644p -U lock:w:0x0F:m Der Mikrocontrollerboard ist nun vorbereitet für die eigentliche Firmware. Der ISP-Programmer kann nun bei Seite gelegt werden und wird soweit alles richtig konfiguriert ist auch nicht mehr benötigt.<br> Nun erfolgt das Erstellen der Firmware. =FIRMWARE= ==Firmware bauen== <gallery> File:Putty_c6_m4_tempmess01.png File:Putty_c6_m4_tempmess02.png File:Putty_c6_m4_tempmess03.png </gallery> * <b>WICHTIG:</b> IP, MAC Adresse, Gateway, Netmask, Hostname <b>MUSS</b> gleich sein wie bei dem Bootloader! * Der integrierte Webserver ist in der original Firmware schon aktiviert. ( Applications --> [*] HTTP Server ) # cd /home/avr/ethersex_IP_60/ # cd ethersex/ # make menuconfig │ │ Load a Default Configuration ---> │ │ (*) Etherrape │ │ General Setup ---> │ │ (ATmega644) Target MCU // atmega644p bei mir │ │ (20000000) MCU frequency // 20MHz Quarz │ │ [ ] VFS (Virtual File System) support // Benötige ich hier nicht. │ │ [*] control6 script // Hier wird unsere DS1820 Temperatur in eine Variable geschrieben für den implementieren Webserver. │ │ Network ---> // WICHTIG: IP, MAC Adresse, Gateway, Netmask, Hostname MUSS gleich sein wie bei dem Bootloader! │ │ Hostname: "esex060" │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" │ │ Netmask: "255.255.255.0" │ │ │ │ Default gateway: "192.168.123.10" │ │ I/O ---> │ │ [*] Onewire support ---> // Die allgemeine Onewire Unterstützung. │ │ [*] Onewire device detection support // Automatische Bauteilerkennung In der etherrape.m4 Datei wird nun noch der Pin des atmega geändert wo der DS1820 angeschlossen ist. Im NANO Editor wird mit "STRG-O dann Enter" gespeichert und mit STRG-X beendet. # nano pinning/hardware/etherrape.m4 // editieren der m4 Datei ----- ONEWIRE PIN ändern bei "ONEWIRE_PORT_RANGE(PD6, PD6)" zb. auf PD0 ----- Nun schreiben wir uns ein Script welches den Temperatursensor regelmäßig abfragt und in eine Globale Variable schiebt. # rm control6/control6.src // Original Datei löschen # nano control6/control6.src // Anlegen der c6 Datei. Die Datei ist nun neu und leer. C6_HEADER(`/* This will be in control6.h */') CONTROL_START ECMD_GLOBAL(temp01, 0, uint16_t); THREAD(start) temp01 = ONEWIRE_GET(1054698802080017); WAIT(5) THREAD_END(start) ON STARTUP DO THREAD_START(start) END CONTROL_END Kompilieren der eigentlichen Firmware. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 24072/65536 bytes (36.73%) [===========-------------------] Program (.text + .data) : 24072 bytes Data (.data + .bss) : 2250 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.bin</b> Die eigentliche Firmware ist nun kompiliert und fertig um via Netzwerk/tftpd aufgespielt zu werden. Ich verwende im folgenden Schritt Windows 7. Beschreibung folgt. ==Firmware flashen via TFTPD== <div><ul> <li style="display: inline-block;"> [[File:Tftpd_tempmess01.png|thumb|none|130px|tftpd Bild 1]] </li> <li style="display: inline-block;"> [[File:Tftpd_tempmess02.png|thumb|none|130px|tftpd Bild 2]] </li> <li style="display: inline-block;"> [[File:Tftpd_tempmess03.png|thumb|none|200px|tftpd Bild 3]] </li> <li style="display: inline-block;"> [[File:Tftpd_tempmess04.png|thumb|none|180px|tftpd Bild 4]] </li> </ul></div> Nun ladet ihr euch [http://tftpd32.jounin.net/tftpd32_download.html tftpd] herunter und entpackt es. Ich habe dazu einen Ordner Namens "tftpd" in mein Benutzerverzeichnis "C:\Users\BANANE\tftpd\". Dort wird alles hinein kopiert.<br> Es muss eigentlich nicht viel eingestellt werden. Unter <b>GLOBAL</b> muss TFTP aktiviert sein und unter <b>TFTP</b> sollte das "Base Directory" angepasst werden. Eventuell noch die Bind IP berichtigen. Seht Ihr ja auf den Fotos. Jetzt das Programm noch einmal neu starten. * Mikrocontrollerplatine ist <b>abgesteckt</b>. * tftpd starten * die Datei vom vorigen Schritt in den tftpd Ordner kopieren. <b>ethersex.bin</b> * ethersex.bin umbenennen in "<b>esex060.bin</b>". * Mikrocontrollerplatine Einstecken. Jetzt sollte auch schon was passieren, wie auf Bild 4 zu sehen ist. ''- Bei meiner Firewall musste ich tftpd noch akzeptieren. tftpd hing beim ersten mal in einer Schleife.'' <br> ''- Und nochmals via Netzwerk wird die .bin geflasht, nicht die .hex Datei!'' [[User_talk:Djmaster#1 | Todoliste]] [[Category:Tutorials]] 04ba14b47227c79ab1c25dc85bbc6988d980a150 1644 1643 2016-01-30T16:57:18Z Djmaster 255 /* Bootloader bauen */ wikitext text/x-wiki {{i18n|Temperaturmesssystem}} [[File:Tempmess_pcb_01.jpg|thumb|250px|meine Testplatine, Layout stimmt bis auf Kleinigkeiten überein]] [[File:Tempmess_pcb_02.jpg|thumb|250px|Testplatine beim Programmieren mit avrdude via ISP]] =PROJEKT Temperaturmessung= ===Einleitung=== * ZIEL: Eine einfache Temperaturmessung mit dem [[Onewire_(Deutsch)#Anschluss_AVR-NET-IO | DS1820 im parasitären Modus]]. * ZIEL: Die Ausgabe einer Temperaturvariable via integrierten Webbrowser oder telnet. * ZIEL: Die Firmware muss via Netzwerk neu flashbar sein. * Abgeändertes vereinfachtes [http://www.lochraster.org/etherrape/ etherrape] Board. * Zwei Spannungsregler, ein atmega644p, ein enc28j60, und etwas 0805 Hühnerfutter. ===Schaltung=== Das Layout passt in folgendes Gehäuse. Vorher am besten nochmal genau nachmessen. ;)<br> Conrad Bestell-Nr.: [https://www.conrad.at/de/hutschienen-gehaeuse-90-x-360-x-58-polycarbonat-axxatronic-cnmb-2-kit-con-1-st-531441.html 531441] / Axxatronic CNMB-2-KIT-CON <gallery> File:Sch_tempmess.png File:Pcb_tempmess.png </gallery> * Erstellt mit Eagle Version 7.1.0 für Windows * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_schematic_001.pdf PDF Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_layout_001.pdf PDF Layout gespiegelt] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.sch Eagle Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.brd Eagle Layout] ===Software=== Ethersex (Linux) - https://github.com/ethersex/ethersex Avrdude (Windows) - http://download.savannah.gnu.org/releases/avrdude/ (avrdude-6.1-mingw32.zip) tftpd (Windows) - http://tftpd32.jounin.net/tftpd32_download.html (v4.52 tftpd64 standard edition (zip)) ===Firmware/Bootloader=== Die ethersex Firmware selbst wird für zwei Sachen verwendet. Den <b>Bootloader</b> UND die <b>Firmware</b>. Der Bootloader wird sozusagen einmal in den ersten Bereich des Mikrocontrollers geschrieben und bleibt dort auch. Er wird später die Firmware via Netzwerk entgegennehmen und in den Controller schreiben. Somit befindet sich in den ersten 10% unser Bootloader und in den restlichen 90% der Code den wir wollen. Das zu Verstehen war für mich an Anfang der schwierigste Teil, ist aber dann doch sehr einfach. Ich kann somit ohne ISP-Programmer eine Firmware in den Controller schreiben. Hier grob noch die nächsten Schritte: * Als erstes ist der Bootloader zu konfigurieren, dann via ISP zu programmieren. * Der ISP-Programmer wegräumen. ;) * Als zweites ist die Firmware zu konfigurieren, dann holt sich der Bootloader unsere Firmware via Netzerk/tftpd. =BOOTLOADER= ==Bootloader bauen== <gallery> File:Putty_bootl_tempmess01.png File:Putty_bootl_tempmess02.png File:Putty_bootl_tempmess03.png File:Putty_bootl_tempmess04.png File:Putty_bootl_tempmess05.png File:Putty_bootl_tempmess06.png File:Putty_bootl_tempmess07.png File:Putty_bootl_tempmess08.png </gallery> Ab nun befinde ich mich auf einem <b>virtuellen Debian Rechner</b> wo ich die Firmware herunterlade und daraus den Bootloader erstelle.<br> <b>WICHTIG:</b> Die IP und MAC-Adresse müssen natürlich verändert werden. Die selbe IP und MAC-Adresse müssen in der Firmware später auch benutzt werden. <br> * Bei einem neuen Debian System müssen mit "apt-get" ein paar Sachen nachinstalliert werden. Hier zu finden [[Preparation_(Deutsch)]] * So eine art DHCP wäre auch möglich, nennt sich [[BOOTP_(Deutsch) | BOOTP]]. Darauf gehe ich hier nicht ein. # cd /home/avr/ # mkdir ethersex_IP_60 // Mein "Arbeitsordner" # cd ethersex_IP_60/ // Ordner für das Board mit der IP 192.168.123.60 # git clone git://github.com/ethersex/ethersex.git // ethersex Firmware herunterladen Cloning into ethersex... remote: Counting objects: 37366, done. remote: Total 37366 (delta 0), reused 0 (delta 0), pack-reused 37366 Receiving objects: 100% (37366/37366), 11.27 MiB | 1.22 MiB/s, done. Resolving deltas: 100% (26538/26538), done. # cp -r ethersex bootloader // Ich kopiere den ethersex Ordner zu dem bootloader Ordner. 1:1 Kopie # cd bootloader/ // In den Bootloader Ordner wechseln # make menuconfig // Einstellungen für Bootloader im nächsten Schritt │ │ Load a Default Configuration ---> │ │ (*) Ethernet Bootloader │ │ General Setup ---> │ │ (ATmega644) Target MCU │ │ (20000000) MCU frequency │ │ [*] Build a bootloader │ │ [*] Teensy build │ │ Network ---> │ │ Hostname: "esex060" // Hostname ändern │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" // MAC ändern mit "Randomize MAC address" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" // Wenn IP nicht vorhanden BOOTP deaktivieren! │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ [ ] BOOTP (DHCP-like) support // BOOTP deaktivieren! │ │ Applications ---> │ │ [*] TFTP support ---> │ │ [*] TFTP-o-matic │ │ TFTP-server IPv4 address: "192.168.123.233" // Server wo TFTPD läuft │ │ TFTP image to load: "esex060.bin" // Diesen Dateinamen ladet später unser Board via Netzwerk/tftpd jetzt noch EXIT und SPEICHERN. # make clean && make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 5902/8192 bytes (72.4%) [=====================---------] Program (.text + .data) : 5902 bytes Data (.data + .bss) : 1902 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.hex</b> ==Bootloader flashen via ISP== <gallery> File:Avrdude tempmess01.png File:Avrdude tempmess02.png File:Avrdude tempmess03.png File:Avrdude tempmess04.png </gallery> Ich flashe hier einfacher weise mit meinem Windows 7 Notebook. Ich habe avrdude einfach unter C:\ liegen. Dort kopiere ich nun die ethersex.hex hin.<br> Somit kann man mit dem flashen den Bootloaders loslegen. avrdude -cusbasp -pm644p -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m // gilt nur für atmega644p und vermutlich auch 644 avrdude -cusbasp -pm644p -U flash:w:ethersex.hex avrdude -cusbasp -pm644p -U lock:w:0x0F:m Der Mikrocontrollerboard ist nun vorbereitet für die eigentliche Firmware. Der ISP-Programmer kann nun bei Seite gelegt werden und wird soweit alles richtig konfiguriert ist auch nicht mehr benötigt.<br> Nun erfolgt das Erstellen der Firmware. =FIRMWARE= ==Firmware bauen== <gallery> File:Putty_c6_m4_tempmess01.png File:Putty_c6_m4_tempmess02.png File:Putty_c6_m4_tempmess03.png </gallery> * <b>WICHTIG:</b> IP, MAC Adresse, Gateway, Netmask, Hostname <b>MUSS</b> gleich sein wie bei dem Bootloader! * Der integrierte Webserver ist in der original Firmware schon aktiviert. ( Applications --> [*] HTTP Server ) # cd /home/avr/ethersex_IP_60/ # cd ethersex/ # make menuconfig │ │ Load a Default Configuration ---> │ │ (*) Etherrape │ │ General Setup ---> │ │ (ATmega644) Target MCU // atmega644p bei mir │ │ (20000000) MCU frequency // 20MHz Quarz │ │ [ ] VFS (Virtual File System) support // Benötige ich hier nicht. │ │ [*] control6 script // Hier wird unsere DS1820 Temperatur in eine Variable geschrieben für den implementieren Webserver. │ │ Network ---> // WICHTIG: IP, MAC Adresse, Gateway, Netmask, Hostname MUSS gleich sein wie bei dem Bootloader! │ │ Hostname: "esex060" │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" │ │ Netmask: "255.255.255.0" │ │ │ │ Default gateway: "192.168.123.10" │ │ I/O ---> │ │ [*] Onewire support ---> // Die allgemeine Onewire Unterstützung. │ │ [*] Onewire device detection support // Automatische Bauteilerkennung In der etherrape.m4 Datei wird nun noch der Pin des atmega geändert wo der DS1820 angeschlossen ist. Im NANO Editor wird mit "STRG-O dann Enter" gespeichert und mit STRG-X beendet. # nano pinning/hardware/etherrape.m4 // editieren der m4 Datei ----- ONEWIRE PIN ändern bei "ONEWIRE_PORT_RANGE(PD6, PD6)" zb. auf PD0 ----- Nun schreiben wir uns ein Script welches den Temperatursensor regelmäßig abfragt und in eine Globale Variable schiebt. # rm control6/control6.src // Original Datei löschen # nano control6/control6.src // Anlegen der c6 Datei. Die Datei ist nun neu und leer. C6_HEADER(`/* This will be in control6.h */') CONTROL_START ECMD_GLOBAL(temp01, 0, uint16_t); THREAD(start) temp01 = ONEWIRE_GET(1054698802080017); WAIT(5) THREAD_END(start) ON STARTUP DO THREAD_START(start) END CONTROL_END Kompilieren der eigentlichen Firmware. # make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 24072/65536 bytes (36.73%) [===========-------------------] Program (.text + .data) : 24072 bytes Data (.data + .bss) : 2250 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.bin</b> Die eigentliche Firmware ist nun kompiliert und fertig um via Netzwerk/tftpd aufgespielt zu werden. Ich verwende im folgenden Schritt Windows 7. Beschreibung folgt. ==Firmware flashen via TFTPD== <div><ul> <li style="display: inline-block;"> [[File:Tftpd_tempmess01.png|thumb|none|130px|tftpd Bild 1]] </li> <li style="display: inline-block;"> [[File:Tftpd_tempmess02.png|thumb|none|130px|tftpd Bild 2]] </li> <li style="display: inline-block;"> [[File:Tftpd_tempmess03.png|thumb|none|200px|tftpd Bild 3]] </li> <li style="display: inline-block;"> [[File:Tftpd_tempmess04.png|thumb|none|180px|tftpd Bild 4]] </li> </ul></div> Nun ladet ihr euch [http://tftpd32.jounin.net/tftpd32_download.html tftpd] herunter und entpackt es. Ich habe dazu einen Ordner Namens "tftpd" in mein Benutzerverzeichnis "C:\Users\BANANE\tftpd\". Dort wird alles hinein kopiert.<br> Es muss eigentlich nicht viel eingestellt werden. Unter <b>GLOBAL</b> muss TFTP aktiviert sein und unter <b>TFTP</b> sollte das "Base Directory" angepasst werden. Eventuell noch die Bind IP berichtigen. Seht Ihr ja auf den Fotos. Jetzt das Programm noch einmal neu starten. * Mikrocontrollerplatine ist <b>abgesteckt</b>. * tftpd starten * die Datei vom vorigen Schritt in den tftpd Ordner kopieren. <b>ethersex.bin</b> * ethersex.bin umbenennen in "<b>esex060.bin</b>". * Mikrocontrollerplatine Einstecken. Jetzt sollte auch schon was passieren, wie auf Bild 4 zu sehen ist. ''- Bei meiner Firewall musste ich tftpd noch akzeptieren. tftpd hing beim ersten mal in einer Schleife.'' <br> ''- Und nochmals via Netzwerk wird die .bin geflasht, nicht die .hex Datei!'' [[User_talk:Djmaster#1 | Todoliste]] [[Category:Tutorials]] 2100d18a48eb9ffeae59ca4f9c9cecd9939173bb 1645 1644 2016-01-30T16:58:27Z Djmaster 255 /* Firmware bauen */ wikitext text/x-wiki {{i18n|Temperaturmesssystem}} [[File:Tempmess_pcb_01.jpg|thumb|250px|meine Testplatine, Layout stimmt bis auf Kleinigkeiten überein]] [[File:Tempmess_pcb_02.jpg|thumb|250px|Testplatine beim Programmieren mit avrdude via ISP]] =PROJEKT Temperaturmessung= ===Einleitung=== * ZIEL: Eine einfache Temperaturmessung mit dem [[Onewire_(Deutsch)#Anschluss_AVR-NET-IO | DS1820 im parasitären Modus]]. * ZIEL: Die Ausgabe einer Temperaturvariable via integrierten Webbrowser oder telnet. * ZIEL: Die Firmware muss via Netzwerk neu flashbar sein. * Abgeändertes vereinfachtes [http://www.lochraster.org/etherrape/ etherrape] Board. * Zwei Spannungsregler, ein atmega644p, ein enc28j60, und etwas 0805 Hühnerfutter. ===Schaltung=== Das Layout passt in folgendes Gehäuse. Vorher am besten nochmal genau nachmessen. ;)<br> Conrad Bestell-Nr.: [https://www.conrad.at/de/hutschienen-gehaeuse-90-x-360-x-58-polycarbonat-axxatronic-cnmb-2-kit-con-1-st-531441.html 531441] / Axxatronic CNMB-2-KIT-CON <gallery> File:Sch_tempmess.png File:Pcb_tempmess.png </gallery> * Erstellt mit Eagle Version 7.1.0 für Windows * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_schematic_001.pdf PDF Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_layout_001.pdf PDF Layout gespiegelt] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.sch Eagle Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.brd Eagle Layout] ===Software=== Ethersex (Linux) - https://github.com/ethersex/ethersex Avrdude (Windows) - http://download.savannah.gnu.org/releases/avrdude/ (avrdude-6.1-mingw32.zip) tftpd (Windows) - http://tftpd32.jounin.net/tftpd32_download.html (v4.52 tftpd64 standard edition (zip)) ===Firmware/Bootloader=== Die ethersex Firmware selbst wird für zwei Sachen verwendet. Den <b>Bootloader</b> UND die <b>Firmware</b>. Der Bootloader wird sozusagen einmal in den ersten Bereich des Mikrocontrollers geschrieben und bleibt dort auch. Er wird später die Firmware via Netzwerk entgegennehmen und in den Controller schreiben. Somit befindet sich in den ersten 10% unser Bootloader und in den restlichen 90% der Code den wir wollen. Das zu Verstehen war für mich an Anfang der schwierigste Teil, ist aber dann doch sehr einfach. Ich kann somit ohne ISP-Programmer eine Firmware in den Controller schreiben. Hier grob noch die nächsten Schritte: * Als erstes ist der Bootloader zu konfigurieren, dann via ISP zu programmieren. * Der ISP-Programmer wegräumen. ;) * Als zweites ist die Firmware zu konfigurieren, dann holt sich der Bootloader unsere Firmware via Netzerk/tftpd. =BOOTLOADER= ==Bootloader bauen== <gallery> File:Putty_bootl_tempmess01.png File:Putty_bootl_tempmess02.png File:Putty_bootl_tempmess03.png File:Putty_bootl_tempmess04.png File:Putty_bootl_tempmess05.png File:Putty_bootl_tempmess06.png File:Putty_bootl_tempmess07.png File:Putty_bootl_tempmess08.png </gallery> Ab nun befinde ich mich auf einem <b>virtuellen Debian Rechner</b> wo ich die Firmware herunterlade und daraus den Bootloader erstelle.<br> <b>WICHTIG:</b> Die IP und MAC-Adresse müssen natürlich verändert werden. Die selbe IP und MAC-Adresse müssen in der Firmware später auch benutzt werden. <br> * Bei einem neuen Debian System müssen mit "apt-get" ein paar Sachen nachinstalliert werden. Hier zu finden [[Preparation_(Deutsch)]] * So eine art DHCP wäre auch möglich, nennt sich [[BOOTP_(Deutsch) | BOOTP]]. Darauf gehe ich hier nicht ein. # cd /home/avr/ # mkdir ethersex_IP_60 // Mein "Arbeitsordner" # cd ethersex_IP_60/ // Ordner für das Board mit der IP 192.168.123.60 # git clone git://github.com/ethersex/ethersex.git // ethersex Firmware herunterladen Cloning into ethersex... remote: Counting objects: 37366, done. remote: Total 37366 (delta 0), reused 0 (delta 0), pack-reused 37366 Receiving objects: 100% (37366/37366), 11.27 MiB | 1.22 MiB/s, done. Resolving deltas: 100% (26538/26538), done. # cp -r ethersex bootloader // Ich kopiere den ethersex Ordner zu dem bootloader Ordner. 1:1 Kopie # cd bootloader/ // In den Bootloader Ordner wechseln # make menuconfig // Einstellungen für Bootloader im nächsten Schritt │ │ Load a Default Configuration ---> │ │ (*) Ethernet Bootloader │ │ General Setup ---> │ │ (ATmega644) Target MCU │ │ (20000000) MCU frequency │ │ [*] Build a bootloader │ │ [*] Teensy build │ │ Network ---> │ │ Hostname: "esex060" // Hostname ändern │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" // MAC ändern mit "Randomize MAC address" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" // Wenn IP nicht vorhanden BOOTP deaktivieren! │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ [ ] BOOTP (DHCP-like) support // BOOTP deaktivieren! │ │ Applications ---> │ │ [*] TFTP support ---> │ │ [*] TFTP-o-matic │ │ TFTP-server IPv4 address: "192.168.123.233" // Server wo TFTPD läuft │ │ TFTP image to load: "esex060.bin" // Diesen Dateinamen ladet später unser Board via Netzwerk/tftpd jetzt noch EXIT und SPEICHERN. # make clean && make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 5902/8192 bytes (72.4%) [=====================---------] Program (.text + .data) : 5902 bytes Data (.data + .bss) : 1902 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.hex</b> ==Bootloader flashen via ISP== <gallery> File:Avrdude tempmess01.png File:Avrdude tempmess02.png File:Avrdude tempmess03.png File:Avrdude tempmess04.png </gallery> Ich flashe hier einfacher weise mit meinem Windows 7 Notebook. Ich habe avrdude einfach unter C:\ liegen. Dort kopiere ich nun die ethersex.hex hin.<br> Somit kann man mit dem flashen den Bootloaders loslegen. avrdude -cusbasp -pm644p -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m // gilt nur für atmega644p und vermutlich auch 644 avrdude -cusbasp -pm644p -U flash:w:ethersex.hex avrdude -cusbasp -pm644p -U lock:w:0x0F:m Der Mikrocontrollerboard ist nun vorbereitet für die eigentliche Firmware. Der ISP-Programmer kann nun bei Seite gelegt werden und wird soweit alles richtig konfiguriert ist auch nicht mehr benötigt.<br> Nun erfolgt das Erstellen der Firmware. =FIRMWARE= ==Firmware bauen== <gallery> File:Putty_c6_m4_tempmess01.png File:Putty_c6_m4_tempmess02.png File:Putty_c6_m4_tempmess03.png </gallery> * <b>WICHTIG:</b> IP, MAC Adresse, Gateway, Netmask, Hostname <b>MUSS</b> gleich sein wie bei dem Bootloader! * Der integrierte Webserver ist in der original Firmware schon aktiviert. ( Applications --> [*] HTTP Server ) # cd /home/avr/ethersex_IP_60/ # cd ethersex/ # make menuconfig │ │ Load a Default Configuration ---> │ │ (*) Etherrape │ │ General Setup ---> │ │ (ATmega644) Target MCU // atmega644p bei mir │ │ (20000000) MCU frequency // 20MHz Quarz │ │ [ ] VFS (Virtual File System) support // Benötige ich hier nicht. │ │ [*] control6 script // Hier wird unsere DS1820 Temperatur in eine Variable geschrieben für den implementieren Webserver. │ │ Network ---> // WICHTIG: IP, MAC Adresse, Gateway, Netmask, Hostname MUSS gleich sein wie bei dem Bootloader! │ │ Hostname: "esex060" │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" │ │ Netmask: "255.255.255.0" │ │ │ │ Default gateway: "192.168.123.10" │ │ I/O ---> │ │ [*] Onewire support ---> // Die allgemeine Onewire Unterstützung. │ │ [*] Onewire device detection support // Automatische Bauteilerkennung In der etherrape.m4 Datei wird nun noch der Pin des atmega geändert wo der DS1820 angeschlossen ist. Im NANO Editor wird mit "STRG-O dann Enter" gespeichert und mit STRG-X beendet. # nano pinning/hardware/etherrape.m4 // editieren der m4 Datei ----- ONEWIRE PIN ändern bei "ONEWIRE_PORT_RANGE(PD6, PD6)" zb. auf PD0 ----- Nun schreiben wir uns ein Script welches den Temperatursensor regelmäßig abfragt und in eine Globale Variable schiebt. # rm control6/control6.src // Original Datei löschen # nano control6/control6.src // Anlegen der c6 Datei. Die Datei ist nun neu und leer. C6_HEADER(`/* This will be in control6.h */') CONTROL_START ECMD_GLOBAL(temp01, 0, uint16_t); THREAD(start) temp01 = ONEWIRE_GET(1054698802080017); WAIT(5) THREAD_END(start) ON STARTUP DO THREAD_START(start) END CONTROL_END Kompilieren der eigentlichen Firmware. # make clean && make // Befehl zum bereinigen & kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 24072/65536 bytes (36.73%) [===========-------------------] Program (.text + .data) : 24072 bytes Data (.data + .bss) : 2250 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.bin</b> Die eigentliche Firmware ist nun kompiliert und fertig um via Netzwerk/tftpd aufgespielt zu werden. Ich verwende im folgenden Schritt Windows 7. Beschreibung im nächsten Schritt. ==Firmware flashen via TFTPD== <div><ul> <li style="display: inline-block;"> [[File:Tftpd_tempmess01.png|thumb|none|130px|tftpd Bild 1]] </li> <li style="display: inline-block;"> [[File:Tftpd_tempmess02.png|thumb|none|130px|tftpd Bild 2]] </li> <li style="display: inline-block;"> [[File:Tftpd_tempmess03.png|thumb|none|200px|tftpd Bild 3]] </li> <li style="display: inline-block;"> [[File:Tftpd_tempmess04.png|thumb|none|180px|tftpd Bild 4]] </li> </ul></div> Nun ladet ihr euch [http://tftpd32.jounin.net/tftpd32_download.html tftpd] herunter und entpackt es. Ich habe dazu einen Ordner Namens "tftpd" in mein Benutzerverzeichnis "C:\Users\BANANE\tftpd\". Dort wird alles hinein kopiert.<br> Es muss eigentlich nicht viel eingestellt werden. Unter <b>GLOBAL</b> muss TFTP aktiviert sein und unter <b>TFTP</b> sollte das "Base Directory" angepasst werden. Eventuell noch die Bind IP berichtigen. Seht Ihr ja auf den Fotos. Jetzt das Programm noch einmal neu starten. * Mikrocontrollerplatine ist <b>abgesteckt</b>. * tftpd starten * die Datei vom vorigen Schritt in den tftpd Ordner kopieren. <b>ethersex.bin</b> * ethersex.bin umbenennen in "<b>esex060.bin</b>". * Mikrocontrollerplatine Einstecken. Jetzt sollte auch schon was passieren, wie auf Bild 4 zu sehen ist. ''- Bei meiner Firewall musste ich tftpd noch akzeptieren. tftpd hing beim ersten mal in einer Schleife.'' <br> ''- Und nochmals via Netzwerk wird die .bin geflasht, nicht die .hex Datei!'' [[User_talk:Djmaster#1 | Todoliste]] [[Category:Tutorials]] 80de1564af6aaa5895dff2a13c27bb92cb6c40d4 1646 1645 2016-01-30T17:09:28Z Djmaster 255 wikitext text/x-wiki {{i18n|Temperaturmesssystem}} [[File:Tempmess_pcb_01.jpg|thumb|250px|meine Testplatine, Layout stimmt bis auf Kleinigkeiten überein]] [[File:Tempmess_pcb_02.jpg|thumb|250px|Testplatine beim Programmieren mit avrdude via ISP]] =PROJEKT Temperaturmessung= ===Einleitung=== * ZIEL: Eine einfache Temperaturmessung mit dem [[Onewire_(Deutsch)#Anschluss_AVR-NET-IO | DS1820 im parasitären Modus]]. * ZIEL: Die Ausgabe einer Temperaturvariable via integrierten Webbrowser oder telnet. * ZIEL: Die Firmware muss via Netzwerk neu flashbar sein. * Abgeändertes vereinfachtes [http://www.lochraster.org/etherrape/ etherrape] Board. * Zwei Spannungsregler, ein atmega644p, ein enc28j60, und etwas 0805 Hühnerfutter. ===Schaltung=== Das Layout passt in folgendes Gehäuse. Vorher am besten nochmal genau nachmessen. ;)<br> Conrad Bestell-Nr.: [https://www.conrad.at/de/hutschienen-gehaeuse-90-x-360-x-58-polycarbonat-axxatronic-cnmb-2-kit-con-1-st-531441.html 531441] / Axxatronic CNMB-2-KIT-CON <div><ul> <li style="display: inline-block;"> [[File:Sch_tempmess.png|thumb|none|210px|Schaltung]] </li> <li style="display: inline-block;"> [[File:Pcb_tempmess.png|thumb|none|280px|Layout]] </li> </ul></div> * Erstellt mit Eagle Version 7.1.0 für Windows * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_schematic_001.pdf PDF Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_layout_001.pdf PDF Layout gespiegelt] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.sch Eagle Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.brd Eagle Layout] ===Software=== Ethersex (Linux) - https://github.com/ethersex/ethersex Avrdude (Windows) - http://download.savannah.gnu.org/releases/avrdude/ (avrdude-6.1-mingw32.zip) tftpd (Windows) - http://tftpd32.jounin.net/tftpd32_download.html (v4.52 tftpd64 standard edition (zip)) ===Firmware/Bootloader=== Die ethersex Firmware selbst wird für zwei Sachen verwendet. Den <b>Bootloader</b> UND die <b>Firmware</b>. Der Bootloader wird sozusagen einmal in den ersten Bereich des Mikrocontrollers geschrieben und bleibt dort auch. Er wird später die Firmware via Netzwerk entgegennehmen und in den Controller schreiben. Somit befindet sich in den ersten 10% unser Bootloader und in den restlichen 90% der Code den wir wollen. Das zu Verstehen war für mich an Anfang der schwierigste Teil, ist aber dann doch sehr einfach. Ich kann somit ohne ISP-Programmer eine Firmware in den Controller schreiben. Hier grob noch die nächsten Schritte: * Als erstes ist der Bootloader zu konfigurieren, dann via ISP zu programmieren. * Der ISP-Programmer wegräumen. ;) * Als zweites ist die Firmware zu konfigurieren, dann holt sich der Bootloader unsere Firmware via Netzerk/tftpd. =BOOTLOADER= ===Bootloader bauen=== <div><ul> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess01.png|thumb|none|200px|Putty Bild 1]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess02.png|thumb|none|200px|Putty Bild 2]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess03.png|thumb|none|200px|Putty Bild 3]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess04.png|thumb|none|200px|Putty Bild 4]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess05.png|thumb|none|200px|Putty Bild 5]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess06.png|thumb|none|200px|Putty Bild 6]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess07.png|thumb|none|200px|Putty Bild 7]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess08.png|thumb|none|200px|Putty Bild 8]] </li> </ul></div> Ab nun befinde ich mich auf einem <b>virtuellen Debian Rechner</b> wo ich die Firmware herunterlade und daraus den Bootloader erstelle.<br> <b>WICHTIG:</b> Die IP und MAC-Adresse müssen natürlich verändert werden. Die selbe IP und MAC-Adresse müssen in der Firmware später auch benutzt werden. <br> * Bei einem neuen Debian System müssen mit "apt-get" ein paar Sachen nachinstalliert werden. Hier zu finden [[Preparation_(Deutsch)]] * So eine art DHCP wäre auch möglich, nennt sich [[BOOTP_(Deutsch) | BOOTP]]. Darauf gehe ich hier nicht ein. # cd /home/avr/ # mkdir ethersex_IP_60 // Mein "Arbeitsordner" # cd ethersex_IP_60/ // Ordner für das Board mit der IP 192.168.123.60 # git clone git://github.com/ethersex/ethersex.git // ethersex Firmware herunterladen Cloning into ethersex... remote: Counting objects: 37366, done. remote: Total 37366 (delta 0), reused 0 (delta 0), pack-reused 37366 Receiving objects: 100% (37366/37366), 11.27 MiB | 1.22 MiB/s, done. Resolving deltas: 100% (26538/26538), done. # cp -r ethersex bootloader // Ich kopiere den ethersex Ordner zu dem bootloader Ordner. 1:1 Kopie # cd bootloader/ // In den Bootloader Ordner wechseln # make menuconfig // Einstellungen für Bootloader im nächsten Schritt │ │ Load a Default Configuration ---> │ │ (*) Ethernet Bootloader │ │ General Setup ---> │ │ (ATmega644) Target MCU │ │ (20000000) MCU frequency │ │ [*] Build a bootloader │ │ [*] Teensy build │ │ Network ---> │ │ Hostname: "esex060" // Hostname ändern │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" // MAC ändern mit "Randomize MAC address" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" // Wenn IP nicht vorhanden BOOTP deaktivieren! │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ [ ] BOOTP (DHCP-like) support // BOOTP deaktivieren! │ │ Applications ---> │ │ [*] TFTP support ---> │ │ [*] TFTP-o-matic │ │ TFTP-server IPv4 address: "192.168.123.233" // Server wo TFTPD läuft │ │ TFTP image to load: "esex060.bin" // Diesen Dateinamen ladet später unser Board via Netzwerk/tftpd jetzt noch EXIT und SPEICHERN. # make clean && make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 5902/8192 bytes (72.4%) [=====================---------] Program (.text + .data) : 5902 bytes Data (.data + .bss) : 1902 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.hex</b> ===Bootloader flashen via ISP=== <div><ul> <li style="display: inline-block;"> [[File:Avrdude tempmess01.png|thumb|none|200px|avrdude Bild 1]] </li> <li style="display: inline-block;"> [[File:Avrdude tempmess01.png|thumb|none|200px|avrdude Bild 2]] </li> <li style="display: inline-block;"> [[File:Avrdude tempmess01.png|thumb|none|200px|avrdude Bild 3]] </li> <li style="display: inline-block;"> [[File:Avrdude tempmess01.png|thumb|none|200px|avrdude Bild 4]] </li> </ul></div> Ich flashe hier einfacher weise mit meinem Windows 7 Notebook. Ich habe avrdude einfach unter C:\ liegen. Dort kopiere ich nun die ethersex.hex hin.<br> Somit kann man mit dem flashen den Bootloaders loslegen. avrdude -cusbasp -pm644p -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m // gilt nur für atmega644p und vermutlich auch 644 avrdude -cusbasp -pm644p -U flash:w:ethersex.hex avrdude -cusbasp -pm644p -U lock:w:0x0F:m Der Mikrocontrollerboard ist nun vorbereitet für die eigentliche Firmware. Der ISP-Programmer kann nun bei Seite gelegt werden und wird soweit alles richtig konfiguriert ist auch nicht mehr benötigt.<br> Nun erfolgt das Erstellen der Firmware. =FIRMWARE= ===Firmware bauen=== <div><ul> <li style="display: inline-block;"> [[File:Putty_c6_m4_tempmess01.png|thumb|none|200px|c6_m4 Bild 1]] </li> <li style="display: inline-block;"> [[File:Putty_c6_m4_tempmess02.png|thumb|none|200px|c6_m4 Bild 2]] </li> <li style="display: inline-block;"> [[File:Putty_c6_m4_tempmess03.png|thumb|none|200px|c6_m4 Bild 3]] </li> </ul></div> * <b>WICHTIG:</b> IP, MAC Adresse, Gateway, Netmask, Hostname <b>MUSS</b> gleich sein wie bei dem Bootloader! * Der integrierte Webserver ist in der original Firmware schon aktiviert. ( Applications --> [*] HTTP Server ) # cd /home/avr/ethersex_IP_60/ # cd ethersex/ # make menuconfig │ │ Load a Default Configuration ---> │ │ (*) Etherrape │ │ General Setup ---> │ │ (ATmega644) Target MCU // atmega644p bei mir │ │ (20000000) MCU frequency // 20MHz Quarz │ │ [ ] VFS (Virtual File System) support // Benötige ich hier nicht. │ │ [*] control6 script // Hier wird unsere DS1820 Temperatur in eine Variable geschrieben für den implementieren Webserver. │ │ Network ---> // WICHTIG: IP, MAC Adresse, Gateway, Netmask, Hostname MUSS gleich sein wie bei dem Bootloader! │ │ Hostname: "esex060" │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" │ │ Netmask: "255.255.255.0" │ │ │ │ Default gateway: "192.168.123.10" │ │ I/O ---> │ │ [*] Onewire support ---> // Die allgemeine Onewire Unterstützung. │ │ [*] Onewire device detection support // Automatische Bauteilerkennung In der etherrape.m4 Datei wird nun noch der Pin des atmega geändert wo der DS1820 angeschlossen ist. Im NANO Editor wird mit "STRG-O dann Enter" gespeichert und mit STRG-X beendet. # nano pinning/hardware/etherrape.m4 // editieren der m4 Datei ----- ONEWIRE PIN ändern bei "ONEWIRE_PORT_RANGE(PD6, PD6)" zb. auf PD0 ----- Nun schreiben wir uns ein Script welches den Temperatursensor regelmäßig abfragt und in eine Globale Variable schiebt. # rm control6/control6.src // Original Datei löschen # nano control6/control6.src // Anlegen der c6 Datei. Die Datei ist nun neu und leer. C6_HEADER(`/* This will be in control6.h */') CONTROL_START ECMD_GLOBAL(temp01, 0, uint16_t); THREAD(start) temp01 = ONEWIRE_GET(1054698802080017); WAIT(5) THREAD_END(start) ON STARTUP DO THREAD_START(start) END CONTROL_END Kompilieren der eigentlichen Firmware. # make clean && make // Befehl zum bereinigen & kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 24072/65536 bytes (36.73%) [===========-------------------] Program (.text + .data) : 24072 bytes Data (.data + .bss) : 2250 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.bin</b> Die eigentliche Firmware ist nun kompiliert und fertig um via Netzwerk/tftpd aufgespielt zu werden. Ich verwende im folgenden Schritt Windows 7. Beschreibung im nächsten Schritt. ===Firmware flashen via TFTPD=== <div><ul> <li style="display: inline-block;"> [[File:Tftpd_tempmess01.png|thumb|none|130px|tftpd Bild 1]] </li> <li style="display: inline-block;"> [[File:Tftpd_tempmess02.png|thumb|none|130px|tftpd Bild 2]] </li> <li style="display: inline-block;"> [[File:Tftpd_tempmess03.png|thumb|none|200px|tftpd Bild 3]] </li> <li style="display: inline-block;"> [[File:Tftpd_tempmess04.png|thumb|none|180px|tftpd Bild 4]] </li> </ul></div> Nun ladet ihr euch [http://tftpd32.jounin.net/tftpd32_download.html tftpd] herunter und entpackt es. Ich habe dazu einen Ordner Namens "tftpd" in mein Benutzerverzeichnis "C:\Users\BANANE\tftpd\". Dort wird alles hinein kopiert.<br> Es muss eigentlich nicht viel eingestellt werden. Unter <b>GLOBAL</b> muss TFTP aktiviert sein und unter <b>TFTP</b> sollte das "Base Directory" angepasst werden. Eventuell noch die Bind IP berichtigen. Seht Ihr ja auf den Fotos. Jetzt das Programm noch einmal neu starten. * Mikrocontrollerplatine ist <b>abgesteckt</b>. * tftpd starten * die Datei vom vorigen Schritt in den tftpd Ordner kopieren. <b>ethersex.bin</b> * ethersex.bin umbenennen in "<b>esex060.bin</b>". * Mikrocontrollerplatine Einstecken. Jetzt sollte auch schon was passieren, wie auf Bild 4 zu sehen ist. ''- Bei meiner Firewall musste ich tftpd noch akzeptieren. tftpd hing beim ersten mal in einer Schleife.'' <br> ''- Und nochmals via Netzwerk wird die .bin geflasht, nicht die .hex Datei!'' [[User_talk:Djmaster#1 | Todoliste]] [[Category:Tutorials]] 03cda6cc3544cddd0d702da8589eca9611fbe223 1649 1646 2016-01-30T18:00:12Z Djmaster 255 wikitext text/x-wiki {{i18n|Temperaturmesssystem}} [[File:Tempmess_pcb_01.jpg|thumb|250px|meine Testplatine, Layout stimmt bis auf Kleinigkeiten überein]] [[File:Tempmess_pcb_02.jpg|thumb|250px|Testplatine beim Programmieren mit avrdude via ISP]] =PROJEKT Temperaturmessung= ===Einleitung=== * ZIEL: Eine einfache Temperaturmessung mit dem [[Onewire_(Deutsch)#Anschluss_AVR-NET-IO | DS1820 im parasitären Modus]]. * ZIEL: Die Ausgabe einer Temperaturvariable via integrierten Webbrowser oder telnet. * ZIEL: Die Firmware muss via Netzwerk neu flashbar sein. * Abgeändertes vereinfachtes [http://www.lochraster.org/etherrape/ etherrape] Board. * Zwei Spannungsregler, ein atmega644p, ein enc28j60, und etwas 0805 Hühnerfutter. ===Schaltung=== Das Layout passt in folgendes Gehäuse. Vorher am besten nochmal genau nachmessen. ;)<br> Conrad Bestell-Nr.: [https://www.conrad.at/de/hutschienen-gehaeuse-90-x-360-x-58-polycarbonat-axxatronic-cnmb-2-kit-con-1-st-531441.html 531441] / Axxatronic CNMB-2-KIT-CON <div><ul> <li style="display: inline-block;"> [[File:Sch_tempmess.png|thumb|none|210px|Schaltung]] </li> <li style="display: inline-block;"> [[File:Pcb_tempmess.png|thumb|none|280px|Layout]] </li> </ul></div> * Erstellt mit Eagle Version 7.1.0 für Windows * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_schematic_001.pdf PDF Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_layout_001.pdf PDF Layout gespiegelt] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.sch Eagle Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.brd Eagle Layout] ===Software=== Ethersex (Linux) - https://github.com/ethersex/ethersex Avrdude (Windows) - http://download.savannah.gnu.org/releases/avrdude/ (avrdude-6.1-mingw32.zip) tftpd (Windows) - http://tftpd32.jounin.net/tftpd32_download.html (v4.52 tftpd64 standard edition (zip)) ===Firmware/Bootloader=== Die ethersex Firmware selbst wird für zwei Sachen verwendet. Den <b>Bootloader</b> UND die <b>Firmware</b>. Der Bootloader wird sozusagen einmal in den ersten Bereich des Mikrocontrollers geschrieben und bleibt dort auch. Er wird später die Firmware via Netzwerk entgegennehmen und in den Controller schreiben. Somit befindet sich in den ersten 10% unser Bootloader und in den restlichen 90% der Code den wir wollen. Das zu Verstehen war für mich an Anfang der schwierigste Teil, ist aber dann doch sehr einfach. Ich kann somit ohne ISP-Programmer eine Firmware in den Controller schreiben. Hier grob noch die nächsten Schritte: * Als erstes ist der Bootloader zu konfigurieren, dann via ISP zu programmieren. * Der ISP-Programmer wegräumen. ;) * Als zweites ist die Firmware zu konfigurieren, dann holt sich der Bootloader unsere Firmware via Netzerk/tftpd. =BOOTLOADER= ===Bootloader bauen=== <div><ul> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess01.png|thumb|none|200px|Putty Bild 1]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess02.png|thumb|none|200px|Putty Bild 2]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess03.png|thumb|none|200px|Putty Bild 3]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess04.png|thumb|none|200px|Putty Bild 4]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess05.png|thumb|none|200px|Putty Bild 5]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess06.png|thumb|none|200px|Putty Bild 6]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess07.png|thumb|none|200px|Putty Bild 7]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess08.png|thumb|none|200px|Putty Bild 8]] </li> </ul></div> Ab nun befinde ich mich auf einem <b>virtuellen Debian Rechner</b> wo ich die Firmware herunterlade und daraus den Bootloader erstelle.<br> <b>WICHTIG:</b> Die IP und MAC-Adresse müssen natürlich verändert werden. Die selbe IP und MAC-Adresse müssen in der Firmware später auch benutzt werden. <br> * Bei einem neuen Debian System müssen mit "apt-get" ein paar Sachen nachinstalliert werden. Hier zu finden [[Preparation_(Deutsch)]] * So eine art DHCP wäre auch möglich, nennt sich [[BOOTP_(Deutsch) | BOOTP]]. Darauf gehe ich hier nicht ein. # cd /home/avr/ # mkdir ethersex_IP_60 // Mein "Arbeitsordner" # cd ethersex_IP_60/ // Ordner für das Board mit der IP 192.168.123.60 # git clone git://github.com/ethersex/ethersex.git // ethersex Firmware herunterladen Cloning into ethersex... remote: Counting objects: 37366, done. remote: Total 37366 (delta 0), reused 0 (delta 0), pack-reused 37366 Receiving objects: 100% (37366/37366), 11.27 MiB | 1.22 MiB/s, done. Resolving deltas: 100% (26538/26538), done. # cp -r ethersex bootloader // Ich kopiere den ethersex Ordner zu dem bootloader Ordner. 1:1 Kopie # cd bootloader/ // In den Bootloader Ordner wechseln # make menuconfig // Einstellungen für Bootloader im nächsten Schritt │ │ Load a Default Configuration ---> │ │ (*) Ethernet Bootloader │ │ General Setup ---> │ │ (ATmega644) Target MCU │ │ (20000000) MCU frequency │ │ [*] Build a bootloader │ │ [*] Teensy build │ │ Network ---> │ │ Hostname: "esex060" // Hostname ändern │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" // MAC ändern mit "Randomize MAC address" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" // Wenn IP nicht vorhanden BOOTP deaktivieren! │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ [ ] BOOTP (DHCP-like) support // BOOTP deaktivieren! │ │ Applications ---> │ │ [*] TFTP support ---> │ │ [*] TFTP-o-matic │ │ TFTP-server IPv4 address: "192.168.123.233" // Server wo TFTPD läuft │ │ TFTP image to load: "esex060.bin" // Diesen Dateinamen ladet später unser Board via Netzwerk/tftpd jetzt noch EXIT und SPEICHERN. # make clean && make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 5902/8192 bytes (72.4%) [=====================---------] Program (.text + .data) : 5902 bytes Data (.data + .bss) : 1902 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.hex</b> ===Bootloader flashen via ISP=== <div><ul> <li style="display: inline-block;"> [[File:Avrdude tempmess01.png|thumb|none|200px|avrdude Bild 1]] </li> <li style="display: inline-block;"> [[File:Avrdude tempmess01.png|thumb|none|200px|avrdude Bild 2]] </li> <li style="display: inline-block;"> [[File:Avrdude tempmess01.png|thumb|none|200px|avrdude Bild 3]] </li> <li style="display: inline-block;"> [[File:Avrdude tempmess01.png|thumb|none|200px|avrdude Bild 4]] </li> </ul></div> Ich flashe hier einfacher weise mit meinem Windows 7 Notebook. Ich habe avrdude einfach unter C:\ liegen. Dort kopiere ich nun die ethersex.hex hin.<br> Somit kann man mit dem flashen den Bootloaders loslegen. avrdude -cusbasp -pm644p -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m // gilt nur für atmega644p und vermutlich auch 644 avrdude -cusbasp -pm644p -U flash:w:ethersex.hex avrdude -cusbasp -pm644p -U lock:w:0x0F:m Der Mikrocontrollerboard ist nun vorbereitet für die eigentliche Firmware. Der ISP-Programmer kann nun bei Seite gelegt werden und wird soweit alles richtig konfiguriert ist auch nicht mehr benötigt.<br> Nun erfolgt das Erstellen der Firmware. =FIRMWARE= ===Firmware bauen=== <div><ul> <li style="display: inline-block;"> [[File:Putty_c6_m4_tempmess01.png|thumb|none|200px|c6_m4 Bild 1]] </li> <li style="display: inline-block;"> [[File:Putty_c6_m4_tempmess02.png|thumb|none|200px|c6_m4 Bild 2]] </li> <li style="display: inline-block;"> [[File:Putty_c6_m4_tempmess03.png|thumb|none|200px|c6_m4 Bild 3]] </li> </ul></div> * <b>WICHTIG:</b> IP, MAC Adresse, Gateway, Netmask, Hostname <b>MUSS</b> gleich sein wie bei dem Bootloader! * Der integrierte Webserver ist in der original Firmware schon aktiviert. ( Applications --> [*] HTTP Server ) # cd /home/avr/ethersex_IP_60/ # cd ethersex/ # make menuconfig │ │ Load a Default Configuration ---> │ │ (*) Etherrape │ │ General Setup ---> │ │ (ATmega644) Target MCU // atmega644p bei mir │ │ (20000000) MCU frequency // 20MHz Quarz │ │ [ ] VFS (Virtual File System) support // Benötige ich hier nicht. │ │ [*] control6 script // Hier wird unsere DS1820 Temperatur in eine Variable geschrieben für den implementieren Webserver. │ │ Network ---> // WICHTIG: IP, MAC Adresse, Gateway, Netmask, Hostname MUSS gleich sein wie bei dem Bootloader! │ │ Hostname: "esex060" │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" │ │ Netmask: "255.255.255.0" │ │ │ │ Default gateway: "192.168.123.10" │ │ I/O ---> │ │ [*] Onewire support ---> // Die allgemeine Onewire Unterstützung. │ │ [*] Onewire device detection support // Automatische Bauteilerkennung In der etherrape.m4 Datei wird nun noch der Pin des atmega geändert wo der DS1820 angeschlossen ist. Im NANO Editor wird mit "STRG-O dann Enter" gespeichert und mit STRG-X beendet. # nano pinning/hardware/etherrape.m4 // editieren der m4 Datei ----- ONEWIRE PIN ändern bei "ONEWIRE_PORT_RANGE(PD6, PD6)" zb. auf PD0 ----- Nun schreiben wir uns ein Script welches den Temperatursensor regelmäßig abfragt und in eine Globale Variable schiebt. # rm control6/control6.src // Original Datei löschen # nano control6/control6.src // Anlegen der c6 Datei. Die Datei ist nun neu und leer. C6_HEADER(`/* This will be in control6.h */') CONTROL_START ECMD_GLOBAL(temp01, 0, uint16_t); THREAD(start) temp01 = ONEWIRE_GET(1054698802080017); // Die ID muss vorher aus dem Sensor ausgelesen werden. Erklärung ganz am Schluss. WAIT(5) THREAD_END(start) ON STARTUP DO THREAD_START(start) END CONTROL_END Kompilieren der eigentlichen Firmware. # make clean && make // Befehl zum bereinigen & kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 24072/65536 bytes (36.73%) [===========-------------------] Program (.text + .data) : 24072 bytes Data (.data + .bss) : 2250 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.bin</b> Die eigentliche Firmware ist nun kompiliert und fertig um via Netzwerk/tftpd aufgespielt zu werden. Ich verwende im folgenden Schritt Windows 7. Beschreibung im nächsten Schritt. ===Firmware flashen via TFTPD=== <div><ul> <li style="display: inline-block;"> [[File:Tftpd_tempmess01.png|thumb|none|130px|tftpd Bild 1]] </li> <li style="display: inline-block;"> [[File:Tftpd_tempmess02.png|thumb|none|130px|tftpd Bild 2]] </li> <li style="display: inline-block;"> [[File:Tftpd_tempmess03.png|thumb|none|200px|tftpd Bild 3]] </li> <li style="display: inline-block;"> [[File:Tftpd_tempmess04.png|thumb|none|180px|tftpd Bild 4]] </li> </ul></div> Nun ladet ihr euch [http://tftpd32.jounin.net/tftpd32_download.html tftpd] herunter und entpackt es. Ich habe dazu einen Ordner Namens "tftpd" in mein Benutzerverzeichnis "C:\Users\BANANE\tftpd\". Dort wird alles hinein kopiert.<br> Es muss eigentlich nicht viel eingestellt werden. Unter <b>GLOBAL</b> muss TFTP aktiviert sein und unter <b>TFTP</b> sollte das "Base Directory" angepasst werden. Eventuell noch die Bind IP berichtigen. Seht Ihr ja auf den Fotos. Jetzt das Programm noch einmal neu starten. * Mikrocontrollerplatine ist <b>abgesteckt</b>. * tftpd starten * die Datei vom vorigen Schritt in den tftpd Ordner kopieren. <b>ethersex.bin</b> * ethersex.bin umbenennen in "<b>esex060.bin</b>". * Mikrocontrollerplatine Einstecken. Jetzt sollte auch schon was passieren, wie auf Bild 4 zu sehen ist. * Der Mikrocontroller ist nun via Webinterface erreichbar. Es können nur ecmd Befehle entgegengenommen werden. * erste Testverbindung zu unserem Mikrocontroller - http://192.168.123.60/ecmd?help ----AUSGABE---- c6 get c6 set wdreset .... 1w list 1w get 1w convert help version * <b>Sollten wir eine neue Firmware kompiliert haben können wir den Controller via Webinterface neu starten. Befehl dazu ist "wdreset"</b>. * Also neue esex060.bin wieder in den tftpd Ordner kopieren, tftpd starten und via Web "wdreset" ausführen. * http://192.168.123.60/ecmd?wdreset * Nun ladet sich der Controller die esex060.bin wieder via tftpd. ===Hinweise=== ''- Bei meiner Firewall musste ich tftpd noch akzeptieren. tftpd hing beim ersten mal in einer Schleife.'' <br> ''- Und nochmals via Netzwerk wird die .bin geflasht, nicht die .hex Datei!'' [[User_talk:Djmaster#1 | Todoliste]] [[Category:Tutorials]] 79e72806f49f915dc4ad2151ac85abb7268b519b 1650 1649 2016-01-30T18:14:55Z Djmaster 255 /* Hinweise */ wikitext text/x-wiki {{i18n|Temperaturmesssystem}} [[File:Tempmess_pcb_01.jpg|thumb|250px|meine Testplatine, Layout stimmt bis auf Kleinigkeiten überein]] [[File:Tempmess_pcb_02.jpg|thumb|250px|Testplatine beim Programmieren mit avrdude via ISP]] =PROJEKT Temperaturmessung= ===Einleitung=== * ZIEL: Eine einfache Temperaturmessung mit dem [[Onewire_(Deutsch)#Anschluss_AVR-NET-IO | DS1820 im parasitären Modus]]. * ZIEL: Die Ausgabe einer Temperaturvariable via integrierten Webbrowser oder telnet. * ZIEL: Die Firmware muss via Netzwerk neu flashbar sein. * Abgeändertes vereinfachtes [http://www.lochraster.org/etherrape/ etherrape] Board. * Zwei Spannungsregler, ein atmega644p, ein enc28j60, und etwas 0805 Hühnerfutter. ===Schaltung=== Das Layout passt in folgendes Gehäuse. Vorher am besten nochmal genau nachmessen. ;)<br> Conrad Bestell-Nr.: [https://www.conrad.at/de/hutschienen-gehaeuse-90-x-360-x-58-polycarbonat-axxatronic-cnmb-2-kit-con-1-st-531441.html 531441] / Axxatronic CNMB-2-KIT-CON <div><ul> <li style="display: inline-block;"> [[File:Sch_tempmess.png|thumb|none|210px|Schaltung]] </li> <li style="display: inline-block;"> [[File:Pcb_tempmess.png|thumb|none|280px|Layout]] </li> </ul></div> * Erstellt mit Eagle Version 7.1.0 für Windows * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_schematic_001.pdf PDF Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_layout_001.pdf PDF Layout gespiegelt] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.sch Eagle Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.brd Eagle Layout] ===Software=== Ethersex (Linux) - https://github.com/ethersex/ethersex Avrdude (Windows) - http://download.savannah.gnu.org/releases/avrdude/ (avrdude-6.1-mingw32.zip) tftpd (Windows) - http://tftpd32.jounin.net/tftpd32_download.html (v4.52 tftpd64 standard edition (zip)) ===Firmware/Bootloader=== Die ethersex Firmware selbst wird für zwei Sachen verwendet. Den <b>Bootloader</b> UND die <b>Firmware</b>. Der Bootloader wird sozusagen einmal in den ersten Bereich des Mikrocontrollers geschrieben und bleibt dort auch. Er wird später die Firmware via Netzwerk entgegennehmen und in den Controller schreiben. Somit befindet sich in den ersten 10% unser Bootloader und in den restlichen 90% der Code den wir wollen. Das zu Verstehen war für mich an Anfang der schwierigste Teil, ist aber dann doch sehr einfach. Ich kann somit ohne ISP-Programmer eine Firmware in den Controller schreiben. Hier grob noch die nächsten Schritte: * Als erstes ist der Bootloader zu konfigurieren, dann via ISP zu programmieren. * Der ISP-Programmer wegräumen. ;) * Als zweites ist die Firmware zu konfigurieren, dann holt sich der Bootloader unsere Firmware via Netzerk/tftpd. =BOOTLOADER= ===Bootloader bauen=== <div><ul> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess01.png|thumb|none|200px|Putty Bild 1]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess02.png|thumb|none|200px|Putty Bild 2]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess03.png|thumb|none|200px|Putty Bild 3]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess04.png|thumb|none|200px|Putty Bild 4]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess05.png|thumb|none|200px|Putty Bild 5]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess06.png|thumb|none|200px|Putty Bild 6]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess07.png|thumb|none|200px|Putty Bild 7]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess08.png|thumb|none|200px|Putty Bild 8]] </li> </ul></div> Ab nun befinde ich mich auf einem <b>virtuellen Debian Rechner</b> wo ich die Firmware herunterlade und daraus den Bootloader erstelle.<br> <b>WICHTIG:</b> Die IP und MAC-Adresse müssen natürlich verändert werden. Die selbe IP und MAC-Adresse müssen in der Firmware später auch benutzt werden. <br> * Bei einem neuen Debian System müssen mit "apt-get" ein paar Sachen nachinstalliert werden. Hier zu finden [[Preparation_(Deutsch)]] * So eine art DHCP wäre auch möglich, nennt sich [[BOOTP_(Deutsch) | BOOTP]]. Darauf gehe ich hier nicht ein. # cd /home/avr/ # mkdir ethersex_IP_60 // Mein "Arbeitsordner" # cd ethersex_IP_60/ // Ordner für das Board mit der IP 192.168.123.60 # git clone git://github.com/ethersex/ethersex.git // ethersex Firmware herunterladen Cloning into ethersex... remote: Counting objects: 37366, done. remote: Total 37366 (delta 0), reused 0 (delta 0), pack-reused 37366 Receiving objects: 100% (37366/37366), 11.27 MiB | 1.22 MiB/s, done. Resolving deltas: 100% (26538/26538), done. # cp -r ethersex bootloader // Ich kopiere den ethersex Ordner zu dem bootloader Ordner. 1:1 Kopie # cd bootloader/ // In den Bootloader Ordner wechseln # make menuconfig // Einstellungen für Bootloader im nächsten Schritt │ │ Load a Default Configuration ---> │ │ (*) Ethernet Bootloader │ │ General Setup ---> │ │ (ATmega644) Target MCU │ │ (20000000) MCU frequency │ │ [*] Build a bootloader │ │ [*] Teensy build │ │ Network ---> │ │ Hostname: "esex060" // Hostname ändern │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" // MAC ändern mit "Randomize MAC address" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" // Wenn IP nicht vorhanden BOOTP deaktivieren! │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ [ ] BOOTP (DHCP-like) support // BOOTP deaktivieren! │ │ Applications ---> │ │ [*] TFTP support ---> │ │ [*] TFTP-o-matic │ │ TFTP-server IPv4 address: "192.168.123.233" // Server wo TFTPD läuft │ │ TFTP image to load: "esex060.bin" // Diesen Dateinamen ladet später unser Board via Netzwerk/tftpd jetzt noch EXIT und SPEICHERN. # make clean && make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 5902/8192 bytes (72.4%) [=====================---------] Program (.text + .data) : 5902 bytes Data (.data + .bss) : 1902 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.hex</b> ===Bootloader flashen via ISP=== <div><ul> <li style="display: inline-block;"> [[File:Avrdude tempmess01.png|thumb|none|200px|avrdude Bild 1]] </li> <li style="display: inline-block;"> [[File:Avrdude tempmess01.png|thumb|none|200px|avrdude Bild 2]] </li> <li style="display: inline-block;"> [[File:Avrdude tempmess01.png|thumb|none|200px|avrdude Bild 3]] </li> <li style="display: inline-block;"> [[File:Avrdude tempmess01.png|thumb|none|200px|avrdude Bild 4]] </li> </ul></div> Ich flashe hier einfacher weise mit meinem Windows 7 Notebook. Ich habe avrdude einfach unter C:\ liegen. Dort kopiere ich nun die ethersex.hex hin.<br> Somit kann man mit dem flashen den Bootloaders loslegen. avrdude -cusbasp -pm644p -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m // gilt nur für atmega644p und vermutlich auch 644 avrdude -cusbasp -pm644p -U flash:w:ethersex.hex avrdude -cusbasp -pm644p -U lock:w:0x0F:m Der Mikrocontrollerboard ist nun vorbereitet für die eigentliche Firmware. Der ISP-Programmer kann nun bei Seite gelegt werden und wird soweit alles richtig konfiguriert ist auch nicht mehr benötigt.<br> Nun erfolgt das Erstellen der Firmware. =FIRMWARE= ===Firmware bauen=== <div><ul> <li style="display: inline-block;"> [[File:Putty_c6_m4_tempmess01.png|thumb|none|200px|c6_m4 Bild 1]] </li> <li style="display: inline-block;"> [[File:Putty_c6_m4_tempmess02.png|thumb|none|200px|c6_m4 Bild 2]] </li> <li style="display: inline-block;"> [[File:Putty_c6_m4_tempmess03.png|thumb|none|200px|c6_m4 Bild 3]] </li> </ul></div> * <b>WICHTIG:</b> IP, MAC Adresse, Gateway, Netmask, Hostname <b>MUSS</b> gleich sein wie bei dem Bootloader! * Der integrierte Webserver ist in der original Firmware schon aktiviert. ( Applications --> [*] HTTP Server ) # cd /home/avr/ethersex_IP_60/ # cd ethersex/ # make menuconfig │ │ Load a Default Configuration ---> │ │ (*) Etherrape │ │ General Setup ---> │ │ (ATmega644) Target MCU // atmega644p bei mir │ │ (20000000) MCU frequency // 20MHz Quarz │ │ [ ] VFS (Virtual File System) support // Benötige ich hier nicht. │ │ [*] control6 script // Hier wird unsere DS1820 Temperatur in eine Variable geschrieben für den implementieren Webserver. │ │ Network ---> // WICHTIG: IP, MAC Adresse, Gateway, Netmask, Hostname MUSS gleich sein wie bei dem Bootloader! │ │ Hostname: "esex060" │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" │ │ Netmask: "255.255.255.0" │ │ │ │ Default gateway: "192.168.123.10" │ │ I/O ---> │ │ [*] Onewire support ---> // Die allgemeine Onewire Unterstützung. │ │ [*] Onewire device detection support // Automatische Bauteilerkennung In der etherrape.m4 Datei wird nun noch der Pin des atmega geändert wo der DS1820 angeschlossen ist. Im NANO Editor wird mit "STRG-O dann Enter" gespeichert und mit STRG-X beendet. # nano pinning/hardware/etherrape.m4 // editieren der m4 Datei ----- ONEWIRE PIN ändern bei "ONEWIRE_PORT_RANGE(PD6, PD6)" zb. auf PD0 ----- Nun schreiben wir uns ein Script welches den Temperatursensor regelmäßig abfragt und in eine Globale Variable schiebt. # rm control6/control6.src // Original Datei löschen # nano control6/control6.src // Anlegen der c6 Datei. Die Datei ist nun neu und leer. C6_HEADER(`/* This will be in control6.h */') CONTROL_START ECMD_GLOBAL(temp01, 0, uint16_t); THREAD(start) temp01 = ONEWIRE_GET(1054698802080017); // Die ID muss vorher aus dem Sensor ausgelesen werden. Erklärung ganz am Schluss. WAIT(5) THREAD_END(start) ON STARTUP DO THREAD_START(start) END CONTROL_END Kompilieren der eigentlichen Firmware. # make clean && make // Befehl zum bereinigen & kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 24072/65536 bytes (36.73%) [===========-------------------] Program (.text + .data) : 24072 bytes Data (.data + .bss) : 2250 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.bin</b> Die eigentliche Firmware ist nun kompiliert und fertig um via Netzwerk/tftpd aufgespielt zu werden. Ich verwende im folgenden Schritt Windows 7. Beschreibung im nächsten Schritt. ===Firmware flashen via TFTPD=== <div><ul> <li style="display: inline-block;"> [[File:Tftpd_tempmess01.png|thumb|none|130px|tftpd Bild 1]] </li> <li style="display: inline-block;"> [[File:Tftpd_tempmess02.png|thumb|none|130px|tftpd Bild 2]] </li> <li style="display: inline-block;"> [[File:Tftpd_tempmess03.png|thumb|none|200px|tftpd Bild 3]] </li> <li style="display: inline-block;"> [[File:Tftpd_tempmess04.png|thumb|none|180px|tftpd Bild 4]] </li> </ul></div> Nun ladet ihr euch [http://tftpd32.jounin.net/tftpd32_download.html tftpd] herunter und entpackt es. Ich habe dazu einen Ordner Namens "tftpd" in mein Benutzerverzeichnis "C:\Users\BANANE\tftpd\". Dort wird alles hinein kopiert.<br> Es muss eigentlich nicht viel eingestellt werden. Unter <b>GLOBAL</b> muss TFTP aktiviert sein und unter <b>TFTP</b> sollte das "Base Directory" angepasst werden. Eventuell noch die Bind IP berichtigen. Seht Ihr ja auf den Fotos. Jetzt das Programm noch einmal neu starten. * Mikrocontrollerplatine ist <b>abgesteckt</b>. * tftpd starten * die Datei vom vorigen Schritt in den tftpd Ordner kopieren. <b>ethersex.bin</b> * ethersex.bin umbenennen in "<b>esex060.bin</b>". * Mikrocontrollerplatine Einstecken. Jetzt sollte auch schon was passieren, wie auf Bild 4 zu sehen ist. * Der Mikrocontroller ist nun via Webinterface erreichbar. Es können nur ecmd Befehle entgegengenommen werden. * erste Testverbindung zu unserem Mikrocontroller - http://192.168.123.60/ecmd?help ----AUSGABE---- c6 get c6 set wdreset .... 1w list 1w get 1w convert help version * <b>Sollten wir eine neue Firmware kompiliert haben können wir den Controller via Webinterface neu starten. Befehl dazu ist "wdreset"</b>. * Also neue esex060.bin wieder in den tftpd Ordner kopieren, tftpd starten und via Web "wdreset" ausführen. * http://192.168.123.60/ecmd?wdreset * Nun ladet sich der Controller die esex060.bin wieder via tftpd. ===Hinweise=== ''- Bei meiner Firewall musste ich tftpd noch akzeptieren. tftpd hing beim ersten mal in einer Schleife.'' ''- Und nochmals via Netzwerk wird die .bin geflasht, nicht die .hex Datei!'' =OneWire= ===Auslesen der Sensor ID=== * Die ID kann via Webinterace mit dem Befehl "1w list" ausgelesen werde. * [http://192.168.123.60/ecmd?1w%20list http://192.168.123.60/ecmd?1w list] ----AUSGABE---- 1054698802080017 OK * Nun könnt Ihr die richtige ID oben im Control6 Script einsetzten und die Firmware neu kompilieren. * Wir haben im C6 Script eine Temperatur variable definiert welche "temp01" lautet. * Aktualisiert wird die Variable alle 5 Sekunden, das ist ebenfalls im C6 Script angegeben. * Diese kann ich nun via Webinterface abfragen - [http://192.168.123.60/ecmd?c6%20get%20temp01 http://192.168.123.60/ecmd?c6 get temp01] ----AUSGABE---- temp01 241 // 24.1 Grad [[User_talk:Djmaster#1 | Todoliste]] [[Category:Tutorials]] 175f30a1424f4d4eec4a8e57549a5428e34d2c0d 1651 1650 2016-01-30T18:15:18Z Djmaster 255 /* OneWire */ wikitext text/x-wiki {{i18n|Temperaturmesssystem}} [[File:Tempmess_pcb_01.jpg|thumb|250px|meine Testplatine, Layout stimmt bis auf Kleinigkeiten überein]] [[File:Tempmess_pcb_02.jpg|thumb|250px|Testplatine beim Programmieren mit avrdude via ISP]] =PROJEKT Temperaturmessung= ===Einleitung=== * ZIEL: Eine einfache Temperaturmessung mit dem [[Onewire_(Deutsch)#Anschluss_AVR-NET-IO | DS1820 im parasitären Modus]]. * ZIEL: Die Ausgabe einer Temperaturvariable via integrierten Webbrowser oder telnet. * ZIEL: Die Firmware muss via Netzwerk neu flashbar sein. * Abgeändertes vereinfachtes [http://www.lochraster.org/etherrape/ etherrape] Board. * Zwei Spannungsregler, ein atmega644p, ein enc28j60, und etwas 0805 Hühnerfutter. ===Schaltung=== Das Layout passt in folgendes Gehäuse. Vorher am besten nochmal genau nachmessen. ;)<br> Conrad Bestell-Nr.: [https://www.conrad.at/de/hutschienen-gehaeuse-90-x-360-x-58-polycarbonat-axxatronic-cnmb-2-kit-con-1-st-531441.html 531441] / Axxatronic CNMB-2-KIT-CON <div><ul> <li style="display: inline-block;"> [[File:Sch_tempmess.png|thumb|none|210px|Schaltung]] </li> <li style="display: inline-block;"> [[File:Pcb_tempmess.png|thumb|none|280px|Layout]] </li> </ul></div> * Erstellt mit Eagle Version 7.1.0 für Windows * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_schematic_001.pdf PDF Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_layout_001.pdf PDF Layout gespiegelt] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.sch Eagle Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.brd Eagle Layout] ===Software=== Ethersex (Linux) - https://github.com/ethersex/ethersex Avrdude (Windows) - http://download.savannah.gnu.org/releases/avrdude/ (avrdude-6.1-mingw32.zip) tftpd (Windows) - http://tftpd32.jounin.net/tftpd32_download.html (v4.52 tftpd64 standard edition (zip)) ===Firmware/Bootloader=== Die ethersex Firmware selbst wird für zwei Sachen verwendet. Den <b>Bootloader</b> UND die <b>Firmware</b>. Der Bootloader wird sozusagen einmal in den ersten Bereich des Mikrocontrollers geschrieben und bleibt dort auch. Er wird später die Firmware via Netzwerk entgegennehmen und in den Controller schreiben. Somit befindet sich in den ersten 10% unser Bootloader und in den restlichen 90% der Code den wir wollen. Das zu Verstehen war für mich an Anfang der schwierigste Teil, ist aber dann doch sehr einfach. Ich kann somit ohne ISP-Programmer eine Firmware in den Controller schreiben. Hier grob noch die nächsten Schritte: * Als erstes ist der Bootloader zu konfigurieren, dann via ISP zu programmieren. * Der ISP-Programmer wegräumen. ;) * Als zweites ist die Firmware zu konfigurieren, dann holt sich der Bootloader unsere Firmware via Netzerk/tftpd. =BOOTLOADER= ===Bootloader bauen=== <div><ul> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess01.png|thumb|none|200px|Putty Bild 1]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess02.png|thumb|none|200px|Putty Bild 2]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess03.png|thumb|none|200px|Putty Bild 3]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess04.png|thumb|none|200px|Putty Bild 4]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess05.png|thumb|none|200px|Putty Bild 5]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess06.png|thumb|none|200px|Putty Bild 6]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess07.png|thumb|none|200px|Putty Bild 7]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess08.png|thumb|none|200px|Putty Bild 8]] </li> </ul></div> Ab nun befinde ich mich auf einem <b>virtuellen Debian Rechner</b> wo ich die Firmware herunterlade und daraus den Bootloader erstelle.<br> <b>WICHTIG:</b> Die IP und MAC-Adresse müssen natürlich verändert werden. Die selbe IP und MAC-Adresse müssen in der Firmware später auch benutzt werden. <br> * Bei einem neuen Debian System müssen mit "apt-get" ein paar Sachen nachinstalliert werden. Hier zu finden [[Preparation_(Deutsch)]] * So eine art DHCP wäre auch möglich, nennt sich [[BOOTP_(Deutsch) | BOOTP]]. Darauf gehe ich hier nicht ein. # cd /home/avr/ # mkdir ethersex_IP_60 // Mein "Arbeitsordner" # cd ethersex_IP_60/ // Ordner für das Board mit der IP 192.168.123.60 # git clone git://github.com/ethersex/ethersex.git // ethersex Firmware herunterladen Cloning into ethersex... remote: Counting objects: 37366, done. remote: Total 37366 (delta 0), reused 0 (delta 0), pack-reused 37366 Receiving objects: 100% (37366/37366), 11.27 MiB | 1.22 MiB/s, done. Resolving deltas: 100% (26538/26538), done. # cp -r ethersex bootloader // Ich kopiere den ethersex Ordner zu dem bootloader Ordner. 1:1 Kopie # cd bootloader/ // In den Bootloader Ordner wechseln # make menuconfig // Einstellungen für Bootloader im nächsten Schritt │ │ Load a Default Configuration ---> │ │ (*) Ethernet Bootloader │ │ General Setup ---> │ │ (ATmega644) Target MCU │ │ (20000000) MCU frequency │ │ [*] Build a bootloader │ │ [*] Teensy build │ │ Network ---> │ │ Hostname: "esex060" // Hostname ändern │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" // MAC ändern mit "Randomize MAC address" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" // Wenn IP nicht vorhanden BOOTP deaktivieren! │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ [ ] BOOTP (DHCP-like) support // BOOTP deaktivieren! │ │ Applications ---> │ │ [*] TFTP support ---> │ │ [*] TFTP-o-matic │ │ TFTP-server IPv4 address: "192.168.123.233" // Server wo TFTPD läuft │ │ TFTP image to load: "esex060.bin" // Diesen Dateinamen ladet später unser Board via Netzwerk/tftpd jetzt noch EXIT und SPEICHERN. # make clean && make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 5902/8192 bytes (72.4%) [=====================---------] Program (.text + .data) : 5902 bytes Data (.data + .bss) : 1902 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.hex</b> ===Bootloader flashen via ISP=== <div><ul> <li style="display: inline-block;"> [[File:Avrdude tempmess01.png|thumb|none|200px|avrdude Bild 1]] </li> <li style="display: inline-block;"> [[File:Avrdude tempmess01.png|thumb|none|200px|avrdude Bild 2]] </li> <li style="display: inline-block;"> [[File:Avrdude tempmess01.png|thumb|none|200px|avrdude Bild 3]] </li> <li style="display: inline-block;"> [[File:Avrdude tempmess01.png|thumb|none|200px|avrdude Bild 4]] </li> </ul></div> Ich flashe hier einfacher weise mit meinem Windows 7 Notebook. Ich habe avrdude einfach unter C:\ liegen. Dort kopiere ich nun die ethersex.hex hin.<br> Somit kann man mit dem flashen den Bootloaders loslegen. avrdude -cusbasp -pm644p -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m // gilt nur für atmega644p und vermutlich auch 644 avrdude -cusbasp -pm644p -U flash:w:ethersex.hex avrdude -cusbasp -pm644p -U lock:w:0x0F:m Der Mikrocontrollerboard ist nun vorbereitet für die eigentliche Firmware. Der ISP-Programmer kann nun bei Seite gelegt werden und wird soweit alles richtig konfiguriert ist auch nicht mehr benötigt.<br> Nun erfolgt das Erstellen der Firmware. =FIRMWARE= ===Firmware bauen=== <div><ul> <li style="display: inline-block;"> [[File:Putty_c6_m4_tempmess01.png|thumb|none|200px|c6_m4 Bild 1]] </li> <li style="display: inline-block;"> [[File:Putty_c6_m4_tempmess02.png|thumb|none|200px|c6_m4 Bild 2]] </li> <li style="display: inline-block;"> [[File:Putty_c6_m4_tempmess03.png|thumb|none|200px|c6_m4 Bild 3]] </li> </ul></div> * <b>WICHTIG:</b> IP, MAC Adresse, Gateway, Netmask, Hostname <b>MUSS</b> gleich sein wie bei dem Bootloader! * Der integrierte Webserver ist in der original Firmware schon aktiviert. ( Applications --> [*] HTTP Server ) # cd /home/avr/ethersex_IP_60/ # cd ethersex/ # make menuconfig │ │ Load a Default Configuration ---> │ │ (*) Etherrape │ │ General Setup ---> │ │ (ATmega644) Target MCU // atmega644p bei mir │ │ (20000000) MCU frequency // 20MHz Quarz │ │ [ ] VFS (Virtual File System) support // Benötige ich hier nicht. │ │ [*] control6 script // Hier wird unsere DS1820 Temperatur in eine Variable geschrieben für den implementieren Webserver. │ │ Network ---> // WICHTIG: IP, MAC Adresse, Gateway, Netmask, Hostname MUSS gleich sein wie bei dem Bootloader! │ │ Hostname: "esex060" │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" │ │ Netmask: "255.255.255.0" │ │ │ │ Default gateway: "192.168.123.10" │ │ I/O ---> │ │ [*] Onewire support ---> // Die allgemeine Onewire Unterstützung. │ │ [*] Onewire device detection support // Automatische Bauteilerkennung In der etherrape.m4 Datei wird nun noch der Pin des atmega geändert wo der DS1820 angeschlossen ist. Im NANO Editor wird mit "STRG-O dann Enter" gespeichert und mit STRG-X beendet. # nano pinning/hardware/etherrape.m4 // editieren der m4 Datei ----- ONEWIRE PIN ändern bei "ONEWIRE_PORT_RANGE(PD6, PD6)" zb. auf PD0 ----- Nun schreiben wir uns ein Script welches den Temperatursensor regelmäßig abfragt und in eine Globale Variable schiebt. # rm control6/control6.src // Original Datei löschen # nano control6/control6.src // Anlegen der c6 Datei. Die Datei ist nun neu und leer. C6_HEADER(`/* This will be in control6.h */') CONTROL_START ECMD_GLOBAL(temp01, 0, uint16_t); THREAD(start) temp01 = ONEWIRE_GET(1054698802080017); // Die ID muss vorher aus dem Sensor ausgelesen werden. Erklärung ganz am Schluss. WAIT(5) THREAD_END(start) ON STARTUP DO THREAD_START(start) END CONTROL_END Kompilieren der eigentlichen Firmware. # make clean && make // Befehl zum bereinigen & kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 24072/65536 bytes (36.73%) [===========-------------------] Program (.text + .data) : 24072 bytes Data (.data + .bss) : 2250 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.bin</b> Die eigentliche Firmware ist nun kompiliert und fertig um via Netzwerk/tftpd aufgespielt zu werden. Ich verwende im folgenden Schritt Windows 7. Beschreibung im nächsten Schritt. ===Firmware flashen via TFTPD=== <div><ul> <li style="display: inline-block;"> [[File:Tftpd_tempmess01.png|thumb|none|130px|tftpd Bild 1]] </li> <li style="display: inline-block;"> [[File:Tftpd_tempmess02.png|thumb|none|130px|tftpd Bild 2]] </li> <li style="display: inline-block;"> [[File:Tftpd_tempmess03.png|thumb|none|200px|tftpd Bild 3]] </li> <li style="display: inline-block;"> [[File:Tftpd_tempmess04.png|thumb|none|180px|tftpd Bild 4]] </li> </ul></div> Nun ladet ihr euch [http://tftpd32.jounin.net/tftpd32_download.html tftpd] herunter und entpackt es. Ich habe dazu einen Ordner Namens "tftpd" in mein Benutzerverzeichnis "C:\Users\BANANE\tftpd\". Dort wird alles hinein kopiert.<br> Es muss eigentlich nicht viel eingestellt werden. Unter <b>GLOBAL</b> muss TFTP aktiviert sein und unter <b>TFTP</b> sollte das "Base Directory" angepasst werden. Eventuell noch die Bind IP berichtigen. Seht Ihr ja auf den Fotos. Jetzt das Programm noch einmal neu starten. * Mikrocontrollerplatine ist <b>abgesteckt</b>. * tftpd starten * die Datei vom vorigen Schritt in den tftpd Ordner kopieren. <b>ethersex.bin</b> * ethersex.bin umbenennen in "<b>esex060.bin</b>". * Mikrocontrollerplatine Einstecken. Jetzt sollte auch schon was passieren, wie auf Bild 4 zu sehen ist. * Der Mikrocontroller ist nun via Webinterface erreichbar. Es können nur ecmd Befehle entgegengenommen werden. * erste Testverbindung zu unserem Mikrocontroller - http://192.168.123.60/ecmd?help ----AUSGABE---- c6 get c6 set wdreset .... 1w list 1w get 1w convert help version * <b>Sollten wir eine neue Firmware kompiliert haben können wir den Controller via Webinterface neu starten. Befehl dazu ist "wdreset"</b>. * Also neue esex060.bin wieder in den tftpd Ordner kopieren, tftpd starten und via Web "wdreset" ausführen. * http://192.168.123.60/ecmd?wdreset * Nun ladet sich der Controller die esex060.bin wieder via tftpd. ===Hinweise=== ''- Bei meiner Firewall musste ich tftpd noch akzeptieren. tftpd hing beim ersten mal in einer Schleife.'' ''- Und nochmals via Netzwerk wird die .bin geflasht, nicht die .hex Datei!'' =ONEWIRE= ===Auslesen der Sensor ID=== * Die ID kann via Webinterace mit dem Befehl "1w list" ausgelesen werde. * [http://192.168.123.60/ecmd?1w%20list http://192.168.123.60/ecmd?1w list] ----AUSGABE---- 1054698802080017 OK * Nun könnt Ihr die richtige ID oben im Control6 Script einsetzten und die Firmware neu kompilieren. * Wir haben im C6 Script eine Temperatur variable definiert welche "temp01" lautet. * Aktualisiert wird die Variable alle 5 Sekunden, das ist ebenfalls im C6 Script angegeben. * Diese kann ich nun via Webinterface abfragen - [http://192.168.123.60/ecmd?c6%20get%20temp01 http://192.168.123.60/ecmd?c6 get temp01] ----AUSGABE---- temp01 241 // 24.1 Grad [[User_talk:Djmaster#1 | Todoliste]] [[Category:Tutorials]] 3b009c148a425a88dbe310984a43a3f2724389d6 1653 1651 2016-01-30T18:16:25Z Djmaster 255 /* Auslesen der Sensor ID */ wikitext text/x-wiki {{i18n|Temperaturmesssystem}} [[File:Tempmess_pcb_01.jpg|thumb|250px|meine Testplatine, Layout stimmt bis auf Kleinigkeiten überein]] [[File:Tempmess_pcb_02.jpg|thumb|250px|Testplatine beim Programmieren mit avrdude via ISP]] =PROJEKT Temperaturmessung= ===Einleitung=== * ZIEL: Eine einfache Temperaturmessung mit dem [[Onewire_(Deutsch)#Anschluss_AVR-NET-IO | DS1820 im parasitären Modus]]. * ZIEL: Die Ausgabe einer Temperaturvariable via integrierten Webbrowser oder telnet. * ZIEL: Die Firmware muss via Netzwerk neu flashbar sein. * Abgeändertes vereinfachtes [http://www.lochraster.org/etherrape/ etherrape] Board. * Zwei Spannungsregler, ein atmega644p, ein enc28j60, und etwas 0805 Hühnerfutter. ===Schaltung=== Das Layout passt in folgendes Gehäuse. Vorher am besten nochmal genau nachmessen. ;)<br> Conrad Bestell-Nr.: [https://www.conrad.at/de/hutschienen-gehaeuse-90-x-360-x-58-polycarbonat-axxatronic-cnmb-2-kit-con-1-st-531441.html 531441] / Axxatronic CNMB-2-KIT-CON <div><ul> <li style="display: inline-block;"> [[File:Sch_tempmess.png|thumb|none|210px|Schaltung]] </li> <li style="display: inline-block;"> [[File:Pcb_tempmess.png|thumb|none|280px|Layout]] </li> </ul></div> * Erstellt mit Eagle Version 7.1.0 für Windows * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_schematic_001.pdf PDF Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_layout_001.pdf PDF Layout gespiegelt] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.sch Eagle Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.brd Eagle Layout] ===Software=== Ethersex (Linux) - https://github.com/ethersex/ethersex Avrdude (Windows) - http://download.savannah.gnu.org/releases/avrdude/ (avrdude-6.1-mingw32.zip) tftpd (Windows) - http://tftpd32.jounin.net/tftpd32_download.html (v4.52 tftpd64 standard edition (zip)) ===Firmware/Bootloader=== Die ethersex Firmware selbst wird für zwei Sachen verwendet. Den <b>Bootloader</b> UND die <b>Firmware</b>. Der Bootloader wird sozusagen einmal in den ersten Bereich des Mikrocontrollers geschrieben und bleibt dort auch. Er wird später die Firmware via Netzwerk entgegennehmen und in den Controller schreiben. Somit befindet sich in den ersten 10% unser Bootloader und in den restlichen 90% der Code den wir wollen. Das zu Verstehen war für mich an Anfang der schwierigste Teil, ist aber dann doch sehr einfach. Ich kann somit ohne ISP-Programmer eine Firmware in den Controller schreiben. Hier grob noch die nächsten Schritte: * Als erstes ist der Bootloader zu konfigurieren, dann via ISP zu programmieren. * Der ISP-Programmer wegräumen. ;) * Als zweites ist die Firmware zu konfigurieren, dann holt sich der Bootloader unsere Firmware via Netzerk/tftpd. =BOOTLOADER= ===Bootloader bauen=== <div><ul> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess01.png|thumb|none|200px|Putty Bild 1]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess02.png|thumb|none|200px|Putty Bild 2]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess03.png|thumb|none|200px|Putty Bild 3]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess04.png|thumb|none|200px|Putty Bild 4]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess05.png|thumb|none|200px|Putty Bild 5]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess06.png|thumb|none|200px|Putty Bild 6]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess07.png|thumb|none|200px|Putty Bild 7]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess08.png|thumb|none|200px|Putty Bild 8]] </li> </ul></div> Ab nun befinde ich mich auf einem <b>virtuellen Debian Rechner</b> wo ich die Firmware herunterlade und daraus den Bootloader erstelle.<br> <b>WICHTIG:</b> Die IP und MAC-Adresse müssen natürlich verändert werden. Die selbe IP und MAC-Adresse müssen in der Firmware später auch benutzt werden. <br> * Bei einem neuen Debian System müssen mit "apt-get" ein paar Sachen nachinstalliert werden. Hier zu finden [[Preparation_(Deutsch)]] * So eine art DHCP wäre auch möglich, nennt sich [[BOOTP_(Deutsch) | BOOTP]]. Darauf gehe ich hier nicht ein. # cd /home/avr/ # mkdir ethersex_IP_60 // Mein "Arbeitsordner" # cd ethersex_IP_60/ // Ordner für das Board mit der IP 192.168.123.60 # git clone git://github.com/ethersex/ethersex.git // ethersex Firmware herunterladen Cloning into ethersex... remote: Counting objects: 37366, done. remote: Total 37366 (delta 0), reused 0 (delta 0), pack-reused 37366 Receiving objects: 100% (37366/37366), 11.27 MiB | 1.22 MiB/s, done. Resolving deltas: 100% (26538/26538), done. # cp -r ethersex bootloader // Ich kopiere den ethersex Ordner zu dem bootloader Ordner. 1:1 Kopie # cd bootloader/ // In den Bootloader Ordner wechseln # make menuconfig // Einstellungen für Bootloader im nächsten Schritt │ │ Load a Default Configuration ---> │ │ (*) Ethernet Bootloader │ │ General Setup ---> │ │ (ATmega644) Target MCU │ │ (20000000) MCU frequency │ │ [*] Build a bootloader │ │ [*] Teensy build │ │ Network ---> │ │ Hostname: "esex060" // Hostname ändern │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" // MAC ändern mit "Randomize MAC address" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" // Wenn IP nicht vorhanden BOOTP deaktivieren! │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ [ ] BOOTP (DHCP-like) support // BOOTP deaktivieren! │ │ Applications ---> │ │ [*] TFTP support ---> │ │ [*] TFTP-o-matic │ │ TFTP-server IPv4 address: "192.168.123.233" // Server wo TFTPD läuft │ │ TFTP image to load: "esex060.bin" // Diesen Dateinamen ladet später unser Board via Netzwerk/tftpd jetzt noch EXIT und SPEICHERN. # make clean && make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 5902/8192 bytes (72.4%) [=====================---------] Program (.text + .data) : 5902 bytes Data (.data + .bss) : 1902 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.hex</b> ===Bootloader flashen via ISP=== <div><ul> <li style="display: inline-block;"> [[File:Avrdude tempmess01.png|thumb|none|200px|avrdude Bild 1]] </li> <li style="display: inline-block;"> [[File:Avrdude tempmess01.png|thumb|none|200px|avrdude Bild 2]] </li> <li style="display: inline-block;"> [[File:Avrdude tempmess01.png|thumb|none|200px|avrdude Bild 3]] </li> <li style="display: inline-block;"> [[File:Avrdude tempmess01.png|thumb|none|200px|avrdude Bild 4]] </li> </ul></div> Ich flashe hier einfacher weise mit meinem Windows 7 Notebook. Ich habe avrdude einfach unter C:\ liegen. Dort kopiere ich nun die ethersex.hex hin.<br> Somit kann man mit dem flashen den Bootloaders loslegen. avrdude -cusbasp -pm644p -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m // gilt nur für atmega644p und vermutlich auch 644 avrdude -cusbasp -pm644p -U flash:w:ethersex.hex avrdude -cusbasp -pm644p -U lock:w:0x0F:m Der Mikrocontrollerboard ist nun vorbereitet für die eigentliche Firmware. Der ISP-Programmer kann nun bei Seite gelegt werden und wird soweit alles richtig konfiguriert ist auch nicht mehr benötigt.<br> Nun erfolgt das Erstellen der Firmware. =FIRMWARE= ===Firmware bauen=== <div><ul> <li style="display: inline-block;"> [[File:Putty_c6_m4_tempmess01.png|thumb|none|200px|c6_m4 Bild 1]] </li> <li style="display: inline-block;"> [[File:Putty_c6_m4_tempmess02.png|thumb|none|200px|c6_m4 Bild 2]] </li> <li style="display: inline-block;"> [[File:Putty_c6_m4_tempmess03.png|thumb|none|200px|c6_m4 Bild 3]] </li> </ul></div> * <b>WICHTIG:</b> IP, MAC Adresse, Gateway, Netmask, Hostname <b>MUSS</b> gleich sein wie bei dem Bootloader! * Der integrierte Webserver ist in der original Firmware schon aktiviert. ( Applications --> [*] HTTP Server ) # cd /home/avr/ethersex_IP_60/ # cd ethersex/ # make menuconfig │ │ Load a Default Configuration ---> │ │ (*) Etherrape │ │ General Setup ---> │ │ (ATmega644) Target MCU // atmega644p bei mir │ │ (20000000) MCU frequency // 20MHz Quarz │ │ [ ] VFS (Virtual File System) support // Benötige ich hier nicht. │ │ [*] control6 script // Hier wird unsere DS1820 Temperatur in eine Variable geschrieben für den implementieren Webserver. │ │ Network ---> // WICHTIG: IP, MAC Adresse, Gateway, Netmask, Hostname MUSS gleich sein wie bei dem Bootloader! │ │ Hostname: "esex060" │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" │ │ Netmask: "255.255.255.0" │ │ │ │ Default gateway: "192.168.123.10" │ │ I/O ---> │ │ [*] Onewire support ---> // Die allgemeine Onewire Unterstützung. │ │ [*] Onewire device detection support // Automatische Bauteilerkennung In der etherrape.m4 Datei wird nun noch der Pin des atmega geändert wo der DS1820 angeschlossen ist. Im NANO Editor wird mit "STRG-O dann Enter" gespeichert und mit STRG-X beendet. # nano pinning/hardware/etherrape.m4 // editieren der m4 Datei ----- ONEWIRE PIN ändern bei "ONEWIRE_PORT_RANGE(PD6, PD6)" zb. auf PD0 ----- Nun schreiben wir uns ein Script welches den Temperatursensor regelmäßig abfragt und in eine Globale Variable schiebt. # rm control6/control6.src // Original Datei löschen # nano control6/control6.src // Anlegen der c6 Datei. Die Datei ist nun neu und leer. C6_HEADER(`/* This will be in control6.h */') CONTROL_START ECMD_GLOBAL(temp01, 0, uint16_t); THREAD(start) temp01 = ONEWIRE_GET(1054698802080017); // Die ID muss vorher aus dem Sensor ausgelesen werden. Erklärung ganz am Schluss. WAIT(5) THREAD_END(start) ON STARTUP DO THREAD_START(start) END CONTROL_END Kompilieren der eigentlichen Firmware. # make clean && make // Befehl zum bereinigen & kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 24072/65536 bytes (36.73%) [===========-------------------] Program (.text + .data) : 24072 bytes Data (.data + .bss) : 2250 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.bin</b> Die eigentliche Firmware ist nun kompiliert und fertig um via Netzwerk/tftpd aufgespielt zu werden. Ich verwende im folgenden Schritt Windows 7. Beschreibung im nächsten Schritt. ===Firmware flashen via TFTPD=== <div><ul> <li style="display: inline-block;"> [[File:Tftpd_tempmess01.png|thumb|none|130px|tftpd Bild 1]] </li> <li style="display: inline-block;"> [[File:Tftpd_tempmess02.png|thumb|none|130px|tftpd Bild 2]] </li> <li style="display: inline-block;"> [[File:Tftpd_tempmess03.png|thumb|none|200px|tftpd Bild 3]] </li> <li style="display: inline-block;"> [[File:Tftpd_tempmess04.png|thumb|none|180px|tftpd Bild 4]] </li> </ul></div> Nun ladet ihr euch [http://tftpd32.jounin.net/tftpd32_download.html tftpd] herunter und entpackt es. Ich habe dazu einen Ordner Namens "tftpd" in mein Benutzerverzeichnis "C:\Users\BANANE\tftpd\". Dort wird alles hinein kopiert.<br> Es muss eigentlich nicht viel eingestellt werden. Unter <b>GLOBAL</b> muss TFTP aktiviert sein und unter <b>TFTP</b> sollte das "Base Directory" angepasst werden. Eventuell noch die Bind IP berichtigen. Seht Ihr ja auf den Fotos. Jetzt das Programm noch einmal neu starten. * Mikrocontrollerplatine ist <b>abgesteckt</b>. * tftpd starten * die Datei vom vorigen Schritt in den tftpd Ordner kopieren. <b>ethersex.bin</b> * ethersex.bin umbenennen in "<b>esex060.bin</b>". * Mikrocontrollerplatine Einstecken. Jetzt sollte auch schon was passieren, wie auf Bild 4 zu sehen ist. * Der Mikrocontroller ist nun via Webinterface erreichbar. Es können nur ecmd Befehle entgegengenommen werden. * erste Testverbindung zu unserem Mikrocontroller - http://192.168.123.60/ecmd?help ----AUSGABE---- c6 get c6 set wdreset .... 1w list 1w get 1w convert help version * <b>Sollten wir eine neue Firmware kompiliert haben können wir den Controller via Webinterface neu starten. Befehl dazu ist "wdreset"</b>. * Also neue esex060.bin wieder in den tftpd Ordner kopieren, tftpd starten und via Web "wdreset" ausführen. * http://192.168.123.60/ecmd?wdreset * Nun ladet sich der Controller die esex060.bin wieder via tftpd. ===Hinweise=== ''- Bei meiner Firewall musste ich tftpd noch akzeptieren. tftpd hing beim ersten mal in einer Schleife.'' ''- Und nochmals via Netzwerk wird die .bin geflasht, nicht die .hex Datei!'' =ONEWIRE= ===Auslesen der Sensor ID=== * Die ID kann via Webinterface mit dem Befehl "1w list" ausgelesen werden. * [http://192.168.123.60/ecmd?1w%20list http://192.168.123.60/ecmd?1w list] ----AUSGABE---- 1054698802080017 OK * Nun könnt Ihr die richtige ID oben im Control6 Script einsetzten und die Firmware neu kompilieren. * Wir haben im C6 Script eine Temperatur variable definiert welche "temp01" lautet. * Aktualisiert wird die Variable alle 5 Sekunden, das ist ebenfalls im C6 Script angegeben. * Diese kann ich nun via Webinterface abfragen - [http://192.168.123.60/ecmd?c6%20get%20temp01 http://192.168.123.60/ecmd?c6 get temp01] ----AUSGABE---- temp01 241 // 24.1 Grad [[User_talk:Djmaster#1 | Todoliste]] [[Category:Tutorials]] db4b6cf763ef413ec74585470e0831dd59d18d4b 1654 1653 2016-01-30T18:20:32Z Djmaster 255 wikitext text/x-wiki {{i18n|Temperaturmesssystem}} [[File:Tempmess_pcb_01.jpg|thumb|250px|meine Testplatine, Layout stimmt bis auf Kleinigkeiten überein]] [[File:Tempmess_pcb_02.jpg|thumb|250px|Testplatine beim Programmieren mit avrdude via ISP]] =PROJEKT Temperaturmessung= ===Einleitung=== * ZIEL: Eine einfache Temperaturmessung mit dem [[Onewire_(Deutsch)#Anschluss_AVR-NET-IO | DS1820 im parasitären Modus]]. * ZIEL: Die Ausgabe einer Temperaturvariable via integrierten Webbrowser oder telnet. * ZIEL: Die Firmware muss via Netzwerk neu flashbar sein. * Abgeändertes vereinfachtes [http://www.lochraster.org/etherrape/ etherrape] Board. * Zwei Spannungsregler, ein atmega644p, ein enc28j60, und etwas 0805 Hühnerfutter. ===Schaltung=== Das Layout passt in folgendes Gehäuse. Vorher am besten nochmal genau nachmessen. ;)<br> Conrad Bestell-Nr.: [https://www.conrad.at/de/hutschienen-gehaeuse-90-x-360-x-58-polycarbonat-axxatronic-cnmb-2-kit-con-1-st-531441.html 531441] / Axxatronic CNMB-2-KIT-CON <div><ul> <li style="display: inline-block;"> [[File:Sch_tempmess.png|thumb|none|210px|Schaltung]] </li> <li style="display: inline-block;"> [[File:Pcb_tempmess.png|thumb|none|280px|Layout]] </li> </ul></div> * Erstellt mit Eagle Version 7.1.0 für Windows * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_schematic_001.pdf PDF Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess_layout_001.pdf PDF Layout gespiegelt] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.sch Eagle Schaltung] * [http://wiki.senseye.org/etherwiki/tempmesssystem/tempmess001.brd Eagle Layout] ===Software=== Ethersex (Linux) - https://github.com/ethersex/ethersex Avrdude (Windows) - http://download.savannah.gnu.org/releases/avrdude/ (avrdude-6.1-mingw32.zip) tftpd (Windows) - http://tftpd32.jounin.net/tftpd32_download.html (v4.52 tftpd64 standard edition (zip)) ===Firmware/Bootloader=== Die ethersex Firmware selbst wird für zwei Sachen verwendet. Den <b>Bootloader</b> UND die <b>Firmware</b>. Der Bootloader wird sozusagen einmal in den ersten Bereich des Mikrocontrollers geschrieben und bleibt dort auch. Er wird später die Firmware via Netzwerk entgegennehmen und in den Controller schreiben. Somit befindet sich in den ersten 10% unser Bootloader und in den restlichen 90% der Code den wir wollen. Das zu Verstehen war für mich an Anfang der schwierigste Teil, ist aber dann doch sehr einfach. Ich kann somit ohne ISP-Programmer eine Firmware in den Controller schreiben. Hier grob noch die nächsten Schritte: * Als erstes ist der Bootloader zu konfigurieren, dann via ISP zu programmieren. * Der ISP-Programmer wegräumen. ;) * Als zweites ist die Firmware zu konfigurieren, dann holt sich der Bootloader unsere Firmware via Netzerk/tftpd. =BOOTLOADER= ===Bootloader bauen=== <div><ul> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess01.png|thumb|none|200px|Putty Bild 1]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess02.png|thumb|none|200px|Putty Bild 2]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess03.png|thumb|none|200px|Putty Bild 3]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess04.png|thumb|none|200px|Putty Bild 4]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess05.png|thumb|none|200px|Putty Bild 5]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess06.png|thumb|none|200px|Putty Bild 6]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess07.png|thumb|none|200px|Putty Bild 7]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess08.png|thumb|none|200px|Putty Bild 8]] </li> </ul></div> Ab nun befinde ich mich auf einem <b>virtuellen Debian Rechner</b> wo ich die Firmware herunterlade und daraus den Bootloader erstelle.<br> <b>WICHTIG:</b> Die IP und MAC-Adresse müssen natürlich verändert werden. Die selbe IP und MAC-Adresse müssen in der Firmware später auch benutzt werden. <br> * Bei einem neuen Debian System müssen mit "apt-get" ein paar Sachen nachinstalliert werden. Hier zu finden [[Quick_Start_Guide/Preparation_(Deutsch)]] * So eine art DHCP wäre auch möglich, nennt sich [[BOOTP_(Deutsch) | BOOTP]]. Darauf gehe ich hier nicht ein. # cd /home/avr/ # mkdir ethersex_IP_60 // Mein "Arbeitsordner" # cd ethersex_IP_60/ // Ordner für das Board mit der IP 192.168.123.60 # git clone git://github.com/ethersex/ethersex.git // ethersex Firmware herunterladen Cloning into ethersex... remote: Counting objects: 37366, done. remote: Total 37366 (delta 0), reused 0 (delta 0), pack-reused 37366 Receiving objects: 100% (37366/37366), 11.27 MiB | 1.22 MiB/s, done. Resolving deltas: 100% (26538/26538), done. # cp -r ethersex bootloader // Ich kopiere den ethersex Ordner zu dem bootloader Ordner. 1:1 Kopie # cd bootloader/ // In den Bootloader Ordner wechseln # make menuconfig // Einstellungen für Bootloader im nächsten Schritt │ │ Load a Default Configuration ---> │ │ (*) Ethernet Bootloader │ │ General Setup ---> │ │ (ATmega644) Target MCU │ │ (20000000) MCU frequency │ │ [*] Build a bootloader │ │ [*] Teensy build │ │ Network ---> │ │ Hostname: "esex060" // Hostname ändern │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" // MAC ändern mit "Randomize MAC address" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" // Wenn IP nicht vorhanden BOOTP deaktivieren! │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ [ ] BOOTP (DHCP-like) support // BOOTP deaktivieren! │ │ Applications ---> │ │ [*] TFTP support ---> │ │ [*] TFTP-o-matic │ │ TFTP-server IPv4 address: "192.168.123.233" // Server wo TFTPD läuft │ │ TFTP image to load: "esex060.bin" // Diesen Dateinamen ladet später unser Board via Netzwerk/tftpd jetzt noch EXIT und SPEICHERN. # make clean && make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 5902/8192 bytes (72.4%) [=====================---------] Program (.text + .data) : 5902 bytes Data (.data + .bss) : 1902 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.hex</b> ===Bootloader flashen via ISP=== <div><ul> <li style="display: inline-block;"> [[File:Avrdude tempmess01.png|thumb|none|200px|avrdude Bild 1]] </li> <li style="display: inline-block;"> [[File:Avrdude tempmess01.png|thumb|none|200px|avrdude Bild 2]] </li> <li style="display: inline-block;"> [[File:Avrdude tempmess01.png|thumb|none|200px|avrdude Bild 3]] </li> <li style="display: inline-block;"> [[File:Avrdude tempmess01.png|thumb|none|200px|avrdude Bild 4]] </li> </ul></div> Ich flashe hier einfacher weise mit meinem Windows 7 Notebook. Ich habe avrdude einfach unter C:\ liegen. Dort kopiere ich nun die ethersex.hex hin.<br> Somit kann man mit dem flashen den Bootloaders loslegen. avrdude -cusbasp -pm644p -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m // gilt nur für atmega644p und vermutlich auch 644 avrdude -cusbasp -pm644p -U flash:w:ethersex.hex avrdude -cusbasp -pm644p -U lock:w:0x0F:m Der Mikrocontrollerboard ist nun vorbereitet für die eigentliche Firmware. Der ISP-Programmer kann nun bei Seite gelegt werden und wird soweit alles richtig konfiguriert ist auch nicht mehr benötigt.<br> Nun erfolgt das Erstellen der Firmware. =FIRMWARE= ===Firmware bauen=== <div><ul> <li style="display: inline-block;"> [[File:Putty_c6_m4_tempmess01.png|thumb|none|200px|c6_m4 Bild 1]] </li> <li style="display: inline-block;"> [[File:Putty_c6_m4_tempmess02.png|thumb|none|200px|c6_m4 Bild 2]] </li> <li style="display: inline-block;"> [[File:Putty_c6_m4_tempmess03.png|thumb|none|200px|c6_m4 Bild 3]] </li> </ul></div> * <b>WICHTIG:</b> IP, MAC Adresse, Gateway, Netmask, Hostname <b>MUSS</b> gleich sein wie bei dem Bootloader! * Der integrierte Webserver ist in der original Firmware schon aktiviert. ( Applications --> [*] HTTP Server ) # cd /home/avr/ethersex_IP_60/ # cd ethersex/ # make menuconfig │ │ Load a Default Configuration ---> │ │ (*) Etherrape │ │ General Setup ---> │ │ (ATmega644) Target MCU // atmega644p bei mir │ │ (20000000) MCU frequency // 20MHz Quarz │ │ [ ] VFS (Virtual File System) support // Benötige ich hier nicht. │ │ [*] control6 script // Hier wird unsere DS1820 Temperatur in eine Variable geschrieben für den implementieren Webserver. │ │ Network ---> // WICHTIG: IP, MAC Adresse, Gateway, Netmask, Hostname MUSS gleich sein wie bei dem Bootloader! │ │ Hostname: "esex060" │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" │ │ Netmask: "255.255.255.0" │ │ │ │ Default gateway: "192.168.123.10" │ │ I/O ---> │ │ [*] Onewire support ---> // Die allgemeine Onewire Unterstützung. │ │ [*] Onewire device detection support // Automatische Bauteilerkennung In der etherrape.m4 Datei wird nun noch der Pin des atmega geändert wo der DS1820 angeschlossen ist. Im NANO Editor wird mit "STRG-O dann Enter" gespeichert und mit STRG-X beendet. # nano pinning/hardware/etherrape.m4 // editieren der m4 Datei ----- ONEWIRE PIN ändern bei "ONEWIRE_PORT_RANGE(PD6, PD6)" zb. auf PD0 ----- Nun schreiben wir uns ein Script welches den Temperatursensor regelmäßig abfragt und in eine Globale Variable schiebt. # rm control6/control6.src // Original Datei löschen # nano control6/control6.src // Anlegen der c6 Datei. Die Datei ist nun neu und leer. C6_HEADER(`/* This will be in control6.h */') CONTROL_START ECMD_GLOBAL(temp01, 0, uint16_t); THREAD(start) temp01 = ONEWIRE_GET(1054698802080017); // Die ID muss vorher aus dem Sensor ausgelesen werden. Erklärung ganz am Schluss. WAIT(5) THREAD_END(start) ON STARTUP DO THREAD_START(start) END CONTROL_END Kompilieren der eigentlichen Firmware. # make clean && make // Befehl zum bereinigen & kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 24072/65536 bytes (36.73%) [===========-------------------] Program (.text + .data) : 24072 bytes Data (.data + .bss) : 2250 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.bin</b> Die eigentliche Firmware ist nun kompiliert und fertig um via Netzwerk/tftpd aufgespielt zu werden. Ich verwende im folgenden Schritt Windows 7. Beschreibung im nächsten Schritt. ===Firmware flashen via TFTPD=== <div><ul> <li style="display: inline-block;"> [[File:Tftpd_tempmess01.png|thumb|none|130px|tftpd Bild 1]] </li> <li style="display: inline-block;"> [[File:Tftpd_tempmess02.png|thumb|none|130px|tftpd Bild 2]] </li> <li style="display: inline-block;"> [[File:Tftpd_tempmess03.png|thumb|none|200px|tftpd Bild 3]] </li> <li style="display: inline-block;"> [[File:Tftpd_tempmess04.png|thumb|none|180px|tftpd Bild 4]] </li> </ul></div> Nun ladet ihr euch [http://tftpd32.jounin.net/tftpd32_download.html tftpd] herunter und entpackt es. Ich habe dazu einen Ordner Namens "tftpd" in mein Benutzerverzeichnis "C:\Users\BANANE\tftpd\". Dort wird alles hinein kopiert.<br> Es muss eigentlich nicht viel eingestellt werden. Unter <b>GLOBAL</b> muss TFTP aktiviert sein und unter <b>TFTP</b> sollte das "Base Directory" angepasst werden. Eventuell noch die Bind IP berichtigen. Seht Ihr ja auf den Fotos. Jetzt das Programm noch einmal neu starten. * Mikrocontrollerplatine ist <b>abgesteckt</b>. * tftpd starten * die Datei vom vorigen Schritt in den tftpd Ordner kopieren. <b>ethersex.bin</b> * ethersex.bin umbenennen in "<b>esex060.bin</b>". * Mikrocontrollerplatine Einstecken. Jetzt sollte auch schon was passieren, wie auf Bild 4 zu sehen ist. * Der Mikrocontroller ist nun via Webinterface erreichbar. Es können nur ecmd Befehle entgegengenommen werden. * erste Testverbindung zu unserem Mikrocontroller - http://192.168.123.60/ecmd?help ----AUSGABE---- c6 get c6 set wdreset .... 1w list 1w get 1w convert help version * <b>Sollten wir eine neue Firmware kompiliert haben können wir den Controller via Webinterface neu starten. Befehl dazu ist "wdreset"</b>. * Also neue esex060.bin wieder in den tftpd Ordner kopieren, tftpd starten und via Web "wdreset" ausführen. * http://192.168.123.60/ecmd?wdreset * Nun ladet sich der Controller die esex060.bin wieder via tftpd. ===Hinweise=== ''- Bei meiner Firewall musste ich tftpd noch akzeptieren. tftpd hing beim ersten mal in einer Schleife.'' ''- Und nochmals via Netzwerk wird die .bin geflasht, nicht die .hex Datei!'' =ONEWIRE= ===Auslesen der Sensor ID=== * Die ID kann via Webinterface mit dem Befehl "1w list" ausgelesen werden. * [http://192.168.123.60/ecmd?1w%20list http://192.168.123.60/ecmd?1w list] ----AUSGABE---- 1054698802080017 OK * Nun könnt Ihr die richtige ID oben im Control6 Script einsetzten und die Firmware neu kompilieren. * Wir haben im C6 Script eine Temperatur variable definiert welche "temp01" lautet. * Aktualisiert wird die Variable alle 5 Sekunden, das ist ebenfalls im C6 Script angegeben. * Diese kann ich nun via Webinterface abfragen - [http://192.168.123.60/ecmd?c6%20get%20temp01 http://192.168.123.60/ecmd?c6 get temp01] ----AUSGABE---- temp01 241 // 24.1 Grad [[User_talk:Djmaster#1 | Todoliste]] [[Category:Tutorials]] f357a4bf494b5fdb9795dae7bdb7e2337d1d147b 6 523 1607 2016-01-30T14:31:40Z Kpwg 721 taken from old wiki wikitext text/x-wiki taken from old wiki 5d2d9155505ad5afc04e47e9a12b9f122e62774c 6 524 1608 2016-01-30T14:32:15Z Kpwg 721 taken from old wiki wikitext text/x-wiki taken from old wiki 5d2d9155505ad5afc04e47e9a12b9f122e62774c 6 525 1609 2016-01-30T14:32:56Z Kpwg 721 taken from old wiki wikitext text/x-wiki taken from old wiki 5d2d9155505ad5afc04e47e9a12b9f122e62774c 6 526 1610 2016-01-30T14:35:15Z Kpwg 721 taken from old wiki wikitext text/x-wiki taken from old wiki 5d2d9155505ad5afc04e47e9a12b9f122e62774c 6 527 1611 2016-01-30T14:35:37Z Kpwg 721 taken from old wiki wikitext text/x-wiki taken from old wiki 5d2d9155505ad5afc04e47e9a12b9f122e62774c 6 528 1612 2016-01-30T14:36:14Z Kpwg 721 taken from old wiki wikitext text/x-wiki taken from old wiki 5d2d9155505ad5afc04e47e9a12b9f122e62774c 6 529 1613 2016-01-30T14:37:09Z Kpwg 721 taken from old wiki wikitext text/x-wiki taken from old wiki 5d2d9155505ad5afc04e47e9a12b9f122e62774c 6 530 1614 2016-01-30T14:37:33Z Kpwg 721 taken from old wiki wikitext text/x-wiki taken from old wiki 5d2d9155505ad5afc04e47e9a12b9f122e62774c 6 531 1615 2016-01-30T14:37:58Z Kpwg 721 taken from old wiki wikitext text/x-wiki taken from old wiki 5d2d9155505ad5afc04e47e9a12b9f122e62774c 6 532 1616 2016-01-30T14:38:27Z Kpwg 721 taken from old wiki wikitext text/x-wiki taken from old wiki 5d2d9155505ad5afc04e47e9a12b9f122e62774c 6 533 1617 2016-01-30T14:39:04Z Kpwg 721 taken from old wiki wikitext text/x-wiki taken from old wiki 5d2d9155505ad5afc04e47e9a12b9f122e62774c 6 534 1618 2016-01-30T14:39:31Z Kpwg 721 taken from old wiki wikitext text/x-wiki taken from old wiki 5d2d9155505ad5afc04e47e9a12b9f122e62774c 6 535 1619 2016-01-30T14:39:53Z Kpwg 721 taken from old wiki wikitext text/x-wiki taken from old wiki 5d2d9155505ad5afc04e47e9a12b9f122e62774c 6 536 1620 2016-01-30T14:40:16Z Kpwg 721 taken from old wiki wikitext text/x-wiki taken from old wiki 5d2d9155505ad5afc04e47e9a12b9f122e62774c 6 537 1621 2016-01-30T14:40:35Z Kpwg 721 taken from old wiki wikitext text/x-wiki taken from old wiki 5d2d9155505ad5afc04e47e9a12b9f122e62774c 0 439 1622 1385 2016-01-30T15:11:35Z Kpwg 721 /* Conrad Probot */ wikitext text/x-wiki {{i18n|Conrad Probot}} {{i18n|Conrad Probot}} Der Support für den [https://www.conrad.de/de/beratung/markenshops/c-control/c-robotics.html Probot von Conrad] ist noch experimentell! [[File:Conrad-probot.jpg|thumb|right]] == make menuconfig == In menuconfig sollte man folgendes einstellen: * Target MCU: atmega128 * MCU Frequency: 14745000 * Hardware/Periphery Class: Conrad:Probot * Named and logic state I/O * I2C Master Support (mit I2C Detection Support und I2C EEPROM (24cxx) Support) * ADC Referenzspannung ist AVCC == Named Pin Konfiguration == Hier die passende core/portio/config für [[Named PIN_(Deutsch) | Named PIN]] * Named Pin muss aktiviert sein! # # Named Pin Configuration File # # You can assign names to your microcontroller's pins here. # Keep in mind that this names must consist of alphanumeric # characters only! # # Every line starting with a hash sign (#) is a comment. # # # PIN | IN/OUT | When active? | Name #-----+--------+--------------+---------------- PB0 OUTPUT LOW encoder_ir # led for encoder_right AND encoder_left PB4 OUTPUT HIGH beep PB5 OUTPUT HIGH motor_right PB6 OUTPUT HIGH motor_left PB7 OUTPUT HIGH motor_enable PC0 OUTPUT LOW led_back_right PC1 OUTPUT LOW led_back_left PC2 OUTPUT LOW led_front_right PC3 OUTPUT LOW led_front_left PC4 OUTPUT LOW led_line_sensor PD2 INPUT HIGH tsop PD3 OUTPUT LOW ir_left # together with pwm_ir PD4 OUTPUT LOW ir_right # together with pwm_ir PE3 OUTPUT HIGH pwm_ir # pwm for ir_left AND ir_right PE4 INPUT HIGH boot #test invert action PE6 INPUT LOW encoder_right # ? PE7 INPUT LOW encoder_left # ? PF5 INPUT LOW ldr_right # active? PF4 INPUT LOW ldr_left # active? PF3 INPUT HIGH mic PF2 INPUT HIGH line_sensor_right PF1 INPUT HIGH line_sensor_left PF0 INPUT HIGH ub_measurement == Control6 Scripte == Einen Einstieg in [[Control6_(Deutsch) | Control6]] gibt es auch auf der Seite für [[PIN_Commands_(Deutsch) | PIN_Commands]] === Beispiel für ein [[Control6_(Deutsch) | Control6]] mit Named Pin=== * Script unter control6/control6.src * control6 muss aktiviert sein! * [[Named PIN_(Deutsch) | Named PIN]] muss aktiviert sein! Die 4 LEDs der Hauptplatine blinken alle der Reihe nach THREAD(blinkrun) PIN_SET(led_front_left); PIN_CLEAR(led_back_left); WAIT(1); PIN_SET(led_back_left); PIN_CLEAR(led_back_right); WAIT(1); PIN_SET(led_back_right); PIN_CLEAR(led_front_right); WAIT(1); PIN_SET(led_front_right); PIN_CLEAR(led_front_left); WAIT(1); THREAD_END(blinkrun) THREAD_START(blinkrun) == Funktionstüchtig == Wichtig ist das man AVCC als Referenzspannung für die ADC Eingänge einstellt, sonst geben die Sensoren nichts sinnvolles zurück. === Main Unit === * [[I2C_(Deutsch) | I2C]] Bus * Serielle Schnittstelle für [[ECMD_(Deutsch) | ECMD]] (TTL Logik, daher Pegelwandler benutzen) * 4 Rote LEDs auf der Main Unit * Helligkeitssensoren mit [[ADC_(Deutsch) | ADC]] * Buzzer (Piezo Lautsprecher - sehr leise) getestet mit Melodyausgabe aus dem [[Sound_(Deutsch) | Sound]]-Modul === Drive Unit === * Motoren via H-Bridge angesteuert (Vor, Zurück, Rechts, Links) * Line Sensor mit [[ADC_(Deutsch) | ADC]] == Bilder == <gallery> Conrad-probot.jpg Habo_probot_drive_unit_top.jpg Habo_probot_drive_unit_top_bottom.jpg Habo_probot_front_view2.jpg Habo_probot_front_view3.jpg Habo_probot_main%2Bdrive_unit.jpg Habo_probot_main_unitbottom_mit_programmieradapter.jpg Habo_probot_main_unit_CPU_modul_ohne_Deckel.jpg Habo_probot_main_unit_top_mit_programmieradapter.jpg Habo_probot_mit_RFM12_modul.jpg Habo_probot_selfmade_breadboard.jpg Habo_rfm12_probot_modul1.jpg Habo_rfm12_probot_modul2.jpg Habo_probot_stackable.jpg Habo_probot_advanced.jpg Habo_probot_lights_on.jpg </gallery> [[Category:Hardware]] 83aae30b5e88b5bb0916f84bb4234567ab6229cb 1623 1622 2016-01-30T15:12:06Z Kpwg 721 wikitext text/x-wiki {{i18n|Conrad Probot}} Der Support für den [https://www.conrad.de/de/beratung/markenshops/c-control/c-robotics.html Probot von Conrad] ist noch experimentell! [[File:Conrad-probot.jpg|thumb|right]] == make menuconfig == In menuconfig sollte man folgendes einstellen: * Target MCU: atmega128 * MCU Frequency: 14745000 * Hardware/Periphery Class: Conrad:Probot * Named and logic state I/O * I2C Master Support (mit I2C Detection Support und I2C EEPROM (24cxx) Support) * ADC Referenzspannung ist AVCC == Named Pin Konfiguration == Hier die passende core/portio/config für [[Named PIN_(Deutsch) | Named PIN]] * Named Pin muss aktiviert sein! # # Named Pin Configuration File # # You can assign names to your microcontroller's pins here. # Keep in mind that this names must consist of alphanumeric # characters only! # # Every line starting with a hash sign (#) is a comment. # # # PIN | IN/OUT | When active? | Name #-----+--------+--------------+---------------- PB0 OUTPUT LOW encoder_ir # led for encoder_right AND encoder_left PB4 OUTPUT HIGH beep PB5 OUTPUT HIGH motor_right PB6 OUTPUT HIGH motor_left PB7 OUTPUT HIGH motor_enable PC0 OUTPUT LOW led_back_right PC1 OUTPUT LOW led_back_left PC2 OUTPUT LOW led_front_right PC3 OUTPUT LOW led_front_left PC4 OUTPUT LOW led_line_sensor PD2 INPUT HIGH tsop PD3 OUTPUT LOW ir_left # together with pwm_ir PD4 OUTPUT LOW ir_right # together with pwm_ir PE3 OUTPUT HIGH pwm_ir # pwm for ir_left AND ir_right PE4 INPUT HIGH boot #test invert action PE6 INPUT LOW encoder_right # ? PE7 INPUT LOW encoder_left # ? PF5 INPUT LOW ldr_right # active? PF4 INPUT LOW ldr_left # active? PF3 INPUT HIGH mic PF2 INPUT HIGH line_sensor_right PF1 INPUT HIGH line_sensor_left PF0 INPUT HIGH ub_measurement == Control6 Scripte == Einen Einstieg in [[Control6_(Deutsch) | Control6]] gibt es auch auf der Seite für [[PIN_Commands_(Deutsch) | PIN_Commands]] === Beispiel für ein [[Control6_(Deutsch) | Control6]] mit Named Pin=== * Script unter control6/control6.src * control6 muss aktiviert sein! * [[Named PIN_(Deutsch) | Named PIN]] muss aktiviert sein! Die 4 LEDs der Hauptplatine blinken alle der Reihe nach THREAD(blinkrun) PIN_SET(led_front_left); PIN_CLEAR(led_back_left); WAIT(1); PIN_SET(led_back_left); PIN_CLEAR(led_back_right); WAIT(1); PIN_SET(led_back_right); PIN_CLEAR(led_front_right); WAIT(1); PIN_SET(led_front_right); PIN_CLEAR(led_front_left); WAIT(1); THREAD_END(blinkrun) THREAD_START(blinkrun) == Funktionstüchtig == Wichtig ist das man AVCC als Referenzspannung für die ADC Eingänge einstellt, sonst geben die Sensoren nichts sinnvolles zurück. === Main Unit === * [[I2C_(Deutsch) | I2C]] Bus * Serielle Schnittstelle für [[ECMD_(Deutsch) | ECMD]] (TTL Logik, daher Pegelwandler benutzen) * 4 Rote LEDs auf der Main Unit * Helligkeitssensoren mit [[ADC_(Deutsch) | ADC]] * Buzzer (Piezo Lautsprecher - sehr leise) getestet mit Melodyausgabe aus dem [[Sound_(Deutsch) | Sound]]-Modul === Drive Unit === * Motoren via H-Bridge angesteuert (Vor, Zurück, Rechts, Links) * Line Sensor mit [[ADC_(Deutsch) | ADC]] == Bilder == <gallery> Conrad-probot.jpg Habo_probot_drive_unit_top.jpg Habo_probot_drive_unit_top_bottom.jpg Habo_probot_front_view2.jpg Habo_probot_front_view3.jpg Habo_probot_main%2Bdrive_unit.jpg Habo_probot_main_unitbottom_mit_programmieradapter.jpg Habo_probot_main_unit_CPU_modul_ohne_Deckel.jpg Habo_probot_main_unit_top_mit_programmieradapter.jpg Habo_probot_mit_RFM12_modul.jpg Habo_probot_selfmade_breadboard.jpg Habo_rfm12_probot_modul1.jpg Habo_rfm12_probot_modul2.jpg Habo_probot_stackable.jpg Habo_probot_advanced.jpg Habo_probot_lights_on.jpg </gallery> [[Category:Hardware]] 92ed6d30074b2aaa2ccbfa5a0225a72d3d7241c5 0 440 1624 1386 2016-01-30T15:16:43Z Kpwg 721 /* Fimser */ wikitext text/x-wiki {{i18n|Fimser}} == Fimser == [[File:Fimser.jpg|thumb]] aka (Fifi) Field Day Instant Messenger Der Fifi SMSer auch Fimser genannt ist ein Amateurfunk Device das Kurzmitteilungen über Funk versenden kann. Entstanden ist der Fimser als Bastelprojekt für die Fielddays des OV Lennestadt und kann von dem Verein auch erworben werden. Ursprüngliche Einstellungen: * Trac: http://o28.sischa.net/fimser/trac * Fuse: fuse: D9h, lfuse: 62h, efuse: 07h == Ethersex == Folgendes funktioniert bisher: * Speaker * LEDs * 20ms Periodic Call (interner Timer) * RFM12 (rfm12 status: 02xx) [[Category:Hardware]] f4e17e039aaed33d5e1d1f6a696d49b3d6349c3d 0 441 1625 1466 2016-01-30T15:32:13Z Kpwg 721 wikitext text/x-wiki {{i18n|JeeLink}} [[File:Jeelinkv2.jpg|thumb]] Das [http://jeelabs.org/jl2 JeeLink v2] ist ein kleines Atmega-Modul mit [[RFM12_(Deutsch) | RFM12]] in Form eines USB-Sticks. Es war von [http://jeelabs.org JeeLabs] aus Holland erhältlich für 29,50 EUR inkl. Versand. Mittlerweile gibt es zahlreiche Nachbauten auf Basis von [[https://www.arduino.cc/en/Main/ArduinoBoardNano | Arduino Nano]] und RFM12 bzw. RFM12b. Aktuelle JeeLink [http://www.digitalsmarties.net/products/jeelink (v3c)] werden aufgrund des verwendeten [[RFM69_(Deutsch) | RFM69]] Funkmoduls noch nicht von Ethersex unterstützt! ==Features== * Atmega 328p * RFM12B mit 868MHz * USB-Anbindung über FTDI FT232R * Atmel Dataflash AT26DF081A (1 MByte, derzeit in Ethersex nicht unterstützt) ==Flashen== * Das JeeLink-Modul wird fertig mit einem [http://www.arduino.cc/ Arduino]-kompatiblen seriellen Bootloader ausgeliefert * Der Bootloader wartet nach einem Reset ca. 1 Sek. auf entsprechende Kommandos, danach startet die normale Ethersex-Firmware * Über ein kleines Programm im contrib-Ordner kann ein Reset per Software ausgelöst werden: <source lang="bash"> ./contrib/arduino-bootloader/reset /dev/ttyUSB0 </source> * Dann mit avrdude flashen: <source lang="bash"> avrdude -v -v -p m328p -c arduino -P /dev/ttyUSB0 -b 57600 -U flash:w:ethersex.hex </source> <font color="red">ACHTUNG!</font> Bei der v3 funktioniert das flashen mit <source lang="bash"> avrdude -v -v -p m328p -c arduino -P /dev/ttyUSB0 -b 115200 -U flash:w:ethersex.hex </source> ==Anbindung in Ethersex== * In Ethersex ist eine fertige Konfiguration für das JeeLink enthalten * Dabei wird über den FT232R das [[ZBus_(Deutsch) | ZBUS]]-Protokoll gesprochen, Anbindung über [[ZBus_Serial_Host_(Deutsch) | ZBus Serial Host]] * Nach Verbinden des JeeLinks folgendes aufrufen: <source lang="bash"> ./contrib/zbus-serial-host/zbus-serial-host -r 57600 -d /dev/ttyUSB0 -a 192.168.23.1/24 </source> * Das JeeLink-Modul selbst ist jetzt unter 192.168.23.244 erreichbar * Das Funknetz liegt auf 192.168.5.0/24, wir müssen daher ein Routing definieren: <source lang="bash"> ip route add 192.168.5.0/24 via 192.168.23.244 </source> * Danach sind andere Ethersexe im Netz 192.168.5.0/24 über Funk erreichbar ==Adressierung== * In obigen Beispielen wurde angenommen, daß das JeeLink auf /dev/ttyUSB0 liegt * Je nach Reihenfolge des Einsteckens und anderen seriellen Geräten am USB kann es aber auch auf einem anderen Namen landen. Das ist für Dinge wie Initskripte aber natürlich unpraktisch. * [[https://wiki.ubuntuusers.de/udev/ | Hier ist beschrieben]], wie man dem JeeLink von udev immer einen festen Namen zuweisen lässt [[Category:Hardware]] [[Category:ZBus]] [[Category:USB]] [[Category:RFM12]] 1601229c50b34d77086b35b154cb463544fdfff9 1626 1625 2016-01-30T15:36:55Z Kpwg 721 /* Adressierung */ wikitext text/x-wiki {{i18n|JeeLink}} [[File:Jeelinkv2.jpg|thumb]] Das [http://jeelabs.org/jl2 JeeLink v2] ist ein kleines Atmega-Modul mit [[RFM12_(Deutsch) | RFM12]] in Form eines USB-Sticks. Es war von [http://jeelabs.org JeeLabs] aus Holland erhältlich für 29,50 EUR inkl. Versand. Mittlerweile gibt es zahlreiche Nachbauten auf Basis von [[https://www.arduino.cc/en/Main/ArduinoBoardNano | Arduino Nano]] und RFM12 bzw. RFM12b. Aktuelle JeeLink [http://www.digitalsmarties.net/products/jeelink (v3c)] werden aufgrund des verwendeten [[RFM69_(Deutsch) | RFM69]] Funkmoduls noch nicht von Ethersex unterstützt! ==Features== * Atmega 328p * RFM12B mit 868MHz * USB-Anbindung über FTDI FT232R * Atmel Dataflash AT26DF081A (1 MByte, derzeit in Ethersex nicht unterstützt) ==Flashen== * Das JeeLink-Modul wird fertig mit einem [http://www.arduino.cc/ Arduino]-kompatiblen seriellen Bootloader ausgeliefert * Der Bootloader wartet nach einem Reset ca. 1 Sek. auf entsprechende Kommandos, danach startet die normale Ethersex-Firmware * Über ein kleines Programm im contrib-Ordner kann ein Reset per Software ausgelöst werden: <source lang="bash"> ./contrib/arduino-bootloader/reset /dev/ttyUSB0 </source> * Dann mit avrdude flashen: <source lang="bash"> avrdude -v -v -p m328p -c arduino -P /dev/ttyUSB0 -b 57600 -U flash:w:ethersex.hex </source> <font color="red">ACHTUNG!</font> Bei der v3 funktioniert das flashen mit <source lang="bash"> avrdude -v -v -p m328p -c arduino -P /dev/ttyUSB0 -b 115200 -U flash:w:ethersex.hex </source> ==Anbindung in Ethersex== * In Ethersex ist eine fertige Konfiguration für das JeeLink enthalten * Dabei wird über den FT232R das [[ZBus_(Deutsch) | ZBUS]]-Protokoll gesprochen, Anbindung über [[ZBus_Serial_Host_(Deutsch) | ZBus Serial Host]] * Nach Verbinden des JeeLinks folgendes aufrufen: <source lang="bash"> ./contrib/zbus-serial-host/zbus-serial-host -r 57600 -d /dev/ttyUSB0 -a 192.168.23.1/24 </source> * Das JeeLink-Modul selbst ist jetzt unter 192.168.23.244 erreichbar * Das Funknetz liegt auf 192.168.5.0/24, wir müssen daher ein Routing definieren: <source lang="bash"> ip route add 192.168.5.0/24 via 192.168.23.244 </source> * Danach sind andere Ethersexe im Netz 192.168.5.0/24 über Funk erreichbar ==Adressierung== * In obigen Beispielen wurde angenommen, daß das JeeLink auf /dev/ttyUSB0 liegt * Je nach Reihenfolge des Einsteckens und anderen seriellen Geräten am USB kann es aber auch auf einem anderen Namen landen. Das ist für Dinge wie Initskripte aber natürlich unpraktisch. * [https://wiki.ubuntuusers.de/udev/ Hier ist beschrieben], wie man dem JeeLink von udev immer einen festen Namen zuweisen lässt [[Category:Hardware]] [[Category:ZBus]] [[Category:USB]] [[Category:RFM12]] 4b3d51d8e18440986b6c0d64bb6811d7003391fb 0 477 1627 1498 2016-01-30T15:37:53Z Kpwg 721 /* Hinweise / Praktische Erfahrungen */ wikitext text/x-wiki {{i18n|ZBus}} {{Module |NAME=ZBUS |MENUCONFIG=Network->ZBUS Support |STATUS={{stable}} |PINNING= - |ECMD={{has_ecmd}} |CONTROL6= - |DEPENDS=[[ECMD]] |REQUIRES= USART |TIMER= - |CODE=[https://github.com/ethersex/ethersex/tree/master/protocols/zbus https://github.com/ethersex/ethersex/tree/master/protocols/zbus] }} == Was ist ZBus? == ZBus ist ein auf [[wikipedia:RS485|RS485]] basierendes Zweidraht-Bussystem, auf welchem Pakete variabler Länge übermittelt werden können. Es wurde primär für die Datenübertragung zwischen Mikrocontrollern konzipiert, zum Beispiel zur Kommunikation von ATmega8 und ATmega644. Ethersex verwendet ZBus zur Übermittlung von IP-Paketen von einem Controller, der als Bridge fungiert, hin zu einzelnen kleineren ZBus-Geräten, die beispielsweise auf ATmega8 basieren. Der Einsatz von ZBus ermöglicht den großflächigen Einsatz von kleineren ATmega-Mikrocontrolleren, an die man in der Regel keinen ENC28J60 anschließen möchte. Zudem lässt sich zum Beispiel ein bestehendes Telefonkabelnetz verwenden, welches für LAN ungeeignet wäre. Ebendiese kleineren Controller können über eine Bridge hinweg via IP-Protokoll erreicht werden, zumindest über UDP und ICMP. Eine TCP/IP-Übertragung scheitert an den begrenzten Resourcen eines ATmega8, mit größeren Controllern ist jedoch auch TCP möglich. Als Bridge kann wahlweise ein entsprechend konfiguriertes Ethersex oder ein normaler Rechner mit serieller Schnittstelle, auf dem [[ZBus Serial Host_(Deutsch) | ZBus Serial Host]] läuft, eingesetzt werden. == Anschluss == [[File:ZBUS_bias_term.JPG|thumb|right|ATMega8 mit ZBUS]] [[File:Zbus_ttl.jpg|thumb|right|TTL-ZBus-Adapter mit MAX485, Terminierung und Bias-R's]] ==== prozessorseitige Beschaltung ==== Zur Anschaltung des ZBus wird ein Pegelwandler benötigt. Dabei wird an dieser Stelle ein preiswerter und moderner MAX485 verwendet, welcher sich durch minimale Außenbeschaltung und geringen Eigenstromverbrauch (etwa 1mA) auszeichnet. Damit ist zwar nur Halbduplexbetrieb möglich, was jedoch in den allermeisten Fällen genügt. Es werden drei Prozessorpins benötigt: TX, RX sowie die TX/RX-Umschaltung. ==== busseitige Beschaltung ==== Der Bus muss an beiden Enden mit 120 Ohm terminiert werden (R1) und sollte an einer Stelle mit Bias-Widerständen (R2 und R3) bestückt sein, damit definierte Pegel herrschen, wenn kein Sender aktiv ist. Diese beiden identischen Widerstände sind unkritisch; Werte zwischen 390 und 820 Ohm funktionieren problemlos. Es kann daher Busteilnehmer mit einem, zwei oder drei Widerständen geben; der flexibelste Busteilnehmer hat alle Widerstände mit Jumper aktivierbar. == Konfiguration == todo == Statusmonitor == Der ECMD-Befehl "zbus stats" ermöglicht die schnelle Beurteilung der Übertragungsqualität. Aktiviert wird er über das Debug-flag "ZBUS ecmd" im Menuconfig. Die beispielhafte Ausgabe bedeutet im Einzelnen: '''fe=2, ov=0, pe=0, bf=0, #=57736, tx #=45264''' {| border='1' | ''Wert'' | ''Beschreibung'' |- | rx fe | frame error |- | rx ov | overflow |- | rx pe | parity error |- | rx bf | buffer full |- | # | Summe empfangene Bytes |- | tx # | Summe gesendete Bytes |- |} == Hinweise / Praktische Erfahrungen == [[File:ZBus_Test.jpg|thumb|right|ZBus Testumgebung mit Gateway und Client]] * unterschiedliche Kabelarten sind zu vermeiden, da sich durch Stoßstellen die Signalqualität verschlechtert (Reflexionen); "fe" steigt * die Beschaltung der Terminierung und der Bias-R's muss experimentell ermittelt werden- hier sind deutliche Qualitätssteigerungen möglich * "Network Buffer Size" sollte maximiert werden; vor allem beim ZBus-LAN-Gateway hilft viel Speicher bzw. ein größerer Controller (m328p=384, m32=500, m644p=1500) * eine Datenrate von 38,4 kbit/s erzielte hier die besten Ergebnisse; eine geringere Geschwindigkeit bringt bei schlechterer Signalqualität praktisch keine Verbesserung * bei zu hoher Geschwindigkeit (hier 76,8 kbit/s auf Mega32@16MHz am ZBus-Gateway) kommt es zum Pufferüberlauf; "bf" steigt deutlich bei hohem Datenaufkommen * ein Mega644p@16MHz mit buffers=1500 läuft problemlos mit 115,2 kbit/s, sofern die anderen Busteilnehmer mitspielen * die Masseverbindung sollte mitgeführt werden; eine Versorgungsspannung wird als abgesicherte Rohspannung (12V) ebenfalls am Bus zur Versorgung der Devices bereitgestellt * ein [[ZBus_Testboard_(Deutsch) | ZBus-Testboard]] stellt zum Beispiel eine Minimalvariante dar; basierend auf ATMega328 (Arduino Pro Mini) mit Keramikresonator, Längsregler 7805 und MAX485 [[Category:Hardware]] [[Category:ZBus]] cfd7d10a65d649316714c2a9c1c4c9b51d707d17 14 538 1628 2016-01-30T15:40:53Z Kpwg 721 Created page with "This category lists all articles about ZBus." wikitext text/x-wiki This category lists all articles about ZBus. b8ce20d71890810549f2ab9be158da9ccf0507e4 0 492 1629 1514 2016-01-30T15:41:56Z Kpwg 721 wikitext text/x-wiki {{i18n|ZBus_Board_1_0}} [[File:ZBus-Board_06.jpg|thumb|right|Schaltbild]] '''Motivation''' * Test eines kommerziellen Platinenherstellers mit einem preiswerten, aber sinnvollen Projekt * einseitige Platine, um auch selbst ätzen zu können; leicht verfügbare Bauteile * günstiger [[ZBus_(Deutsch) | ZBus]]-Client für kleine Aufgaben und geringsten Platzbedarf * direkte Verbindung zu einem LCD (rückseitig auflötbar) * direkte Anschaltung eines DHT22 oder I2C [[File:ZBus-Board_05.jpg|thumb|right|Platine]] '''Ausstattung''' * ATMega 328p mit 16MHz Quarz * MAX485 als Pegelwandler * Terminierung optional bestückbar * Verpolschutzdiode, kleiner Spannungsregler * Status-LEDs für ZBus TX/RX oder andere Aufgaben * 16pol. Pinreihe für direkten Anschluß eines HD44780-LCD inkl. Kontrastregler und schaltbarer Hintergrundbeleuchtung * 4pol. Pinreihe für DHT22, I2C oder Onewire * 6pol. ISP-Stecker * alle Pinreihen sind zueinander im 2.54mm-Raster, um eine Lochrasterplatine für weitere Aufgaben anlöten zu können '''Einsatzbeispiele''' * Roomnode mit LCD und abgesetztem DHT22 im schlanken Gehäuse * mit optionalem Sensorboard (Lochraster) zum Messen und Schalten '''Bilder''' <gallery> ZBus-Board_01.jpg|bestückte Platine ZBus-Board_02.jpg|Rückseite ZBus-Board_03.jpg|aufgesteckt auf HD44780-LCD ZBus-Board_04.jpg|Schnittstelle für DHT22 oder I2C </gallery> [[Category:Hardware]] [[Category:ZBus]] 49e64ed9d5c93e186a426b33649d9834512cbffb 0 460 1630 1499 2016-01-30T15:42:16Z Kpwg 721 wikitext text/x-wiki {{i18n|ZBus Testboard}} '''Wofür?''' * Hiermit lassen sich Versuche mit [http://de.wikipedia.org/wiki/EIA-485 RS485] und [[ZBus_(Deutsch) | ZBus]] durchführen, um die Machbarkeit diverser Vorhaben abzuschätzen '''Ausstattung''' * Arduino ProMini Clone (hier das [http://arduino.cc/en/pmwiki.php?n=Main/ArduinoBoardProMini Original]) * MAX485 als Pegelwandler * per Jumper aktivierbare Terminierung * Verpolschutzdiode, separater Spannungsregler für MAX485 und Test-Peripherie * Status-LEDs für ZBus TX/RX * ein DS18B20 Temperatursensor, damit es auch was zu messen gibt * 6pol. ISP-Stecker '''praktische Eigenschaften''' * sehr einfacher, schneller und preiswerter Aufbau (<6 Euro; Recycling aus der Bastelkiste) * hohe Flexibilität bei Peripherie und Platzierung innerhalb des Busses * weiter Betriebsspannungsbereich * bester Datendurchsatz mit 38,4 kbit/s bei ECMD (buffers=384) * 20-25mA Stromaufnahme an 12V '''Bilder''' <gallery> Zbus_testboard.jpg|Gesamtansicht Zbus_testboard2.jpg|Ansicht von oben Zbus_testboard3.jpg|Ansicht von unten </gallery> [[Category:Hardware]] [[Category:ZBus]] f235970fe5da9add569c9365b297195d0a1f2e62 0 433 1631 1503 2016-01-30T15:43:14Z Kpwg 721 /* FHEM Roomnode Wohnzimmer */ wikitext text/x-wiki {{i18n|FHEM Wohnzimmer}} == [[Nutzung_in_FHEM_(Deutsch)|FHEM]] Roomnode Wohnzimmer == Für diverse Mess- und Schaltaufgaben im Wohnzimmer musste ein individuelles und vorzeigbares Gerät entstehen, das diese Aufgaben übernimmt. Dabei sollen Daten über LAN an FHEM geliefert bzw. Display und Schaltaktoren mit FHEM gesteuert werden. Die wichtigsten Grundfunktionen sollen auch ohne FHEM direkt bedienbar sein. '''Ziele''' * Messung Temperatur/Feuchte im Raum * Anzeige diverser Klimadaten und Uhrzeit * Schalten eines [[RFM12_ASK_(Deutsch)#Intertechno_.28ITS-150.29|Intertechno]] Schaltaktors * Schalten einiger [[RFM12_ASK_(Deutsch)#2272|IC2272]]-Funksteckdosen (Weihnachtsbeleuchtung, etc.) * Steuerung Schrankwandbeleuchtung * Schalten eines [http://www.raspberrypi.org/ RasPi] für [http://xbmc.org/ XBMC] * Autonome Grundfunktionen ohne FHEM * vorzeigbares fertiges Gehäuse '''Ausstattung''' * [[DHT|DHT22]] mit ca. 3m Kabel * LCD 16x1 HD44780 mit extra großen Zeichen * [[RFM12_(Deutsch)|RFM12]] 433MHz mit externer Antenne * Taster mit LEDs * Schaltausgänge 12V mit PowerFET (IRLZ34) * USB-Buchse, die per Kabel den RasPi mit 5V versorgt * ATMega32 (98% Nutzung des Flash) '''Bilder''' <gallery> Fhem_wz_01.jpg|Aussenansicht (noch ohne Frontplatte) Fhem_wz_02.jpg|Platine von oben Fhem_wz_03.jpg|Stromversorgung und LAN-Modul Fhem_wz_04.jpg|Stecker Schrankwandbeleuchtung und DHT22 Fhem_wz_05.jpg|RFM12, Reed-Relais für geschaltene 5V Fhem_wz_06.jpg|zweckentfremdetes WLAN-Pigtail und 433MHz-Antenne Fhem_wz_07.jpg|Platine ohne Gehäuse für letzte Anpassungen Fhem_wz_08.jpg|Platine von unten </gallery> '''Update ZBus''' * Ersatz des Mega32 durch einen Mega644p * Einbau eines MAX485 mit Abschluss- und Bias-Widerständen sowie einer RJ10-Buchse für den ZBus-Anschluss * Fertigung eines Y-Kabels zur Übertragung des ZBus auf den ungenutzten LAN-Paaren <gallery> Fhem_wz_09.jpg|Platine mit Mega644 und MAX485 Fhem_wz_10.jpg|Rückseite mit RJ10 Buchse Fhem_wz_11.jpg|LAN-ZBus-Y-Kabel </gallery> '''Besonderheiten/Hinweise''' * das Gehäuse stammt von einem nutzlos gewordenen ELSA Lancom 800 * mit [[Control6_(Deutsch)|Control6]] und NamedPin sind die Grundfunktionen autonom bedienbar * die Stecker für die Schrankwandbeleuchtung entsprechen dem Original (Gewährleistung...) [[Category:Hardware]] [[Category:ZBus]] 4b232c14ebd711f90e1697c0a1db1befb6ef8832 0 459 1632 1481 2016-01-30T15:44:44Z Kpwg 721 wikitext text/x-wiki {{i18n|FHEM Keller}} In einem durch nachlässiges Lüften sehr feuchten Keller sollen Temperatur/Feuchte an mehreren Punkten sowie außen am Gebäude gemessen werden. Daraus errechnet [[Nutzung_in_FHEM_(Deutsch)|FHEM]] Lüftungsempfehlungen. Diese wird zusätzlich auf dem Display durch '''(auf)''' und '''(zu)''' angzeigt. Da es keine Möglichkeit gibt, per LAN in den Raum zu gelangen, musste eine Wireless-Bridge her. Damit steht zugleich LAN an der Werkbank bereit. Ein Anschluss für [[ZBus_(Deutsch) | ZBus]] lässt Platz für weitere Spielereien. '''Ziele''' * genaue Messung Temperatur/Feuchte in den Räumen und an der Außenwand * Anzeige diverser Klimadaten und Uhrzeit * pespektivisch weitere Möglichkeiten zur Steuerung/Regelung * Feuchtraum-Gehäuse '''Ausstattung''' * WLAN-Router als Wireless-Bridge * mehrere [[DHT|DHT22]] mit bis zu 6m Kabel (Cat.5-Reste) * [[LCD_(Deutsch) | LCD]] 20x4 HD44780 zur Anzeige von Datum, Uhrzeit, Klimadaten, Lüftungsempfehlung * [[ZBus_(Deutsch) | ZBus]] Interface mit MAX485 für [[ZBus_Testboard_(Deutsch) | ZBus-Tests]] oder weitere Zbus-Roomnodes * Industrienetzteil mit Reserven für dem ZBus und Versorgung des Routers * ATMega32 '''Bilder''' <gallery> Fhem_ke_01.jpg|Aussenansicht (Klarsichtdeckel abgenommen) Fhem_ke_02.jpg|Display in Aktion (Hi=hinten; Vo=vorn; Ga=Garten; TP=Taupunkt) Fhem_ke_03.jpg|DHT22 als Raumsensor, auf einem alten Bopla-Gehäuse Fhem_ke_04.jpg|Prozessorboard von oben; LAN-modul aufgesetzt Fhem_ke_05.jpg|Prozessorboard von unten Fhem_ke_06.jpg|Stromversorgungs-/ZBus-Board von oben Fhem_ke_07.jpg|Stromversorgungs-/ZBus-Board von unten </gallery> [[Category:Hardware]] [[Category:ZBus]] 25c41d695c166aa56f6f97f63934bbceff5b586b 0 497 1633 1549 2016-01-30T16:04:30Z Kpwg 721 /* Supported Network Hardware */ wikitext text/x-wiki {{i18n|Features}} == Unterstützte Netzwerk Hardware == * Ethernet [[ENC28J60 | Microchip's ENC28J60]] with IEEE 802.1q VLAN tagging * [[USB_(Deutsch)]] * [[RFM12_(Deutsch)]] * [[ZBus_(Deutsch)]] == Network Protocols == * IPv4, IPv4 * TCP/IP, UDP/IP and ICMP * DNS * mDNS (Avahi) * [[BOOTP_(Deutsch)]] * [[DHCP]] * TFTP (can be used in combination with the [[Ethernet Loader]]) * SYSLOG * [[SNMP]] * SMTP * [[NTP]] (Client and Server) * DynDNS * MySQL (Client) * IRC (Client) * [[XMPP | XMPP / Jabber Client]] * MPD (Music Player Daemon) * [[SOAP_(Deutsch)]] / XMLRPC * [[UPnP]] * [[Artnet]] == Hardware Drivers == * [[Onewire_(Deutsch)]] * [[I2C_(Deutsch) | I2C_(Deutsch) Master / Slave]] * [[ADC input]] * [[PWM Generator]] * [[RFM12_FS20_(Deutsch)]] * [[RFM12_ASK_(Deutsch)]] * [[Generic ASK Modules]] * [[Bluetooth|Bluetooth SPP]] * [[USB]] * [[PS/2 Keyboard]] * [[Button Input]] * [[HC595]] * [[HC165]] * [[IRMP_(Deutsch) | IR Receivers_(Deutsch)]] * [[SRAM]] == Software Modules == * [[Ethersex Lighting Architecture]] ** [[Starburst]] ** [[StellaLight]] ** [[DMX Storage]] ** [[DMX FXSlot]] * [[Cron_(Deutsch) | Cron Daemon_(Deutsch)]] * [[System Clock | Clock ]] * [[VNC Server]] * [[lome6]] * [[Frequency Counter]] 20b04a1e5563034e4d45dd295745c4ea14e0b2c7 1634 1633 2016-01-30T16:05:42Z Kpwg 721 /* Network Protocols */ wikitext text/x-wiki {{i18n|Features}} == Unterstützte Netzwerk Hardware == * Ethernet [[ENC28J60 | Microchip's ENC28J60]] with IEEE 802.1q VLAN tagging * [[USB_(Deutsch)]] * [[RFM12_(Deutsch)]] * [[ZBus_(Deutsch)]] == Netzwerk Protokolle == * IPv4, IPv4 * TCP/IP, UDP/IP and ICMP * DNS * mDNS (Avahi) * [[BOOTP_(Deutsch)]] * [[DHCP]] * TFTP (can be used in combination with the [[Ethernet Loader]]) * SYSLOG * [[SNMP]] * SMTP * [[NTP]] (Client and Server) * DynDNS * MySQL (Client) * IRC (Client) * [[XMPP | XMPP / Jabber Client]] * MPD (Music Player Daemon) * [[SOAP_(Deutsch)]] / XMLRPC * [[UPnP]] * [[Artnet]] == Hardware Drivers == * [[Onewire_(Deutsch)]] * [[I2C_(Deutsch) | I2C_(Deutsch) Master / Slave]] * [[ADC input]] * [[PWM Generator]] * [[RFM12_FS20_(Deutsch)]] * [[RFM12_ASK_(Deutsch)]] * [[Generic ASK Modules]] * [[Bluetooth|Bluetooth SPP]] * [[USB]] * [[PS/2 Keyboard]] * [[Button Input]] * [[HC595]] * [[HC165]] * [[IRMP_(Deutsch) | IR Receivers_(Deutsch)]] * [[SRAM]] == Software Modules == * [[Ethersex Lighting Architecture]] ** [[Starburst]] ** [[StellaLight]] ** [[DMX Storage]] ** [[DMX FXSlot]] * [[Cron_(Deutsch) | Cron Daemon_(Deutsch)]] * [[System Clock | Clock ]] * [[VNC Server]] * [[lome6]] * [[Frequency Counter]] e2e1e9f77bb32370c4a4015b0a79496630b0ee13 1635 1634 2016-01-30T16:19:25Z Kpwg 721 /* Hardware Drivers */ wikitext text/x-wiki {{i18n|Features}} == Unterstützte Netzwerk Hardware == * Ethernet [[ENC28J60 | Microchip's ENC28J60]] with IEEE 802.1q VLAN tagging * [[USB_(Deutsch)]] * [[RFM12_(Deutsch)]] * [[ZBus_(Deutsch)]] == Netzwerk Protokolle == * IPv4, IPv4 * TCP/IP, UDP/IP and ICMP * DNS * mDNS (Avahi) * [[BOOTP_(Deutsch)]] * [[DHCP]] * TFTP (can be used in combination with the [[Ethernet Loader]]) * SYSLOG * [[SNMP]] * SMTP * [[NTP]] (Client and Server) * DynDNS * MySQL (Client) * IRC (Client) * [[XMPP | XMPP / Jabber Client]] * MPD (Music Player Daemon) * [[SOAP_(Deutsch)]] / XMLRPC * [[UPnP]] * [[Artnet]] == Hardware Treiber == * [[Onewire_(Deutsch) | Onewire / 1Wire]] * [[I2C_(Deutsch) | I2C Master / Slave]] * [[ADC_(Deutsch) | ADC input]] * [[PWM Generator]] * [[RFM12_FS20_(Deutsch) | FS20 mit RFM12]] * [[RFM12_ASK_(Deutsch) | ASK mit RFM12]] * [[Generic ASK Modules | ASK mit generischen Modulen]] * [[Bluetooth|Bluetooth SPP]] * [[USB]] * [[PS/2 Keyboard]] * [[Button Input]] * [[Porterweiterungen_(Deutsch)#74HC595_als_Ausgangserweiterung | 74HC595 Ausgangserweiterung]] * [[Porterweiterungen_(Deutsch)#74HC164_als_Ausgangserweiterung | 74HC164 Ausgangserweiterung]] * [[Porterweiterungen_(Deutsch)#74HC165_als_Eingangserweiterung | 74HC165 Eingangserweiterung]] * [[IRMP_(Deutsch) | IRMP Infrarot Empfänger]] * [[SRAM]] == Software Modules == * [[Ethersex Lighting Architecture]] ** [[Starburst]] ** [[StellaLight]] ** [[DMX Storage]] ** [[DMX FXSlot]] * [[Cron_(Deutsch) | Cron Daemon_(Deutsch)]] * [[System Clock | Clock ]] * [[VNC Server]] * [[lome6]] * [[Frequency Counter]] 371f8dfe6a5c232b9b340c87d6ebd9f78d3ec588 1636 1635 2016-01-30T16:21:37Z Kpwg 721 /* Software Modules */ wikitext text/x-wiki {{i18n|Features}} == Unterstützte Netzwerk Hardware == * Ethernet [[ENC28J60 | Microchip's ENC28J60]] with IEEE 802.1q VLAN tagging * [[USB_(Deutsch)]] * [[RFM12_(Deutsch)]] * [[ZBus_(Deutsch)]] == Netzwerk Protokolle == * IPv4, IPv4 * TCP/IP, UDP/IP and ICMP * DNS * mDNS (Avahi) * [[BOOTP_(Deutsch)]] * [[DHCP]] * TFTP (can be used in combination with the [[Ethernet Loader]]) * SYSLOG * [[SNMP]] * SMTP * [[NTP]] (Client and Server) * DynDNS * MySQL (Client) * IRC (Client) * [[XMPP | XMPP / Jabber Client]] * MPD (Music Player Daemon) * [[SOAP_(Deutsch)]] / XMLRPC * [[UPnP]] * [[Artnet]] == Hardware Treiber == * [[Onewire_(Deutsch) | Onewire / 1Wire]] * [[I2C_(Deutsch) | I2C Master / Slave]] * [[ADC_(Deutsch) | ADC input]] * [[PWM Generator]] * [[RFM12_FS20_(Deutsch) | FS20 mit RFM12]] * [[RFM12_ASK_(Deutsch) | ASK mit RFM12]] * [[Generic ASK Modules | ASK mit generischen Modulen]] * [[Bluetooth|Bluetooth SPP]] * [[USB]] * [[PS/2 Keyboard]] * [[Button Input]] * [[Porterweiterungen_(Deutsch)#74HC595_als_Ausgangserweiterung | 74HC595 Ausgangserweiterung]] * [[Porterweiterungen_(Deutsch)#74HC164_als_Ausgangserweiterung | 74HC164 Ausgangserweiterung]] * [[Porterweiterungen_(Deutsch)#74HC165_als_Eingangserweiterung | 74HC165 Eingangserweiterung]] * [[IRMP_(Deutsch) | IRMP Infrarot Empfänger]] * [[SRAM]] == Software Module == * [[Ethersex Lighting Architecture]] ** [[Starburst]] ** [[StellaLight]] ** [[DMX Storage]] ** [[DMX FXSlot]] * [[Cron_(Deutsch) | Cron Daemon_(Deutsch)]] * [[System Clock | Clock ]] * [[VNC Server]] * [[lome6]] * [[Frequency Counter]] e75b5d77e64a5843322caec60bf087e6c7096c6e 1638 1636 2016-01-30T16:34:57Z Kpwg 721 /* Unterstützte Netzwerk Hardware */ wikitext text/x-wiki {{i18n|Features}} == Unterstützte Netzwerk Hardware == * Ethernet Microchip's [[ENC28J60_(Deutsch) | ENC28J60]] mit IEEE 802.1q VLAN tagging * [[USB_(Deutsch) | IP über USB serial host]] * [[RFM12_(Deutsch) | IP über RFM12]] * [[ZBus_(Deutsch) | ZBus: IP über RS485]] == Netzwerk Protokolle == * IPv4, IPv4 * TCP/IP, UDP/IP and ICMP * DNS * mDNS (Avahi) * [[BOOTP_(Deutsch)]] * [[DHCP]] * TFTP (can be used in combination with the [[Ethernet Loader]]) * SYSLOG * [[SNMP]] * SMTP * [[NTP]] (Client and Server) * DynDNS * MySQL (Client) * IRC (Client) * [[XMPP | XMPP / Jabber Client]] * MPD (Music Player Daemon) * [[SOAP_(Deutsch)]] / XMLRPC * [[UPnP]] * [[Artnet]] == Hardware Treiber == * [[Onewire_(Deutsch) | Onewire / 1Wire]] * [[I2C_(Deutsch) | I2C Master / Slave]] * [[ADC_(Deutsch) | ADC input]] * [[PWM Generator]] * [[RFM12_FS20_(Deutsch) | FS20 mit RFM12]] * [[RFM12_ASK_(Deutsch) | ASK mit RFM12]] * [[Generic ASK Modules | ASK mit generischen Modulen]] * [[Bluetooth|Bluetooth SPP]] * [[USB]] * [[PS/2 Keyboard]] * [[Button Input]] * [[Porterweiterungen_(Deutsch)#74HC595_als_Ausgangserweiterung | 74HC595 Ausgangserweiterung]] * [[Porterweiterungen_(Deutsch)#74HC164_als_Ausgangserweiterung | 74HC164 Ausgangserweiterung]] * [[Porterweiterungen_(Deutsch)#74HC165_als_Eingangserweiterung | 74HC165 Eingangserweiterung]] * [[IRMP_(Deutsch) | IRMP Infrarot Empfänger]] * [[SRAM]] == Software Module == * [[Ethersex Lighting Architecture]] ** [[Starburst]] ** [[StellaLight]] ** [[DMX Storage]] ** [[DMX FXSlot]] * [[Cron_(Deutsch) | Cron Daemon_(Deutsch)]] * [[System Clock | Clock ]] * [[VNC Server]] * [[lome6]] * [[Frequency Counter]] b39f8546add23f5bd95391048e7606b5cdcfb571 0 539 1639 2016-01-30T16:36:38Z Kpwg 721 Created page with "{{i18n|ENC28J60}} Der Halbleiterbaustein ENC28J60 von Microchip ist ein "Stand-Alone Ethernet Controller with SPI Interface", also eine vollständige Ethernet-Schnittstelle f..." wikitext text/x-wiki {{i18n|ENC28J60}} Der Halbleiterbaustein ENC28J60 von Microchip ist ein "Stand-Alone Ethernet Controller with SPI Interface", also eine vollständige Ethernet-Schnittstelle für 10BASE-T mit seriellem Anschluss (Serial Peripheral Interface) in einem 28-poligen SPDIP, SSOP, SOIC bzw. QFN-Gehäuse. Weitere Infos und Daten gibt es beim Hersteller: http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en022889 9d5b2121f26242ba8a726a468d790ea450e3c31f 3 495 1647 1585 2016-01-30T17:10:35Z Djmaster 255 /* 1 */ wikitext text/x-wiki =Todo Liste= ==1== *[[Temperaturmesssystem_(Deutsch)]] ** <s>make clean && make</s> ** <s>Paar Bilder und tftpd win32</s> ** ds1820 id herausbekommen und 4k7 pullup anfügen ** <s>[ ] jump bootloader????</s> Anm.: Voraussetzung für das ECMD "bootloader" sind die Optionen "General Setup -> Prompt all possible options" (CONFIG_EXPERT) und "General Setup -> Enable bootloader jump" (BOOTLOADER_JUMP) im menuconfig. Per Telnet sich mit dem ethersex verbinden (telnet <IP-Ethersex> 2701). Dort "bootloader" oder "wdreset" eingeben. ==2== *[[BOOTP_%28Deutsch%29]] ** Links prüfen ** <s>Bilder prüfen</s> ** Text anpassen an aktuelle rel. ==3== *[[I2C_%28Deutsch%29]] **Levelshifter **Aufteilung ==4== *ETHERNET LOADER??? old wiki 1d1fe78b9196fa2eb46d3a9428210eb38f07a00d 1648 1647 2016-01-30T17:18:13Z Djmaster 255 /* 1 */ wikitext text/x-wiki =Todo Liste= ==1== *[[Temperaturmesssystem_(Deutsch)]] ** webabfrage ** wdreset ** <s>make clean && make</s> ** <s>Paar Bilder und tftpd win32</s> ** ds1820 id herausbekommen und 4k7 pullup anfügen ** <s>[ ] jump bootloader????</s> Anm.: Voraussetzung für das ECMD "bootloader" sind die Optionen "General Setup -> Prompt all possible options" (CONFIG_EXPERT) und "General Setup -> Enable bootloader jump" (BOOTLOADER_JUMP) im menuconfig. Per Telnet sich mit dem ethersex verbinden (telnet <IP-Ethersex> 2701). Dort "bootloader" oder "wdreset" eingeben. ==2== *[[BOOTP_%28Deutsch%29]] ** Links prüfen ** <s>Bilder prüfen</s> ** Text anpassen an aktuelle rel. ==3== *[[I2C_%28Deutsch%29]] **Levelshifter **Aufteilung ==4== *ETHERNET LOADER??? old wiki 4c711151cf84806dfc29869c75e48fcecf7bd1d7 1652 1648 2016-01-30T18:15:50Z Djmaster 255 /* 1 */ wikitext text/x-wiki =Todo Liste= ==1== *[[Temperaturmesssystem_(Deutsch)]] ** <s>webabfrage</s> ** <s>wdreset</s> ** <s>make clean && make</s> ** <s>Paar Bilder und tftpd win32</s> ** ds1820 id herausbekommen und 4k7 pullup anfügen ** <s>[ ] jump bootloader????</s> Anm.: Voraussetzung für das ECMD "bootloader" sind die Optionen "General Setup -> Prompt all possible options" (CONFIG_EXPERT) und "General Setup -> Enable bootloader jump" (BOOTLOADER_JUMP) im menuconfig. Per Telnet sich mit dem ethersex verbinden (telnet <IP-Ethersex> 2701). Dort "bootloader" oder "wdreset" eingeben. ==2== *[[BOOTP_%28Deutsch%29]] ** Links prüfen ** <s>Bilder prüfen</s> ** Text anpassen an aktuelle rel. ==3== *[[I2C_%28Deutsch%29]] **Levelshifter **Aufteilung ==4== *ETHERNET LOADER??? old wiki 6fb1f1db1596964c1d9866775442bf84eae48230 0 438 1655 1384 2016-01-30T18:38:58Z Kpwg 721 wikitext text/x-wiki {{i18n|Funk-AVR-Evaluationsboard}} [[File:Funk-avr-eval.jpg|150px|thumb|right|Funk-AVR-Evaluationsboard]] Das Funk-AVR-Evaluationsboard von [http://www.pollin.de Pollin] ist ein relativ einfach gehaltenes und daher auch sehr günstiges Board. Es war als Bausatz oder auch als Fertigmodul erhältlich. Der gelieferte ATmega32 kann einfach durch einen leistungsfähigeren ATmega644 oder ATmega1284p (Hinweise zu 128K beachten!) ausgetauscht werden. Gegenüber dem AVR-Net-IO besitzt es zwar keine Netztwerkschnittstelle, jedoch zwei Plätze für RFM-Funkmodule, JTAG-Port, volltändig zugängliche IO-Ports und den ISP zusätzlich an einer Sub-D 9pol Buchse. ===Features=== * 40-poliger Sockel für Atmel ATmega 32/644/1284 Mikrocontroller * 28-poliger Sockel für Atmel ATmega 8/168/328 Mikrocontroller * zwei Plätze für RFM-Funkmodule * RS232-Schnittstelle * 10-polige ISP-Schnittstelle * 10-polige JTAG-Schnittstelle * vollständig zugängliche I/O-Pins an einer 2x20-poligen Pfostenleiste [[Category:Hardware]] 73be7a1687cc1692aae11a40594fa5949965bca5 0 497 1656 1638 2016-01-30T19:07:42Z Kpwg 721 /* Hardware Treiber */ wikitext text/x-wiki {{i18n|Features}} == Unterstützte Netzwerk Hardware == * Ethernet Microchip's [[ENC28J60_(Deutsch) | ENC28J60]] mit IEEE 802.1q VLAN tagging * [[USB_(Deutsch) | IP über USB serial host]] * [[RFM12_(Deutsch) | IP über RFM12]] * [[ZBus_(Deutsch) | ZBus: IP über RS485]] == Netzwerk Protokolle == * IPv4, IPv4 * TCP/IP, UDP/IP and ICMP * DNS * mDNS (Avahi) * [[BOOTP_(Deutsch)]] * [[DHCP]] * TFTP (can be used in combination with the [[Ethernet Loader]]) * SYSLOG * [[SNMP]] * SMTP * [[NTP]] (Client and Server) * DynDNS * MySQL (Client) * IRC (Client) * [[XMPP | XMPP / Jabber Client]] * MPD (Music Player Daemon) * [[SOAP_(Deutsch)]] / XMLRPC * [[UPnP]] * [[Artnet]] == Hardware Treiber == * [[Onewire_(Deutsch) | Onewire / 1Wire]] * [[I2C_(Deutsch) | I2C Master / Slave]] * [[ADC_(Deutsch) | ADC input]] * [[PWM Generator]] * [[RFM12_FS20_(Deutsch) | FS20 mit RFM12]] * [[RFM12_ASK_(Deutsch) | ASK mit RFM12]] * [[Generic ASK Modules | ASK mit generischen Modulen]] * [[Bluetooth|Bluetooth SPP]] * [[USB_(Deutsch) | USB]] * [[PS/2 Keyboard]] * [[Button Input]] * [[Porterweiterungen_(Deutsch)#74HC595_als_Ausgangserweiterung | 74HC595 Ausgangserweiterung]] * [[Porterweiterungen_(Deutsch)#74HC164_als_Ausgangserweiterung | 74HC164 Ausgangserweiterung]] * [[Porterweiterungen_(Deutsch)#74HC165_als_Eingangserweiterung | 74HC165 Eingangserweiterung]] * [[IRMP_(Deutsch) | IRMP Infrarot Empfänger]] * [[SRAM]] == Software Module == * [[Ethersex Lighting Architecture]] ** [[Starburst]] ** [[StellaLight]] ** [[DMX Storage]] ** [[DMX FXSlot]] * [[Cron_(Deutsch) | Cron Daemon_(Deutsch)]] * [[System Clock | Clock ]] * [[VNC Server]] * [[lome6]] * [[Frequency Counter]] 6155b6e91b387916a0ffb41d59cd879ffe2701e9 1683 1656 2016-01-30T20:10:50Z Djmaster 255 /* Netzwerk Protokolle */ wikitext text/x-wiki {{i18n|Features}} == Unterstützte Netzwerk Hardware == * Ethernet Microchip's [[ENC28J60_(Deutsch) | ENC28J60]] mit IEEE 802.1q VLAN tagging * [[USB_(Deutsch) | IP über USB serial host]] * [[RFM12_(Deutsch) | IP über RFM12]] * [[ZBus_(Deutsch) | ZBus: IP über RS485]] == Netzwerk Protokolle == * IPv4, IPv4 * TCP/IP, UDP/IP and ICMP * DNS * mDNS (Avahi) * [[BOOTP_(Deutsch)]] * [[DHCP]] * TFTP (can be used in combination with the [[Ethernet Loader_(Deutsch)]]) * SYSLOG * [[SNMP]] * SMTP * [[NTP]] (Client and Server) * DynDNS * MySQL (Client) * IRC (Client) * [[XMPP | XMPP / Jabber Client]] * MPD (Music Player Daemon) * [[SOAP_(Deutsch)]] / XMLRPC * [[UPnP]] * [[Artnet]] == Hardware Treiber == * [[Onewire_(Deutsch) | Onewire / 1Wire]] * [[I2C_(Deutsch) | I2C Master / Slave]] * [[ADC_(Deutsch) | ADC input]] * [[PWM Generator]] * [[RFM12_FS20_(Deutsch) | FS20 mit RFM12]] * [[RFM12_ASK_(Deutsch) | ASK mit RFM12]] * [[Generic ASK Modules | ASK mit generischen Modulen]] * [[Bluetooth|Bluetooth SPP]] * [[USB_(Deutsch) | USB]] * [[PS/2 Keyboard]] * [[Button Input]] * [[Porterweiterungen_(Deutsch)#74HC595_als_Ausgangserweiterung | 74HC595 Ausgangserweiterung]] * [[Porterweiterungen_(Deutsch)#74HC164_als_Ausgangserweiterung | 74HC164 Ausgangserweiterung]] * [[Porterweiterungen_(Deutsch)#74HC165_als_Eingangserweiterung | 74HC165 Eingangserweiterung]] * [[IRMP_(Deutsch) | IRMP Infrarot Empfänger]] * [[SRAM]] == Software Module == * [[Ethersex Lighting Architecture]] ** [[Starburst]] ** [[StellaLight]] ** [[DMX Storage]] ** [[DMX FXSlot]] * [[Cron_(Deutsch) | Cron Daemon_(Deutsch)]] * [[System Clock | Clock ]] * [[VNC Server]] * [[lome6]] * [[Frequency Counter]] 67630bf020840415dff850ef72a0cb8c8ed53985 6 540 1657 2016-01-30T19:11:39Z Kpwg 721 taken from old wiki wikitext text/x-wiki taken from old wiki 5d2d9155505ad5afc04e47e9a12b9f122e62774c 0 541 1658 2016-01-30T19:31:59Z Kpwg 721 Created page with "{{i18n|Global Variables}} '''Globale Variablen''' werden in [[Control6_(Deutsch) | Control6]] folgendermaßen deklariert: ECMD_GLOBAL(<name>, <initialwert>, [datentyp]); Di..." wikitext text/x-wiki {{i18n|Global Variables}} '''Globale Variablen''' werden in [[Control6_(Deutsch) | Control6]] folgendermaßen deklariert: ECMD_GLOBAL(<name>, <initialwert>, [datentyp]); Die Angabe des Datentyps ist optional. Wenn kein Datentyp angegeben ist, wird uint8_t verwendet. Beispiel: ECMD_GLOBAL(zaehler, 0, uint16_t); Auf diese Weise deklarierte globale Variablen können per [[ECMD_(Deutsch) | ECMD]] abgefragt werden: c6 get zaehler oder gesetzt werden: c6 set zaehler 0 ==Beispiele== *siehe [[Counter_(Deutsch) | Counter]] [[Category:Control6]] f696103952f00e914d06b729d3b4c665d71ac941 0 542 1659 2016-01-30T19:34:05Z Kpwg 721 Created page with "{{i18n|Conditions}} == Bedingungen in Control6 == === Grundsätzlicher Aufbau === ON [ONCE] ''Bedingung'' DO ''Befehle'' END Das Schlüsselwort '''ONCE''' sorgt dafür,..." wikitext text/x-wiki {{i18n|Conditions}} == Bedingungen in Control6 == === Grundsätzlicher Aufbau === ON [ONCE] ''Bedingung'' DO ''Befehle'' END Das Schlüsselwort '''ONCE''' sorgt dafür, dass die Bedingung nur '''einmal pro Minute''' überprüft wird. Dies ist nützlich, wenn zum Beispiel ein Codeblock nur einmal um 6 Uhr morgens ausgeführt werden soll. Die Bedingung könnte dann '''ON ONCE CLOCK_MIN == 0 && CLOCK_HOUR == 6''' lauten. Ohne das Schlüsselwort ''ONCE'' würde der Codeblock von 6:00 bis 6:01 ständig im Rahmen der Hauptschleife von Ethersex ausgeführt, was häufig nicht gewünscht ist :-) Es kann jedoch nicht nur die Uhr abgefragt werden, sondern es steht auch alle übrigen Funktionen, die Rückgabewerte liefern, zur Auswahl. Beispielsweise können KTY-Temperatursensoren abgefragt werden. Um einmal pro Minute zu prüfen, ob die von Sensor 5 gemessene Temperatur unter 3,0 Grad liegt, kann Folgendes geschrieben werden: ON ONCE KTY_GET(AussenNord) < 30 SYSLOG("Draußen ist es sehr kalt!") END [[Category:Control6]] 67ed8844774035986460f23ebf57d13afaaef9bd 0 494 1660 1602 2016-01-30T19:40:22Z Djmaster 255 wikitext text/x-wiki {{i18n|BOOTP}} {{Module |NAME=BOOTP |MENUCONFIG={{Protocol}}->BOOTP |STATUS={{In_Development}} |PINNING=no |ECMD=no |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/protocols/bootp https://github.com/ethersex/ethersex/tree/master/protocols/bootp] }} == Warum BOOTP? == Jeder kennt das Problem, wenn man eine Firmware erstellt hat, muss sie irgendwie in die Hardware kommen. Der gängige Weg, man flasht die Hardware mit einem Programmieradapter über SPI oder [http://de.wikipedia.org/wiki/Joint_Test_Action_Group JTAG] ([http://www.atmel.com/dyn/resources/prod_documents/doc2475.pdf ATMEL]). In der Firmware muss die [http://de.wikipedia.org/wiki/MAC-Adresse MAC]- Adresse und die [http://de.wikipedia.org/wiki/IP-Adresse IP-Adresse] für die Hardware (µC) einkompiliert sein. Sie ist damit erstmals fix und kann nur nachträglich über das ECMD-Kommandos ip geändert werden. Schön wäre es, wenn man sich um die IP-Adresse nicht kümmern müsste und sie selbständig zum Bootzeitpunkt geladen wird. Und noch schöner wäre es, wenn der µC sich auch gleich die aktuelle Firmware selbst laden und flashen würde. Genau dies macht jetzt BOOTP.<br /> === BOOTP Startsequenz === [http://de.wikipedia.org/wiki/Bootstrap_Protocol BOOTP] ist der Vorläufer von [http://de.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol DHCP] mit dem einem Netzwerkgerät wie z.B. unserem µC eine IP-Adresse zugeordnet werden kann. Falls das Netzwerkgerät nicht über einen eigenen Festspeicher verfügt, kann auch die Firmware oder das Betriebssystem auf Anfrage des Netzwerkgerätes übertragen werden. Damit BOOTP funktioniert, muss ein Minimalprogramm mit dem BOOTP-Client auf dem Netzwerkgerät als Bootloader gespeicher sein. Bei einem PC liegt dieses Programm in der Netzwerkkarte. Auf unserem µC muss der Ethernet Bootloader geflasht sein. Dieser enthält eine eindeutige MAC-Adresse für das Netzwerkgerät, damit es adressiert werden kann.<br /> Zum Bootzeitpunkt verfügt der µC nur über die MAC-Adresse. Er stellt also als erstes eine Broadcast-Anfrage an alle Netzwerkteilnehmer mit der Bitte ihm eine IP-Adresse zu geben. Gibt es im Netzwerk einen anderen Rechner, der einen BOOTP- oder DHCP-Server enthält, so antwortet dieser Server und gibt ihm, sofern erlaubt, eine IP-Adresse, die Netmask und das Gateway. Ab nun an kann der µC unter dieser Adresse erreicht werden. Als nächstes fragt der µC den BOOTP-Server nach einer aktuellen Firmware. Dieser teilt ihm den Server und den Port mit, von dem die Firmware per [http://de.wikipedia.org/wiki/Trivial_File_Transfer_Protocol TFTP] geladen werden kann. Mit dieser Art des bootens, kann sehr elegant der µC geflasht und gleichzeitig eine IP-Adresse zugeordnet werden. Das eigentliche flashen der Firmware macht der µC damit selbständig. Mit dem Ethernet Bootloader und BOOTP ist es möglich, beliebige Firmware zu laden ohne ein Programmieradapter zu benutzen. Es muss lediglich die aktuelle Firmware auf dem BOOTP-Server hinterlegt sein und einmal der µC neu gestartet werden und schon flasht er sich selbständig ohne weiteres zutun nur über das Netzwerk. Diese Art des "flashens" geht schneller als mit einem Programmieradapter. In gut 10s ist die Firmware (ca. 50kB) geladen, geflasht und gestartet.<br /> === Voraussetzungen === Damit BOOTP benutzt werden kann müssen bestimmte Voraussetzungen erfüllt sein: * Nur mit einem ATMEGA644 oder größer läßt sich der 8KB Ethernet Bootloader flashen * Der Bootloader mit BOOTP belegt die letzten 8KB ab Adresse xE000 des Programmspeichers, die nicht mehr genutzt werden können * Die Programmgröße (Firmware) ist auf 56 KB beschränkt * Die Securebits sollten gesetzt sein, damit der Bootloader sich nicht selbst überschreiben kann * Es muss ein BOOTP- und TFTP- Server wie z.B. HahneDHCP o.ä. im Netzwerk erreichbar sein * Die Firmware muss als ethersex.bin auf dem TFTP-Server hinterlegt sein * In der Firmware muss die selbe MAC-Adresse verwendet werden wie im Bootloader von BOOTP == Konfiguration in menuconfig == Als Basis kann in nenuconfig die Option "Bootloader BOOTP" gewählt werden. Es ist zu beachten, dass '''keine spezifischen Einstellungen''' außer CPU-Typ und MCU frequency für die jeweilige Hardware im Bootloader durchgeführt werden. Die hardwarespezifischen Einstellungen werden in der Firmware vorgenommen. Folgende Optionen sollten in '''menuconfig''' aktiviert sein: * '''config-File''' ** Load a Default Configuration ---> *** (x) Ethernet Bootloader ** General Setup *** ATMEGA644 *** 16000000 MCU frequency (für AVR-NET-IO) *** (x) Build a bootloader *** (x) Teensy build ** Network ---> *** Ethernet (ENC28J60) support **** Etherrape MAC address 00:11:22:33:44:55 (bitte ändern!) *** (x) UDP support *** (x) UDP broadcast support *** (x) BOOTP (DHCP like) support ** Applications -> *** (x) TFTP support '''Wichtig!''' Die MAC-Adresse muss gesetzt sein. Die selbe MAC-Adresse muss in der Firmware später auch benutzt werden. Hier ist eine [http://www.phw-magdeburg.de/ethersex/BOOTP.config Konfigurationsdatei] für das Pollin AVR-NET-IO mit Addon (MAC: AC:DE:48:CE:23:C8 ): Damit man nun nicht jedes mal die MAC-Adresse neu einkompilieren muss, kann man sie auch händisch mit einem Texteditor in [http://www.phw-magdeburg.de/ethersex/ethersex.hex ''ethersex.hex''] ändern. <source lang="perl"> :10E000003EC0000066C0000064C0000062C00000A6 :10E0100060C000005EC000005CC000005AC000008C :10E0200058C0000056C0000054C0000052C000009C :10E0300050C0000014C100004CC000004AC00000E5 :10E0400048C0000046C0000044C0000042C00000BC :10E0500040C000003EC000003CC000003AC00000CC :10E0600038C0000036C0000034C0000032C00000DC :10E07000"ACDE48CE23C8"006F63746574000014BE24 :10E0800088E10FB6F89480936000109260000FBE94 :10E0900010926E0010926F001092700011241FBE3B :10E0A000CFEFD0E1DEBFCDBF11E0A0E0B1E0E8EE00 </source> == Flashen des Bootloaders == Nach der Konfiguration mit menuconfig den Bootloader mit ''make clean'' und ''make'' compilieren und mit einem Programmieradapter die Datei ''ethersex.hex'' flashen. Wenn eine alte Vorlage benutzt wird, muss ggf. die MAC-Adresse noch einmal geändert werden. Damit der Bootloader nicht durch die Firmware überschrieben wird, müssen die Lock-Bits folgendermaßen gesetzt sein: Für ATmega644: ''avrdude -p m644 -c ponyser -P /dev/ttyS0 -U lock:w:0x0F:m'' oder in Ponyprog: *(x) BootLock02 *(x) BootLock01 *(x) Lock2 *(x) Lock1 '''Achtung!''' Sollte der Bootloader neu geflasht werden, so müssen die Lock-Bits nach dem flashen immer wieder neu gesetzt werden. Wer keine Lust hat den Ethernet-Bootloader zu kompilieren, kann hier für das AVR-NET-IO mit Addon die Datei [http://www.phw-magdeburg.de/ethersex/ethersex.hex ''ethersex.hex''] verwenden. == BOOTP-Server konfigurieren (Windows) == Als BOOTP-Server verwende ich unter Windows '''hahneWin DHCP Server'''. Als Beispielkonfiguration ist bei mir folgendes eingestellt: * Kein DHCP sondern nur BOOTP aktiviert (zur Problemvermeidung bei bestehendem DHCP-Server) * 192.168.0.0 Netzwerk für BOOTP * 192.168.0.1 Rechner mit hahneWin DHCP Server und TFTP auf Port 69 * statische Adressvergabe über MAC-Adressen fest zugewiesen * 192.168.0.88 AVR-NET-IO mit MAC AC:DE:48:CE:23:C8 * 255.255.255.0 Netmask * 192.168.0.251 Gateway * 192.168.0.251 DNS-Server [[File:Hahne_DHCP.jpg]] Abb.: hahneWin DHCP Server Alle weiteren Einstellungen zum hahneWin DHCP Server können den nachfolgenden Links entnommen werden: Grundsätzlich werden als erstes unter ''Optionen->Einstellungen'' die Grundeinstellungen vorgenommen. * [http://www.phw-magdeburg.de/ethersex/Einstellungen_Allgemein.JPG Einstellungen Allgemein] * [http://www.phw-magdeburg.de/ethersex/Einstellungen_Schnittstellen.JPG Einstellungen Schnittstellen] * [http://www.phw-magdeburg.de/ethersex/Einstellungen_DHCP.JPG Einstellungen DHCP] * [http://www.phw-magdeburg.de/ethersex/Einstellungen_TFTP.JPG Einstellungen TFTP] * [http://www.phw-magdeburg.de/ethersex/Einstellungen_TFTP_Optionen.JPG Einstellungen TFTP Optionen] Im zweiten Schritt werden unter ''Optionen->Konfigurationsprofile verwalten'' das betreffende Netzwerk ausgewählt und mit ''Bearbeiten'' angepaßt. Im meinem Beispiel wurde der Profilname durch Ethersex ersetzt. Vorher stand dort If-2_0.1. * [http://www.phw-magdeburg.de/ethersex/Konfigurationsprofile.JPG Konfigurationsprofile] * [http://www.phw-magdeburg.de/ethersex/Ethersex_Basiskonfiguration.JPG Basiskonfiguration] * [http://www.phw-magdeburg.de/ethersex/Ethersex_DNS.JPG DNS] * [http://www.phw-magdeburg.de/ethersex/Ethersex_Boot.JPG Boot] Als letztes wird dann noch ein neuer statischer Eintrag über den Schaltknopf ''Hinzufügen'' für den µC erstellt. * [http://www.phw-magdeburg.de/ethersex/Statische_Eintraege.JPG Statische Einträge] Alle nicht aufgeführten Seiten enthalten die Standardeinstellungen und müssen nicht weiter modifiziert werden. So, nun sollte der BOOTP-Server laufen. Den Server kann man unter ''Datei->Server starten/beenden'' in den jeweiligen Zustand setzen. === Hahne BOOTP-Server verwenden === Wird jetzt der µC gebootet, so bezieht er seine Netzwerkeinstellungen vom BOOTP-Server, läd danach die Firmware und startet diese. Im Logfile des BOOTP-Server können die Aktivitäten verfolgt werden. Sobald dem µC eine IP-Adresse vergeben wurde erscheint ein grünes Häkchen vor der MAC-Adresse in der Hauptansicht. Folgende Bedingungen müssen beachtet werden: * hat der µC noch keine Firmware geladen, so wird diese per TFTP im BOOTP-Prozess geladen und geflasht * ist schon eine Firmware im µC geflasht, so werden nur die Netzwerkparameter nach einem Reboot oder Power on/off geladen und die vorhandene Firmware gestartet * um die Firmware erleut zu laden, muss mit dem [[ECMD]] Kommando ''wdreset'' oder ''bootloader'' der µC "resettet" werden == BOOTP-Server konfigurieren (Linux) == Als BOOTP-Server verwende ich unter Linux '''dhcpd3'''. Als Beispielkonfiguration ist bei mir folgendes eingestellt: * Kein DHCP sondern nur BOOTP aktiviert (zur Problemvermeidung bei bestehendem DHCP-Server) * 192.168.30.0 Netzwerk für BOOTP * 192.168.30.134 Rechner mit DHCPD3 Server und TFTP auf Port 69 * statische Adressvergabe über MAC-Adressen fest zugewiesen * 192.168.30.10 AVR-NET-IO mit MAC AC:DE:48:CE:23:C8 * 255.255.255.0 Netmask * 192.168.30.1 Gateway * 192.168.30.1 DNS-Server Die folgende Konfiguration verfügt nicht über eine dynamische IP-Range. Dies bedeutet, dass diese Konfiguration nicht mit einem bereits vorhanden DHCP Server ins Gehege kommt. Dem ethersex wird zum Starten eine feste IP zugewiesen. Der Ablauf: #DHCP Server und TFTP Server müssen gestartet sein #Dann das AVR Net-IO in die Steckdose #Ethersex fragt mit seiner Netzwerkadresse ac:de:48:ce:23:c8 per bootp nach einer IP-Adresse #Der DHCP Server schaut in seiner Liste nach ac:de:48:ce:23:c8, findet diese und die IP 192.168.30.10 zusammen mit der TFTP Server IP 192.168.30.134 und dem Dateinamen ethersex.bin zurück an Ethersex #Ethersex kann nun eine IP Verbindung zum TFTP Server 192.168.30.134 aufbauen und lädt die Datei ethersex.bin #Anschlißend startet Ethersex mit der ethersex.bin ===DHCP-Server konfigurieren === sudo apt-get install dhcp3-server Anschließend muss die Konfigurationsdatei /etc/dhcp3/dhcpd.conf, wie folgt bearbeitet werden. Die IP Adressen musst Du an Deine Gegebenheiten anpassen. <pre> default-lease-time 86400; max-lease-time 2592000; authoritative; subnet 192.168.30.0 netmask 255.255.255.0 { option subnet-mask 255.255.255.0; # subnet maske option routers 192.168.30.1; # Gateway option domain-name-servers 192.168.30.1; # DNS Server ddns-update-style none; # Neue Clients werden dem DNS Server nicht mitgeteilt next-server 192.168.30.134; # TFTP Server host netio { hardware ethernet ac:de:48:ce:23:c8; # mac adresse des pollin net io fixed-address 192.168.30.10; # Eine freie IP-Adresse im lokalen Netz filename "ethersex.bin"; # bootfile (Achtung das ethersex.bin file nehmen!) } } </pre> Anschließend kann der DHCP Server gestartet/neu gestartet werden: sudo /etc/init.d/dhcp3-server restart ===TFTP Server konfigurieren=== Die Konfiguration des TFTP Servers ist ziemlich einfach. Dieser muss nur installiert und gestartet werden: sudo apt-get install tftpd-hpa Die vom Makefile generierte ethersex.bin Datei muss dann nur noch nach /var/lib/tftpboot kopiert werden. Den TFTP Server startetn/neu starten sudo /etc/init.d/tftpd-hpa restart == Bekannte Probleme == Ist im µC bereits eine Firmware geflasht, so sollten durch den BOOTP-Mechanismus die Netzwerkparameter wie IP, Gateway, DNS und Gateway bezogen werden. Laut Logfile vom haneWin DHCP Server erfolgt dies auch. Danach sollte dann die Firmware mit genau diesen Netzwerkparametern gestartet werden. Dies geschiet aber nicht, da vermutlich die Netzwerkparameter nicht an die Firmware weitergereicht werden. Es werden die alten Netzwerkparameter geladen trotz der Einstellung in ''menuconfig'', dass BOOTP verwendet werden soll. Man erkennt mit dem Kommando ''arp -a'' in der Windows-Konsole, dass nach dem Booten die neuen Netzwerkparameter mit der IP vom BOOTP-Server vergeben wurden. Im zweiten Schritt, wenn der µC die Firmware läd, jedoch die alte letzte IP-Adresse benutzt. Daher muss man mit ''arp -d'' die ARP-Tabelle löschen und sich unter der alten IP in den µC mit telnet (siehe [[ECMD Protocols]]) einloggen und mit den Befehlen ''ip, netmask, gw, dns server'' manuell auf die neuen Werte setzen. Alternativ kann man den µC zwingen die neue Firmware zu laden, die dann aber intern die gleichen Netzwerkparameter wie der BOOTP-Server haben muss. Schade eigentlich, so hätte man sehr elegant mit dem BOOTP-Server die Netzwerkparameter zur Bootzeit vergeben können. Ich habe gerade noch einmal in den Quellen nachgesehen, dort werden die Netzwerkparameter von BOOTP nur im EEPROM des µC gespeichert, wenn ''Write BOOTP data to EEPROM'' in ''menuconfig'' ausgewählt ist. Damit lassen sich die Netzwerkparameter zwischenspeichern und stehen nach dem Start der Firmware als Default zur Verfügung. Per Default wird diese Option nicht geladen. Das Problem sollte sich damit beheben lassen. Das habe ich aber bisher noch nicht getestet. Wenn dem so ist, sollte die Default-Konfiguration des ''Ethernet Bootloader'' entsprechend angepasst werden. Ist die zu ladende Firmware größer als 56kB, so wird die Firmware nicht richtig geflasht, da ab xE000 der Ethernet-Bootloader den Bereich mit gesetzten Secure-Bits blockiert. == Nützliche Links == * [http://www.atmel.com/dyn/resources/prod_documents/doc2475.pdf ATMEL JTAG-Interface-Beschreibung] * [http://www.atmel.com/dyn/resources/prod_documents/doc2593.pdf Datenblatt zum ATMEGA644] 1e0b9e479b9a97838c173b721de4fca8d72eb774 1662 1660 2016-01-30T19:45:57Z Djmaster 255 /* Konfiguration in menuconfig */ wikitext text/x-wiki {{i18n|BOOTP}} {{Module |NAME=BOOTP |MENUCONFIG={{Protocol}}->BOOTP |STATUS={{In_Development}} |PINNING=no |ECMD=no |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/protocols/bootp https://github.com/ethersex/ethersex/tree/master/protocols/bootp] }} == Warum BOOTP? == Jeder kennt das Problem, wenn man eine Firmware erstellt hat, muss sie irgendwie in die Hardware kommen. Der gängige Weg, man flasht die Hardware mit einem Programmieradapter über SPI oder [http://de.wikipedia.org/wiki/Joint_Test_Action_Group JTAG] ([http://www.atmel.com/dyn/resources/prod_documents/doc2475.pdf ATMEL]). In der Firmware muss die [http://de.wikipedia.org/wiki/MAC-Adresse MAC]- Adresse und die [http://de.wikipedia.org/wiki/IP-Adresse IP-Adresse] für die Hardware (µC) einkompiliert sein. Sie ist damit erstmals fix und kann nur nachträglich über das ECMD-Kommandos ip geändert werden. Schön wäre es, wenn man sich um die IP-Adresse nicht kümmern müsste und sie selbständig zum Bootzeitpunkt geladen wird. Und noch schöner wäre es, wenn der µC sich auch gleich die aktuelle Firmware selbst laden und flashen würde. Genau dies macht jetzt BOOTP.<br /> === BOOTP Startsequenz === [http://de.wikipedia.org/wiki/Bootstrap_Protocol BOOTP] ist der Vorläufer von [http://de.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol DHCP] mit dem einem Netzwerkgerät wie z.B. unserem µC eine IP-Adresse zugeordnet werden kann. Falls das Netzwerkgerät nicht über einen eigenen Festspeicher verfügt, kann auch die Firmware oder das Betriebssystem auf Anfrage des Netzwerkgerätes übertragen werden. Damit BOOTP funktioniert, muss ein Minimalprogramm mit dem BOOTP-Client auf dem Netzwerkgerät als Bootloader gespeicher sein. Bei einem PC liegt dieses Programm in der Netzwerkkarte. Auf unserem µC muss der Ethernet Bootloader geflasht sein. Dieser enthält eine eindeutige MAC-Adresse für das Netzwerkgerät, damit es adressiert werden kann.<br /> Zum Bootzeitpunkt verfügt der µC nur über die MAC-Adresse. Er stellt also als erstes eine Broadcast-Anfrage an alle Netzwerkteilnehmer mit der Bitte ihm eine IP-Adresse zu geben. Gibt es im Netzwerk einen anderen Rechner, der einen BOOTP- oder DHCP-Server enthält, so antwortet dieser Server und gibt ihm, sofern erlaubt, eine IP-Adresse, die Netmask und das Gateway. Ab nun an kann der µC unter dieser Adresse erreicht werden. Als nächstes fragt der µC den BOOTP-Server nach einer aktuellen Firmware. Dieser teilt ihm den Server und den Port mit, von dem die Firmware per [http://de.wikipedia.org/wiki/Trivial_File_Transfer_Protocol TFTP] geladen werden kann. Mit dieser Art des bootens, kann sehr elegant der µC geflasht und gleichzeitig eine IP-Adresse zugeordnet werden. Das eigentliche flashen der Firmware macht der µC damit selbständig. Mit dem Ethernet Bootloader und BOOTP ist es möglich, beliebige Firmware zu laden ohne ein Programmieradapter zu benutzen. Es muss lediglich die aktuelle Firmware auf dem BOOTP-Server hinterlegt sein und einmal der µC neu gestartet werden und schon flasht er sich selbständig ohne weiteres zutun nur über das Netzwerk. Diese Art des "flashens" geht schneller als mit einem Programmieradapter. In gut 10s ist die Firmware (ca. 50kB) geladen, geflasht und gestartet.<br /> === Voraussetzungen === Damit BOOTP benutzt werden kann müssen bestimmte Voraussetzungen erfüllt sein: * Nur mit einem ATMEGA644 oder größer läßt sich der 8KB Ethernet Bootloader flashen * Der Bootloader mit BOOTP belegt die letzten 8KB ab Adresse xE000 des Programmspeichers, die nicht mehr genutzt werden können * Die Programmgröße (Firmware) ist auf 56 KB beschränkt * Die Securebits sollten gesetzt sein, damit der Bootloader sich nicht selbst überschreiben kann * Es muss ein BOOTP- und TFTP- Server wie z.B. HahneDHCP o.ä. im Netzwerk erreichbar sein * Die Firmware muss als ethersex.bin auf dem TFTP-Server hinterlegt sein * In der Firmware muss die selbe MAC-Adresse verwendet werden wie im Bootloader von BOOTP == Konfiguration in menuconfig == Als Basis kann in nenuconfig die Option "Bootloader BOOTP" gewählt werden. Es ist zu beachten, dass '''keine spezifischen Einstellungen''' außer CPU-Typ und MCU frequency für die jeweilige Hardware im Bootloader durchgeführt werden. Die hardwarespezifischen Einstellungen werden in der Firmware vorgenommen. Folgende Optionen sollten in '''menuconfig''' aktiviert sein: * '''config-File''' ** Load a Default Configuration ---> ** General Setup *** ATMEGA644 │ │ Load a Default Configuration ---> │ │ (*) Ethernet Bootloader │ │ General Setup ---> │ │ (ATmega644) Target MCU │ │ (20000000) MCU frequency // 16000000 für AVR-NET-IO │ │ [*] Build a bootloader │ │ [*] Teensy build │ │ Network ---> │ │ Hostname: "ethersex" // Hostname ändern │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "00:11:22:33:44:55" // MAC ändern mit "Randomize MAC address" │ │ Randomize MAC address │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ [*] BOOTP (DHCP-like) support │ │ Applications ---> │ │ [*] TFTP support '''Wichtig!''' Die MAC-Adresse muss gesetzt sein. Die selbe MAC-Adresse muss in der Firmware später auch benutzt werden. Hier ist eine [http://www.phw-magdeburg.de/ethersex/BOOTP.config Konfigurationsdatei] für das Pollin AVR-NET-IO mit Addon (MAC: AC:DE:48:CE:23:C8 ): Damit man nun nicht jedes mal die MAC-Adresse neu einkompilieren muss, kann man sie auch händisch mit einem Texteditor in [http://www.phw-magdeburg.de/ethersex/ethersex.hex ''ethersex.hex''] ändern. <source lang="perl"> :10E000003EC0000066C0000064C0000062C00000A6 :10E0100060C000005EC000005CC000005AC000008C :10E0200058C0000056C0000054C0000052C000009C :10E0300050C0000014C100004CC000004AC00000E5 :10E0400048C0000046C0000044C0000042C00000BC :10E0500040C000003EC000003CC000003AC00000CC :10E0600038C0000036C0000034C0000032C00000DC :10E07000"ACDE48CE23C8"006F63746574000014BE24 :10E0800088E10FB6F89480936000109260000FBE94 :10E0900010926E0010926F001092700011241FBE3B :10E0A000CFEFD0E1DEBFCDBF11E0A0E0B1E0E8EE00 </source> == Flashen des Bootloaders == Nach der Konfiguration mit menuconfig den Bootloader mit ''make clean'' und ''make'' compilieren und mit einem Programmieradapter die Datei ''ethersex.hex'' flashen. Wenn eine alte Vorlage benutzt wird, muss ggf. die MAC-Adresse noch einmal geändert werden. Damit der Bootloader nicht durch die Firmware überschrieben wird, müssen die Lock-Bits folgendermaßen gesetzt sein: Für ATmega644: ''avrdude -p m644 -c ponyser -P /dev/ttyS0 -U lock:w:0x0F:m'' oder in Ponyprog: *(x) BootLock02 *(x) BootLock01 *(x) Lock2 *(x) Lock1 '''Achtung!''' Sollte der Bootloader neu geflasht werden, so müssen die Lock-Bits nach dem flashen immer wieder neu gesetzt werden. Wer keine Lust hat den Ethernet-Bootloader zu kompilieren, kann hier für das AVR-NET-IO mit Addon die Datei [http://www.phw-magdeburg.de/ethersex/ethersex.hex ''ethersex.hex''] verwenden. == BOOTP-Server konfigurieren (Windows) == Als BOOTP-Server verwende ich unter Windows '''hahneWin DHCP Server'''. Als Beispielkonfiguration ist bei mir folgendes eingestellt: * Kein DHCP sondern nur BOOTP aktiviert (zur Problemvermeidung bei bestehendem DHCP-Server) * 192.168.0.0 Netzwerk für BOOTP * 192.168.0.1 Rechner mit hahneWin DHCP Server und TFTP auf Port 69 * statische Adressvergabe über MAC-Adressen fest zugewiesen * 192.168.0.88 AVR-NET-IO mit MAC AC:DE:48:CE:23:C8 * 255.255.255.0 Netmask * 192.168.0.251 Gateway * 192.168.0.251 DNS-Server [[File:Hahne_DHCP.jpg]] Abb.: hahneWin DHCP Server Alle weiteren Einstellungen zum hahneWin DHCP Server können den nachfolgenden Links entnommen werden: Grundsätzlich werden als erstes unter ''Optionen->Einstellungen'' die Grundeinstellungen vorgenommen. * [http://www.phw-magdeburg.de/ethersex/Einstellungen_Allgemein.JPG Einstellungen Allgemein] * [http://www.phw-magdeburg.de/ethersex/Einstellungen_Schnittstellen.JPG Einstellungen Schnittstellen] * [http://www.phw-magdeburg.de/ethersex/Einstellungen_DHCP.JPG Einstellungen DHCP] * [http://www.phw-magdeburg.de/ethersex/Einstellungen_TFTP.JPG Einstellungen TFTP] * [http://www.phw-magdeburg.de/ethersex/Einstellungen_TFTP_Optionen.JPG Einstellungen TFTP Optionen] Im zweiten Schritt werden unter ''Optionen->Konfigurationsprofile verwalten'' das betreffende Netzwerk ausgewählt und mit ''Bearbeiten'' angepaßt. Im meinem Beispiel wurde der Profilname durch Ethersex ersetzt. Vorher stand dort If-2_0.1. * [http://www.phw-magdeburg.de/ethersex/Konfigurationsprofile.JPG Konfigurationsprofile] * [http://www.phw-magdeburg.de/ethersex/Ethersex_Basiskonfiguration.JPG Basiskonfiguration] * [http://www.phw-magdeburg.de/ethersex/Ethersex_DNS.JPG DNS] * [http://www.phw-magdeburg.de/ethersex/Ethersex_Boot.JPG Boot] Als letztes wird dann noch ein neuer statischer Eintrag über den Schaltknopf ''Hinzufügen'' für den µC erstellt. * [http://www.phw-magdeburg.de/ethersex/Statische_Eintraege.JPG Statische Einträge] Alle nicht aufgeführten Seiten enthalten die Standardeinstellungen und müssen nicht weiter modifiziert werden. So, nun sollte der BOOTP-Server laufen. Den Server kann man unter ''Datei->Server starten/beenden'' in den jeweiligen Zustand setzen. === Hahne BOOTP-Server verwenden === Wird jetzt der µC gebootet, so bezieht er seine Netzwerkeinstellungen vom BOOTP-Server, läd danach die Firmware und startet diese. Im Logfile des BOOTP-Server können die Aktivitäten verfolgt werden. Sobald dem µC eine IP-Adresse vergeben wurde erscheint ein grünes Häkchen vor der MAC-Adresse in der Hauptansicht. Folgende Bedingungen müssen beachtet werden: * hat der µC noch keine Firmware geladen, so wird diese per TFTP im BOOTP-Prozess geladen und geflasht * ist schon eine Firmware im µC geflasht, so werden nur die Netzwerkparameter nach einem Reboot oder Power on/off geladen und die vorhandene Firmware gestartet * um die Firmware erleut zu laden, muss mit dem [[ECMD]] Kommando ''wdreset'' oder ''bootloader'' der µC "resettet" werden == BOOTP-Server konfigurieren (Linux) == Als BOOTP-Server verwende ich unter Linux '''dhcpd3'''. Als Beispielkonfiguration ist bei mir folgendes eingestellt: * Kein DHCP sondern nur BOOTP aktiviert (zur Problemvermeidung bei bestehendem DHCP-Server) * 192.168.30.0 Netzwerk für BOOTP * 192.168.30.134 Rechner mit DHCPD3 Server und TFTP auf Port 69 * statische Adressvergabe über MAC-Adressen fest zugewiesen * 192.168.30.10 AVR-NET-IO mit MAC AC:DE:48:CE:23:C8 * 255.255.255.0 Netmask * 192.168.30.1 Gateway * 192.168.30.1 DNS-Server Die folgende Konfiguration verfügt nicht über eine dynamische IP-Range. Dies bedeutet, dass diese Konfiguration nicht mit einem bereits vorhanden DHCP Server ins Gehege kommt. Dem ethersex wird zum Starten eine feste IP zugewiesen. Der Ablauf: #DHCP Server und TFTP Server müssen gestartet sein #Dann das AVR Net-IO in die Steckdose #Ethersex fragt mit seiner Netzwerkadresse ac:de:48:ce:23:c8 per bootp nach einer IP-Adresse #Der DHCP Server schaut in seiner Liste nach ac:de:48:ce:23:c8, findet diese und die IP 192.168.30.10 zusammen mit der TFTP Server IP 192.168.30.134 und dem Dateinamen ethersex.bin zurück an Ethersex #Ethersex kann nun eine IP Verbindung zum TFTP Server 192.168.30.134 aufbauen und lädt die Datei ethersex.bin #Anschlißend startet Ethersex mit der ethersex.bin ===DHCP-Server konfigurieren === sudo apt-get install dhcp3-server Anschließend muss die Konfigurationsdatei /etc/dhcp3/dhcpd.conf, wie folgt bearbeitet werden. Die IP Adressen musst Du an Deine Gegebenheiten anpassen. <pre> default-lease-time 86400; max-lease-time 2592000; authoritative; subnet 192.168.30.0 netmask 255.255.255.0 { option subnet-mask 255.255.255.0; # subnet maske option routers 192.168.30.1; # Gateway option domain-name-servers 192.168.30.1; # DNS Server ddns-update-style none; # Neue Clients werden dem DNS Server nicht mitgeteilt next-server 192.168.30.134; # TFTP Server host netio { hardware ethernet ac:de:48:ce:23:c8; # mac adresse des pollin net io fixed-address 192.168.30.10; # Eine freie IP-Adresse im lokalen Netz filename "ethersex.bin"; # bootfile (Achtung das ethersex.bin file nehmen!) } } </pre> Anschließend kann der DHCP Server gestartet/neu gestartet werden: sudo /etc/init.d/dhcp3-server restart ===TFTP Server konfigurieren=== Die Konfiguration des TFTP Servers ist ziemlich einfach. Dieser muss nur installiert und gestartet werden: sudo apt-get install tftpd-hpa Die vom Makefile generierte ethersex.bin Datei muss dann nur noch nach /var/lib/tftpboot kopiert werden. Den TFTP Server startetn/neu starten sudo /etc/init.d/tftpd-hpa restart == Bekannte Probleme == Ist im µC bereits eine Firmware geflasht, so sollten durch den BOOTP-Mechanismus die Netzwerkparameter wie IP, Gateway, DNS und Gateway bezogen werden. Laut Logfile vom haneWin DHCP Server erfolgt dies auch. Danach sollte dann die Firmware mit genau diesen Netzwerkparametern gestartet werden. Dies geschiet aber nicht, da vermutlich die Netzwerkparameter nicht an die Firmware weitergereicht werden. Es werden die alten Netzwerkparameter geladen trotz der Einstellung in ''menuconfig'', dass BOOTP verwendet werden soll. Man erkennt mit dem Kommando ''arp -a'' in der Windows-Konsole, dass nach dem Booten die neuen Netzwerkparameter mit der IP vom BOOTP-Server vergeben wurden. Im zweiten Schritt, wenn der µC die Firmware läd, jedoch die alte letzte IP-Adresse benutzt. Daher muss man mit ''arp -d'' die ARP-Tabelle löschen und sich unter der alten IP in den µC mit telnet (siehe [[ECMD Protocols]]) einloggen und mit den Befehlen ''ip, netmask, gw, dns server'' manuell auf die neuen Werte setzen. Alternativ kann man den µC zwingen die neue Firmware zu laden, die dann aber intern die gleichen Netzwerkparameter wie der BOOTP-Server haben muss. Schade eigentlich, so hätte man sehr elegant mit dem BOOTP-Server die Netzwerkparameter zur Bootzeit vergeben können. Ich habe gerade noch einmal in den Quellen nachgesehen, dort werden die Netzwerkparameter von BOOTP nur im EEPROM des µC gespeichert, wenn ''Write BOOTP data to EEPROM'' in ''menuconfig'' ausgewählt ist. Damit lassen sich die Netzwerkparameter zwischenspeichern und stehen nach dem Start der Firmware als Default zur Verfügung. Per Default wird diese Option nicht geladen. Das Problem sollte sich damit beheben lassen. Das habe ich aber bisher noch nicht getestet. Wenn dem so ist, sollte die Default-Konfiguration des ''Ethernet Bootloader'' entsprechend angepasst werden. Ist die zu ladende Firmware größer als 56kB, so wird die Firmware nicht richtig geflasht, da ab xE000 der Ethernet-Bootloader den Bereich mit gesetzten Secure-Bits blockiert. == Nützliche Links == * [http://www.atmel.com/dyn/resources/prod_documents/doc2475.pdf ATMEL JTAG-Interface-Beschreibung] * [http://www.atmel.com/dyn/resources/prod_documents/doc2593.pdf Datenblatt zum ATMEGA644] efc23bcbfdc930a70b6fde636de1e4e91fddce46 1663 1662 2016-01-30T19:46:21Z Djmaster 255 /* Konfiguration in menuconfig */ wikitext text/x-wiki {{i18n|BOOTP}} {{Module |NAME=BOOTP |MENUCONFIG={{Protocol}}->BOOTP |STATUS={{In_Development}} |PINNING=no |ECMD=no |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/protocols/bootp https://github.com/ethersex/ethersex/tree/master/protocols/bootp] }} == Warum BOOTP? == Jeder kennt das Problem, wenn man eine Firmware erstellt hat, muss sie irgendwie in die Hardware kommen. Der gängige Weg, man flasht die Hardware mit einem Programmieradapter über SPI oder [http://de.wikipedia.org/wiki/Joint_Test_Action_Group JTAG] ([http://www.atmel.com/dyn/resources/prod_documents/doc2475.pdf ATMEL]). In der Firmware muss die [http://de.wikipedia.org/wiki/MAC-Adresse MAC]- Adresse und die [http://de.wikipedia.org/wiki/IP-Adresse IP-Adresse] für die Hardware (µC) einkompiliert sein. Sie ist damit erstmals fix und kann nur nachträglich über das ECMD-Kommandos ip geändert werden. Schön wäre es, wenn man sich um die IP-Adresse nicht kümmern müsste und sie selbständig zum Bootzeitpunkt geladen wird. Und noch schöner wäre es, wenn der µC sich auch gleich die aktuelle Firmware selbst laden und flashen würde. Genau dies macht jetzt BOOTP.<br /> === BOOTP Startsequenz === [http://de.wikipedia.org/wiki/Bootstrap_Protocol BOOTP] ist der Vorläufer von [http://de.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol DHCP] mit dem einem Netzwerkgerät wie z.B. unserem µC eine IP-Adresse zugeordnet werden kann. Falls das Netzwerkgerät nicht über einen eigenen Festspeicher verfügt, kann auch die Firmware oder das Betriebssystem auf Anfrage des Netzwerkgerätes übertragen werden. Damit BOOTP funktioniert, muss ein Minimalprogramm mit dem BOOTP-Client auf dem Netzwerkgerät als Bootloader gespeicher sein. Bei einem PC liegt dieses Programm in der Netzwerkkarte. Auf unserem µC muss der Ethernet Bootloader geflasht sein. Dieser enthält eine eindeutige MAC-Adresse für das Netzwerkgerät, damit es adressiert werden kann.<br /> Zum Bootzeitpunkt verfügt der µC nur über die MAC-Adresse. Er stellt also als erstes eine Broadcast-Anfrage an alle Netzwerkteilnehmer mit der Bitte ihm eine IP-Adresse zu geben. Gibt es im Netzwerk einen anderen Rechner, der einen BOOTP- oder DHCP-Server enthält, so antwortet dieser Server und gibt ihm, sofern erlaubt, eine IP-Adresse, die Netmask und das Gateway. Ab nun an kann der µC unter dieser Adresse erreicht werden. Als nächstes fragt der µC den BOOTP-Server nach einer aktuellen Firmware. Dieser teilt ihm den Server und den Port mit, von dem die Firmware per [http://de.wikipedia.org/wiki/Trivial_File_Transfer_Protocol TFTP] geladen werden kann. Mit dieser Art des bootens, kann sehr elegant der µC geflasht und gleichzeitig eine IP-Adresse zugeordnet werden. Das eigentliche flashen der Firmware macht der µC damit selbständig. Mit dem Ethernet Bootloader und BOOTP ist es möglich, beliebige Firmware zu laden ohne ein Programmieradapter zu benutzen. Es muss lediglich die aktuelle Firmware auf dem BOOTP-Server hinterlegt sein und einmal der µC neu gestartet werden und schon flasht er sich selbständig ohne weiteres zutun nur über das Netzwerk. Diese Art des "flashens" geht schneller als mit einem Programmieradapter. In gut 10s ist die Firmware (ca. 50kB) geladen, geflasht und gestartet.<br /> === Voraussetzungen === Damit BOOTP benutzt werden kann müssen bestimmte Voraussetzungen erfüllt sein: * Nur mit einem ATMEGA644 oder größer läßt sich der 8KB Ethernet Bootloader flashen * Der Bootloader mit BOOTP belegt die letzten 8KB ab Adresse xE000 des Programmspeichers, die nicht mehr genutzt werden können * Die Programmgröße (Firmware) ist auf 56 KB beschränkt * Die Securebits sollten gesetzt sein, damit der Bootloader sich nicht selbst überschreiben kann * Es muss ein BOOTP- und TFTP- Server wie z.B. HahneDHCP o.ä. im Netzwerk erreichbar sein * Die Firmware muss als ethersex.bin auf dem TFTP-Server hinterlegt sein * In der Firmware muss die selbe MAC-Adresse verwendet werden wie im Bootloader von BOOTP == Konfiguration in menuconfig == Als Basis kann in nenuconfig die Option "Bootloader BOOTP" gewählt werden. Es ist zu beachten, dass '''keine spezifischen Einstellungen''' außer CPU-Typ und MCU frequency für die jeweilige Hardware im Bootloader durchgeführt werden. Die hardwarespezifischen Einstellungen werden in der Firmware vorgenommen. Folgende Optionen sollten in '''menuconfig''' aktiviert sein: │ │ Load a Default Configuration ---> │ │ (*) Ethernet Bootloader │ │ General Setup ---> │ │ (ATmega644) Target MCU │ │ (20000000) MCU frequency // 16000000 für AVR-NET-IO │ │ [*] Build a bootloader │ │ [*] Teensy build │ │ Network ---> │ │ Hostname: "ethersex" // Hostname ändern │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "00:11:22:33:44:55" // MAC ändern mit "Randomize MAC address" │ │ Randomize MAC address │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ [*] BOOTP (DHCP-like) support │ │ Applications ---> │ │ [*] TFTP support '''Wichtig!''' Die MAC-Adresse muss gesetzt sein. Die selbe MAC-Adresse muss in der Firmware später auch benutzt werden. Hier ist eine [http://www.phw-magdeburg.de/ethersex/BOOTP.config Konfigurationsdatei] für das Pollin AVR-NET-IO mit Addon (MAC: AC:DE:48:CE:23:C8 ): Damit man nun nicht jedes mal die MAC-Adresse neu einkompilieren muss, kann man sie auch händisch mit einem Texteditor in [http://www.phw-magdeburg.de/ethersex/ethersex.hex ''ethersex.hex''] ändern. <source lang="perl"> :10E000003EC0000066C0000064C0000062C00000A6 :10E0100060C000005EC000005CC000005AC000008C :10E0200058C0000056C0000054C0000052C000009C :10E0300050C0000014C100004CC000004AC00000E5 :10E0400048C0000046C0000044C0000042C00000BC :10E0500040C000003EC000003CC000003AC00000CC :10E0600038C0000036C0000034C0000032C00000DC :10E07000"ACDE48CE23C8"006F63746574000014BE24 :10E0800088E10FB6F89480936000109260000FBE94 :10E0900010926E0010926F001092700011241FBE3B :10E0A000CFEFD0E1DEBFCDBF11E0A0E0B1E0E8EE00 </source> == Flashen des Bootloaders == Nach der Konfiguration mit menuconfig den Bootloader mit ''make clean'' und ''make'' compilieren und mit einem Programmieradapter die Datei ''ethersex.hex'' flashen. Wenn eine alte Vorlage benutzt wird, muss ggf. die MAC-Adresse noch einmal geändert werden. Damit der Bootloader nicht durch die Firmware überschrieben wird, müssen die Lock-Bits folgendermaßen gesetzt sein: Für ATmega644: ''avrdude -p m644 -c ponyser -P /dev/ttyS0 -U lock:w:0x0F:m'' oder in Ponyprog: *(x) BootLock02 *(x) BootLock01 *(x) Lock2 *(x) Lock1 '''Achtung!''' Sollte der Bootloader neu geflasht werden, so müssen die Lock-Bits nach dem flashen immer wieder neu gesetzt werden. Wer keine Lust hat den Ethernet-Bootloader zu kompilieren, kann hier für das AVR-NET-IO mit Addon die Datei [http://www.phw-magdeburg.de/ethersex/ethersex.hex ''ethersex.hex''] verwenden. == BOOTP-Server konfigurieren (Windows) == Als BOOTP-Server verwende ich unter Windows '''hahneWin DHCP Server'''. Als Beispielkonfiguration ist bei mir folgendes eingestellt: * Kein DHCP sondern nur BOOTP aktiviert (zur Problemvermeidung bei bestehendem DHCP-Server) * 192.168.0.0 Netzwerk für BOOTP * 192.168.0.1 Rechner mit hahneWin DHCP Server und TFTP auf Port 69 * statische Adressvergabe über MAC-Adressen fest zugewiesen * 192.168.0.88 AVR-NET-IO mit MAC AC:DE:48:CE:23:C8 * 255.255.255.0 Netmask * 192.168.0.251 Gateway * 192.168.0.251 DNS-Server [[File:Hahne_DHCP.jpg]] Abb.: hahneWin DHCP Server Alle weiteren Einstellungen zum hahneWin DHCP Server können den nachfolgenden Links entnommen werden: Grundsätzlich werden als erstes unter ''Optionen->Einstellungen'' die Grundeinstellungen vorgenommen. * [http://www.phw-magdeburg.de/ethersex/Einstellungen_Allgemein.JPG Einstellungen Allgemein] * [http://www.phw-magdeburg.de/ethersex/Einstellungen_Schnittstellen.JPG Einstellungen Schnittstellen] * [http://www.phw-magdeburg.de/ethersex/Einstellungen_DHCP.JPG Einstellungen DHCP] * [http://www.phw-magdeburg.de/ethersex/Einstellungen_TFTP.JPG Einstellungen TFTP] * [http://www.phw-magdeburg.de/ethersex/Einstellungen_TFTP_Optionen.JPG Einstellungen TFTP Optionen] Im zweiten Schritt werden unter ''Optionen->Konfigurationsprofile verwalten'' das betreffende Netzwerk ausgewählt und mit ''Bearbeiten'' angepaßt. Im meinem Beispiel wurde der Profilname durch Ethersex ersetzt. Vorher stand dort If-2_0.1. * [http://www.phw-magdeburg.de/ethersex/Konfigurationsprofile.JPG Konfigurationsprofile] * [http://www.phw-magdeburg.de/ethersex/Ethersex_Basiskonfiguration.JPG Basiskonfiguration] * [http://www.phw-magdeburg.de/ethersex/Ethersex_DNS.JPG DNS] * [http://www.phw-magdeburg.de/ethersex/Ethersex_Boot.JPG Boot] Als letztes wird dann noch ein neuer statischer Eintrag über den Schaltknopf ''Hinzufügen'' für den µC erstellt. * [http://www.phw-magdeburg.de/ethersex/Statische_Eintraege.JPG Statische Einträge] Alle nicht aufgeführten Seiten enthalten die Standardeinstellungen und müssen nicht weiter modifiziert werden. So, nun sollte der BOOTP-Server laufen. Den Server kann man unter ''Datei->Server starten/beenden'' in den jeweiligen Zustand setzen. === Hahne BOOTP-Server verwenden === Wird jetzt der µC gebootet, so bezieht er seine Netzwerkeinstellungen vom BOOTP-Server, läd danach die Firmware und startet diese. Im Logfile des BOOTP-Server können die Aktivitäten verfolgt werden. Sobald dem µC eine IP-Adresse vergeben wurde erscheint ein grünes Häkchen vor der MAC-Adresse in der Hauptansicht. Folgende Bedingungen müssen beachtet werden: * hat der µC noch keine Firmware geladen, so wird diese per TFTP im BOOTP-Prozess geladen und geflasht * ist schon eine Firmware im µC geflasht, so werden nur die Netzwerkparameter nach einem Reboot oder Power on/off geladen und die vorhandene Firmware gestartet * um die Firmware erleut zu laden, muss mit dem [[ECMD]] Kommando ''wdreset'' oder ''bootloader'' der µC "resettet" werden == BOOTP-Server konfigurieren (Linux) == Als BOOTP-Server verwende ich unter Linux '''dhcpd3'''. Als Beispielkonfiguration ist bei mir folgendes eingestellt: * Kein DHCP sondern nur BOOTP aktiviert (zur Problemvermeidung bei bestehendem DHCP-Server) * 192.168.30.0 Netzwerk für BOOTP * 192.168.30.134 Rechner mit DHCPD3 Server und TFTP auf Port 69 * statische Adressvergabe über MAC-Adressen fest zugewiesen * 192.168.30.10 AVR-NET-IO mit MAC AC:DE:48:CE:23:C8 * 255.255.255.0 Netmask * 192.168.30.1 Gateway * 192.168.30.1 DNS-Server Die folgende Konfiguration verfügt nicht über eine dynamische IP-Range. Dies bedeutet, dass diese Konfiguration nicht mit einem bereits vorhanden DHCP Server ins Gehege kommt. Dem ethersex wird zum Starten eine feste IP zugewiesen. Der Ablauf: #DHCP Server und TFTP Server müssen gestartet sein #Dann das AVR Net-IO in die Steckdose #Ethersex fragt mit seiner Netzwerkadresse ac:de:48:ce:23:c8 per bootp nach einer IP-Adresse #Der DHCP Server schaut in seiner Liste nach ac:de:48:ce:23:c8, findet diese und die IP 192.168.30.10 zusammen mit der TFTP Server IP 192.168.30.134 und dem Dateinamen ethersex.bin zurück an Ethersex #Ethersex kann nun eine IP Verbindung zum TFTP Server 192.168.30.134 aufbauen und lädt die Datei ethersex.bin #Anschlißend startet Ethersex mit der ethersex.bin ===DHCP-Server konfigurieren === sudo apt-get install dhcp3-server Anschließend muss die Konfigurationsdatei /etc/dhcp3/dhcpd.conf, wie folgt bearbeitet werden. Die IP Adressen musst Du an Deine Gegebenheiten anpassen. <pre> default-lease-time 86400; max-lease-time 2592000; authoritative; subnet 192.168.30.0 netmask 255.255.255.0 { option subnet-mask 255.255.255.0; # subnet maske option routers 192.168.30.1; # Gateway option domain-name-servers 192.168.30.1; # DNS Server ddns-update-style none; # Neue Clients werden dem DNS Server nicht mitgeteilt next-server 192.168.30.134; # TFTP Server host netio { hardware ethernet ac:de:48:ce:23:c8; # mac adresse des pollin net io fixed-address 192.168.30.10; # Eine freie IP-Adresse im lokalen Netz filename "ethersex.bin"; # bootfile (Achtung das ethersex.bin file nehmen!) } } </pre> Anschließend kann der DHCP Server gestartet/neu gestartet werden: sudo /etc/init.d/dhcp3-server restart ===TFTP Server konfigurieren=== Die Konfiguration des TFTP Servers ist ziemlich einfach. Dieser muss nur installiert und gestartet werden: sudo apt-get install tftpd-hpa Die vom Makefile generierte ethersex.bin Datei muss dann nur noch nach /var/lib/tftpboot kopiert werden. Den TFTP Server startetn/neu starten sudo /etc/init.d/tftpd-hpa restart == Bekannte Probleme == Ist im µC bereits eine Firmware geflasht, so sollten durch den BOOTP-Mechanismus die Netzwerkparameter wie IP, Gateway, DNS und Gateway bezogen werden. Laut Logfile vom haneWin DHCP Server erfolgt dies auch. Danach sollte dann die Firmware mit genau diesen Netzwerkparametern gestartet werden. Dies geschiet aber nicht, da vermutlich die Netzwerkparameter nicht an die Firmware weitergereicht werden. Es werden die alten Netzwerkparameter geladen trotz der Einstellung in ''menuconfig'', dass BOOTP verwendet werden soll. Man erkennt mit dem Kommando ''arp -a'' in der Windows-Konsole, dass nach dem Booten die neuen Netzwerkparameter mit der IP vom BOOTP-Server vergeben wurden. Im zweiten Schritt, wenn der µC die Firmware läd, jedoch die alte letzte IP-Adresse benutzt. Daher muss man mit ''arp -d'' die ARP-Tabelle löschen und sich unter der alten IP in den µC mit telnet (siehe [[ECMD Protocols]]) einloggen und mit den Befehlen ''ip, netmask, gw, dns server'' manuell auf die neuen Werte setzen. Alternativ kann man den µC zwingen die neue Firmware zu laden, die dann aber intern die gleichen Netzwerkparameter wie der BOOTP-Server haben muss. Schade eigentlich, so hätte man sehr elegant mit dem BOOTP-Server die Netzwerkparameter zur Bootzeit vergeben können. Ich habe gerade noch einmal in den Quellen nachgesehen, dort werden die Netzwerkparameter von BOOTP nur im EEPROM des µC gespeichert, wenn ''Write BOOTP data to EEPROM'' in ''menuconfig'' ausgewählt ist. Damit lassen sich die Netzwerkparameter zwischenspeichern und stehen nach dem Start der Firmware als Default zur Verfügung. Per Default wird diese Option nicht geladen. Das Problem sollte sich damit beheben lassen. Das habe ich aber bisher noch nicht getestet. Wenn dem so ist, sollte die Default-Konfiguration des ''Ethernet Bootloader'' entsprechend angepasst werden. Ist die zu ladende Firmware größer als 56kB, so wird die Firmware nicht richtig geflasht, da ab xE000 der Ethernet-Bootloader den Bereich mit gesetzten Secure-Bits blockiert. == Nützliche Links == * [http://www.atmel.com/dyn/resources/prod_documents/doc2475.pdf ATMEL JTAG-Interface-Beschreibung] * [http://www.atmel.com/dyn/resources/prod_documents/doc2593.pdf Datenblatt zum ATMEGA644] 049d1d8a7d8ff854645bf1690c29b324ba2cad75 1675 1663 2016-01-30T19:58:40Z Djmaster 255 /* BOOTP-Server konfigurieren (Windows) */ wikitext text/x-wiki {{i18n|BOOTP}} {{Module |NAME=BOOTP |MENUCONFIG={{Protocol}}->BOOTP |STATUS={{In_Development}} |PINNING=no |ECMD=no |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/protocols/bootp https://github.com/ethersex/ethersex/tree/master/protocols/bootp] }} == Warum BOOTP? == Jeder kennt das Problem, wenn man eine Firmware erstellt hat, muss sie irgendwie in die Hardware kommen. Der gängige Weg, man flasht die Hardware mit einem Programmieradapter über SPI oder [http://de.wikipedia.org/wiki/Joint_Test_Action_Group JTAG] ([http://www.atmel.com/dyn/resources/prod_documents/doc2475.pdf ATMEL]). In der Firmware muss die [http://de.wikipedia.org/wiki/MAC-Adresse MAC]- Adresse und die [http://de.wikipedia.org/wiki/IP-Adresse IP-Adresse] für die Hardware (µC) einkompiliert sein. Sie ist damit erstmals fix und kann nur nachträglich über das ECMD-Kommandos ip geändert werden. Schön wäre es, wenn man sich um die IP-Adresse nicht kümmern müsste und sie selbständig zum Bootzeitpunkt geladen wird. Und noch schöner wäre es, wenn der µC sich auch gleich die aktuelle Firmware selbst laden und flashen würde. Genau dies macht jetzt BOOTP.<br /> === BOOTP Startsequenz === [http://de.wikipedia.org/wiki/Bootstrap_Protocol BOOTP] ist der Vorläufer von [http://de.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol DHCP] mit dem einem Netzwerkgerät wie z.B. unserem µC eine IP-Adresse zugeordnet werden kann. Falls das Netzwerkgerät nicht über einen eigenen Festspeicher verfügt, kann auch die Firmware oder das Betriebssystem auf Anfrage des Netzwerkgerätes übertragen werden. Damit BOOTP funktioniert, muss ein Minimalprogramm mit dem BOOTP-Client auf dem Netzwerkgerät als Bootloader gespeicher sein. Bei einem PC liegt dieses Programm in der Netzwerkkarte. Auf unserem µC muss der Ethernet Bootloader geflasht sein. Dieser enthält eine eindeutige MAC-Adresse für das Netzwerkgerät, damit es adressiert werden kann.<br /> Zum Bootzeitpunkt verfügt der µC nur über die MAC-Adresse. Er stellt also als erstes eine Broadcast-Anfrage an alle Netzwerkteilnehmer mit der Bitte ihm eine IP-Adresse zu geben. Gibt es im Netzwerk einen anderen Rechner, der einen BOOTP- oder DHCP-Server enthält, so antwortet dieser Server und gibt ihm, sofern erlaubt, eine IP-Adresse, die Netmask und das Gateway. Ab nun an kann der µC unter dieser Adresse erreicht werden. Als nächstes fragt der µC den BOOTP-Server nach einer aktuellen Firmware. Dieser teilt ihm den Server und den Port mit, von dem die Firmware per [http://de.wikipedia.org/wiki/Trivial_File_Transfer_Protocol TFTP] geladen werden kann. Mit dieser Art des bootens, kann sehr elegant der µC geflasht und gleichzeitig eine IP-Adresse zugeordnet werden. Das eigentliche flashen der Firmware macht der µC damit selbständig. Mit dem Ethernet Bootloader und BOOTP ist es möglich, beliebige Firmware zu laden ohne ein Programmieradapter zu benutzen. Es muss lediglich die aktuelle Firmware auf dem BOOTP-Server hinterlegt sein und einmal der µC neu gestartet werden und schon flasht er sich selbständig ohne weiteres zutun nur über das Netzwerk. Diese Art des "flashens" geht schneller als mit einem Programmieradapter. In gut 10s ist die Firmware (ca. 50kB) geladen, geflasht und gestartet.<br /> === Voraussetzungen === Damit BOOTP benutzt werden kann müssen bestimmte Voraussetzungen erfüllt sein: * Nur mit einem ATMEGA644 oder größer läßt sich der 8KB Ethernet Bootloader flashen * Der Bootloader mit BOOTP belegt die letzten 8KB ab Adresse xE000 des Programmspeichers, die nicht mehr genutzt werden können * Die Programmgröße (Firmware) ist auf 56 KB beschränkt * Die Securebits sollten gesetzt sein, damit der Bootloader sich nicht selbst überschreiben kann * Es muss ein BOOTP- und TFTP- Server wie z.B. HahneDHCP o.ä. im Netzwerk erreichbar sein * Die Firmware muss als ethersex.bin auf dem TFTP-Server hinterlegt sein * In der Firmware muss die selbe MAC-Adresse verwendet werden wie im Bootloader von BOOTP == Konfiguration in menuconfig == Als Basis kann in nenuconfig die Option "Bootloader BOOTP" gewählt werden. Es ist zu beachten, dass '''keine spezifischen Einstellungen''' außer CPU-Typ und MCU frequency für die jeweilige Hardware im Bootloader durchgeführt werden. Die hardwarespezifischen Einstellungen werden in der Firmware vorgenommen. Folgende Optionen sollten in '''menuconfig''' aktiviert sein: │ │ Load a Default Configuration ---> │ │ (*) Ethernet Bootloader │ │ General Setup ---> │ │ (ATmega644) Target MCU │ │ (20000000) MCU frequency // 16000000 für AVR-NET-IO │ │ [*] Build a bootloader │ │ [*] Teensy build │ │ Network ---> │ │ Hostname: "ethersex" // Hostname ändern │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "00:11:22:33:44:55" // MAC ändern mit "Randomize MAC address" │ │ Randomize MAC address │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ [*] BOOTP (DHCP-like) support │ │ Applications ---> │ │ [*] TFTP support '''Wichtig!''' Die MAC-Adresse muss gesetzt sein. Die selbe MAC-Adresse muss in der Firmware später auch benutzt werden. Hier ist eine [http://www.phw-magdeburg.de/ethersex/BOOTP.config Konfigurationsdatei] für das Pollin AVR-NET-IO mit Addon (MAC: AC:DE:48:CE:23:C8 ): Damit man nun nicht jedes mal die MAC-Adresse neu einkompilieren muss, kann man sie auch händisch mit einem Texteditor in [http://www.phw-magdeburg.de/ethersex/ethersex.hex ''ethersex.hex''] ändern. <source lang="perl"> :10E000003EC0000066C0000064C0000062C00000A6 :10E0100060C000005EC000005CC000005AC000008C :10E0200058C0000056C0000054C0000052C000009C :10E0300050C0000014C100004CC000004AC00000E5 :10E0400048C0000046C0000044C0000042C00000BC :10E0500040C000003EC000003CC000003AC00000CC :10E0600038C0000036C0000034C0000032C00000DC :10E07000"ACDE48CE23C8"006F63746574000014BE24 :10E0800088E10FB6F89480936000109260000FBE94 :10E0900010926E0010926F001092700011241FBE3B :10E0A000CFEFD0E1DEBFCDBF11E0A0E0B1E0E8EE00 </source> == Flashen des Bootloaders == Nach der Konfiguration mit menuconfig den Bootloader mit ''make clean'' und ''make'' compilieren und mit einem Programmieradapter die Datei ''ethersex.hex'' flashen. Wenn eine alte Vorlage benutzt wird, muss ggf. die MAC-Adresse noch einmal geändert werden. Damit der Bootloader nicht durch die Firmware überschrieben wird, müssen die Lock-Bits folgendermaßen gesetzt sein: Für ATmega644: ''avrdude -p m644 -c ponyser -P /dev/ttyS0 -U lock:w:0x0F:m'' oder in Ponyprog: *(x) BootLock02 *(x) BootLock01 *(x) Lock2 *(x) Lock1 '''Achtung!''' Sollte der Bootloader neu geflasht werden, so müssen die Lock-Bits nach dem flashen immer wieder neu gesetzt werden. Wer keine Lust hat den Ethernet-Bootloader zu kompilieren, kann hier für das AVR-NET-IO mit Addon die Datei [http://www.phw-magdeburg.de/ethersex/ethersex.hex ''ethersex.hex''] verwenden. == BOOTP-Server konfigurieren (Windows) == Als BOOTP-Server verwende ich unter Windows '''hahneWin DHCP Server'''. Als Beispielkonfiguration ist bei mir folgendes eingestellt: * Kein DHCP sondern nur BOOTP aktiviert (zur Problemvermeidung bei bestehendem DHCP-Server) * 192.168.0.0 Netzwerk für BOOTP * 192.168.0.1 Rechner mit hahneWin DHCP Server und TFTP auf Port 69 * statische Adressvergabe über MAC-Adressen fest zugewiesen * 192.168.0.88 AVR-NET-IO mit MAC AC:DE:48:CE:23:C8 * 255.255.255.0 Netmask * 192.168.0.251 Gateway * 192.168.0.251 DNS-Server [[File:Hahne_DHCP.jpg]] Abb.: hahneWin DHCP Server Alle weiteren Einstellungen zum hahneWin DHCP Server können den nachfolgenden Links entnommen werden: Grundsätzlich werden als erstes unter ''Optionen->Einstellungen'' die Grundeinstellungen vorgenommen. <div><ul> <li style="display: inline-block;"> [[File:Einstellungen_Allgemein.JPG|thumb|none|180px|Einstellungen Allgemein]] </li> <li style="display: inline-block;"> [[File:Einstellungen Schnittstellen.JPG|thumb|none|180px|Einstellungen Schnittstellen]] </li> <li style="display: inline-block;"> [[File:Einstellungen_DHCP.JPG|thumb|none|180px|Einstellungen DHCP]] </li> <li style="display: inline-block;"> [[File:Einstellungen_TFTP.JPG|thumb|none|180px|Einstellungen TFTP]] </li> <li style="display: inline-block;"> [[File:Einstellungen_TFTP_Optionen.JPG|thumb|none|180px|Einstellungen TFTP Optionen]] </li> </ul></div> Im zweiten Schritt werden unter ''Optionen->Konfigurationsprofile verwalten'' das betreffende Netzwerk ausgewählt und mit ''Bearbeiten'' angepaßt. Im meinem Beispiel wurde der Profilname durch Ethersex ersetzt. Vorher stand dort If-2_0.1. <div><ul> <li style="display: inline-block;"> [[File:Konfigurationsprofile.JPG|thumb|none|200px|Konfigurationsprofile]] </li> <li style="display: inline-block;"> [[File:Ethersex_Basiskonfiguration.JPG|thumb|none|180px|Basiskonfiguration]] </li> <li style="display: inline-block;"> [[File:Ethersex_DNS.JPG|thumb|none|180px|DNS]] </li> <li style="display: inline-block;"> [[File:Ethersex_Boot.JPG|thumb|none|180px|Boot]] </li> </ul></div> Als letztes wird dann noch ein neuer statischer Eintrag über den Schaltknopf ''Hinzufügen'' für den µC erstellt. <div><ul> <li style="display: inline-block;"> [[File:Statische_Eintraege.JPG|thumb|none|180px|Statische Einträge]] </li> </ul></div> Alle nicht aufgeführten Seiten enthalten die Standardeinstellungen und müssen nicht weiter modifiziert werden. So, nun sollte der BOOTP-Server laufen. Den Server kann man unter ''Datei->Server starten/beenden'' in den jeweiligen Zustand setzen. === Hahne BOOTP-Server verwenden === Wird jetzt der µC gebootet, so bezieht er seine Netzwerkeinstellungen vom BOOTP-Server, läd danach die Firmware und startet diese. Im Logfile des BOOTP-Server können die Aktivitäten verfolgt werden. Sobald dem µC eine IP-Adresse vergeben wurde erscheint ein grünes Häkchen vor der MAC-Adresse in der Hauptansicht. Folgende Bedingungen müssen beachtet werden: * hat der µC noch keine Firmware geladen, so wird diese per TFTP im BOOTP-Prozess geladen und geflasht * ist schon eine Firmware im µC geflasht, so werden nur die Netzwerkparameter nach einem Reboot oder Power on/off geladen und die vorhandene Firmware gestartet * um die Firmware erleut zu laden, muss mit dem [[ECMD]] Kommando ''wdreset'' oder ''bootloader'' der µC "resettet" werden == BOOTP-Server konfigurieren (Linux) == Als BOOTP-Server verwende ich unter Linux '''dhcpd3'''. Als Beispielkonfiguration ist bei mir folgendes eingestellt: * Kein DHCP sondern nur BOOTP aktiviert (zur Problemvermeidung bei bestehendem DHCP-Server) * 192.168.30.0 Netzwerk für BOOTP * 192.168.30.134 Rechner mit DHCPD3 Server und TFTP auf Port 69 * statische Adressvergabe über MAC-Adressen fest zugewiesen * 192.168.30.10 AVR-NET-IO mit MAC AC:DE:48:CE:23:C8 * 255.255.255.0 Netmask * 192.168.30.1 Gateway * 192.168.30.1 DNS-Server Die folgende Konfiguration verfügt nicht über eine dynamische IP-Range. Dies bedeutet, dass diese Konfiguration nicht mit einem bereits vorhanden DHCP Server ins Gehege kommt. Dem ethersex wird zum Starten eine feste IP zugewiesen. Der Ablauf: #DHCP Server und TFTP Server müssen gestartet sein #Dann das AVR Net-IO in die Steckdose #Ethersex fragt mit seiner Netzwerkadresse ac:de:48:ce:23:c8 per bootp nach einer IP-Adresse #Der DHCP Server schaut in seiner Liste nach ac:de:48:ce:23:c8, findet diese und die IP 192.168.30.10 zusammen mit der TFTP Server IP 192.168.30.134 und dem Dateinamen ethersex.bin zurück an Ethersex #Ethersex kann nun eine IP Verbindung zum TFTP Server 192.168.30.134 aufbauen und lädt die Datei ethersex.bin #Anschlißend startet Ethersex mit der ethersex.bin ===DHCP-Server konfigurieren === sudo apt-get install dhcp3-server Anschließend muss die Konfigurationsdatei /etc/dhcp3/dhcpd.conf, wie folgt bearbeitet werden. Die IP Adressen musst Du an Deine Gegebenheiten anpassen. <pre> default-lease-time 86400; max-lease-time 2592000; authoritative; subnet 192.168.30.0 netmask 255.255.255.0 { option subnet-mask 255.255.255.0; # subnet maske option routers 192.168.30.1; # Gateway option domain-name-servers 192.168.30.1; # DNS Server ddns-update-style none; # Neue Clients werden dem DNS Server nicht mitgeteilt next-server 192.168.30.134; # TFTP Server host netio { hardware ethernet ac:de:48:ce:23:c8; # mac adresse des pollin net io fixed-address 192.168.30.10; # Eine freie IP-Adresse im lokalen Netz filename "ethersex.bin"; # bootfile (Achtung das ethersex.bin file nehmen!) } } </pre> Anschließend kann der DHCP Server gestartet/neu gestartet werden: sudo /etc/init.d/dhcp3-server restart ===TFTP Server konfigurieren=== Die Konfiguration des TFTP Servers ist ziemlich einfach. Dieser muss nur installiert und gestartet werden: sudo apt-get install tftpd-hpa Die vom Makefile generierte ethersex.bin Datei muss dann nur noch nach /var/lib/tftpboot kopiert werden. Den TFTP Server startetn/neu starten sudo /etc/init.d/tftpd-hpa restart == Bekannte Probleme == Ist im µC bereits eine Firmware geflasht, so sollten durch den BOOTP-Mechanismus die Netzwerkparameter wie IP, Gateway, DNS und Gateway bezogen werden. Laut Logfile vom haneWin DHCP Server erfolgt dies auch. Danach sollte dann die Firmware mit genau diesen Netzwerkparametern gestartet werden. Dies geschiet aber nicht, da vermutlich die Netzwerkparameter nicht an die Firmware weitergereicht werden. Es werden die alten Netzwerkparameter geladen trotz der Einstellung in ''menuconfig'', dass BOOTP verwendet werden soll. Man erkennt mit dem Kommando ''arp -a'' in der Windows-Konsole, dass nach dem Booten die neuen Netzwerkparameter mit der IP vom BOOTP-Server vergeben wurden. Im zweiten Schritt, wenn der µC die Firmware läd, jedoch die alte letzte IP-Adresse benutzt. Daher muss man mit ''arp -d'' die ARP-Tabelle löschen und sich unter der alten IP in den µC mit telnet (siehe [[ECMD Protocols]]) einloggen und mit den Befehlen ''ip, netmask, gw, dns server'' manuell auf die neuen Werte setzen. Alternativ kann man den µC zwingen die neue Firmware zu laden, die dann aber intern die gleichen Netzwerkparameter wie der BOOTP-Server haben muss. Schade eigentlich, so hätte man sehr elegant mit dem BOOTP-Server die Netzwerkparameter zur Bootzeit vergeben können. Ich habe gerade noch einmal in den Quellen nachgesehen, dort werden die Netzwerkparameter von BOOTP nur im EEPROM des µC gespeichert, wenn ''Write BOOTP data to EEPROM'' in ''menuconfig'' ausgewählt ist. Damit lassen sich die Netzwerkparameter zwischenspeichern und stehen nach dem Start der Firmware als Default zur Verfügung. Per Default wird diese Option nicht geladen. Das Problem sollte sich damit beheben lassen. Das habe ich aber bisher noch nicht getestet. Wenn dem so ist, sollte die Default-Konfiguration des ''Ethernet Bootloader'' entsprechend angepasst werden. Ist die zu ladende Firmware größer als 56kB, so wird die Firmware nicht richtig geflasht, da ab xE000 der Ethernet-Bootloader den Bereich mit gesetzten Secure-Bits blockiert. == Nützliche Links == * [http://www.atmel.com/dyn/resources/prod_documents/doc2475.pdf ATMEL JTAG-Interface-Beschreibung] * [http://www.atmel.com/dyn/resources/prod_documents/doc2593.pdf Datenblatt zum ATMEGA644] aabd2cc74a6f9d3df9d8b27c76addc8423416b95 1676 1675 2016-01-30T20:00:40Z Djmaster 255 /* BOOTP-Server konfigurieren (Windows) */ wikitext text/x-wiki {{i18n|BOOTP}} {{Module |NAME=BOOTP |MENUCONFIG={{Protocol}}->BOOTP |STATUS={{In_Development}} |PINNING=no |ECMD=no |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/protocols/bootp https://github.com/ethersex/ethersex/tree/master/protocols/bootp] }} == Warum BOOTP? == Jeder kennt das Problem, wenn man eine Firmware erstellt hat, muss sie irgendwie in die Hardware kommen. Der gängige Weg, man flasht die Hardware mit einem Programmieradapter über SPI oder [http://de.wikipedia.org/wiki/Joint_Test_Action_Group JTAG] ([http://www.atmel.com/dyn/resources/prod_documents/doc2475.pdf ATMEL]). In der Firmware muss die [http://de.wikipedia.org/wiki/MAC-Adresse MAC]- Adresse und die [http://de.wikipedia.org/wiki/IP-Adresse IP-Adresse] für die Hardware (µC) einkompiliert sein. Sie ist damit erstmals fix und kann nur nachträglich über das ECMD-Kommandos ip geändert werden. Schön wäre es, wenn man sich um die IP-Adresse nicht kümmern müsste und sie selbständig zum Bootzeitpunkt geladen wird. Und noch schöner wäre es, wenn der µC sich auch gleich die aktuelle Firmware selbst laden und flashen würde. Genau dies macht jetzt BOOTP.<br /> === BOOTP Startsequenz === [http://de.wikipedia.org/wiki/Bootstrap_Protocol BOOTP] ist der Vorläufer von [http://de.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol DHCP] mit dem einem Netzwerkgerät wie z.B. unserem µC eine IP-Adresse zugeordnet werden kann. Falls das Netzwerkgerät nicht über einen eigenen Festspeicher verfügt, kann auch die Firmware oder das Betriebssystem auf Anfrage des Netzwerkgerätes übertragen werden. Damit BOOTP funktioniert, muss ein Minimalprogramm mit dem BOOTP-Client auf dem Netzwerkgerät als Bootloader gespeicher sein. Bei einem PC liegt dieses Programm in der Netzwerkkarte. Auf unserem µC muss der Ethernet Bootloader geflasht sein. Dieser enthält eine eindeutige MAC-Adresse für das Netzwerkgerät, damit es adressiert werden kann.<br /> Zum Bootzeitpunkt verfügt der µC nur über die MAC-Adresse. Er stellt also als erstes eine Broadcast-Anfrage an alle Netzwerkteilnehmer mit der Bitte ihm eine IP-Adresse zu geben. Gibt es im Netzwerk einen anderen Rechner, der einen BOOTP- oder DHCP-Server enthält, so antwortet dieser Server und gibt ihm, sofern erlaubt, eine IP-Adresse, die Netmask und das Gateway. Ab nun an kann der µC unter dieser Adresse erreicht werden. Als nächstes fragt der µC den BOOTP-Server nach einer aktuellen Firmware. Dieser teilt ihm den Server und den Port mit, von dem die Firmware per [http://de.wikipedia.org/wiki/Trivial_File_Transfer_Protocol TFTP] geladen werden kann. Mit dieser Art des bootens, kann sehr elegant der µC geflasht und gleichzeitig eine IP-Adresse zugeordnet werden. Das eigentliche flashen der Firmware macht der µC damit selbständig. Mit dem Ethernet Bootloader und BOOTP ist es möglich, beliebige Firmware zu laden ohne ein Programmieradapter zu benutzen. Es muss lediglich die aktuelle Firmware auf dem BOOTP-Server hinterlegt sein und einmal der µC neu gestartet werden und schon flasht er sich selbständig ohne weiteres zutun nur über das Netzwerk. Diese Art des "flashens" geht schneller als mit einem Programmieradapter. In gut 10s ist die Firmware (ca. 50kB) geladen, geflasht und gestartet.<br /> === Voraussetzungen === Damit BOOTP benutzt werden kann müssen bestimmte Voraussetzungen erfüllt sein: * Nur mit einem ATMEGA644 oder größer läßt sich der 8KB Ethernet Bootloader flashen * Der Bootloader mit BOOTP belegt die letzten 8KB ab Adresse xE000 des Programmspeichers, die nicht mehr genutzt werden können * Die Programmgröße (Firmware) ist auf 56 KB beschränkt * Die Securebits sollten gesetzt sein, damit der Bootloader sich nicht selbst überschreiben kann * Es muss ein BOOTP- und TFTP- Server wie z.B. HahneDHCP o.ä. im Netzwerk erreichbar sein * Die Firmware muss als ethersex.bin auf dem TFTP-Server hinterlegt sein * In der Firmware muss die selbe MAC-Adresse verwendet werden wie im Bootloader von BOOTP == Konfiguration in menuconfig == Als Basis kann in nenuconfig die Option "Bootloader BOOTP" gewählt werden. Es ist zu beachten, dass '''keine spezifischen Einstellungen''' außer CPU-Typ und MCU frequency für die jeweilige Hardware im Bootloader durchgeführt werden. Die hardwarespezifischen Einstellungen werden in der Firmware vorgenommen. Folgende Optionen sollten in '''menuconfig''' aktiviert sein: │ │ Load a Default Configuration ---> │ │ (*) Ethernet Bootloader │ │ General Setup ---> │ │ (ATmega644) Target MCU │ │ (20000000) MCU frequency // 16000000 für AVR-NET-IO │ │ [*] Build a bootloader │ │ [*] Teensy build │ │ Network ---> │ │ Hostname: "ethersex" // Hostname ändern │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "00:11:22:33:44:55" // MAC ändern mit "Randomize MAC address" │ │ Randomize MAC address │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ [*] BOOTP (DHCP-like) support │ │ Applications ---> │ │ [*] TFTP support '''Wichtig!''' Die MAC-Adresse muss gesetzt sein. Die selbe MAC-Adresse muss in der Firmware später auch benutzt werden. Hier ist eine [http://www.phw-magdeburg.de/ethersex/BOOTP.config Konfigurationsdatei] für das Pollin AVR-NET-IO mit Addon (MAC: AC:DE:48:CE:23:C8 ): Damit man nun nicht jedes mal die MAC-Adresse neu einkompilieren muss, kann man sie auch händisch mit einem Texteditor in [http://www.phw-magdeburg.de/ethersex/ethersex.hex ''ethersex.hex''] ändern. <source lang="perl"> :10E000003EC0000066C0000064C0000062C00000A6 :10E0100060C000005EC000005CC000005AC000008C :10E0200058C0000056C0000054C0000052C000009C :10E0300050C0000014C100004CC000004AC00000E5 :10E0400048C0000046C0000044C0000042C00000BC :10E0500040C000003EC000003CC000003AC00000CC :10E0600038C0000036C0000034C0000032C00000DC :10E07000"ACDE48CE23C8"006F63746574000014BE24 :10E0800088E10FB6F89480936000109260000FBE94 :10E0900010926E0010926F001092700011241FBE3B :10E0A000CFEFD0E1DEBFCDBF11E0A0E0B1E0E8EE00 </source> == Flashen des Bootloaders == Nach der Konfiguration mit menuconfig den Bootloader mit ''make clean'' und ''make'' compilieren und mit einem Programmieradapter die Datei ''ethersex.hex'' flashen. Wenn eine alte Vorlage benutzt wird, muss ggf. die MAC-Adresse noch einmal geändert werden. Damit der Bootloader nicht durch die Firmware überschrieben wird, müssen die Lock-Bits folgendermaßen gesetzt sein: Für ATmega644: ''avrdude -p m644 -c ponyser -P /dev/ttyS0 -U lock:w:0x0F:m'' oder in Ponyprog: *(x) BootLock02 *(x) BootLock01 *(x) Lock2 *(x) Lock1 '''Achtung!''' Sollte der Bootloader neu geflasht werden, so müssen die Lock-Bits nach dem flashen immer wieder neu gesetzt werden. Wer keine Lust hat den Ethernet-Bootloader zu kompilieren, kann hier für das AVR-NET-IO mit Addon die Datei [http://www.phw-magdeburg.de/ethersex/ethersex.hex ''ethersex.hex''] verwenden. == BOOTP-Server konfigurieren (Windows) == Als BOOTP-Server verwende ich unter Windows '''hahneWin DHCP Server'''. Als Beispielkonfiguration ist bei mir folgendes eingestellt: * Kein DHCP sondern nur BOOTP aktiviert (zur Problemvermeidung bei bestehendem DHCP-Server) * 192.168.0.0 Netzwerk für BOOTP * 192.168.0.1 Rechner mit hahneWin DHCP Server und TFTP auf Port 69 * statische Adressvergabe über MAC-Adressen fest zugewiesen * 192.168.0.88 AVR-NET-IO mit MAC AC:DE:48:CE:23:C8 * 255.255.255.0 Netmask * 192.168.0.251 Gateway * 192.168.0.251 DNS-Server <div><ul> <li style="display: inline-block;"> [[File:Hahne_DHCP.jpg|thumb|none|320px|hahneWin DHCP Server]] </li> </ul></div> Alle weiteren Einstellungen zum hahneWin DHCP Server können den nachfolgenden Links entnommen werden: Grundsätzlich werden als erstes unter ''Optionen->Einstellungen'' die Grundeinstellungen vorgenommen. <div><ul> <li style="display: inline-block;"> [[File:Einstellungen_Allgemein.JPG|thumb|none|150px|Einstellungen Allgemein]] </li> <li style="display: inline-block;"> [[File:Einstellungen Schnittstellen.JPG|thumb|none|150px|Einstellungen Schnittstellen]] </li> <li style="display: inline-block;"> [[File:Einstellungen_DHCP.JPG|thumb|none|150px|Einstellungen DHCP]] </li> <li style="display: inline-block;"> [[File:Einstellungen_TFTP.JPG|thumb|none|150px|Einstellungen TFTP]] </li> <li style="display: inline-block;"> [[File:Einstellungen_TFTP_Optionen.JPG|thumb|none|150px|Einstellungen TFTP Optionen]] </li> </ul></div> Im zweiten Schritt werden unter ''Optionen->Konfigurationsprofile verwalten'' das betreffende Netzwerk ausgewählt und mit ''Bearbeiten'' angepaßt. Im meinem Beispiel wurde der Profilname durch Ethersex ersetzt. Vorher stand dort If-2_0.1. <div><ul> <li style="display: inline-block;"> [[File:Konfigurationsprofile.JPG|thumb|none|200px|Konfigurationsprofile]] </li> <li style="display: inline-block;"> [[File:Ethersex_Basiskonfiguration.JPG|thumb|none|150px|Basiskonfiguration]] </li> <li style="display: inline-block;"> [[File:Ethersex_DNS.JPG|thumb|none|150px|DNS]] </li> <li style="display: inline-block;"> [[File:Ethersex_Boot.JPG|thumb|none|150px|Boot]] </li> </ul></div> Als letztes wird dann noch ein neuer statischer Eintrag über den Schaltknopf ''Hinzufügen'' für den µC erstellt. <div><ul> <li style="display: inline-block;"> [[File:Statische_Eintraege.JPG|thumb|none|150px|Statische Einträge]] </li> </ul></div> Alle nicht aufgeführten Seiten enthalten die Standardeinstellungen und müssen nicht weiter modifiziert werden. So, nun sollte der BOOTP-Server laufen. Den Server kann man unter ''Datei->Server starten/beenden'' in den jeweiligen Zustand setzen. === Hahne BOOTP-Server verwenden === Wird jetzt der µC gebootet, so bezieht er seine Netzwerkeinstellungen vom BOOTP-Server, läd danach die Firmware und startet diese. Im Logfile des BOOTP-Server können die Aktivitäten verfolgt werden. Sobald dem µC eine IP-Adresse vergeben wurde erscheint ein grünes Häkchen vor der MAC-Adresse in der Hauptansicht. Folgende Bedingungen müssen beachtet werden: * hat der µC noch keine Firmware geladen, so wird diese per TFTP im BOOTP-Prozess geladen und geflasht * ist schon eine Firmware im µC geflasht, so werden nur die Netzwerkparameter nach einem Reboot oder Power on/off geladen und die vorhandene Firmware gestartet * um die Firmware erleut zu laden, muss mit dem [[ECMD]] Kommando ''wdreset'' oder ''bootloader'' der µC "resettet" werden == BOOTP-Server konfigurieren (Linux) == Als BOOTP-Server verwende ich unter Linux '''dhcpd3'''. Als Beispielkonfiguration ist bei mir folgendes eingestellt: * Kein DHCP sondern nur BOOTP aktiviert (zur Problemvermeidung bei bestehendem DHCP-Server) * 192.168.30.0 Netzwerk für BOOTP * 192.168.30.134 Rechner mit DHCPD3 Server und TFTP auf Port 69 * statische Adressvergabe über MAC-Adressen fest zugewiesen * 192.168.30.10 AVR-NET-IO mit MAC AC:DE:48:CE:23:C8 * 255.255.255.0 Netmask * 192.168.30.1 Gateway * 192.168.30.1 DNS-Server Die folgende Konfiguration verfügt nicht über eine dynamische IP-Range. Dies bedeutet, dass diese Konfiguration nicht mit einem bereits vorhanden DHCP Server ins Gehege kommt. Dem ethersex wird zum Starten eine feste IP zugewiesen. Der Ablauf: #DHCP Server und TFTP Server müssen gestartet sein #Dann das AVR Net-IO in die Steckdose #Ethersex fragt mit seiner Netzwerkadresse ac:de:48:ce:23:c8 per bootp nach einer IP-Adresse #Der DHCP Server schaut in seiner Liste nach ac:de:48:ce:23:c8, findet diese und die IP 192.168.30.10 zusammen mit der TFTP Server IP 192.168.30.134 und dem Dateinamen ethersex.bin zurück an Ethersex #Ethersex kann nun eine IP Verbindung zum TFTP Server 192.168.30.134 aufbauen und lädt die Datei ethersex.bin #Anschlißend startet Ethersex mit der ethersex.bin ===DHCP-Server konfigurieren === sudo apt-get install dhcp3-server Anschließend muss die Konfigurationsdatei /etc/dhcp3/dhcpd.conf, wie folgt bearbeitet werden. Die IP Adressen musst Du an Deine Gegebenheiten anpassen. <pre> default-lease-time 86400; max-lease-time 2592000; authoritative; subnet 192.168.30.0 netmask 255.255.255.0 { option subnet-mask 255.255.255.0; # subnet maske option routers 192.168.30.1; # Gateway option domain-name-servers 192.168.30.1; # DNS Server ddns-update-style none; # Neue Clients werden dem DNS Server nicht mitgeteilt next-server 192.168.30.134; # TFTP Server host netio { hardware ethernet ac:de:48:ce:23:c8; # mac adresse des pollin net io fixed-address 192.168.30.10; # Eine freie IP-Adresse im lokalen Netz filename "ethersex.bin"; # bootfile (Achtung das ethersex.bin file nehmen!) } } </pre> Anschließend kann der DHCP Server gestartet/neu gestartet werden: sudo /etc/init.d/dhcp3-server restart ===TFTP Server konfigurieren=== Die Konfiguration des TFTP Servers ist ziemlich einfach. Dieser muss nur installiert und gestartet werden: sudo apt-get install tftpd-hpa Die vom Makefile generierte ethersex.bin Datei muss dann nur noch nach /var/lib/tftpboot kopiert werden. Den TFTP Server startetn/neu starten sudo /etc/init.d/tftpd-hpa restart == Bekannte Probleme == Ist im µC bereits eine Firmware geflasht, so sollten durch den BOOTP-Mechanismus die Netzwerkparameter wie IP, Gateway, DNS und Gateway bezogen werden. Laut Logfile vom haneWin DHCP Server erfolgt dies auch. Danach sollte dann die Firmware mit genau diesen Netzwerkparametern gestartet werden. Dies geschiet aber nicht, da vermutlich die Netzwerkparameter nicht an die Firmware weitergereicht werden. Es werden die alten Netzwerkparameter geladen trotz der Einstellung in ''menuconfig'', dass BOOTP verwendet werden soll. Man erkennt mit dem Kommando ''arp -a'' in der Windows-Konsole, dass nach dem Booten die neuen Netzwerkparameter mit der IP vom BOOTP-Server vergeben wurden. Im zweiten Schritt, wenn der µC die Firmware läd, jedoch die alte letzte IP-Adresse benutzt. Daher muss man mit ''arp -d'' die ARP-Tabelle löschen und sich unter der alten IP in den µC mit telnet (siehe [[ECMD Protocols]]) einloggen und mit den Befehlen ''ip, netmask, gw, dns server'' manuell auf die neuen Werte setzen. Alternativ kann man den µC zwingen die neue Firmware zu laden, die dann aber intern die gleichen Netzwerkparameter wie der BOOTP-Server haben muss. Schade eigentlich, so hätte man sehr elegant mit dem BOOTP-Server die Netzwerkparameter zur Bootzeit vergeben können. Ich habe gerade noch einmal in den Quellen nachgesehen, dort werden die Netzwerkparameter von BOOTP nur im EEPROM des µC gespeichert, wenn ''Write BOOTP data to EEPROM'' in ''menuconfig'' ausgewählt ist. Damit lassen sich die Netzwerkparameter zwischenspeichern und stehen nach dem Start der Firmware als Default zur Verfügung. Per Default wird diese Option nicht geladen. Das Problem sollte sich damit beheben lassen. Das habe ich aber bisher noch nicht getestet. Wenn dem so ist, sollte die Default-Konfiguration des ''Ethernet Bootloader'' entsprechend angepasst werden. Ist die zu ladende Firmware größer als 56kB, so wird die Firmware nicht richtig geflasht, da ab xE000 der Ethernet-Bootloader den Bereich mit gesetzten Secure-Bits blockiert. == Nützliche Links == * [http://www.atmel.com/dyn/resources/prod_documents/doc2475.pdf ATMEL JTAG-Interface-Beschreibung] * [http://www.atmel.com/dyn/resources/prod_documents/doc2593.pdf Datenblatt zum ATMEGA644] 080bc3f11d920519a119bf71186904cb6abfda9d 1678 1676 2016-01-30T20:02:39Z Djmaster 255 /* Bekannte Probleme */ wikitext text/x-wiki {{i18n|BOOTP}} {{Module |NAME=BOOTP |MENUCONFIG={{Protocol}}->BOOTP |STATUS={{In_Development}} |PINNING=no |ECMD=no |DEPENDS= |REQUIRES= |CODE=[https://github.com/ethersex/ethersex/tree/master/protocols/bootp https://github.com/ethersex/ethersex/tree/master/protocols/bootp] }} == Warum BOOTP? == Jeder kennt das Problem, wenn man eine Firmware erstellt hat, muss sie irgendwie in die Hardware kommen. Der gängige Weg, man flasht die Hardware mit einem Programmieradapter über SPI oder [http://de.wikipedia.org/wiki/Joint_Test_Action_Group JTAG] ([http://www.atmel.com/dyn/resources/prod_documents/doc2475.pdf ATMEL]). In der Firmware muss die [http://de.wikipedia.org/wiki/MAC-Adresse MAC]- Adresse und die [http://de.wikipedia.org/wiki/IP-Adresse IP-Adresse] für die Hardware (µC) einkompiliert sein. Sie ist damit erstmals fix und kann nur nachträglich über das ECMD-Kommandos ip geändert werden. Schön wäre es, wenn man sich um die IP-Adresse nicht kümmern müsste und sie selbständig zum Bootzeitpunkt geladen wird. Und noch schöner wäre es, wenn der µC sich auch gleich die aktuelle Firmware selbst laden und flashen würde. Genau dies macht jetzt BOOTP.<br /> === BOOTP Startsequenz === [http://de.wikipedia.org/wiki/Bootstrap_Protocol BOOTP] ist der Vorläufer von [http://de.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol DHCP] mit dem einem Netzwerkgerät wie z.B. unserem µC eine IP-Adresse zugeordnet werden kann. Falls das Netzwerkgerät nicht über einen eigenen Festspeicher verfügt, kann auch die Firmware oder das Betriebssystem auf Anfrage des Netzwerkgerätes übertragen werden. Damit BOOTP funktioniert, muss ein Minimalprogramm mit dem BOOTP-Client auf dem Netzwerkgerät als Bootloader gespeicher sein. Bei einem PC liegt dieses Programm in der Netzwerkkarte. Auf unserem µC muss der Ethernet Bootloader geflasht sein. Dieser enthält eine eindeutige MAC-Adresse für das Netzwerkgerät, damit es adressiert werden kann.<br /> Zum Bootzeitpunkt verfügt der µC nur über die MAC-Adresse. Er stellt also als erstes eine Broadcast-Anfrage an alle Netzwerkteilnehmer mit der Bitte ihm eine IP-Adresse zu geben. Gibt es im Netzwerk einen anderen Rechner, der einen BOOTP- oder DHCP-Server enthält, so antwortet dieser Server und gibt ihm, sofern erlaubt, eine IP-Adresse, die Netmask und das Gateway. Ab nun an kann der µC unter dieser Adresse erreicht werden. Als nächstes fragt der µC den BOOTP-Server nach einer aktuellen Firmware. Dieser teilt ihm den Server und den Port mit, von dem die Firmware per [http://de.wikipedia.org/wiki/Trivial_File_Transfer_Protocol TFTP] geladen werden kann. Mit dieser Art des bootens, kann sehr elegant der µC geflasht und gleichzeitig eine IP-Adresse zugeordnet werden. Das eigentliche flashen der Firmware macht der µC damit selbständig. Mit dem Ethernet Bootloader und BOOTP ist es möglich, beliebige Firmware zu laden ohne ein Programmieradapter zu benutzen. Es muss lediglich die aktuelle Firmware auf dem BOOTP-Server hinterlegt sein und einmal der µC neu gestartet werden und schon flasht er sich selbständig ohne weiteres zutun nur über das Netzwerk. Diese Art des "flashens" geht schneller als mit einem Programmieradapter. In gut 10s ist die Firmware (ca. 50kB) geladen, geflasht und gestartet.<br /> === Voraussetzungen === Damit BOOTP benutzt werden kann müssen bestimmte Voraussetzungen erfüllt sein: * Nur mit einem ATMEGA644 oder größer läßt sich der 8KB Ethernet Bootloader flashen * Der Bootloader mit BOOTP belegt die letzten 8KB ab Adresse xE000 des Programmspeichers, die nicht mehr genutzt werden können * Die Programmgröße (Firmware) ist auf 56 KB beschränkt * Die Securebits sollten gesetzt sein, damit der Bootloader sich nicht selbst überschreiben kann * Es muss ein BOOTP- und TFTP- Server wie z.B. HahneDHCP o.ä. im Netzwerk erreichbar sein * Die Firmware muss als ethersex.bin auf dem TFTP-Server hinterlegt sein * In der Firmware muss die selbe MAC-Adresse verwendet werden wie im Bootloader von BOOTP == Konfiguration in menuconfig == Als Basis kann in nenuconfig die Option "Bootloader BOOTP" gewählt werden. Es ist zu beachten, dass '''keine spezifischen Einstellungen''' außer CPU-Typ und MCU frequency für die jeweilige Hardware im Bootloader durchgeführt werden. Die hardwarespezifischen Einstellungen werden in der Firmware vorgenommen. Folgende Optionen sollten in '''menuconfig''' aktiviert sein: │ │ Load a Default Configuration ---> │ │ (*) Ethernet Bootloader │ │ General Setup ---> │ │ (ATmega644) Target MCU │ │ (20000000) MCU frequency // 16000000 für AVR-NET-IO │ │ [*] Build a bootloader │ │ [*] Teensy build │ │ Network ---> │ │ Hostname: "ethersex" // Hostname ändern │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "00:11:22:33:44:55" // MAC ändern mit "Randomize MAC address" │ │ Randomize MAC address │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ [*] BOOTP (DHCP-like) support │ │ Applications ---> │ │ [*] TFTP support '''Wichtig!''' Die MAC-Adresse muss gesetzt sein. Die selbe MAC-Adresse muss in der Firmware später auch benutzt werden. Hier ist eine [http://www.phw-magdeburg.de/ethersex/BOOTP.config Konfigurationsdatei] für das Pollin AVR-NET-IO mit Addon (MAC: AC:DE:48:CE:23:C8 ): Damit man nun nicht jedes mal die MAC-Adresse neu einkompilieren muss, kann man sie auch händisch mit einem Texteditor in [http://www.phw-magdeburg.de/ethersex/ethersex.hex ''ethersex.hex''] ändern. <source lang="perl"> :10E000003EC0000066C0000064C0000062C00000A6 :10E0100060C000005EC000005CC000005AC000008C :10E0200058C0000056C0000054C0000052C000009C :10E0300050C0000014C100004CC000004AC00000E5 :10E0400048C0000046C0000044C0000042C00000BC :10E0500040C000003EC000003CC000003AC00000CC :10E0600038C0000036C0000034C0000032C00000DC :10E07000"ACDE48CE23C8"006F63746574000014BE24 :10E0800088E10FB6F89480936000109260000FBE94 :10E0900010926E0010926F001092700011241FBE3B :10E0A000CFEFD0E1DEBFCDBF11E0A0E0B1E0E8EE00 </source> == Flashen des Bootloaders == Nach der Konfiguration mit menuconfig den Bootloader mit ''make clean'' und ''make'' compilieren und mit einem Programmieradapter die Datei ''ethersex.hex'' flashen. Wenn eine alte Vorlage benutzt wird, muss ggf. die MAC-Adresse noch einmal geändert werden. Damit der Bootloader nicht durch die Firmware überschrieben wird, müssen die Lock-Bits folgendermaßen gesetzt sein: Für ATmega644: ''avrdude -p m644 -c ponyser -P /dev/ttyS0 -U lock:w:0x0F:m'' oder in Ponyprog: *(x) BootLock02 *(x) BootLock01 *(x) Lock2 *(x) Lock1 '''Achtung!''' Sollte der Bootloader neu geflasht werden, so müssen die Lock-Bits nach dem flashen immer wieder neu gesetzt werden. Wer keine Lust hat den Ethernet-Bootloader zu kompilieren, kann hier für das AVR-NET-IO mit Addon die Datei [http://www.phw-magdeburg.de/ethersex/ethersex.hex ''ethersex.hex''] verwenden. == BOOTP-Server konfigurieren (Windows) == Als BOOTP-Server verwende ich unter Windows '''hahneWin DHCP Server'''. Als Beispielkonfiguration ist bei mir folgendes eingestellt: * Kein DHCP sondern nur BOOTP aktiviert (zur Problemvermeidung bei bestehendem DHCP-Server) * 192.168.0.0 Netzwerk für BOOTP * 192.168.0.1 Rechner mit hahneWin DHCP Server und TFTP auf Port 69 * statische Adressvergabe über MAC-Adressen fest zugewiesen * 192.168.0.88 AVR-NET-IO mit MAC AC:DE:48:CE:23:C8 * 255.255.255.0 Netmask * 192.168.0.251 Gateway * 192.168.0.251 DNS-Server <div><ul> <li style="display: inline-block;"> [[File:Hahne_DHCP.jpg|thumb|none|320px|hahneWin DHCP Server]] </li> </ul></div> Alle weiteren Einstellungen zum hahneWin DHCP Server können den nachfolgenden Links entnommen werden: Grundsätzlich werden als erstes unter ''Optionen->Einstellungen'' die Grundeinstellungen vorgenommen. <div><ul> <li style="display: inline-block;"> [[File:Einstellungen_Allgemein.JPG|thumb|none|150px|Einstellungen Allgemein]] </li> <li style="display: inline-block;"> [[File:Einstellungen Schnittstellen.JPG|thumb|none|150px|Einstellungen Schnittstellen]] </li> <li style="display: inline-block;"> [[File:Einstellungen_DHCP.JPG|thumb|none|150px|Einstellungen DHCP]] </li> <li style="display: inline-block;"> [[File:Einstellungen_TFTP.JPG|thumb|none|150px|Einstellungen TFTP]] </li> <li style="display: inline-block;"> [[File:Einstellungen_TFTP_Optionen.JPG|thumb|none|150px|Einstellungen TFTP Optionen]] </li> </ul></div> Im zweiten Schritt werden unter ''Optionen->Konfigurationsprofile verwalten'' das betreffende Netzwerk ausgewählt und mit ''Bearbeiten'' angepaßt. Im meinem Beispiel wurde der Profilname durch Ethersex ersetzt. Vorher stand dort If-2_0.1. <div><ul> <li style="display: inline-block;"> [[File:Konfigurationsprofile.JPG|thumb|none|200px|Konfigurationsprofile]] </li> <li style="display: inline-block;"> [[File:Ethersex_Basiskonfiguration.JPG|thumb|none|150px|Basiskonfiguration]] </li> <li style="display: inline-block;"> [[File:Ethersex_DNS.JPG|thumb|none|150px|DNS]] </li> <li style="display: inline-block;"> [[File:Ethersex_Boot.JPG|thumb|none|150px|Boot]] </li> </ul></div> Als letztes wird dann noch ein neuer statischer Eintrag über den Schaltknopf ''Hinzufügen'' für den µC erstellt. <div><ul> <li style="display: inline-block;"> [[File:Statische_Eintraege.JPG|thumb|none|150px|Statische Einträge]] </li> </ul></div> Alle nicht aufgeführten Seiten enthalten die Standardeinstellungen und müssen nicht weiter modifiziert werden. So, nun sollte der BOOTP-Server laufen. Den Server kann man unter ''Datei->Server starten/beenden'' in den jeweiligen Zustand setzen. === Hahne BOOTP-Server verwenden === Wird jetzt der µC gebootet, so bezieht er seine Netzwerkeinstellungen vom BOOTP-Server, läd danach die Firmware und startet diese. Im Logfile des BOOTP-Server können die Aktivitäten verfolgt werden. Sobald dem µC eine IP-Adresse vergeben wurde erscheint ein grünes Häkchen vor der MAC-Adresse in der Hauptansicht. Folgende Bedingungen müssen beachtet werden: * hat der µC noch keine Firmware geladen, so wird diese per TFTP im BOOTP-Prozess geladen und geflasht * ist schon eine Firmware im µC geflasht, so werden nur die Netzwerkparameter nach einem Reboot oder Power on/off geladen und die vorhandene Firmware gestartet * um die Firmware erleut zu laden, muss mit dem [[ECMD]] Kommando ''wdreset'' oder ''bootloader'' der µC "resettet" werden == BOOTP-Server konfigurieren (Linux) == Als BOOTP-Server verwende ich unter Linux '''dhcpd3'''. Als Beispielkonfiguration ist bei mir folgendes eingestellt: * Kein DHCP sondern nur BOOTP aktiviert (zur Problemvermeidung bei bestehendem DHCP-Server) * 192.168.30.0 Netzwerk für BOOTP * 192.168.30.134 Rechner mit DHCPD3 Server und TFTP auf Port 69 * statische Adressvergabe über MAC-Adressen fest zugewiesen * 192.168.30.10 AVR-NET-IO mit MAC AC:DE:48:CE:23:C8 * 255.255.255.0 Netmask * 192.168.30.1 Gateway * 192.168.30.1 DNS-Server Die folgende Konfiguration verfügt nicht über eine dynamische IP-Range. Dies bedeutet, dass diese Konfiguration nicht mit einem bereits vorhanden DHCP Server ins Gehege kommt. Dem ethersex wird zum Starten eine feste IP zugewiesen. Der Ablauf: #DHCP Server und TFTP Server müssen gestartet sein #Dann das AVR Net-IO in die Steckdose #Ethersex fragt mit seiner Netzwerkadresse ac:de:48:ce:23:c8 per bootp nach einer IP-Adresse #Der DHCP Server schaut in seiner Liste nach ac:de:48:ce:23:c8, findet diese und die IP 192.168.30.10 zusammen mit der TFTP Server IP 192.168.30.134 und dem Dateinamen ethersex.bin zurück an Ethersex #Ethersex kann nun eine IP Verbindung zum TFTP Server 192.168.30.134 aufbauen und lädt die Datei ethersex.bin #Anschlißend startet Ethersex mit der ethersex.bin ===DHCP-Server konfigurieren === sudo apt-get install dhcp3-server Anschließend muss die Konfigurationsdatei /etc/dhcp3/dhcpd.conf, wie folgt bearbeitet werden. Die IP Adressen musst Du an Deine Gegebenheiten anpassen. <pre> default-lease-time 86400; max-lease-time 2592000; authoritative; subnet 192.168.30.0 netmask 255.255.255.0 { option subnet-mask 255.255.255.0; # subnet maske option routers 192.168.30.1; # Gateway option domain-name-servers 192.168.30.1; # DNS Server ddns-update-style none; # Neue Clients werden dem DNS Server nicht mitgeteilt next-server 192.168.30.134; # TFTP Server host netio { hardware ethernet ac:de:48:ce:23:c8; # mac adresse des pollin net io fixed-address 192.168.30.10; # Eine freie IP-Adresse im lokalen Netz filename "ethersex.bin"; # bootfile (Achtung das ethersex.bin file nehmen!) } } </pre> Anschließend kann der DHCP Server gestartet/neu gestartet werden: sudo /etc/init.d/dhcp3-server restart ===TFTP Server konfigurieren=== Die Konfiguration des TFTP Servers ist ziemlich einfach. Dieser muss nur installiert und gestartet werden: sudo apt-get install tftpd-hpa Die vom Makefile generierte ethersex.bin Datei muss dann nur noch nach /var/lib/tftpboot kopiert werden. Den TFTP Server startetn/neu starten sudo /etc/init.d/tftpd-hpa restart == Bekannte Probleme == Ist im µC bereits eine Firmware geflasht, so sollten durch den BOOTP-Mechanismus die Netzwerkparameter wie IP, Gateway, DNS und Gateway bezogen werden. Laut Logfile vom haneWin DHCP Server erfolgt dies auch. Danach sollte dann die Firmware mit genau diesen Netzwerkparametern gestartet werden. Dies geschiet aber nicht, da vermutlich die Netzwerkparameter nicht an die Firmware weitergereicht werden. Es werden die alten Netzwerkparameter geladen trotz der Einstellung in ''menuconfig'', dass BOOTP verwendet werden soll. Man erkennt mit dem Kommando ''arp -a'' in der Windows-Konsole, dass nach dem Booten die neuen Netzwerkparameter mit der IP vom BOOTP-Server vergeben wurden. Im zweiten Schritt, wenn der µC die Firmware läd, jedoch die alte letzte IP-Adresse benutzt. Daher muss man mit ''arp -d'' die ARP-Tabelle löschen und sich unter der alten IP in den µC mit telnet (siehe [[ECMD_Protocols_(Deutsch)]]) einloggen und mit den Befehlen ''ip, netmask, gw, dns server'' manuell auf die neuen Werte setzen. Alternativ kann man den µC zwingen die neue Firmware zu laden, die dann aber intern die gleichen Netzwerkparameter wie der BOOTP-Server haben muss. Schade eigentlich, so hätte man sehr elegant mit dem BOOTP-Server die Netzwerkparameter zur Bootzeit vergeben können. Ich habe gerade noch einmal in den Quellen nachgesehen, dort werden die Netzwerkparameter von BOOTP nur im EEPROM des µC gespeichert, wenn ''Write BOOTP data to EEPROM'' in ''menuconfig'' ausgewählt ist. Damit lassen sich die Netzwerkparameter zwischenspeichern und stehen nach dem Start der Firmware als Default zur Verfügung. Per Default wird diese Option nicht geladen. Das Problem sollte sich damit beheben lassen. Das habe ich aber bisher noch nicht getestet. Wenn dem so ist, sollte die Default-Konfiguration des ''Ethernet Bootloader'' entsprechend angepasst werden. Ist die zu ladende Firmware größer als 56kB, so wird die Firmware nicht richtig geflasht, da ab xE000 der Ethernet-Bootloader den Bereich mit gesetzten Secure-Bits blockiert. == Nützliche Links == * [http://www.atmel.com/dyn/resources/prod_documents/doc2475.pdf ATMEL JTAG-Interface-Beschreibung] * [http://www.atmel.com/dyn/resources/prod_documents/doc2593.pdf Datenblatt zum ATMEGA644] ce456b7c59c3190c2a2db4c40b93c845eb6b1865 0 364 1661 1066 2016-01-30T19:44:02Z Kpwg 721 wikitext text/x-wiki {{i18n|Control6}} {{Module |NAME=Control6 |MENUCONFIG=General Setup->Control6 script |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=- |REQUIRES=- |TIMER=- |CODE=[https://github.com/ethersex/ethersex/tree/master/control6 https://github.com/ethersex/ethersex/tree/master/control6] }} '''Control6''' ist eine auf [http://de.wikipedia.org/wiki/Protothread Protothreads] fußende Art von Skriptsprache, die ein wenig von ''Basic'' inspiriert ist. Control6 soll insbesondere dazu dienen, dass man die einzelnen Komponenten von Ethersex schnell zusammenfügen kann. Beispielsweise können in einer Endlosschleife die Temperaturen von KTY-Sensoren ausgelesen werden und in Abhängigkeit der Werte dann Pins geschaltet, [[SYSLOG_(Deutsch)|SYSLOG]]-Nachrichten abgesetzt oder [[ECMD_(Deutsch)|ECMD]]-Befehle versendet werden. Die Skripte werden während des Kompiliervorgangs in C-Code übersetzt und letztlich mit in die Firmware einkompiliert. Sie sind somit ''statisch'' und nur durch Neuprogrammierung änderbar. == So fängt man an == Standardmäßig werden, wenn in Menuconfig die Funktion ''Control6'' aktiviert wurde, die Instruktionen aus der Datei '''control6/control6.src''' in die Firmware eingebunden. Für Eigenentwicklungen, die nicht in die "Distribution" aufgenommen werden sollen, empfiehlt es sich separate Dateien in der Ethersex Ordnerstruktur anzulegen, sodass es zu keinen (oder zumindest seltener) zu Konflikten beim Update auf eine neuere offizielle Firmwareversion kommt. Dazu einfach eine beliebige Datei im Stile der o.g. ''control6.src'' anlegen, zum Beispiel eine ''control6/erste-schritte.src'' und diese dem Makesystem bekannt machen. Letzteres durch folgenden Eintrag in der Datei [[config.mk_(Deutsch)|config.mk]] im Hauptverzeichnis (wenn diese noch nicht existiert, einfach eine neue Datei anlegen und nur diese Zeile eintragen): C6_SOURCE = $(TOPDIR)/control6/erste-schritte.src * [[:Kategorie:Control6 Examples|Control6 Beispielcode]] * [[PIN_Commands|Wie schreibe ich ein Control6 Skript]] == Konzepte == * Ein Control6-Skript wird immer von den Tags '''CONTROL_START''' und '''CONTROL_END''' umschlossen. * Mit '''THREAD''' resp. '''THREAD_END''' können leicht quasi nebenläufige Programmabschnitte erstellt werden. Dies ermöglicht mehrere Aufgaben, die miteinander nichts zu tun haben, auch getrennt voneinander im Control6-Code abzubilden. == Befehlssatz == Control6 ist momentan schon relativ mächtig und stellt durchaus eine Alternative zum Verfassen von C-Code dar. Es werden aber nachwievor nicht alle Aspekte von Ethersex auch in Control6 abgebildet und noch weniger werden hier im Wiki bislang thematisiert. * übergreifende Funktionen ** [[Global_Variables_(Deutsch)|Globale Variablen]] ** [[PIN_Commands_(Deutsch)|Pin-Befehle]], Threading, Timer und Events ** [[Conditions_(Deutsch)|Bedingungen]] * Einzelaspekte, siehe ** [[ADC_(Deutsch) | ADC-Werte abfragen]] ** [[Zugriff auf die Systemuhr]] ** [[Debug-Meldungen und SYSLOG]] ** [[ECMD-Befehle absetzen]] ** [[Jabber_(Deutsch) | Jabber]] ** [[eMail versenden]] ** [[Dallas 1-wire Bus]] ** [[KTY81]] ** [[Einfaches Menüsystem|TTY und Menü-System]] ** [[IRMP_(Deutsch)|IR-Empfänger abfragen]] ** [[TCP-Client als FRITZ!Box Call Monitor]] [[Kategorie:Ethersex]] [[Kategorie:Control6]] c433b0da9086c3177b74bb5b81d126d0a12e0fbd 1677 1661 2016-01-30T20:01:29Z Kpwg 721 wikitext text/x-wiki {{i18n|Control6}} {{Module |NAME=Control6 |MENUCONFIG=General Setup->Control6 script |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=- |REQUIRES=- |TIMER=- |CODE=[https://github.com/ethersex/ethersex/tree/master/control6 https://github.com/ethersex/ethersex/tree/master/control6] }} '''Control6''' ist eine auf [http://de.wikipedia.org/wiki/Protothread Protothreads] fußende Art von Skriptsprache, die ein wenig von ''Basic'' inspiriert ist. Control6 soll insbesondere dazu dienen, dass man die einzelnen Komponenten von Ethersex schnell zusammenfügen kann. Beispielsweise können in einer Endlosschleife die Temperaturen von KTY-Sensoren ausgelesen werden und in Abhängigkeit der Werte dann Pins geschaltet, [[SYSLOG_(Deutsch)|SYSLOG]]-Nachrichten abgesetzt oder [[ECMD_(Deutsch)|ECMD]]-Befehle versendet werden. Die Skripte werden während des Kompiliervorgangs in C-Code übersetzt und letztlich mit in die Firmware einkompiliert. Sie sind somit ''statisch'' und nur durch Neuprogrammierung änderbar. == So fängt man an == Standardmäßig werden, wenn in Menuconfig die Funktion ''Control6'' aktiviert wurde, die Instruktionen aus der Datei '''control6/control6.src''' in die Firmware eingebunden. Für Eigenentwicklungen, die nicht in die "Distribution" aufgenommen werden sollen, empfiehlt es sich separate Dateien in der Ethersex Ordnerstruktur anzulegen, sodass es zu keinen (oder zumindest seltener) zu Konflikten beim Update auf eine neuere offizielle Firmwareversion kommt. Dazu einfach eine beliebige Datei im Stile der o.g. ''control6.src'' anlegen, zum Beispiel eine ''control6/erste-schritte.src'' und diese dem Makesystem bekannt machen. Letzteres durch folgenden Eintrag in der Datei [[config.mk_(Deutsch)|config.mk]] im Hauptverzeichnis (wenn diese noch nicht existiert, einfach eine neue Datei anlegen und nur diese Zeile eintragen): C6_SOURCE = $(TOPDIR)/control6/erste-schritte.src * [[:Kategorie:Control6 Examples|Control6 Beispielcode]] * [[PIN_Commands|Wie schreibe ich ein Control6 Skript]] == Konzepte == * Ein Control6-Skript wird immer von den Tags '''CONTROL_START''' und '''CONTROL_END''' umschlossen. * Mit '''THREAD''' resp. '''THREAD_END''' können leicht quasi nebenläufige Programmabschnitte erstellt werden. Dies ermöglicht mehrere Aufgaben, die miteinander nichts zu tun haben, auch getrennt voneinander im Control6-Code abzubilden. == Befehlssatz == Control6 ist momentan schon relativ mächtig und stellt durchaus eine Alternative zum Verfassen von C-Code dar. Es werden aber nachwievor nicht alle Aspekte von Ethersex auch in Control6 abgebildet und noch weniger werden hier im Wiki bislang thematisiert. * übergreifende Funktionen ** [[Global_Variables_(Deutsch)|Globale Variablen]] ** [[PIN_Commands_(Deutsch)|Pin-Befehle]], Threading, Timer und Events ** [[Conditions_(Deutsch)|Bedingungen]] * Einzelaspekte, siehe ** [[ADC_(Deutsch) | ADC-Werte abfragen]] ** [[Zugriff auf die Systemuhr]] ** [[Debug-Meldungen und SYSLOG]] ** [[ECMD-Befehle absetzen]] ** [[Jabber_(Deutsch) | Jabber]] ** [[eMail versenden]] ** [[Onewire_(Deutsch) | Dallas 1-wire Bus]] ** [[KTY81]] ** [[Einfaches Menüsystem|TTY und Menü-System]] ** [[IRMP_(Deutsch)|IR-Empfänger abfragen]] ** [[TCP-Client als FRITZ!Box Call Monitor]] [[Kategorie:Ethersex]] [[Kategorie:Control6]] 941e00572135b52dde059344d9b3d0a5cedcb836 1680 1677 2016-01-30T20:07:15Z Kpwg 721 wikitext text/x-wiki {{i18n|Control6}} {{Module |NAME=Control6 |MENUCONFIG=General Setup->Control6 script |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=- |REQUIRES=- |TIMER=- |CODE=[https://github.com/ethersex/ethersex/tree/master/control6 https://github.com/ethersex/ethersex/tree/master/control6] }} '''Control6''' ist eine auf [http://de.wikipedia.org/wiki/Protothread Protothreads] fußende Art von Skriptsprache, die ein wenig von ''Basic'' inspiriert ist. Control6 soll insbesondere dazu dienen, dass man die einzelnen Komponenten von Ethersex schnell zusammenfügen kann. Beispielsweise können in einer Endlosschleife die Temperaturen von KTY-Sensoren ausgelesen werden und in Abhängigkeit der Werte dann Pins geschaltet, [[SYSLOG_(Deutsch)|SYSLOG]]-Nachrichten abgesetzt oder [[ECMD_(Deutsch)|ECMD]]-Befehle versendet werden. Die Skripte werden während des Kompiliervorgangs in C-Code übersetzt und letztlich mit in die Firmware einkompiliert. Sie sind somit ''statisch'' und nur durch Neuprogrammierung änderbar. == So fängt man an == Standardmäßig werden, wenn in Menuconfig die Funktion ''Control6'' aktiviert wurde, die Instruktionen aus der Datei '''control6/control6.src''' in die Firmware eingebunden. Für Eigenentwicklungen, die nicht in die "Distribution" aufgenommen werden sollen, empfiehlt es sich separate Dateien in der Ethersex Ordnerstruktur anzulegen, sodass es zu keinen (oder zumindest seltener) zu Konflikten beim Update auf eine neuere offizielle Firmwareversion kommt. Dazu einfach eine beliebige Datei im Stile der o.g. ''control6.src'' anlegen, zum Beispiel eine ''control6/erste-schritte.src'' und diese dem Makesystem bekannt machen. Letzteres durch folgenden Eintrag in der Datei [[config.mk_(Deutsch)|config.mk]] im Hauptverzeichnis (wenn diese noch nicht existiert, einfach eine neue Datei anlegen und nur diese Zeile eintragen): C6_SOURCE = $(TOPDIR)/control6/erste-schritte.src * [[:Kategorie:Control6_Examples_(Deutsch) | Control6 Beispielcode]] * [[PIN_Commands_(Deutsch) | Wie schreibe ich ein Control6 Skript]] == Konzepte == * Ein Control6-Skript wird immer von den Tags '''CONTROL_START''' und '''CONTROL_END''' umschlossen. * Mit '''THREAD''' resp. '''THREAD_END''' können leicht quasi nebenläufige Programmabschnitte erstellt werden. Dies ermöglicht mehrere Aufgaben, die miteinander nichts zu tun haben, auch getrennt voneinander im Control6-Code abzubilden. == Befehlssatz == Control6 ist momentan schon relativ mächtig und stellt durchaus eine Alternative zum Verfassen von C-Code dar. Es werden aber nachwievor nicht alle Aspekte von Ethersex auch in Control6 abgebildet und noch weniger werden hier im Wiki bislang thematisiert. * übergreifende Funktionen ** [[Global_Variables_(Deutsch)|Globale Variablen]] ** [[PIN_Commands_(Deutsch)|Pin-Befehle]], Threading, Timer und Events ** [[Conditions_(Deutsch)|Bedingungen]] * Einzelaspekte, siehe ** [[ADC_(Deutsch) | ADC-Werte abfragen]] ** [[Zugriff auf die Systemuhr]] ** [[Debug-Meldungen und SYSLOG]] ** [[ECMD-Befehle absetzen]] ** [[Jabber_(Deutsch) | Jabber]] ** [[eMail versenden]] ** [[Onewire_(Deutsch) | Dallas 1-wire Bus]] ** [[KTY81]] ** [[Einfaches Menüsystem|TTY und Menü-System]] ** [[IRMP_(Deutsch)|IR-Empfänger abfragen]] ** [[TCP-Client als FRITZ!Box Call Monitor]] 2248b950c552283ed614c30a2625a501c59ea56e 1682 1680 2016-01-30T20:10:48Z Kpwg 721 wikitext text/x-wiki {{i18n|Control6}} {{Module |NAME=Control6 |MENUCONFIG=General Setup->Control6 script |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=- |REQUIRES=- |TIMER=- |CODE=[https://github.com/ethersex/ethersex/tree/master/control6 https://github.com/ethersex/ethersex/tree/master/control6] }} '''Control6''' ist eine auf [http://de.wikipedia.org/wiki/Protothread Protothreads] fußende Art von Skriptsprache, die ein wenig von ''Basic'' inspiriert ist. Control6 soll insbesondere dazu dienen, dass man die einzelnen Komponenten von Ethersex schnell zusammenfügen kann. Beispielsweise können in einer Endlosschleife die Temperaturen von KTY-Sensoren ausgelesen werden und in Abhängigkeit der Werte dann Pins geschaltet, [[SYSLOG_(Deutsch)|SYSLOG]]-Nachrichten abgesetzt oder [[ECMD_(Deutsch)|ECMD]]-Befehle versendet werden. Die Skripte werden während des Kompiliervorgangs in C-Code übersetzt und letztlich mit in die Firmware einkompiliert. Sie sind somit ''statisch'' und nur durch Neuprogrammierung änderbar. == So fängt man an == Standardmäßig werden, wenn in Menuconfig die Funktion ''Control6'' aktiviert wurde, die Instruktionen aus der Datei '''control6/control6.src''' in die Firmware eingebunden. Für Eigenentwicklungen, die nicht in die "Distribution" aufgenommen werden sollen, empfiehlt es sich separate Dateien in der Ethersex Ordnerstruktur anzulegen, sodass es zu keinen (oder zumindest seltener) zu Konflikten beim Update auf eine neuere offizielle Firmwareversion kommt. Dazu einfach eine beliebige Datei im Stile der o.g. ''control6.src'' anlegen, zum Beispiel eine ''control6/erste-schritte.src'' und diese dem Makesystem bekannt machen. Letzteres durch folgenden Eintrag in der Datei [[config.mk_(Deutsch)|config.mk]] im Hauptverzeichnis (wenn diese noch nicht existiert, einfach eine neue Datei anlegen und nur diese Zeile eintragen): C6_SOURCE = $(TOPDIR)/control6/erste-schritte.src * [[:Kategorie:Control6_Examples | Control6 Beispielcode]] * [[PIN_Commands_(Deutsch) | Wie schreibe ich ein Control6 Skript]] == Konzepte == * Ein Control6-Skript wird immer von den Tags '''CONTROL_START''' und '''CONTROL_END''' umschlossen. * Mit '''THREAD''' resp. '''THREAD_END''' können leicht quasi nebenläufige Programmabschnitte erstellt werden. Dies ermöglicht mehrere Aufgaben, die miteinander nichts zu tun haben, auch getrennt voneinander im Control6-Code abzubilden. == Befehlssatz == Control6 ist momentan schon relativ mächtig und stellt durchaus eine Alternative zum Verfassen von C-Code dar. Es werden aber nachwievor nicht alle Aspekte von Ethersex auch in Control6 abgebildet und noch weniger werden hier im Wiki bislang thematisiert. * übergreifende Funktionen ** [[Global_Variables_(Deutsch)|Globale Variablen]] ** [[PIN_Commands_(Deutsch)|Pin-Befehle]], Threading, Timer und Events ** [[Conditions_(Deutsch)|Bedingungen]] * Einzelaspekte, siehe ** [[ADC_(Deutsch) | ADC-Werte abfragen]] ** [[Zugriff auf die Systemuhr]] ** [[Debug-Meldungen und SYSLOG]] ** [[ECMD-Befehle absetzen]] ** [[Jabber_(Deutsch) | Jabber]] ** [[eMail versenden]] ** [[Onewire_(Deutsch) | Dallas 1-wire Bus]] ** [[KTY81]] ** [[Einfaches Menüsystem|TTY und Menü-System]] ** [[IRMP_(Deutsch)|IR-Empfänger abfragen]] ** [[TCP-Client als FRITZ!Box Call Monitor]] 1af36acb12a38700066459dfe55e6b7f9d667f5b 6 543 1664 2016-01-30T19:50:49Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 544 1665 2016-01-30T19:51:26Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 545 1666 2016-01-30T19:51:55Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 546 1667 2016-01-30T19:52:16Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 547 1668 2016-01-30T19:52:32Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 548 1669 2016-01-30T19:54:39Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 549 1670 2016-01-30T19:55:10Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 550 1671 2016-01-30T19:55:39Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 551 1672 2016-01-30T19:56:16Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 222 1673 591 2016-01-30T19:56:48Z Kpwg 721 wikitext text/x-wiki {{i18n|Config.mk}} Die Datei '''config.mk''' im Hauptverzeichnis der Ethersex-Ordnerstruktur ist quasi der Schlüssel zur Entwicklung eigener Ethersex-Komponenten, '''die nicht in Ethersex aufgenommen werden sollen''', weil sie schlicht zu speziell sind. Als Grundregel sollte in etwa gelten: Wenn du etwas an Ethersex ergänzen möchtest, das nicht groß veröffentlicht werden soll, solltest du zusehen, dass du die bestehenden Dateien, die in Ethersex enthalten sind, nicht modifizierst. Die Datei ''config.mk'' sowie Mechanismen wie die Meta-Bereiche ermöglichen dies weitestgehend. Dieses Vorgehen hat für dich den Vorteil, dass es beim Aktualisieren auf eine neue Ethersex-Version nicht zu Konflikten zwischen deinen und unseren Modifikationen kommen kann. Wenn du ab und an Patches erstellen möchtest, machst du dir das Leben so ebenfalls einfacher, da du nicht mehr aufpassen musst, versehentlich etwas zu committen, das eigentlich gar nicht eingecheckt werden sollte. Also: Alles, was du am liebsten in die Datei ''Makefile'' im Hauptverzeichnis eintragen möchtest, trägst du einfach in die Datei ''config.mk'' ein. Wenn es diese noch nicht gibt, leg' sie einfach an. == Weitere Ergänzungsdateien == === protocols/ecmd/ecmd_defs.m4 === Statt die ''ecmd_defs.m4'' zu bearbeiten, kannst du auch irgendwo eine neue Datei anlegen und die gleiche Syntax wie in ''ecmd_defs.m4'' verwenden. Dass das Make-System die Datei berücksichtigt, musst du sie noch registrieren. Dazu dient wieder die ''config.mk'': ECMD_DEFS_EXTRA += mycruft/private_ecmds.m4 ... und schon werden auch die Einträge in der Datei mycruft/private_ecmds.m4 entsprechend berücksichtigt. === named_pin Konfiguration === Zunächst kopierst du dir am besten die Datei ''core/portio/config'' irgendwo hin und verwendest sie als Vorlage. Um diese zu registrieren, verwenden wir die folgende Zeile in ''config.mk'': NP_CONFIG = mycruft/named_pin.conf === [[Control6_(Deutsch) | Control6]] Skript === Ein eigenes [[Control6_(Deutsch) | Control6]] Skript in einer von control6/control6.src abweichenden Datei kann du mit folgendem Statement registrieren: C6_SOURCE = mycruft/wecky.src or C6_SOURCE = $(TOPDIR)/control6/you_programm.src == mögliche weitere Einträge == === avrdude mit 'make dude644' aufrufen === dude644: ethersex.hex avrdude -p m644 -c usbasp -V -Uflash:w:$< === AVR mit 'make reset' via ISP resetten === reset: avrdude -p m644 -c usbasp [[Category:development]] 5e085774d413a56fc629b00f0202f8a7127361a2 6 552 1674 2016-01-30T19:58:14Z Djmaster 255 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 3 495 1679 1652 2016-01-30T20:07:04Z Djmaster 255 /* 2 */ wikitext text/x-wiki =Todo Liste= ==1== *[[Temperaturmesssystem_(Deutsch)]] ** <s>webabfrage</s> ** <s>wdreset</s> ** <s>make clean && make</s> ** <s>Paar Bilder und tftpd win32</s> ** ds1820 id herausbekommen und 4k7 pullup anfügen ** <s>[ ] jump bootloader????</s> Anm.: Voraussetzung für das ECMD "bootloader" sind die Optionen "General Setup -> Prompt all possible options" (CONFIG_EXPERT) und "General Setup -> Enable bootloader jump" (BOOTLOADER_JUMP) im menuconfig. Per Telnet sich mit dem ethersex verbinden (telnet <IP-Ethersex> 2701). Dort "bootloader" oder "wdreset" eingeben. ==2== *[[BOOTP_%28Deutsch%29]] ** <s>Links prüfen</s> ** <s>Bilder prüfen</s> ** <s>Text anpassen</s> ==3== *[[I2C_%28Deutsch%29]] **Levelshifter **Aufteilung ==4== *ETHERNET LOADER??? old wiki cbd9e5648ab36de4cf66de06d737bc083371cdbc 1681 1679 2016-01-30T20:08:20Z Djmaster 255 /* 1 */ wikitext text/x-wiki =Todo Liste= ==1== *[[Temperaturmesssystem_(Deutsch)]] ** <s>webabfrage</s> ** <s>wdreset</s> ** <s>make clean && make</s> ** <s>Paar Bilder und tftpd win32</s> ** <s>ds1820 id herausbekommen</s> ** schaltung ds1820 4k7 ==2== *[[BOOTP_%28Deutsch%29]] ** <s>Links prüfen</s> ** <s>Bilder prüfen</s> ** <s>Text anpassen</s> ==3== *[[I2C_%28Deutsch%29]] **Levelshifter **Aufteilung ==4== *ETHERNET LOADER??? old wiki 4780e92c912ce31748f9428aad8201fe6d1842e4 0 553 1684 2016-01-30T20:15:48Z Djmaster 255 Created page with "{{i18n|Ethernet_Loader}} = Bootloader einrichten (TFTP)= Da ich mindesten 6h mit Fehlersuche verschwendet habe, hier eine Anleitung wie man den TFTP-Bootloader verwendet.<br ..." wikitext text/x-wiki {{i18n|Ethernet_Loader}} = Bootloader einrichten (TFTP)= Da ich mindesten 6h mit Fehlersuche verschwendet habe, hier eine Anleitung wie man den TFTP-Bootloader verwendet.<br /> Ganz wichtig, es darf per tftp NIE das ''ethersex.hex'' File geladen werden. = Vorteile des Bootloaders = * Durch den Einsatz eines Bootloaders benötigt man (vom Flashen des Bootloaders einmal abgesehen) keine Flash-Hardware mehr. * Der ISP-Port blockiert den Ethernet-Port (zumindesten bei der AVR NET-IO bzw. beim Einsatz bestimmter Programmieradapter) * Update und Entwicklungen können bequem vom Schreibtisch aus vorgenommen werden == Benötigt werden: == * Bootloader im ethersex.hex Format ** [http://www.ethersex.de/firmware-builder/list.cgi Firmware Builder] *** enc_mac = die MAC-Adresse vom Hardwareboard *** enc_ip = IP-Adresse vom Board *** enc_ip4_netmask = passende Maske vom Netz *** etherrape_gateway = default GW *** tftp_ip = die IP-Adresse vom tftpd Server, also des PCs auf dem der tftpd läuft *** tftp_image = Name des binaries, das im tftpboot-Verzeichnis liegt. z.B. esex.bin *oder ** config-File für die '''AVR Net-IO''' *** Load a Default Configuration ---> **** (x) Ethernet Bootloader *** als Start und dann an die Gegebenheiten anpassen. Im Bootloader werden nur UDP und TFTP zum Nachladen der Firmware benötigt. *** Network ---> **** (x) UDP support **** (x) UDP broadcast support **** (x) Ethernet(ENC28J60)support -> Etherrape IP-Adresse: "IP-ADRESSE eintragen" (Dieser Eintrag erscheint nur wenn bootp nicht aktiv ist) *** Applications -> **** (x) TFTP support **** Bootloader configuration ->TFTP-o-matic (Dieser Eintrag erscheint nur wenn Network --> bootp nicht aktiv ist) ***** TFTP IP address: "IP-ADRESSE DES TFTP-SERVERS" ***** TFTP image to load: "esex.bin" (Name des BIN-files) (evtl. ist hier der absolute Pfad nötig /tftpboot/esex.bin) * eigentliche Firmware im ethersex.bin Format ** das make erzeugt immer eine ethersex.hex und eine ethersex.bin und wird z.B. als esex.bin auf den tftpd-Server kopiert * [http://de.wikipedia.org/wiki/Trivial_File_Transfer_Protocol tfpd-Server] ** Linux: [http://www.debianadmin.com/atftp-server-and-client-installation-and-configuration.html atftpd], tftpd oder tftpd-hpt ** Windows: [http://tftpd32.jounin.net/ tftp32.exe] *** BESCHREIBUNG FÜR WINDOWS wenn '''nicht''' DHCP verwendet wird *** der Windows Rechner muss die IP haben die vorher in Ethersex als Server eingestellt worden ist *** esex.bin einfach in das Verzeichnis vom TFTP-Server (Windows) kopieren *** Programm starten und freuen -- sobald der Ethersex startet holt er sich automatisch neue Firmware esex.bin (Name der eingestellt ist) *** anschließend könnt ihr die Datei aus dem Verzeichnis löschen oder Programm schließen ansonsten wird der nach jedem starten vom ESEX wieder neu gelasht == Wichtig! == * Der Bootloader funktioniert ''nicht'' ohne weiteres mit dem Atmega32, da dort der Bootloaderbereich zu klein ist. Es wird ein Atmega644 oder ein 1284p benötigt. * der ethersex Bootloader funktioniert als TFTP-Client * auf der Linux bzw. Windows Maschine muss ein TFTPD (TFTP-Server) laufen. * das ethersex sucht auf dem TFTP-Server seine Firmware lädt sie selbständig in seinen Flash. == Installation == * auf dem klassischem Weg wird die ethersex.bin erstellt (make menuconfig; make) * Der tftpd wird wie von der Distribution vorgesehen gestartet. Das ethersex.bin kommt in das /tftpboot Verzeichniss == Anpassung der FUSE-Bits == Damit das Ganze funktioniert, müssen die FUSE-Bits angepasst werden. Mit dem Tool [http://www.engbedded.com/fusecalc/ FUSE-Calc] kann man sich durch anklicken seine FUSE-Bits zusammenstellen. Für den atmega644(p) hier ein Beispiel. <source lang="text"> avrdude -p m644p -c ponyser -P /dev/ttyS0 -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m </source> == Flashen des Bootloaders == Der Bootloader wird als .hex auf klasischem Weg geflasht. <source lang="text"> avrdude -p m644p -c ponyser -P /dev/ttyS0 -U flash:w:<bootloader.hex> -v </source> (Statt <bootloader.hex> ist natürlich der korrekte Name des Hex-Files anzugeben; selbstverständlich ohne "<>". Wichtig: unbedingt das <bootloader.hex> flashen, mit dem Flashen des <bootloader.bin> funktioniert der Bootloader nicht, weil dieser in den falschen Bereich im Flash geschrieben wird) Spätestens nach einem Reboot der Hardware versucht der Bootloader per [http://de.wikipedia.org/wiki/Trivial_File_Transfer_Protocol tftp] die eigentliche Firmware zu laden und zu starten. Eine einmal auf diesem Weg installierte Firmware ist immer auf dem Board und der Bootloader holt nur auf händische Anfrage ein neues esex.bin vom tftp-Server == LOCKBITS Bootloaderschutz == Wenn der Bootloader instaliert ist sollten noch die Lockbits gesetzt werden. Bitte nur die [http://www.ethersex.de/index.php/Bild:AvrNet-644-boot.jpg Fuses mit Boot Loader Protections Mode3] setzen. Dadurch wird verhindert das der Bootloader überschrieben wird, wenn das Image in den Bereich vom Bootloader kommt. Dies Passiert wenn das Image für den ATMEGA 644 größer als 90% ist. (bei mir 90,3% da BL 9,7%) Durch die Lockbits bekommt man dann am TFTP Server die Meldung ERR, '''aber der Bootloader funktioniert weiterhin'''. Wenn mit SPI der Bootloaader neu geflasht wird, werden die Lockbits vom Bootloader Mode3 wieder auf Mode1 gesetzt. D.h. immer beim neuflash über SPI, den Boot Loader Protections Mode3 setzen. '''ALS FAUSTFORMEL: BIN-File nicht größer als ''90%'' -- ca. ''10%'' braucht der Bootloader''' Für ATmega644P: avrdude -p m644p -c ponyser -P /dev/ttyS0 -U lock:w:0x0F:m == Händisches laden eines neuen Images ([[Ecmd_Reference]])== Anm.: Voraussetzung für das ECMD "bootloader" sind die Optionen "General Setup -> Prompt all possible options" (CONFIG_EXPERT) und "General Setup -> Enable bootloader jump" (BOOTLOADER_JUMP) im menuconfig. Per Telnet sich mit dem ethersex verbinden (telnet <IP-Ethersex> 2701). Dort "bootloader" oder "wdreset" eingeben. Oder per Web-Browser: http://<IP-Ethersex>/ecmd?bootloader. Wenns nicht auf Anhieb klappt: (a) Fehlerbild: Ethersex holt sich zwar vom TFTP-Server ein neues Binärfile und schreibt es in seinen Speicher - aber dann geht nichts mehr übers Netzwerk (kein Ping, kein Telnet, etc). (b) Ursachen: b1) In Bootloader-Image und im Binärfile werden unterschiedliche MAC-Adressen verwendet. oder: b2) "make" hat keine wesentliche Änderung an .config festgestellt und daher das identische Binary nochmals erzeugt; Image wird zwar neu geladen und auch geflasht - Controller zeigt aber das identische Verhalten (c) Abhilfe: für b1) ARP-Cache löschen oder warten für b2) "make clean && make" == mögliche Probleme == Bei Einsatz des Add-On Boards kann es vorkommen, dass der SD-Kartenleser nicht mehr einwandfrei initialisiert wird. Die LED neben dem SD-Kartenslot leuchtet ständig und es erscheint die Meldung im Debug-Mode: „sd_reader: fat_create_file: invalid parameters.“ Dann muss die SD-Karte einmal entfernt und wieder eingesetzt werden. Die LED leuchtet dann auch nicht mehr dauerhaft. [[Category:Ethersex]] [[Category:Protocol]] [[Category:Application]] 27b33b41e3a468cff637406a101455ea46f777fc 0 554 1685 2016-02-01T06:44:18Z Kpwg 721 Created page with "{{i18n|ZBus Serial Host}} [[File:Zbus_ttl.jpg|thumb|right|TTL-ZBus-Adapter mit MAX485, Terminierung und Bias-R's]] Da der [[ZBus_(Deutsch) | ZBus]] auf dem USART Feature basi..." wikitext text/x-wiki {{i18n|ZBus Serial Host}} [[File:Zbus_ttl.jpg|thumb|right|TTL-ZBus-Adapter mit MAX485, Terminierung und Bias-R's]] Da der [[ZBus_(Deutsch) | ZBus]] auf dem USART Feature basiert, welches alle ATmegas haben, können wir einfach eine ZBus Netzwerkschnittstelle an unserem Computer anschließen. Die serielle Schnittstelle (auch bekannt als COM-Port oder RS232) ist nur eine normale USART mit Pegelwandler (-3V - +15V). Um eine RS485-Schnittstelle daraus zu machen, welche für den ZBus benötigt wird, nimmt man einen MAX232 (oder funktional ähnlich), um das RS232-Signal wieder in ein USART TTL-Signal zu wandeln. Ein RS485-Interface-Chip (z.B. ein MAX485, siehe Bild) konvertiert daraus das Differenzsignal. Einige Embedded-Gerät haben USARTs an Bord, die keinen Signalwandler besitzen- sie bieten das USART TTL-Signal direkt an. Man muss dann nur noch den RS485-Chip verbinden und den Treiber für die Architektur kompilieren. Der populäre Linksys WRT54G (WLAN-Router mit OpenWRT) ist so ein Embedded-Gerät mit einer TTL-USART an Bord. Auf der Software-Seite habe ich beschlossen, einen userland driver mit tun device anstatt eines Kernel-Moduls zu schreiben, weil es viel einfacher zu codieren und zu debuggen ist. Das Programm stellt eine übliche Netzwerkschnittstelle wie die Ethernet-Karte bereit und kann auch wie Diese verwendet werden (zum Beispiel Routing, verschiedene IP-Adressen und so weiter). Das ist sehr flexibel. Man kann den Treiber-Daemon bei [https://github.com/ethersex/ethersex/tree/master/contrib/zbus-serial-host contrib/zbus-serial-host] finden. <pre> zbus0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:192.168.9.1 P-t-P:192.168.9.1 Mask:255.255.255.0 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:174 Metric:1 RX packets:16418 errors:0 dropped:0 overruns:0 frame:0 TX packets:16423 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:1381934 (1.3 MiB) TX bytes:1379532 (1.3 MiB) </pre> [[Category:ZBus]] 690d2aecf66351dc3a96fe58f751faafad3dec00 0 279 1686 864 2016-02-01T06:47:16Z Kpwg 721 wikitext text/x-wiki {{i18n|Flashing}} = AVR Net-IO mit dem ATMEL Evaluations-Board von Pollin flashen= Als Einsteiger hat man es immer wieder schwer alle Information zu finden. Ich habe lange gesucht bis ich das mit dem Flashen kapiert habe. == Benötigt wird: == * AVR Net-IO * ATMEL Evaluations-Board * ein 1:1 Kabel für den [[ISP]]-Port (10-poliger Pfostenstecker). === Andere ISP-Programmer === Wer über einen ISP-Programmer mit 6-poligem Ausgang verfügt, kann sich ein Adapterkabel bauen. Zu den Pinbelegungen siehe Figure 4-1 auf Seite 5 von [http://www.atmel.com/dyn/resources/prod_documents/doc2521.pdf AVR042: AVR Hardware Design Considerations]. Achtung, Pin 4 des 10-poligen Steckers ist auf dem AVR Net-IO nicht belegt! GND muss daher an einen der anderen Pins (6, 8 oder 10) angeschlossen werden. == Flashen unter Linux == Das 10-polige Kabel in die ISP-Buchse stecken. Nun das AVR Net-IO Board mit Strom versorgen. Wenn das ISP-Kabel richtig gesteckt ist, leuchtet auf dem Evalutions-Board die (gelbe) LED Nach dem Erzeugen der [[:Kategorie:StepByStep#Firmware_kompilieren|ethersex.hex]] kann man mit avrdude das Ganze flashen. Das nachfolgende Kommando ist bei einigen Parametern vom ISP-Programmer abhängig. Das nachfolgende Beispiel gilt für einen ISP-Programmer der über die serielle Schnittstelle arbeitet: avrdude -v -p m32 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex Für eine USB-ISP-Programmer wäre statt dessen der folgende Befehl zu verwenden: avrdude -v -p m32 -c stk500v2 -P /dev/ttyACM0 -U flash:w:ethersex.hex Für ein paralleles ISP-Kabel: avrdude -p m32 -e -c stk200 -U flash:w:ethersex.hex Nach dem Flashen das ISP-Kabel entfernen und kurz die Stromversorgung unterbrechen um das Board zu rebooten. * -p m32 steht für den ATMega32; -p m644 wäre der ATMega644 * -v erweiterte Ausgaben * -c ponyser ist das Verfahren wie das Evalutions-Board die Daten flasht * -P ist die Serielle Schnittstelle an dem das Evalutions-Board angeschlossen ist (bei USB /dev/ttyUSB0) * -U was man machen möchte. In unserem Fall wollen wir das File ethersex.hex flashen (-U flash:w:ethersex.hex) Es kann sein das man für den ATMega32 die FUSE Bits setzen muss. avrdude -p m32 -c ponyser -P /dev/ttyS0 -U lfuse:w:0xCF:m -U hfuse:w:0xDC:m Um die korrekte Fuse-Einstellung rauszufinden, ist es sinnvoll http://www.engbedded.com/fusecalc/ zu benutzen. Die Parameter für MyAVR mySmartusb light (Insbesondere das -e war nötig): avrdude -p m32 -e -c stk500v2 -P /dev/ttyUSB0 -U flash:w:ethersex.hex == Umbau von einem ATMega32 auf den ATMega644 / ATMega644p == Der Vorteil von ATMega644 und ATMega644p ist vor allem der doppelt so große Speicher gegenüber dem serienmäßigen ATMega32. === Mikrocontroller tauschen === * Stromversorgung abschalten und ISP-Stecker abziehen. * Den ATMega32 aus seinem Sockel auf dem AVR Net-IO ziehen. * Den ATMega644 oder ATMega644p einbauen. (ACHTUNG: Kerbe im Sockel muss mit Kerbe in der CPU übereinstimmen) === Fuse-Bits setzen === * ISP wieder einstecken und Stromversorgung einschalten. * Fuse-Bits setzen * '''Wichtig:''' im Auslieferungszustand ist der ATMega644 programmiert auf 8MHz interner RC-Oszillator '''und''' der Takt wird durch 8 geteilt; also 1MHz Takt. Wenn ein externer Quarz verwendet wir, muss das Bit CKDIV8 (Takt geteilt durch 8) auf null gesetzt werden. * (Übernommen von dinus) Der ATMega wird dabei mit 1Mhz getaktet, kein JTAG. avrdude -p m644 -c ponyser -P /dev/ttyS0 -U lfuse:w:0xE7:m -U hfuse:w:0xDC:m -U efuse:w:0xFF:m * bzw. avrdude -p m644p -c ponyser -P /dev/ttyS0 -U lfuse:w:0xE7:m -U hfuse:w:0xDC:m -U efuse:w:0xFF:m Fuse-Bits wie sie "DiDi" einsetzt. Der JTAG ist eingeschaltet. * -U lfuse:w:0xf7:m -U hfuse:w:0x99:m -U efuse:w:0xfc:m Fuse-Bits wie "loddel" sie einsetzt. Der JTAG ist ausgeschaltet. * -U lfuse:w:0xf7:m -U hfuse:w:0xd9:m -U efuse:w:0xff:m * -U lfuse:w:0xe7:m -U hfuse:w:0xd9:m -U efuse:w:0xff:m Fuse-Bits wie "gregor" sie einsetzt. "Damit läuft der 644 auf 16MHz Quarz und der Takt wird nicht durch 8 geteilt." Der JTAG ist eingeschaltet. * -U lfuse:w:0xef:m -U hfuse:w:0x99:m -U efuse:w:0xff:m === Ethersex reinflashen=== * in der Config von Ethersex (make menuconfig) von ATmega32 auf ATMega644 umstellen * Flashen mit avrdude -p m644 -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex -v * bzw. avrdude -p m644p -c ponyser -P /dev/ttyS0 -U flash:w:ethersex.hex -v === Unterschiede zwischen ATMega32, ATMega644, ATMega644p und ATMega1284p=== {| border=1 cellspacing=0 padding=4 class=wikitable " ! !! ATMega32 !! ATMega644 !! ATMega644p !! ATMega1284p |- | Gehäuse || DIL-40 || DIL-40 || DIL-40 || DIL-40 |- | MHz || max. 16 || max. 20 || max. 20 || max. 20 |- | Flash || 32 KB || 64 KB || 64 KB || 128 KB |- | EEProm || 1 KB || 2 KB || 2 KB || 4 KB |- | RAM || 2 KB || 4 KB || 4 KB || 16 KB |- | I/O || 32 || 32 || 32 || 32 |- | PWM || 4 || 6 || 6 || 6 |- | ext. INT || 3 || 32 || 32 || 32 |- | Ser-Port || 1 || 1 || 2 || 2 |} ====Datenblätter==== * [http://www.atmel.com/Images/doc2503.pdf AtMega32] * [http://www.atmel.com/Images/doc2593.pdf ATMega644] * [http://www.atmel.com/images/doc8011.pdf ATMega644p] * [http://www.atmel.com/dyn/resources/prod_documents/8059S.pdf ATMega1284p] == Flashen unter Windows == Es gibt mindestens zwei Möglichkeiten: #Flashen mit avrdude #Flashen mit AVR Studio Wer keines der beiden Programme auf seine Festplatte legen möchte, weil er sein Windows-System nicht ändern möchte, kann auch die [[Live CD]] verwenden. ===Flashen mit avrdude=== Das Flashen mit avrdude erfolgt prinzipiell genauso wie unter Linux (siehe oben). Ein Windows-Binary von avrdude erhält man am einfachsten als Bestandteil von [http://sourceforge.net/projects/winavr/ WinAVR]. (Ansonsten findet man ein Windows-Binary von avrdude auch auf [http://yuki-lab.jp/hw/avrdude-GUI/index.html dieser japanischen Seite], wo man auch eine GUI für avrdude bekommen kann. Google-Translate hilft den japanischen Text zu verstehen.) In der Kommandozeile muss natürlich die Bezeichnung des seriellen Ports angepasst werden, also "COMx" anstelle von "/dev/ttyS0", z.B. avrdude -v -p m32 -c ponyser -P com3 -U flash:w:ethersex.hex Sofern der Programmer per USB angeschlossen ist, benötigt man * bei echten USB-Programmern die libusb0.dll (bei WinAVR enthalten), * bei Verwendung eines USB-nach-seriell-Adapters mit FTDI-Chip (dieser kann auch manchmal bereits in den Programmer mit USB-Anschluss eingebaut sein!) einen passenden Treiber, siehe http://www.ftdichip.com/Drivers/VCP.htm. ===Flashen mit AVR Studio=== Das [[AVR Studio]] von Atmel bietet eine grafische Oberfläche zur Bedienung von ISPs. Beim AVR Studio werden USB-Treiber für USB-Programmer mitgeliefert, die optional zusammen mit dem AVR Studio installiert werden können. Für USB-nach-seriell-Adapter mit FTDI-Chip benötigt man einen passenden Treiber, siehe http://www.ftdichip.com/Drivers/VCP.htm. === Links zu Erfahrungsberichten === *http://www.saschakimmel.de/2010/02/ethersex-auf-avr-net-io-installieren-mittels-pollin-atmel-evaluationsboard-2-0-und-windows/ , jedoch nicht mit ISP-Kabel sondern mit Umstecken des Controllers. == Live-CD == Diese hat den Vorteil, dass man sein vorhandenes System nicht ändern muss. * http://www.ethersex.de/index.php?title=Live_CD * apt-get install libncurses5-dev * update und installier software fuer ethersex wie beschrieben http://www.ethersex.de/index.php/Download * wenn help in menuconfig nicht geht: apt-get install dialog * weiter wie in "Flashen unter Linux" beschrieben. [[Category:StepByStep]] 42138b2161312fe4e3eb47b04476560a6ac0b933 0 58 1687 1146 2016-02-01T07:08:33Z Kpwg 721 wikitext text/x-wiki {{i18n|Quick Start Guide}} Mit drei Schritten läuft Ethersex auf Ihrem Microcontroller! [[Quick_Start_Guide/Preparation_(Deutsch) | Step 1: Vorbereitung]] [[Quick_Start_Guide/Configuration_(Deutsch) | Step 2: Konfiguration]] [[Quick_Start_Guide/Flashing_(Deutsch) | Step 3: Flashen]] [[Category:Ethersex]] [[Category:Quick Start Guide]] [[Category:Tutorials]] 24e890700bce9c13d21bba2d0be0234ab18159e9 0 315 1688 840 2016-02-05T18:09:11Z Djmaster 255 /* Nach einer Stunde funktioniert die GET ausgabe nicht */ wikitext text/x-wiki {{i18n|Onewire/DS2450}} {{Module |NAME=Onewire DS2450 |MENUCONFIG={{I/O}}->Onewire support |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} *Beitrag am 23.09.2012 erneuert. == Dallas 1-wire DS2450 4 Kanal ADC == Der DS2450 ist ein 4 Kanal ADC mit einer maximalen Auflösung von 16 Bit (vgl. [http://datasheets.maxim-ic.com/en/ds/DS2450.pdf Datenblatt]). Die analog-digital Umwandlung erfolgt durch einen internen four-to-one multiplexer. Kanäle, die nicht als Eingänge genutzt werden, können als Ausgänge (open drain) geschaltet werden (max. 4mA und 6V). === ECMD Interface === Über ECMD sind folgende Befehle für den DS2450 bekannt: *<code>1w ds2450 power</code> *<code>1w ds2450 res</code> *<code>1w ds2450 oc</code> *<code>1w ds2450 oe</code> *<code>1w ds2450 range</code> *<code>1w ds2450 por</code> *<code>1w ds2450 convert</code> *<code>1w ds2450 get</code> ==== Grundsätzliches ==== Grundsätzlich gilt für alle Befehle: * als erstes Argument kann optional die 64 Bit ROM Id des DS2450 angegeben werden, der angesprochen werden soll (match rom). Wird die ROM Id <b>nicht</b> angeben, so werden alle im Bus befindlichen 1-wire Devices (egal welchen Typs) angesprochen (skip rom). Dies macht <b>nur</b> Sinn, wenn sich <b>genau</b> ein Device im 1-wire Bus befindet (skip rom führt bei mehreren Devices unweigerlich dazu, dass mehrere Devices gleichzeitig antworten werden, was zu Bit-Salat beim bus master (d.h. Ethersex) führt, das Datenblatt spricht von "a wired-AND result"). * wird ein Kanal angeben, so ist dieser mit einem Buchstaben (entsprechend Datenblatt) zu bezeichnen (case-insensitiv). * wird mit einem Befehl ein Wert gesetzt, so kann mit dem gleichen Befehl der Wert gelesen werden, in dem man kein Werte-Argument angibt. ==== <code>1w ds2450 power</code> ==== Hierüber wird die Art der Spannungsversorgung des DS2450 gesetzt (global). Dieser Parameter wird durch den Anschluss an der 1-wire Bus bestimmt, vgl. die [[Onewire_(Deutsch)#Anschluss_AVR-NET-IO | Erklärung der Anschlussmöglichkeiten]]. Wird der 1-wire Bus "normal" (drei-adrig) betrieben, so muss der Wert auf 1 gesetzt werden. Wird der Bus "parasitär" (zwei-adrig) betrieben, muss der Wert auf 0 gesetzt werden. Default-Wert: 0 Beispiel: 1w ds2450 power 1 (der DS250 wird auf "normale" Spannungsversorgung konfiguriert) ==== <code>1w ds2450 res</code> ==== Hierüber wird die Auflösung der analog-digital Umwandlung gesetzt (pro Kanal). Die Auflösung kann zw. 1 und 16 Bit eingestellt werden. Die Eingabe erfolgt als 8 Bit Hexadezimalwert, wobei eine Auflösung von 16 Bit durch den Wert 0x00 oder alternativ 0x10 erreicht wird. Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0x08 Beispiel: 1w ds2450 res c 08 (setzt die Auflösung für Kanal C auf 0x08, d.h. 8 Bit) ==== <code>1w ds2450 oc</code> ==== Hierüber kann der Ausgang ein- oder ausgeschaltet werden (pro Kanal). Voraussetzung ist, dass über [[DS2450#1w_ds2450_oe | 1w ds2450 oe]] der Kanal als Ausgang geschaltet wurde (ansonsten wird das OC-Bit ignoriert). Die Eingabe erfolgt als bool über 0 (Ausgangstransistor leitend) bzw. 1 (Ausgangstransistor nicht-leitend). Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0 Beispiel: 1w ds2450 oc a 1 (der Ausgangstransistor des Kanal A wird leitend) ==== <code>1w ds2450 oe</code> ==== Hierüber kann der Kanal als Ein- oder Ausgang gesetzt werden (pro Kanal). Eine analog-digital Umwandlung ist <b>nur</b> möglich, wenn das OE-Bit auf 0 gesetzt ist. In diesem Fall wird das OC-Bit ignoriert. Ist das OE-Bit auf 1 gesetzt, kann der Ausgang über 1w ds2450 oc ein- bzw. ausgeschaltet werden. Die Eingabe erfolgt als bool über 0 (Eingang für ADC) bzw. 1 (Ausgang open drain). Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0 Beispiel: 1w ds2450 oe d 1 (Kanal A wird als Ausgang gesetzt) ==== <code>1w ds2450 range</code> ==== Hierüber kann der Spannungs-Bereich angegeben werden, in dem die analog-digital Umwandlung stattfinden soll. Die Eingabe erfolgt als bool über 0 (Spannungsbereich 0 bis 2,55V) bzw. 1 (Spannungsbereich 0 bis 5,10V). Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0 Beispiel: 1w ds2450 range b 1 (für Kanal B wird bei der analog-digital Umwandlung der Spannungsbereich 0 bis 5,10V genutzt) ==== <code>1w ds2450 por</code> ==== Hierüber kann das power on reset Bit gelesen bzw. gesetzt werden. Nach einem power-on reset cycle setzt der DS2450 das Bit auf 1. Das Bit beeinflusst die conditional search, welche in Ethersex (noch) nicht implementiert ist. Setzt der bus master das Bit auf 0, so nimmt der DS2450 nicht mehr an der conditional search teil Die Eingabe erfolgt als bool über 0 bzw. 1. Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 1 (nach power-on reset cycle) Beispiel: 1w ds2450 por c 0 (für Kanal C wird das power on reset Bit auf 0 gesetzt) FixMe: Es sieht so aus, als kann das Bit nur global gesetzt werden, d.h. wird es für einen Kanal verändert, haben danach alle anderen Kanäle den gleich POR-Bit Wert. Außerdem kann man das Bit nicht mehr auf 1 setzen, wenn es vorher schon auf 0 gesetzt wurde (das widerspricht aber dem Datenblatt!). ==== <code>1w ds2450 convert</code> ==== Hierüber wird die analog-digital Umwandlung ausgelöst (analog den 1-wire Temperatursensoren). Werden keine weiteren Argumente angegeben, so wird die Umwandlung für alle 4 Kanäle des DS2450 durchgeführt (FixMe: vermutlich werden die Kanäle, bei denen das OE-Bit auf 1 steht ausgelassen, dass ist aber nicht durch Dallas dokumentiert). Optional können zwei Argumente angegeben werden (werden Argumente angegeben, <b>müssen beide</b> Argumente angegeben werden!): * input select mask * read-out control ===== input select mask ===== Mit der input select mask kann angegeben werden, für welche Kanäle die analog-digital Umwandlung durchgeführt werden soll. Die input select mask ist ein 8 Bit Hexadezimalwert: {| border=1 cellspacing=0 padding=4 class=wikitable ! bit7 !! bit6 !! bit5 !! bit4 !! bit3 !! bit2 !! bit1 !! bit0 |- | ignore || ignore || ignore || ignore || Kanal D || Kanal C || Kanal B || Kanal A |} Eine input select mask von 0x0f bedeutet also, dass für alle 4 Kanäle die analog-digital Umwandlung durchgeführt werden soll. Eine mask von 0x00 ist (offensichtlich) sinnlos. Eine ungültige input select mask (d.h. input select mask == 0x00 oder > 0x0f) wird erkannt und führt zu einer ECMD-Fehlermeldung. Die analog-digital Umwandlung erfolgt in der Reihenfolge von Kanal A zu Kanal D, wobei die nicht gewünschte Kanäle (sprich jene, wo das input select mask Bit auf 0 steht) übersprungen werden. Der DS2450 braucht für jedes Bit Auflösung ca. 60 bis 80µs. Außerdem braucht das Umwandlung-Kommando generell 160µs (offset) Dies bedeutet, dass eine Umwandlung aller 4 Kanäle bei maximaler 16 Bit Auflösung also nicht länger als 4*16*80+160µs = 5280µs = 5,28ms dauern wird. ===== read out control ===== Mit dem read out control kann angegeben werden, ob und wie das Register für die Ergebnisse der analog-digital Umwandlung vorbelegt werden soll. Das macht nur dann Sinn, wenn die Umwandlungsergebnisse schon gelesen werden sollen, während der DS2450 im Hintergrund noch die analog-digital Umwandlung durchführt (was möglich ist). Das read out control ist ein 8 Bit Hexadezimalwert: {| border=1 cellspacing=0 padding=4 class=wikitable ! bit7 !! bit6 !! bit5 !! bit4 !! bit3 !! bit2 !! bit1 !! bit0 |- | Set D || Clear D || Set C || Clear C || Set B || Clear B || Set A || Clear A |} Set bzw. Clear verhalten sich wie folgt: {| border=1 cellspacing=0 padding=4 class=wikitable ! Set !! Clear !! Ergebnis |- | 0 || 0 || keine Veränderung am Umwandlung-Register |- | 0 || 1 || alle Bits des Umwandlung-Register werden auf 0 gesetzt |- | 1 || 0 || alle Bits des Umwandlung-Register werden auf 1 gesetzt |- | 1 || 1 || invalid |} Ungültige Kombinationen im read out control (d.h. Set = 1 und Clear = 1) werden erkannt und führen zu einer ECMD-Fehlermeldung. Default-Werte: * input select mask: 0x04 * read out control: 0x00 Beispiel: 1w ds2450 convert (für alle Kanäle wird die analog-digital Umwandlung durchgeführt) ==== <code>1w ds2450 get</code> ==== Hierüber wird das Ergebnis der analog-digital Umwandlung ausgelesen (analog den 1-wire Temperatursensoren). Werden keine weiteren Argumente angegeben, so werden die Umwandlungsergebnisse für alle 4 Kanäle des DS2450 ausgegeben. Optional kann ein Kanal angegeben werden, dann wird nur das Umwandlungsergebniss dieses Kanals ausgegeben. Wurde seit dem letzten power-on reset cycle keine Umwandlung durchgeführt, stehen alle Bits der Register auf 0. Die Ausgabe erfolgt als raw (unsigned integer 16 Bit - <code>uint16_t</code>). Die eingelesene Spannung errechnet sich wie folgt (VAL ist die Ausgabe von <code>1w ds2450 get</code>): * für range = 0 (0..2,55V) VAL ------- * 2,55V 2**16-1 * für range = 1 (0..5,10V) VAL ------- * 5,10V 2**16-1 Default-Werte: - Beispiel: 1w ds2450 get (die Umwandlungsergebnisse für alle 4 Kanäle werden ausgegeben) === Beispielschaltung 1=== Hier ein Beispielschaltung für den DS2450. Kanal A wird als Eingabe genutzt (range = 1). Kanal D wird als Ausgabe genutzt, über den Optokoppler kann die LED geschaltet werden. Der Widerstand R1 muss <b>unbedingt</b> entsprechend dem Optokoppler dimensioniert werden. Beim 4N35 sind 1k3 ausreichend, dann fließt ein Strom von ca. 2,8mA. [[File:DS2450 Beispiel 01.gif|600px|Beispielschaltung DS2450]] === Beispielschaltung 2=== Hier die Beispielschaltung 2 für den DS2450. Kanal A/B/C/D wird als Eingang genutzt (Range = 1). * I/O-A wird zb. als Tür oder Fenster Detektor genutzt. * I/O-B wird als Eingang für den Luftfeuchtesensor genutzt. * I/O-C wird als Eingang für den Luftdrucksensor genutzt. * I/O-D wird genutzt um die Versorgungsspannung zu messen welche bei der Berechnung des Luftdrucksensor benötigt wird. <br> Weiters hängt ein DS2450 und ein DS1820 parallel am Bus um noch eine Temperatur über den Bus zu bekommen. * [http://www.ethersex.de/images/5/5c/1W_MPX6115_HIH4000.pdf Schaltung als PDF downloaden] [[File:1W MPX6115 HIH4000.png|600px|Beispielschaltung DS2450]] * Zum Initialisieren verwende ich folgende Kommandos via ecmd zb.: <pre><nowiki> 1w ds2450 power 1 //(drei adrig) 1w ds2450 res c 08 //(00 / 10 = 16bit, 08 8bit) 1w ds2450 oe c 0 //(als eingang stetzen) 1w ds2450 range c 1 //(Range 0-5,10V) 1w ds2450 convert 1w ds2450 get </nowiki></pre> == Probleme == === Berechnungen des Feuchtesensor === // lt. Datenblatt: // OFFSET 0.958062V bei 0%RH // SLOPE: 30.680 mV/%RH $V_Feuchte = ($Humid/65535)*5.17; $RH_Feuchte = ($V_Feuchte - 0.958062) * 34.558; //Werte nach Kalibrierung ( 34.558 Ist bei mir genauer als 30.680) $RHR = $RH_Feuchte / ((1.0305 + (0.000044 * 25) - (0.0000011 * pow(22.6,2)))); echo $RHR; === Berechnungen des Drucksensor === $ADCwert = ($Druck/65535)*5.10; $ADCVBuswert= ($Vdd/65535)*5.10; $kpawert = $ADCwert/($ADCVBuswert*0.009)+10.55; echo $kpawert*10; === Werte des ADC schwanken beim auslesen === Lege doch mal die Versorgungsspannung direkt auf einen Eingang und schaue mal ob der Wert immer noch schwankt. === parse error 05.02.2016 === debug abschalten avr-gcc 472ok 435nok == Einbindung in Control6 (tcp_send) == https://github.com/ethersex/ethersex/blob/master/hardware/onewire/ds2450.h<br> http://www.tutorials.at/c/03-dateneingabe-ausgabe.html<br> <br> '''"ecmd?1w list"''' ergibt den rom code '''20686414000000b5''' für den ds2450<br> <br> <pre><nowiki> C6_HEADER(`/* This will be in control6.h */') #include "hardware/onewire/ds2450.h" uint16_t counter1 = 0; uint16_t var1 = 0; CONTROL_START CLOCK_USED() THREAD(start) var1 = 1; WAIT(5) var1 = 0; WAIT(5) THREAD_END(start) TCP_HANDLER_PERSIST(message_handler); if (var1 == 1){ ow_rom_code_t rom_code; uint16_t result; rom_code.bytewise[0] = 0x20; rom_code.bytewise[1] = 0x68; rom_code.bytewise[2] = 0x64; rom_code.bytewise[3] = 0x14; rom_code.bytewise[4] = 0x00; rom_code.bytewise[5] = 0x00; rom_code.bytewise[6] = 0x00; rom_code.bytewise[7] = 0xb5; ow_ds2450_convert(&rom_code, 0x0f, 0x00); ow_ds2450_get(&rom_code, 2, 2, &result); TCP_SEND("%u", result); WAIT(15) } TCP_HANDLER_END(); ON STARTUP DO THREAD_START(start) TCP_CONNECT(192.168.123.106, 4445, message_handler); END CONTROL_END </nowiki></pre> 268639483addea4d3bda0b0bf1f71a0979bb6e78 1691 1688 2016-02-05T19:12:08Z Djmaster 255 /* Beispielschaltung 1 */ wikitext text/x-wiki {{i18n|Onewire/DS2450}} {{Module |NAME=Onewire DS2450 |MENUCONFIG={{I/O}}->Onewire support |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} *Beitrag am 23.09.2012 erneuert. == Dallas 1-wire DS2450 4 Kanal ADC == Der DS2450 ist ein 4 Kanal ADC mit einer maximalen Auflösung von 16 Bit (vgl. [http://datasheets.maxim-ic.com/en/ds/DS2450.pdf Datenblatt]). Die analog-digital Umwandlung erfolgt durch einen internen four-to-one multiplexer. Kanäle, die nicht als Eingänge genutzt werden, können als Ausgänge (open drain) geschaltet werden (max. 4mA und 6V). === ECMD Interface === Über ECMD sind folgende Befehle für den DS2450 bekannt: *<code>1w ds2450 power</code> *<code>1w ds2450 res</code> *<code>1w ds2450 oc</code> *<code>1w ds2450 oe</code> *<code>1w ds2450 range</code> *<code>1w ds2450 por</code> *<code>1w ds2450 convert</code> *<code>1w ds2450 get</code> ==== Grundsätzliches ==== Grundsätzlich gilt für alle Befehle: * als erstes Argument kann optional die 64 Bit ROM Id des DS2450 angegeben werden, der angesprochen werden soll (match rom). Wird die ROM Id <b>nicht</b> angeben, so werden alle im Bus befindlichen 1-wire Devices (egal welchen Typs) angesprochen (skip rom). Dies macht <b>nur</b> Sinn, wenn sich <b>genau</b> ein Device im 1-wire Bus befindet (skip rom führt bei mehreren Devices unweigerlich dazu, dass mehrere Devices gleichzeitig antworten werden, was zu Bit-Salat beim bus master (d.h. Ethersex) führt, das Datenblatt spricht von "a wired-AND result"). * wird ein Kanal angeben, so ist dieser mit einem Buchstaben (entsprechend Datenblatt) zu bezeichnen (case-insensitiv). * wird mit einem Befehl ein Wert gesetzt, so kann mit dem gleichen Befehl der Wert gelesen werden, in dem man kein Werte-Argument angibt. ==== <code>1w ds2450 power</code> ==== Hierüber wird die Art der Spannungsversorgung des DS2450 gesetzt (global). Dieser Parameter wird durch den Anschluss an der 1-wire Bus bestimmt, vgl. die [[Onewire_(Deutsch)#Anschluss_AVR-NET-IO | Erklärung der Anschlussmöglichkeiten]]. Wird der 1-wire Bus "normal" (drei-adrig) betrieben, so muss der Wert auf 1 gesetzt werden. Wird der Bus "parasitär" (zwei-adrig) betrieben, muss der Wert auf 0 gesetzt werden. Default-Wert: 0 Beispiel: 1w ds2450 power 1 (der DS250 wird auf "normale" Spannungsversorgung konfiguriert) ==== <code>1w ds2450 res</code> ==== Hierüber wird die Auflösung der analog-digital Umwandlung gesetzt (pro Kanal). Die Auflösung kann zw. 1 und 16 Bit eingestellt werden. Die Eingabe erfolgt als 8 Bit Hexadezimalwert, wobei eine Auflösung von 16 Bit durch den Wert 0x00 oder alternativ 0x10 erreicht wird. Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0x08 Beispiel: 1w ds2450 res c 08 (setzt die Auflösung für Kanal C auf 0x08, d.h. 8 Bit) ==== <code>1w ds2450 oc</code> ==== Hierüber kann der Ausgang ein- oder ausgeschaltet werden (pro Kanal). Voraussetzung ist, dass über [[DS2450#1w_ds2450_oe | 1w ds2450 oe]] der Kanal als Ausgang geschaltet wurde (ansonsten wird das OC-Bit ignoriert). Die Eingabe erfolgt als bool über 0 (Ausgangstransistor leitend) bzw. 1 (Ausgangstransistor nicht-leitend). Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0 Beispiel: 1w ds2450 oc a 1 (der Ausgangstransistor des Kanal A wird leitend) ==== <code>1w ds2450 oe</code> ==== Hierüber kann der Kanal als Ein- oder Ausgang gesetzt werden (pro Kanal). Eine analog-digital Umwandlung ist <b>nur</b> möglich, wenn das OE-Bit auf 0 gesetzt ist. In diesem Fall wird das OC-Bit ignoriert. Ist das OE-Bit auf 1 gesetzt, kann der Ausgang über 1w ds2450 oc ein- bzw. ausgeschaltet werden. Die Eingabe erfolgt als bool über 0 (Eingang für ADC) bzw. 1 (Ausgang open drain). Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0 Beispiel: 1w ds2450 oe d 1 (Kanal A wird als Ausgang gesetzt) ==== <code>1w ds2450 range</code> ==== Hierüber kann der Spannungs-Bereich angegeben werden, in dem die analog-digital Umwandlung stattfinden soll. Die Eingabe erfolgt als bool über 0 (Spannungsbereich 0 bis 2,55V) bzw. 1 (Spannungsbereich 0 bis 5,10V). Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0 Beispiel: 1w ds2450 range b 1 (für Kanal B wird bei der analog-digital Umwandlung der Spannungsbereich 0 bis 5,10V genutzt) ==== <code>1w ds2450 por</code> ==== Hierüber kann das power on reset Bit gelesen bzw. gesetzt werden. Nach einem power-on reset cycle setzt der DS2450 das Bit auf 1. Das Bit beeinflusst die conditional search, welche in Ethersex (noch) nicht implementiert ist. Setzt der bus master das Bit auf 0, so nimmt der DS2450 nicht mehr an der conditional search teil Die Eingabe erfolgt als bool über 0 bzw. 1. Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 1 (nach power-on reset cycle) Beispiel: 1w ds2450 por c 0 (für Kanal C wird das power on reset Bit auf 0 gesetzt) FixMe: Es sieht so aus, als kann das Bit nur global gesetzt werden, d.h. wird es für einen Kanal verändert, haben danach alle anderen Kanäle den gleich POR-Bit Wert. Außerdem kann man das Bit nicht mehr auf 1 setzen, wenn es vorher schon auf 0 gesetzt wurde (das widerspricht aber dem Datenblatt!). ==== <code>1w ds2450 convert</code> ==== Hierüber wird die analog-digital Umwandlung ausgelöst (analog den 1-wire Temperatursensoren). Werden keine weiteren Argumente angegeben, so wird die Umwandlung für alle 4 Kanäle des DS2450 durchgeführt (FixMe: vermutlich werden die Kanäle, bei denen das OE-Bit auf 1 steht ausgelassen, dass ist aber nicht durch Dallas dokumentiert). Optional können zwei Argumente angegeben werden (werden Argumente angegeben, <b>müssen beide</b> Argumente angegeben werden!): * input select mask * read-out control ===== input select mask ===== Mit der input select mask kann angegeben werden, für welche Kanäle die analog-digital Umwandlung durchgeführt werden soll. Die input select mask ist ein 8 Bit Hexadezimalwert: {| border=1 cellspacing=0 padding=4 class=wikitable ! bit7 !! bit6 !! bit5 !! bit4 !! bit3 !! bit2 !! bit1 !! bit0 |- | ignore || ignore || ignore || ignore || Kanal D || Kanal C || Kanal B || Kanal A |} Eine input select mask von 0x0f bedeutet also, dass für alle 4 Kanäle die analog-digital Umwandlung durchgeführt werden soll. Eine mask von 0x00 ist (offensichtlich) sinnlos. Eine ungültige input select mask (d.h. input select mask == 0x00 oder > 0x0f) wird erkannt und führt zu einer ECMD-Fehlermeldung. Die analog-digital Umwandlung erfolgt in der Reihenfolge von Kanal A zu Kanal D, wobei die nicht gewünschte Kanäle (sprich jene, wo das input select mask Bit auf 0 steht) übersprungen werden. Der DS2450 braucht für jedes Bit Auflösung ca. 60 bis 80µs. Außerdem braucht das Umwandlung-Kommando generell 160µs (offset) Dies bedeutet, dass eine Umwandlung aller 4 Kanäle bei maximaler 16 Bit Auflösung also nicht länger als 4*16*80+160µs = 5280µs = 5,28ms dauern wird. ===== read out control ===== Mit dem read out control kann angegeben werden, ob und wie das Register für die Ergebnisse der analog-digital Umwandlung vorbelegt werden soll. Das macht nur dann Sinn, wenn die Umwandlungsergebnisse schon gelesen werden sollen, während der DS2450 im Hintergrund noch die analog-digital Umwandlung durchführt (was möglich ist). Das read out control ist ein 8 Bit Hexadezimalwert: {| border=1 cellspacing=0 padding=4 class=wikitable ! bit7 !! bit6 !! bit5 !! bit4 !! bit3 !! bit2 !! bit1 !! bit0 |- | Set D || Clear D || Set C || Clear C || Set B || Clear B || Set A || Clear A |} Set bzw. Clear verhalten sich wie folgt: {| border=1 cellspacing=0 padding=4 class=wikitable ! Set !! Clear !! Ergebnis |- | 0 || 0 || keine Veränderung am Umwandlung-Register |- | 0 || 1 || alle Bits des Umwandlung-Register werden auf 0 gesetzt |- | 1 || 0 || alle Bits des Umwandlung-Register werden auf 1 gesetzt |- | 1 || 1 || invalid |} Ungültige Kombinationen im read out control (d.h. Set = 1 und Clear = 1) werden erkannt und führen zu einer ECMD-Fehlermeldung. Default-Werte: * input select mask: 0x04 * read out control: 0x00 Beispiel: 1w ds2450 convert (für alle Kanäle wird die analog-digital Umwandlung durchgeführt) ==== <code>1w ds2450 get</code> ==== Hierüber wird das Ergebnis der analog-digital Umwandlung ausgelesen (analog den 1-wire Temperatursensoren). Werden keine weiteren Argumente angegeben, so werden die Umwandlungsergebnisse für alle 4 Kanäle des DS2450 ausgegeben. Optional kann ein Kanal angegeben werden, dann wird nur das Umwandlungsergebniss dieses Kanals ausgegeben. Wurde seit dem letzten power-on reset cycle keine Umwandlung durchgeführt, stehen alle Bits der Register auf 0. Die Ausgabe erfolgt als raw (unsigned integer 16 Bit - <code>uint16_t</code>). Die eingelesene Spannung errechnet sich wie folgt (VAL ist die Ausgabe von <code>1w ds2450 get</code>): * für range = 0 (0..2,55V) VAL ------- * 2,55V 2**16-1 * für range = 1 (0..5,10V) VAL ------- * 5,10V 2**16-1 Default-Werte: - Beispiel: 1w ds2450 get (die Umwandlungsergebnisse für alle 4 Kanäle werden ausgegeben) = Beispielschaltung 1= Hier ein Beispielschaltung für den DS2450. Kanal A wird als Eingabe genutzt (range = 1). Kanal D wird als Ausgabe genutzt, über den Optokoppler kann die LED geschaltet werden. Der Widerstand R1 muss <b>unbedingt</b> entsprechend dem Optokoppler dimensioniert werden. Beim 4N35 sind 1k3 ausreichend, dann fließt ein Strom von ca. 2,8mA. [[File:DS2450 Beispiel 01.gif|600px|Beispielschaltung DS2450]] === Beispielschaltung 2=== Hier die Beispielschaltung 2 für den DS2450. Kanal A/B/C/D wird als Eingang genutzt (Range = 1). * I/O-A wird zb. als Tür oder Fenster Detektor genutzt. * I/O-B wird als Eingang für den Luftfeuchtesensor genutzt. * I/O-C wird als Eingang für den Luftdrucksensor genutzt. * I/O-D wird genutzt um die Versorgungsspannung zu messen welche bei der Berechnung des Luftdrucksensor benötigt wird. <br> Weiters hängt ein DS2450 und ein DS1820 parallel am Bus um noch eine Temperatur über den Bus zu bekommen. * [http://www.ethersex.de/images/5/5c/1W_MPX6115_HIH4000.pdf Schaltung als PDF downloaden] [[File:1W MPX6115 HIH4000.png|600px|Beispielschaltung DS2450]] * Zum Initialisieren verwende ich folgende Kommandos via ecmd zb.: <pre><nowiki> 1w ds2450 power 1 //(drei adrig) 1w ds2450 res c 08 //(00 / 10 = 16bit, 08 8bit) 1w ds2450 oe c 0 //(als eingang stetzen) 1w ds2450 range c 1 //(Range 0-5,10V) 1w ds2450 convert 1w ds2450 get </nowiki></pre> == Probleme == === Berechnungen des Feuchtesensor === // lt. Datenblatt: // OFFSET 0.958062V bei 0%RH // SLOPE: 30.680 mV/%RH $V_Feuchte = ($Humid/65535)*5.17; $RH_Feuchte = ($V_Feuchte - 0.958062) * 34.558; //Werte nach Kalibrierung ( 34.558 Ist bei mir genauer als 30.680) $RHR = $RH_Feuchte / ((1.0305 + (0.000044 * 25) - (0.0000011 * pow(22.6,2)))); echo $RHR; === Berechnungen des Drucksensor === $ADCwert = ($Druck/65535)*5.10; $ADCVBuswert= ($Vdd/65535)*5.10; $kpawert = $ADCwert/($ADCVBuswert*0.009)+10.55; echo $kpawert*10; === Werte des ADC schwanken beim auslesen === Lege doch mal die Versorgungsspannung direkt auf einen Eingang und schaue mal ob der Wert immer noch schwankt. === parse error 05.02.2016 === debug abschalten avr-gcc 472ok 435nok == Einbindung in Control6 (tcp_send) == https://github.com/ethersex/ethersex/blob/master/hardware/onewire/ds2450.h<br> http://www.tutorials.at/c/03-dateneingabe-ausgabe.html<br> <br> '''"ecmd?1w list"''' ergibt den rom code '''20686414000000b5''' für den ds2450<br> <br> <pre><nowiki> C6_HEADER(`/* This will be in control6.h */') #include "hardware/onewire/ds2450.h" uint16_t counter1 = 0; uint16_t var1 = 0; CONTROL_START CLOCK_USED() THREAD(start) var1 = 1; WAIT(5) var1 = 0; WAIT(5) THREAD_END(start) TCP_HANDLER_PERSIST(message_handler); if (var1 == 1){ ow_rom_code_t rom_code; uint16_t result; rom_code.bytewise[0] = 0x20; rom_code.bytewise[1] = 0x68; rom_code.bytewise[2] = 0x64; rom_code.bytewise[3] = 0x14; rom_code.bytewise[4] = 0x00; rom_code.bytewise[5] = 0x00; rom_code.bytewise[6] = 0x00; rom_code.bytewise[7] = 0xb5; ow_ds2450_convert(&rom_code, 0x0f, 0x00); ow_ds2450_get(&rom_code, 2, 2, &result); TCP_SEND("%u", result); WAIT(15) } TCP_HANDLER_END(); ON STARTUP DO THREAD_START(start) TCP_CONNECT(192.168.123.106, 4445, message_handler); END CONTROL_END </nowiki></pre> f49f276dff62bc2fed7dc27301fd3db57386a144 1692 1691 2016-02-05T19:17:17Z Djmaster 255 wikitext text/x-wiki {{i18n|Onewire/DS2450}} {{Module |NAME=Onewire DS2450 |MENUCONFIG={{I/O}}->Onewire support |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} *Beitrag am 05.02.2016 erneuert. = Einleitung = Der DS2450 ist ein 4 Kanal ADC mit einer maximalen Auflösung von 16 Bit (vgl. [http://datasheets.maxim-ic.com/en/ds/DS2450.pdf Datenblatt]). Die analog-digital Umwandlung erfolgt durch einen internen four-to-one multiplexer. Kanäle, die nicht als Eingänge genutzt werden, können als Ausgänge (open drain) geschaltet werden (max. 4mA und 6V). === ECMD Interface === Über ECMD sind folgende Befehle für den DS2450 bekannt: 1w list 1w ds2450 power 1w ds2450 res 1w ds2450 oc 1w ds2450 oe 1w ds2450 range 1w ds2450 por 1w ds2450 convert 1w ds2450 get ==== Grundsätzliches ==== Grundsätzlich gilt für alle Befehle: * als erstes Argument kann optional die 64 Bit ROM Id des DS2450 angegeben werden, der angesprochen werden soll (match rom). Wird die ROM Id <b>nicht</b> angeben, so werden alle im Bus befindlichen 1-wire Devices (egal welchen Typs) angesprochen (skip rom). Dies macht <b>nur</b> Sinn, wenn sich <b>genau</b> ein Device im 1-wire Bus befindet (skip rom führt bei mehreren Devices unweigerlich dazu, dass mehrere Devices gleichzeitig antworten werden, was zu Bit-Salat beim bus master (d.h. Ethersex) führt, das Datenblatt spricht von "a wired-AND result"). * wird ein Kanal angeben, so ist dieser mit einem Buchstaben (entsprechend Datenblatt) zu bezeichnen (case-insensitiv). * wird mit einem Befehl ein Wert gesetzt, so kann mit dem gleichen Befehl der Wert gelesen werden, in dem man kein Werte-Argument angibt. ==== <code>1w ds2450 power</code> ==== Hierüber wird die Art der Spannungsversorgung des DS2450 gesetzt (global). Dieser Parameter wird durch den Anschluss an der 1-wire Bus bestimmt, vgl. die [[Onewire_(Deutsch)#Anschluss_AVR-NET-IO | Erklärung der Anschlussmöglichkeiten]]. Wird der 1-wire Bus "normal" (drei-adrig) betrieben, so muss der Wert auf 1 gesetzt werden. Wird der Bus "parasitär" (zwei-adrig) betrieben, muss der Wert auf 0 gesetzt werden. Default-Wert: 0 Beispiel: 1w ds2450 power 1 (der DS250 wird auf "normale" Spannungsversorgung konfiguriert) ==== <code>1w ds2450 res</code> ==== Hierüber wird die Auflösung der analog-digital Umwandlung gesetzt (pro Kanal). Die Auflösung kann zw. 1 und 16 Bit eingestellt werden. Die Eingabe erfolgt als 8 Bit Hexadezimalwert, wobei eine Auflösung von 16 Bit durch den Wert 0x00 oder alternativ 0x10 erreicht wird. Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0x08 Beispiel: 1w ds2450 res c 08 (setzt die Auflösung für Kanal C auf 0x08, d.h. 8 Bit) ==== <code>1w ds2450 oc</code> ==== Hierüber kann der Ausgang ein- oder ausgeschaltet werden (pro Kanal). Voraussetzung ist, dass über [[DS2450#1w_ds2450_oe | 1w ds2450 oe]] der Kanal als Ausgang geschaltet wurde (ansonsten wird das OC-Bit ignoriert). Die Eingabe erfolgt als bool über 0 (Ausgangstransistor leitend) bzw. 1 (Ausgangstransistor nicht-leitend). Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0 Beispiel: 1w ds2450 oc a 1 (der Ausgangstransistor des Kanal A wird leitend) ==== <code>1w ds2450 oe</code> ==== Hierüber kann der Kanal als Ein- oder Ausgang gesetzt werden (pro Kanal). Eine analog-digital Umwandlung ist <b>nur</b> möglich, wenn das OE-Bit auf 0 gesetzt ist. In diesem Fall wird das OC-Bit ignoriert. Ist das OE-Bit auf 1 gesetzt, kann der Ausgang über 1w ds2450 oc ein- bzw. ausgeschaltet werden. Die Eingabe erfolgt als bool über 0 (Eingang für ADC) bzw. 1 (Ausgang open drain). Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0 Beispiel: 1w ds2450 oe d 1 (Kanal A wird als Ausgang gesetzt) ==== <code>1w ds2450 range</code> ==== Hierüber kann der Spannungs-Bereich angegeben werden, in dem die analog-digital Umwandlung stattfinden soll. Die Eingabe erfolgt als bool über 0 (Spannungsbereich 0 bis 2,55V) bzw. 1 (Spannungsbereich 0 bis 5,10V). Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0 Beispiel: 1w ds2450 range b 1 (für Kanal B wird bei der analog-digital Umwandlung der Spannungsbereich 0 bis 5,10V genutzt) ==== <code>1w ds2450 por</code> ==== Hierüber kann das power on reset Bit gelesen bzw. gesetzt werden. Nach einem power-on reset cycle setzt der DS2450 das Bit auf 1. Das Bit beeinflusst die conditional search, welche in Ethersex (noch) nicht implementiert ist. Setzt der bus master das Bit auf 0, so nimmt der DS2450 nicht mehr an der conditional search teil Die Eingabe erfolgt als bool über 0 bzw. 1. Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 1 (nach power-on reset cycle) Beispiel: 1w ds2450 por c 0 (für Kanal C wird das power on reset Bit auf 0 gesetzt) FixMe: Es sieht so aus, als kann das Bit nur global gesetzt werden, d.h. wird es für einen Kanal verändert, haben danach alle anderen Kanäle den gleich POR-Bit Wert. Außerdem kann man das Bit nicht mehr auf 1 setzen, wenn es vorher schon auf 0 gesetzt wurde (das widerspricht aber dem Datenblatt!). ==== <code>1w ds2450 convert</code> ==== Hierüber wird die analog-digital Umwandlung ausgelöst (analog den 1-wire Temperatursensoren). Werden keine weiteren Argumente angegeben, so wird die Umwandlung für alle 4 Kanäle des DS2450 durchgeführt (FixMe: vermutlich werden die Kanäle, bei denen das OE-Bit auf 1 steht ausgelassen, dass ist aber nicht durch Dallas dokumentiert). Optional können zwei Argumente angegeben werden (werden Argumente angegeben, <b>müssen beide</b> Argumente angegeben werden!): * input select mask * read-out control ===== input select mask ===== Mit der input select mask kann angegeben werden, für welche Kanäle die analog-digital Umwandlung durchgeführt werden soll. Die input select mask ist ein 8 Bit Hexadezimalwert: {| border=1 cellspacing=0 padding=4 class=wikitable ! bit7 !! bit6 !! bit5 !! bit4 !! bit3 !! bit2 !! bit1 !! bit0 |- | ignore || ignore || ignore || ignore || Kanal D || Kanal C || Kanal B || Kanal A |} Eine input select mask von 0x0f bedeutet also, dass für alle 4 Kanäle die analog-digital Umwandlung durchgeführt werden soll. Eine mask von 0x00 ist (offensichtlich) sinnlos. Eine ungültige input select mask (d.h. input select mask == 0x00 oder > 0x0f) wird erkannt und führt zu einer ECMD-Fehlermeldung. Die analog-digital Umwandlung erfolgt in der Reihenfolge von Kanal A zu Kanal D, wobei die nicht gewünschte Kanäle (sprich jene, wo das input select mask Bit auf 0 steht) übersprungen werden. Der DS2450 braucht für jedes Bit Auflösung ca. 60 bis 80µs. Außerdem braucht das Umwandlung-Kommando generell 160µs (offset) Dies bedeutet, dass eine Umwandlung aller 4 Kanäle bei maximaler 16 Bit Auflösung also nicht länger als 4*16*80+160µs = 5280µs = 5,28ms dauern wird. ===== read out control ===== Mit dem read out control kann angegeben werden, ob und wie das Register für die Ergebnisse der analog-digital Umwandlung vorbelegt werden soll. Das macht nur dann Sinn, wenn die Umwandlungsergebnisse schon gelesen werden sollen, während der DS2450 im Hintergrund noch die analog-digital Umwandlung durchführt (was möglich ist). Das read out control ist ein 8 Bit Hexadezimalwert: {| border=1 cellspacing=0 padding=4 class=wikitable ! bit7 !! bit6 !! bit5 !! bit4 !! bit3 !! bit2 !! bit1 !! bit0 |- | Set D || Clear D || Set C || Clear C || Set B || Clear B || Set A || Clear A |} Set bzw. Clear verhalten sich wie folgt: {| border=1 cellspacing=0 padding=4 class=wikitable ! Set !! Clear !! Ergebnis |- | 0 || 0 || keine Veränderung am Umwandlung-Register |- | 0 || 1 || alle Bits des Umwandlung-Register werden auf 0 gesetzt |- | 1 || 0 || alle Bits des Umwandlung-Register werden auf 1 gesetzt |- | 1 || 1 || invalid |} Ungültige Kombinationen im read out control (d.h. Set = 1 und Clear = 1) werden erkannt und führen zu einer ECMD-Fehlermeldung. Default-Werte: * input select mask: 0x04 * read out control: 0x00 Beispiel: 1w ds2450 convert (für alle Kanäle wird die analog-digital Umwandlung durchgeführt) ==== <code>1w ds2450 get</code> ==== Hierüber wird das Ergebnis der analog-digital Umwandlung ausgelesen (analog den 1-wire Temperatursensoren). Werden keine weiteren Argumente angegeben, so werden die Umwandlungsergebnisse für alle 4 Kanäle des DS2450 ausgegeben. Optional kann ein Kanal angegeben werden, dann wird nur das Umwandlungsergebniss dieses Kanals ausgegeben. Wurde seit dem letzten power-on reset cycle keine Umwandlung durchgeführt, stehen alle Bits der Register auf 0. Die Ausgabe erfolgt als raw (unsigned integer 16 Bit - <code>uint16_t</code>). Die eingelesene Spannung errechnet sich wie folgt (VAL ist die Ausgabe von <code>1w ds2450 get</code>): * für range = 0 (0..2,55V) VAL ------- * 2,55V 2**16-1 * für range = 1 (0..5,10V) VAL ------- * 5,10V 2**16-1 Default-Werte: - Beispiel: 1w ds2450 get (die Umwandlungsergebnisse für alle 4 Kanäle werden ausgegeben) =Schaltungen= === Beispielschaltung 1=== Hier ein Beispielschaltung für den DS2450. Kanal A wird als Eingabe genutzt (range = 1). Kanal D wird als Ausgabe genutzt, über den Optokoppler kann die LED geschaltet werden. Der Widerstand R1 muss <b>unbedingt</b> entsprechend dem Optokoppler dimensioniert werden. Beim 4N35 sind 1k3 ausreichend, dann fließt ein Strom von ca. 2,8mA. [[File:DS2450 Beispiel 01.gif|600px|Beispielschaltung DS2450]] === Beispielschaltung 2=== Hier die Beispielschaltung 2 für den DS2450. Kanal A/B/C/D wird als Eingang genutzt (Range = 1). * I/O-A wird zb. als Tür oder Fenster Detektor genutzt. * I/O-B wird als Eingang für den Luftfeuchtesensor genutzt. * I/O-C wird als Eingang für den Luftdrucksensor genutzt. * I/O-D wird genutzt um die Versorgungsspannung zu messen welche bei der Berechnung des Luftdrucksensor benötigt wird. <br> Weiters hängt ein DS2450 und ein DS1820 parallel am Bus um noch eine Temperatur über den Bus zu bekommen. * [http://www.ethersex.de/images/5/5c/1W_MPX6115_HIH4000.pdf Schaltung als PDF downloaden] [[File:1W MPX6115 HIH4000.png|600px|Beispielschaltung DS2450]] * Zum Initialisieren verwende ich folgende Kommandos via ecmd zb.: <pre><nowiki> 1w ds2450 power 1 //(drei adrig) 1w ds2450 res c 08 //(00 / 10 = 16bit, 08 8bit) 1w ds2450 oe c 0 //(als eingang stetzen) 1w ds2450 range c 1 //(Range 0-5,10V) 1w ds2450 convert 1w ds2450 get </nowiki></pre> === Berechnungen des Feuchtesensor === // lt. Datenblatt: // OFFSET 0.958062V bei 0%RH // SLOPE: 30.680 mV/%RH $V_Feuchte = ($Humid/65535)*5.17; $RH_Feuchte = ($V_Feuchte - 0.958062) * 34.558; //Werte nach Kalibrierung ( 34.558 Ist bei mir genauer als 30.680) $RHR = $RH_Feuchte / ((1.0305 + (0.000044 * 25) - (0.0000011 * pow(22.6,2)))); echo $RHR; === Berechnungen des Drucksensor === $ADCwert = ($Druck/65535)*5.10; $ADCVBuswert= ($Vdd/65535)*5.10; $kpawert = $ADCwert/($ADCVBuswert*0.009)+10.55; echo $kpawert*10; === Werte des ADC schwanken beim auslesen === Lege doch mal die Versorgungsspannung direkt auf einen Eingang und schaue mal ob der Wert immer noch schwankt. === parse error 05.02.2016 === debug abschalten avr-gcc 472ok 435nok == Einbindung in Control6 (tcp_send) == https://github.com/ethersex/ethersex/blob/master/hardware/onewire/ds2450.h<br> http://www.tutorials.at/c/03-dateneingabe-ausgabe.html<br> <br> '''"ecmd?1w list"''' ergibt den rom code '''20686414000000b5''' für den ds2450<br> <br> <pre><nowiki> C6_HEADER(`/* This will be in control6.h */') #include "hardware/onewire/ds2450.h" uint16_t counter1 = 0; uint16_t var1 = 0; CONTROL_START CLOCK_USED() THREAD(start) var1 = 1; WAIT(5) var1 = 0; WAIT(5) THREAD_END(start) TCP_HANDLER_PERSIST(message_handler); if (var1 == 1){ ow_rom_code_t rom_code; uint16_t result; rom_code.bytewise[0] = 0x20; rom_code.bytewise[1] = 0x68; rom_code.bytewise[2] = 0x64; rom_code.bytewise[3] = 0x14; rom_code.bytewise[4] = 0x00; rom_code.bytewise[5] = 0x00; rom_code.bytewise[6] = 0x00; rom_code.bytewise[7] = 0xb5; ow_ds2450_convert(&rom_code, 0x0f, 0x00); ow_ds2450_get(&rom_code, 2, 2, &result); TCP_SEND("%u", result); WAIT(15) } TCP_HANDLER_END(); ON STARTUP DO THREAD_START(start) TCP_CONNECT(192.168.123.106, 4445, message_handler); END CONTROL_END </nowiki></pre> ca5c4e3cef5c4777780a00a6f26bbb6d55eeb86c 1693 1692 2016-02-05T19:18:04Z Djmaster 255 wikitext text/x-wiki {{i18n|Onewire/DS2450}} {{Module |NAME=Onewire DS2450 |MENUCONFIG={{I/O}}->Onewire support |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} *Beitrag am 05.02.2016 erneuert. = Einleitung = Der DS2450 ist ein 4 Kanal ADC mit einer maximalen Auflösung von 16 Bit (vgl. [http://datasheets.maxim-ic.com/en/ds/DS2450.pdf Datenblatt]). Die analog-digital Umwandlung erfolgt durch einen internen four-to-one multiplexer. Kanäle, die nicht als Eingänge genutzt werden, können als Ausgänge (open drain) geschaltet werden (max. 4mA und 6V). Grundsätzlich gilt für alle Befehle: * als erstes Argument kann optional die 64 Bit ROM Id des DS2450 angegeben werden, der angesprochen werden soll (match rom). Wird die ROM Id <b>nicht</b> angeben, so werden alle im Bus befindlichen 1-wire Devices (egal welchen Typs) angesprochen (skip rom). Dies macht <b>nur</b> Sinn, wenn sich <b>genau</b> ein Device im 1-wire Bus befindet (skip rom führt bei mehreren Devices unweigerlich dazu, dass mehrere Devices gleichzeitig antworten werden, was zu Bit-Salat beim bus master (d.h. Ethersex) führt, das Datenblatt spricht von "a wired-AND result"). * wird ein Kanal angeben, so ist dieser mit einem Buchstaben (entsprechend Datenblatt) zu bezeichnen (case-insensitiv). * wird mit einem Befehl ein Wert gesetzt, so kann mit dem gleichen Befehl der Wert gelesen werden, in dem man kein Werte-Argument angibt. === ECMD Interface === Über ECMD sind folgende Befehle für den DS2450 bekannt: 1w list 1w ds2450 power 1w ds2450 res 1w ds2450 oc 1w ds2450 oe 1w ds2450 range 1w ds2450 por 1w ds2450 convert 1w ds2450 get ==== <code>1w ds2450 power</code> ==== Hierüber wird die Art der Spannungsversorgung des DS2450 gesetzt (global). Dieser Parameter wird durch den Anschluss an der 1-wire Bus bestimmt, vgl. die [[Onewire_(Deutsch)#Anschluss_AVR-NET-IO | Erklärung der Anschlussmöglichkeiten]]. Wird der 1-wire Bus "normal" (drei-adrig) betrieben, so muss der Wert auf 1 gesetzt werden. Wird der Bus "parasitär" (zwei-adrig) betrieben, muss der Wert auf 0 gesetzt werden. Default-Wert: 0 Beispiel: 1w ds2450 power 1 (der DS250 wird auf "normale" Spannungsversorgung konfiguriert) ==== <code>1w ds2450 res</code> ==== Hierüber wird die Auflösung der analog-digital Umwandlung gesetzt (pro Kanal). Die Auflösung kann zw. 1 und 16 Bit eingestellt werden. Die Eingabe erfolgt als 8 Bit Hexadezimalwert, wobei eine Auflösung von 16 Bit durch den Wert 0x00 oder alternativ 0x10 erreicht wird. Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0x08 Beispiel: 1w ds2450 res c 08 (setzt die Auflösung für Kanal C auf 0x08, d.h. 8 Bit) ==== <code>1w ds2450 oc</code> ==== Hierüber kann der Ausgang ein- oder ausgeschaltet werden (pro Kanal). Voraussetzung ist, dass über [[DS2450#1w_ds2450_oe | 1w ds2450 oe]] der Kanal als Ausgang geschaltet wurde (ansonsten wird das OC-Bit ignoriert). Die Eingabe erfolgt als bool über 0 (Ausgangstransistor leitend) bzw. 1 (Ausgangstransistor nicht-leitend). Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0 Beispiel: 1w ds2450 oc a 1 (der Ausgangstransistor des Kanal A wird leitend) ==== <code>1w ds2450 oe</code> ==== Hierüber kann der Kanal als Ein- oder Ausgang gesetzt werden (pro Kanal). Eine analog-digital Umwandlung ist <b>nur</b> möglich, wenn das OE-Bit auf 0 gesetzt ist. In diesem Fall wird das OC-Bit ignoriert. Ist das OE-Bit auf 1 gesetzt, kann der Ausgang über 1w ds2450 oc ein- bzw. ausgeschaltet werden. Die Eingabe erfolgt als bool über 0 (Eingang für ADC) bzw. 1 (Ausgang open drain). Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0 Beispiel: 1w ds2450 oe d 1 (Kanal A wird als Ausgang gesetzt) ==== <code>1w ds2450 range</code> ==== Hierüber kann der Spannungs-Bereich angegeben werden, in dem die analog-digital Umwandlung stattfinden soll. Die Eingabe erfolgt als bool über 0 (Spannungsbereich 0 bis 2,55V) bzw. 1 (Spannungsbereich 0 bis 5,10V). Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 0 Beispiel: 1w ds2450 range b 1 (für Kanal B wird bei der analog-digital Umwandlung der Spannungsbereich 0 bis 5,10V genutzt) ==== <code>1w ds2450 por</code> ==== Hierüber kann das power on reset Bit gelesen bzw. gesetzt werden. Nach einem power-on reset cycle setzt der DS2450 das Bit auf 1. Das Bit beeinflusst die conditional search, welche in Ethersex (noch) nicht implementiert ist. Setzt der bus master das Bit auf 0, so nimmt der DS2450 nicht mehr an der conditional search teil Die Eingabe erfolgt als bool über 0 bzw. 1. Außerdem ist die Kanal-Bezeichnung anzugeben. Default-Wert: 1 (nach power-on reset cycle) Beispiel: 1w ds2450 por c 0 (für Kanal C wird das power on reset Bit auf 0 gesetzt) FixMe: Es sieht so aus, als kann das Bit nur global gesetzt werden, d.h. wird es für einen Kanal verändert, haben danach alle anderen Kanäle den gleich POR-Bit Wert. Außerdem kann man das Bit nicht mehr auf 1 setzen, wenn es vorher schon auf 0 gesetzt wurde (das widerspricht aber dem Datenblatt!). ==== <code>1w ds2450 convert</code> ==== Hierüber wird die analog-digital Umwandlung ausgelöst (analog den 1-wire Temperatursensoren). Werden keine weiteren Argumente angegeben, so wird die Umwandlung für alle 4 Kanäle des DS2450 durchgeführt (FixMe: vermutlich werden die Kanäle, bei denen das OE-Bit auf 1 steht ausgelassen, dass ist aber nicht durch Dallas dokumentiert). Optional können zwei Argumente angegeben werden (werden Argumente angegeben, <b>müssen beide</b> Argumente angegeben werden!): * input select mask * read-out control ===== input select mask ===== Mit der input select mask kann angegeben werden, für welche Kanäle die analog-digital Umwandlung durchgeführt werden soll. Die input select mask ist ein 8 Bit Hexadezimalwert: {| border=1 cellspacing=0 padding=4 class=wikitable ! bit7 !! bit6 !! bit5 !! bit4 !! bit3 !! bit2 !! bit1 !! bit0 |- | ignore || ignore || ignore || ignore || Kanal D || Kanal C || Kanal B || Kanal A |} Eine input select mask von 0x0f bedeutet also, dass für alle 4 Kanäle die analog-digital Umwandlung durchgeführt werden soll. Eine mask von 0x00 ist (offensichtlich) sinnlos. Eine ungültige input select mask (d.h. input select mask == 0x00 oder > 0x0f) wird erkannt und führt zu einer ECMD-Fehlermeldung. Die analog-digital Umwandlung erfolgt in der Reihenfolge von Kanal A zu Kanal D, wobei die nicht gewünschte Kanäle (sprich jene, wo das input select mask Bit auf 0 steht) übersprungen werden. Der DS2450 braucht für jedes Bit Auflösung ca. 60 bis 80µs. Außerdem braucht das Umwandlung-Kommando generell 160µs (offset) Dies bedeutet, dass eine Umwandlung aller 4 Kanäle bei maximaler 16 Bit Auflösung also nicht länger als 4*16*80+160µs = 5280µs = 5,28ms dauern wird. ===== read out control ===== Mit dem read out control kann angegeben werden, ob und wie das Register für die Ergebnisse der analog-digital Umwandlung vorbelegt werden soll. Das macht nur dann Sinn, wenn die Umwandlungsergebnisse schon gelesen werden sollen, während der DS2450 im Hintergrund noch die analog-digital Umwandlung durchführt (was möglich ist). Das read out control ist ein 8 Bit Hexadezimalwert: {| border=1 cellspacing=0 padding=4 class=wikitable ! bit7 !! bit6 !! bit5 !! bit4 !! bit3 !! bit2 !! bit1 !! bit0 |- | Set D || Clear D || Set C || Clear C || Set B || Clear B || Set A || Clear A |} Set bzw. Clear verhalten sich wie folgt: {| border=1 cellspacing=0 padding=4 class=wikitable ! Set !! Clear !! Ergebnis |- | 0 || 0 || keine Veränderung am Umwandlung-Register |- | 0 || 1 || alle Bits des Umwandlung-Register werden auf 0 gesetzt |- | 1 || 0 || alle Bits des Umwandlung-Register werden auf 1 gesetzt |- | 1 || 1 || invalid |} Ungültige Kombinationen im read out control (d.h. Set = 1 und Clear = 1) werden erkannt und führen zu einer ECMD-Fehlermeldung. Default-Werte: * input select mask: 0x04 * read out control: 0x00 Beispiel: 1w ds2450 convert (für alle Kanäle wird die analog-digital Umwandlung durchgeführt) ==== <code>1w ds2450 get</code> ==== Hierüber wird das Ergebnis der analog-digital Umwandlung ausgelesen (analog den 1-wire Temperatursensoren). Werden keine weiteren Argumente angegeben, so werden die Umwandlungsergebnisse für alle 4 Kanäle des DS2450 ausgegeben. Optional kann ein Kanal angegeben werden, dann wird nur das Umwandlungsergebniss dieses Kanals ausgegeben. Wurde seit dem letzten power-on reset cycle keine Umwandlung durchgeführt, stehen alle Bits der Register auf 0. Die Ausgabe erfolgt als raw (unsigned integer 16 Bit - <code>uint16_t</code>). Die eingelesene Spannung errechnet sich wie folgt (VAL ist die Ausgabe von <code>1w ds2450 get</code>): * für range = 0 (0..2,55V) VAL ------- * 2,55V 2**16-1 * für range = 1 (0..5,10V) VAL ------- * 5,10V 2**16-1 Default-Werte: - Beispiel: 1w ds2450 get (die Umwandlungsergebnisse für alle 4 Kanäle werden ausgegeben) =Schaltungen= === Beispielschaltung 1=== Hier ein Beispielschaltung für den DS2450. Kanal A wird als Eingabe genutzt (range = 1). Kanal D wird als Ausgabe genutzt, über den Optokoppler kann die LED geschaltet werden. Der Widerstand R1 muss <b>unbedingt</b> entsprechend dem Optokoppler dimensioniert werden. Beim 4N35 sind 1k3 ausreichend, dann fließt ein Strom von ca. 2,8mA. [[File:DS2450 Beispiel 01.gif|600px|Beispielschaltung DS2450]] === Beispielschaltung 2=== Hier die Beispielschaltung 2 für den DS2450. Kanal A/B/C/D wird als Eingang genutzt (Range = 1). * I/O-A wird zb. als Tür oder Fenster Detektor genutzt. * I/O-B wird als Eingang für den Luftfeuchtesensor genutzt. * I/O-C wird als Eingang für den Luftdrucksensor genutzt. * I/O-D wird genutzt um die Versorgungsspannung zu messen welche bei der Berechnung des Luftdrucksensor benötigt wird. <br> Weiters hängt ein DS2450 und ein DS1820 parallel am Bus um noch eine Temperatur über den Bus zu bekommen. * [http://www.ethersex.de/images/5/5c/1W_MPX6115_HIH4000.pdf Schaltung als PDF downloaden] [[File:1W MPX6115 HIH4000.png|600px|Beispielschaltung DS2450]] * Zum Initialisieren verwende ich folgende Kommandos via ecmd zb.: <pre><nowiki> 1w ds2450 power 1 //(drei adrig) 1w ds2450 res c 08 //(00 / 10 = 16bit, 08 8bit) 1w ds2450 oe c 0 //(als eingang stetzen) 1w ds2450 range c 1 //(Range 0-5,10V) 1w ds2450 convert 1w ds2450 get </nowiki></pre> === Berechnungen des Feuchtesensor === // lt. Datenblatt: // OFFSET 0.958062V bei 0%RH // SLOPE: 30.680 mV/%RH $V_Feuchte = ($Humid/65535)*5.17; $RH_Feuchte = ($V_Feuchte - 0.958062) * 34.558; //Werte nach Kalibrierung ( 34.558 Ist bei mir genauer als 30.680) $RHR = $RH_Feuchte / ((1.0305 + (0.000044 * 25) - (0.0000011 * pow(22.6,2)))); echo $RHR; === Berechnungen des Drucksensor === $ADCwert = ($Druck/65535)*5.10; $ADCVBuswert= ($Vdd/65535)*5.10; $kpawert = $ADCwert/($ADCVBuswert*0.009)+10.55; echo $kpawert*10; === Werte des ADC schwanken beim auslesen === Lege doch mal die Versorgungsspannung direkt auf einen Eingang und schaue mal ob der Wert immer noch schwankt. === parse error 05.02.2016 === debug abschalten avr-gcc 472ok 435nok == Einbindung in Control6 (tcp_send) == https://github.com/ethersex/ethersex/blob/master/hardware/onewire/ds2450.h<br> http://www.tutorials.at/c/03-dateneingabe-ausgabe.html<br> <br> '''"ecmd?1w list"''' ergibt den rom code '''20686414000000b5''' für den ds2450<br> <br> <pre><nowiki> C6_HEADER(`/* This will be in control6.h */') #include "hardware/onewire/ds2450.h" uint16_t counter1 = 0; uint16_t var1 = 0; CONTROL_START CLOCK_USED() THREAD(start) var1 = 1; WAIT(5) var1 = 0; WAIT(5) THREAD_END(start) TCP_HANDLER_PERSIST(message_handler); if (var1 == 1){ ow_rom_code_t rom_code; uint16_t result; rom_code.bytewise[0] = 0x20; rom_code.bytewise[1] = 0x68; rom_code.bytewise[2] = 0x64; rom_code.bytewise[3] = 0x14; rom_code.bytewise[4] = 0x00; rom_code.bytewise[5] = 0x00; rom_code.bytewise[6] = 0x00; rom_code.bytewise[7] = 0xb5; ow_ds2450_convert(&rom_code, 0x0f, 0x00); ow_ds2450_get(&rom_code, 2, 2, &result); TCP_SEND("%u", result); WAIT(15) } TCP_HANDLER_END(); ON STARTUP DO THREAD_START(start) TCP_CONNECT(192.168.123.106, 4445, message_handler); END CONTROL_END </nowiki></pre> 7e484e5931d07ba9d76a923f4a496487c31996ec 1694 1693 2016-02-05T19:53:12Z Djmaster 255 wikitext text/x-wiki {{i18n|Onewire/DS2450}} {{Module |NAME=Onewire DS2450 |MENUCONFIG={{I/O}}->Onewire support |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} *Beitrag am 05.02.2016 erneuert. = Einleitung = Der DS2450 ist ein 4 Kanal ADC mit einer maximalen Auflösung von 16 Bit (vgl. [http://datasheets.maxim-ic.com/en/ds/DS2450.pdf Datenblatt]). Die analog-digital Umwandlung erfolgt durch einen internen four-to-one multiplexer. Kanäle, die nicht als Eingänge genutzt werden, können als Ausgänge (open drain) geschaltet werden (max. 4mA und 6V). Grundsätzlich gilt für alle Befehle: * als erstes Argument kann optional die 64 Bit ROM Id des DS2450 angegeben werden, der angesprochen werden soll (match rom). Wird die ROM Id <b>nicht</b> angeben, so werden alle im Bus befindlichen 1-wire Devices (egal welchen Typs) angesprochen (skip rom). Dies macht <b>nur</b> Sinn, wenn sich <b>genau</b> ein Device im 1-wire Bus befindet (skip rom führt bei mehreren Devices unweigerlich dazu, dass mehrere Devices gleichzeitig antworten werden, was zu Bit-Salat beim bus master (d.h. Ethersex) führt, das Datenblatt spricht von "a wired-AND result"). * wird ein Kanal angeben, so ist dieser mit einem Buchstaben (entsprechend Datenblatt) zu bezeichnen (case-insensitiv). * wird mit einem Befehl ein Wert gesetzt, so kann mit dem gleichen Befehl der Wert gelesen werden, in dem man kein Werte-Argument angibt. == ECMD Befehle == Über ECMD sind folgende Befehle für den DS2450 bekannt: 1w list 1w ds2450 power $id // Sensor id mit "1w list" auslesen 1w ds2450 res 1w ds2450 oc 1w ds2450 oe 1w ds2450 range 1w ds2450 por 1w ds2450 convert 1w ds2450 get ---- === POWER === 1w ds2450 power $id // Parameter auslesen. 1w ds2450 power $id 1 // Beispiel: Der DS2450 wird auf "normale" Spannungsversorgung konfiguriert. Hierüber wird die Art der Spannungsversorgung des DS2450 gesetzt (global). Dieser Parameter wird durch den Anschluss an der 1-wire Bus bestimmt, vgl. die [[Onewire_(Deutsch)#Anschluss_AVR-NET-IO | Erklärung der Anschlussmöglichkeiten]]. Wird der 1-wire Bus "normal" (drei-adrig) betrieben, so muss der Wert auf 1 gesetzt werden. Wird der Bus "parasitär" (zwei-adrig) betrieben, muss der Wert auf 0 gesetzt werden. (Default-Wert: 0) ---- === RES === 1w ds2450 res $id $kanal // Parameter auslesen. 1w ds2450 res $id c 08 // Beispiel: Setzt die Auflösung für Kanal C auf 0x08, d.h. 8 Bit. Hierüber wird die Auflösung der analog-digital Umwandlung gesetzt (pro Kanal). Die Auflösung kann zw. 1 und 16 Bit eingestellt werden. Die Eingabe erfolgt als 8 Bit Hexadezimalwert, wobei eine Auflösung von 16 Bit durch den Wert 0x00 oder alternativ 0x10 erreicht wird. Außerdem ist die Kanal-Bezeichnung anzugeben. (Default-Wert: 0x08) ---- === OC === 1w ds2450 oc $id $kanal // Parameter auslesen. 1w ds2450 oc $id a 1 // Beispiel: Der Ausgangstransistor des Kanal A wird leitend. Hierüber kann der Ausgang ein- oder ausgeschaltet werden (pro Kanal). Voraussetzung ist, dass über [[DS2450#1w_ds2450_oe | 1w ds2450 oe]] der Kanal als Ausgang geschaltet wurde (ansonsten wird das OC-Bit ignoriert). Die Eingabe erfolgt als bool über 0 (Ausgangstransistor leitend) bzw. 1 (Ausgangstransistor nicht-leitend). Außerdem ist die Kanal-Bezeichnung anzugeben. (Default-Wert: 0) ---- === OE === 1w ds2450 oe $id $kanal // Parameter auslesen. 1w ds2450 oe $id d 1 // Beispiel: Kanal A wird als Ausgang gesetzt. Hierüber kann der Kanal als Ein- oder Ausgang gesetzt werden (pro Kanal). Eine analog-digital Umwandlung ist <b>nur</b> möglich, wenn das OE-Bit auf 0 gesetzt ist. In diesem Fall wird das OC-Bit ignoriert. Ist das OE-Bit auf 1 gesetzt, kann der Ausgang über 1w ds2450 oc ein- bzw. ausgeschaltet werden. Die Eingabe erfolgt als bool über 0 (Eingang für ADC) bzw. 1 (Ausgang open drain). Außerdem ist die Kanal-Bezeichnung anzugeben. (Default-Wert: 0) ---- === RANGE === 1w ds2450 range $id $kanal // Parameter auslesen. 1w ds2450 range $id b 1 // Beispiel: Für Kanal B wird bei der A/D Umwandlung der Spannungsbereich 0 bis 5,10V genutzt. Hierüber kann der Spannungs-Bereich angegeben werden, in dem die analog-digital Umwandlung stattfinden soll. Die Eingabe erfolgt als bool über 0 (Spannungsbereich 0 bis 2,55V) bzw. 1 (Spannungsbereich 0 bis 5,10V). Außerdem ist die Kanal-Bezeichnung anzugeben. (Default-Wert: 0) ---- === POR === 1w ds2450 por $id $kanal // Parameter auslesen. 1w ds2450 por $id c 0 // Beispiel: Für Kanal C wird das power on reset Bit auf 0 gesetzt. Hierüber kann das power on reset Bit gelesen bzw. gesetzt werden. Nach einem power-on reset cycle setzt der DS2450 das Bit auf 1. Das Bit beeinflusst die conditional search, welche in Ethersex (noch) nicht implementiert ist. Setzt der bus master das Bit auf 0, so nimmt der DS2450 nicht mehr an der conditional search teil. Die Eingabe erfolgt als bool über 0 bzw. 1. Außerdem ist die Kanal-Bezeichnung anzugeben. (Default-Wert: 1 (nach power-on reset cycle)) FixMe: Es sieht so aus, als kann das Bit nur global gesetzt werden, d.h. wird es für einen Kanal verändert, haben danach alle anderen Kanäle den gleich POR-Bit Wert. Außerdem kann man das Bit nicht mehr auf 1 setzen, wenn es vorher schon auf 0 gesetzt wurde (das widerspricht aber dem Datenblatt!). ---- === CONVERT === 1w ds2450 convert $id // Beispiel: Für alle Kanäle wird die analog-digital Umwandlung durchgeführt. Hierüber wird die analog-digital Umwandlung ausgelöst (analog den 1-wire Temperatursensoren). Werden keine weiteren Argumente angegeben, so wird die Umwandlung für alle 4 Kanäle des DS2450 durchgeführt (FixMe: vermutlich werden die Kanäle, bei denen das OE-Bit auf 1 steht ausgelassen, dass ist aber nicht durch Dallas dokumentiert). Optional können zwei Argumente angegeben werden (werden Argumente angegeben, <b>müssen beide</b> Argumente angegeben werden!): * input select mask * read-out control *'''input select mask''' Mit der input select mask kann angegeben werden, für welche Kanäle die analog-digital Umwandlung durchgeführt werden soll. Die input select mask ist ein 8 Bit Hexadezimalwert: {| border=1 cellspacing=0 padding=4 class=wikitable ! bit7 !! bit6 !! bit5 !! bit4 !! bit3 !! bit2 !! bit1 !! bit0 |- | ignore || ignore || ignore || ignore || Kanal D || Kanal C || Kanal B || Kanal A |} Eine input select mask von 0x0f bedeutet also, dass für alle 4 Kanäle die analog-digital Umwandlung durchgeführt werden soll. Eine mask von 0x00 ist (offensichtlich) sinnlos. Eine ungültige input select mask (d.h. input select mask == 0x00 oder > 0x0f) wird erkannt und führt zu einer ECMD-Fehlermeldung. Die analog-digital Umwandlung erfolgt in der Reihenfolge von Kanal A zu Kanal D, wobei die nicht gewünschte Kanäle (sprich jene, wo das input select mask Bit auf 0 steht) übersprungen werden. Der DS2450 braucht für jedes Bit Auflösung ca. 60 bis 80µs. Außerdem braucht das Umwandlung-Kommando generell 160µs (offset) Dies bedeutet, dass eine Umwandlung aller 4 Kanäle bei maximaler 16 Bit Auflösung also nicht länger als 4*16*80+160µs = 5280µs = 5,28ms dauern wird. * '''read out control''' Mit dem read out control kann angegeben werden, ob und wie das Register für die Ergebnisse der analog-digital Umwandlung vorbelegt werden soll. Das macht nur dann Sinn, wenn die Umwandlungsergebnisse schon gelesen werden sollen, während der DS2450 im Hintergrund noch die analog-digital Umwandlung durchführt (was möglich ist). Das read out control ist ein 8 Bit Hexadezimalwert: {| border=1 cellspacing=0 padding=4 class=wikitable ! bit7 !! bit6 !! bit5 !! bit4 !! bit3 !! bit2 !! bit1 !! bit0 |- | Set D || Clear D || Set C || Clear C || Set B || Clear B || Set A || Clear A |} Set bzw. Clear verhalten sich wie folgt: {| border=1 cellspacing=0 padding=4 class=wikitable ! Set !! Clear !! Ergebnis |- | 0 || 0 || keine Veränderung am Umwandlung-Register |- | 0 || 1 || alle Bits des Umwandlung-Register werden auf 0 gesetzt |- | 1 || 0 || alle Bits des Umwandlung-Register werden auf 1 gesetzt |- | 1 || 1 || invalid |} Ungültige Kombinationen im read out control (d.h. Set = 1 und Clear = 1) werden erkannt und führen zu einer ECMD-Fehlermeldung. Default-Werte: * input select mask: 0x04 * read out control: 0x00 ---- === GET === 1w ds2450 get // Beispiel: Die Umwandlungsergebnisse für alle 4 Kanäle werden ausgegeben. Hierüber wird das Ergebnis der analog-digital Umwandlung ausgelesen (analog den 1-wire Temperatursensoren). Werden keine weiteren Argumente angegeben, so werden die Umwandlungsergebnisse für alle 4 Kanäle des DS2450 ausgegeben. Optional kann ein Kanal angegeben werden, dann wird nur das Umwandlungsergebniss dieses Kanals ausgegeben. Wurde seit dem letzten power-on reset cycle keine Umwandlung durchgeführt, stehen alle Bits der Register auf 0. Die Ausgabe erfolgt als raw (unsigned integer 16 Bit - <code>uint16_t</code>). Die eingelesene Spannung errechnet sich wie folgt (VAL ist die Ausgabe von <code>1w ds2450 get</code>): * für range = 0 (0..2,55V) VAL ------- * 2,55V 2**16-1 * für range = 1 (0..5,10V) VAL ------- * 5,10V 2**16-1 =Schaltungen= === Beispielschaltung 1=== Hier ein Beispielschaltung für den DS2450. Kanal A wird als Eingabe genutzt (range = 1). Kanal D wird als Ausgabe genutzt, über den Optokoppler kann die LED geschaltet werden. Der Widerstand R1 muss <b>unbedingt</b> entsprechend dem Optokoppler dimensioniert werden. Beim 4N35 sind 1k3 ausreichend, dann fließt ein Strom von ca. 2,8mA. [[File:DS2450 Beispiel 01.gif|600px|Beispielschaltung DS2450]] === Beispielschaltung 2=== Hier die Beispielschaltung 2 für den DS2450. Kanal A/B/C/D wird als Eingang genutzt (Range = 1). * I/O-A wird zb. als Tür oder Fenster Detektor genutzt. * I/O-B wird als Eingang für den Luftfeuchtesensor genutzt. * I/O-C wird als Eingang für den Luftdrucksensor genutzt. * I/O-D wird genutzt um die Versorgungsspannung zu messen welche bei der Berechnung des Luftdrucksensor benötigt wird. <br> Weiters hängt ein DS2450 und ein DS1820 parallel am Bus um noch eine Temperatur über den Bus zu bekommen. * [http://www.ethersex.de/images/5/5c/1W_MPX6115_HIH4000.pdf Schaltung als PDF downloaden] [[File:1W MPX6115 HIH4000.png|600px|Beispielschaltung DS2450]] * Zum Initialisieren verwende ich folgende Kommandos via ecmd zb.: <pre><nowiki> 1w ds2450 power 1 //(drei adrig) 1w ds2450 res c 08 //(00 / 10 = 16bit, 08 8bit) 1w ds2450 oe c 0 //(als eingang stetzen) 1w ds2450 range c 1 //(Range 0-5,10V) 1w ds2450 convert 1w ds2450 get </nowiki></pre> === Berechnungen des Feuchtesensor === // lt. Datenblatt: // OFFSET 0.958062V bei 0%RH // SLOPE: 30.680 mV/%RH $V_Feuchte = ($Humid/65535)*5.17; $RH_Feuchte = ($V_Feuchte - 0.958062) * 34.558; //Werte nach Kalibrierung ( 34.558 Ist bei mir genauer als 30.680) $RHR = $RH_Feuchte / ((1.0305 + (0.000044 * 25) - (0.0000011 * pow(22.6,2)))); echo $RHR; === Berechnungen des Drucksensor === $ADCwert = ($Druck/65535)*5.10; $ADCVBuswert= ($Vdd/65535)*5.10; $kpawert = $ADCwert/($ADCVBuswert*0.009)+10.55; echo $kpawert*10; === Werte des ADC schwanken beim auslesen === Lege doch mal die Versorgungsspannung direkt auf einen Eingang und schaue mal ob der Wert immer noch schwankt. === parse error 05.02.2016 === debug abschalten avr-gcc 472ok 435nok == Einbindung in Control6 (tcp_send) == https://github.com/ethersex/ethersex/blob/master/hardware/onewire/ds2450.h<br> http://www.tutorials.at/c/03-dateneingabe-ausgabe.html<br> <br> '''"ecmd?1w list"''' ergibt den rom code '''20686414000000b5''' für den ds2450<br> <br> <pre><nowiki> C6_HEADER(`/* This will be in control6.h */') #include "hardware/onewire/ds2450.h" uint16_t counter1 = 0; uint16_t var1 = 0; CONTROL_START CLOCK_USED() THREAD(start) var1 = 1; WAIT(5) var1 = 0; WAIT(5) THREAD_END(start) TCP_HANDLER_PERSIST(message_handler); if (var1 == 1){ ow_rom_code_t rom_code; uint16_t result; rom_code.bytewise[0] = 0x20; rom_code.bytewise[1] = 0x68; rom_code.bytewise[2] = 0x64; rom_code.bytewise[3] = 0x14; rom_code.bytewise[4] = 0x00; rom_code.bytewise[5] = 0x00; rom_code.bytewise[6] = 0x00; rom_code.bytewise[7] = 0xb5; ow_ds2450_convert(&rom_code, 0x0f, 0x00); ow_ds2450_get(&rom_code, 2, 2, &result); TCP_SEND("%u", result); WAIT(15) } TCP_HANDLER_END(); ON STARTUP DO THREAD_START(start) TCP_CONNECT(192.168.123.106, 4445, message_handler); END CONTROL_END </nowiki></pre> aaa77b4d85edd1a08cbf4add543305c880a4ca5c 1695 1694 2016-02-05T19:53:48Z Djmaster 255 /* POR */ wikitext text/x-wiki {{i18n|Onewire/DS2450}} {{Module |NAME=Onewire DS2450 |MENUCONFIG={{I/O}}->Onewire support |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} *Beitrag am 05.02.2016 erneuert. = Einleitung = Der DS2450 ist ein 4 Kanal ADC mit einer maximalen Auflösung von 16 Bit (vgl. [http://datasheets.maxim-ic.com/en/ds/DS2450.pdf Datenblatt]). Die analog-digital Umwandlung erfolgt durch einen internen four-to-one multiplexer. Kanäle, die nicht als Eingänge genutzt werden, können als Ausgänge (open drain) geschaltet werden (max. 4mA und 6V). Grundsätzlich gilt für alle Befehle: * als erstes Argument kann optional die 64 Bit ROM Id des DS2450 angegeben werden, der angesprochen werden soll (match rom). Wird die ROM Id <b>nicht</b> angeben, so werden alle im Bus befindlichen 1-wire Devices (egal welchen Typs) angesprochen (skip rom). Dies macht <b>nur</b> Sinn, wenn sich <b>genau</b> ein Device im 1-wire Bus befindet (skip rom führt bei mehreren Devices unweigerlich dazu, dass mehrere Devices gleichzeitig antworten werden, was zu Bit-Salat beim bus master (d.h. Ethersex) führt, das Datenblatt spricht von "a wired-AND result"). * wird ein Kanal angeben, so ist dieser mit einem Buchstaben (entsprechend Datenblatt) zu bezeichnen (case-insensitiv). * wird mit einem Befehl ein Wert gesetzt, so kann mit dem gleichen Befehl der Wert gelesen werden, in dem man kein Werte-Argument angibt. == ECMD Befehle == Über ECMD sind folgende Befehle für den DS2450 bekannt: 1w list 1w ds2450 power $id // Sensor id mit "1w list" auslesen 1w ds2450 res 1w ds2450 oc 1w ds2450 oe 1w ds2450 range 1w ds2450 por 1w ds2450 convert 1w ds2450 get ---- === POWER === 1w ds2450 power $id // Parameter auslesen. 1w ds2450 power $id 1 // Beispiel: Der DS2450 wird auf "normale" Spannungsversorgung konfiguriert. Hierüber wird die Art der Spannungsversorgung des DS2450 gesetzt (global). Dieser Parameter wird durch den Anschluss an der 1-wire Bus bestimmt, vgl. die [[Onewire_(Deutsch)#Anschluss_AVR-NET-IO | Erklärung der Anschlussmöglichkeiten]]. Wird der 1-wire Bus "normal" (drei-adrig) betrieben, so muss der Wert auf 1 gesetzt werden. Wird der Bus "parasitär" (zwei-adrig) betrieben, muss der Wert auf 0 gesetzt werden. (Default-Wert: 0) ---- === RES === 1w ds2450 res $id $kanal // Parameter auslesen. 1w ds2450 res $id c 08 // Beispiel: Setzt die Auflösung für Kanal C auf 0x08, d.h. 8 Bit. Hierüber wird die Auflösung der analog-digital Umwandlung gesetzt (pro Kanal). Die Auflösung kann zw. 1 und 16 Bit eingestellt werden. Die Eingabe erfolgt als 8 Bit Hexadezimalwert, wobei eine Auflösung von 16 Bit durch den Wert 0x00 oder alternativ 0x10 erreicht wird. Außerdem ist die Kanal-Bezeichnung anzugeben. (Default-Wert: 0x08) ---- === OC === 1w ds2450 oc $id $kanal // Parameter auslesen. 1w ds2450 oc $id a 1 // Beispiel: Der Ausgangstransistor des Kanal A wird leitend. Hierüber kann der Ausgang ein- oder ausgeschaltet werden (pro Kanal). Voraussetzung ist, dass über [[DS2450#1w_ds2450_oe | 1w ds2450 oe]] der Kanal als Ausgang geschaltet wurde (ansonsten wird das OC-Bit ignoriert). Die Eingabe erfolgt als bool über 0 (Ausgangstransistor leitend) bzw. 1 (Ausgangstransistor nicht-leitend). Außerdem ist die Kanal-Bezeichnung anzugeben. (Default-Wert: 0) ---- === OE === 1w ds2450 oe $id $kanal // Parameter auslesen. 1w ds2450 oe $id d 1 // Beispiel: Kanal A wird als Ausgang gesetzt. Hierüber kann der Kanal als Ein- oder Ausgang gesetzt werden (pro Kanal). Eine analog-digital Umwandlung ist <b>nur</b> möglich, wenn das OE-Bit auf 0 gesetzt ist. In diesem Fall wird das OC-Bit ignoriert. Ist das OE-Bit auf 1 gesetzt, kann der Ausgang über 1w ds2450 oc ein- bzw. ausgeschaltet werden. Die Eingabe erfolgt als bool über 0 (Eingang für ADC) bzw. 1 (Ausgang open drain). Außerdem ist die Kanal-Bezeichnung anzugeben. (Default-Wert: 0) ---- === RANGE === 1w ds2450 range $id $kanal // Parameter auslesen. 1w ds2450 range $id b 1 // Beispiel: Für Kanal B wird bei der A/D Umwandlung der Spannungsbereich 0 bis 5,10V genutzt. Hierüber kann der Spannungs-Bereich angegeben werden, in dem die analog-digital Umwandlung stattfinden soll. Die Eingabe erfolgt als bool über 0 (Spannungsbereich 0 bis 2,55V) bzw. 1 (Spannungsbereich 0 bis 5,10V). Außerdem ist die Kanal-Bezeichnung anzugeben. (Default-Wert: 0) ---- === POR === 1w ds2450 por $id $kanal // Parameter auslesen. 1w ds2450 por $id c 0 // Beispiel: Für Kanal C wird das power on reset Bit auf 0 gesetzt. Hierüber kann das power on reset Bit gelesen bzw. gesetzt werden. Nach einem power-on reset cycle setzt der DS2450 das Bit auf 1. Das Bit beeinflusst die conditional search, welche in Ethersex (noch) nicht implementiert ist. Setzt der bus master das Bit auf 0, so nimmt der DS2450 nicht mehr an der conditional search teil. Die Eingabe erfolgt als bool über 0 bzw. 1. Außerdem ist die Kanal-Bezeichnung anzugeben. (Default-Wert: 1 (nach power-on reset cycle)) FixMe:<br> Es sieht so aus, als kann das Bit nur global gesetzt werden, d.h. wird es für einen Kanal verändert, haben danach alle anderen Kanäle den gleich POR-Bit Wert. Außerdem kann man das Bit nicht mehr auf 1 setzen, wenn es vorher schon auf 0 gesetzt wurde (das widerspricht aber dem Datenblatt!). ---- === CONVERT === 1w ds2450 convert $id // Beispiel: Für alle Kanäle wird die analog-digital Umwandlung durchgeführt. Hierüber wird die analog-digital Umwandlung ausgelöst (analog den 1-wire Temperatursensoren). Werden keine weiteren Argumente angegeben, so wird die Umwandlung für alle 4 Kanäle des DS2450 durchgeführt (FixMe: vermutlich werden die Kanäle, bei denen das OE-Bit auf 1 steht ausgelassen, dass ist aber nicht durch Dallas dokumentiert). Optional können zwei Argumente angegeben werden (werden Argumente angegeben, <b>müssen beide</b> Argumente angegeben werden!): * input select mask * read-out control *'''input select mask''' Mit der input select mask kann angegeben werden, für welche Kanäle die analog-digital Umwandlung durchgeführt werden soll. Die input select mask ist ein 8 Bit Hexadezimalwert: {| border=1 cellspacing=0 padding=4 class=wikitable ! bit7 !! bit6 !! bit5 !! bit4 !! bit3 !! bit2 !! bit1 !! bit0 |- | ignore || ignore || ignore || ignore || Kanal D || Kanal C || Kanal B || Kanal A |} Eine input select mask von 0x0f bedeutet also, dass für alle 4 Kanäle die analog-digital Umwandlung durchgeführt werden soll. Eine mask von 0x00 ist (offensichtlich) sinnlos. Eine ungültige input select mask (d.h. input select mask == 0x00 oder > 0x0f) wird erkannt und führt zu einer ECMD-Fehlermeldung. Die analog-digital Umwandlung erfolgt in der Reihenfolge von Kanal A zu Kanal D, wobei die nicht gewünschte Kanäle (sprich jene, wo das input select mask Bit auf 0 steht) übersprungen werden. Der DS2450 braucht für jedes Bit Auflösung ca. 60 bis 80µs. Außerdem braucht das Umwandlung-Kommando generell 160µs (offset) Dies bedeutet, dass eine Umwandlung aller 4 Kanäle bei maximaler 16 Bit Auflösung also nicht länger als 4*16*80+160µs = 5280µs = 5,28ms dauern wird. * '''read out control''' Mit dem read out control kann angegeben werden, ob und wie das Register für die Ergebnisse der analog-digital Umwandlung vorbelegt werden soll. Das macht nur dann Sinn, wenn die Umwandlungsergebnisse schon gelesen werden sollen, während der DS2450 im Hintergrund noch die analog-digital Umwandlung durchführt (was möglich ist). Das read out control ist ein 8 Bit Hexadezimalwert: {| border=1 cellspacing=0 padding=4 class=wikitable ! bit7 !! bit6 !! bit5 !! bit4 !! bit3 !! bit2 !! bit1 !! bit0 |- | Set D || Clear D || Set C || Clear C || Set B || Clear B || Set A || Clear A |} Set bzw. Clear verhalten sich wie folgt: {| border=1 cellspacing=0 padding=4 class=wikitable ! Set !! Clear !! Ergebnis |- | 0 || 0 || keine Veränderung am Umwandlung-Register |- | 0 || 1 || alle Bits des Umwandlung-Register werden auf 0 gesetzt |- | 1 || 0 || alle Bits des Umwandlung-Register werden auf 1 gesetzt |- | 1 || 1 || invalid |} Ungültige Kombinationen im read out control (d.h. Set = 1 und Clear = 1) werden erkannt und führen zu einer ECMD-Fehlermeldung. Default-Werte: * input select mask: 0x04 * read out control: 0x00 ---- === GET === 1w ds2450 get // Beispiel: Die Umwandlungsergebnisse für alle 4 Kanäle werden ausgegeben. Hierüber wird das Ergebnis der analog-digital Umwandlung ausgelesen (analog den 1-wire Temperatursensoren). Werden keine weiteren Argumente angegeben, so werden die Umwandlungsergebnisse für alle 4 Kanäle des DS2450 ausgegeben. Optional kann ein Kanal angegeben werden, dann wird nur das Umwandlungsergebniss dieses Kanals ausgegeben. Wurde seit dem letzten power-on reset cycle keine Umwandlung durchgeführt, stehen alle Bits der Register auf 0. Die Ausgabe erfolgt als raw (unsigned integer 16 Bit - <code>uint16_t</code>). Die eingelesene Spannung errechnet sich wie folgt (VAL ist die Ausgabe von <code>1w ds2450 get</code>): * für range = 0 (0..2,55V) VAL ------- * 2,55V 2**16-1 * für range = 1 (0..5,10V) VAL ------- * 5,10V 2**16-1 =Schaltungen= === Beispielschaltung 1=== Hier ein Beispielschaltung für den DS2450. Kanal A wird als Eingabe genutzt (range = 1). Kanal D wird als Ausgabe genutzt, über den Optokoppler kann die LED geschaltet werden. Der Widerstand R1 muss <b>unbedingt</b> entsprechend dem Optokoppler dimensioniert werden. Beim 4N35 sind 1k3 ausreichend, dann fließt ein Strom von ca. 2,8mA. [[File:DS2450 Beispiel 01.gif|600px|Beispielschaltung DS2450]] === Beispielschaltung 2=== Hier die Beispielschaltung 2 für den DS2450. Kanal A/B/C/D wird als Eingang genutzt (Range = 1). * I/O-A wird zb. als Tür oder Fenster Detektor genutzt. * I/O-B wird als Eingang für den Luftfeuchtesensor genutzt. * I/O-C wird als Eingang für den Luftdrucksensor genutzt. * I/O-D wird genutzt um die Versorgungsspannung zu messen welche bei der Berechnung des Luftdrucksensor benötigt wird. <br> Weiters hängt ein DS2450 und ein DS1820 parallel am Bus um noch eine Temperatur über den Bus zu bekommen. * [http://www.ethersex.de/images/5/5c/1W_MPX6115_HIH4000.pdf Schaltung als PDF downloaden] [[File:1W MPX6115 HIH4000.png|600px|Beispielschaltung DS2450]] * Zum Initialisieren verwende ich folgende Kommandos via ecmd zb.: <pre><nowiki> 1w ds2450 power 1 //(drei adrig) 1w ds2450 res c 08 //(00 / 10 = 16bit, 08 8bit) 1w ds2450 oe c 0 //(als eingang stetzen) 1w ds2450 range c 1 //(Range 0-5,10V) 1w ds2450 convert 1w ds2450 get </nowiki></pre> === Berechnungen des Feuchtesensor === // lt. Datenblatt: // OFFSET 0.958062V bei 0%RH // SLOPE: 30.680 mV/%RH $V_Feuchte = ($Humid/65535)*5.17; $RH_Feuchte = ($V_Feuchte - 0.958062) * 34.558; //Werte nach Kalibrierung ( 34.558 Ist bei mir genauer als 30.680) $RHR = $RH_Feuchte / ((1.0305 + (0.000044 * 25) - (0.0000011 * pow(22.6,2)))); echo $RHR; === Berechnungen des Drucksensor === $ADCwert = ($Druck/65535)*5.10; $ADCVBuswert= ($Vdd/65535)*5.10; $kpawert = $ADCwert/($ADCVBuswert*0.009)+10.55; echo $kpawert*10; === Werte des ADC schwanken beim auslesen === Lege doch mal die Versorgungsspannung direkt auf einen Eingang und schaue mal ob der Wert immer noch schwankt. === parse error 05.02.2016 === debug abschalten avr-gcc 472ok 435nok == Einbindung in Control6 (tcp_send) == https://github.com/ethersex/ethersex/blob/master/hardware/onewire/ds2450.h<br> http://www.tutorials.at/c/03-dateneingabe-ausgabe.html<br> <br> '''"ecmd?1w list"''' ergibt den rom code '''20686414000000b5''' für den ds2450<br> <br> <pre><nowiki> C6_HEADER(`/* This will be in control6.h */') #include "hardware/onewire/ds2450.h" uint16_t counter1 = 0; uint16_t var1 = 0; CONTROL_START CLOCK_USED() THREAD(start) var1 = 1; WAIT(5) var1 = 0; WAIT(5) THREAD_END(start) TCP_HANDLER_PERSIST(message_handler); if (var1 == 1){ ow_rom_code_t rom_code; uint16_t result; rom_code.bytewise[0] = 0x20; rom_code.bytewise[1] = 0x68; rom_code.bytewise[2] = 0x64; rom_code.bytewise[3] = 0x14; rom_code.bytewise[4] = 0x00; rom_code.bytewise[5] = 0x00; rom_code.bytewise[6] = 0x00; rom_code.bytewise[7] = 0xb5; ow_ds2450_convert(&rom_code, 0x0f, 0x00); ow_ds2450_get(&rom_code, 2, 2, &result); TCP_SEND("%u", result); WAIT(15) } TCP_HANDLER_END(); ON STARTUP DO THREAD_START(start) TCP_CONNECT(192.168.123.106, 4445, message_handler); END CONTROL_END </nowiki></pre> 0e6f106ca347046351a0bfc7646cd06155dfe40a 1696 1695 2016-02-05T19:54:05Z Djmaster 255 /* POR */ wikitext text/x-wiki {{i18n|Onewire/DS2450}} {{Module |NAME=Onewire DS2450 |MENUCONFIG={{I/O}}->Onewire support |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} *Beitrag am 05.02.2016 erneuert. = Einleitung = Der DS2450 ist ein 4 Kanal ADC mit einer maximalen Auflösung von 16 Bit (vgl. [http://datasheets.maxim-ic.com/en/ds/DS2450.pdf Datenblatt]). Die analog-digital Umwandlung erfolgt durch einen internen four-to-one multiplexer. Kanäle, die nicht als Eingänge genutzt werden, können als Ausgänge (open drain) geschaltet werden (max. 4mA und 6V). Grundsätzlich gilt für alle Befehle: * als erstes Argument kann optional die 64 Bit ROM Id des DS2450 angegeben werden, der angesprochen werden soll (match rom). Wird die ROM Id <b>nicht</b> angeben, so werden alle im Bus befindlichen 1-wire Devices (egal welchen Typs) angesprochen (skip rom). Dies macht <b>nur</b> Sinn, wenn sich <b>genau</b> ein Device im 1-wire Bus befindet (skip rom führt bei mehreren Devices unweigerlich dazu, dass mehrere Devices gleichzeitig antworten werden, was zu Bit-Salat beim bus master (d.h. Ethersex) führt, das Datenblatt spricht von "a wired-AND result"). * wird ein Kanal angeben, so ist dieser mit einem Buchstaben (entsprechend Datenblatt) zu bezeichnen (case-insensitiv). * wird mit einem Befehl ein Wert gesetzt, so kann mit dem gleichen Befehl der Wert gelesen werden, in dem man kein Werte-Argument angibt. == ECMD Befehle == Über ECMD sind folgende Befehle für den DS2450 bekannt: 1w list 1w ds2450 power $id // Sensor id mit "1w list" auslesen 1w ds2450 res 1w ds2450 oc 1w ds2450 oe 1w ds2450 range 1w ds2450 por 1w ds2450 convert 1w ds2450 get ---- === POWER === 1w ds2450 power $id // Parameter auslesen. 1w ds2450 power $id 1 // Beispiel: Der DS2450 wird auf "normale" Spannungsversorgung konfiguriert. Hierüber wird die Art der Spannungsversorgung des DS2450 gesetzt (global). Dieser Parameter wird durch den Anschluss an der 1-wire Bus bestimmt, vgl. die [[Onewire_(Deutsch)#Anschluss_AVR-NET-IO | Erklärung der Anschlussmöglichkeiten]]. Wird der 1-wire Bus "normal" (drei-adrig) betrieben, so muss der Wert auf 1 gesetzt werden. Wird der Bus "parasitär" (zwei-adrig) betrieben, muss der Wert auf 0 gesetzt werden. (Default-Wert: 0) ---- === RES === 1w ds2450 res $id $kanal // Parameter auslesen. 1w ds2450 res $id c 08 // Beispiel: Setzt die Auflösung für Kanal C auf 0x08, d.h. 8 Bit. Hierüber wird die Auflösung der analog-digital Umwandlung gesetzt (pro Kanal). Die Auflösung kann zw. 1 und 16 Bit eingestellt werden. Die Eingabe erfolgt als 8 Bit Hexadezimalwert, wobei eine Auflösung von 16 Bit durch den Wert 0x00 oder alternativ 0x10 erreicht wird. Außerdem ist die Kanal-Bezeichnung anzugeben. (Default-Wert: 0x08) ---- === OC === 1w ds2450 oc $id $kanal // Parameter auslesen. 1w ds2450 oc $id a 1 // Beispiel: Der Ausgangstransistor des Kanal A wird leitend. Hierüber kann der Ausgang ein- oder ausgeschaltet werden (pro Kanal). Voraussetzung ist, dass über [[DS2450#1w_ds2450_oe | 1w ds2450 oe]] der Kanal als Ausgang geschaltet wurde (ansonsten wird das OC-Bit ignoriert). Die Eingabe erfolgt als bool über 0 (Ausgangstransistor leitend) bzw. 1 (Ausgangstransistor nicht-leitend). Außerdem ist die Kanal-Bezeichnung anzugeben. (Default-Wert: 0) ---- === OE === 1w ds2450 oe $id $kanal // Parameter auslesen. 1w ds2450 oe $id d 1 // Beispiel: Kanal A wird als Ausgang gesetzt. Hierüber kann der Kanal als Ein- oder Ausgang gesetzt werden (pro Kanal). Eine analog-digital Umwandlung ist <b>nur</b> möglich, wenn das OE-Bit auf 0 gesetzt ist. In diesem Fall wird das OC-Bit ignoriert. Ist das OE-Bit auf 1 gesetzt, kann der Ausgang über 1w ds2450 oc ein- bzw. ausgeschaltet werden. Die Eingabe erfolgt als bool über 0 (Eingang für ADC) bzw. 1 (Ausgang open drain). Außerdem ist die Kanal-Bezeichnung anzugeben. (Default-Wert: 0) ---- === RANGE === 1w ds2450 range $id $kanal // Parameter auslesen. 1w ds2450 range $id b 1 // Beispiel: Für Kanal B wird bei der A/D Umwandlung der Spannungsbereich 0 bis 5,10V genutzt. Hierüber kann der Spannungs-Bereich angegeben werden, in dem die analog-digital Umwandlung stattfinden soll. Die Eingabe erfolgt als bool über 0 (Spannungsbereich 0 bis 2,55V) bzw. 1 (Spannungsbereich 0 bis 5,10V). Außerdem ist die Kanal-Bezeichnung anzugeben. (Default-Wert: 0) ---- === POR === 1w ds2450 por $id $kanal // Parameter auslesen. 1w ds2450 por $id c 0 // Beispiel: Für Kanal C wird das power on reset Bit auf 0 gesetzt. Hierüber kann das power on reset Bit gelesen bzw. gesetzt werden. Nach einem power-on reset cycle setzt der DS2450 das Bit auf 1. Das Bit beeinflusst die conditional search, welche in Ethersex (noch) nicht implementiert ist. Setzt der bus master das Bit auf 0, so nimmt der DS2450 nicht mehr an der conditional search teil. Die Eingabe erfolgt als bool über 0 bzw. 1. Außerdem ist die Kanal-Bezeichnung anzugeben. (Default-Wert: 1 (nach power-on reset cycle)) <b>FixMe:</b><br> Es sieht so aus, als kann das Bit nur global gesetzt werden, d.h. wird es für einen Kanal verändert, haben danach alle anderen Kanäle den gleich POR-Bit Wert. Außerdem kann man das Bit nicht mehr auf 1 setzen, wenn es vorher schon auf 0 gesetzt wurde (das widerspricht aber dem Datenblatt!). ---- === CONVERT === 1w ds2450 convert $id // Beispiel: Für alle Kanäle wird die analog-digital Umwandlung durchgeführt. Hierüber wird die analog-digital Umwandlung ausgelöst (analog den 1-wire Temperatursensoren). Werden keine weiteren Argumente angegeben, so wird die Umwandlung für alle 4 Kanäle des DS2450 durchgeführt (FixMe: vermutlich werden die Kanäle, bei denen das OE-Bit auf 1 steht ausgelassen, dass ist aber nicht durch Dallas dokumentiert). Optional können zwei Argumente angegeben werden (werden Argumente angegeben, <b>müssen beide</b> Argumente angegeben werden!): * input select mask * read-out control *'''input select mask''' Mit der input select mask kann angegeben werden, für welche Kanäle die analog-digital Umwandlung durchgeführt werden soll. Die input select mask ist ein 8 Bit Hexadezimalwert: {| border=1 cellspacing=0 padding=4 class=wikitable ! bit7 !! bit6 !! bit5 !! bit4 !! bit3 !! bit2 !! bit1 !! bit0 |- | ignore || ignore || ignore || ignore || Kanal D || Kanal C || Kanal B || Kanal A |} Eine input select mask von 0x0f bedeutet also, dass für alle 4 Kanäle die analog-digital Umwandlung durchgeführt werden soll. Eine mask von 0x00 ist (offensichtlich) sinnlos. Eine ungültige input select mask (d.h. input select mask == 0x00 oder > 0x0f) wird erkannt und führt zu einer ECMD-Fehlermeldung. Die analog-digital Umwandlung erfolgt in der Reihenfolge von Kanal A zu Kanal D, wobei die nicht gewünschte Kanäle (sprich jene, wo das input select mask Bit auf 0 steht) übersprungen werden. Der DS2450 braucht für jedes Bit Auflösung ca. 60 bis 80µs. Außerdem braucht das Umwandlung-Kommando generell 160µs (offset) Dies bedeutet, dass eine Umwandlung aller 4 Kanäle bei maximaler 16 Bit Auflösung also nicht länger als 4*16*80+160µs = 5280µs = 5,28ms dauern wird. * '''read out control''' Mit dem read out control kann angegeben werden, ob und wie das Register für die Ergebnisse der analog-digital Umwandlung vorbelegt werden soll. Das macht nur dann Sinn, wenn die Umwandlungsergebnisse schon gelesen werden sollen, während der DS2450 im Hintergrund noch die analog-digital Umwandlung durchführt (was möglich ist). Das read out control ist ein 8 Bit Hexadezimalwert: {| border=1 cellspacing=0 padding=4 class=wikitable ! bit7 !! bit6 !! bit5 !! bit4 !! bit3 !! bit2 !! bit1 !! bit0 |- | Set D || Clear D || Set C || Clear C || Set B || Clear B || Set A || Clear A |} Set bzw. Clear verhalten sich wie folgt: {| border=1 cellspacing=0 padding=4 class=wikitable ! Set !! Clear !! Ergebnis |- | 0 || 0 || keine Veränderung am Umwandlung-Register |- | 0 || 1 || alle Bits des Umwandlung-Register werden auf 0 gesetzt |- | 1 || 0 || alle Bits des Umwandlung-Register werden auf 1 gesetzt |- | 1 || 1 || invalid |} Ungültige Kombinationen im read out control (d.h. Set = 1 und Clear = 1) werden erkannt und führen zu einer ECMD-Fehlermeldung. Default-Werte: * input select mask: 0x04 * read out control: 0x00 ---- === GET === 1w ds2450 get // Beispiel: Die Umwandlungsergebnisse für alle 4 Kanäle werden ausgegeben. Hierüber wird das Ergebnis der analog-digital Umwandlung ausgelesen (analog den 1-wire Temperatursensoren). Werden keine weiteren Argumente angegeben, so werden die Umwandlungsergebnisse für alle 4 Kanäle des DS2450 ausgegeben. Optional kann ein Kanal angegeben werden, dann wird nur das Umwandlungsergebniss dieses Kanals ausgegeben. Wurde seit dem letzten power-on reset cycle keine Umwandlung durchgeführt, stehen alle Bits der Register auf 0. Die Ausgabe erfolgt als raw (unsigned integer 16 Bit - <code>uint16_t</code>). Die eingelesene Spannung errechnet sich wie folgt (VAL ist die Ausgabe von <code>1w ds2450 get</code>): * für range = 0 (0..2,55V) VAL ------- * 2,55V 2**16-1 * für range = 1 (0..5,10V) VAL ------- * 5,10V 2**16-1 =Schaltungen= === Beispielschaltung 1=== Hier ein Beispielschaltung für den DS2450. Kanal A wird als Eingabe genutzt (range = 1). Kanal D wird als Ausgabe genutzt, über den Optokoppler kann die LED geschaltet werden. Der Widerstand R1 muss <b>unbedingt</b> entsprechend dem Optokoppler dimensioniert werden. Beim 4N35 sind 1k3 ausreichend, dann fließt ein Strom von ca. 2,8mA. [[File:DS2450 Beispiel 01.gif|600px|Beispielschaltung DS2450]] === Beispielschaltung 2=== Hier die Beispielschaltung 2 für den DS2450. Kanal A/B/C/D wird als Eingang genutzt (Range = 1). * I/O-A wird zb. als Tür oder Fenster Detektor genutzt. * I/O-B wird als Eingang für den Luftfeuchtesensor genutzt. * I/O-C wird als Eingang für den Luftdrucksensor genutzt. * I/O-D wird genutzt um die Versorgungsspannung zu messen welche bei der Berechnung des Luftdrucksensor benötigt wird. <br> Weiters hängt ein DS2450 und ein DS1820 parallel am Bus um noch eine Temperatur über den Bus zu bekommen. * [http://www.ethersex.de/images/5/5c/1W_MPX6115_HIH4000.pdf Schaltung als PDF downloaden] [[File:1W MPX6115 HIH4000.png|600px|Beispielschaltung DS2450]] * Zum Initialisieren verwende ich folgende Kommandos via ecmd zb.: <pre><nowiki> 1w ds2450 power 1 //(drei adrig) 1w ds2450 res c 08 //(00 / 10 = 16bit, 08 8bit) 1w ds2450 oe c 0 //(als eingang stetzen) 1w ds2450 range c 1 //(Range 0-5,10V) 1w ds2450 convert 1w ds2450 get </nowiki></pre> === Berechnungen des Feuchtesensor === // lt. Datenblatt: // OFFSET 0.958062V bei 0%RH // SLOPE: 30.680 mV/%RH $V_Feuchte = ($Humid/65535)*5.17; $RH_Feuchte = ($V_Feuchte - 0.958062) * 34.558; //Werte nach Kalibrierung ( 34.558 Ist bei mir genauer als 30.680) $RHR = $RH_Feuchte / ((1.0305 + (0.000044 * 25) - (0.0000011 * pow(22.6,2)))); echo $RHR; === Berechnungen des Drucksensor === $ADCwert = ($Druck/65535)*5.10; $ADCVBuswert= ($Vdd/65535)*5.10; $kpawert = $ADCwert/($ADCVBuswert*0.009)+10.55; echo $kpawert*10; === Werte des ADC schwanken beim auslesen === Lege doch mal die Versorgungsspannung direkt auf einen Eingang und schaue mal ob der Wert immer noch schwankt. === parse error 05.02.2016 === debug abschalten avr-gcc 472ok 435nok == Einbindung in Control6 (tcp_send) == https://github.com/ethersex/ethersex/blob/master/hardware/onewire/ds2450.h<br> http://www.tutorials.at/c/03-dateneingabe-ausgabe.html<br> <br> '''"ecmd?1w list"''' ergibt den rom code '''20686414000000b5''' für den ds2450<br> <br> <pre><nowiki> C6_HEADER(`/* This will be in control6.h */') #include "hardware/onewire/ds2450.h" uint16_t counter1 = 0; uint16_t var1 = 0; CONTROL_START CLOCK_USED() THREAD(start) var1 = 1; WAIT(5) var1 = 0; WAIT(5) THREAD_END(start) TCP_HANDLER_PERSIST(message_handler); if (var1 == 1){ ow_rom_code_t rom_code; uint16_t result; rom_code.bytewise[0] = 0x20; rom_code.bytewise[1] = 0x68; rom_code.bytewise[2] = 0x64; rom_code.bytewise[3] = 0x14; rom_code.bytewise[4] = 0x00; rom_code.bytewise[5] = 0x00; rom_code.bytewise[6] = 0x00; rom_code.bytewise[7] = 0xb5; ow_ds2450_convert(&rom_code, 0x0f, 0x00); ow_ds2450_get(&rom_code, 2, 2, &result); TCP_SEND("%u", result); WAIT(15) } TCP_HANDLER_END(); ON STARTUP DO THREAD_START(start) TCP_CONNECT(192.168.123.106, 4445, message_handler); END CONTROL_END </nowiki></pre> cf2f7b1f5c2d19afc4bc30711764c491ee55da7d 1697 1696 2016-02-05T20:00:04Z Djmaster 255 /* GET */ wikitext text/x-wiki {{i18n|Onewire/DS2450}} {{Module |NAME=Onewire DS2450 |MENUCONFIG={{I/O}}->Onewire support |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} *Beitrag am 05.02.2016 erneuert. = Einleitung = Der DS2450 ist ein 4 Kanal ADC mit einer maximalen Auflösung von 16 Bit (vgl. [http://datasheets.maxim-ic.com/en/ds/DS2450.pdf Datenblatt]). Die analog-digital Umwandlung erfolgt durch einen internen four-to-one multiplexer. Kanäle, die nicht als Eingänge genutzt werden, können als Ausgänge (open drain) geschaltet werden (max. 4mA und 6V). Grundsätzlich gilt für alle Befehle: * als erstes Argument kann optional die 64 Bit ROM Id des DS2450 angegeben werden, der angesprochen werden soll (match rom). Wird die ROM Id <b>nicht</b> angeben, so werden alle im Bus befindlichen 1-wire Devices (egal welchen Typs) angesprochen (skip rom). Dies macht <b>nur</b> Sinn, wenn sich <b>genau</b> ein Device im 1-wire Bus befindet (skip rom führt bei mehreren Devices unweigerlich dazu, dass mehrere Devices gleichzeitig antworten werden, was zu Bit-Salat beim bus master (d.h. Ethersex) führt, das Datenblatt spricht von "a wired-AND result"). * wird ein Kanal angeben, so ist dieser mit einem Buchstaben (entsprechend Datenblatt) zu bezeichnen (case-insensitiv). * wird mit einem Befehl ein Wert gesetzt, so kann mit dem gleichen Befehl der Wert gelesen werden, in dem man kein Werte-Argument angibt. == ECMD Befehle == Über ECMD sind folgende Befehle für den DS2450 bekannt: 1w list 1w ds2450 power $id // Sensor id mit "1w list" auslesen 1w ds2450 res 1w ds2450 oc 1w ds2450 oe 1w ds2450 range 1w ds2450 por 1w ds2450 convert 1w ds2450 get ---- === POWER === 1w ds2450 power $id // Parameter auslesen. 1w ds2450 power $id 1 // Beispiel: Der DS2450 wird auf "normale" Spannungsversorgung konfiguriert. Hierüber wird die Art der Spannungsversorgung des DS2450 gesetzt (global). Dieser Parameter wird durch den Anschluss an der 1-wire Bus bestimmt, vgl. die [[Onewire_(Deutsch)#Anschluss_AVR-NET-IO | Erklärung der Anschlussmöglichkeiten]]. Wird der 1-wire Bus "normal" (drei-adrig) betrieben, so muss der Wert auf 1 gesetzt werden. Wird der Bus "parasitär" (zwei-adrig) betrieben, muss der Wert auf 0 gesetzt werden. (Default-Wert: 0) ---- === RES === 1w ds2450 res $id $kanal // Parameter auslesen. 1w ds2450 res $id c 08 // Beispiel: Setzt die Auflösung für Kanal C auf 0x08, d.h. 8 Bit. Hierüber wird die Auflösung der analog-digital Umwandlung gesetzt (pro Kanal). Die Auflösung kann zw. 1 und 16 Bit eingestellt werden. Die Eingabe erfolgt als 8 Bit Hexadezimalwert, wobei eine Auflösung von 16 Bit durch den Wert 0x00 oder alternativ 0x10 erreicht wird. Außerdem ist die Kanal-Bezeichnung anzugeben. (Default-Wert: 0x08) ---- === OC === 1w ds2450 oc $id $kanal // Parameter auslesen. 1w ds2450 oc $id a 1 // Beispiel: Der Ausgangstransistor des Kanal A wird leitend. Hierüber kann der Ausgang ein- oder ausgeschaltet werden (pro Kanal). Voraussetzung ist, dass über [[DS2450#1w_ds2450_oe | 1w ds2450 oe]] der Kanal als Ausgang geschaltet wurde (ansonsten wird das OC-Bit ignoriert). Die Eingabe erfolgt als bool über 0 (Ausgangstransistor leitend) bzw. 1 (Ausgangstransistor nicht-leitend). Außerdem ist die Kanal-Bezeichnung anzugeben. (Default-Wert: 0) ---- === OE === 1w ds2450 oe $id $kanal // Parameter auslesen. 1w ds2450 oe $id d 1 // Beispiel: Kanal A wird als Ausgang gesetzt. Hierüber kann der Kanal als Ein- oder Ausgang gesetzt werden (pro Kanal). Eine analog-digital Umwandlung ist <b>nur</b> möglich, wenn das OE-Bit auf 0 gesetzt ist. In diesem Fall wird das OC-Bit ignoriert. Ist das OE-Bit auf 1 gesetzt, kann der Ausgang über 1w ds2450 oc ein- bzw. ausgeschaltet werden. Die Eingabe erfolgt als bool über 0 (Eingang für ADC) bzw. 1 (Ausgang open drain). Außerdem ist die Kanal-Bezeichnung anzugeben. (Default-Wert: 0) ---- === RANGE === 1w ds2450 range $id $kanal // Parameter auslesen. 1w ds2450 range $id b 1 // Beispiel: Für Kanal B wird bei der A/D Umwandlung der Spannungsbereich 0 bis 5,10V genutzt. Hierüber kann der Spannungs-Bereich angegeben werden, in dem die analog-digital Umwandlung stattfinden soll. Die Eingabe erfolgt als bool über 0 (Spannungsbereich 0 bis 2,55V) bzw. 1 (Spannungsbereich 0 bis 5,10V). Außerdem ist die Kanal-Bezeichnung anzugeben. (Default-Wert: 0) ---- === POR === 1w ds2450 por $id $kanal // Parameter auslesen. 1w ds2450 por $id c 0 // Beispiel: Für Kanal C wird das power on reset Bit auf 0 gesetzt. Hierüber kann das power on reset Bit gelesen bzw. gesetzt werden. Nach einem power-on reset cycle setzt der DS2450 das Bit auf 1. Das Bit beeinflusst die conditional search, welche in Ethersex (noch) nicht implementiert ist. Setzt der bus master das Bit auf 0, so nimmt der DS2450 nicht mehr an der conditional search teil. Die Eingabe erfolgt als bool über 0 bzw. 1. Außerdem ist die Kanal-Bezeichnung anzugeben. (Default-Wert: 1 (nach power-on reset cycle)) <b>FixMe:</b><br> Es sieht so aus, als kann das Bit nur global gesetzt werden, d.h. wird es für einen Kanal verändert, haben danach alle anderen Kanäle den gleich POR-Bit Wert. Außerdem kann man das Bit nicht mehr auf 1 setzen, wenn es vorher schon auf 0 gesetzt wurde (das widerspricht aber dem Datenblatt!). ---- === CONVERT === 1w ds2450 convert $id // Beispiel: Für alle Kanäle wird die analog-digital Umwandlung durchgeführt. Hierüber wird die analog-digital Umwandlung ausgelöst (analog den 1-wire Temperatursensoren). Werden keine weiteren Argumente angegeben, so wird die Umwandlung für alle 4 Kanäle des DS2450 durchgeführt (FixMe: vermutlich werden die Kanäle, bei denen das OE-Bit auf 1 steht ausgelassen, dass ist aber nicht durch Dallas dokumentiert). Optional können zwei Argumente angegeben werden (werden Argumente angegeben, <b>müssen beide</b> Argumente angegeben werden!): * input select mask * read-out control *'''input select mask''' Mit der input select mask kann angegeben werden, für welche Kanäle die analog-digital Umwandlung durchgeführt werden soll. Die input select mask ist ein 8 Bit Hexadezimalwert: {| border=1 cellspacing=0 padding=4 class=wikitable ! bit7 !! bit6 !! bit5 !! bit4 !! bit3 !! bit2 !! bit1 !! bit0 |- | ignore || ignore || ignore || ignore || Kanal D || Kanal C || Kanal B || Kanal A |} Eine input select mask von 0x0f bedeutet also, dass für alle 4 Kanäle die analog-digital Umwandlung durchgeführt werden soll. Eine mask von 0x00 ist (offensichtlich) sinnlos. Eine ungültige input select mask (d.h. input select mask == 0x00 oder > 0x0f) wird erkannt und führt zu einer ECMD-Fehlermeldung. Die analog-digital Umwandlung erfolgt in der Reihenfolge von Kanal A zu Kanal D, wobei die nicht gewünschte Kanäle (sprich jene, wo das input select mask Bit auf 0 steht) übersprungen werden. Der DS2450 braucht für jedes Bit Auflösung ca. 60 bis 80µs. Außerdem braucht das Umwandlung-Kommando generell 160µs (offset) Dies bedeutet, dass eine Umwandlung aller 4 Kanäle bei maximaler 16 Bit Auflösung also nicht länger als 4*16*80+160µs = 5280µs = 5,28ms dauern wird. * '''read out control''' Mit dem read out control kann angegeben werden, ob und wie das Register für die Ergebnisse der analog-digital Umwandlung vorbelegt werden soll. Das macht nur dann Sinn, wenn die Umwandlungsergebnisse schon gelesen werden sollen, während der DS2450 im Hintergrund noch die analog-digital Umwandlung durchführt (was möglich ist). Das read out control ist ein 8 Bit Hexadezimalwert: {| border=1 cellspacing=0 padding=4 class=wikitable ! bit7 !! bit6 !! bit5 !! bit4 !! bit3 !! bit2 !! bit1 !! bit0 |- | Set D || Clear D || Set C || Clear C || Set B || Clear B || Set A || Clear A |} Set bzw. Clear verhalten sich wie folgt: {| border=1 cellspacing=0 padding=4 class=wikitable ! Set !! Clear !! Ergebnis |- | 0 || 0 || keine Veränderung am Umwandlung-Register |- | 0 || 1 || alle Bits des Umwandlung-Register werden auf 0 gesetzt |- | 1 || 0 || alle Bits des Umwandlung-Register werden auf 1 gesetzt |- | 1 || 1 || invalid |} Ungültige Kombinationen im read out control (d.h. Set = 1 und Clear = 1) werden erkannt und führen zu einer ECMD-Fehlermeldung. Default-Werte: * input select mask: 0x04 * read out control: 0x00 ---- === GET === 1w ds2450 get $id // Beispiel: Die Umwandlungsergebnisse für alle 4 Kanäle werden ausgegeben. Hierüber wird das Ergebnis der analog-digital Umwandlung ausgelesen (analog den 1-wire Temperatursensoren). Werden keine weiteren Argumente angegeben, so werden die Umwandlungsergebnisse für alle 4 Kanäle des DS2450 ausgegeben. Optional kann ein Kanal angegeben werden, dann wird nur das Umwandlungsergebniss dieses Kanals ausgegeben. Wurde seit dem letzten power-on reset cycle keine Umwandlung durchgeführt, stehen alle Bits der Register auf 0. Die Ausgabe erfolgt als raw (unsigned integer 16 Bit - <code>uint16_t</code>). Die eingelesene Spannung errechnet sich wie folgt (VAL ist die Ausgabe von <code>1w ds2450 get $id</code>): Für Range = 0 (0,00V - 2,55V) (VAL / 2**16-1)* 2,55V Für Range = 1 (0,00V - 5,10V) (VAL / 2**16-1)* 5,10V =Schaltungen= === Beispielschaltung 1=== Hier ein Beispielschaltung für den DS2450. Kanal A wird als Eingabe genutzt (range = 1). Kanal D wird als Ausgabe genutzt, über den Optokoppler kann die LED geschaltet werden. Der Widerstand R1 muss <b>unbedingt</b> entsprechend dem Optokoppler dimensioniert werden. Beim 4N35 sind 1k3 ausreichend, dann fließt ein Strom von ca. 2,8mA. [[File:DS2450 Beispiel 01.gif|600px|Beispielschaltung DS2450]] === Beispielschaltung 2=== Hier die Beispielschaltung 2 für den DS2450. Kanal A/B/C/D wird als Eingang genutzt (Range = 1). * I/O-A wird zb. als Tür oder Fenster Detektor genutzt. * I/O-B wird als Eingang für den Luftfeuchtesensor genutzt. * I/O-C wird als Eingang für den Luftdrucksensor genutzt. * I/O-D wird genutzt um die Versorgungsspannung zu messen welche bei der Berechnung des Luftdrucksensor benötigt wird. <br> Weiters hängt ein DS2450 und ein DS1820 parallel am Bus um noch eine Temperatur über den Bus zu bekommen. * [http://www.ethersex.de/images/5/5c/1W_MPX6115_HIH4000.pdf Schaltung als PDF downloaden] [[File:1W MPX6115 HIH4000.png|600px|Beispielschaltung DS2450]] * Zum Initialisieren verwende ich folgende Kommandos via ecmd zb.: <pre><nowiki> 1w ds2450 power 1 //(drei adrig) 1w ds2450 res c 08 //(00 / 10 = 16bit, 08 8bit) 1w ds2450 oe c 0 //(als eingang stetzen) 1w ds2450 range c 1 //(Range 0-5,10V) 1w ds2450 convert 1w ds2450 get </nowiki></pre> === Berechnungen des Feuchtesensor === // lt. Datenblatt: // OFFSET 0.958062V bei 0%RH // SLOPE: 30.680 mV/%RH $V_Feuchte = ($Humid/65535)*5.17; $RH_Feuchte = ($V_Feuchte - 0.958062) * 34.558; //Werte nach Kalibrierung ( 34.558 Ist bei mir genauer als 30.680) $RHR = $RH_Feuchte / ((1.0305 + (0.000044 * 25) - (0.0000011 * pow(22.6,2)))); echo $RHR; === Berechnungen des Drucksensor === $ADCwert = ($Druck/65535)*5.10; $ADCVBuswert= ($Vdd/65535)*5.10; $kpawert = $ADCwert/($ADCVBuswert*0.009)+10.55; echo $kpawert*10; === Werte des ADC schwanken beim auslesen === Lege doch mal die Versorgungsspannung direkt auf einen Eingang und schaue mal ob der Wert immer noch schwankt. === parse error 05.02.2016 === debug abschalten avr-gcc 472ok 435nok == Einbindung in Control6 (tcp_send) == https://github.com/ethersex/ethersex/blob/master/hardware/onewire/ds2450.h<br> http://www.tutorials.at/c/03-dateneingabe-ausgabe.html<br> <br> '''"ecmd?1w list"''' ergibt den rom code '''20686414000000b5''' für den ds2450<br> <br> <pre><nowiki> C6_HEADER(`/* This will be in control6.h */') #include "hardware/onewire/ds2450.h" uint16_t counter1 = 0; uint16_t var1 = 0; CONTROL_START CLOCK_USED() THREAD(start) var1 = 1; WAIT(5) var1 = 0; WAIT(5) THREAD_END(start) TCP_HANDLER_PERSIST(message_handler); if (var1 == 1){ ow_rom_code_t rom_code; uint16_t result; rom_code.bytewise[0] = 0x20; rom_code.bytewise[1] = 0x68; rom_code.bytewise[2] = 0x64; rom_code.bytewise[3] = 0x14; rom_code.bytewise[4] = 0x00; rom_code.bytewise[5] = 0x00; rom_code.bytewise[6] = 0x00; rom_code.bytewise[7] = 0xb5; ow_ds2450_convert(&rom_code, 0x0f, 0x00); ow_ds2450_get(&rom_code, 2, 2, &result); TCP_SEND("%u", result); WAIT(15) } TCP_HANDLER_END(); ON STARTUP DO THREAD_START(start) TCP_CONNECT(192.168.123.106, 4445, message_handler); END CONTROL_END </nowiki></pre> ef4adc6a6cc0e3af440e6d927351458f884252ad 1698 1697 2016-02-05T20:01:15Z Djmaster 255 /* parse error 05.02.2016 */ wikitext text/x-wiki {{i18n|Onewire/DS2450}} {{Module |NAME=Onewire DS2450 |MENUCONFIG={{I/O}}->Onewire support |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} *Beitrag am 05.02.2016 erneuert. = Einleitung = Der DS2450 ist ein 4 Kanal ADC mit einer maximalen Auflösung von 16 Bit (vgl. [http://datasheets.maxim-ic.com/en/ds/DS2450.pdf Datenblatt]). Die analog-digital Umwandlung erfolgt durch einen internen four-to-one multiplexer. Kanäle, die nicht als Eingänge genutzt werden, können als Ausgänge (open drain) geschaltet werden (max. 4mA und 6V). Grundsätzlich gilt für alle Befehle: * als erstes Argument kann optional die 64 Bit ROM Id des DS2450 angegeben werden, der angesprochen werden soll (match rom). Wird die ROM Id <b>nicht</b> angeben, so werden alle im Bus befindlichen 1-wire Devices (egal welchen Typs) angesprochen (skip rom). Dies macht <b>nur</b> Sinn, wenn sich <b>genau</b> ein Device im 1-wire Bus befindet (skip rom führt bei mehreren Devices unweigerlich dazu, dass mehrere Devices gleichzeitig antworten werden, was zu Bit-Salat beim bus master (d.h. Ethersex) führt, das Datenblatt spricht von "a wired-AND result"). * wird ein Kanal angeben, so ist dieser mit einem Buchstaben (entsprechend Datenblatt) zu bezeichnen (case-insensitiv). * wird mit einem Befehl ein Wert gesetzt, so kann mit dem gleichen Befehl der Wert gelesen werden, in dem man kein Werte-Argument angibt. == ECMD Befehle == Über ECMD sind folgende Befehle für den DS2450 bekannt: 1w list 1w ds2450 power $id // Sensor id mit "1w list" auslesen 1w ds2450 res 1w ds2450 oc 1w ds2450 oe 1w ds2450 range 1w ds2450 por 1w ds2450 convert 1w ds2450 get ---- === POWER === 1w ds2450 power $id // Parameter auslesen. 1w ds2450 power $id 1 // Beispiel: Der DS2450 wird auf "normale" Spannungsversorgung konfiguriert. Hierüber wird die Art der Spannungsversorgung des DS2450 gesetzt (global). Dieser Parameter wird durch den Anschluss an der 1-wire Bus bestimmt, vgl. die [[Onewire_(Deutsch)#Anschluss_AVR-NET-IO | Erklärung der Anschlussmöglichkeiten]]. Wird der 1-wire Bus "normal" (drei-adrig) betrieben, so muss der Wert auf 1 gesetzt werden. Wird der Bus "parasitär" (zwei-adrig) betrieben, muss der Wert auf 0 gesetzt werden. (Default-Wert: 0) ---- === RES === 1w ds2450 res $id $kanal // Parameter auslesen. 1w ds2450 res $id c 08 // Beispiel: Setzt die Auflösung für Kanal C auf 0x08, d.h. 8 Bit. Hierüber wird die Auflösung der analog-digital Umwandlung gesetzt (pro Kanal). Die Auflösung kann zw. 1 und 16 Bit eingestellt werden. Die Eingabe erfolgt als 8 Bit Hexadezimalwert, wobei eine Auflösung von 16 Bit durch den Wert 0x00 oder alternativ 0x10 erreicht wird. Außerdem ist die Kanal-Bezeichnung anzugeben. (Default-Wert: 0x08) ---- === OC === 1w ds2450 oc $id $kanal // Parameter auslesen. 1w ds2450 oc $id a 1 // Beispiel: Der Ausgangstransistor des Kanal A wird leitend. Hierüber kann der Ausgang ein- oder ausgeschaltet werden (pro Kanal). Voraussetzung ist, dass über [[DS2450#1w_ds2450_oe | 1w ds2450 oe]] der Kanal als Ausgang geschaltet wurde (ansonsten wird das OC-Bit ignoriert). Die Eingabe erfolgt als bool über 0 (Ausgangstransistor leitend) bzw. 1 (Ausgangstransistor nicht-leitend). Außerdem ist die Kanal-Bezeichnung anzugeben. (Default-Wert: 0) ---- === OE === 1w ds2450 oe $id $kanal // Parameter auslesen. 1w ds2450 oe $id d 1 // Beispiel: Kanal A wird als Ausgang gesetzt. Hierüber kann der Kanal als Ein- oder Ausgang gesetzt werden (pro Kanal). Eine analog-digital Umwandlung ist <b>nur</b> möglich, wenn das OE-Bit auf 0 gesetzt ist. In diesem Fall wird das OC-Bit ignoriert. Ist das OE-Bit auf 1 gesetzt, kann der Ausgang über 1w ds2450 oc ein- bzw. ausgeschaltet werden. Die Eingabe erfolgt als bool über 0 (Eingang für ADC) bzw. 1 (Ausgang open drain). Außerdem ist die Kanal-Bezeichnung anzugeben. (Default-Wert: 0) ---- === RANGE === 1w ds2450 range $id $kanal // Parameter auslesen. 1w ds2450 range $id b 1 // Beispiel: Für Kanal B wird bei der A/D Umwandlung der Spannungsbereich 0 bis 5,10V genutzt. Hierüber kann der Spannungs-Bereich angegeben werden, in dem die analog-digital Umwandlung stattfinden soll. Die Eingabe erfolgt als bool über 0 (Spannungsbereich 0 bis 2,55V) bzw. 1 (Spannungsbereich 0 bis 5,10V). Außerdem ist die Kanal-Bezeichnung anzugeben. (Default-Wert: 0) ---- === POR === 1w ds2450 por $id $kanal // Parameter auslesen. 1w ds2450 por $id c 0 // Beispiel: Für Kanal C wird das power on reset Bit auf 0 gesetzt. Hierüber kann das power on reset Bit gelesen bzw. gesetzt werden. Nach einem power-on reset cycle setzt der DS2450 das Bit auf 1. Das Bit beeinflusst die conditional search, welche in Ethersex (noch) nicht implementiert ist. Setzt der bus master das Bit auf 0, so nimmt der DS2450 nicht mehr an der conditional search teil. Die Eingabe erfolgt als bool über 0 bzw. 1. Außerdem ist die Kanal-Bezeichnung anzugeben. (Default-Wert: 1 (nach power-on reset cycle)) <b>FixMe:</b><br> Es sieht so aus, als kann das Bit nur global gesetzt werden, d.h. wird es für einen Kanal verändert, haben danach alle anderen Kanäle den gleich POR-Bit Wert. Außerdem kann man das Bit nicht mehr auf 1 setzen, wenn es vorher schon auf 0 gesetzt wurde (das widerspricht aber dem Datenblatt!). ---- === CONVERT === 1w ds2450 convert $id // Beispiel: Für alle Kanäle wird die analog-digital Umwandlung durchgeführt. Hierüber wird die analog-digital Umwandlung ausgelöst (analog den 1-wire Temperatursensoren). Werden keine weiteren Argumente angegeben, so wird die Umwandlung für alle 4 Kanäle des DS2450 durchgeführt (FixMe: vermutlich werden die Kanäle, bei denen das OE-Bit auf 1 steht ausgelassen, dass ist aber nicht durch Dallas dokumentiert). Optional können zwei Argumente angegeben werden (werden Argumente angegeben, <b>müssen beide</b> Argumente angegeben werden!): * input select mask * read-out control *'''input select mask''' Mit der input select mask kann angegeben werden, für welche Kanäle die analog-digital Umwandlung durchgeführt werden soll. Die input select mask ist ein 8 Bit Hexadezimalwert: {| border=1 cellspacing=0 padding=4 class=wikitable ! bit7 !! bit6 !! bit5 !! bit4 !! bit3 !! bit2 !! bit1 !! bit0 |- | ignore || ignore || ignore || ignore || Kanal D || Kanal C || Kanal B || Kanal A |} Eine input select mask von 0x0f bedeutet also, dass für alle 4 Kanäle die analog-digital Umwandlung durchgeführt werden soll. Eine mask von 0x00 ist (offensichtlich) sinnlos. Eine ungültige input select mask (d.h. input select mask == 0x00 oder > 0x0f) wird erkannt und führt zu einer ECMD-Fehlermeldung. Die analog-digital Umwandlung erfolgt in der Reihenfolge von Kanal A zu Kanal D, wobei die nicht gewünschte Kanäle (sprich jene, wo das input select mask Bit auf 0 steht) übersprungen werden. Der DS2450 braucht für jedes Bit Auflösung ca. 60 bis 80µs. Außerdem braucht das Umwandlung-Kommando generell 160µs (offset) Dies bedeutet, dass eine Umwandlung aller 4 Kanäle bei maximaler 16 Bit Auflösung also nicht länger als 4*16*80+160µs = 5280µs = 5,28ms dauern wird. * '''read out control''' Mit dem read out control kann angegeben werden, ob und wie das Register für die Ergebnisse der analog-digital Umwandlung vorbelegt werden soll. Das macht nur dann Sinn, wenn die Umwandlungsergebnisse schon gelesen werden sollen, während der DS2450 im Hintergrund noch die analog-digital Umwandlung durchführt (was möglich ist). Das read out control ist ein 8 Bit Hexadezimalwert: {| border=1 cellspacing=0 padding=4 class=wikitable ! bit7 !! bit6 !! bit5 !! bit4 !! bit3 !! bit2 !! bit1 !! bit0 |- | Set D || Clear D || Set C || Clear C || Set B || Clear B || Set A || Clear A |} Set bzw. Clear verhalten sich wie folgt: {| border=1 cellspacing=0 padding=4 class=wikitable ! Set !! Clear !! Ergebnis |- | 0 || 0 || keine Veränderung am Umwandlung-Register |- | 0 || 1 || alle Bits des Umwandlung-Register werden auf 0 gesetzt |- | 1 || 0 || alle Bits des Umwandlung-Register werden auf 1 gesetzt |- | 1 || 1 || invalid |} Ungültige Kombinationen im read out control (d.h. Set = 1 und Clear = 1) werden erkannt und führen zu einer ECMD-Fehlermeldung. Default-Werte: * input select mask: 0x04 * read out control: 0x00 ---- === GET === 1w ds2450 get $id // Beispiel: Die Umwandlungsergebnisse für alle 4 Kanäle werden ausgegeben. Hierüber wird das Ergebnis der analog-digital Umwandlung ausgelesen (analog den 1-wire Temperatursensoren). Werden keine weiteren Argumente angegeben, so werden die Umwandlungsergebnisse für alle 4 Kanäle des DS2450 ausgegeben. Optional kann ein Kanal angegeben werden, dann wird nur das Umwandlungsergebniss dieses Kanals ausgegeben. Wurde seit dem letzten power-on reset cycle keine Umwandlung durchgeführt, stehen alle Bits der Register auf 0. Die Ausgabe erfolgt als raw (unsigned integer 16 Bit - <code>uint16_t</code>). Die eingelesene Spannung errechnet sich wie folgt (VAL ist die Ausgabe von <code>1w ds2450 get $id</code>): Für Range = 0 (0,00V - 2,55V) (VAL / 2**16-1)* 2,55V Für Range = 1 (0,00V - 5,10V) (VAL / 2**16-1)* 5,10V =Schaltungen= === Beispielschaltung 1=== Hier ein Beispielschaltung für den DS2450. Kanal A wird als Eingabe genutzt (range = 1). Kanal D wird als Ausgabe genutzt, über den Optokoppler kann die LED geschaltet werden. Der Widerstand R1 muss <b>unbedingt</b> entsprechend dem Optokoppler dimensioniert werden. Beim 4N35 sind 1k3 ausreichend, dann fließt ein Strom von ca. 2,8mA. [[File:DS2450 Beispiel 01.gif|600px|Beispielschaltung DS2450]] === Beispielschaltung 2=== Hier die Beispielschaltung 2 für den DS2450. Kanal A/B/C/D wird als Eingang genutzt (Range = 1). * I/O-A wird zb. als Tür oder Fenster Detektor genutzt. * I/O-B wird als Eingang für den Luftfeuchtesensor genutzt. * I/O-C wird als Eingang für den Luftdrucksensor genutzt. * I/O-D wird genutzt um die Versorgungsspannung zu messen welche bei der Berechnung des Luftdrucksensor benötigt wird. <br> Weiters hängt ein DS2450 und ein DS1820 parallel am Bus um noch eine Temperatur über den Bus zu bekommen. * [http://www.ethersex.de/images/5/5c/1W_MPX6115_HIH4000.pdf Schaltung als PDF downloaden] [[File:1W MPX6115 HIH4000.png|600px|Beispielschaltung DS2450]] * Zum Initialisieren verwende ich folgende Kommandos via ecmd zb.: <pre><nowiki> 1w ds2450 power 1 //(drei adrig) 1w ds2450 res c 08 //(00 / 10 = 16bit, 08 8bit) 1w ds2450 oe c 0 //(als eingang stetzen) 1w ds2450 range c 1 //(Range 0-5,10V) 1w ds2450 convert 1w ds2450 get </nowiki></pre> === Berechnungen des Feuchtesensor === // lt. Datenblatt: // OFFSET 0.958062V bei 0%RH // SLOPE: 30.680 mV/%RH $V_Feuchte = ($Humid/65535)*5.17; $RH_Feuchte = ($V_Feuchte - 0.958062) * 34.558; //Werte nach Kalibrierung ( 34.558 Ist bei mir genauer als 30.680) $RHR = $RH_Feuchte / ((1.0305 + (0.000044 * 25) - (0.0000011 * pow(22.6,2)))); echo $RHR; === Berechnungen des Drucksensor === $ADCwert = ($Druck/65535)*5.10; $ADCVBuswert= ($Vdd/65535)*5.10; $kpawert = $ADCwert/($ADCVBuswert*0.009)+10.55; echo $kpawert*10; === Werte des ADC schwanken beim auslesen === Lege doch mal die Versorgungsspannung direkt auf einen Eingang und schaue mal ob der Wert immer noch schwankt. === parse error 05.02.2016 === debug abschalten avr-gcc >=4.7.2 verwenden == Einbindung in Control6 (tcp_send) == https://github.com/ethersex/ethersex/blob/master/hardware/onewire/ds2450.h<br> http://www.tutorials.at/c/03-dateneingabe-ausgabe.html<br> <br> '''"ecmd?1w list"''' ergibt den rom code '''20686414000000b5''' für den ds2450<br> <br> <pre><nowiki> C6_HEADER(`/* This will be in control6.h */') #include "hardware/onewire/ds2450.h" uint16_t counter1 = 0; uint16_t var1 = 0; CONTROL_START CLOCK_USED() THREAD(start) var1 = 1; WAIT(5) var1 = 0; WAIT(5) THREAD_END(start) TCP_HANDLER_PERSIST(message_handler); if (var1 == 1){ ow_rom_code_t rom_code; uint16_t result; rom_code.bytewise[0] = 0x20; rom_code.bytewise[1] = 0x68; rom_code.bytewise[2] = 0x64; rom_code.bytewise[3] = 0x14; rom_code.bytewise[4] = 0x00; rom_code.bytewise[5] = 0x00; rom_code.bytewise[6] = 0x00; rom_code.bytewise[7] = 0xb5; ow_ds2450_convert(&rom_code, 0x0f, 0x00); ow_ds2450_get(&rom_code, 2, 2, &result); TCP_SEND("%u", result); WAIT(15) } TCP_HANDLER_END(); ON STARTUP DO THREAD_START(start) TCP_CONNECT(192.168.123.106, 4445, message_handler); END CONTROL_END </nowiki></pre> 69198552719f6485bb31e3b4e3fe8558246b429a 1699 1698 2016-02-05T20:02:26Z Djmaster 255 /* Beispielschaltung 2 */ wikitext text/x-wiki {{i18n|Onewire/DS2450}} {{Module |NAME=Onewire DS2450 |MENUCONFIG={{I/O}}->Onewire support |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} *Beitrag am 05.02.2016 erneuert. = Einleitung = Der DS2450 ist ein 4 Kanal ADC mit einer maximalen Auflösung von 16 Bit (vgl. [http://datasheets.maxim-ic.com/en/ds/DS2450.pdf Datenblatt]). Die analog-digital Umwandlung erfolgt durch einen internen four-to-one multiplexer. Kanäle, die nicht als Eingänge genutzt werden, können als Ausgänge (open drain) geschaltet werden (max. 4mA und 6V). Grundsätzlich gilt für alle Befehle: * als erstes Argument kann optional die 64 Bit ROM Id des DS2450 angegeben werden, der angesprochen werden soll (match rom). Wird die ROM Id <b>nicht</b> angeben, so werden alle im Bus befindlichen 1-wire Devices (egal welchen Typs) angesprochen (skip rom). Dies macht <b>nur</b> Sinn, wenn sich <b>genau</b> ein Device im 1-wire Bus befindet (skip rom führt bei mehreren Devices unweigerlich dazu, dass mehrere Devices gleichzeitig antworten werden, was zu Bit-Salat beim bus master (d.h. Ethersex) führt, das Datenblatt spricht von "a wired-AND result"). * wird ein Kanal angeben, so ist dieser mit einem Buchstaben (entsprechend Datenblatt) zu bezeichnen (case-insensitiv). * wird mit einem Befehl ein Wert gesetzt, so kann mit dem gleichen Befehl der Wert gelesen werden, in dem man kein Werte-Argument angibt. == ECMD Befehle == Über ECMD sind folgende Befehle für den DS2450 bekannt: 1w list 1w ds2450 power $id // Sensor id mit "1w list" auslesen 1w ds2450 res 1w ds2450 oc 1w ds2450 oe 1w ds2450 range 1w ds2450 por 1w ds2450 convert 1w ds2450 get ---- === POWER === 1w ds2450 power $id // Parameter auslesen. 1w ds2450 power $id 1 // Beispiel: Der DS2450 wird auf "normale" Spannungsversorgung konfiguriert. Hierüber wird die Art der Spannungsversorgung des DS2450 gesetzt (global). Dieser Parameter wird durch den Anschluss an der 1-wire Bus bestimmt, vgl. die [[Onewire_(Deutsch)#Anschluss_AVR-NET-IO | Erklärung der Anschlussmöglichkeiten]]. Wird der 1-wire Bus "normal" (drei-adrig) betrieben, so muss der Wert auf 1 gesetzt werden. Wird der Bus "parasitär" (zwei-adrig) betrieben, muss der Wert auf 0 gesetzt werden. (Default-Wert: 0) ---- === RES === 1w ds2450 res $id $kanal // Parameter auslesen. 1w ds2450 res $id c 08 // Beispiel: Setzt die Auflösung für Kanal C auf 0x08, d.h. 8 Bit. Hierüber wird die Auflösung der analog-digital Umwandlung gesetzt (pro Kanal). Die Auflösung kann zw. 1 und 16 Bit eingestellt werden. Die Eingabe erfolgt als 8 Bit Hexadezimalwert, wobei eine Auflösung von 16 Bit durch den Wert 0x00 oder alternativ 0x10 erreicht wird. Außerdem ist die Kanal-Bezeichnung anzugeben. (Default-Wert: 0x08) ---- === OC === 1w ds2450 oc $id $kanal // Parameter auslesen. 1w ds2450 oc $id a 1 // Beispiel: Der Ausgangstransistor des Kanal A wird leitend. Hierüber kann der Ausgang ein- oder ausgeschaltet werden (pro Kanal). Voraussetzung ist, dass über [[DS2450#1w_ds2450_oe | 1w ds2450 oe]] der Kanal als Ausgang geschaltet wurde (ansonsten wird das OC-Bit ignoriert). Die Eingabe erfolgt als bool über 0 (Ausgangstransistor leitend) bzw. 1 (Ausgangstransistor nicht-leitend). Außerdem ist die Kanal-Bezeichnung anzugeben. (Default-Wert: 0) ---- === OE === 1w ds2450 oe $id $kanal // Parameter auslesen. 1w ds2450 oe $id d 1 // Beispiel: Kanal A wird als Ausgang gesetzt. Hierüber kann der Kanal als Ein- oder Ausgang gesetzt werden (pro Kanal). Eine analog-digital Umwandlung ist <b>nur</b> möglich, wenn das OE-Bit auf 0 gesetzt ist. In diesem Fall wird das OC-Bit ignoriert. Ist das OE-Bit auf 1 gesetzt, kann der Ausgang über 1w ds2450 oc ein- bzw. ausgeschaltet werden. Die Eingabe erfolgt als bool über 0 (Eingang für ADC) bzw. 1 (Ausgang open drain). Außerdem ist die Kanal-Bezeichnung anzugeben. (Default-Wert: 0) ---- === RANGE === 1w ds2450 range $id $kanal // Parameter auslesen. 1w ds2450 range $id b 1 // Beispiel: Für Kanal B wird bei der A/D Umwandlung der Spannungsbereich 0 bis 5,10V genutzt. Hierüber kann der Spannungs-Bereich angegeben werden, in dem die analog-digital Umwandlung stattfinden soll. Die Eingabe erfolgt als bool über 0 (Spannungsbereich 0 bis 2,55V) bzw. 1 (Spannungsbereich 0 bis 5,10V). Außerdem ist die Kanal-Bezeichnung anzugeben. (Default-Wert: 0) ---- === POR === 1w ds2450 por $id $kanal // Parameter auslesen. 1w ds2450 por $id c 0 // Beispiel: Für Kanal C wird das power on reset Bit auf 0 gesetzt. Hierüber kann das power on reset Bit gelesen bzw. gesetzt werden. Nach einem power-on reset cycle setzt der DS2450 das Bit auf 1. Das Bit beeinflusst die conditional search, welche in Ethersex (noch) nicht implementiert ist. Setzt der bus master das Bit auf 0, so nimmt der DS2450 nicht mehr an der conditional search teil. Die Eingabe erfolgt als bool über 0 bzw. 1. Außerdem ist die Kanal-Bezeichnung anzugeben. (Default-Wert: 1 (nach power-on reset cycle)) <b>FixMe:</b><br> Es sieht so aus, als kann das Bit nur global gesetzt werden, d.h. wird es für einen Kanal verändert, haben danach alle anderen Kanäle den gleich POR-Bit Wert. Außerdem kann man das Bit nicht mehr auf 1 setzen, wenn es vorher schon auf 0 gesetzt wurde (das widerspricht aber dem Datenblatt!). ---- === CONVERT === 1w ds2450 convert $id // Beispiel: Für alle Kanäle wird die analog-digital Umwandlung durchgeführt. Hierüber wird die analog-digital Umwandlung ausgelöst (analog den 1-wire Temperatursensoren). Werden keine weiteren Argumente angegeben, so wird die Umwandlung für alle 4 Kanäle des DS2450 durchgeführt (FixMe: vermutlich werden die Kanäle, bei denen das OE-Bit auf 1 steht ausgelassen, dass ist aber nicht durch Dallas dokumentiert). Optional können zwei Argumente angegeben werden (werden Argumente angegeben, <b>müssen beide</b> Argumente angegeben werden!): * input select mask * read-out control *'''input select mask''' Mit der input select mask kann angegeben werden, für welche Kanäle die analog-digital Umwandlung durchgeführt werden soll. Die input select mask ist ein 8 Bit Hexadezimalwert: {| border=1 cellspacing=0 padding=4 class=wikitable ! bit7 !! bit6 !! bit5 !! bit4 !! bit3 !! bit2 !! bit1 !! bit0 |- | ignore || ignore || ignore || ignore || Kanal D || Kanal C || Kanal B || Kanal A |} Eine input select mask von 0x0f bedeutet also, dass für alle 4 Kanäle die analog-digital Umwandlung durchgeführt werden soll. Eine mask von 0x00 ist (offensichtlich) sinnlos. Eine ungültige input select mask (d.h. input select mask == 0x00 oder > 0x0f) wird erkannt und führt zu einer ECMD-Fehlermeldung. Die analog-digital Umwandlung erfolgt in der Reihenfolge von Kanal A zu Kanal D, wobei die nicht gewünschte Kanäle (sprich jene, wo das input select mask Bit auf 0 steht) übersprungen werden. Der DS2450 braucht für jedes Bit Auflösung ca. 60 bis 80µs. Außerdem braucht das Umwandlung-Kommando generell 160µs (offset) Dies bedeutet, dass eine Umwandlung aller 4 Kanäle bei maximaler 16 Bit Auflösung also nicht länger als 4*16*80+160µs = 5280µs = 5,28ms dauern wird. * '''read out control''' Mit dem read out control kann angegeben werden, ob und wie das Register für die Ergebnisse der analog-digital Umwandlung vorbelegt werden soll. Das macht nur dann Sinn, wenn die Umwandlungsergebnisse schon gelesen werden sollen, während der DS2450 im Hintergrund noch die analog-digital Umwandlung durchführt (was möglich ist). Das read out control ist ein 8 Bit Hexadezimalwert: {| border=1 cellspacing=0 padding=4 class=wikitable ! bit7 !! bit6 !! bit5 !! bit4 !! bit3 !! bit2 !! bit1 !! bit0 |- | Set D || Clear D || Set C || Clear C || Set B || Clear B || Set A || Clear A |} Set bzw. Clear verhalten sich wie folgt: {| border=1 cellspacing=0 padding=4 class=wikitable ! Set !! Clear !! Ergebnis |- | 0 || 0 || keine Veränderung am Umwandlung-Register |- | 0 || 1 || alle Bits des Umwandlung-Register werden auf 0 gesetzt |- | 1 || 0 || alle Bits des Umwandlung-Register werden auf 1 gesetzt |- | 1 || 1 || invalid |} Ungültige Kombinationen im read out control (d.h. Set = 1 und Clear = 1) werden erkannt und führen zu einer ECMD-Fehlermeldung. Default-Werte: * input select mask: 0x04 * read out control: 0x00 ---- === GET === 1w ds2450 get $id // Beispiel: Die Umwandlungsergebnisse für alle 4 Kanäle werden ausgegeben. Hierüber wird das Ergebnis der analog-digital Umwandlung ausgelesen (analog den 1-wire Temperatursensoren). Werden keine weiteren Argumente angegeben, so werden die Umwandlungsergebnisse für alle 4 Kanäle des DS2450 ausgegeben. Optional kann ein Kanal angegeben werden, dann wird nur das Umwandlungsergebniss dieses Kanals ausgegeben. Wurde seit dem letzten power-on reset cycle keine Umwandlung durchgeführt, stehen alle Bits der Register auf 0. Die Ausgabe erfolgt als raw (unsigned integer 16 Bit - <code>uint16_t</code>). Die eingelesene Spannung errechnet sich wie folgt (VAL ist die Ausgabe von <code>1w ds2450 get $id</code>): Für Range = 0 (0,00V - 2,55V) (VAL / 2**16-1)* 2,55V Für Range = 1 (0,00V - 5,10V) (VAL / 2**16-1)* 5,10V =Schaltungen= === Beispielschaltung 1=== Hier ein Beispielschaltung für den DS2450. Kanal A wird als Eingabe genutzt (range = 1). Kanal D wird als Ausgabe genutzt, über den Optokoppler kann die LED geschaltet werden. Der Widerstand R1 muss <b>unbedingt</b> entsprechend dem Optokoppler dimensioniert werden. Beim 4N35 sind 1k3 ausreichend, dann fließt ein Strom von ca. 2,8mA. [[File:DS2450 Beispiel 01.gif|600px|Beispielschaltung DS2450]] === Beispielschaltung 2=== Hier die Beispielschaltung 2 für den DS2450. Kanal A/B/C/D wird als Eingang genutzt (Range = 1). * I/O-A wird zb. als Tür oder Fenster Detektor genutzt. * I/O-B wird als Eingang für den Luftfeuchtesensor genutzt. * I/O-C wird als Eingang für den Luftdrucksensor genutzt. * I/O-D wird genutzt um die Versorgungsspannung zu messen welche bei der Berechnung des Luftdrucksensor benötigt wird. <br> Weiters hängt ein DS2450 und ein DS1820 parallel am Bus um noch eine Temperatur über den Bus zu bekommen. * [http://www.ethersex.de/images/5/5c/1W_MPX6115_HIH4000.pdf Schaltung als PDF downloaden] [[File:1W MPX6115 HIH4000.png|600px|Beispielschaltung DS2450]] * Zum Initialisieren verwende ich folgende Kommandos via ecmd zb.: <pre><nowiki> 1w ds2450 power $id 1 //(drei adrig) 1w ds2450 res $id c 08 //(00 / 10 = 16bit, 08 8bit) 1w ds2450 oe $id c 0 //(als eingang stetzen) 1w ds2450 range $id c 1 //(Range 0-5,10V) 1w ds2450 convert $id 1w ds2450 get $id </nowiki></pre> === Berechnungen des Feuchtesensor === // lt. Datenblatt: // OFFSET 0.958062V bei 0%RH // SLOPE: 30.680 mV/%RH $V_Feuchte = ($Humid/65535)*5.17; $RH_Feuchte = ($V_Feuchte - 0.958062) * 34.558; //Werte nach Kalibrierung ( 34.558 Ist bei mir genauer als 30.680) $RHR = $RH_Feuchte / ((1.0305 + (0.000044 * 25) - (0.0000011 * pow(22.6,2)))); echo $RHR; === Berechnungen des Drucksensor === $ADCwert = ($Druck/65535)*5.10; $ADCVBuswert= ($Vdd/65535)*5.10; $kpawert = $ADCwert/($ADCVBuswert*0.009)+10.55; echo $kpawert*10; === Werte des ADC schwanken beim auslesen === Lege doch mal die Versorgungsspannung direkt auf einen Eingang und schaue mal ob der Wert immer noch schwankt. === parse error 05.02.2016 === debug abschalten avr-gcc >=4.7.2 verwenden == Einbindung in Control6 (tcp_send) == https://github.com/ethersex/ethersex/blob/master/hardware/onewire/ds2450.h<br> http://www.tutorials.at/c/03-dateneingabe-ausgabe.html<br> <br> '''"ecmd?1w list"''' ergibt den rom code '''20686414000000b5''' für den ds2450<br> <br> <pre><nowiki> C6_HEADER(`/* This will be in control6.h */') #include "hardware/onewire/ds2450.h" uint16_t counter1 = 0; uint16_t var1 = 0; CONTROL_START CLOCK_USED() THREAD(start) var1 = 1; WAIT(5) var1 = 0; WAIT(5) THREAD_END(start) TCP_HANDLER_PERSIST(message_handler); if (var1 == 1){ ow_rom_code_t rom_code; uint16_t result; rom_code.bytewise[0] = 0x20; rom_code.bytewise[1] = 0x68; rom_code.bytewise[2] = 0x64; rom_code.bytewise[3] = 0x14; rom_code.bytewise[4] = 0x00; rom_code.bytewise[5] = 0x00; rom_code.bytewise[6] = 0x00; rom_code.bytewise[7] = 0xb5; ow_ds2450_convert(&rom_code, 0x0f, 0x00); ow_ds2450_get(&rom_code, 2, 2, &result); TCP_SEND("%u", result); WAIT(15) } TCP_HANDLER_END(); ON STARTUP DO THREAD_START(start) TCP_CONNECT(192.168.123.106, 4445, message_handler); END CONTROL_END </nowiki></pre> e1cd35d1de3d10c6b458e8ca46098157096fc552 1703 1699 2016-02-05T20:14:27Z Djmaster 255 wikitext text/x-wiki {{i18n|Onewire/DS2450}} {{Module |NAME=Onewire DS2450 |MENUCONFIG={{I/O}}->Onewire support |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} *Beitrag am 05.02.2016 erneuert. = Einleitung = Der DS2450 ist ein 4 Kanal ADC mit einer maximalen Auflösung von 16 Bit (vgl. [http://datasheets.maxim-ic.com/en/ds/DS2450.pdf Datenblatt]). Die analog-digital Umwandlung erfolgt durch einen internen four-to-one multiplexer. Kanäle, die nicht als Eingänge genutzt werden, können als Ausgänge (open drain) geschaltet werden (max. 4mA und 6V). Grundsätzlich gilt für alle Befehle: * als erstes Argument kann optional die 64 Bit ROM Id des DS2450 angegeben werden, der angesprochen werden soll (match rom). Wird die ROM Id <b>nicht</b> angeben, so werden alle im Bus befindlichen 1-wire Devices (egal welchen Typs) angesprochen (skip rom). Dies macht <b>nur</b> Sinn, wenn sich <b>genau</b> ein Device im 1-wire Bus befindet (skip rom führt bei mehreren Devices unweigerlich dazu, dass mehrere Devices gleichzeitig antworten werden, was zu Bit-Salat beim bus master (d.h. Ethersex) führt, das Datenblatt spricht von "a wired-AND result"). * wird ein Kanal angeben, so ist dieser mit einem Buchstaben (entsprechend Datenblatt) zu bezeichnen (case-insensitiv). * wird mit einem Befehl ein Wert gesetzt, so kann mit dem gleichen Befehl der Wert gelesen werden, in dem man kein Werte-Argument angibt. == ECMD Befehle == Über ECMD sind folgende Befehle für den DS2450 bekannt: 1w list 1w ds2450 power $id // Sensor id mit "1w list" auslesen 1w ds2450 res 1w ds2450 oc 1w ds2450 oe 1w ds2450 range 1w ds2450 por 1w ds2450 convert 1w ds2450 get ---- === POWER === 1w ds2450 power $id // Parameter auslesen. 1w ds2450 power $id 1 // Beispiel: Der DS2450 wird auf "normale" Spannungsversorgung konfiguriert. Hierüber wird die Art der Spannungsversorgung des DS2450 gesetzt (global). Dieser Parameter wird durch den Anschluss an der 1-wire Bus bestimmt, vgl. die [[Onewire_(Deutsch)#Anschluss_AVR-NET-IO | Erklärung der Anschlussmöglichkeiten]]. Wird der 1-wire Bus "normal" (drei-adrig) betrieben, so muss der Wert auf 1 gesetzt werden. Wird der Bus "parasitär" (zwei-adrig) betrieben, muss der Wert auf 0 gesetzt werden. (Default-Wert: 0) ---- === RES === 1w ds2450 res $id $kanal // Parameter auslesen. 1w ds2450 res $id c 08 // Beispiel: Setzt die Auflösung für Kanal C auf 0x08, d.h. 8 Bit. Hierüber wird die Auflösung der analog-digital Umwandlung gesetzt (pro Kanal). Die Auflösung kann zw. 1 und 16 Bit eingestellt werden. Die Eingabe erfolgt als 8 Bit Hexadezimalwert, wobei eine Auflösung von 16 Bit durch den Wert 0x00 oder alternativ 0x10 erreicht wird. Außerdem ist die Kanal-Bezeichnung anzugeben. (Default-Wert: 0x08) ---- === OC === 1w ds2450 oc $id $kanal // Parameter auslesen. 1w ds2450 oc $id a 1 // Beispiel: Der Ausgangstransistor des Kanal A wird leitend. Hierüber kann der Ausgang ein- oder ausgeschaltet werden (pro Kanal). Voraussetzung ist, dass über [[DS2450#1w_ds2450_oe | 1w ds2450 oe]] der Kanal als Ausgang geschaltet wurde (ansonsten wird das OC-Bit ignoriert). Die Eingabe erfolgt als bool über 0 (Ausgangstransistor leitend) bzw. 1 (Ausgangstransistor nicht-leitend). Außerdem ist die Kanal-Bezeichnung anzugeben. (Default-Wert: 0) ---- === OE === 1w ds2450 oe $id $kanal // Parameter auslesen. 1w ds2450 oe $id d 1 // Beispiel: Kanal A wird als Ausgang gesetzt. Hierüber kann der Kanal als Ein- oder Ausgang gesetzt werden (pro Kanal). Eine analog-digital Umwandlung ist <b>nur</b> möglich, wenn das OE-Bit auf 0 gesetzt ist. In diesem Fall wird das OC-Bit ignoriert. Ist das OE-Bit auf 1 gesetzt, kann der Ausgang über 1w ds2450 oc ein- bzw. ausgeschaltet werden. Die Eingabe erfolgt als bool über 0 (Eingang für ADC) bzw. 1 (Ausgang open drain). Außerdem ist die Kanal-Bezeichnung anzugeben. (Default-Wert: 0) ---- === RANGE === 1w ds2450 range $id $kanal // Parameter auslesen. 1w ds2450 range $id b 1 // Beispiel: Für Kanal B wird bei der A/D Umwandlung der Spannungsbereich 0 bis 5,10V genutzt. Hierüber kann der Spannungs-Bereich angegeben werden, in dem die analog-digital Umwandlung stattfinden soll. Die Eingabe erfolgt als bool über 0 (Spannungsbereich 0 bis 2,55V) bzw. 1 (Spannungsbereich 0 bis 5,10V). Außerdem ist die Kanal-Bezeichnung anzugeben. (Default-Wert: 0) ---- === POR === 1w ds2450 por $id $kanal // Parameter auslesen. 1w ds2450 por $id c 0 // Beispiel: Für Kanal C wird das power on reset Bit auf 0 gesetzt. Hierüber kann das power on reset Bit gelesen bzw. gesetzt werden. Nach einem power-on reset cycle setzt der DS2450 das Bit auf 1. Das Bit beeinflusst die conditional search, welche in Ethersex (noch) nicht implementiert ist. Setzt der bus master das Bit auf 0, so nimmt der DS2450 nicht mehr an der conditional search teil. Die Eingabe erfolgt als bool über 0 bzw. 1. Außerdem ist die Kanal-Bezeichnung anzugeben. (Default-Wert: 1 (nach power-on reset cycle)) <b>FixMe:</b><br> Es sieht so aus, als kann das Bit nur global gesetzt werden, d.h. wird es für einen Kanal verändert, haben danach alle anderen Kanäle den gleich POR-Bit Wert. Außerdem kann man das Bit nicht mehr auf 1 setzen, wenn es vorher schon auf 0 gesetzt wurde (das widerspricht aber dem Datenblatt!). ---- === CONVERT === 1w ds2450 convert $id // Beispiel: Für alle Kanäle wird die analog-digital Umwandlung durchgeführt. Hierüber wird die analog-digital Umwandlung ausgelöst (analog den 1-wire Temperatursensoren). Werden keine weiteren Argumente angegeben, so wird die Umwandlung für alle 4 Kanäle des DS2450 durchgeführt (FixMe: vermutlich werden die Kanäle, bei denen das OE-Bit auf 1 steht ausgelassen, dass ist aber nicht durch Dallas dokumentiert). Optional können zwei Argumente angegeben werden (werden Argumente angegeben, <b>müssen beide</b> Argumente angegeben werden!): * input select mask * read-out control *'''input select mask''' Mit der input select mask kann angegeben werden, für welche Kanäle die analog-digital Umwandlung durchgeführt werden soll. Die input select mask ist ein 8 Bit Hexadezimalwert: {| border=1 cellspacing=0 padding=4 class=wikitable ! bit7 !! bit6 !! bit5 !! bit4 !! bit3 !! bit2 !! bit1 !! bit0 |- | ignore || ignore || ignore || ignore || Kanal D || Kanal C || Kanal B || Kanal A |} Eine input select mask von 0x0f bedeutet also, dass für alle 4 Kanäle die analog-digital Umwandlung durchgeführt werden soll. Eine mask von 0x00 ist (offensichtlich) sinnlos. Eine ungültige input select mask (d.h. input select mask == 0x00 oder > 0x0f) wird erkannt und führt zu einer ECMD-Fehlermeldung. Die analog-digital Umwandlung erfolgt in der Reihenfolge von Kanal A zu Kanal D, wobei die nicht gewünschte Kanäle (sprich jene, wo das input select mask Bit auf 0 steht) übersprungen werden. Der DS2450 braucht für jedes Bit Auflösung ca. 60 bis 80µs. Außerdem braucht das Umwandlung-Kommando generell 160µs (offset) Dies bedeutet, dass eine Umwandlung aller 4 Kanäle bei maximaler 16 Bit Auflösung also nicht länger als 4*16*80+160µs = 5280µs = 5,28ms dauern wird. * '''read out control''' Mit dem read out control kann angegeben werden, ob und wie das Register für die Ergebnisse der analog-digital Umwandlung vorbelegt werden soll. Das macht nur dann Sinn, wenn die Umwandlungsergebnisse schon gelesen werden sollen, während der DS2450 im Hintergrund noch die analog-digital Umwandlung durchführt (was möglich ist). Das read out control ist ein 8 Bit Hexadezimalwert: {| border=1 cellspacing=0 padding=4 class=wikitable ! bit7 !! bit6 !! bit5 !! bit4 !! bit3 !! bit2 !! bit1 !! bit0 |- | Set D || Clear D || Set C || Clear C || Set B || Clear B || Set A || Clear A |} Set bzw. Clear verhalten sich wie folgt: {| border=1 cellspacing=0 padding=4 class=wikitable ! Set !! Clear !! Ergebnis |- | 0 || 0 || keine Veränderung am Umwandlung-Register |- | 0 || 1 || alle Bits des Umwandlung-Register werden auf 0 gesetzt |- | 1 || 0 || alle Bits des Umwandlung-Register werden auf 1 gesetzt |- | 1 || 1 || invalid |} Ungültige Kombinationen im read out control (d.h. Set = 1 und Clear = 1) werden erkannt und führen zu einer ECMD-Fehlermeldung. Default-Werte: * input select mask: 0x04 * read out control: 0x00 ---- === GET === 1w ds2450 get $id // Beispiel: Die Umwandlungsergebnisse für alle 4 Kanäle werden ausgegeben. Hierüber wird das Ergebnis der analog-digital Umwandlung ausgelesen (analog den 1-wire Temperatursensoren). Werden keine weiteren Argumente angegeben, so werden die Umwandlungsergebnisse für alle 4 Kanäle des DS2450 ausgegeben. Optional kann ein Kanal angegeben werden, dann wird nur das Umwandlungsergebniss dieses Kanals ausgegeben. Wurde seit dem letzten power-on reset cycle keine Umwandlung durchgeführt, stehen alle Bits der Register auf 0. Die Ausgabe erfolgt als raw (unsigned integer 16 Bit - <code>uint16_t</code>). Die eingelesene Spannung errechnet sich wie folgt (VAL ist die Ausgabe von <code>1w ds2450 get $id</code>): Für Range = 0 (0,00V - 2,55V) (VAL / 2**16-1)* 2,55V Für Range = 1 (0,00V - 5,10V) (VAL / 2**16-1)* 5,10V =Schaltungen= === Beispielschaltung 1=== Hier ein Beispielschaltung für den DS2450. Kanal A wird als Eingabe genutzt (range = 1). Kanal D wird als Ausgabe genutzt, über den Optokoppler kann die LED geschaltet werden. Der Widerstand R1 muss <b>unbedingt</b> entsprechend dem Optokoppler dimensioniert werden. Beim 4N35 sind 1k3 ausreichend, dann fließt ein Strom von ca. 2,8mA. [[File:DS2450 Beispiel 01.gif|600px|Beispielschaltung DS2450]] === Beispielschaltung 2=== Hier die Beispielschaltung 2 für den DS2450. Kanal A/B/C/D wird als Eingang genutzt (Range = 1). * I/O-A wird zb. als Tür oder Fenster Detektor genutzt. * I/O-B wird als Eingang für den Luftfeuchtesensor genutzt. * I/O-C wird als Eingang für den Luftdrucksensor genutzt. * I/O-D wird genutzt um die Versorgungsspannung zu messen welche bei der Berechnung des Luftdrucksensor benötigt wird. <br> Weiters hängt ein DS2450 und ein DS1820 parallel am Bus um noch eine Temperatur über den Bus zu bekommen. * [http://www.ethersex.de/images/5/5c/1W_MPX6115_HIH4000.pdf Schaltung als PDF downloaden] [[File:1W MPX6115 HIH4000.png|600px|Beispielschaltung DS2450]] * Zum Initialisieren verwende ich folgende Kommandos via ecmd zb.: <pre><nowiki> 1w ds2450 power $id 1 //(drei adrig) 1w ds2450 res $id c 08 //(00 / 10 = 16bit, 08 8bit) 1w ds2450 oe $id c 0 //(als eingang stetzen) 1w ds2450 range $id c 1 //(Range 0-5,10V) 1w ds2450 convert $id 1w ds2450 get $id </nowiki></pre> =Berechnung in PHP= == Berechnungen des Feuchtesensor == // lt. Datenblatt: // OFFSET 0.958062V bei 0%RH // SLOPE: 30.680 mV/%RH $V_Feuchte = ($Humid/65535)*5.17; $RH_Feuchte = ($V_Feuchte - 0.958062) * 34.558; //Werte nach Kalibrierung ( 34.558 Ist bei mir genauer als 30.680) $RHR = $RH_Feuchte / ((1.0305 + (0.000044 * 25) - (0.0000011 * pow(22.6,2)))); echo $RHR; == Berechnungen des Drucksensor == $ADCwert = ($Druck/65535)*5.10; $ADCVBuswert= ($Vdd/65535)*5.10; $kpawert = $ADCwert/($ADCVBuswert*0.009)+10.55; echo $kpawert*10; =Probleme= === Werte des ADC schwanken beim auslesen === Lege doch mal die Versorgungsspannung direkt auf einen Eingang und schaue mal ob der Wert immer noch schwankt. === parse error 05.02.2016 === debug abschalten avr-gcc >=4.7.2 verwenden =c6= === Einbindung in Control6 (tcp_send) === '''TODO: Code testen, ur alt.<b'''r> https://github.com/ethersex/ethersex/blob/master/hardware/onewire/ds2450.h<br> http://www.tutorials.at/c/03-dateneingabe-ausgabe.html<br> <br> '''"ecmd?1w list"''' ergibt den rom code '''20686414000000b5''' für den ds2450<br> <br> <pre><nowiki> C6_HEADER(`/* This will be in control6.h */') #include "hardware/onewire/ds2450.h" uint16_t counter1 = 0; uint16_t var1 = 0; CONTROL_START CLOCK_USED() THREAD(start) var1 = 1; WAIT(5) var1 = 0; WAIT(5) THREAD_END(start) TCP_HANDLER_PERSIST(message_handler); if (var1 == 1){ ow_rom_code_t rom_code; uint16_t result; rom_code.bytewise[0] = 0x20; rom_code.bytewise[1] = 0x68; rom_code.bytewise[2] = 0x64; rom_code.bytewise[3] = 0x14; rom_code.bytewise[4] = 0x00; rom_code.bytewise[5] = 0x00; rom_code.bytewise[6] = 0x00; rom_code.bytewise[7] = 0xb5; ow_ds2450_convert(&rom_code, 0x0f, 0x00); ow_ds2450_get(&rom_code, 2, 2, &result); TCP_SEND("%u", result); WAIT(15) } TCP_HANDLER_END(); ON STARTUP DO THREAD_START(start) TCP_CONNECT(192.168.123.106, 4445, message_handler); END CONTROL_END </nowiki></pre> 244b0f58a2a1f8742aa04df5058636ce1c45d429 1704 1703 2016-02-05T20:15:42Z Djmaster 255 im allg. die Befehle angepasst. wikitext text/x-wiki {{i18n|Onewire/DS2450}} {{Module |NAME=Onewire DS2450 |MENUCONFIG={{I/O}}->Onewire support |STATUS={{In_Development}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/onewire] }} *Beitrag am 05.02.2016 erneuert. = Einleitung = Der DS2450 ist ein 4 Kanal ADC mit einer maximalen Auflösung von 16 Bit (vgl. [http://datasheets.maxim-ic.com/en/ds/DS2450.pdf Datenblatt]). Die analog-digital Umwandlung erfolgt durch einen internen four-to-one multiplexer. Kanäle, die nicht als Eingänge genutzt werden, können als Ausgänge (open drain) geschaltet werden (max. 4mA und 6V). Grundsätzlich gilt für alle Befehle: * als erstes Argument kann optional die 64 Bit ROM Id des DS2450 angegeben werden, der angesprochen werden soll (match rom). Wird die ROM Id <b>nicht</b> angeben, so werden alle im Bus befindlichen 1-wire Devices (egal welchen Typs) angesprochen (skip rom). Dies macht <b>nur</b> Sinn, wenn sich <b>genau</b> ein Device im 1-wire Bus befindet (skip rom führt bei mehreren Devices unweigerlich dazu, dass mehrere Devices gleichzeitig antworten werden, was zu Bit-Salat beim bus master (d.h. Ethersex) führt, das Datenblatt spricht von "a wired-AND result"). * wird ein Kanal angeben, so ist dieser mit einem Buchstaben (entsprechend Datenblatt) zu bezeichnen (case-insensitiv). * wird mit einem Befehl ein Wert gesetzt, so kann mit dem gleichen Befehl der Wert gelesen werden, in dem man kein Werte-Argument angibt. == ECMD Befehle == Über ECMD sind folgende Befehle für den DS2450 bekannt: 1w list 1w ds2450 power $id // Sensor id mit "1w list" auslesen 1w ds2450 res 1w ds2450 oc 1w ds2450 oe 1w ds2450 range 1w ds2450 por 1w ds2450 convert 1w ds2450 get ---- === POWER === 1w ds2450 power $id // Parameter auslesen. 1w ds2450 power $id 1 // Beispiel: Der DS2450 wird auf "normale" Spannungsversorgung konfiguriert. Hierüber wird die Art der Spannungsversorgung des DS2450 gesetzt (global). Dieser Parameter wird durch den Anschluss an der 1-wire Bus bestimmt, vgl. die [[Onewire_(Deutsch)#Anschluss_AVR-NET-IO | Erklärung der Anschlussmöglichkeiten]]. Wird der 1-wire Bus "normal" (drei-adrig) betrieben, so muss der Wert auf 1 gesetzt werden. Wird der Bus "parasitär" (zwei-adrig) betrieben, muss der Wert auf 0 gesetzt werden. (Default-Wert: 0) ---- === RES === 1w ds2450 res $id $kanal // Parameter auslesen. 1w ds2450 res $id c 08 // Beispiel: Setzt die Auflösung für Kanal C auf 0x08, d.h. 8 Bit. Hierüber wird die Auflösung der analog-digital Umwandlung gesetzt (pro Kanal). Die Auflösung kann zw. 1 und 16 Bit eingestellt werden. Die Eingabe erfolgt als 8 Bit Hexadezimalwert, wobei eine Auflösung von 16 Bit durch den Wert 0x00 oder alternativ 0x10 erreicht wird. Außerdem ist die Kanal-Bezeichnung anzugeben. (Default-Wert: 0x08) ---- === OC === 1w ds2450 oc $id $kanal // Parameter auslesen. 1w ds2450 oc $id a 1 // Beispiel: Der Ausgangstransistor des Kanal A wird leitend. Hierüber kann der Ausgang ein- oder ausgeschaltet werden (pro Kanal). Voraussetzung ist, dass über [[DS2450#1w_ds2450_oe | 1w ds2450 oe]] der Kanal als Ausgang geschaltet wurde (ansonsten wird das OC-Bit ignoriert). Die Eingabe erfolgt als bool über 0 (Ausgangstransistor leitend) bzw. 1 (Ausgangstransistor nicht-leitend). Außerdem ist die Kanal-Bezeichnung anzugeben. (Default-Wert: 0) ---- === OE === 1w ds2450 oe $id $kanal // Parameter auslesen. 1w ds2450 oe $id d 1 // Beispiel: Kanal A wird als Ausgang gesetzt. Hierüber kann der Kanal als Ein- oder Ausgang gesetzt werden (pro Kanal). Eine analog-digital Umwandlung ist <b>nur</b> möglich, wenn das OE-Bit auf 0 gesetzt ist. In diesem Fall wird das OC-Bit ignoriert. Ist das OE-Bit auf 1 gesetzt, kann der Ausgang über 1w ds2450 oc ein- bzw. ausgeschaltet werden. Die Eingabe erfolgt als bool über 0 (Eingang für ADC) bzw. 1 (Ausgang open drain). Außerdem ist die Kanal-Bezeichnung anzugeben. (Default-Wert: 0) ---- === RANGE === 1w ds2450 range $id $kanal // Parameter auslesen. 1w ds2450 range $id b 1 // Beispiel: Für Kanal B wird bei der A/D Umwandlung der Spannungsbereich 0 bis 5,10V genutzt. Hierüber kann der Spannungs-Bereich angegeben werden, in dem die analog-digital Umwandlung stattfinden soll. Die Eingabe erfolgt als bool über 0 (Spannungsbereich 0 bis 2,55V) bzw. 1 (Spannungsbereich 0 bis 5,10V). Außerdem ist die Kanal-Bezeichnung anzugeben. (Default-Wert: 0) ---- === POR === 1w ds2450 por $id $kanal // Parameter auslesen. 1w ds2450 por $id c 0 // Beispiel: Für Kanal C wird das power on reset Bit auf 0 gesetzt. Hierüber kann das power on reset Bit gelesen bzw. gesetzt werden. Nach einem power-on reset cycle setzt der DS2450 das Bit auf 1. Das Bit beeinflusst die conditional search, welche in Ethersex (noch) nicht implementiert ist. Setzt der bus master das Bit auf 0, so nimmt der DS2450 nicht mehr an der conditional search teil. Die Eingabe erfolgt als bool über 0 bzw. 1. Außerdem ist die Kanal-Bezeichnung anzugeben. (Default-Wert: 1 (nach power-on reset cycle)) <b>FixMe:</b><br> Es sieht so aus, als kann das Bit nur global gesetzt werden, d.h. wird es für einen Kanal verändert, haben danach alle anderen Kanäle den gleich POR-Bit Wert. Außerdem kann man das Bit nicht mehr auf 1 setzen, wenn es vorher schon auf 0 gesetzt wurde (das widerspricht aber dem Datenblatt!). ---- === CONVERT === 1w ds2450 convert $id // Beispiel: Für alle Kanäle wird die analog-digital Umwandlung durchgeführt. Hierüber wird die analog-digital Umwandlung ausgelöst (analog den 1-wire Temperatursensoren). Werden keine weiteren Argumente angegeben, so wird die Umwandlung für alle 4 Kanäle des DS2450 durchgeführt (FixMe: vermutlich werden die Kanäle, bei denen das OE-Bit auf 1 steht ausgelassen, dass ist aber nicht durch Dallas dokumentiert). Optional können zwei Argumente angegeben werden (werden Argumente angegeben, <b>müssen beide</b> Argumente angegeben werden!): * input select mask * read-out control *'''input select mask''' Mit der input select mask kann angegeben werden, für welche Kanäle die analog-digital Umwandlung durchgeführt werden soll. Die input select mask ist ein 8 Bit Hexadezimalwert: {| border=1 cellspacing=0 padding=4 class=wikitable ! bit7 !! bit6 !! bit5 !! bit4 !! bit3 !! bit2 !! bit1 !! bit0 |- | ignore || ignore || ignore || ignore || Kanal D || Kanal C || Kanal B || Kanal A |} Eine input select mask von 0x0f bedeutet also, dass für alle 4 Kanäle die analog-digital Umwandlung durchgeführt werden soll. Eine mask von 0x00 ist (offensichtlich) sinnlos. Eine ungültige input select mask (d.h. input select mask == 0x00 oder > 0x0f) wird erkannt und führt zu einer ECMD-Fehlermeldung. Die analog-digital Umwandlung erfolgt in der Reihenfolge von Kanal A zu Kanal D, wobei die nicht gewünschte Kanäle (sprich jene, wo das input select mask Bit auf 0 steht) übersprungen werden. Der DS2450 braucht für jedes Bit Auflösung ca. 60 bis 80µs. Außerdem braucht das Umwandlung-Kommando generell 160µs (offset) Dies bedeutet, dass eine Umwandlung aller 4 Kanäle bei maximaler 16 Bit Auflösung also nicht länger als 4*16*80+160µs = 5280µs = 5,28ms dauern wird. * '''read out control''' Mit dem read out control kann angegeben werden, ob und wie das Register für die Ergebnisse der analog-digital Umwandlung vorbelegt werden soll. Das macht nur dann Sinn, wenn die Umwandlungsergebnisse schon gelesen werden sollen, während der DS2450 im Hintergrund noch die analog-digital Umwandlung durchführt (was möglich ist). Das read out control ist ein 8 Bit Hexadezimalwert: {| border=1 cellspacing=0 padding=4 class=wikitable ! bit7 !! bit6 !! bit5 !! bit4 !! bit3 !! bit2 !! bit1 !! bit0 |- | Set D || Clear D || Set C || Clear C || Set B || Clear B || Set A || Clear A |} Set bzw. Clear verhalten sich wie folgt: {| border=1 cellspacing=0 padding=4 class=wikitable ! Set !! Clear !! Ergebnis |- | 0 || 0 || keine Veränderung am Umwandlung-Register |- | 0 || 1 || alle Bits des Umwandlung-Register werden auf 0 gesetzt |- | 1 || 0 || alle Bits des Umwandlung-Register werden auf 1 gesetzt |- | 1 || 1 || invalid |} Ungültige Kombinationen im read out control (d.h. Set = 1 und Clear = 1) werden erkannt und führen zu einer ECMD-Fehlermeldung. Default-Werte: * input select mask: 0x04 * read out control: 0x00 ---- === GET === 1w ds2450 get $id // Beispiel: Die Umwandlungsergebnisse für alle 4 Kanäle werden ausgegeben. Hierüber wird das Ergebnis der analog-digital Umwandlung ausgelesen (analog den 1-wire Temperatursensoren). Werden keine weiteren Argumente angegeben, so werden die Umwandlungsergebnisse für alle 4 Kanäle des DS2450 ausgegeben. Optional kann ein Kanal angegeben werden, dann wird nur das Umwandlungsergebniss dieses Kanals ausgegeben. Wurde seit dem letzten power-on reset cycle keine Umwandlung durchgeführt, stehen alle Bits der Register auf 0. Die Ausgabe erfolgt als raw (unsigned integer 16 Bit - <code>uint16_t</code>). Die eingelesene Spannung errechnet sich wie folgt (VAL ist die Ausgabe von <code>1w ds2450 get $id</code>): Für Range = 0 (0,00V - 2,55V) (VAL / 2**16-1)* 2,55V Für Range = 1 (0,00V - 5,10V) (VAL / 2**16-1)* 5,10V =Schaltungen= === Beispielschaltung 1=== Hier ein Beispielschaltung für den DS2450. Kanal A wird als Eingabe genutzt (range = 1). Kanal D wird als Ausgabe genutzt, über den Optokoppler kann die LED geschaltet werden. Der Widerstand R1 muss <b>unbedingt</b> entsprechend dem Optokoppler dimensioniert werden. Beim 4N35 sind 1k3 ausreichend, dann fließt ein Strom von ca. 2,8mA. [[File:DS2450 Beispiel 01.gif|600px|Beispielschaltung DS2450]] === Beispielschaltung 2=== Hier die Beispielschaltung 2 für den DS2450. Kanal A/B/C/D wird als Eingang genutzt (Range = 1). * I/O-A wird zb. als Tür oder Fenster Detektor genutzt. * I/O-B wird als Eingang für den Luftfeuchtesensor genutzt. * I/O-C wird als Eingang für den Luftdrucksensor genutzt. * I/O-D wird genutzt um die Versorgungsspannung zu messen welche bei der Berechnung des Luftdrucksensor benötigt wird. <br> Weiters hängt ein DS2450 und ein DS1820 parallel am Bus um noch eine Temperatur über den Bus zu bekommen. * [http://www.ethersex.de/images/5/5c/1W_MPX6115_HIH4000.pdf Schaltung als PDF downloaden] [[File:1W MPX6115 HIH4000.png|600px|Beispielschaltung DS2450]] * Zum Initialisieren verwende ich folgende Kommandos via ecmd zb.: <pre><nowiki> 1w ds2450 power $id 1 //(drei adrig) 1w ds2450 res $id c 08 //(00 / 10 = 16bit, 08 8bit) 1w ds2450 oe $id c 0 //(als eingang stetzen) 1w ds2450 range $id c 1 //(Range 0-5,10V) 1w ds2450 convert $id 1w ds2450 get $id </nowiki></pre> =Berechnung in PHP= == Berechnungen des Feuchtesensor == // lt. Datenblatt: // OFFSET 0.958062V bei 0%RH // SLOPE: 30.680 mV/%RH $V_Feuchte = ($Humid/65535)*5.17; $RH_Feuchte = ($V_Feuchte - 0.958062) * 34.558; //Werte nach Kalibrierung ( 34.558 Ist bei mir genauer als 30.680) $RHR = $RH_Feuchte / ((1.0305 + (0.000044 * 25) - (0.0000011 * pow(22.6,2)))); echo $RHR; == Berechnungen des Drucksensor == $ADCwert = ($Druck/65535)*5.10; $ADCVBuswert= ($Vdd/65535)*5.10; $kpawert = $ADCwert/($ADCVBuswert*0.009)+10.55; echo $kpawert*10; =Probleme= === Werte des ADC schwanken beim auslesen === Lege doch mal die Versorgungsspannung direkt auf einen Eingang und schaue mal ob der Wert immer noch schwankt. === parse error 05.02.2016 === debug abschalten avr-gcc >=4.7.2 verwenden =c6= === Einbindung in Control6 (tcp_send) === '''TODO: Code testen, ur alt.'''<br> https://github.com/ethersex/ethersex/blob/master/hardware/onewire/ds2450.h<br> http://www.tutorials.at/c/03-dateneingabe-ausgabe.html<br> <br> '''"ecmd?1w list"''' ergibt den rom code '''20686414000000b5''' für den ds2450<br> <br> <pre><nowiki> C6_HEADER(`/* This will be in control6.h */') #include "hardware/onewire/ds2450.h" uint16_t counter1 = 0; uint16_t var1 = 0; CONTROL_START CLOCK_USED() THREAD(start) var1 = 1; WAIT(5) var1 = 0; WAIT(5) THREAD_END(start) TCP_HANDLER_PERSIST(message_handler); if (var1 == 1){ ow_rom_code_t rom_code; uint16_t result; rom_code.bytewise[0] = 0x20; rom_code.bytewise[1] = 0x68; rom_code.bytewise[2] = 0x64; rom_code.bytewise[3] = 0x14; rom_code.bytewise[4] = 0x00; rom_code.bytewise[5] = 0x00; rom_code.bytewise[6] = 0x00; rom_code.bytewise[7] = 0xb5; ow_ds2450_convert(&rom_code, 0x0f, 0x00); ow_ds2450_get(&rom_code, 2, 2, &result); TCP_SEND("%u", result); WAIT(15) } TCP_HANDLER_END(); ON STARTUP DO THREAD_START(start) TCP_CONNECT(192.168.123.106, 4445, message_handler); END CONTROL_END </nowiki></pre> 5672275b24c15ce625411ffd6fe8ef538f4b0b39 0 374 1689 1143 2016-02-05T18:56:50Z Djmaster 255 /* Voraussetzungen */ wikitext text/x-wiki {{i18n|Quick Start Guide/Preparation}} = Voraussetzungen = * AVR GCC-Compiler, >= 4.7 * AVR LIBC Version 1.6.8, für 128er ATMegas 1.7 * GNU-Tools Bash, Make, m4, awk * AVR-Programmier Werkzeug, z. B. avrdude '''Achtung:''' binutils ''2.22'' hat einen Fehler, der das Übersetzen von Ethersex abbricht. Installiere Version 2.21 bis [http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52692 GCC 4.7.1] verfügbar ist. == Linux Debian / Ubuntu == apt-get install gcc-avr avr-libc binutils-avr m4 gawk libncurses5-dev make dialog git-core avrdude == Arch Linux == pacman -Sy m4 avr-binutils avr-libc avrdude avr-gcc git gawk ncurses make perl == FreeBSD == add gmake avr-binutils avr-gcc avr-libc (to compile) add gsed m4 gawk (need for ethersex), add avrdude git use add_page -r PKG-NAME or use ports (goggle freebsd ports install) == Mac OS X == Zum Einsatz von Ethersex müssen auf Mac OS X noch Softwarepakete installiert werden. Dazu wird [http://www.macports.org MacPorts] benutzt. Sollten die Softwarepakete von MacPorts nicht aktuell sein, gibt es eine [http://www.heise.de/ct/projekte/machmit/ctbot/wiki/AVRToolchain Anleitung], die Arbeitsumgebung für AVR manuell zu bauen. Die Nutzung von MacPorts ist einfacher und führt schneller zum Ziel. Wer schon einen Atmel AVR programmiert und geflasht hat, besitzt bereits eine funktionierende Arbeitsumgebung. Wenn nicht, müssen zuerst die Softwarepakete zur Programmierung eines AVR installiert werden: sudo port install avr-binutils avr-gcc avr-libc avrdude Für Neueinsteiger wird als Fingerübung empfohlen, eine LED auf dem AVR zum Blinken zu bringen, bevor man sich in das Ethersex Abenteuer stürzt. Wer bereits git nutzt, kann den nächsten Schritt überspringen: sudo port install git-core Es folgen die Softwarepakete, die von Ethersex benötigt werden: sudo port install bash gsed gawk dialog = Sourcen von GitHub holen= Entweder mit git clone git://github.com/ethersex/ethersex.git oder via http git clone http://github.com/ethersex/ethersex.git Die lokale Version von Ethersex wird aktualisiert mit: git pull origin [[Quick_Start_Guide/Configuration | Nächster Schritt]] 0726d2a016f882527291e9c736c8454359e8ef7d 1701 1689 2016-02-05T20:04:21Z Djmaster 255 /* Voraussetzungen */ wikitext text/x-wiki {{i18n|Quick Start Guide/Preparation}} = Voraussetzungen = * AVR GCC-Compiler >= 4.7 * AVR LIBC >= 1.8 * GNU-Tools Bash, Make, m4, awk * AVR-Programmier Werkzeug, z. B. avrdude '''Achtung:''' binutils ''2.22'' hat einen Fehler, der das Übersetzen von Ethersex abbricht. Installiere Version 2.21 bis [http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52692 GCC 4.7.1] verfügbar ist. == Linux Debian / Ubuntu == apt-get install gcc-avr avr-libc binutils-avr m4 gawk libncurses5-dev make dialog git-core avrdude == Arch Linux == pacman -Sy m4 avr-binutils avr-libc avrdude avr-gcc git gawk ncurses make perl == FreeBSD == add gmake avr-binutils avr-gcc avr-libc (to compile) add gsed m4 gawk (need for ethersex), add avrdude git use add_page -r PKG-NAME or use ports (goggle freebsd ports install) == Mac OS X == Zum Einsatz von Ethersex müssen auf Mac OS X noch Softwarepakete installiert werden. Dazu wird [http://www.macports.org MacPorts] benutzt. Sollten die Softwarepakete von MacPorts nicht aktuell sein, gibt es eine [http://www.heise.de/ct/projekte/machmit/ctbot/wiki/AVRToolchain Anleitung], die Arbeitsumgebung für AVR manuell zu bauen. Die Nutzung von MacPorts ist einfacher und führt schneller zum Ziel. Wer schon einen Atmel AVR programmiert und geflasht hat, besitzt bereits eine funktionierende Arbeitsumgebung. Wenn nicht, müssen zuerst die Softwarepakete zur Programmierung eines AVR installiert werden: sudo port install avr-binutils avr-gcc avr-libc avrdude Für Neueinsteiger wird als Fingerübung empfohlen, eine LED auf dem AVR zum Blinken zu bringen, bevor man sich in das Ethersex Abenteuer stürzt. Wer bereits git nutzt, kann den nächsten Schritt überspringen: sudo port install git-core Es folgen die Softwarepakete, die von Ethersex benötigt werden: sudo port install bash gsed gawk dialog = Sourcen von GitHub holen= Entweder mit git clone git://github.com/ethersex/ethersex.git oder via http git clone http://github.com/ethersex/ethersex.git Die lokale Version von Ethersex wird aktualisiert mit: git pull origin [[Quick_Start_Guide/Configuration | Nächster Schritt]] 519d842ad1b86a9e49ba2e53ea2bc48b71d50b08 1702 1701 2016-02-05T20:07:15Z Djmaster 255 /* Voraussetzungen */ wikitext text/x-wiki {{i18n|Quick Start Guide/Preparation}} = Voraussetzungen = * AVR GCC-Compiler >= 4.7 * AVR LIBC >= 1.8 * GNU-Tools (Bash, Make, m4, awk) * AVR-Programmier Werkzeug (z.B.: avrdude) '''Achtung:''' binutils ''2.22'' hat einen Fehler, der das Übersetzen von Ethersex abbricht. Installiere Version 2.21 bis [http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52692 GCC 4.7.1] verfügbar ist. == Linux Debian / Ubuntu == apt-get install gcc-avr avr-libc binutils-avr m4 gawk libncurses5-dev make dialog git-core avrdude == Arch Linux == pacman -Sy m4 avr-binutils avr-libc avrdude avr-gcc git gawk ncurses make perl == FreeBSD == add gmake avr-binutils avr-gcc avr-libc (to compile) add gsed m4 gawk (need for ethersex), add avrdude git use add_page -r PKG-NAME or use ports (goggle freebsd ports install) == Mac OS X == Zum Einsatz von Ethersex müssen auf Mac OS X noch Softwarepakete installiert werden. Dazu wird [http://www.macports.org MacPorts] benutzt. Sollten die Softwarepakete von MacPorts nicht aktuell sein, gibt es eine [http://www.heise.de/ct/projekte/machmit/ctbot/wiki/AVRToolchain Anleitung], die Arbeitsumgebung für AVR manuell zu bauen. Die Nutzung von MacPorts ist einfacher und führt schneller zum Ziel. Wer schon einen Atmel AVR programmiert und geflasht hat, besitzt bereits eine funktionierende Arbeitsumgebung. Wenn nicht, müssen zuerst die Softwarepakete zur Programmierung eines AVR installiert werden: sudo port install avr-binutils avr-gcc avr-libc avrdude Für Neueinsteiger wird als Fingerübung empfohlen, eine LED auf dem AVR zum Blinken zu bringen, bevor man sich in das Ethersex Abenteuer stürzt. Wer bereits git nutzt, kann den nächsten Schritt überspringen: sudo port install git-core Es folgen die Softwarepakete, die von Ethersex benötigt werden: sudo port install bash gsed gawk dialog = Sourcen von GitHub holen= Entweder mit git clone git://github.com/ethersex/ethersex.git oder via http git clone http://github.com/ethersex/ethersex.git Die lokale Version von Ethersex wird aktualisiert mit: git pull origin [[Quick_Start_Guide/Configuration | Nächster Schritt]] d6c2033ab80bfc2151f0501cefa8ca9845abae74 0 169 1690 1138 2016-02-05T18:57:12Z Djmaster 255 /* Requirements */ wikitext text/x-wiki {{i18n|Quick Start Guide/Preparation}} = Requirements = * AVR GCC-Compiler, >= 4.7 * AVR LIBC (Version 1.6.8, for 128er ATMegas 1.7) * GNU-Tools (Bash, Make, m4, awk) * AVR-Programmer (e.g. avrdude) '''Attention:''' binutils ''2.22'' has a bug that causes the compilation of ethersex to fail. Install version 2.21 until [http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52692 GCC 4.7.1 has been released]. == Linux Debian / Ubuntu == apt-get install gcc-avr avr-libc binutils-avr m4 gawk libncurses5-dev make dialog git-core avrdude == Arch Linux == pacman -Sy m4 avr-binutils avr-libc avrdude avr-gcc git gawk ncurses make perl == FreeBSD == add gmake avr-binutils avr-gcc avr-libc (to compile) add gsed m4 gawk (need for ethersex), add avrdude git use add_page -r PKG-NAME or use ports (goggle freebsd ports install) == Mac OS X == Before compiling Ethersex on Mac OS X additional software packages need to be installed. [http://www.macports.org MacPorts] are used for that. In case MacPorts are outdated, there is a [http://www.heise.de/ct/projekte/machmit/ctbot/wiki/AVRToolchain guide] for building the AVR toolchain manually. Using MacPorts is easier and faster. Who already programmed and flashed an Atmel AVR has a proper working environment. Else the packages for programming an AVR need to be installed: sudo port install avr-binutils avr-gcc avr-libc avrdude For newbies it is recommended to connect a LED and have that flashing by the AVR before jumping into the Ethersex adventure. Who already uses git, can skip the next step: sudo port install git-core Now install the software packages that are required by Ethersex: sudo port install bash gsed gawk dialog = Download the Source from GitHub = You can download Ethersex from github via git protocol git clone git://github.com/ethersex/ethersex.git or via http git clone http://github.com/ethersex/ethersex.git Updating a local version of ethersex is possible with: git pull origin [[Quick_Start_Guide/Configuration | next step]] 978c71f575dd8ccaf6d6f17f79f035fa95c24c01 1700 1690 2016-02-05T20:03:52Z Djmaster 255 /* Requirements */ wikitext text/x-wiki {{i18n|Quick Start Guide/Preparation}} = Requirements = * AVR GCC-Compiler >= 4.7 * AVR LIBC >= 1.8 * GNU-Tools (Bash, Make, m4, awk) * AVR-Programmer (e.g. avrdude) '''Attention:''' binutils ''2.22'' has a bug that causes the compilation of ethersex to fail. Install version 2.21 until [http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52692 GCC 4.7.1 has been released]. == Linux Debian / Ubuntu == apt-get install gcc-avr avr-libc binutils-avr m4 gawk libncurses5-dev make dialog git-core avrdude == Arch Linux == pacman -Sy m4 avr-binutils avr-libc avrdude avr-gcc git gawk ncurses make perl == FreeBSD == add gmake avr-binutils avr-gcc avr-libc (to compile) add gsed m4 gawk (need for ethersex), add avrdude git use add_page -r PKG-NAME or use ports (goggle freebsd ports install) == Mac OS X == Before compiling Ethersex on Mac OS X additional software packages need to be installed. [http://www.macports.org MacPorts] are used for that. In case MacPorts are outdated, there is a [http://www.heise.de/ct/projekte/machmit/ctbot/wiki/AVRToolchain guide] for building the AVR toolchain manually. Using MacPorts is easier and faster. Who already programmed and flashed an Atmel AVR has a proper working environment. Else the packages for programming an AVR need to be installed: sudo port install avr-binutils avr-gcc avr-libc avrdude For newbies it is recommended to connect a LED and have that flashing by the AVR before jumping into the Ethersex adventure. Who already uses git, can skip the next step: sudo port install git-core Now install the software packages that are required by Ethersex: sudo port install bash gsed gawk dialog = Download the Source from GitHub = You can download Ethersex from github via git protocol git clone git://github.com/ethersex/ethersex.git or via http git clone http://github.com/ethersex/ethersex.git Updating a local version of ethersex is possible with: git pull origin [[Quick_Start_Guide/Configuration | next step]] 696e59777ab9342e467b1577f99dc200650db322 0 169 1705 1700 2016-02-06T08:11:39Z Djmaster 255 wikitext text/x-wiki {{i18n|Quick Start Guide/Preparation}} = Requirements = * AVR GCC-Compiler >= 4.7 * AVR LIBC >= 1.8 * GNU-Tools (Bash, Make, m4, awk) * AVR-Programmer (e.g. avrdude) <s>'''Attention:''' binutils ''2.22'' has a bug that causes the compilation of ethersex to fail. Install version 2.21 until [http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52692 GCC 4.7.1 has been released].</s> == Linux Debian / Ubuntu == apt-get install gcc-avr avr-libc binutils-avr m4 gawk libncurses5-dev make dialog git-core avrdude == Arch Linux == pacman -Sy m4 avr-binutils avr-libc avrdude avr-gcc git gawk ncurses make perl == FreeBSD == add gmake avr-binutils avr-gcc avr-libc (to compile) add gsed m4 gawk (need for ethersex), add avrdude git use add_page -r PKG-NAME or use ports (goggle freebsd ports install) == Mac OS X == Before compiling Ethersex on Mac OS X additional software packages need to be installed. [http://www.macports.org MacPorts] are used for that. In case MacPorts are outdated, there is a [http://www.heise.de/ct/projekte/machmit/ctbot/wiki/AVRToolchain guide] for building the AVR toolchain manually. Using MacPorts is easier and faster. Who already programmed and flashed an Atmel AVR has a proper working environment. Else the packages for programming an AVR need to be installed: sudo port install avr-binutils avr-gcc avr-libc avrdude For newbies it is recommended to connect a LED and have that flashing by the AVR before jumping into the Ethersex adventure. Who already uses git, can skip the next step: sudo port install git-core Now install the software packages that are required by Ethersex: sudo port install bash gsed gawk dialog = Download the Source from GitHub = You can download Ethersex from github via git protocol git clone git://github.com/ethersex/ethersex.git or via http git clone http://github.com/ethersex/ethersex.git Updating a local version of ethersex is possible with: git pull origin [[Quick_Start_Guide/Configuration | next step]] 1c0f8c538e22068563302286c03665ad61fbe68d 1708 1705 2016-02-06T08:23:07Z Djmaster 255 /* Requirements */ wikitext text/x-wiki {{i18n|Quick Start Guide/Preparation}} = Requirements = * AVR GCC-Compiler >= 4.7 * AVR LIBC >= 1.8 * AVR Binutils >= 2.22 * GNU-Tools (Bash, Make, m4, awk) * AVR-Programmer (e.g. avrdude) <s>'''Attention:''' binutils ''2.22'' has a bug that causes the compilation of ethersex to fail. Install version 2.21 until [http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52692 GCC 4.7.1 has been released].</s> == Linux Debian / Ubuntu == apt-get install gcc-avr avr-libc binutils-avr m4 gawk libncurses5-dev make dialog git-core avrdude == Arch Linux == pacman -Sy m4 avr-binutils avr-libc avrdude avr-gcc git gawk ncurses make perl == FreeBSD == add gmake avr-binutils avr-gcc avr-libc (to compile) add gsed m4 gawk (need for ethersex), add avrdude git use add_page -r PKG-NAME or use ports (goggle freebsd ports install) == Mac OS X == Before compiling Ethersex on Mac OS X additional software packages need to be installed. [http://www.macports.org MacPorts] are used for that. In case MacPorts are outdated, there is a [http://www.heise.de/ct/projekte/machmit/ctbot/wiki/AVRToolchain guide] for building the AVR toolchain manually. Using MacPorts is easier and faster. Who already programmed and flashed an Atmel AVR has a proper working environment. Else the packages for programming an AVR need to be installed: sudo port install avr-binutils avr-gcc avr-libc avrdude For newbies it is recommended to connect a LED and have that flashing by the AVR before jumping into the Ethersex adventure. Who already uses git, can skip the next step: sudo port install git-core Now install the software packages that are required by Ethersex: sudo port install bash gsed gawk dialog = Download the Source from GitHub = You can download Ethersex from github via git protocol git clone git://github.com/ethersex/ethersex.git or via http git clone http://github.com/ethersex/ethersex.git Updating a local version of ethersex is possible with: git pull origin [[Quick_Start_Guide/Configuration | next step]] 66822a813e29eea65959d163ef6002420c7f2803 1729 1708 2016-08-28T17:55:17Z Michaelb 718 /* Requirements */ Added native GCC wikitext text/x-wiki {{i18n|Quick Start Guide/Preparation}} = Requirements = * Native GCC-Compiler (for the lxdialog utility required by make menuconfig) * AVR GCC-Compiler >= 4.7 * AVR LIBC >= 1.8 * AVR Binutils >= 2.22 * GNU-Tools (Bash, Make, m4, awk) * AVR-Programmer (e.g. avrdude) <s>'''Attention:''' binutils ''2.22'' has a bug that causes the compilation of ethersex to fail. Install version 2.21 until [http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52692 GCC 4.7.1 has been released].</s> == Linux Debian / Ubuntu == apt-get install gcc-avr avr-libc binutils-avr m4 gawk libncurses5-dev make dialog git-core avrdude == Arch Linux == pacman -Sy m4 avr-binutils avr-libc avrdude avr-gcc git gawk ncurses make perl == FreeBSD == add gmake avr-binutils avr-gcc avr-libc (to compile) add gsed m4 gawk (need for ethersex), add avrdude git use add_page -r PKG-NAME or use ports (goggle freebsd ports install) == Mac OS X == Before compiling Ethersex on Mac OS X additional software packages need to be installed. [http://www.macports.org MacPorts] are used for that. In case MacPorts are outdated, there is a [http://www.heise.de/ct/projekte/machmit/ctbot/wiki/AVRToolchain guide] for building the AVR toolchain manually. Using MacPorts is easier and faster. Who already programmed and flashed an Atmel AVR has a proper working environment. Else the packages for programming an AVR need to be installed: sudo port install avr-binutils avr-gcc avr-libc avrdude For newbies it is recommended to connect a LED and have that flashing by the AVR before jumping into the Ethersex adventure. Who already uses git, can skip the next step: sudo port install git-core Now install the software packages that are required by Ethersex: sudo port install bash gsed gawk dialog = Download the Source from GitHub = You can download Ethersex from github via git protocol git clone git://github.com/ethersex/ethersex.git or via http git clone http://github.com/ethersex/ethersex.git Updating a local version of ethersex is possible with: git pull origin [[Quick_Start_Guide/Configuration | next step]] 39aa9601bc011b0607410102159dcea6ce5dfc1e 0 374 1706 1702 2016-02-06T08:11:52Z Djmaster 255 /* Voraussetzungen */ wikitext text/x-wiki {{i18n|Quick Start Guide/Preparation}} = Voraussetzungen = * AVR GCC-Compiler >= 4.7 * AVR LIBC >= 1.8 * GNU-Tools (Bash, Make, m4, awk) * AVR-Programmier Werkzeug (z.B.: avrdude) <s>'''Achtung:''' binutils ''2.22'' hat einen Fehler, der das Übersetzen von Ethersex abbricht. Installiere Version 2.21 bis [http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52692 GCC 4.7.1] verfügbar ist.</s> == Linux Debian / Ubuntu == apt-get install gcc-avr avr-libc binutils-avr m4 gawk libncurses5-dev make dialog git-core avrdude == Arch Linux == pacman -Sy m4 avr-binutils avr-libc avrdude avr-gcc git gawk ncurses make perl == FreeBSD == add gmake avr-binutils avr-gcc avr-libc (to compile) add gsed m4 gawk (need for ethersex), add avrdude git use add_page -r PKG-NAME or use ports (goggle freebsd ports install) == Mac OS X == Zum Einsatz von Ethersex müssen auf Mac OS X noch Softwarepakete installiert werden. Dazu wird [http://www.macports.org MacPorts] benutzt. Sollten die Softwarepakete von MacPorts nicht aktuell sein, gibt es eine [http://www.heise.de/ct/projekte/machmit/ctbot/wiki/AVRToolchain Anleitung], die Arbeitsumgebung für AVR manuell zu bauen. Die Nutzung von MacPorts ist einfacher und führt schneller zum Ziel. Wer schon einen Atmel AVR programmiert und geflasht hat, besitzt bereits eine funktionierende Arbeitsumgebung. Wenn nicht, müssen zuerst die Softwarepakete zur Programmierung eines AVR installiert werden: sudo port install avr-binutils avr-gcc avr-libc avrdude Für Neueinsteiger wird als Fingerübung empfohlen, eine LED auf dem AVR zum Blinken zu bringen, bevor man sich in das Ethersex Abenteuer stürzt. Wer bereits git nutzt, kann den nächsten Schritt überspringen: sudo port install git-core Es folgen die Softwarepakete, die von Ethersex benötigt werden: sudo port install bash gsed gawk dialog = Sourcen von GitHub holen= Entweder mit git clone git://github.com/ethersex/ethersex.git oder via http git clone http://github.com/ethersex/ethersex.git Die lokale Version von Ethersex wird aktualisiert mit: git pull origin [[Quick_Start_Guide/Configuration | Nächster Schritt]] c09d6cdc53ca50d66dcdc0f3458cf82341060536 1707 1706 2016-02-06T08:22:39Z Djmaster 255 /* Voraussetzungen */ wikitext text/x-wiki {{i18n|Quick Start Guide/Preparation}} = Voraussetzungen = * AVR GCC-Compiler >= 4.7 * AVR LIBC >= 1.8 * AVR Binutils >= 2.22 * GNU-Tools (Bash, Make, m4, awk) * AVR-Programmier Werkzeug (z.B.: avrdude) <s>'''Achtung:''' binutils ''2.22'' hat einen Fehler, der das Übersetzen von Ethersex abbricht. Installiere Version 2.21 bis [http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52692 GCC 4.7.1] verfügbar ist.</s> == Linux Debian / Ubuntu == apt-get install gcc-avr avr-libc binutils-avr m4 gawk libncurses5-dev make dialog git-core avrdude == Arch Linux == pacman -Sy m4 avr-binutils avr-libc avrdude avr-gcc git gawk ncurses make perl == FreeBSD == add gmake avr-binutils avr-gcc avr-libc (to compile) add gsed m4 gawk (need for ethersex), add avrdude git use add_page -r PKG-NAME or use ports (goggle freebsd ports install) == Mac OS X == Zum Einsatz von Ethersex müssen auf Mac OS X noch Softwarepakete installiert werden. Dazu wird [http://www.macports.org MacPorts] benutzt. Sollten die Softwarepakete von MacPorts nicht aktuell sein, gibt es eine [http://www.heise.de/ct/projekte/machmit/ctbot/wiki/AVRToolchain Anleitung], die Arbeitsumgebung für AVR manuell zu bauen. Die Nutzung von MacPorts ist einfacher und führt schneller zum Ziel. Wer schon einen Atmel AVR programmiert und geflasht hat, besitzt bereits eine funktionierende Arbeitsumgebung. Wenn nicht, müssen zuerst die Softwarepakete zur Programmierung eines AVR installiert werden: sudo port install avr-binutils avr-gcc avr-libc avrdude Für Neueinsteiger wird als Fingerübung empfohlen, eine LED auf dem AVR zum Blinken zu bringen, bevor man sich in das Ethersex Abenteuer stürzt. Wer bereits git nutzt, kann den nächsten Schritt überspringen: sudo port install git-core Es folgen die Softwarepakete, die von Ethersex benötigt werden: sudo port install bash gsed gawk dialog = Sourcen von GitHub holen= Entweder mit git clone git://github.com/ethersex/ethersex.git oder via http git clone http://github.com/ethersex/ethersex.git Die lokale Version von Ethersex wird aktualisiert mit: git pull origin [[Quick_Start_Guide/Configuration | Nächster Schritt]] 7637ecb19233c84464ccdd48bf38e03853f9a3bc 3 495 1709 1681 2016-03-07T06:08:54Z Djmaster 255 wikitext text/x-wiki =Todo Liste= ==1== *[[Temperaturmesssystem_(Deutsch)]] ** <s>webabfrage</s> ** <s>wdreset</s> ** <s>make clean && make</s> ** <s>Paar Bilder und tftpd win32</s> ** <s>ds1820 id herausbekommen</s> ** schaltung ds1820 4k7 ==2== *[[BOOTP_%28Deutsch%29]] ** <s>Links prüfen</s> ** <s>Bilder prüfen</s> ** <s>Text anpassen</s> ==3== *[[I2C_%28Deutsch%29]] **Levelshifter **Aufteilung =4== *ETHERNET LOADER??? old wiki *ENC28J60_(Deutsch) = LÖSCHEN?? 93c1714acbd71a504d4a11671fe0315e166f0a12 2 329 1710 1526 2016-03-19T14:17:32Z Djmaster 255 /* Levelshifter 3.3V 5V */ wikitext text/x-wiki [[File:RJ45Buchse_Pinout.png|400px|thumb|RJ45 Buchse]] ==Person== Nick im IRC: djmaster oder djmaster2<br> Web: http://wiki.senseye.org/ ==Bauteile== Für [http://www.lochraster.org/etherrape/ Etherrape] Module {| | {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%;" |- ! Bauteil !! Hersteller !! HerstellerNr !! Lieferant !! Bestellnummer !! Dokumente !! Sonstiges |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/products/en?q=6605424-1 6605424-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154361/ 615-4361] || [http://www.te.com/catalog/pn/en/6605424-1?RQPN=6605424-1 Link] || Netzwerkbuchse ohne LED, Verriegelung Unten |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/pn/en/5-6605308-1 5-6605308-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154383/ 615-4383] || [http://www.te.com/catalog/pn/en/5-6605308-1?RQPN=5-6605308-1 Link] || Netzwerkbuchse mit LED, Verriegelung Unten |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/products/en?q=6605759-1 6605759-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154399/ 615-4399] || [http://www.te.com/catalog/pn/en/6605759-1?RQPN=6605759-1 Link] || Netzwerkbuchse ohne LED, Verriegelung Oben |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/products/en?q=5-6605758-1 5-6605758-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154412/ 615-4412] || [http://www.te.com/catalog/pn/en/5-6605758-1?RQPN=5-6605758-1 Link] || Netzwerkbuchse mit LED, Verriegelung Oben |- align="right" | Hutschienen Gehäuse || Axxatronic || [http://www.axxatronic.de/serie-cnmb.html CNMB-4-KIT-CON] || Conrad || [http://www.conrad.at/ce/de/product/531443/Axxatronic-Hutschienen-Gehaeuse-CNMB-4-KIT-CON-Polycarbonat-L-x-B-x-H-90-x-710-x-58-mm 531443 - 62] || [http://www.axxatronic.de/serie-cnmb.html Link] || (L x B x H) 90 x 71.0 x 58 mm |- align="right" | DS2450 || Maxim || [http://www.maximintegrated.com/datasheet/index.mvp/id/2921 DS2450] || RS-Components || [http://at.rs-online.com/web/p/products/07327557/ 732-7557] || [http://datasheets.maximintegrated.com/en/ds/DS2450.pdf Link] || Onewire quad AD Converter |- align="right" | HIH4000-001 || Honeywell || [http://sensing.honeywell.com/product%20page?pr_id=53944 HIH4000-001] || RS-Components || [http://at.rs-online.com/web/p/products/05283171/ 528-3171] || [http://sensing.honeywell.com/product%20page?pr_id=53944 Link] || Luftfeuchte Sensor von Honeywell |- align="right" | MPXH6115AC6U || Freescale || xx || RS-Components || [http://at.rs-online.com/web/p/products/07176536/ 717-6536] || [http://www.freescale.com/files/sensors/doc/data_sheet/MPXA6115A.pdf Link] || Luftdruck Sensor von Freescale |} ==Die Software== [[File:Ethersex det ssr.png|400px|thumb|die Theorie]] [[File:Hausbus v1.JPG|400px|thumb|die Praxis]] ===TFTP-Bootloader & Fuses=== Menuconfig: │ │ Load a Default Configuration ---> │ │ [*] Ethernet Bootloader │ │ Network ---> │ │ [*] Ethernet (ENC28J60) support ---> │ │ Etherrape IP address: "192.168.12.220" │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ Applications ---> │ │ [*] TFTP support ---> │ │ Bootloader configuration ---> │ │ [*] TFTP-o-matic │ │ --- TFTP-o-matic configuration │ │ TFTP IP address: "192.168.12.120" │ │ TFTP image to load: "ethersex.bin" make clean && make --> ethersex.hex =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 6064/65536 bytes (9.25%) [==----------------------------] Program (.text + .data) : 6064 bytes Data (.data + .bss) : 826 bytes =================================== sudo avrdude -cusbasp -pm644 -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m sudo avrdude -cusbasp -pm644 -U flash:w:ethersex.hex sudo avrdude -cusbasp -pm644 -U lock:w:0x0F:m Achtung bei den SMD Typen vom mega644, ich habe mega644P bekommen, wobei ich jetzt nicht weiß ob die SMD immer P Typen sind. Egal das Problem ist man sollte avrdude genau lesen und auch "-p m644p" anhängen da der P Type eine andere Signatur aufweist. Hat mich ne Stunde gekostet. ;) ==Bilder== ===Testsystem=== <gallery perrow=7> File:1_stella_all_off.jpg File:2_stella_all_on.jpg File:3_mosfets.jpg File:4_schaltung_fet.png File:IMG_5286.JPG File:IMG_6592.JPG File:IMG_6594.JPG File:S0-zaehler_img.JPG File:Esex sensor1.JPG </gallery><br> ==Probleme== 25.1.2011 - ethersex mit m644 und 32khz uhrenquarz.<br> datenblatt mega644 seite 101 - http://www.atmel.com/dyn/resources/prod_documents/doc2593.pdf<br> services/clock/clock.c - zeile 64<br> <obiflix> du könntest https://github.com/ethersex/ethersex/commit/da511f074940423e8e8ef7ee67ca20e6d91f608c rückgängig machen <obiflix> möglicherweise bekommst du dann probleme mit dcf77, falls du das nutzen möchtest, aber einen versuch ist es wert ;) Notiz: Hat funktioniert für den MEGA644<br> Update#1<br> 26.1.2011 - Problem sollte nun behoben sein, Danke an eku! master Erik Kunze * ae3ef98 (2 files in 1 dirs): use timer makros for prescaler 64 (32768Hz/256/64=2Hz) - http://bit.ly/eG2d4c --- DCF muss noch getestet werden ==Notizzettel== schnell mal notiert ein script zum email versenden wenn zb..PIN_LOW... <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include <util/delay.h> CONTROL_START CLOCK_USED() ECMD_GLOBAL(t1, 0, uint16_t); ECMD_GLOBAL(var1, 0); ECMD_GLOBAL(var2, 0); ECMD_GLOBAL(aqua_mail_sent, 0, uint8_t) THREAD(start) if (!PIN_HIGH(WTR)) t1++; else t1=0; if (t1 > 10) var1=1; else var1 = 0; if (t1 > 400) var2=1; else var2 = 0; if (var1 == 1) PIN_CLEAR(LED1); else PIN_SET(LED1); if (var2 == 1){ if (aqua_mail_sent == 0){ PIN_CLEAR(LED2); mail_send(); aqua_mail_sent = 1; } var2 = 0; }else{ PIN_SET(LED2); } THREAD_END(start) ON STARTUP DO THREAD_START(start) END CONTROL_END </source> ==Levelshifter 3.3V 5V== <gallery perrow=1> File:Levelshifter.png </gallery><br> Source: http://wiki.senseye.org/_dirs/levelshifter/levelshifter.sch dc86266eae79b0fcb0ed9e86851afe9a490e5d6f 1711 1710 2016-03-27T18:43:24Z Djmaster 255 /* Levelshifter 3.3V 5V */ wikitext text/x-wiki [[File:RJ45Buchse_Pinout.png|400px|thumb|RJ45 Buchse]] ==Person== Nick im IRC: djmaster oder djmaster2<br> Web: http://wiki.senseye.org/ ==Bauteile== Für [http://www.lochraster.org/etherrape/ Etherrape] Module {| | {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%;" |- ! Bauteil !! Hersteller !! HerstellerNr !! Lieferant !! Bestellnummer !! Dokumente !! Sonstiges |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/products/en?q=6605424-1 6605424-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154361/ 615-4361] || [http://www.te.com/catalog/pn/en/6605424-1?RQPN=6605424-1 Link] || Netzwerkbuchse ohne LED, Verriegelung Unten |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/pn/en/5-6605308-1 5-6605308-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154383/ 615-4383] || [http://www.te.com/catalog/pn/en/5-6605308-1?RQPN=5-6605308-1 Link] || Netzwerkbuchse mit LED, Verriegelung Unten |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/products/en?q=6605759-1 6605759-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154399/ 615-4399] || [http://www.te.com/catalog/pn/en/6605759-1?RQPN=6605759-1 Link] || Netzwerkbuchse ohne LED, Verriegelung Oben |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/products/en?q=5-6605758-1 5-6605758-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154412/ 615-4412] || [http://www.te.com/catalog/pn/en/5-6605758-1?RQPN=5-6605758-1 Link] || Netzwerkbuchse mit LED, Verriegelung Oben |- align="right" | Hutschienen Gehäuse || Axxatronic || [http://www.axxatronic.de/serie-cnmb.html CNMB-4-KIT-CON] || Conrad || [http://www.conrad.at/ce/de/product/531443/Axxatronic-Hutschienen-Gehaeuse-CNMB-4-KIT-CON-Polycarbonat-L-x-B-x-H-90-x-710-x-58-mm 531443 - 62] || [http://www.axxatronic.de/serie-cnmb.html Link] || (L x B x H) 90 x 71.0 x 58 mm |- align="right" | DS2450 || Maxim || [http://www.maximintegrated.com/datasheet/index.mvp/id/2921 DS2450] || RS-Components || [http://at.rs-online.com/web/p/products/07327557/ 732-7557] || [http://datasheets.maximintegrated.com/en/ds/DS2450.pdf Link] || Onewire quad AD Converter |- align="right" | HIH4000-001 || Honeywell || [http://sensing.honeywell.com/product%20page?pr_id=53944 HIH4000-001] || RS-Components || [http://at.rs-online.com/web/p/products/05283171/ 528-3171] || [http://sensing.honeywell.com/product%20page?pr_id=53944 Link] || Luftfeuchte Sensor von Honeywell |- align="right" | MPXH6115AC6U || Freescale || xx || RS-Components || [http://at.rs-online.com/web/p/products/07176536/ 717-6536] || [http://www.freescale.com/files/sensors/doc/data_sheet/MPXA6115A.pdf Link] || Luftdruck Sensor von Freescale |} ==Die Software== [[File:Ethersex det ssr.png|400px|thumb|die Theorie]] [[File:Hausbus v1.JPG|400px|thumb|die Praxis]] ===TFTP-Bootloader & Fuses=== Menuconfig: │ │ Load a Default Configuration ---> │ │ [*] Ethernet Bootloader │ │ Network ---> │ │ [*] Ethernet (ENC28J60) support ---> │ │ Etherrape IP address: "192.168.12.220" │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ Applications ---> │ │ [*] TFTP support ---> │ │ Bootloader configuration ---> │ │ [*] TFTP-o-matic │ │ --- TFTP-o-matic configuration │ │ TFTP IP address: "192.168.12.120" │ │ TFTP image to load: "ethersex.bin" make clean && make --> ethersex.hex =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 6064/65536 bytes (9.25%) [==----------------------------] Program (.text + .data) : 6064 bytes Data (.data + .bss) : 826 bytes =================================== sudo avrdude -cusbasp -pm644 -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m sudo avrdude -cusbasp -pm644 -U flash:w:ethersex.hex sudo avrdude -cusbasp -pm644 -U lock:w:0x0F:m Achtung bei den SMD Typen vom mega644, ich habe mega644P bekommen, wobei ich jetzt nicht weiß ob die SMD immer P Typen sind. Egal das Problem ist man sollte avrdude genau lesen und auch "-p m644p" anhängen da der P Type eine andere Signatur aufweist. Hat mich ne Stunde gekostet. ;) ==Bilder== ===Testsystem=== <gallery perrow=7> File:1_stella_all_off.jpg File:2_stella_all_on.jpg File:3_mosfets.jpg File:4_schaltung_fet.png File:IMG_5286.JPG File:IMG_6592.JPG File:IMG_6594.JPG File:S0-zaehler_img.JPG File:Esex sensor1.JPG </gallery><br> ==Probleme== 25.1.2011 - ethersex mit m644 und 32khz uhrenquarz.<br> datenblatt mega644 seite 101 - http://www.atmel.com/dyn/resources/prod_documents/doc2593.pdf<br> services/clock/clock.c - zeile 64<br> <obiflix> du könntest https://github.com/ethersex/ethersex/commit/da511f074940423e8e8ef7ee67ca20e6d91f608c rückgängig machen <obiflix> möglicherweise bekommst du dann probleme mit dcf77, falls du das nutzen möchtest, aber einen versuch ist es wert ;) Notiz: Hat funktioniert für den MEGA644<br> Update#1<br> 26.1.2011 - Problem sollte nun behoben sein, Danke an eku! master Erik Kunze * ae3ef98 (2 files in 1 dirs): use timer makros for prescaler 64 (32768Hz/256/64=2Hz) - http://bit.ly/eG2d4c --- DCF muss noch getestet werden ==Notizzettel== schnell mal notiert ein script zum email versenden wenn zb..PIN_LOW... <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include <util/delay.h> CONTROL_START CLOCK_USED() ECMD_GLOBAL(t1, 0, uint16_t); ECMD_GLOBAL(var1, 0); ECMD_GLOBAL(var2, 0); ECMD_GLOBAL(aqua_mail_sent, 0, uint8_t) THREAD(start) if (!PIN_HIGH(WTR)) t1++; else t1=0; if (t1 > 10) var1=1; else var1 = 0; if (t1 > 400) var2=1; else var2 = 0; if (var1 == 1) PIN_CLEAR(LED1); else PIN_SET(LED1); if (var2 == 1){ if (aqua_mail_sent == 0){ PIN_CLEAR(LED2); mail_send(); aqua_mail_sent = 1; } var2 = 0; }else{ PIN_SET(LED2); } THREAD_END(start) ON STARTUP DO THREAD_START(start) END CONTROL_END </source> ==Levelshifter 3.3V 5V== <gallery perrow=1> File:Levelshifter.png </gallery><br> Source: http://wiki.senseye.org/adir/levelshifter/levelshifter.sch f8ecd8c2d0f37a54882b2750b4144ca5dc625c1e 0 498 1712 1654 2016-03-27T18:47:44Z Djmaster 255 /* Schaltung */ wikitext text/x-wiki {{i18n|Temperaturmesssystem}} [[File:Tempmess_pcb_01.jpg|thumb|250px|meine Testplatine, Layout stimmt bis auf Kleinigkeiten überein]] [[File:Tempmess_pcb_02.jpg|thumb|250px|Testplatine beim Programmieren mit avrdude via ISP]] =PROJEKT Temperaturmessung= ===Einleitung=== * ZIEL: Eine einfache Temperaturmessung mit dem [[Onewire_(Deutsch)#Anschluss_AVR-NET-IO | DS1820 im parasitären Modus]]. * ZIEL: Die Ausgabe einer Temperaturvariable via integrierten Webbrowser oder telnet. * ZIEL: Die Firmware muss via Netzwerk neu flashbar sein. * Abgeändertes vereinfachtes [http://www.lochraster.org/etherrape/ etherrape] Board. * Zwei Spannungsregler, ein atmega644p, ein enc28j60, und etwas 0805 Hühnerfutter. ===Schaltung=== Das Layout passt in folgendes Gehäuse. Vorher am besten nochmal genau nachmessen. ;)<br> Conrad Bestell-Nr.: [https://www.conrad.at/de/hutschienen-gehaeuse-90-x-360-x-58-polycarbonat-axxatronic-cnmb-2-kit-con-1-st-531441.html 531441] / Axxatronic CNMB-2-KIT-CON <div><ul> <li style="display: inline-block;"> [[File:Sch_tempmess.png|thumb|none|210px|Schaltung]] </li> <li style="display: inline-block;"> [[File:Pcb_tempmess.png|thumb|none|280px|Layout]] </li> </ul></div> * Erstellt mit Eagle Version 7.1.0 für Windows * [http://wiki.senseye.org/adir/tempmesssystem/tempmess_schematic_001.pdf PDF Schaltung] * [http://wiki.senseye.org/adir/tempmesssystem/tempmess_layout_001.pdf PDF Layout gespiegelt] * [http://wiki.senseye.org/adir/tempmesssystem/tempmess001.sch Eagle Schaltung] * [http://wiki.senseye.org/adir/tempmesssystem/tempmess001.brd Eagle Layout] ===Software=== Ethersex (Linux) - https://github.com/ethersex/ethersex Avrdude (Windows) - http://download.savannah.gnu.org/releases/avrdude/ (avrdude-6.1-mingw32.zip) tftpd (Windows) - http://tftpd32.jounin.net/tftpd32_download.html (v4.52 tftpd64 standard edition (zip)) ===Firmware/Bootloader=== Die ethersex Firmware selbst wird für zwei Sachen verwendet. Den <b>Bootloader</b> UND die <b>Firmware</b>. Der Bootloader wird sozusagen einmal in den ersten Bereich des Mikrocontrollers geschrieben und bleibt dort auch. Er wird später die Firmware via Netzwerk entgegennehmen und in den Controller schreiben. Somit befindet sich in den ersten 10% unser Bootloader und in den restlichen 90% der Code den wir wollen. Das zu Verstehen war für mich an Anfang der schwierigste Teil, ist aber dann doch sehr einfach. Ich kann somit ohne ISP-Programmer eine Firmware in den Controller schreiben. Hier grob noch die nächsten Schritte: * Als erstes ist der Bootloader zu konfigurieren, dann via ISP zu programmieren. * Der ISP-Programmer wegräumen. ;) * Als zweites ist die Firmware zu konfigurieren, dann holt sich der Bootloader unsere Firmware via Netzerk/tftpd. =BOOTLOADER= ===Bootloader bauen=== <div><ul> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess01.png|thumb|none|200px|Putty Bild 1]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess02.png|thumb|none|200px|Putty Bild 2]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess03.png|thumb|none|200px|Putty Bild 3]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess04.png|thumb|none|200px|Putty Bild 4]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess05.png|thumb|none|200px|Putty Bild 5]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess06.png|thumb|none|200px|Putty Bild 6]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess07.png|thumb|none|200px|Putty Bild 7]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess08.png|thumb|none|200px|Putty Bild 8]] </li> </ul></div> Ab nun befinde ich mich auf einem <b>virtuellen Debian Rechner</b> wo ich die Firmware herunterlade und daraus den Bootloader erstelle.<br> <b>WICHTIG:</b> Die IP und MAC-Adresse müssen natürlich verändert werden. Die selbe IP und MAC-Adresse müssen in der Firmware später auch benutzt werden. <br> * Bei einem neuen Debian System müssen mit "apt-get" ein paar Sachen nachinstalliert werden. Hier zu finden [[Quick_Start_Guide/Preparation_(Deutsch)]] * So eine art DHCP wäre auch möglich, nennt sich [[BOOTP_(Deutsch) | BOOTP]]. Darauf gehe ich hier nicht ein. # cd /home/avr/ # mkdir ethersex_IP_60 // Mein "Arbeitsordner" # cd ethersex_IP_60/ // Ordner für das Board mit der IP 192.168.123.60 # git clone git://github.com/ethersex/ethersex.git // ethersex Firmware herunterladen Cloning into ethersex... remote: Counting objects: 37366, done. remote: Total 37366 (delta 0), reused 0 (delta 0), pack-reused 37366 Receiving objects: 100% (37366/37366), 11.27 MiB | 1.22 MiB/s, done. Resolving deltas: 100% (26538/26538), done. # cp -r ethersex bootloader // Ich kopiere den ethersex Ordner zu dem bootloader Ordner. 1:1 Kopie # cd bootloader/ // In den Bootloader Ordner wechseln # make menuconfig // Einstellungen für Bootloader im nächsten Schritt │ │ Load a Default Configuration ---> │ │ (*) Ethernet Bootloader │ │ General Setup ---> │ │ (ATmega644) Target MCU │ │ (20000000) MCU frequency │ │ [*] Build a bootloader │ │ [*] Teensy build │ │ Network ---> │ │ Hostname: "esex060" // Hostname ändern │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" // MAC ändern mit "Randomize MAC address" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" // Wenn IP nicht vorhanden BOOTP deaktivieren! │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ [ ] BOOTP (DHCP-like) support // BOOTP deaktivieren! │ │ Applications ---> │ │ [*] TFTP support ---> │ │ [*] TFTP-o-matic │ │ TFTP-server IPv4 address: "192.168.123.233" // Server wo TFTPD läuft │ │ TFTP image to load: "esex060.bin" // Diesen Dateinamen ladet später unser Board via Netzwerk/tftpd jetzt noch EXIT und SPEICHERN. # make clean && make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 5902/8192 bytes (72.4%) [=====================---------] Program (.text + .data) : 5902 bytes Data (.data + .bss) : 1902 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.hex</b> ===Bootloader flashen via ISP=== <div><ul> <li style="display: inline-block;"> [[File:Avrdude tempmess01.png|thumb|none|200px|avrdude Bild 1]] </li> <li style="display: inline-block;"> [[File:Avrdude tempmess01.png|thumb|none|200px|avrdude Bild 2]] </li> <li style="display: inline-block;"> [[File:Avrdude tempmess01.png|thumb|none|200px|avrdude Bild 3]] </li> <li style="display: inline-block;"> [[File:Avrdude tempmess01.png|thumb|none|200px|avrdude Bild 4]] </li> </ul></div> Ich flashe hier einfacher weise mit meinem Windows 7 Notebook. Ich habe avrdude einfach unter C:\ liegen. Dort kopiere ich nun die ethersex.hex hin.<br> Somit kann man mit dem flashen den Bootloaders loslegen. avrdude -cusbasp -pm644p -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m // gilt nur für atmega644p und vermutlich auch 644 avrdude -cusbasp -pm644p -U flash:w:ethersex.hex avrdude -cusbasp -pm644p -U lock:w:0x0F:m Der Mikrocontrollerboard ist nun vorbereitet für die eigentliche Firmware. Der ISP-Programmer kann nun bei Seite gelegt werden und wird soweit alles richtig konfiguriert ist auch nicht mehr benötigt.<br> Nun erfolgt das Erstellen der Firmware. =FIRMWARE= ===Firmware bauen=== <div><ul> <li style="display: inline-block;"> [[File:Putty_c6_m4_tempmess01.png|thumb|none|200px|c6_m4 Bild 1]] </li> <li style="display: inline-block;"> [[File:Putty_c6_m4_tempmess02.png|thumb|none|200px|c6_m4 Bild 2]] </li> <li style="display: inline-block;"> [[File:Putty_c6_m4_tempmess03.png|thumb|none|200px|c6_m4 Bild 3]] </li> </ul></div> * <b>WICHTIG:</b> IP, MAC Adresse, Gateway, Netmask, Hostname <b>MUSS</b> gleich sein wie bei dem Bootloader! * Der integrierte Webserver ist in der original Firmware schon aktiviert. ( Applications --> [*] HTTP Server ) # cd /home/avr/ethersex_IP_60/ # cd ethersex/ # make menuconfig │ │ Load a Default Configuration ---> │ │ (*) Etherrape │ │ General Setup ---> │ │ (ATmega644) Target MCU // atmega644p bei mir │ │ (20000000) MCU frequency // 20MHz Quarz │ │ [ ] VFS (Virtual File System) support // Benötige ich hier nicht. │ │ [*] control6 script // Hier wird unsere DS1820 Temperatur in eine Variable geschrieben für den implementieren Webserver. │ │ Network ---> // WICHTIG: IP, MAC Adresse, Gateway, Netmask, Hostname MUSS gleich sein wie bei dem Bootloader! │ │ Hostname: "esex060" │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" │ │ Netmask: "255.255.255.0" │ │ │ │ Default gateway: "192.168.123.10" │ │ I/O ---> │ │ [*] Onewire support ---> // Die allgemeine Onewire Unterstützung. │ │ [*] Onewire device detection support // Automatische Bauteilerkennung In der etherrape.m4 Datei wird nun noch der Pin des atmega geändert wo der DS1820 angeschlossen ist. Im NANO Editor wird mit "STRG-O dann Enter" gespeichert und mit STRG-X beendet. # nano pinning/hardware/etherrape.m4 // editieren der m4 Datei ----- ONEWIRE PIN ändern bei "ONEWIRE_PORT_RANGE(PD6, PD6)" zb. auf PD0 ----- Nun schreiben wir uns ein Script welches den Temperatursensor regelmäßig abfragt und in eine Globale Variable schiebt. # rm control6/control6.src // Original Datei löschen # nano control6/control6.src // Anlegen der c6 Datei. Die Datei ist nun neu und leer. C6_HEADER(`/* This will be in control6.h */') CONTROL_START ECMD_GLOBAL(temp01, 0, uint16_t); THREAD(start) temp01 = ONEWIRE_GET(1054698802080017); // Die ID muss vorher aus dem Sensor ausgelesen werden. Erklärung ganz am Schluss. WAIT(5) THREAD_END(start) ON STARTUP DO THREAD_START(start) END CONTROL_END Kompilieren der eigentlichen Firmware. # make clean && make // Befehl zum bereinigen & kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 24072/65536 bytes (36.73%) [===========-------------------] Program (.text + .data) : 24072 bytes Data (.data + .bss) : 2250 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.bin</b> Die eigentliche Firmware ist nun kompiliert und fertig um via Netzwerk/tftpd aufgespielt zu werden. Ich verwende im folgenden Schritt Windows 7. Beschreibung im nächsten Schritt. ===Firmware flashen via TFTPD=== <div><ul> <li style="display: inline-block;"> [[File:Tftpd_tempmess01.png|thumb|none|130px|tftpd Bild 1]] </li> <li style="display: inline-block;"> [[File:Tftpd_tempmess02.png|thumb|none|130px|tftpd Bild 2]] </li> <li style="display: inline-block;"> [[File:Tftpd_tempmess03.png|thumb|none|200px|tftpd Bild 3]] </li> <li style="display: inline-block;"> [[File:Tftpd_tempmess04.png|thumb|none|180px|tftpd Bild 4]] </li> </ul></div> Nun ladet ihr euch [http://tftpd32.jounin.net/tftpd32_download.html tftpd] herunter und entpackt es. Ich habe dazu einen Ordner Namens "tftpd" in mein Benutzerverzeichnis "C:\Users\BANANE\tftpd\". Dort wird alles hinein kopiert.<br> Es muss eigentlich nicht viel eingestellt werden. Unter <b>GLOBAL</b> muss TFTP aktiviert sein und unter <b>TFTP</b> sollte das "Base Directory" angepasst werden. Eventuell noch die Bind IP berichtigen. Seht Ihr ja auf den Fotos. Jetzt das Programm noch einmal neu starten. * Mikrocontrollerplatine ist <b>abgesteckt</b>. * tftpd starten * die Datei vom vorigen Schritt in den tftpd Ordner kopieren. <b>ethersex.bin</b> * ethersex.bin umbenennen in "<b>esex060.bin</b>". * Mikrocontrollerplatine Einstecken. Jetzt sollte auch schon was passieren, wie auf Bild 4 zu sehen ist. * Der Mikrocontroller ist nun via Webinterface erreichbar. Es können nur ecmd Befehle entgegengenommen werden. * erste Testverbindung zu unserem Mikrocontroller - http://192.168.123.60/ecmd?help ----AUSGABE---- c6 get c6 set wdreset .... 1w list 1w get 1w convert help version * <b>Sollten wir eine neue Firmware kompiliert haben können wir den Controller via Webinterface neu starten. Befehl dazu ist "wdreset"</b>. * Also neue esex060.bin wieder in den tftpd Ordner kopieren, tftpd starten und via Web "wdreset" ausführen. * http://192.168.123.60/ecmd?wdreset * Nun ladet sich der Controller die esex060.bin wieder via tftpd. ===Hinweise=== ''- Bei meiner Firewall musste ich tftpd noch akzeptieren. tftpd hing beim ersten mal in einer Schleife.'' ''- Und nochmals via Netzwerk wird die .bin geflasht, nicht die .hex Datei!'' =ONEWIRE= ===Auslesen der Sensor ID=== * Die ID kann via Webinterface mit dem Befehl "1w list" ausgelesen werden. * [http://192.168.123.60/ecmd?1w%20list http://192.168.123.60/ecmd?1w list] ----AUSGABE---- 1054698802080017 OK * Nun könnt Ihr die richtige ID oben im Control6 Script einsetzten und die Firmware neu kompilieren. * Wir haben im C6 Script eine Temperatur variable definiert welche "temp01" lautet. * Aktualisiert wird die Variable alle 5 Sekunden, das ist ebenfalls im C6 Script angegeben. * Diese kann ich nun via Webinterface abfragen - [http://192.168.123.60/ecmd?c6%20get%20temp01 http://192.168.123.60/ecmd?c6 get temp01] ----AUSGABE---- temp01 241 // 24.1 Grad [[User_talk:Djmaster#1 | Todoliste]] [[Category:Tutorials]] 0df2c34f76e60b3bcd9719d80985d1eaed8808e7 6 555 1713 2016-04-13T20:57:42Z Alez 726 A tiny board similar to Pollin's Avr-Net-Io wikitext text/x-wiki A tiny board similar to Pollin's Avr-Net-Io caa6b5f700616ddf7c80f80aae7ca0f3872645d7 0 457 1714 1512 2016-04-13T20:59:36Z Alez 726 added mae1061 board wikitext text/x-wiki {{i18n|Supported Boards}} == Commercial Products == <gallery> Etherrape.jpg | [[Etherrape | Etherrape]] by lochraster.org Jackalope.jpg | [[Jackalope | Jackalope]] by lochraster.org Radig.jpg | [[AVR Webmodul | AVR Webmodul]] by lrich Radig Avr-net-io.jpg | [[AVR-NET-IO | AVR-NET-IO]] by Pollin Funk-avr-eval.jpg | [[Funk-AVR-Evaluationsboard | Funk-AVR-Evaluationsboard]] by Pollin Conrad-probot.jpg | [[Conrad Probot | Conrad Probot]] by Conrad Fimser.jpg | [[Fimser | Fimser]] by OV Lennestadt Jeelinkv2.jpg | [[JeeLink | JeeLink]] by JeeLabs </gallery> == DIY Hardware == <gallery> Fhem_wz_01.jpg | [[Nutzung_in_FHEM | FHEM]] [[FHEM_Wohnzimmer | Roomnode #1]] Fhem_ku_01.jpg | [[Nutzung_in_FHEM | FHEM]] [[FHEM_Kueche | Roomnode #2]] Fhem_ke_01.jpg | [[Nutzung_in_FHEM | FHEM]] [[FHEM_Keller | Roomnode #3]] Zbus_testboard.jpg | [[ZBus|ZBus]][[ZBus_Testboard | Testboard]] ZBus-Board 01.jpg | [[ZBus|ZBus]][[ZBus_Board_1_0 | Board 1.0]] Bw_final.jpg | bed guard Atmega162-usb.jpg | ATmega162 with USB Usb2zbus-i2c.jpg | USB to [[ZBus | ZBus]] Dongle Pumpensteuerung.jpg | Jochen's pump control Ethmega.jpg | ths' ATmega64+ (SMD) Usbonly_atmega32+i2c_pcf8574_auf_steckbrett.jpg | USB-Ethersex with [[I2C| I2C]] and port extension Chaotischer-aufbau.jpg | Pollin AVR-NET-IO with add ons Ethersex-Avrnet-GPA.jpg | Pollin AVR-NET-IO based outlet control center Resetbox_proto_01.jpg | [[Resetbox | Resetbox]] Habo_bulbdial_clock.jpg | [[Bulbdial Clock | Bulbdial Clock]] Ftdi-lochraster.jpg | Atmega168p with USB connector via FT232R Ehaserl-badge-eh2010.jpg | [[ehaserl|ehaserl]] Badge des easter(h)egg 2010 maetech-it-mae1061_1.jpg | [[mae1061|mae1061]] Tiny board similar to Pollin Avr-Net-Io </gallery> [[Category:Ethersex]] [[Category:Hardware]] 92ca7d0c0a8de3dcfe661b1cf7fa2a6b43859354 1724 1714 2016-08-23T11:43:13Z GooPie4o 265 /* DIY Hardware */ wikitext text/x-wiki {{i18n|Supported Boards}} == Commercial Products == <gallery> Etherrape.jpg | [[Etherrape | Etherrape]] by lochraster.org Jackalope.jpg | [[Jackalope | Jackalope]] by lochraster.org Radig.jpg | [[AVR Webmodul | AVR Webmodul]] by lrich Radig Avr-net-io.jpg | [[AVR-NET-IO | AVR-NET-IO]] by Pollin Funk-avr-eval.jpg | [[Funk-AVR-Evaluationsboard | Funk-AVR-Evaluationsboard]] by Pollin Conrad-probot.jpg | [[Conrad Probot | Conrad Probot]] by Conrad Fimser.jpg | [[Fimser | Fimser]] by OV Lennestadt Jeelinkv2.jpg | [[JeeLink | JeeLink]] by JeeLabs </gallery> == DIY Hardware == <gallery> Fhem_wz_01.jpg | [[Nutzung_in_FHEM | FHEM]] [[FHEM_Wohnzimmer | Roomnode #1]] Fhem_ku_01.jpg | [[Nutzung_in_FHEM | FHEM]] [[FHEM_Kueche | Roomnode #2]] Fhem_ke_01.jpg | [[Nutzung_in_FHEM | FHEM]] [[FHEM_Keller | Roomnode #3]] Zbus_testboard.jpg | [[ZBus|ZBus]][[ZBus_Testboard | Testboard]] ZBus-Board 01.jpg | [[ZBus|ZBus]][[ZBus_Board_1_0 | Board 1.0]] Bw_final.jpg | bed guard Atmega162-usb.jpg | ATmega162 with USB Usb2zbus-i2c.jpg | USB to [[ZBus | ZBus]] Dongle Pumpensteuerung.jpg | Jochen's pump control Ethmega.jpg | ths' ATmega64+ (SMD) Usbonly_atmega32+i2c_pcf8574_auf_steckbrett.jpg | USB-Ethersex with [[I2C| I2C]] and port extension Chaotischer-aufbau.jpg | Pollin AVR-NET-IO with add ons Ethersex-Avrnet-GPA.jpg | Pollin AVR-NET-IO based outlet control center Resetbox_proto_01.jpg | [[Resetbox | Resetbox]] Habo_bulbdial_clock.jpg | [[Bulbdial Clock | Bulbdial Clock]] Ftdi-lochraster.jpg | Atmega168p with USB connector via FT232R Ehaserl-badge-eh2010.jpg | [[ehaserl|ehaserl]] Badge des easter(h)egg 2010 maetech-it-mae1061_1.jpg | [[mae1061|mae1061]] Tiny board similar to Pollin Avr-Net-Io meduino_with_enc.jpg | [https://www.arduino.cc/ Ardunio] [http://wiki.epalsite.com/index.php?title=Mega2560_Pro_Mini Mega2560 Pro Mini] with [[ENC28J60 | Microchip's ENC28J60]] </gallery> [[Category:Ethersex]] [[Category:Hardware]] d29ecd9c5003c7e3012c8592b27792ed1a8c5bd0 0 556 1715 2016-04-13T21:05:41Z Alez 726 Created page with "mae1061 - tiny board similar to Pollin Avr-Net-Io by Alessandro Mauro see the page at [http://maetech.it/doku.php?id=projects:mini-ethersex-board] Key features: * Mounts..." wikitext text/x-wiki mae1061 - tiny board similar to Pollin Avr-Net-Io by Alessandro Mauro see the page at [http://maetech.it/doku.php?id=projects:mini-ethersex-board] Key features: * Mounts ATmega32, can also mount ATmega64; * Form factor fits in a 2-modules-width DIN box; * Ethernet 10Mbps (ENC28J60); * 1 RS485 through screw 5mm connector with optional polarization and termination; * 2 opto-isolated dc-input through screw 5mm connector; * 1 low-voltage, low-current relay output through screw 5mm connector; * 1 internal i/o line on a 2 pin header that can be used for a OneWire sensor, or a configuration Jumper, or other; * 12V power supply through screw 5mm connector. compiled Ethersex using Pollin Avr-Net-Io basic configuration; just few patches are needed for the RS485 to work. 444ad487984be16a01c8d02f488d2e55c9bb9433 1716 1715 2016-04-13T21:07:25Z Alez 726 wikitext text/x-wiki mae1061 - tiny board similar to Pollin Avr-Net-Io [[File:maetech-it-mae1061_1.jpg|500px]] by Alessandro Mauro see the page at [http://maetech.it/doku.php?id=projects:mini-ethersex-board] Key features: * Mounts ATmega32, can also mount ATmega64; * Form factor fits in a 2-modules-width DIN box; * Ethernet 10Mbps (ENC28J60); * 1 RS485 through screw 5mm connector with optional polarization and termination; * 2 opto-isolated dc-input through screw 5mm connector; * 1 low-voltage, low-current relay output through screw 5mm connector; * 1 internal i/o line on a 2 pin header that can be used for a OneWire sensor, or a configuration Jumper, or other; * 12V power supply through screw 5mm connector. compiled Ethersex using Pollin Avr-Net-Io basic configuration; just few patches are needed for the RS485 to work. ca07d90952ed73cdc51187da50b7556b5faf3d5d 1718 1716 2016-04-14T20:01:52Z Alez 726 wikitext text/x-wiki mae1061 - tiny board similar to Pollin Avr-Net-Io [[File:maetech-it-mae1061_1.jpg|500px]] by Alessandro Mauro see the page at [http://www.maetech.it/doku.php?id=projects:mini-ethersex-board] Key features: * Mounts ATmega32, can also mount ATmega64; * Form factor fits in a 2-modules-width DIN box; * Ethernet 10Mbps (ENC28J60); * 1 RS485 through screw 5mm connector with optional polarization and termination; * 2 opto-isolated dc-input through screw 5mm connector; * 1 low-voltage, low-current relay output through screw 5mm connector; * 1 internal i/o line on a 2 pin header that can be used for a OneWire sensor, or a configuration Jumper, or other; * 12V power supply through screw 5mm connector. compiled Ethersex using Pollin Avr-Net-Io basic configuration; just few patches are needed for the RS485 to work. e382da139c5e150f55b433872f08bf8944822a73 1719 1718 2016-04-14T20:03:01Z Alez 726 wikitext text/x-wiki mae1061 - tiny board similar to Pollin Avr-Net-Io [[File:maetech-it-mae1061_1.jpg|500px]] by Alessandro Mauro see the page at [http://www.maetech.it/doku.php?id=projects:mini-ethersex-board] Key features: * Mounts ATmega32, can also mount ATmega64; * Form factor fits in a 2-modules-width DIN box; * Ethernet 10Mbps (ENC28J60); * 1 RS485 through screw 5mm connector with optional polarization and termination; * 2 opto-isolated dc-input through screw 5mm connector; * 1 low-voltage, low-current relay output through screw 5mm connector; * 1 internal i/o line on a 2 pin header that can be used for a OneWire sensor, or a configuration Jumper, or other; * 12V power supply through screw 5mm connector. compiled Ethersex using Pollin Avr-Net-Io basic configuration; just few patches are needed for the RS485 to work. '''''If you are interested in this, contact me at''''' alez at maetech dot it . f3d6a52d9a036bf05ec33dec7163eaa33fc0937c 0 412 1717 1511 2016-04-13T21:08:22Z Alez 726 /* Eigenbau Hardware */ wikitext text/x-wiki {{i18n|Supported Boards}} == Kommerzielle Produkte == <gallery> Etherrape.jpg | [[Etherrape_(Deutsch) | Etherrape]] von lochraster.org Jackalope.jpg | [[Jackalope_(Deutsch) | Jackalope]] von lochraster.org Radig.jpg | [[AVR Webmodul_(Deutsch) | AVR Webmodul]] von Ulrich Radig Avr-net-io.jpg | [[AVR-NET-IO_(Deutsch) | AVR-NET-IO]] von Pollin Funk-avr-eval.jpg | [[Funk-AVR-Evaluationsboard_(Deutsch) | Funk-AVR-Evaluationsboard]] von Pollin Conrad-probot.jpg | [[Conrad Probot_(Deutsch) | Conrad Probot]] von Conrad Fimser.jpg | [[Fimser_(Deutsch) | Fimser]] vom OV Lennestadt Jeelinkv2.jpg | [[JeeLink_(Deutsch) | JeeLink]] von JeeLabs </gallery> == Eigenbau Hardware == <gallery> Fhem_wz_01.jpg | [[Nutzung_in_FHEM_(Deutsch) | FHEM]] [[FHEM_Wohnzimmer_(Deutsch) | Roomnode #1]] Fhem_ku_01.jpg | [[Nutzung_in_FHEM_(Deutsch) | FHEM]] [[FHEM_Kueche_(Deutsch) | Roomnode #2]] Fhem_ke_01.jpg | [[Nutzung_in_FHEM_(Deutsch) | FHEM]] [[FHEM_Keller_(Deutsch) | Roomnode #3]] Zbus_testboard.jpg | [[ZBus_(Deutsch)|ZBus]][[ZBus_Testboard_(Deutsch) | Testboard]] ZBus-Board 01.jpg | [[ZBus_(Deutsch)|ZBus]][[ZBus_Board_1_0_(Deutsch) | Board 1.0]] Bw_final.jpg | Bettwächter Atmega162-usb.jpg | ATmega162 mit USB Usb2zbus-i2c.jpg | USB to [[ZBus_(Deutsch) | ZBus]] Dongle Pumpensteuerung.jpg | Jochens Pumpensteuerung Ethmega.jpg | ths' ATmega64+ (SMD) Usbonly_atmega32+i2c_pcf8574_auf_steckbrett.jpg | USB-Ethersex mit [[I2C_(Deutsch) | I2C]] und Porterweiterung Chaotischer-aufbau.jpg | Pollins AVR-NET-IO und Erweiterungen Ethersex-Avrnet-GPA.jpg | Pollins AVR-NET-IO Steckdosenschaltzentrale Resetbox_proto_01.jpg | [[Resetbox_(Deutsch) | Resetbox]] Habo_bulbdial_clock.jpg | [[Bulbdial Clock_(Deutsch) | Bulbdial Clock]] Ftdi-lochraster.jpg | Atmega168p mit USB-Anschluss über FT232R Ehaserl-badge-eh2010.jpg | [[ehaserl_(Deutsch)|ehaserl]] Badge des easter(h)egg 2010 maetech-it-mae1061_1.jpg | [[mae1061|mae1061]] Tiny board similar to Pollin Avr-Net-Io </gallery> [[Category:Ethersex]] [[Category:Hardware]] 4093f9a9c9c4fad702a293ce9f39b6a19e983f76 1725 1717 2016-08-23T11:43:46Z GooPie4o 265 /* Eigenbau Hardware */ wikitext text/x-wiki {{i18n|Supported Boards}} == Kommerzielle Produkte == <gallery> Etherrape.jpg | [[Etherrape_(Deutsch) | Etherrape]] von lochraster.org Jackalope.jpg | [[Jackalope_(Deutsch) | Jackalope]] von lochraster.org Radig.jpg | [[AVR Webmodul_(Deutsch) | AVR Webmodul]] von Ulrich Radig Avr-net-io.jpg | [[AVR-NET-IO_(Deutsch) | AVR-NET-IO]] von Pollin Funk-avr-eval.jpg | [[Funk-AVR-Evaluationsboard_(Deutsch) | Funk-AVR-Evaluationsboard]] von Pollin Conrad-probot.jpg | [[Conrad Probot_(Deutsch) | Conrad Probot]] von Conrad Fimser.jpg | [[Fimser_(Deutsch) | Fimser]] vom OV Lennestadt Jeelinkv2.jpg | [[JeeLink_(Deutsch) | JeeLink]] von JeeLabs </gallery> == Eigenbau Hardware == <gallery> Fhem_wz_01.jpg | [[Nutzung_in_FHEM_(Deutsch) | FHEM]] [[FHEM_Wohnzimmer_(Deutsch) | Roomnode #1]] Fhem_ku_01.jpg | [[Nutzung_in_FHEM_(Deutsch) | FHEM]] [[FHEM_Kueche_(Deutsch) | Roomnode #2]] Fhem_ke_01.jpg | [[Nutzung_in_FHEM_(Deutsch) | FHEM]] [[FHEM_Keller_(Deutsch) | Roomnode #3]] Zbus_testboard.jpg | [[ZBus_(Deutsch)|ZBus]][[ZBus_Testboard_(Deutsch) | Testboard]] ZBus-Board 01.jpg | [[ZBus_(Deutsch)|ZBus]][[ZBus_Board_1_0_(Deutsch) | Board 1.0]] Bw_final.jpg | Bettwächter Atmega162-usb.jpg | ATmega162 mit USB Usb2zbus-i2c.jpg | USB to [[ZBus_(Deutsch) | ZBus]] Dongle Pumpensteuerung.jpg | Jochens Pumpensteuerung Ethmega.jpg | ths' ATmega64+ (SMD) Usbonly_atmega32+i2c_pcf8574_auf_steckbrett.jpg | USB-Ethersex mit [[I2C_(Deutsch) | I2C]] und Porterweiterung Chaotischer-aufbau.jpg | Pollins AVR-NET-IO und Erweiterungen Ethersex-Avrnet-GPA.jpg | Pollins AVR-NET-IO Steckdosenschaltzentrale Resetbox_proto_01.jpg | [[Resetbox_(Deutsch) | Resetbox]] Habo_bulbdial_clock.jpg | [[Bulbdial Clock_(Deutsch) | Bulbdial Clock]] Ftdi-lochraster.jpg | Atmega168p mit USB-Anschluss über FT232R Ehaserl-badge-eh2010.jpg | [[ehaserl_(Deutsch)|ehaserl]] Badge des easter(h)egg 2010 maetech-it-mae1061_1.jpg | [[mae1061|mae1061]] Tiny board similar to Pollin Avr-Net-Io meduino_with_enc.jpg | [https://www.arduino.cc/ Ardunio] [http://wiki.epalsite.com/index.php?title=Mega2560_Pro_Mini Mega2560 Pro Mini] mit[[ENC28J60 | Microchip's ENC28J60]] </gallery> [[Category:Ethersex]] [[Category:Hardware]] c57a15aa43a61db8fb43dc37872cf2c58ebd4a59 1726 1725 2016-08-23T11:46:10Z GooPie4o 265 /* Eigenbau Hardware */ wikitext text/x-wiki {{i18n|Supported Boards}} == Kommerzielle Produkte == <gallery> Etherrape.jpg | [[Etherrape_(Deutsch) | Etherrape]] von lochraster.org Jackalope.jpg | [[Jackalope_(Deutsch) | Jackalope]] von lochraster.org Radig.jpg | [[AVR Webmodul_(Deutsch) | AVR Webmodul]] von Ulrich Radig Avr-net-io.jpg | [[AVR-NET-IO_(Deutsch) | AVR-NET-IO]] von Pollin Funk-avr-eval.jpg | [[Funk-AVR-Evaluationsboard_(Deutsch) | Funk-AVR-Evaluationsboard]] von Pollin Conrad-probot.jpg | [[Conrad Probot_(Deutsch) | Conrad Probot]] von Conrad Fimser.jpg | [[Fimser_(Deutsch) | Fimser]] vom OV Lennestadt Jeelinkv2.jpg | [[JeeLink_(Deutsch) | JeeLink]] von JeeLabs </gallery> == Eigenbau Hardware == <gallery> Fhem_wz_01.jpg | [[Nutzung_in_FHEM_(Deutsch) | FHEM]] [[FHEM_Wohnzimmer_(Deutsch) | Roomnode #1]] Fhem_ku_01.jpg | [[Nutzung_in_FHEM_(Deutsch) | FHEM]] [[FHEM_Kueche_(Deutsch) | Roomnode #2]] Fhem_ke_01.jpg | [[Nutzung_in_FHEM_(Deutsch) | FHEM]] [[FHEM_Keller_(Deutsch) | Roomnode #3]] Zbus_testboard.jpg | [[ZBus_(Deutsch)|ZBus]][[ZBus_Testboard_(Deutsch) | Testboard]] ZBus-Board 01.jpg | [[ZBus_(Deutsch)|ZBus]][[ZBus_Board_1_0_(Deutsch) | Board 1.0]] Bw_final.jpg | Bettwächter Atmega162-usb.jpg | ATmega162 mit USB Usb2zbus-i2c.jpg | USB to [[ZBus_(Deutsch) | ZBus]] Dongle Pumpensteuerung.jpg | Jochens Pumpensteuerung Ethmega.jpg | ths' ATmega64+ (SMD) Usbonly_atmega32+i2c_pcf8574_auf_steckbrett.jpg | USB-Ethersex mit [[I2C_(Deutsch) | I2C]] und Porterweiterung Chaotischer-aufbau.jpg | Pollins AVR-NET-IO und Erweiterungen Ethersex-Avrnet-GPA.jpg | Pollins AVR-NET-IO Steckdosenschaltzentrale Resetbox_proto_01.jpg | [[Resetbox_(Deutsch) | Resetbox]] Habo_bulbdial_clock.jpg | [[Bulbdial Clock_(Deutsch) | Bulbdial Clock]] Ftdi-lochraster.jpg | Atmega168p mit USB-Anschluss über FT232R Ehaserl-badge-eh2010.jpg | [[ehaserl_(Deutsch)|ehaserl]] Badge des easter(h)egg 2010 maetech-it-mae1061_1.jpg | [[mae1061|mae1061]] Tiny board similar to Pollin Avr-Net-Io meduino_with_enc.jpg | [https://www.arduino.cc/ Ardunio] [http://wiki.epalsite.com/index.php?title=Mega2560_Pro_Mini Mega2560 Pro Mini] mit[[ENC28J60_(Deutsch)| Microchip's ENC28J60]] </gallery> [[Category:Ethersex]] [[Category:Hardware]] c7ce0836165832615eba796cc49ccb2e7797a07f 1728 1726 2016-08-23T11:49:40Z GooPie4o 265 /* Eigenbau Hardware */ wikitext text/x-wiki {{i18n|Supported Boards}} == Kommerzielle Produkte == <gallery> Etherrape.jpg | [[Etherrape_(Deutsch) | Etherrape]] von lochraster.org Jackalope.jpg | [[Jackalope_(Deutsch) | Jackalope]] von lochraster.org Radig.jpg | [[AVR Webmodul_(Deutsch) | AVR Webmodul]] von Ulrich Radig Avr-net-io.jpg | [[AVR-NET-IO_(Deutsch) | AVR-NET-IO]] von Pollin Funk-avr-eval.jpg | [[Funk-AVR-Evaluationsboard_(Deutsch) | Funk-AVR-Evaluationsboard]] von Pollin Conrad-probot.jpg | [[Conrad Probot_(Deutsch) | Conrad Probot]] von Conrad Fimser.jpg | [[Fimser_(Deutsch) | Fimser]] vom OV Lennestadt Jeelinkv2.jpg | [[JeeLink_(Deutsch) | JeeLink]] von JeeLabs </gallery> == Eigenbau Hardware == <gallery> Fhem_wz_01.jpg | [[Nutzung_in_FHEM_(Deutsch) | FHEM]] [[FHEM_Wohnzimmer_(Deutsch) | Roomnode #1]] Fhem_ku_01.jpg | [[Nutzung_in_FHEM_(Deutsch) | FHEM]] [[FHEM_Kueche_(Deutsch) | Roomnode #2]] Fhem_ke_01.jpg | [[Nutzung_in_FHEM_(Deutsch) | FHEM]] [[FHEM_Keller_(Deutsch) | Roomnode #3]] Zbus_testboard.jpg | [[ZBus_(Deutsch)|ZBus]][[ZBus_Testboard_(Deutsch) | Testboard]] ZBus-Board 01.jpg | [[ZBus_(Deutsch)|ZBus]][[ZBus_Board_1_0_(Deutsch) | Board 1.0]] Bw_final.jpg | Bettwächter Atmega162-usb.jpg | ATmega162 mit USB Usb2zbus-i2c.jpg | USB nach [[ZBus_(Deutsch) | ZBus]] Dongle Pumpensteuerung.jpg | Jochens Pumpensteuerung Ethmega.jpg | ths' ATmega64+ (SMD) Usbonly_atmega32+i2c_pcf8574_auf_steckbrett.jpg | USB-Ethersex mit [[I2C_(Deutsch) | I2C]] und Porterweiterung Chaotischer-aufbau.jpg | Pollins AVR-NET-IO und Erweiterungen Ethersex-Avrnet-GPA.jpg | Pollins AVR-NET-IO Steckdosenschaltzentrale Resetbox_proto_01.jpg | [[Resetbox_(Deutsch) | Resetbox]] Habo_bulbdial_clock.jpg | [[Bulbdial Clock_(Deutsch) | Bulbdial Clock]] Ftdi-lochraster.jpg | Atmega168p mit USB-Anschluss über FT232R Ehaserl-badge-eh2010.jpg | [[ehaserl_(Deutsch)|ehaserl]] Badge des easter(h)egg 2010 maetech-it-mae1061_1.jpg | [[mae1061|mae1061]] Tiny board similar to Pollin Avr-Net-Io meduino_with_enc.jpg | [https://www.arduino.cc/ Ardunio] [http://wiki.epalsite.com/index.php?title=Mega2560_Pro_Mini Mega2560 Pro Mini] mit[[ENC28J60_(Deutsch)| Microchip's ENC28J60]] </gallery> [[Category:Ethersex]] [[Category:Hardware]] f8a6ab0502ce55acdb919fa994ca4c914662d913 0 390 1720 1504 2016-06-01T09:40:58Z Tobox 727 /* BMP085/BMP180 Luftdrucksensor */ wikitext text/x-wiki {{i18n|Nutzung in FHEM}} [http://www.fhemwiki.de/wiki/Hauptseite FHEM] ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um diverse per Funk und Kabel angebundene Komponenten aus dem Bereich der Hausautomation zu steuern. Er ist lizensiert unter der GPL v2. Das [http://www.pollin.de/shop/suchergebnis.html?S_TEXT=810+058 AVR-Net-IO] von [http://www.pollin.de Pollin] mit [[Ethersex]] dient als [http://www.fhemwiki.de/wiki/AVR-NET-IO preisgünstiger Einstieg in die Hausautomatisierung]. Verwendbar ist aber auch jede andere [[Supported_Boards_(Deutsch) | Hardware]], die von Ethersex unterstützt wird (Arduino, eigene Entwicklungen, etc.). Über [[ECMD]] lassen sich dabei theoretisch alle in [[Ethersex]] vorhandenen [[ECMD_Protocols_%28Deutsch%29 | Möglichkeiten]] nutzen, sofern in FHEM entsprechende [http://fhem.de/commandref.html#ECMD ECMD-Devices] definiert und eingebunden werden, die passende Klassendefinition exisitert und die Aktion ausgelöst wird. == Grundlagen == Ausgehend von einem fertigen und per Telnet erreichbaren Ethersex muss in FHEM zuerst das entsprechende Device definiert werden. <pre> define NETIO_WZ ECMD telnet 192.168.3.81:2701 </pre> Eine serielle Anbindung kann mit ''define <name> ECMD serial <SerialDevice>[<@BaudRate>]'' alternativ erfolgen. Anschließend werden die erstellten .classdef-Konfigurationsdateien der einzelnen Funktionen dem System bekannt gemacht. In diesen .classdef-Dateien (Name und Endung sind frei wählbar!) wird die Schnittstelle zwischen FHEM und ECMD/Ethersex definiert. Dabei können mit perl übergebene Parameter und empfangene Daten bearbeitet sowie die in FHEM gebräuchlichen Readings erstellt werden. <pre> attr NETIO_WZ classdefs RFM12_2272=/opt/fhem/FHEM/rfm12_2272.classdef:RFM12_IT=/opt/fhem/FHEM/rfm12_it.classdef:LCD=/opt/fhem/FHEM/lcd.classdef:DHT22=/opt/fhem/FHEM/dht22.classdef:1WIRE=/opt/fhem/FHEM/1wire.classdef </pre> Die Definitionen für IC2272, Intertechno, HD44780-LCD, DHT22 und 1wire sind nun eingebunden. In den folgenden Abschnitten wird auf die einzelnen Devices näher eingegangen. Generell sind Pfade und IP-Adressen sowie übergebene Parameter noch entsprechend der eigenen Konfiguration anzupassen. == [[Onewire_(Deutsch) | 1-Wire Temperatursensoren]] == [[File:DS18B20.jpg|150px|thumb|right|DS18B20-Sensoren]] Die 1wire-Temperatursensoren DS18B20 oder DS18S20 werden im [[Onewire_(Deutsch)#Polling_Modus | Polling Modus]] abgefragt. Das macht die zyklische Abfrage aus FHEM heraus wesentlich einfacher. Eine Polling-Zeit von mindestens 30 Sekunden ist absolut ausreichend.Im Vorfeld sollte man sich die [[Onewire_(Deutsch)#Benennung_von_Sensoren | ROM-Codes der Sensoren]] notieren, da diese nachher benötigt werden. 1w-temp.classdef erstellen: <source lang="perl"> # Uebergabeparameter Onewire Rom-Code params devID # Umsetzung in ECMD Befehle 1w get = Temperatur auslesen get 1W cmd {"1w get %devID\n"} get 1W expect "\d+.\d+\n" get 1W postproc {\ s/\n//g;\ my $hash = $defs{%NAME};\ my $temperature = $_;\ my $state = "T: $temperature";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die classdef wird eingebunden: <pre> define NETIO_KU ECMD telnet 192.168.3.82:2701 attr NETIO_KU classdefs 1W-TEMP=/opt/fhem/FHEM/1w-temp.classdef </pre> Die Sensoren werden anhand des ROM-Code definiert: <pre> define HZ_WW ECMDDevice 1W-TEMP 284c8820050003d4 attr HZ_WW IODev NETIO_KU define HZ_VL ECMDDevice 1W-TEMP 2890a520050003d7 attr HZ_VL IODev NETIO_KU </pre> Eine zyklische Messung pro Minute lässt sich in dieser Form auslösen: <pre> define Messung_1w at +*00:01 get HZ_WW 1W;; get HZ_VL 1W attr Messung_1w verbose 0 </pre> == [[DHT|DHT22 Temperatur-/Feuchtesensoren]] == [[File:DHT22.jpg|150px|thumb|right|DHT22-Sensoren]] [[Ethersex]] unterstützt die preiswerten Temperatur-/Feuchtesensoren [[DHT|DHT11 und DHT22]], wobei letztere [[DHT#DHT11_vs_DHT22|um einiges genauer sind]]. Die Sensoren benötigen 5V Betriebsspannung und kommunizieren über je einen Pin mit dem Prozessor. Der Preis pro Stück liegt derzeit bei etwa 3.50 Euro (ebay/China). Wer die Trägheit und Ungenauigkeit der S300TH oder TX29DTH kennt, wünscht sich vermutlich Besseres; vor allem bei Berechnung von [http://de.wikipedia.org/wiki/Taupunkt Taupunkt] und [http://de.wikipedia.org/wiki/Luftfeuchtigkeit#Absolute_Luftfeuchtigkeit absoluter Feuchte], welche von der Genauigkeit der gemessenen Eingangsgrößen sehr profitieren. Berechnungen von Hand kann man beim [http://www.wetterochs.de/wetter/feuchte.html Wetterochs] durchführen. Die automatische Berechnung der absoluten Feuchte in FHEM wird im [http://forum.fhem.de/index.php/topic,21458.0.html Forum] erklärt. '''Einbindung in FHEM''' dht22m.classdef erstellen: <source lang="perl"> # Uebergabeparameter DHT22 ID 0...n params devID # Umsetzung in ECMD Befehle fuer DHT22 get DHT cmd {"dht temp %devID\n\000dht humid %devID\n"} get DHT expect "\d+.\d\n" get DHT postproc {\ s/(.*)\n(.*)\n/T: $1 H: $2/;\ my $hash = $defs{%NAME};\ my $temperature = $1;\ my $humidity = $2;\ my $state = $_;\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "humidity", $humidity, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs DHT22M=/opt/fhem/FHEM/dht22m.classdef </pre> Die Sensoren werden definiert: <pre> define Test0 ECMDDevice DHT22M 0 attr Test0 IODev NETIO_TEST define Test1 ECMDDevice DHT22M 1 attr Test1 IODev NETIO_TEST define Test2 ECMDDevice DHT22M 2 attr Test2 IODev NETIO_TEST define Test3 ECMDDevice DHT22M 3 attr Test3 IODev NETIO_TEST </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_DHT at +*00:04 get Test0 DHT;; get Test1 DHT;; get Test2 DHT;; get Test3 DHT attr Messung_DHT verbose 0 </pre> Fünfzehn Messwerte pro Stunde genügen den allermeisten Anforderungen. == [[BMP085 | BMP085/BMP180 Luftdrucksensor]] == [[File:BMP180.jpg|150px|thumb|right|BMP180 (unten links)]] Ethersex unterstützt den BMP085 (bzw. den BMP180; der Code ist identisch) über das [[I2C_(Deutsch) | I2C]]-Interface. Da der Sensor für 3.3V Betriebsspannung ausgelegt ist, muss entweder der I2C-Pegel angepasst oder der ATMega auf 3.3V adaptiert werden. Weiterhin sollte die Höhe über Null bekannt sein. Beispiel: Eine Abfrage per [[ECMD]] mit ''bmp085 pressnn 59000'' bedeutet, das ich 590m (59000cm) über NN wohne. Sollte der Befehl ''bmp085 pressnn'' aus Platzgründen nicht mehr in Image passen, kann man die Umrechnung auf Normal Null alternativ auch in der classdef erledigen. Die im Sensor verfügbare Temperatur wird parallel ausgelesen. '''Einbindung in FHEM''' bmp085.classdef erstellen, falls ''presnn'' unterstützt wird (59000 durch eigene Höhe in cm ersetzen!): <source lang="perl"> get BMP cmd {"bmp085 temp\n\000bmp085 pressnn 59000\n"} get BMP expect ".*" get BMP postproc {\ s/(.*)\n(.*)\n/T: $1 P: $2/;\ my $hash = $defs{%NAME};\ my $temperature = $1/10;\ my $pressure = sprintf("%.1f",$2/100);\ my $state = "T: $temperature P: $pressure";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "pressure", $pressure, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die Temperatur wird in °C mit einer Nachkommastelle gelesen, der Luftdruck in hPa bzw. mbar auf eine Nachkommastelle gerundet. Passende Readings werden erstellt. Das expect .* kann noch angepasst werden, um bei fehlerhaften Messwerten entsprechend zu reagieren. Die classdef wird in FHEM eingebunden (mehrere .classdef mit Doppelpunkt trennen: siehe [[Nutzung_in_FHEM_(Deutsch)#Grundlagen | Grundlagen]]): <pre> define NETIO_STK ECMD telnet 192.168.3.89:2701 attr NETIO_STK classdefs BMP=/opt/fhem/FHEM/bmp085.classdef </pre> Der Sensor wird definiert: <pre> define BMP180 ECMDDevice BMP attr BMP180 IODev NETIO_STK </pre> Das STATE ''kann'' mit Maßeinheiten versehen werden: <pre> attr BMP180 stateFormat { sprintf("%s°C %shPa", ReadingsVal("BMP180","temperature",0), ReadingsVal("BMP180","pressure",0)) ;; } </pre> Eine zyklische Messung alle 4 Minuten erfolgt wieder mit ''at'': <pre> define Messung_BMP at +*00:04 get BMP180 BMP attr Messung_BMP verbose 0 </pre> Dabei unterdrückt verbose 0 einen zusätzlichen (doppelten) Logeintrag des Messvorganges. Alternative bmp085.classdef, die die Umrechnung auf Normal Null in Perl macht (590 durch eigene Höhe in m ersetzen): <source lang="perl"> get pressure cmd {"bmp085 apress\n"} get pressure expect "\d+\n" get pressure postproc { s/(..)\n/.$1/; $_/=(1-(590/44330.7692))**5.255; $_ } get temp cmd {"bmp085 temp\n"} get temp expect "\d+\n" get temp postproc { s/(.)\n/.$1/; $_ } </source> Bei diesem Beispiel können Temperatur und Druck separat ausgelesen werden, hier ein Beispiel für das zyklische Auslesen beider Werte: <pre> define Messung_BMP at +*00:04 get BMP180 pressure ;; get BMP180 temp attr Messung_BMP verbose 0 </pre> Dabei unterdrückt verbose 0 einen zusätzlichen (doppelten) Logeintrag des Messvorganges. == analoge Eingänge abfragen == Die analogen Eingänge des ATMega sind recht simpel abzufragen. Dabei werden die hexadezimalen Werte gleich dezimal gewandelt, um die Weiterverarbeitung zu erleichtern. '''Einbindung in FHEM''' adc.classdef erstellen: <source lang="perl"> get value cmd {"adc get %PortID\n"} params PortID get value expect ".*" get value postproc {\ my $hexval = hex(trim("$_"));\ my $hash = $defs{%NAME};\ readingsSingleUpdate($hash, "state", $hexval, 1);\ } </source> Die classdef wird eingebunden: <pre> define NETIO_KU ECMD telnet 192.168.3.89:2701 attr NETIO_KU classdefs ADC=/opt/fhem/FHEM/adc.classdef </pre> Die Sensoren an den ersten beiden Ports werden definiert: <pre> define MP_0 ECMDDevice ADC 0 attr MP_0 IODev NETIO_KU define MP_1 ECMDDevice ADC 1 attr MP_1 IODev NETIO_KU </pre> Eine zyklische Messung alle 60 Sekunden funktioniert damit: <pre> define Messung_adc at +*00:01 get MP_0 value;; get MP_1 value attr Messung_adc verbose 0 </pre> == digitale Eingänge abfragen == todo == digitale Eingänge - proaktiv == Kontakte, die bei Zustandsänderung sofort in FHEM eine Meldung erzeugen sollen, kann man nicht zeitnah mit Polling abfragen. Diese Ereignisse, welche auch aus einem Control6-Script heraus generiert sein können, sollen selbst Meldung machen. Hierbei wird die ESEND-Funktion benutzt, mit welcher auch mehrere Ethersex'e untereinander kommunizieren können. Dabei ist es nicht relevant, ob das Device in FHEM per ECMDDevice bereits eingebunden wurde. Zuerst muss FHEM auf Port 2701 für Telnet-Verbindungen empfänglich werden: <pre> define telnetECMD telnet 2701 global </pre> Mit ''Watch io changes and react'' lässt sich per menuconfig bereits auf einfache Weise eine Abfrage von Portpins mit Generierung eines ESEND-Befehles bewerkstelligen. Das Beispiel soll zeigen, wie bei entsprechender Zustandsänderung an Pin PA0 an 192.168.178.10 ein FHEM-Befehl gesendet wird: <pre> ECMDTCP(PA0, RISING, 192.168.178.10, set Lampe on\n\n) ECMDTCP(PA0, FALLING, 192.168.178.10, set Lampe off\n\n) </pre> Jede Sequenz muss mit \n\n abgeschlossen werden, damit FHEM für weitere Befehle empfangsbereit bleibt. Falls man in FHEM flexibler bei der Weiterverarbeitung sein möchte, bietet sich eine dummy-notify-Kombination an. == [[Porterweiterungen_%28Deutsch%29#D.2FA-Wandler_mit_LTC1257 | LTC1257 D/A-Wandler]] == [[File:LTC1257.jpg|150px|thumb|right|LTC1257 Digital-Analog-Wandler innerhalb einer Schaltung]] Die 12bit Digital-Analog-Wandler von LINEAR TECHNOLOGY werden mit drei Pins bedient. Er wandelt (bei interner Referenzspannung) einen digital übermittelten Wert in eine Spannung von 0-2,048V um. Ein nachgeschalteter OPV als nichtinvertierender Verstärker kann diesen Bereich entsprechend skalieren. ltc1257.classdef erstellen: <source lang="perl"> # Umsetzung in ECMD Befehle # Ein Uebergabeparameter -> Sollwert set setDAC params dacValue set setDAC cmd {"ltc1257_set %dacValue\n"} set setDAC expect "OK\n" # Keine Uebergabeparameter set init cmd {"ltc1257_init\n"} set init expect "OK\n" # } </source> Die classdef wird eingebunden: <pre> define NETIO_KU ECMD telnet 192.168.3.82:2701 attr NETIO_KU classdefs LTC1257=/opt/fhem/FHEM/ltc1257.classdef </pre> Der LTC wird entsprechend definiert: <pre> define HZ_DAC ECMDDevice LTC1257 attr HZ_DAC IODev NETIO_KU </pre> Nun lässt sich mit einem '''set HZ_DAC init''' der LTC initialisieren (die gemessene Ausgangsspannung sollte 0V sein) und mit '''set HZ_DAC setDAC [0...4095]''' der gewünschte Wert setzen. Hier muss vorab experimentell entsprechend der nachfolgenden Beschaltung die tatsächliche Spannung ermittelt werden. == [[LCD_(Deutsch) | HD44780 Punktmatrixdisplays]] == [[File:HD44780.jpg|150px|thumb|right|verschiedene HD44780 Displays (16x1 bis 40x4)]] Die beliebten Punktmatrix-Displays auf Basis [http://de.wikipedia.org/wiki/HD44780 HD44780] können vollumfänglich in FHEM beschrieben werden. Dabei wird vorrausgesetzt, das in [https://github.com/ethersex/ethersex/blob/master/hardware/lcd/hd44780.h /hardware/lcd/hd44780.h] beim entsprechenden Modell die passende Adressierung der Zeilen und die genutzte Zeilen-/Spaltenzahl vor dem Compilieren angepasst wurde. '''Einbindung in FHEM''' lcd.classdef erstellen: <source lang="perl"> # Umsetzung der ECMD Befehle set write params line col text set write cmd {"lcd goto %line %col\n\000lcd write %text\n"} set write expect "OK\n" set write postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set clear params col set clear cmd {"lcd clear %col\n"} set clear expect "OK\n" set clear postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set clear_all cmd {"lcd clear\n"} set clear_all expect "OK\n" set clear_all postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set lcd_bl params state set lcd_bl cmd {"lcd backlight %state\n"} set lcd_bl expect "OK\n" set lcd_bl postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} </source> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs LCD=/opt/fhem/FHEM/lcd.classdef </pre> Das Display wird definiert: <pre> define WZ_LCD ECMDDevice LCD attr WZ_LCD IODev NETIO_TEST </pre> Es stehen in FHEM folgende Befehle für das LCD bereit: {| border='1' | ''Befehl'' | ''Funktion'' |- | set WZ_LCD clear [ZEILE] | löscht den Inhalt einer ZEILE (0...3) |- | set WZ_LCD clear_all | löscht den Inhalt aller Zeilen |- | set WZ_LCD lcd_bl STATE | schaltet die Hintergrundbeleuchtung ein oder aus (STATE on oder off) |- | set WZ_LCD write [ZEILE] [SPALTE] [TEXT] | schreibt einen TEXT auf Position ZEILE SPALTE (0...n) |- |} Da ein im TEXT übergebenes Leerzeichen als weiterer Befehl interpretiert wird und zu einer Fehlermeldung führt, ist eine Übergabe nur mit \x20 im Text möglich. Das gilt auch für Umlaute. Anhand der [http://de.wikipedia.org/wiki/HD44780#Schrift_und_Zeichensatz Zeichensatztabelle] lassen sich ä durch \xE1, ü durch \xF5 und ö durch \xEF darstellen. Das ß wird mit \xE2 erreicht. Die Tabelle kann für manche Displays abweichend sein.<br /> Beispiel: ''set WZ_LCD write 0 0 Fenster\x20schlie\xE2en'' schreibt ein '''Fenster schließen''' auf's LCD. '''Komfortable Nutzung in FHEM mit DLCD''' Mit dem DLCD-Modul ([http://www.fhemwiki.de/wiki/DLCD Wiki-Beitrag] / [http://forum.fhem.de/index.php/topic,24519.0.html Foren-Beitrag]) für FHEM lässt sich jedes Display auf einfache Weise beschreiben. Dabei lassen sich bequem Readings von allen Devices nutzen, aufbereiten (formatieren, umrechnen, etc.) und entsprechend darstellen. Eine genaue Beschreibung hält der Wiki-Beitrag bereit; hier soll ein Beispiel gezeigt werden. Ziel war es, auf einem 16x1 LCD wechselweise ''Datum/Zeit => Klimadaten Keller => Datum/Zeit => Klimadaten Garten'' darzustellen. Die Anzeige rotiert im 15-Sekunden-Takt, so das zu 50% Datum/Zeit und je 25% die Werte aus dem Garten und dem Keller angezeigt werden. Es wird bereits im Modul jedes Leerzeichen mit \x20 übersetzt. Der Außensensor ist ein [http://www.elv.de/elv-funk-kombi-wettersensor-ks-300-2-br-inkl-hochwertigem-2-m-edelstahlmast-br-und-qualitaetsbatterien.html KS300] (bzw. KS200) von ELV. Mit etwas Formatierung und ein paar Leerzeichen lässt sich eine stets gleiche Positionierung der Daten erreichen, da die Zeile nicht explizit gelöscht wird. Auszug aus der fhem.cfg: <pre> define DLCD_WZ DLCD attr DLCD_WZ dlcdBlankspaceReplace \x20 attr DLCD_WZ dlcdCols 16 attr DLCD_WZ dlcdLine1 %date_WD_ger% %date_D%.%date_M_ger% %time_h%:%time_m% attr DLCD_WZ dlcdLine2 Keller:%1%/%2% attr DLCD_WZ dlcdLine3 %date_WD_ger% %date_D%.%date_M_ger% %time_h%:%time_m% attr DLCD_WZ dlcdLine4 Garten: %3%/%4% attr DLCD_WZ dlcdPhysicalRows 1 attr DLCD_WZ dlcdPollInterval 15 attr DLCD_WZ dlcdRows 4 attr DLCD_WZ dlcdScrolling 1 attr DLCD_WZ dlcdTriggerCmd set WZ_LCD write %L% 0 %T% attr DLCD_WZ dlcdVal1 Keller:temperature attr DLCD_WZ dlcdVal1formatnum 3+1 attr DLCD_WZ dlcdVal2 Keller:humidity attr DLCD_WZ dlcdVal2formatnum 3+1 attr DLCD_WZ dlcdVal3 KS300:temperature attr DLCD_WZ dlcdVal3formatnum 3+1+- attr DLCD_WZ dlcdVal4 KS300:humidity attr DLCD_WZ dlcdVal4formatnum 2+0 </pre> Das Ergebnis kann so aussehen: <gallery> DLCD_1.jpg|Zustand 1.-15. Sekunde DLCD_2.jpg|Zustand 16.-30. Sekunde DLCD_3.jpg|Zustand 31.-45. Sekunde DLCD_4.jpg|Zustand 46.-60. Sekunde </gallery> Die Formatierung bewirkt eine immer identische Platzierung der Daten. Der Außensensor hat keine Zehntelwerte bei der Feuchte, muss dafür aber negative Temperaturen darstellen. Der Innensensor zeigt Zehntelwerte, womit sich Tendenzen eher erkennen lassen. == [[RFM12_ASK_(Deutsch) | Intertechno schalten mit RFM12]] == todo == [[RFM12_ASK_(Deutsch) | IC2272 schalten mit RFM12]] == todo [[Category:Application|Application]] e00589874058f85c0dbccf41b8ac42b57d83f436 1721 1720 2016-06-01T09:41:29Z Tobox 727 /* BMP085/BMP180 Luftdrucksensor */ wikitext text/x-wiki {{i18n|Nutzung in FHEM}} [http://www.fhemwiki.de/wiki/Hauptseite FHEM] ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um diverse per Funk und Kabel angebundene Komponenten aus dem Bereich der Hausautomation zu steuern. Er ist lizensiert unter der GPL v2. Das [http://www.pollin.de/shop/suchergebnis.html?S_TEXT=810+058 AVR-Net-IO] von [http://www.pollin.de Pollin] mit [[Ethersex]] dient als [http://www.fhemwiki.de/wiki/AVR-NET-IO preisgünstiger Einstieg in die Hausautomatisierung]. Verwendbar ist aber auch jede andere [[Supported_Boards_(Deutsch) | Hardware]], die von Ethersex unterstützt wird (Arduino, eigene Entwicklungen, etc.). Über [[ECMD]] lassen sich dabei theoretisch alle in [[Ethersex]] vorhandenen [[ECMD_Protocols_%28Deutsch%29 | Möglichkeiten]] nutzen, sofern in FHEM entsprechende [http://fhem.de/commandref.html#ECMD ECMD-Devices] definiert und eingebunden werden, die passende Klassendefinition exisitert und die Aktion ausgelöst wird. == Grundlagen == Ausgehend von einem fertigen und per Telnet erreichbaren Ethersex muss in FHEM zuerst das entsprechende Device definiert werden. <pre> define NETIO_WZ ECMD telnet 192.168.3.81:2701 </pre> Eine serielle Anbindung kann mit ''define <name> ECMD serial <SerialDevice>[<@BaudRate>]'' alternativ erfolgen. Anschließend werden die erstellten .classdef-Konfigurationsdateien der einzelnen Funktionen dem System bekannt gemacht. In diesen .classdef-Dateien (Name und Endung sind frei wählbar!) wird die Schnittstelle zwischen FHEM und ECMD/Ethersex definiert. Dabei können mit perl übergebene Parameter und empfangene Daten bearbeitet sowie die in FHEM gebräuchlichen Readings erstellt werden. <pre> attr NETIO_WZ classdefs RFM12_2272=/opt/fhem/FHEM/rfm12_2272.classdef:RFM12_IT=/opt/fhem/FHEM/rfm12_it.classdef:LCD=/opt/fhem/FHEM/lcd.classdef:DHT22=/opt/fhem/FHEM/dht22.classdef:1WIRE=/opt/fhem/FHEM/1wire.classdef </pre> Die Definitionen für IC2272, Intertechno, HD44780-LCD, DHT22 und 1wire sind nun eingebunden. In den folgenden Abschnitten wird auf die einzelnen Devices näher eingegangen. Generell sind Pfade und IP-Adressen sowie übergebene Parameter noch entsprechend der eigenen Konfiguration anzupassen. == [[Onewire_(Deutsch) | 1-Wire Temperatursensoren]] == [[File:DS18B20.jpg|150px|thumb|right|DS18B20-Sensoren]] Die 1wire-Temperatursensoren DS18B20 oder DS18S20 werden im [[Onewire_(Deutsch)#Polling_Modus | Polling Modus]] abgefragt. Das macht die zyklische Abfrage aus FHEM heraus wesentlich einfacher. Eine Polling-Zeit von mindestens 30 Sekunden ist absolut ausreichend.Im Vorfeld sollte man sich die [[Onewire_(Deutsch)#Benennung_von_Sensoren | ROM-Codes der Sensoren]] notieren, da diese nachher benötigt werden. 1w-temp.classdef erstellen: <source lang="perl"> # Uebergabeparameter Onewire Rom-Code params devID # Umsetzung in ECMD Befehle 1w get = Temperatur auslesen get 1W cmd {"1w get %devID\n"} get 1W expect "\d+.\d+\n" get 1W postproc {\ s/\n//g;\ my $hash = $defs{%NAME};\ my $temperature = $_;\ my $state = "T: $temperature";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die classdef wird eingebunden: <pre> define NETIO_KU ECMD telnet 192.168.3.82:2701 attr NETIO_KU classdefs 1W-TEMP=/opt/fhem/FHEM/1w-temp.classdef </pre> Die Sensoren werden anhand des ROM-Code definiert: <pre> define HZ_WW ECMDDevice 1W-TEMP 284c8820050003d4 attr HZ_WW IODev NETIO_KU define HZ_VL ECMDDevice 1W-TEMP 2890a520050003d7 attr HZ_VL IODev NETIO_KU </pre> Eine zyklische Messung pro Minute lässt sich in dieser Form auslösen: <pre> define Messung_1w at +*00:01 get HZ_WW 1W;; get HZ_VL 1W attr Messung_1w verbose 0 </pre> == [[DHT|DHT22 Temperatur-/Feuchtesensoren]] == [[File:DHT22.jpg|150px|thumb|right|DHT22-Sensoren]] [[Ethersex]] unterstützt die preiswerten Temperatur-/Feuchtesensoren [[DHT|DHT11 und DHT22]], wobei letztere [[DHT#DHT11_vs_DHT22|um einiges genauer sind]]. Die Sensoren benötigen 5V Betriebsspannung und kommunizieren über je einen Pin mit dem Prozessor. Der Preis pro Stück liegt derzeit bei etwa 3.50 Euro (ebay/China). Wer die Trägheit und Ungenauigkeit der S300TH oder TX29DTH kennt, wünscht sich vermutlich Besseres; vor allem bei Berechnung von [http://de.wikipedia.org/wiki/Taupunkt Taupunkt] und [http://de.wikipedia.org/wiki/Luftfeuchtigkeit#Absolute_Luftfeuchtigkeit absoluter Feuchte], welche von der Genauigkeit der gemessenen Eingangsgrößen sehr profitieren. Berechnungen von Hand kann man beim [http://www.wetterochs.de/wetter/feuchte.html Wetterochs] durchführen. Die automatische Berechnung der absoluten Feuchte in FHEM wird im [http://forum.fhem.de/index.php/topic,21458.0.html Forum] erklärt. '''Einbindung in FHEM''' dht22m.classdef erstellen: <source lang="perl"> # Uebergabeparameter DHT22 ID 0...n params devID # Umsetzung in ECMD Befehle fuer DHT22 get DHT cmd {"dht temp %devID\n\000dht humid %devID\n"} get DHT expect "\d+.\d\n" get DHT postproc {\ s/(.*)\n(.*)\n/T: $1 H: $2/;\ my $hash = $defs{%NAME};\ my $temperature = $1;\ my $humidity = $2;\ my $state = $_;\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "humidity", $humidity, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs DHT22M=/opt/fhem/FHEM/dht22m.classdef </pre> Die Sensoren werden definiert: <pre> define Test0 ECMDDevice DHT22M 0 attr Test0 IODev NETIO_TEST define Test1 ECMDDevice DHT22M 1 attr Test1 IODev NETIO_TEST define Test2 ECMDDevice DHT22M 2 attr Test2 IODev NETIO_TEST define Test3 ECMDDevice DHT22M 3 attr Test3 IODev NETIO_TEST </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_DHT at +*00:04 get Test0 DHT;; get Test1 DHT;; get Test2 DHT;; get Test3 DHT attr Messung_DHT verbose 0 </pre> Fünfzehn Messwerte pro Stunde genügen den allermeisten Anforderungen. == [[BMP085 | BMP085/BMP180 Luftdrucksensor]] == [[File:BMP180.jpg|150px|thumb|right|BMP180 (unten links)]] Ethersex unterstützt den BMP085 (bzw. den BMP180; der Code ist identisch) über das [[I2C_(Deutsch) | I2C]]-Interface. Da der Sensor für 3.3V Betriebsspannung ausgelegt ist, muss entweder der I2C-Pegel angepasst oder der ATMega auf 3.3V adaptiert werden. Weiterhin sollte die Höhe über Null bekannt sein. Beispiel: Eine Abfrage per [[ECMD]] mit ''bmp085 pressnn 59000'' bedeutet, das ich 590m (59000cm) über NN wohne. Sollte der Befehl ''bmp085 pressnn'' aus Platzgründen nicht mehr in Image passen, kann man die Umrechnung auf Normal Null alternativ auch in der classdef erledigen. Die im Sensor verfügbare Temperatur wird parallel ausgelesen. '''Einbindung in FHEM''' bmp085.classdef erstellen, falls ''presnn'' unterstützt wird (59000 durch eigene Höhe in cm ersetzen!): <source lang="perl"> get BMP cmd {"bmp085 temp\n\000bmp085 pressnn 59000\n"} get BMP expect ".*" get BMP postproc {\ s/(.*)\n(.*)\n/T: $1 P: $2/;\ my $hash = $defs{%NAME};\ my $temperature = $1/10;\ my $pressure = sprintf("%.1f",$2/100);\ my $state = "T: $temperature P: $pressure";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "pressure", $pressure, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die Temperatur wird in °C mit einer Nachkommastelle gelesen, der Luftdruck in hPa bzw. mbar auf eine Nachkommastelle gerundet. Passende Readings werden erstellt. Das expect .* kann noch angepasst werden, um bei fehlerhaften Messwerten entsprechend zu reagieren. Die classdef wird in FHEM eingebunden (mehrere .classdef mit Doppelpunkt trennen: siehe [[Nutzung_in_FHEM_(Deutsch)#Grundlagen | Grundlagen]]): <pre> define NETIO_STK ECMD telnet 192.168.3.89:2701 attr NETIO_STK classdefs BMP=/opt/fhem/FHEM/bmp085.classdef </pre> Der Sensor wird definiert: <pre> define BMP180 ECMDDevice BMP attr BMP180 IODev NETIO_STK </pre> Das STATE ''kann'' mit Maßeinheiten versehen werden: <pre> attr BMP180 stateFormat { sprintf("%s°C %shPa", ReadingsVal("BMP180","temperature",0), ReadingsVal("BMP180","pressure",0)) ;; } </pre> Eine zyklische Messung alle 4 Minuten erfolgt wieder mit ''at'': <pre> define Messung_BMP at +*00:04 get BMP180 BMP attr Messung_BMP verbose 0 </pre> Dabei unterdrückt verbose 0 einen zusätzlichen (doppelten) Logeintrag des Messvorganges. Alternative bmp085.classdef, die die Umrechnung auf Normal Null in Perl macht (590 durch eigene Höhe in m ersetzen): <source lang="perl"> get pressure cmd {"bmp085 apress\n"} get pressure expect "\d+\n" get pressure postproc { s/(..)\n/.$1/; $_/=(1-(590/44330.7692))**5.255; $_ } get temp cmd {"bmp085 temp\n"} get temp expect "\d+\n" get temp postproc { s/(.)\n/.$1/; $_ } </source> Bei diesem Beispiel können Temperatur und Druck separat ausgelesen werden, hier ein Beispiel für das zyklische Auslesen beider Werte: <pre> define Messung_BMP at +*00:04 get BMP180 pressure ;; get BMP180 temp </pre> == analoge Eingänge abfragen == Die analogen Eingänge des ATMega sind recht simpel abzufragen. Dabei werden die hexadezimalen Werte gleich dezimal gewandelt, um die Weiterverarbeitung zu erleichtern. '''Einbindung in FHEM''' adc.classdef erstellen: <source lang="perl"> get value cmd {"adc get %PortID\n"} params PortID get value expect ".*" get value postproc {\ my $hexval = hex(trim("$_"));\ my $hash = $defs{%NAME};\ readingsSingleUpdate($hash, "state", $hexval, 1);\ } </source> Die classdef wird eingebunden: <pre> define NETIO_KU ECMD telnet 192.168.3.89:2701 attr NETIO_KU classdefs ADC=/opt/fhem/FHEM/adc.classdef </pre> Die Sensoren an den ersten beiden Ports werden definiert: <pre> define MP_0 ECMDDevice ADC 0 attr MP_0 IODev NETIO_KU define MP_1 ECMDDevice ADC 1 attr MP_1 IODev NETIO_KU </pre> Eine zyklische Messung alle 60 Sekunden funktioniert damit: <pre> define Messung_adc at +*00:01 get MP_0 value;; get MP_1 value attr Messung_adc verbose 0 </pre> == digitale Eingänge abfragen == todo == digitale Eingänge - proaktiv == Kontakte, die bei Zustandsänderung sofort in FHEM eine Meldung erzeugen sollen, kann man nicht zeitnah mit Polling abfragen. Diese Ereignisse, welche auch aus einem Control6-Script heraus generiert sein können, sollen selbst Meldung machen. Hierbei wird die ESEND-Funktion benutzt, mit welcher auch mehrere Ethersex'e untereinander kommunizieren können. Dabei ist es nicht relevant, ob das Device in FHEM per ECMDDevice bereits eingebunden wurde. Zuerst muss FHEM auf Port 2701 für Telnet-Verbindungen empfänglich werden: <pre> define telnetECMD telnet 2701 global </pre> Mit ''Watch io changes and react'' lässt sich per menuconfig bereits auf einfache Weise eine Abfrage von Portpins mit Generierung eines ESEND-Befehles bewerkstelligen. Das Beispiel soll zeigen, wie bei entsprechender Zustandsänderung an Pin PA0 an 192.168.178.10 ein FHEM-Befehl gesendet wird: <pre> ECMDTCP(PA0, RISING, 192.168.178.10, set Lampe on\n\n) ECMDTCP(PA0, FALLING, 192.168.178.10, set Lampe off\n\n) </pre> Jede Sequenz muss mit \n\n abgeschlossen werden, damit FHEM für weitere Befehle empfangsbereit bleibt. Falls man in FHEM flexibler bei der Weiterverarbeitung sein möchte, bietet sich eine dummy-notify-Kombination an. == [[Porterweiterungen_%28Deutsch%29#D.2FA-Wandler_mit_LTC1257 | LTC1257 D/A-Wandler]] == [[File:LTC1257.jpg|150px|thumb|right|LTC1257 Digital-Analog-Wandler innerhalb einer Schaltung]] Die 12bit Digital-Analog-Wandler von LINEAR TECHNOLOGY werden mit drei Pins bedient. Er wandelt (bei interner Referenzspannung) einen digital übermittelten Wert in eine Spannung von 0-2,048V um. Ein nachgeschalteter OPV als nichtinvertierender Verstärker kann diesen Bereich entsprechend skalieren. ltc1257.classdef erstellen: <source lang="perl"> # Umsetzung in ECMD Befehle # Ein Uebergabeparameter -> Sollwert set setDAC params dacValue set setDAC cmd {"ltc1257_set %dacValue\n"} set setDAC expect "OK\n" # Keine Uebergabeparameter set init cmd {"ltc1257_init\n"} set init expect "OK\n" # } </source> Die classdef wird eingebunden: <pre> define NETIO_KU ECMD telnet 192.168.3.82:2701 attr NETIO_KU classdefs LTC1257=/opt/fhem/FHEM/ltc1257.classdef </pre> Der LTC wird entsprechend definiert: <pre> define HZ_DAC ECMDDevice LTC1257 attr HZ_DAC IODev NETIO_KU </pre> Nun lässt sich mit einem '''set HZ_DAC init''' der LTC initialisieren (die gemessene Ausgangsspannung sollte 0V sein) und mit '''set HZ_DAC setDAC [0...4095]''' der gewünschte Wert setzen. Hier muss vorab experimentell entsprechend der nachfolgenden Beschaltung die tatsächliche Spannung ermittelt werden. == [[LCD_(Deutsch) | HD44780 Punktmatrixdisplays]] == [[File:HD44780.jpg|150px|thumb|right|verschiedene HD44780 Displays (16x1 bis 40x4)]] Die beliebten Punktmatrix-Displays auf Basis [http://de.wikipedia.org/wiki/HD44780 HD44780] können vollumfänglich in FHEM beschrieben werden. Dabei wird vorrausgesetzt, das in [https://github.com/ethersex/ethersex/blob/master/hardware/lcd/hd44780.h /hardware/lcd/hd44780.h] beim entsprechenden Modell die passende Adressierung der Zeilen und die genutzte Zeilen-/Spaltenzahl vor dem Compilieren angepasst wurde. '''Einbindung in FHEM''' lcd.classdef erstellen: <source lang="perl"> # Umsetzung der ECMD Befehle set write params line col text set write cmd {"lcd goto %line %col\n\000lcd write %text\n"} set write expect "OK\n" set write postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set clear params col set clear cmd {"lcd clear %col\n"} set clear expect "OK\n" set clear postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set clear_all cmd {"lcd clear\n"} set clear_all expect "OK\n" set clear_all postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set lcd_bl params state set lcd_bl cmd {"lcd backlight %state\n"} set lcd_bl expect "OK\n" set lcd_bl postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} </source> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs LCD=/opt/fhem/FHEM/lcd.classdef </pre> Das Display wird definiert: <pre> define WZ_LCD ECMDDevice LCD attr WZ_LCD IODev NETIO_TEST </pre> Es stehen in FHEM folgende Befehle für das LCD bereit: {| border='1' | ''Befehl'' | ''Funktion'' |- | set WZ_LCD clear [ZEILE] | löscht den Inhalt einer ZEILE (0...3) |- | set WZ_LCD clear_all | löscht den Inhalt aller Zeilen |- | set WZ_LCD lcd_bl STATE | schaltet die Hintergrundbeleuchtung ein oder aus (STATE on oder off) |- | set WZ_LCD write [ZEILE] [SPALTE] [TEXT] | schreibt einen TEXT auf Position ZEILE SPALTE (0...n) |- |} Da ein im TEXT übergebenes Leerzeichen als weiterer Befehl interpretiert wird und zu einer Fehlermeldung führt, ist eine Übergabe nur mit \x20 im Text möglich. Das gilt auch für Umlaute. Anhand der [http://de.wikipedia.org/wiki/HD44780#Schrift_und_Zeichensatz Zeichensatztabelle] lassen sich ä durch \xE1, ü durch \xF5 und ö durch \xEF darstellen. Das ß wird mit \xE2 erreicht. Die Tabelle kann für manche Displays abweichend sein.<br /> Beispiel: ''set WZ_LCD write 0 0 Fenster\x20schlie\xE2en'' schreibt ein '''Fenster schließen''' auf's LCD. '''Komfortable Nutzung in FHEM mit DLCD''' Mit dem DLCD-Modul ([http://www.fhemwiki.de/wiki/DLCD Wiki-Beitrag] / [http://forum.fhem.de/index.php/topic,24519.0.html Foren-Beitrag]) für FHEM lässt sich jedes Display auf einfache Weise beschreiben. Dabei lassen sich bequem Readings von allen Devices nutzen, aufbereiten (formatieren, umrechnen, etc.) und entsprechend darstellen. Eine genaue Beschreibung hält der Wiki-Beitrag bereit; hier soll ein Beispiel gezeigt werden. Ziel war es, auf einem 16x1 LCD wechselweise ''Datum/Zeit => Klimadaten Keller => Datum/Zeit => Klimadaten Garten'' darzustellen. Die Anzeige rotiert im 15-Sekunden-Takt, so das zu 50% Datum/Zeit und je 25% die Werte aus dem Garten und dem Keller angezeigt werden. Es wird bereits im Modul jedes Leerzeichen mit \x20 übersetzt. Der Außensensor ist ein [http://www.elv.de/elv-funk-kombi-wettersensor-ks-300-2-br-inkl-hochwertigem-2-m-edelstahlmast-br-und-qualitaetsbatterien.html KS300] (bzw. KS200) von ELV. Mit etwas Formatierung und ein paar Leerzeichen lässt sich eine stets gleiche Positionierung der Daten erreichen, da die Zeile nicht explizit gelöscht wird. Auszug aus der fhem.cfg: <pre> define DLCD_WZ DLCD attr DLCD_WZ dlcdBlankspaceReplace \x20 attr DLCD_WZ dlcdCols 16 attr DLCD_WZ dlcdLine1 %date_WD_ger% %date_D%.%date_M_ger% %time_h%:%time_m% attr DLCD_WZ dlcdLine2 Keller:%1%/%2% attr DLCD_WZ dlcdLine3 %date_WD_ger% %date_D%.%date_M_ger% %time_h%:%time_m% attr DLCD_WZ dlcdLine4 Garten: %3%/%4% attr DLCD_WZ dlcdPhysicalRows 1 attr DLCD_WZ dlcdPollInterval 15 attr DLCD_WZ dlcdRows 4 attr DLCD_WZ dlcdScrolling 1 attr DLCD_WZ dlcdTriggerCmd set WZ_LCD write %L% 0 %T% attr DLCD_WZ dlcdVal1 Keller:temperature attr DLCD_WZ dlcdVal1formatnum 3+1 attr DLCD_WZ dlcdVal2 Keller:humidity attr DLCD_WZ dlcdVal2formatnum 3+1 attr DLCD_WZ dlcdVal3 KS300:temperature attr DLCD_WZ dlcdVal3formatnum 3+1+- attr DLCD_WZ dlcdVal4 KS300:humidity attr DLCD_WZ dlcdVal4formatnum 2+0 </pre> Das Ergebnis kann so aussehen: <gallery> DLCD_1.jpg|Zustand 1.-15. Sekunde DLCD_2.jpg|Zustand 16.-30. Sekunde DLCD_3.jpg|Zustand 31.-45. Sekunde DLCD_4.jpg|Zustand 46.-60. Sekunde </gallery> Die Formatierung bewirkt eine immer identische Platzierung der Daten. Der Außensensor hat keine Zehntelwerte bei der Feuchte, muss dafür aber negative Temperaturen darstellen. Der Innensensor zeigt Zehntelwerte, womit sich Tendenzen eher erkennen lassen. == [[RFM12_ASK_(Deutsch) | Intertechno schalten mit RFM12]] == todo == [[RFM12_ASK_(Deutsch) | IC2272 schalten mit RFM12]] == todo [[Category:Application|Application]] cc7d6f14d3b0c566940a38aa9030d624bf4e24b1 1722 1721 2016-07-10T10:14:06Z Kpwg 721 /* DHT22 Temperatur-/Feuchtesensoren */ wikitext text/x-wiki {{i18n|Nutzung in FHEM}} [http://www.fhemwiki.de/wiki/Hauptseite FHEM] ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um diverse per Funk und Kabel angebundene Komponenten aus dem Bereich der Hausautomation zu steuern. Er ist lizensiert unter der GPL v2. Das [http://www.pollin.de/shop/suchergebnis.html?S_TEXT=810+058 AVR-Net-IO] von [http://www.pollin.de Pollin] mit [[Ethersex]] dient als [http://www.fhemwiki.de/wiki/AVR-NET-IO preisgünstiger Einstieg in die Hausautomatisierung]. Verwendbar ist aber auch jede andere [[Supported_Boards_(Deutsch) | Hardware]], die von Ethersex unterstützt wird (Arduino, eigene Entwicklungen, etc.). Über [[ECMD]] lassen sich dabei theoretisch alle in [[Ethersex]] vorhandenen [[ECMD_Protocols_%28Deutsch%29 | Möglichkeiten]] nutzen, sofern in FHEM entsprechende [http://fhem.de/commandref.html#ECMD ECMD-Devices] definiert und eingebunden werden, die passende Klassendefinition exisitert und die Aktion ausgelöst wird. == Grundlagen == Ausgehend von einem fertigen und per Telnet erreichbaren Ethersex muss in FHEM zuerst das entsprechende Device definiert werden. <pre> define NETIO_WZ ECMD telnet 192.168.3.81:2701 </pre> Eine serielle Anbindung kann mit ''define <name> ECMD serial <SerialDevice>[<@BaudRate>]'' alternativ erfolgen. Anschließend werden die erstellten .classdef-Konfigurationsdateien der einzelnen Funktionen dem System bekannt gemacht. In diesen .classdef-Dateien (Name und Endung sind frei wählbar!) wird die Schnittstelle zwischen FHEM und ECMD/Ethersex definiert. Dabei können mit perl übergebene Parameter und empfangene Daten bearbeitet sowie die in FHEM gebräuchlichen Readings erstellt werden. <pre> attr NETIO_WZ classdefs RFM12_2272=/opt/fhem/FHEM/rfm12_2272.classdef:RFM12_IT=/opt/fhem/FHEM/rfm12_it.classdef:LCD=/opt/fhem/FHEM/lcd.classdef:DHT22=/opt/fhem/FHEM/dht22.classdef:1WIRE=/opt/fhem/FHEM/1wire.classdef </pre> Die Definitionen für IC2272, Intertechno, HD44780-LCD, DHT22 und 1wire sind nun eingebunden. In den folgenden Abschnitten wird auf die einzelnen Devices näher eingegangen. Generell sind Pfade und IP-Adressen sowie übergebene Parameter noch entsprechend der eigenen Konfiguration anzupassen. == [[Onewire_(Deutsch) | 1-Wire Temperatursensoren]] == [[File:DS18B20.jpg|150px|thumb|right|DS18B20-Sensoren]] Die 1wire-Temperatursensoren DS18B20 oder DS18S20 werden im [[Onewire_(Deutsch)#Polling_Modus | Polling Modus]] abgefragt. Das macht die zyklische Abfrage aus FHEM heraus wesentlich einfacher. Eine Polling-Zeit von mindestens 30 Sekunden ist absolut ausreichend.Im Vorfeld sollte man sich die [[Onewire_(Deutsch)#Benennung_von_Sensoren | ROM-Codes der Sensoren]] notieren, da diese nachher benötigt werden. 1w-temp.classdef erstellen: <source lang="perl"> # Uebergabeparameter Onewire Rom-Code params devID # Umsetzung in ECMD Befehle 1w get = Temperatur auslesen get 1W cmd {"1w get %devID\n"} get 1W expect "\d+.\d+\n" get 1W postproc {\ s/\n//g;\ my $hash = $defs{%NAME};\ my $temperature = $_;\ my $state = "T: $temperature";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die classdef wird eingebunden: <pre> define NETIO_KU ECMD telnet 192.168.3.82:2701 attr NETIO_KU classdefs 1W-TEMP=/opt/fhem/FHEM/1w-temp.classdef </pre> Die Sensoren werden anhand des ROM-Code definiert: <pre> define HZ_WW ECMDDevice 1W-TEMP 284c8820050003d4 attr HZ_WW IODev NETIO_KU define HZ_VL ECMDDevice 1W-TEMP 2890a520050003d7 attr HZ_VL IODev NETIO_KU </pre> Eine zyklische Messung pro Minute lässt sich in dieser Form auslösen: <pre> define Messung_1w at +*00:01 get HZ_WW 1W;; get HZ_VL 1W attr Messung_1w verbose 0 </pre> == [[DHT|DHT22 Temperatur-/Feuchtesensoren]] == [[File:DHT22.jpg|150px|thumb|right|DHT22-Sensoren]] [[Ethersex]] unterstützt die preiswerten Temperatur-/Feuchtesensoren [[DHT|DHT11 und DHT22]], wobei letztere [[DHT#DHT11_vs_DHT22|um einiges genauer sind]]. Die Sensoren benötigen 5V Betriebsspannung und kommunizieren über je einen Pin mit dem Prozessor. Der Preis pro Stück liegt derzeit bei etwa 3.50 Euro (ebay/China). Wer die Trägheit und Ungenauigkeit der S300TH oder TX29DTH kennt, wünscht sich vermutlich Besseres; vor allem bei Berechnung von [http://de.wikipedia.org/wiki/Taupunkt Taupunkt] und [http://de.wikipedia.org/wiki/Luftfeuchtigkeit#Absolute_Luftfeuchtigkeit absoluter Feuchte], welche von der Genauigkeit der gemessenen Eingangsgrößen sehr profitieren. Berechnungen von Hand kann man beim [http://www.wetterochs.de/wetter/feuchte.html Wetterochs] durchführen. Die automatische Berechnung der absoluten Feuchte in FHEM wird im [http://forum.fhem.de/index.php/topic,21458.0.html Forum] erklärt. '''Einbindung in FHEM''' dht22m.classdef erstellen: <source lang="perl"> # Uebergabeparameter DHT22 ID 0...n params devID # Umsetzung in ECMD Befehle fuer DHT22 get DHT cmd {"dht temp %devID\n\000dht humid %devID\n"} get DHT expect "-?\d+.\d\n" get DHT postproc {\ s/(.*)\n(.*)\n/T: $1 H: $2/;\ my $hash = $defs{%NAME};\ my $temperature = $1;\ my $humidity = $2;\ my $state = $_;\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "humidity", $humidity, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs DHT22M=/opt/fhem/FHEM/dht22m.classdef </pre> Die Sensoren werden definiert: <pre> define Test0 ECMDDevice DHT22M 0 attr Test0 IODev NETIO_TEST define Test1 ECMDDevice DHT22M 1 attr Test1 IODev NETIO_TEST define Test2 ECMDDevice DHT22M 2 attr Test2 IODev NETIO_TEST define Test3 ECMDDevice DHT22M 3 attr Test3 IODev NETIO_TEST </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_DHT at +*00:04 get Test0 DHT;; get Test1 DHT;; get Test2 DHT;; get Test3 DHT attr Messung_DHT verbose 0 </pre> Fünfzehn Messwerte pro Stunde genügen den allermeisten Anforderungen. == [[BMP085 | BMP085/BMP180 Luftdrucksensor]] == [[File:BMP180.jpg|150px|thumb|right|BMP180 (unten links)]] Ethersex unterstützt den BMP085 (bzw. den BMP180; der Code ist identisch) über das [[I2C_(Deutsch) | I2C]]-Interface. Da der Sensor für 3.3V Betriebsspannung ausgelegt ist, muss entweder der I2C-Pegel angepasst oder der ATMega auf 3.3V adaptiert werden. Weiterhin sollte die Höhe über Null bekannt sein. Beispiel: Eine Abfrage per [[ECMD]] mit ''bmp085 pressnn 59000'' bedeutet, das ich 590m (59000cm) über NN wohne. Sollte der Befehl ''bmp085 pressnn'' aus Platzgründen nicht mehr in Image passen, kann man die Umrechnung auf Normal Null alternativ auch in der classdef erledigen. Die im Sensor verfügbare Temperatur wird parallel ausgelesen. '''Einbindung in FHEM''' bmp085.classdef erstellen, falls ''presnn'' unterstützt wird (59000 durch eigene Höhe in cm ersetzen!): <source lang="perl"> get BMP cmd {"bmp085 temp\n\000bmp085 pressnn 59000\n"} get BMP expect ".*" get BMP postproc {\ s/(.*)\n(.*)\n/T: $1 P: $2/;\ my $hash = $defs{%NAME};\ my $temperature = $1/10;\ my $pressure = sprintf("%.1f",$2/100);\ my $state = "T: $temperature P: $pressure";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "pressure", $pressure, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die Temperatur wird in °C mit einer Nachkommastelle gelesen, der Luftdruck in hPa bzw. mbar auf eine Nachkommastelle gerundet. Passende Readings werden erstellt. Das expect .* kann noch angepasst werden, um bei fehlerhaften Messwerten entsprechend zu reagieren. Die classdef wird in FHEM eingebunden (mehrere .classdef mit Doppelpunkt trennen: siehe [[Nutzung_in_FHEM_(Deutsch)#Grundlagen | Grundlagen]]): <pre> define NETIO_STK ECMD telnet 192.168.3.89:2701 attr NETIO_STK classdefs BMP=/opt/fhem/FHEM/bmp085.classdef </pre> Der Sensor wird definiert: <pre> define BMP180 ECMDDevice BMP attr BMP180 IODev NETIO_STK </pre> Das STATE ''kann'' mit Maßeinheiten versehen werden: <pre> attr BMP180 stateFormat { sprintf("%s°C %shPa", ReadingsVal("BMP180","temperature",0), ReadingsVal("BMP180","pressure",0)) ;; } </pre> Eine zyklische Messung alle 4 Minuten erfolgt wieder mit ''at'': <pre> define Messung_BMP at +*00:04 get BMP180 BMP attr Messung_BMP verbose 0 </pre> Dabei unterdrückt verbose 0 einen zusätzlichen (doppelten) Logeintrag des Messvorganges. Alternative bmp085.classdef, die die Umrechnung auf Normal Null in Perl macht (590 durch eigene Höhe in m ersetzen): <source lang="perl"> get pressure cmd {"bmp085 apress\n"} get pressure expect "\d+\n" get pressure postproc { s/(..)\n/.$1/; $_/=(1-(590/44330.7692))**5.255; $_ } get temp cmd {"bmp085 temp\n"} get temp expect "\d+\n" get temp postproc { s/(.)\n/.$1/; $_ } </source> Bei diesem Beispiel können Temperatur und Druck separat ausgelesen werden, hier ein Beispiel für das zyklische Auslesen beider Werte: <pre> define Messung_BMP at +*00:04 get BMP180 pressure ;; get BMP180 temp </pre> == analoge Eingänge abfragen == Die analogen Eingänge des ATMega sind recht simpel abzufragen. Dabei werden die hexadezimalen Werte gleich dezimal gewandelt, um die Weiterverarbeitung zu erleichtern. '''Einbindung in FHEM''' adc.classdef erstellen: <source lang="perl"> get value cmd {"adc get %PortID\n"} params PortID get value expect ".*" get value postproc {\ my $hexval = hex(trim("$_"));\ my $hash = $defs{%NAME};\ readingsSingleUpdate($hash, "state", $hexval, 1);\ } </source> Die classdef wird eingebunden: <pre> define NETIO_KU ECMD telnet 192.168.3.89:2701 attr NETIO_KU classdefs ADC=/opt/fhem/FHEM/adc.classdef </pre> Die Sensoren an den ersten beiden Ports werden definiert: <pre> define MP_0 ECMDDevice ADC 0 attr MP_0 IODev NETIO_KU define MP_1 ECMDDevice ADC 1 attr MP_1 IODev NETIO_KU </pre> Eine zyklische Messung alle 60 Sekunden funktioniert damit: <pre> define Messung_adc at +*00:01 get MP_0 value;; get MP_1 value attr Messung_adc verbose 0 </pre> == digitale Eingänge abfragen == todo == digitale Eingänge - proaktiv == Kontakte, die bei Zustandsänderung sofort in FHEM eine Meldung erzeugen sollen, kann man nicht zeitnah mit Polling abfragen. Diese Ereignisse, welche auch aus einem Control6-Script heraus generiert sein können, sollen selbst Meldung machen. Hierbei wird die ESEND-Funktion benutzt, mit welcher auch mehrere Ethersex'e untereinander kommunizieren können. Dabei ist es nicht relevant, ob das Device in FHEM per ECMDDevice bereits eingebunden wurde. Zuerst muss FHEM auf Port 2701 für Telnet-Verbindungen empfänglich werden: <pre> define telnetECMD telnet 2701 global </pre> Mit ''Watch io changes and react'' lässt sich per menuconfig bereits auf einfache Weise eine Abfrage von Portpins mit Generierung eines ESEND-Befehles bewerkstelligen. Das Beispiel soll zeigen, wie bei entsprechender Zustandsänderung an Pin PA0 an 192.168.178.10 ein FHEM-Befehl gesendet wird: <pre> ECMDTCP(PA0, RISING, 192.168.178.10, set Lampe on\n\n) ECMDTCP(PA0, FALLING, 192.168.178.10, set Lampe off\n\n) </pre> Jede Sequenz muss mit \n\n abgeschlossen werden, damit FHEM für weitere Befehle empfangsbereit bleibt. Falls man in FHEM flexibler bei der Weiterverarbeitung sein möchte, bietet sich eine dummy-notify-Kombination an. == [[Porterweiterungen_%28Deutsch%29#D.2FA-Wandler_mit_LTC1257 | LTC1257 D/A-Wandler]] == [[File:LTC1257.jpg|150px|thumb|right|LTC1257 Digital-Analog-Wandler innerhalb einer Schaltung]] Die 12bit Digital-Analog-Wandler von LINEAR TECHNOLOGY werden mit drei Pins bedient. Er wandelt (bei interner Referenzspannung) einen digital übermittelten Wert in eine Spannung von 0-2,048V um. Ein nachgeschalteter OPV als nichtinvertierender Verstärker kann diesen Bereich entsprechend skalieren. ltc1257.classdef erstellen: <source lang="perl"> # Umsetzung in ECMD Befehle # Ein Uebergabeparameter -> Sollwert set setDAC params dacValue set setDAC cmd {"ltc1257_set %dacValue\n"} set setDAC expect "OK\n" # Keine Uebergabeparameter set init cmd {"ltc1257_init\n"} set init expect "OK\n" # } </source> Die classdef wird eingebunden: <pre> define NETIO_KU ECMD telnet 192.168.3.82:2701 attr NETIO_KU classdefs LTC1257=/opt/fhem/FHEM/ltc1257.classdef </pre> Der LTC wird entsprechend definiert: <pre> define HZ_DAC ECMDDevice LTC1257 attr HZ_DAC IODev NETIO_KU </pre> Nun lässt sich mit einem '''set HZ_DAC init''' der LTC initialisieren (die gemessene Ausgangsspannung sollte 0V sein) und mit '''set HZ_DAC setDAC [0...4095]''' der gewünschte Wert setzen. Hier muss vorab experimentell entsprechend der nachfolgenden Beschaltung die tatsächliche Spannung ermittelt werden. == [[LCD_(Deutsch) | HD44780 Punktmatrixdisplays]] == [[File:HD44780.jpg|150px|thumb|right|verschiedene HD44780 Displays (16x1 bis 40x4)]] Die beliebten Punktmatrix-Displays auf Basis [http://de.wikipedia.org/wiki/HD44780 HD44780] können vollumfänglich in FHEM beschrieben werden. Dabei wird vorrausgesetzt, das in [https://github.com/ethersex/ethersex/blob/master/hardware/lcd/hd44780.h /hardware/lcd/hd44780.h] beim entsprechenden Modell die passende Adressierung der Zeilen und die genutzte Zeilen-/Spaltenzahl vor dem Compilieren angepasst wurde. '''Einbindung in FHEM''' lcd.classdef erstellen: <source lang="perl"> # Umsetzung der ECMD Befehle set write params line col text set write cmd {"lcd goto %line %col\n\000lcd write %text\n"} set write expect "OK\n" set write postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set clear params col set clear cmd {"lcd clear %col\n"} set clear expect "OK\n" set clear postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set clear_all cmd {"lcd clear\n"} set clear_all expect "OK\n" set clear_all postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set lcd_bl params state set lcd_bl cmd {"lcd backlight %state\n"} set lcd_bl expect "OK\n" set lcd_bl postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} </source> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs LCD=/opt/fhem/FHEM/lcd.classdef </pre> Das Display wird definiert: <pre> define WZ_LCD ECMDDevice LCD attr WZ_LCD IODev NETIO_TEST </pre> Es stehen in FHEM folgende Befehle für das LCD bereit: {| border='1' | ''Befehl'' | ''Funktion'' |- | set WZ_LCD clear [ZEILE] | löscht den Inhalt einer ZEILE (0...3) |- | set WZ_LCD clear_all | löscht den Inhalt aller Zeilen |- | set WZ_LCD lcd_bl STATE | schaltet die Hintergrundbeleuchtung ein oder aus (STATE on oder off) |- | set WZ_LCD write [ZEILE] [SPALTE] [TEXT] | schreibt einen TEXT auf Position ZEILE SPALTE (0...n) |- |} Da ein im TEXT übergebenes Leerzeichen als weiterer Befehl interpretiert wird und zu einer Fehlermeldung führt, ist eine Übergabe nur mit \x20 im Text möglich. Das gilt auch für Umlaute. Anhand der [http://de.wikipedia.org/wiki/HD44780#Schrift_und_Zeichensatz Zeichensatztabelle] lassen sich ä durch \xE1, ü durch \xF5 und ö durch \xEF darstellen. Das ß wird mit \xE2 erreicht. Die Tabelle kann für manche Displays abweichend sein.<br /> Beispiel: ''set WZ_LCD write 0 0 Fenster\x20schlie\xE2en'' schreibt ein '''Fenster schließen''' auf's LCD. '''Komfortable Nutzung in FHEM mit DLCD''' Mit dem DLCD-Modul ([http://www.fhemwiki.de/wiki/DLCD Wiki-Beitrag] / [http://forum.fhem.de/index.php/topic,24519.0.html Foren-Beitrag]) für FHEM lässt sich jedes Display auf einfache Weise beschreiben. Dabei lassen sich bequem Readings von allen Devices nutzen, aufbereiten (formatieren, umrechnen, etc.) und entsprechend darstellen. Eine genaue Beschreibung hält der Wiki-Beitrag bereit; hier soll ein Beispiel gezeigt werden. Ziel war es, auf einem 16x1 LCD wechselweise ''Datum/Zeit => Klimadaten Keller => Datum/Zeit => Klimadaten Garten'' darzustellen. Die Anzeige rotiert im 15-Sekunden-Takt, so das zu 50% Datum/Zeit und je 25% die Werte aus dem Garten und dem Keller angezeigt werden. Es wird bereits im Modul jedes Leerzeichen mit \x20 übersetzt. Der Außensensor ist ein [http://www.elv.de/elv-funk-kombi-wettersensor-ks-300-2-br-inkl-hochwertigem-2-m-edelstahlmast-br-und-qualitaetsbatterien.html KS300] (bzw. KS200) von ELV. Mit etwas Formatierung und ein paar Leerzeichen lässt sich eine stets gleiche Positionierung der Daten erreichen, da die Zeile nicht explizit gelöscht wird. Auszug aus der fhem.cfg: <pre> define DLCD_WZ DLCD attr DLCD_WZ dlcdBlankspaceReplace \x20 attr DLCD_WZ dlcdCols 16 attr DLCD_WZ dlcdLine1 %date_WD_ger% %date_D%.%date_M_ger% %time_h%:%time_m% attr DLCD_WZ dlcdLine2 Keller:%1%/%2% attr DLCD_WZ dlcdLine3 %date_WD_ger% %date_D%.%date_M_ger% %time_h%:%time_m% attr DLCD_WZ dlcdLine4 Garten: %3%/%4% attr DLCD_WZ dlcdPhysicalRows 1 attr DLCD_WZ dlcdPollInterval 15 attr DLCD_WZ dlcdRows 4 attr DLCD_WZ dlcdScrolling 1 attr DLCD_WZ dlcdTriggerCmd set WZ_LCD write %L% 0 %T% attr DLCD_WZ dlcdVal1 Keller:temperature attr DLCD_WZ dlcdVal1formatnum 3+1 attr DLCD_WZ dlcdVal2 Keller:humidity attr DLCD_WZ dlcdVal2formatnum 3+1 attr DLCD_WZ dlcdVal3 KS300:temperature attr DLCD_WZ dlcdVal3formatnum 3+1+- attr DLCD_WZ dlcdVal4 KS300:humidity attr DLCD_WZ dlcdVal4formatnum 2+0 </pre> Das Ergebnis kann so aussehen: <gallery> DLCD_1.jpg|Zustand 1.-15. Sekunde DLCD_2.jpg|Zustand 16.-30. Sekunde DLCD_3.jpg|Zustand 31.-45. Sekunde DLCD_4.jpg|Zustand 46.-60. Sekunde </gallery> Die Formatierung bewirkt eine immer identische Platzierung der Daten. Der Außensensor hat keine Zehntelwerte bei der Feuchte, muss dafür aber negative Temperaturen darstellen. Der Innensensor zeigt Zehntelwerte, womit sich Tendenzen eher erkennen lassen. == [[RFM12_ASK_(Deutsch) | Intertechno schalten mit RFM12]] == todo == [[RFM12_ASK_(Deutsch) | IC2272 schalten mit RFM12]] == todo [[Category:Application|Application]] 67313892eb460faa88070f2e01f419fb187025a8 6 557 1723 2016-08-23T11:38:53Z GooPie4o 265 Copyright by Myself! wikitext text/x-wiki Copyright by Myself! d8bcffe600e8145f05524f449f03ae119ddedfdb 0 433 1727 1631 2016-08-23T11:47:01Z GooPie4o 265 /* FHEM Roomnode Wohnzimmer */ wikitext text/x-wiki {{i18n|FHEM Wohnzimmer}} == [[Nutzung_in_FHEM_(Deutsch)|FHEM]] Roomnode Wohnzimmer == Für diverse Mess- und Schaltaufgaben im Wohnzimmer musste ein individuelles und vorzeigbares Gerät entstehen, das diese Aufgaben übernimmt. Dabei sollen Daten über LAN an FHEM geliefert bzw. Display und Schaltaktoren mit FHEM gesteuert werden. Die wichtigsten Grundfunktionen sollen auch ohne FHEM direkt bedienbar sein. '''Ziele''' * Messung Temperatur/Feuchte im Raum * Anzeige diverser Klimadaten und Uhrzeit * Schalten eines [[RFM12_ASK_(Deutsch)#Intertechno_.28ITS-150.29|Intertechno]] Schaltaktors * Schalten einiger [[RFM12_ASK_(Deutsch)#2272|IC2272]]-Funksteckdosen (Weihnachtsbeleuchtung, etc.) * Steuerung Schrankwandbeleuchtung * Schalten eines [http://www.raspberrypi.org/ RasPi] für [https://kodi.tv/ Kodi] * Autonome Grundfunktionen ohne FHEM * vorzeigbares fertiges Gehäuse '''Ausstattung''' * [[DHT|DHT22]] mit ca. 3m Kabel * LCD 16x1 HD44780 mit extra großen Zeichen * [[RFM12_(Deutsch)|RFM12]] 433MHz mit externer Antenne * Taster mit LEDs * Schaltausgänge 12V mit PowerFET (IRLZ34) * USB-Buchse, die per Kabel den RasPi mit 5V versorgt * ATMega32 (98% Nutzung des Flash) '''Bilder''' <gallery> Fhem_wz_01.jpg|Aussenansicht (noch ohne Frontplatte) Fhem_wz_02.jpg|Platine von oben Fhem_wz_03.jpg|Stromversorgung und LAN-Modul Fhem_wz_04.jpg|Stecker Schrankwandbeleuchtung und DHT22 Fhem_wz_05.jpg|RFM12, Reed-Relais für geschaltene 5V Fhem_wz_06.jpg|zweckentfremdetes WLAN-Pigtail und 433MHz-Antenne Fhem_wz_07.jpg|Platine ohne Gehäuse für letzte Anpassungen Fhem_wz_08.jpg|Platine von unten </gallery> '''Update ZBus''' * Ersatz des Mega32 durch einen Mega644p * Einbau eines MAX485 mit Abschluss- und Bias-Widerständen sowie einer RJ10-Buchse für den ZBus-Anschluss * Fertigung eines Y-Kabels zur Übertragung des ZBus auf den ungenutzten LAN-Paaren <gallery> Fhem_wz_09.jpg|Platine mit Mega644 und MAX485 Fhem_wz_10.jpg|Rückseite mit RJ10 Buchse Fhem_wz_11.jpg|LAN-ZBus-Y-Kabel </gallery> '''Besonderheiten/Hinweise''' * das Gehäuse stammt von einem nutzlos gewordenen ELSA Lancom 800 * mit [[Control6_(Deutsch)|Control6]] und NamedPin sind die Grundfunktionen autonom bedienbar * die Stecker für die Schrankwandbeleuchtung entsprechen dem Original (Gewährleistung...) [[Category:Hardware]] [[Category:ZBus]] 256151efcb054e004027958ef357d0b6178ad5b9 0 43 1730 807 2016-09-22T20:38:36Z Daniel 725 wikitext text/x-wiki <div class="errorbox"> This page is automatically generated from the files in the Ethersex source code repository. Do not edit this page but send [[patches]] for those files! <br> <br> </div> __NOTOC__ == Analog/Digital Conversion ([[ADC]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | adc get [CHANNEL] | Get the ADC value in hex of CHANNEL or if no channel set of all channels. |- | hr20 temp | Read HR20 temperature sensor. |- |} == DNS Resolver == {| border='1' | ''Command syntax'' | ''Short description'' |- | dns server [IPADDR] | Display/Set the IP address of the DNS server to use to IPADDR. |- | nslookup HOSTNAME | Do DNS lookup for HOSTNAME (call twice). |- |} == Digital/Analog Conversion ([[DAC]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ltc1257_delay `[VALUE] | Set (if VALUE given) or get (no VALUE) delay for LTC1257 output bit changes in µs' |- | ltc1257_set `[VALUE0] [VALUE1] ... | Set output to value (value: 0-4095)' |- | tlc5620 `[CHANNEL] [VALUE] | Set Output to value (Value: 0-0xff)' |- |} == Fnordlicht == {| border='1' | ''Command syntax'' | ''Short description'' |- | fnordlicht "ADDRESS RED | GREEN,BLUE",fnordlicht command to set RGB color |- | fnordlicht_init | fnordlicht init |- |} == HD44780 [[LCD]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | hr20 hourbar START STOP | Update hourbar to show ticks between START and STOP (range 0..23) |- | hr20 toggle SEG | Toggle segment SEG (a number, not a symbolic name!) |- | lcd backlight STATE | switch back light STATE to ON or OFF |- | lcd char N D1 D2 D3 D4 D5 D6 D7 D8 | Define use-definable char N with data D1..D8 (provide DATA in hex) |- | lcd clear [LINE] | Clear line LINE (0..3) or the whole display (if parameter is omitted) |- | lcd goto LINE COL | Move cursor to LINE and column COL (origin is 0/0) |- | lcd reinit CURSOR BLINK | Reinitialize the display, set whether to show the cursor (CURSOR, 0 or 1) and whether the cursor shall BLINK |- | lcd shift DIR | Shift the display to DIR (either ''left'' or ''right'') |- | lcd write TEXT | Write TEXT to the current cursor location |- |} == Infrared Send/Receive ([[IR-TRX]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ir receive | receive an IR command |- | ir send DEVICE COMMAND | send COMMAND to DEVICE |- |} == Infrared Send/Receive ([[IRMP]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | irmp receive | receive an IR command |- | irmp send PROTOCOL DEVICE COMMAND REPEAT | send COMMAND with REPEAT flag to DEVICE using PROTOCOL |- |} == NTP Client == {| border='1' | ''Command syntax'' | ''Short description'' |- | ntp query | Query the NTP server to get an NTP update. |- | ntp server [IPADDR] | Display/Set the IP address of the NTP server to use to IPADDR. |- | ntp status | Display NTP server status |- |} == Network configuration == {| border='1' | ''Command syntax'' | ''Short description'' |- | enc dump | Dump the internal state of the enc to serial |- | gw [IP] | Display/Set the address of the default router. |- | ip [IP] | Display/Set the IP address. |- | mac [xx:xx:xx:xx:xx:xx] | Display/Set the MAC address. |- | netmask [IP] | Display/Set the network mask. |- |} == Port I/O == {| border='1' | ''Command syntax'' | ''Short description'' |- | io get ddr PORTNUM | Display the current value of the DDR PORTNUM. |- | io get mask PORTNUM | Display the mask of the port PORTNUM. |- | io get pin PORTNUM | Display the current value of the PIN-register of the port PORTNUM. |- | io get port NUM | Display the current value of the PORT NUM. |- | io set ddr PORTNUM HEXVALUE [MASK] | Set the DDR of port PORTNUM to VALUE (possibly using the provided MASK). |- | io set port NUM HEXVALUE [MASK] | Set the PORT NUM to VALUE (possibly using the provided MASK). |- |} == Reading and Writing EEPROM Space on Device == {| border='1' | ''Command syntax'' | ''Short description'' |- | eer eer <ADDR> <LENGTH> | Read n bytes from address after the config in eeprom. |- | eew eew <ADDR> <HEXBYTES> | Write Hexbytes at address after the config in epprom. |- | fuse | Display current fuse settings |- | hostname | Display hostname. |- |} == Resetting the controller == {| border='1' | ''Command syntax'' | ''Short description'' |- | bootloader | Call the bootloader. |- | reset | Reset the Ethersex. |- | wdreset | Go into endless loop to trigger a watchdog timeout. |- |} == [[ADS]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | adc get | Get the ADC value in hex. |- | adc mean [COUNT] | Get the mean of power of 2 COUNT ADC values in hex. |- |} == [[Am_Puls_der_Zeit|Clock]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | date | Print the current date. |- | lastdcf | Print when last valid DCF signal was received. |- | time [UNIXTIME] | Display/Set the current time in seconds since January 1st 1970. |- | uptime | Display ethersex uptime in unix format. |- | whm | Display ethersex uptime. |- |} == [[Application_Sample]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sample | Manually call application sample commands |- | sample_init | Manually call application sample init method |- | sample_periodic | Manually call application sample periodic method |- |} == [[Blinkenlights_MCUF|MCUF]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | mcuf modul N | Select module N |- | mcuf modul list | List all modules |- | mcuf showclock | Show digital clock |- | mcuf showstring MESSAGE | Show scrolling MESSAGE on the display |- |} == [[CRC]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | crc calc | "read the ethersex program code and calc a crc16 of it" |- | crc read | "read out the crc16 value at the end of the program space" |- |} == [[CRON-Dienst]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | cron_add MIN HOUR DAY MONTH DOW ECMD | Add ECMD to cron to be executed at given time |- | cron_list | Show all cron entries |- | cron_make_persistent | Mark a Job as persistent |- | cron_rm POSITION | Remove one cron entry |- | cron_save | Saves all persistent jobs |- |} == [[DALI]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dali cmd [TARGET] [COMMAND] [!][?] | "send the given command (decimal) to targets (all, g00 to g15, s00 to s63), auto repeat with !, read reply with ?" |- | dali dim [TARGET] [LEVEL] | "dim targets (all, g00 to g15, s00 to s63) to given level (0-254)" |- | dali raw [BYTE1] [BYTE2] | "send a raw frame (two bytes, given in hex) over the DALI bus" |- | dali scmd [SPECIAL COMMAND] [DATA] [!][?] | "send special command (256-287) with data, auto repeat with !, read reply with ?" |- |} == [[DMX_FXSlot]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx fxslot devices | set the device settings |- | dmx fxslot effect | set the effect settings |- | dmx fxslot reset | reset all fxslots and clear saved ones in EEPROM |- | dmx fxslot restore | restore the settings from EEPROM |- | dmx fxslot save | save the current fxslots to EEPROM |- |} == [[DMX_Storage]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx channels | Get channels per universe |- | dmx get | Return channel value |- | dmx set | Set channel values |- | dmx universe | Get a whole universe |- | dmx universes | Get universes |- |} == [[Dallas_1-wire_Bus]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | 1w convert [DEVICE] | Trigger temperature conversion of either DEVICE or all connected devices |- | 1w ds2450 convert [DEVICE] | `start conversion (with optional input mask and read out control)' |- | 1w ds2450 get [DEVICE] | `get conversion result (one or all channels)' |- | 1w ds2450 oc [DEVICE] | `get/set output control (per channel)' |- | 1w ds2450 oe [DEVICE] | `get/set output enable (per channel)' |- | 1w ds2450 por [DEVICE] | `get/set power on reset (per channel)' |- | 1w ds2450 power [DEVICE] | `get/set power supply of device (global)' |- | 1w ds2450 range [DEVICE] | `get/set input voltage range (per channel)' |- | 1w ds2450 res [DEVICE] | `get/set bit resolution of AD convert (per channel)' |- | 1w get DEVICE | Return temperature value of onewire DEVICE (provide 64-bit ID as 16-hex-digits) |- | 1w list | Return a list of the connected onewire devices |- |} == [[DataFlash]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | df status | Display internal status. |- | fs format | Format the filesystem. |- | fs inspect inode INODE | Inspect INODE (and associated page). |- | fs inspect node NODE | Inspect NODE and dump to serial. |- | fs list | List the directory. |- | fs mkfile NAME | Create a new file NAME. |- | fs remove NAME | Delete the file NAME. |- | fs truncate NAME LEN | Truncate the file NAME to LEN bytes. |- |} == [[Dc3840_camera|DC3840 mobil camera support]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dc3840 capture | Take a picture. Access 'dc3840' via VFS afterwards. See [[DC3840 Camera]] for details. |- | dc3840 light | Light level of camera |- | dc3840 send A B C D E | Send provided command bytes to the camera. |- | dc3840 sync | Re-sync to the camera |- | dc3840 zoom | Enable zoom of camera |- |} == [[ECMDScript]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | call FILENAME | Start script named FILENAME |- | cat FILENAME | cat file content (with debug only) |- | dec VAR | Decrement variable VAR (a number) |- | echo <any> | Print out all arguments of echo |- | exit | Exit currently running script |- | get VAR | Get value of variable VAR |- | goto N | Goto line N in currently running script |- | if ( CMD/VAR == CONST ) then CMD2 | If condition matches execute CMD2 |- | inc VAR | Increment variable VAR (a number) |- | rem <any> | Remark for anything |- | set VAR VALUE | Set variable VAR to VALUE |- | wait I | Wait I milliseconds |- |} == [[FS20]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fht send HOUSECODE ADDR CMD [CMD2] | Send FHT command. See [[FS20]] for details. |- | fs20 receive | Receive FS20/FHT sequence and display it. |- | fs20 send HOUSECODE ADDR CMD [CMD2] | Send FS20 command. See [[FS20]] for details. |- | fs20 ws300 | Receive FS20 sequence from WS300 weather station and decode it. |- |} == [[Frequency Counter]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fc %duty [CHANNEL] | "returns last on duty cycle in percent for given channel" |- | fc duty [CHANNEL] | "returns last on duty cycle (0-255) for given channel" |- | fc freq [CHANNEL] | "returns last frequency in Hz for given channel" |- | fc off [CHANNEL] | "switch off frequency counting on given channel" |- | fc on [CHANNEL] | "switch on frequency counting on given channel" |- | fc ticks [CHANNEL] | "returns last frequency in CPU ticks for given channel" |- |} == [[GLCD_Menu]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | glcdmenu key VALUE | Send a keypress to the menu |- | glcdmenu update | Update the menu |- |} == [[GPS]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | nmea get | Get latitude and longitude data |- | nmea satellites | Get satellites |- |} == [[H-Bridge]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | hbridge [action] [enable_l] [enable_r] | Set H-Bridge command |- | hbridge pwm int | Set H-Bridge enable line valueeg. speed |- |} == [[I2C]] (TWI) == {| border='1' | ''Command syntax'' | ''Short description'' |- | bmp085 apress | Get absolute pressure in Pa |- | bmp085 height PRESSNN | Get height in cm, pressure at N0 needed |- | bmp085 pressnn HEIGHT | Get pressure at N0, height in cm needed |- | bmp085 temp | Get temperature in 0.1°C |- | ds1631 convert ADDR VALUE | Initiate temperature conversions (0: stop, 1: convert) |- | ds1631 temp ADDR | Read last converted temperature |- | i2c detect | list detected I2C Chips |- | i2c rbb ADDR | read byte from I2C chip |- | i2c rbd CHIPADDR REGADDR | read byte from register address at I2C chip |- | i2c rwd CHIPADDR REGADDR | read word from register address at I2C chip |- | i2c wbb ADDR HEXVALUE | write byte to I2C chip |- | i2c wbd CHIPADDR REGADDR HEXVALUE | write byte to register address on I2C chip |- | i2c wwd CHIPADDR REGADDR HEXVALUE | write word to register address on I2C chip |- | lm75 ADDR | Get temperature |- | max7311 getDDRw ADDR | Get Direction-Register DDR |- | max7311 getINw ADDR | Get Input-Register IN |- | max7311 getOUTw ADDR | Get Output-Register OUT |- | max7311 pulse ADDR BIT TIME | Toggle Output-BIT for TIME (in ms) |- | max7311 set ADDR BIT VALUE | Set Output-BIT to VALUE (bool) |- | max7311 setDDRw ADDR VALUE | Set Direction-Register DDR (VALUE as hex) |- | max7311 setOUTw ADDR VALUE | Set Output-Register OUT (VALUE as hex) |- | pca9531 ADDR PERIODPWM1 DUTYPWM1 PERIODPWM2 DUTYPWM2 LED0..3 LED4..7 | set PWM1 and PWM2 and LED states |- | pca9685m ADDR | OUTDRV, IVRT, PRESCALE |- | pca9685s ADDR | LED, ON, OFF |- | pcf8574x read ADDR CHIP | Get bits |- | pcf8574x set ADDR CHIP HEXVALUE | Set bits |- | tsl2550 lux | Show light level by reading adc registers and computing level |- | tsl2550 mode VALUE | Set the TSL2550s operating mode (0: standard range, 1: extended range) |- | tsl2550 power VALUE | Set the TSL2550s power state (0: down, 1:up) |- |} == [[Jabber]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | jabber_host [HOSTNAME] | JABBER hostname |- | jabber_pass [PASSWORD] | JABBER password |- | jabber_resrc [RESOURCE] | JABBER resource |- | jabber_user [USERNAME] | JABBER username |- |} == [[KTY]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | kty autocalibrate CHANNEL | Calibrate to 1000 Ohm precision Resistor. |- | kty cal get | Return the calibration difference to 2k2 Resistor. |- | kty get [CHANNEL] | Get the temperature in xxx.x °C of CHANNEL or if no channel set of all channels. |- |} == [[MotorCurtain]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | curtain VALUE | Set value of curtain. 0=closed..7=open. If you use fewer sensors, use the corrent value instead of 7. |- | curtainlast | Return last known position |- | curtainmax | Return maximum position |- | curtainoff | Switch motor off |- |} == [[Named_PIN]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | pin get NAME | Read and display the status of pin NAME. |- | pin list | List all known named-pins. |- | pin set NAME STATUS | Set the status of pin NAME to STATUS. |- | pin toggle NAME | Toggle the status of pin NAME. |- |} == [[PWM]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dtmf CHARS | send CHARS as DTMF |- | freq set FREQUENCY DELAY | Set frequency for DELAY ms |- | pwm fade [channel +-diff startvalue] | Set fading at channel with startvalue and change each stepp to diff (must be signed 3 digit) |- | pwm set [channel value] | Set channel to value |- |} == [[RFM12]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | rfm12 reinit | Re-initialize RFM12 module. |- | rfm12 setbandwidth BW | Set RX bandwidth to BW. |- | rfm12 setbaud BAUD | Set baudrate to BAUD. |- | rfm12 setdrssi DRSSI | Set the drssi to DRSSI. |- | rfm12 setgain GAIN | Set preamplifier gain to GAIN. |- | rfm12 setmod MOD | Set modulation to MOD. |- | rfm12 status | Display internal status. |- |} == [[RFM12_ASK]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | rfm12 1527 | housecodeCommand delay cnt |- | rfm12 2272 | housecodeCommand delay cnt |- | rfm12 ask sense | Trigger (Tevion) ASK sensing. Enable ext. filter pin before! |- | rfm12 external filter [1] | Enable ext. filter pin if argument is present (disable otherwise) |- | rfm12 intertechno | family group device command |- | rfm12 tevion | housecode command delay cnt |- |} == [[RFM12_FS20]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fht send | housecode addr command data |- | fs20 send | housecode addr command data |- |} == [[SD-Karte]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sd dir | List contents of current SD directory. |- | sd mkdir PATH | Create directory hierarchy PATH. |- |} == [[SHT]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sht humid | Return humidity of SHT sensor |- | sht raw | Return raw hex temp (first line) and humidity value (second line) of SHT sensor |- | sht temp | Return temperature of SHT sensor |- |} == [[SMS77]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sms77 MESSAGE | Send MESSAGE to compiled in sms77 service |- | sms77_pass [PASSWORD] | SMS77 password |- | sms77_recv [RECEIVER] | SMS receiver |- | sms77_type [TYPE] | SMS type |- | sms77_user [USERNAME] | SMS77 username |- |} == [[Servo_Ansteuerung|PWM Servo Control]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | pwm servo_dec SERVONR | Decrement position of servo SERVONR |- | pwm servo_inc SERVONR | Increment position of servo SERVONR |- | pwm servo_set SERVONR POSITION | Set servo with SERVONR to POSITION |- |} == [[Sound]]/WAV support == {| border='1' | ''Command syntax'' | ''Short description'' |- | pwm stop | Stop wav |- | pwm wav <FILENAME> | Play wave file. Use VFS if compiled in. More details at [[Sound]] |- |} == [[Stella_Light]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | channel CHANNEL VALUE FUNCTION | Get/Set stella channel to value. Second and third parameters are optional. Function: You may use 's' for instant set, 'f' for fade and 'y' for flashy fade. |- | channels | Return stella channel size |- | fadestep FADESTEP | Get/Set stella fade step |- | stella load | Load values from eeprom |- | stella store | Store values in eeprom |- |} == [[USB]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | keyboard MESSAGE | Send MESSAGE as HID keyboard |- | mouse BUTTON DELTAX DELTAY | Send data as HID mouse |- |} == [[ZACwire]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | zac 306 PORT BIT | Return temperature of TSic 306 at BIT of PORT |- | zac 506 PORT BIT | Return temperature of TSic 506 at BIT of PORT |- | zac raw PORT BIT | Return raw hex temperature value of zacwire at BIT of PORT |- |} == lome6 == {| border='1' | ''Command syntax'' | ''Short description'' |- | lome6 get_t TYPE | get temperature command |- | lome6 power TYPE | press power command |- | lome6 reset | press reset command |- | lome6 set_t TYPE TEMPERATURE | set temperature command |- | lome6 state | get state command |- | lome6 uptime UPTIME | set/get uptime command |- |} == Miscelleanous == {| border='1' | ''Command syntax'' | ''Short description'' |- | alias list | List all available aliases |- | artnet test | artnet test |- | cw send MESSAGE | Send MESSAGE in Morce Code |- | d ADDR | Dump the memory at ADDR (16 bytes). |- | eeprom reinit | Force reinitialization of the EEPROM config area |- | free | Display free space. |- | help | List which commands are available. |- | ht MESSAGE | Send MESSAGE to compiled in httplog service |- | ipstats | Display IP statistics. |- | mb recv | Receive data from modbus |- | moodlight CHANNEL ONOFF | Set CHANNEL moodlight on=1 or off=0. If no channel is given return on if channel CHANNEL is moodlighted |- | motd [MESSAGE] | Save MESSAGE as new message of the day, otherwise just show current message |- | msr1 get | Get data |- | mysql query QUERY | Send specified MySQL query to the configured server |- | ns | update net statistic for public anouncment of currently running ethersex |- | pam USER PASSWORD | Use pam for user and password |- | push NUMBER | Push button identified by NUMBER |- | pwm melody [NUMBER] | Play melody |- | sanyoz700 CMD | Send command to projector |- | sll get | Request the logged data |- | sram memtest | Perform a memory test |- | srf05 | Read SRF05 measurement |- | to1 get | Request data from sensor |- | tw MESSAGE | Send MESSAGE to compiled in twitter service |- | upnp send | Manually send UPnP broadcast packet |- | usart baud BAUD | Set the USART baudrate to BAUD. |- | version | Display the version number. |- | wol MAC | Send WAKE-ON-LAN command to MAC |- | yport stats | Report statistic counters |- | zbus stats | Report statistic counters |- |} [[Category:Ethersex]] [[Category:ECMD]] 63286a137e5d6e472e88259019d183234f24b2c5 1731 1730 2016-09-22T20:40:07Z Daniel 725 wikitext text/x-wiki <div class="errorbox"> This page is automatically generated from the files in the Ethersex source code repository. Do not edit this page but send [[patches]] for those files! </div> <br> <br> __NOTOC__ == Analog/Digital Conversion ([[ADC]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | adc get [CHANNEL] | Get the ADC value in hex of CHANNEL or if no channel set of all channels. |- | hr20 temp | Read HR20 temperature sensor. |- |} == DNS Resolver == {| border='1' | ''Command syntax'' | ''Short description'' |- | dns server [IPADDR] | Display/Set the IP address of the DNS server to use to IPADDR. |- | nslookup HOSTNAME | Do DNS lookup for HOSTNAME (call twice). |- |} == Digital/Analog Conversion ([[DAC]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ltc1257_delay `[VALUE] | Set (if VALUE given) or get (no VALUE) delay for LTC1257 output bit changes in µs' |- | ltc1257_set `[VALUE0] [VALUE1] ... | Set output to value (value: 0-4095)' |- | tlc5620 `[CHANNEL] [VALUE] | Set Output to value (Value: 0-0xff)' |- |} == Fnordlicht == {| border='1' | ''Command syntax'' | ''Short description'' |- | fnordlicht "ADDRESS RED | GREEN,BLUE",fnordlicht command to set RGB color |- | fnordlicht_init | fnordlicht init |- |} == HD44780 [[LCD]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | hr20 hourbar START STOP | Update hourbar to show ticks between START and STOP (range 0..23) |- | hr20 toggle SEG | Toggle segment SEG (a number, not a symbolic name!) |- | lcd backlight STATE | switch back light STATE to ON or OFF |- | lcd char N D1 D2 D3 D4 D5 D6 D7 D8 | Define use-definable char N with data D1..D8 (provide DATA in hex) |- | lcd clear [LINE] | Clear line LINE (0..3) or the whole display (if parameter is omitted) |- | lcd goto LINE COL | Move cursor to LINE and column COL (origin is 0/0) |- | lcd reinit CURSOR BLINK | Reinitialize the display, set whether to show the cursor (CURSOR, 0 or 1) and whether the cursor shall BLINK |- | lcd shift DIR | Shift the display to DIR (either ''left'' or ''right'') |- | lcd write TEXT | Write TEXT to the current cursor location |- |} == Infrared Send/Receive ([[IR-TRX]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ir receive | receive an IR command |- | ir send DEVICE COMMAND | send COMMAND to DEVICE |- |} == Infrared Send/Receive ([[IRMP]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | irmp receive | receive an IR command |- | irmp send PROTOCOL DEVICE COMMAND REPEAT | send COMMAND with REPEAT flag to DEVICE using PROTOCOL |- |} == NTP Client == {| border='1' | ''Command syntax'' | ''Short description'' |- | ntp query | Query the NTP server to get an NTP update. |- | ntp server [IPADDR] | Display/Set the IP address of the NTP server to use to IPADDR. |- | ntp status | Display NTP server status |- |} == Network configuration == {| border='1' | ''Command syntax'' | ''Short description'' |- | enc dump | Dump the internal state of the enc to serial |- | gw [IP] | Display/Set the address of the default router. |- | ip [IP] | Display/Set the IP address. |- | mac [xx:xx:xx:xx:xx:xx] | Display/Set the MAC address. |- | netmask [IP] | Display/Set the network mask. |- |} == Port I/O == {| border='1' | ''Command syntax'' | ''Short description'' |- | io get ddr PORTNUM | Display the current value of the DDR PORTNUM. |- | io get mask PORTNUM | Display the mask of the port PORTNUM. |- | io get pin PORTNUM | Display the current value of the PIN-register of the port PORTNUM. |- | io get port NUM | Display the current value of the PORT NUM. |- | io set ddr PORTNUM HEXVALUE [MASK] | Set the DDR of port PORTNUM to VALUE (possibly using the provided MASK). |- | io set port NUM HEXVALUE [MASK] | Set the PORT NUM to VALUE (possibly using the provided MASK). |- |} == Reading and Writing EEPROM Space on Device == {| border='1' | ''Command syntax'' | ''Short description'' |- | eer eer <ADDR> <LENGTH> | Read n bytes from address after the config in eeprom. |- | eew eew <ADDR> <HEXBYTES> | Write Hexbytes at address after the config in epprom. |- | fuse | Display current fuse settings |- | hostname | Display hostname. |- |} == Resetting the controller == {| border='1' | ''Command syntax'' | ''Short description'' |- | bootloader | Call the bootloader. |- | reset | Reset the Ethersex. |- | wdreset | Go into endless loop to trigger a watchdog timeout. |- |} == [[ADS]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | adc get | Get the ADC value in hex. |- | adc mean [COUNT] | Get the mean of power of 2 COUNT ADC values in hex. |- |} == [[Am_Puls_der_Zeit|Clock]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | date | Print the current date. |- | lastdcf | Print when last valid DCF signal was received. |- | time [UNIXTIME] | Display/Set the current time in seconds since January 1st 1970. |- | uptime | Display ethersex uptime in unix format. |- | whm | Display ethersex uptime. |- |} == [[Application_Sample]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sample | Manually call application sample commands |- | sample_init | Manually call application sample init method |- | sample_periodic | Manually call application sample periodic method |- |} == [[Blinkenlights_MCUF|MCUF]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | mcuf modul N | Select module N |- | mcuf modul list | List all modules |- | mcuf showclock | Show digital clock |- | mcuf showstring MESSAGE | Show scrolling MESSAGE on the display |- |} == [[CRC]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | crc calc | "read the ethersex program code and calc a crc16 of it" |- | crc read | "read out the crc16 value at the end of the program space" |- |} == [[CRON-Dienst]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | cron_add MIN HOUR DAY MONTH DOW ECMD | Add ECMD to cron to be executed at given time |- | cron_list | Show all cron entries |- | cron_make_persistent | Mark a Job as persistent |- | cron_rm POSITION | Remove one cron entry |- | cron_save | Saves all persistent jobs |- |} == [[DALI]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dali cmd [TARGET] [COMMAND] [!][?] | "send the given command (decimal) to targets (all, g00 to g15, s00 to s63), auto repeat with !, read reply with ?" |- | dali dim [TARGET] [LEVEL] | "dim targets (all, g00 to g15, s00 to s63) to given level (0-254)" |- | dali raw [BYTE1] [BYTE2] | "send a raw frame (two bytes, given in hex) over the DALI bus" |- | dali scmd [SPECIAL COMMAND] [DATA] [!][?] | "send special command (256-287) with data, auto repeat with !, read reply with ?" |- |} == [[DMX_FXSlot]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx fxslot devices | set the device settings |- | dmx fxslot effect | set the effect settings |- | dmx fxslot reset | reset all fxslots and clear saved ones in EEPROM |- | dmx fxslot restore | restore the settings from EEPROM |- | dmx fxslot save | save the current fxslots to EEPROM |- |} == [[DMX_Storage]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx channels | Get channels per universe |- | dmx get | Return channel value |- | dmx set | Set channel values |- | dmx universe | Get a whole universe |- | dmx universes | Get universes |- |} == [[Dallas_1-wire_Bus]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | 1w convert [DEVICE] | Trigger temperature conversion of either DEVICE or all connected devices |- | 1w ds2450 convert [DEVICE] | `start conversion (with optional input mask and read out control)' |- | 1w ds2450 get [DEVICE] | `get conversion result (one or all channels)' |- | 1w ds2450 oc [DEVICE] | `get/set output control (per channel)' |- | 1w ds2450 oe [DEVICE] | `get/set output enable (per channel)' |- | 1w ds2450 por [DEVICE] | `get/set power on reset (per channel)' |- | 1w ds2450 power [DEVICE] | `get/set power supply of device (global)' |- | 1w ds2450 range [DEVICE] | `get/set input voltage range (per channel)' |- | 1w ds2450 res [DEVICE] | `get/set bit resolution of AD convert (per channel)' |- | 1w get DEVICE | Return temperature value of onewire DEVICE (provide 64-bit ID as 16-hex-digits) |- | 1w list | Return a list of the connected onewire devices |- |} == [[DataFlash]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | df status | Display internal status. |- | fs format | Format the filesystem. |- | fs inspect inode INODE | Inspect INODE (and associated page). |- | fs inspect node NODE | Inspect NODE and dump to serial. |- | fs list | List the directory. |- | fs mkfile NAME | Create a new file NAME. |- | fs remove NAME | Delete the file NAME. |- | fs truncate NAME LEN | Truncate the file NAME to LEN bytes. |- |} == [[Dc3840_camera|DC3840 mobil camera support]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dc3840 capture | Take a picture. Access 'dc3840' via VFS afterwards. See [[DC3840 Camera]] for details. |- | dc3840 light | Light level of camera |- | dc3840 send A B C D E | Send provided command bytes to the camera. |- | dc3840 sync | Re-sync to the camera |- | dc3840 zoom | Enable zoom of camera |- |} == [[ECMDScript]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | call FILENAME | Start script named FILENAME |- | cat FILENAME | cat file content (with debug only) |- | dec VAR | Decrement variable VAR (a number) |- | echo <any> | Print out all arguments of echo |- | exit | Exit currently running script |- | get VAR | Get value of variable VAR |- | goto N | Goto line N in currently running script |- | if ( CMD/VAR == CONST ) then CMD2 | If condition matches execute CMD2 |- | inc VAR | Increment variable VAR (a number) |- | rem <any> | Remark for anything |- | set VAR VALUE | Set variable VAR to VALUE |- | wait I | Wait I milliseconds |- |} == [[FS20]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fht send HOUSECODE ADDR CMD [CMD2] | Send FHT command. See [[FS20]] for details. |- | fs20 receive | Receive FS20/FHT sequence and display it. |- | fs20 send HOUSECODE ADDR CMD [CMD2] | Send FS20 command. See [[FS20]] for details. |- | fs20 ws300 | Receive FS20 sequence from WS300 weather station and decode it. |- |} == [[Frequency Counter]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fc %duty [CHANNEL] | "returns last on duty cycle in percent for given channel" |- | fc duty [CHANNEL] | "returns last on duty cycle (0-255) for given channel" |- | fc freq [CHANNEL] | "returns last frequency in Hz for given channel" |- | fc off [CHANNEL] | "switch off frequency counting on given channel" |- | fc on [CHANNEL] | "switch on frequency counting on given channel" |- | fc ticks [CHANNEL] | "returns last frequency in CPU ticks for given channel" |- |} == [[GLCD_Menu]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | glcdmenu key VALUE | Send a keypress to the menu |- | glcdmenu update | Update the menu |- |} == [[GPS]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | nmea get | Get latitude and longitude data |- | nmea satellites | Get satellites |- |} == [[H-Bridge]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | hbridge [action] [enable_l] [enable_r] | Set H-Bridge command |- | hbridge pwm int | Set H-Bridge enable line valueeg. speed |- |} == [[I2C]] (TWI) == {| border='1' | ''Command syntax'' | ''Short description'' |- | bmp085 apress | Get absolute pressure in Pa |- | bmp085 height PRESSNN | Get height in cm, pressure at N0 needed |- | bmp085 pressnn HEIGHT | Get pressure at N0, height in cm needed |- | bmp085 temp | Get temperature in 0.1°C |- | ds1631 convert ADDR VALUE | Initiate temperature conversions (0: stop, 1: convert) |- | ds1631 temp ADDR | Read last converted temperature |- | i2c detect | list detected I2C Chips |- | i2c rbb ADDR | read byte from I2C chip |- | i2c rbd CHIPADDR REGADDR | read byte from register address at I2C chip |- | i2c rwd CHIPADDR REGADDR | read word from register address at I2C chip |- | i2c wbb ADDR HEXVALUE | write byte to I2C chip |- | i2c wbd CHIPADDR REGADDR HEXVALUE | write byte to register address on I2C chip |- | i2c wwd CHIPADDR REGADDR HEXVALUE | write word to register address on I2C chip |- | lm75 ADDR | Get temperature |- | max7311 getDDRw ADDR | Get Direction-Register DDR |- | max7311 getINw ADDR | Get Input-Register IN |- | max7311 getOUTw ADDR | Get Output-Register OUT |- | max7311 pulse ADDR BIT TIME | Toggle Output-BIT for TIME (in ms) |- | max7311 set ADDR BIT VALUE | Set Output-BIT to VALUE (bool) |- | max7311 setDDRw ADDR VALUE | Set Direction-Register DDR (VALUE as hex) |- | max7311 setOUTw ADDR VALUE | Set Output-Register OUT (VALUE as hex) |- | pca9531 ADDR PERIODPWM1 DUTYPWM1 PERIODPWM2 DUTYPWM2 LED0..3 LED4..7 | set PWM1 and PWM2 and LED states |- | pca9685m ADDR | OUTDRV, IVRT, PRESCALE |- | pca9685s ADDR | LED, ON, OFF |- | pcf8574x read ADDR CHIP | Get bits |- | pcf8574x set ADDR CHIP HEXVALUE | Set bits |- | tsl2550 lux | Show light level by reading adc registers and computing level |- | tsl2550 mode VALUE | Set the TSL2550s operating mode (0: standard range, 1: extended range) |- | tsl2550 power VALUE | Set the TSL2550s power state (0: down, 1:up) |- |} == [[Jabber]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | jabber_host [HOSTNAME] | JABBER hostname |- | jabber_pass [PASSWORD] | JABBER password |- | jabber_resrc [RESOURCE] | JABBER resource |- | jabber_user [USERNAME] | JABBER username |- |} == [[KTY]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | kty autocalibrate CHANNEL | Calibrate to 1000 Ohm precision Resistor. |- | kty cal get | Return the calibration difference to 2k2 Resistor. |- | kty get [CHANNEL] | Get the temperature in xxx.x °C of CHANNEL or if no channel set of all channels. |- |} == [[MotorCurtain]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | curtain VALUE | Set value of curtain. 0=closed..7=open. If you use fewer sensors, use the corrent value instead of 7. |- | curtainlast | Return last known position |- | curtainmax | Return maximum position |- | curtainoff | Switch motor off |- |} == [[Named_PIN]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | pin get NAME | Read and display the status of pin NAME. |- | pin list | List all known named-pins. |- | pin set NAME STATUS | Set the status of pin NAME to STATUS. |- | pin toggle NAME | Toggle the status of pin NAME. |- |} == [[PWM]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dtmf CHARS | send CHARS as DTMF |- | freq set FREQUENCY DELAY | Set frequency for DELAY ms |- | pwm fade [channel +-diff startvalue] | Set fading at channel with startvalue and change each stepp to diff (must be signed 3 digit) |- | pwm set [channel value] | Set channel to value |- |} == [[RFM12]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | rfm12 reinit | Re-initialize RFM12 module. |- | rfm12 setbandwidth BW | Set RX bandwidth to BW. |- | rfm12 setbaud BAUD | Set baudrate to BAUD. |- | rfm12 setdrssi DRSSI | Set the drssi to DRSSI. |- | rfm12 setgain GAIN | Set preamplifier gain to GAIN. |- | rfm12 setmod MOD | Set modulation to MOD. |- | rfm12 status | Display internal status. |- |} == [[RFM12_ASK]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | rfm12 1527 | housecodeCommand delay cnt |- | rfm12 2272 | housecodeCommand delay cnt |- | rfm12 ask sense | Trigger (Tevion) ASK sensing. Enable ext. filter pin before! |- | rfm12 external filter [1] | Enable ext. filter pin if argument is present (disable otherwise) |- | rfm12 intertechno | family group device command |- | rfm12 tevion | housecode command delay cnt |- |} == [[RFM12_FS20]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fht send | housecode addr command data |- | fs20 send | housecode addr command data |- |} == [[SD-Karte]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sd dir | List contents of current SD directory. |- | sd mkdir PATH | Create directory hierarchy PATH. |- |} == [[SHT]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sht humid | Return humidity of SHT sensor |- | sht raw | Return raw hex temp (first line) and humidity value (second line) of SHT sensor |- | sht temp | Return temperature of SHT sensor |- |} == [[SMS77]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sms77 MESSAGE | Send MESSAGE to compiled in sms77 service |- | sms77_pass [PASSWORD] | SMS77 password |- | sms77_recv [RECEIVER] | SMS receiver |- | sms77_type [TYPE] | SMS type |- | sms77_user [USERNAME] | SMS77 username |- |} == [[Servo_Ansteuerung|PWM Servo Control]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | pwm servo_dec SERVONR | Decrement position of servo SERVONR |- | pwm servo_inc SERVONR | Increment position of servo SERVONR |- | pwm servo_set SERVONR POSITION | Set servo with SERVONR to POSITION |- |} == [[Sound]]/WAV support == {| border='1' | ''Command syntax'' | ''Short description'' |- | pwm stop | Stop wav |- | pwm wav <FILENAME> | Play wave file. Use VFS if compiled in. More details at [[Sound]] |- |} == [[Stella_Light]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | channel CHANNEL VALUE FUNCTION | Get/Set stella channel to value. Second and third parameters are optional. Function: You may use 's' for instant set, 'f' for fade and 'y' for flashy fade. |- | channels | Return stella channel size |- | fadestep FADESTEP | Get/Set stella fade step |- | stella load | Load values from eeprom |- | stella store | Store values in eeprom |- |} == [[USB]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | keyboard MESSAGE | Send MESSAGE as HID keyboard |- | mouse BUTTON DELTAX DELTAY | Send data as HID mouse |- |} == [[ZACwire]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | zac 306 PORT BIT | Return temperature of TSic 306 at BIT of PORT |- | zac 506 PORT BIT | Return temperature of TSic 506 at BIT of PORT |- | zac raw PORT BIT | Return raw hex temperature value of zacwire at BIT of PORT |- |} == lome6 == {| border='1' | ''Command syntax'' | ''Short description'' |- | lome6 get_t TYPE | get temperature command |- | lome6 power TYPE | press power command |- | lome6 reset | press reset command |- | lome6 set_t TYPE TEMPERATURE | set temperature command |- | lome6 state | get state command |- | lome6 uptime UPTIME | set/get uptime command |- |} == Miscelleanous == {| border='1' | ''Command syntax'' | ''Short description'' |- | alias list | List all available aliases |- | artnet test | artnet test |- | cw send MESSAGE | Send MESSAGE in Morce Code |- | d ADDR | Dump the memory at ADDR (16 bytes). |- | eeprom reinit | Force reinitialization of the EEPROM config area |- | free | Display free space. |- | help | List which commands are available. |- | ht MESSAGE | Send MESSAGE to compiled in httplog service |- | ipstats | Display IP statistics. |- | mb recv | Receive data from modbus |- | moodlight CHANNEL ONOFF | Set CHANNEL moodlight on=1 or off=0. If no channel is given return on if channel CHANNEL is moodlighted |- | motd [MESSAGE] | Save MESSAGE as new message of the day, otherwise just show current message |- | msr1 get | Get data |- | mysql query QUERY | Send specified MySQL query to the configured server |- | ns | update net statistic for public anouncment of currently running ethersex |- | pam USER PASSWORD | Use pam for user and password |- | push NUMBER | Push button identified by NUMBER |- | pwm melody [NUMBER] | Play melody |- | sanyoz700 CMD | Send command to projector |- | sll get | Request the logged data |- | sram memtest | Perform a memory test |- | srf05 | Read SRF05 measurement |- | to1 get | Request data from sensor |- | tw MESSAGE | Send MESSAGE to compiled in twitter service |- | upnp send | Manually send UPnP broadcast packet |- | usart baud BAUD | Set the USART baudrate to BAUD. |- | version | Display the version number. |- | wol MAC | Send WAKE-ON-LAN command to MAC |- | yport stats | Report statistic counters |- | zbus stats | Report statistic counters |- |} [[Category:Ethersex]] [[Category:ECMD]] 873fee646ae653f9d07dca7a8184c21296eb7461 1732 1731 2016-09-22T20:40:23Z Daniel 725 wikitext text/x-wiki <div class="errorbox"> This page is automatically generated from the files in the Ethersex source code repository. Do not edit this page but send [[patches]] for those files! </div> __NOTOC__ == Analog/Digital Conversion ([[ADC]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | adc get [CHANNEL] | Get the ADC value in hex of CHANNEL or if no channel set of all channels. |- | hr20 temp | Read HR20 temperature sensor. |- |} == DNS Resolver == {| border='1' | ''Command syntax'' | ''Short description'' |- | dns server [IPADDR] | Display/Set the IP address of the DNS server to use to IPADDR. |- | nslookup HOSTNAME | Do DNS lookup for HOSTNAME (call twice). |- |} == Digital/Analog Conversion ([[DAC]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ltc1257_delay `[VALUE] | Set (if VALUE given) or get (no VALUE) delay for LTC1257 output bit changes in µs' |- | ltc1257_set `[VALUE0] [VALUE1] ... | Set output to value (value: 0-4095)' |- | tlc5620 `[CHANNEL] [VALUE] | Set Output to value (Value: 0-0xff)' |- |} == Fnordlicht == {| border='1' | ''Command syntax'' | ''Short description'' |- | fnordlicht "ADDRESS RED | GREEN,BLUE",fnordlicht command to set RGB color |- | fnordlicht_init | fnordlicht init |- |} == HD44780 [[LCD]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | hr20 hourbar START STOP | Update hourbar to show ticks between START and STOP (range 0..23) |- | hr20 toggle SEG | Toggle segment SEG (a number, not a symbolic name!) |- | lcd backlight STATE | switch back light STATE to ON or OFF |- | lcd char N D1 D2 D3 D4 D5 D6 D7 D8 | Define use-definable char N with data D1..D8 (provide DATA in hex) |- | lcd clear [LINE] | Clear line LINE (0..3) or the whole display (if parameter is omitted) |- | lcd goto LINE COL | Move cursor to LINE and column COL (origin is 0/0) |- | lcd reinit CURSOR BLINK | Reinitialize the display, set whether to show the cursor (CURSOR, 0 or 1) and whether the cursor shall BLINK |- | lcd shift DIR | Shift the display to DIR (either ''left'' or ''right'') |- | lcd write TEXT | Write TEXT to the current cursor location |- |} == Infrared Send/Receive ([[IR-TRX]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ir receive | receive an IR command |- | ir send DEVICE COMMAND | send COMMAND to DEVICE |- |} == Infrared Send/Receive ([[IRMP]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | irmp receive | receive an IR command |- | irmp send PROTOCOL DEVICE COMMAND REPEAT | send COMMAND with REPEAT flag to DEVICE using PROTOCOL |- |} == NTP Client == {| border='1' | ''Command syntax'' | ''Short description'' |- | ntp query | Query the NTP server to get an NTP update. |- | ntp server [IPADDR] | Display/Set the IP address of the NTP server to use to IPADDR. |- | ntp status | Display NTP server status |- |} == Network configuration == {| border='1' | ''Command syntax'' | ''Short description'' |- | enc dump | Dump the internal state of the enc to serial |- | gw [IP] | Display/Set the address of the default router. |- | ip [IP] | Display/Set the IP address. |- | mac [xx:xx:xx:xx:xx:xx] | Display/Set the MAC address. |- | netmask [IP] | Display/Set the network mask. |- |} == Port I/O == {| border='1' | ''Command syntax'' | ''Short description'' |- | io get ddr PORTNUM | Display the current value of the DDR PORTNUM. |- | io get mask PORTNUM | Display the mask of the port PORTNUM. |- | io get pin PORTNUM | Display the current value of the PIN-register of the port PORTNUM. |- | io get port NUM | Display the current value of the PORT NUM. |- | io set ddr PORTNUM HEXVALUE [MASK] | Set the DDR of port PORTNUM to VALUE (possibly using the provided MASK). |- | io set port NUM HEXVALUE [MASK] | Set the PORT NUM to VALUE (possibly using the provided MASK). |- |} == Reading and Writing EEPROM Space on Device == {| border='1' | ''Command syntax'' | ''Short description'' |- | eer eer <ADDR> <LENGTH> | Read n bytes from address after the config in eeprom. |- | eew eew <ADDR> <HEXBYTES> | Write Hexbytes at address after the config in epprom. |- | fuse | Display current fuse settings |- | hostname | Display hostname. |- |} == Resetting the controller == {| border='1' | ''Command syntax'' | ''Short description'' |- | bootloader | Call the bootloader. |- | reset | Reset the Ethersex. |- | wdreset | Go into endless loop to trigger a watchdog timeout. |- |} == [[ADS]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | adc get | Get the ADC value in hex. |- | adc mean [COUNT] | Get the mean of power of 2 COUNT ADC values in hex. |- |} == [[Am_Puls_der_Zeit|Clock]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | date | Print the current date. |- | lastdcf | Print when last valid DCF signal was received. |- | time [UNIXTIME] | Display/Set the current time in seconds since January 1st 1970. |- | uptime | Display ethersex uptime in unix format. |- | whm | Display ethersex uptime. |- |} == [[Application_Sample]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sample | Manually call application sample commands |- | sample_init | Manually call application sample init method |- | sample_periodic | Manually call application sample periodic method |- |} == [[Blinkenlights_MCUF|MCUF]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | mcuf modul N | Select module N |- | mcuf modul list | List all modules |- | mcuf showclock | Show digital clock |- | mcuf showstring MESSAGE | Show scrolling MESSAGE on the display |- |} == [[CRC]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | crc calc | "read the ethersex program code and calc a crc16 of it" |- | crc read | "read out the crc16 value at the end of the program space" |- |} == [[CRON-Dienst]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | cron_add MIN HOUR DAY MONTH DOW ECMD | Add ECMD to cron to be executed at given time |- | cron_list | Show all cron entries |- | cron_make_persistent | Mark a Job as persistent |- | cron_rm POSITION | Remove one cron entry |- | cron_save | Saves all persistent jobs |- |} == [[DALI]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dali cmd [TARGET] [COMMAND] [!][?] | "send the given command (decimal) to targets (all, g00 to g15, s00 to s63), auto repeat with !, read reply with ?" |- | dali dim [TARGET] [LEVEL] | "dim targets (all, g00 to g15, s00 to s63) to given level (0-254)" |- | dali raw [BYTE1] [BYTE2] | "send a raw frame (two bytes, given in hex) over the DALI bus" |- | dali scmd [SPECIAL COMMAND] [DATA] [!][?] | "send special command (256-287) with data, auto repeat with !, read reply with ?" |- |} == [[DMX_FXSlot]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx fxslot devices | set the device settings |- | dmx fxslot effect | set the effect settings |- | dmx fxslot reset | reset all fxslots and clear saved ones in EEPROM |- | dmx fxslot restore | restore the settings from EEPROM |- | dmx fxslot save | save the current fxslots to EEPROM |- |} == [[DMX_Storage]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx channels | Get channels per universe |- | dmx get | Return channel value |- | dmx set | Set channel values |- | dmx universe | Get a whole universe |- | dmx universes | Get universes |- |} == [[Dallas_1-wire_Bus]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | 1w convert [DEVICE] | Trigger temperature conversion of either DEVICE or all connected devices |- | 1w ds2450 convert [DEVICE] | `start conversion (with optional input mask and read out control)' |- | 1w ds2450 get [DEVICE] | `get conversion result (one or all channels)' |- | 1w ds2450 oc [DEVICE] | `get/set output control (per channel)' |- | 1w ds2450 oe [DEVICE] | `get/set output enable (per channel)' |- | 1w ds2450 por [DEVICE] | `get/set power on reset (per channel)' |- | 1w ds2450 power [DEVICE] | `get/set power supply of device (global)' |- | 1w ds2450 range [DEVICE] | `get/set input voltage range (per channel)' |- | 1w ds2450 res [DEVICE] | `get/set bit resolution of AD convert (per channel)' |- | 1w get DEVICE | Return temperature value of onewire DEVICE (provide 64-bit ID as 16-hex-digits) |- | 1w list | Return a list of the connected onewire devices |- |} == [[DataFlash]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | df status | Display internal status. |- | fs format | Format the filesystem. |- | fs inspect inode INODE | Inspect INODE (and associated page). |- | fs inspect node NODE | Inspect NODE and dump to serial. |- | fs list | List the directory. |- | fs mkfile NAME | Create a new file NAME. |- | fs remove NAME | Delete the file NAME. |- | fs truncate NAME LEN | Truncate the file NAME to LEN bytes. |- |} == [[Dc3840_camera|DC3840 mobil camera support]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dc3840 capture | Take a picture. Access 'dc3840' via VFS afterwards. See [[DC3840 Camera]] for details. |- | dc3840 light | Light level of camera |- | dc3840 send A B C D E | Send provided command bytes to the camera. |- | dc3840 sync | Re-sync to the camera |- | dc3840 zoom | Enable zoom of camera |- |} == [[ECMDScript]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | call FILENAME | Start script named FILENAME |- | cat FILENAME | cat file content (with debug only) |- | dec VAR | Decrement variable VAR (a number) |- | echo <any> | Print out all arguments of echo |- | exit | Exit currently running script |- | get VAR | Get value of variable VAR |- | goto N | Goto line N in currently running script |- | if ( CMD/VAR == CONST ) then CMD2 | If condition matches execute CMD2 |- | inc VAR | Increment variable VAR (a number) |- | rem <any> | Remark for anything |- | set VAR VALUE | Set variable VAR to VALUE |- | wait I | Wait I milliseconds |- |} == [[FS20]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fht send HOUSECODE ADDR CMD [CMD2] | Send FHT command. See [[FS20]] for details. |- | fs20 receive | Receive FS20/FHT sequence and display it. |- | fs20 send HOUSECODE ADDR CMD [CMD2] | Send FS20 command. See [[FS20]] for details. |- | fs20 ws300 | Receive FS20 sequence from WS300 weather station and decode it. |- |} == [[Frequency Counter]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fc %duty [CHANNEL] | "returns last on duty cycle in percent for given channel" |- | fc duty [CHANNEL] | "returns last on duty cycle (0-255) for given channel" |- | fc freq [CHANNEL] | "returns last frequency in Hz for given channel" |- | fc off [CHANNEL] | "switch off frequency counting on given channel" |- | fc on [CHANNEL] | "switch on frequency counting on given channel" |- | fc ticks [CHANNEL] | "returns last frequency in CPU ticks for given channel" |- |} == [[GLCD_Menu]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | glcdmenu key VALUE | Send a keypress to the menu |- | glcdmenu update | Update the menu |- |} == [[GPS]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | nmea get | Get latitude and longitude data |- | nmea satellites | Get satellites |- |} == [[H-Bridge]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | hbridge [action] [enable_l] [enable_r] | Set H-Bridge command |- | hbridge pwm int | Set H-Bridge enable line valueeg. speed |- |} == [[I2C]] (TWI) == {| border='1' | ''Command syntax'' | ''Short description'' |- | bmp085 apress | Get absolute pressure in Pa |- | bmp085 height PRESSNN | Get height in cm, pressure at N0 needed |- | bmp085 pressnn HEIGHT | Get pressure at N0, height in cm needed |- | bmp085 temp | Get temperature in 0.1°C |- | ds1631 convert ADDR VALUE | Initiate temperature conversions (0: stop, 1: convert) |- | ds1631 temp ADDR | Read last converted temperature |- | i2c detect | list detected I2C Chips |- | i2c rbb ADDR | read byte from I2C chip |- | i2c rbd CHIPADDR REGADDR | read byte from register address at I2C chip |- | i2c rwd CHIPADDR REGADDR | read word from register address at I2C chip |- | i2c wbb ADDR HEXVALUE | write byte to I2C chip |- | i2c wbd CHIPADDR REGADDR HEXVALUE | write byte to register address on I2C chip |- | i2c wwd CHIPADDR REGADDR HEXVALUE | write word to register address on I2C chip |- | lm75 ADDR | Get temperature |- | max7311 getDDRw ADDR | Get Direction-Register DDR |- | max7311 getINw ADDR | Get Input-Register IN |- | max7311 getOUTw ADDR | Get Output-Register OUT |- | max7311 pulse ADDR BIT TIME | Toggle Output-BIT for TIME (in ms) |- | max7311 set ADDR BIT VALUE | Set Output-BIT to VALUE (bool) |- | max7311 setDDRw ADDR VALUE | Set Direction-Register DDR (VALUE as hex) |- | max7311 setOUTw ADDR VALUE | Set Output-Register OUT (VALUE as hex) |- | pca9531 ADDR PERIODPWM1 DUTYPWM1 PERIODPWM2 DUTYPWM2 LED0..3 LED4..7 | set PWM1 and PWM2 and LED states |- | pca9685m ADDR | OUTDRV, IVRT, PRESCALE |- | pca9685s ADDR | LED, ON, OFF |- | pcf8574x read ADDR CHIP | Get bits |- | pcf8574x set ADDR CHIP HEXVALUE | Set bits |- | tsl2550 lux | Show light level by reading adc registers and computing level |- | tsl2550 mode VALUE | Set the TSL2550s operating mode (0: standard range, 1: extended range) |- | tsl2550 power VALUE | Set the TSL2550s power state (0: down, 1:up) |- |} == [[Jabber]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | jabber_host [HOSTNAME] | JABBER hostname |- | jabber_pass [PASSWORD] | JABBER password |- | jabber_resrc [RESOURCE] | JABBER resource |- | jabber_user [USERNAME] | JABBER username |- |} == [[KTY]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | kty autocalibrate CHANNEL | Calibrate to 1000 Ohm precision Resistor. |- | kty cal get | Return the calibration difference to 2k2 Resistor. |- | kty get [CHANNEL] | Get the temperature in xxx.x °C of CHANNEL or if no channel set of all channels. |- |} == [[MotorCurtain]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | curtain VALUE | Set value of curtain. 0=closed..7=open. If you use fewer sensors, use the corrent value instead of 7. |- | curtainlast | Return last known position |- | curtainmax | Return maximum position |- | curtainoff | Switch motor off |- |} == [[Named_PIN]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | pin get NAME | Read and display the status of pin NAME. |- | pin list | List all known named-pins. |- | pin set NAME STATUS | Set the status of pin NAME to STATUS. |- | pin toggle NAME | Toggle the status of pin NAME. |- |} == [[PWM]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dtmf CHARS | send CHARS as DTMF |- | freq set FREQUENCY DELAY | Set frequency for DELAY ms |- | pwm fade [channel +-diff startvalue] | Set fading at channel with startvalue and change each stepp to diff (must be signed 3 digit) |- | pwm set [channel value] | Set channel to value |- |} == [[RFM12]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | rfm12 reinit | Re-initialize RFM12 module. |- | rfm12 setbandwidth BW | Set RX bandwidth to BW. |- | rfm12 setbaud BAUD | Set baudrate to BAUD. |- | rfm12 setdrssi DRSSI | Set the drssi to DRSSI. |- | rfm12 setgain GAIN | Set preamplifier gain to GAIN. |- | rfm12 setmod MOD | Set modulation to MOD. |- | rfm12 status | Display internal status. |- |} == [[RFM12_ASK]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | rfm12 1527 | housecodeCommand delay cnt |- | rfm12 2272 | housecodeCommand delay cnt |- | rfm12 ask sense | Trigger (Tevion) ASK sensing. Enable ext. filter pin before! |- | rfm12 external filter [1] | Enable ext. filter pin if argument is present (disable otherwise) |- | rfm12 intertechno | family group device command |- | rfm12 tevion | housecode command delay cnt |- |} == [[RFM12_FS20]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fht send | housecode addr command data |- | fs20 send | housecode addr command data |- |} == [[SD-Karte]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sd dir | List contents of current SD directory. |- | sd mkdir PATH | Create directory hierarchy PATH. |- |} == [[SHT]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sht humid | Return humidity of SHT sensor |- | sht raw | Return raw hex temp (first line) and humidity value (second line) of SHT sensor |- | sht temp | Return temperature of SHT sensor |- |} == [[SMS77]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sms77 MESSAGE | Send MESSAGE to compiled in sms77 service |- | sms77_pass [PASSWORD] | SMS77 password |- | sms77_recv [RECEIVER] | SMS receiver |- | sms77_type [TYPE] | SMS type |- | sms77_user [USERNAME] | SMS77 username |- |} == [[Servo_Ansteuerung|PWM Servo Control]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | pwm servo_dec SERVONR | Decrement position of servo SERVONR |- | pwm servo_inc SERVONR | Increment position of servo SERVONR |- | pwm servo_set SERVONR POSITION | Set servo with SERVONR to POSITION |- |} == [[Sound]]/WAV support == {| border='1' | ''Command syntax'' | ''Short description'' |- | pwm stop | Stop wav |- | pwm wav <FILENAME> | Play wave file. Use VFS if compiled in. More details at [[Sound]] |- |} == [[Stella_Light]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | channel CHANNEL VALUE FUNCTION | Get/Set stella channel to value. Second and third parameters are optional. Function: You may use 's' for instant set, 'f' for fade and 'y' for flashy fade. |- | channels | Return stella channel size |- | fadestep FADESTEP | Get/Set stella fade step |- | stella load | Load values from eeprom |- | stella store | Store values in eeprom |- |} == [[USB]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | keyboard MESSAGE | Send MESSAGE as HID keyboard |- | mouse BUTTON DELTAX DELTAY | Send data as HID mouse |- |} == [[ZACwire]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | zac 306 PORT BIT | Return temperature of TSic 306 at BIT of PORT |- | zac 506 PORT BIT | Return temperature of TSic 506 at BIT of PORT |- | zac raw PORT BIT | Return raw hex temperature value of zacwire at BIT of PORT |- |} == lome6 == {| border='1' | ''Command syntax'' | ''Short description'' |- | lome6 get_t TYPE | get temperature command |- | lome6 power TYPE | press power command |- | lome6 reset | press reset command |- | lome6 set_t TYPE TEMPERATURE | set temperature command |- | lome6 state | get state command |- | lome6 uptime UPTIME | set/get uptime command |- |} == Miscelleanous == {| border='1' | ''Command syntax'' | ''Short description'' |- | alias list | List all available aliases |- | artnet test | artnet test |- | cw send MESSAGE | Send MESSAGE in Morce Code |- | d ADDR | Dump the memory at ADDR (16 bytes). |- | eeprom reinit | Force reinitialization of the EEPROM config area |- | free | Display free space. |- | help | List which commands are available. |- | ht MESSAGE | Send MESSAGE to compiled in httplog service |- | ipstats | Display IP statistics. |- | mb recv | Receive data from modbus |- | moodlight CHANNEL ONOFF | Set CHANNEL moodlight on=1 or off=0. If no channel is given return on if channel CHANNEL is moodlighted |- | motd [MESSAGE] | Save MESSAGE as new message of the day, otherwise just show current message |- | msr1 get | Get data |- | mysql query QUERY | Send specified MySQL query to the configured server |- | ns | update net statistic for public anouncment of currently running ethersex |- | pam USER PASSWORD | Use pam for user and password |- | push NUMBER | Push button identified by NUMBER |- | pwm melody [NUMBER] | Play melody |- | sanyoz700 CMD | Send command to projector |- | sll get | Request the logged data |- | sram memtest | Perform a memory test |- | srf05 | Read SRF05 measurement |- | to1 get | Request data from sensor |- | tw MESSAGE | Send MESSAGE to compiled in twitter service |- | upnp send | Manually send UPnP broadcast packet |- | usart baud BAUD | Set the USART baudrate to BAUD. |- | version | Display the version number. |- | wol MAC | Send WAKE-ON-LAN command to MAC |- | yport stats | Report statistic counters |- | zbus stats | Report statistic counters |- |} [[Category:Ethersex]] [[Category:ECMD]] 638714522a0e66d5350109173d81a4572a552fc0 1733 1732 2016-09-22T20:40:33Z Daniel 725 wikitext text/x-wiki <div class="errorbox"> This page is automatically generated from the files in the Ethersex source code repository. Do not edit this page but send [[patches]] for those files! </div> <br> <br> __NOTOC__ == Analog/Digital Conversion ([[ADC]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | adc get [CHANNEL] | Get the ADC value in hex of CHANNEL or if no channel set of all channels. |- | hr20 temp | Read HR20 temperature sensor. |- |} == DNS Resolver == {| border='1' | ''Command syntax'' | ''Short description'' |- | dns server [IPADDR] | Display/Set the IP address of the DNS server to use to IPADDR. |- | nslookup HOSTNAME | Do DNS lookup for HOSTNAME (call twice). |- |} == Digital/Analog Conversion ([[DAC]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ltc1257_delay `[VALUE] | Set (if VALUE given) or get (no VALUE) delay for LTC1257 output bit changes in µs' |- | ltc1257_set `[VALUE0] [VALUE1] ... | Set output to value (value: 0-4095)' |- | tlc5620 `[CHANNEL] [VALUE] | Set Output to value (Value: 0-0xff)' |- |} == Fnordlicht == {| border='1' | ''Command syntax'' | ''Short description'' |- | fnordlicht "ADDRESS RED | GREEN,BLUE",fnordlicht command to set RGB color |- | fnordlicht_init | fnordlicht init |- |} == HD44780 [[LCD]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | hr20 hourbar START STOP | Update hourbar to show ticks between START and STOP (range 0..23) |- | hr20 toggle SEG | Toggle segment SEG (a number, not a symbolic name!) |- | lcd backlight STATE | switch back light STATE to ON or OFF |- | lcd char N D1 D2 D3 D4 D5 D6 D7 D8 | Define use-definable char N with data D1..D8 (provide DATA in hex) |- | lcd clear [LINE] | Clear line LINE (0..3) or the whole display (if parameter is omitted) |- | lcd goto LINE COL | Move cursor to LINE and column COL (origin is 0/0) |- | lcd reinit CURSOR BLINK | Reinitialize the display, set whether to show the cursor (CURSOR, 0 or 1) and whether the cursor shall BLINK |- | lcd shift DIR | Shift the display to DIR (either ''left'' or ''right'') |- | lcd write TEXT | Write TEXT to the current cursor location |- |} == Infrared Send/Receive ([[IR-TRX]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ir receive | receive an IR command |- | ir send DEVICE COMMAND | send COMMAND to DEVICE |- |} == Infrared Send/Receive ([[IRMP]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | irmp receive | receive an IR command |- | irmp send PROTOCOL DEVICE COMMAND REPEAT | send COMMAND with REPEAT flag to DEVICE using PROTOCOL |- |} == NTP Client == {| border='1' | ''Command syntax'' | ''Short description'' |- | ntp query | Query the NTP server to get an NTP update. |- | ntp server [IPADDR] | Display/Set the IP address of the NTP server to use to IPADDR. |- | ntp status | Display NTP server status |- |} == Network configuration == {| border='1' | ''Command syntax'' | ''Short description'' |- | enc dump | Dump the internal state of the enc to serial |- | gw [IP] | Display/Set the address of the default router. |- | ip [IP] | Display/Set the IP address. |- | mac [xx:xx:xx:xx:xx:xx] | Display/Set the MAC address. |- | netmask [IP] | Display/Set the network mask. |- |} == Port I/O == {| border='1' | ''Command syntax'' | ''Short description'' |- | io get ddr PORTNUM | Display the current value of the DDR PORTNUM. |- | io get mask PORTNUM | Display the mask of the port PORTNUM. |- | io get pin PORTNUM | Display the current value of the PIN-register of the port PORTNUM. |- | io get port NUM | Display the current value of the PORT NUM. |- | io set ddr PORTNUM HEXVALUE [MASK] | Set the DDR of port PORTNUM to VALUE (possibly using the provided MASK). |- | io set port NUM HEXVALUE [MASK] | Set the PORT NUM to VALUE (possibly using the provided MASK). |- |} == Reading and Writing EEPROM Space on Device == {| border='1' | ''Command syntax'' | ''Short description'' |- | eer eer <ADDR> <LENGTH> | Read n bytes from address after the config in eeprom. |- | eew eew <ADDR> <HEXBYTES> | Write Hexbytes at address after the config in epprom. |- | fuse | Display current fuse settings |- | hostname | Display hostname. |- |} == Resetting the controller == {| border='1' | ''Command syntax'' | ''Short description'' |- | bootloader | Call the bootloader. |- | reset | Reset the Ethersex. |- | wdreset | Go into endless loop to trigger a watchdog timeout. |- |} == [[ADS]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | adc get | Get the ADC value in hex. |- | adc mean [COUNT] | Get the mean of power of 2 COUNT ADC values in hex. |- |} == [[Am_Puls_der_Zeit|Clock]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | date | Print the current date. |- | lastdcf | Print when last valid DCF signal was received. |- | time [UNIXTIME] | Display/Set the current time in seconds since January 1st 1970. |- | uptime | Display ethersex uptime in unix format. |- | whm | Display ethersex uptime. |- |} == [[Application_Sample]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sample | Manually call application sample commands |- | sample_init | Manually call application sample init method |- | sample_periodic | Manually call application sample periodic method |- |} == [[Blinkenlights_MCUF|MCUF]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | mcuf modul N | Select module N |- | mcuf modul list | List all modules |- | mcuf showclock | Show digital clock |- | mcuf showstring MESSAGE | Show scrolling MESSAGE on the display |- |} == [[CRC]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | crc calc | "read the ethersex program code and calc a crc16 of it" |- | crc read | "read out the crc16 value at the end of the program space" |- |} == [[CRON-Dienst]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | cron_add MIN HOUR DAY MONTH DOW ECMD | Add ECMD to cron to be executed at given time |- | cron_list | Show all cron entries |- | cron_make_persistent | Mark a Job as persistent |- | cron_rm POSITION | Remove one cron entry |- | cron_save | Saves all persistent jobs |- |} == [[DALI]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dali cmd [TARGET] [COMMAND] [!][?] | "send the given command (decimal) to targets (all, g00 to g15, s00 to s63), auto repeat with !, read reply with ?" |- | dali dim [TARGET] [LEVEL] | "dim targets (all, g00 to g15, s00 to s63) to given level (0-254)" |- | dali raw [BYTE1] [BYTE2] | "send a raw frame (two bytes, given in hex) over the DALI bus" |- | dali scmd [SPECIAL COMMAND] [DATA] [!][?] | "send special command (256-287) with data, auto repeat with !, read reply with ?" |- |} == [[DMX_FXSlot]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx fxslot devices | set the device settings |- | dmx fxslot effect | set the effect settings |- | dmx fxslot reset | reset all fxslots and clear saved ones in EEPROM |- | dmx fxslot restore | restore the settings from EEPROM |- | dmx fxslot save | save the current fxslots to EEPROM |- |} == [[DMX_Storage]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx channels | Get channels per universe |- | dmx get | Return channel value |- | dmx set | Set channel values |- | dmx universe | Get a whole universe |- | dmx universes | Get universes |- |} == [[Dallas_1-wire_Bus]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | 1w convert [DEVICE] | Trigger temperature conversion of either DEVICE or all connected devices |- | 1w ds2450 convert [DEVICE] | `start conversion (with optional input mask and read out control)' |- | 1w ds2450 get [DEVICE] | `get conversion result (one or all channels)' |- | 1w ds2450 oc [DEVICE] | `get/set output control (per channel)' |- | 1w ds2450 oe [DEVICE] | `get/set output enable (per channel)' |- | 1w ds2450 por [DEVICE] | `get/set power on reset (per channel)' |- | 1w ds2450 power [DEVICE] | `get/set power supply of device (global)' |- | 1w ds2450 range [DEVICE] | `get/set input voltage range (per channel)' |- | 1w ds2450 res [DEVICE] | `get/set bit resolution of AD convert (per channel)' |- | 1w get DEVICE | Return temperature value of onewire DEVICE (provide 64-bit ID as 16-hex-digits) |- | 1w list | Return a list of the connected onewire devices |- |} == [[DataFlash]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | df status | Display internal status. |- | fs format | Format the filesystem. |- | fs inspect inode INODE | Inspect INODE (and associated page). |- | fs inspect node NODE | Inspect NODE and dump to serial. |- | fs list | List the directory. |- | fs mkfile NAME | Create a new file NAME. |- | fs remove NAME | Delete the file NAME. |- | fs truncate NAME LEN | Truncate the file NAME to LEN bytes. |- |} == [[Dc3840_camera|DC3840 mobil camera support]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dc3840 capture | Take a picture. Access 'dc3840' via VFS afterwards. See [[DC3840 Camera]] for details. |- | dc3840 light | Light level of camera |- | dc3840 send A B C D E | Send provided command bytes to the camera. |- | dc3840 sync | Re-sync to the camera |- | dc3840 zoom | Enable zoom of camera |- |} == [[ECMDScript]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | call FILENAME | Start script named FILENAME |- | cat FILENAME | cat file content (with debug only) |- | dec VAR | Decrement variable VAR (a number) |- | echo <any> | Print out all arguments of echo |- | exit | Exit currently running script |- | get VAR | Get value of variable VAR |- | goto N | Goto line N in currently running script |- | if ( CMD/VAR == CONST ) then CMD2 | If condition matches execute CMD2 |- | inc VAR | Increment variable VAR (a number) |- | rem <any> | Remark for anything |- | set VAR VALUE | Set variable VAR to VALUE |- | wait I | Wait I milliseconds |- |} == [[FS20]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fht send HOUSECODE ADDR CMD [CMD2] | Send FHT command. See [[FS20]] for details. |- | fs20 receive | Receive FS20/FHT sequence and display it. |- | fs20 send HOUSECODE ADDR CMD [CMD2] | Send FS20 command. See [[FS20]] for details. |- | fs20 ws300 | Receive FS20 sequence from WS300 weather station and decode it. |- |} == [[Frequency Counter]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fc %duty [CHANNEL] | "returns last on duty cycle in percent for given channel" |- | fc duty [CHANNEL] | "returns last on duty cycle (0-255) for given channel" |- | fc freq [CHANNEL] | "returns last frequency in Hz for given channel" |- | fc off [CHANNEL] | "switch off frequency counting on given channel" |- | fc on [CHANNEL] | "switch on frequency counting on given channel" |- | fc ticks [CHANNEL] | "returns last frequency in CPU ticks for given channel" |- |} == [[GLCD_Menu]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | glcdmenu key VALUE | Send a keypress to the menu |- | glcdmenu update | Update the menu |- |} == [[GPS]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | nmea get | Get latitude and longitude data |- | nmea satellites | Get satellites |- |} == [[H-Bridge]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | hbridge [action] [enable_l] [enable_r] | Set H-Bridge command |- | hbridge pwm int | Set H-Bridge enable line valueeg. speed |- |} == [[I2C]] (TWI) == {| border='1' | ''Command syntax'' | ''Short description'' |- | bmp085 apress | Get absolute pressure in Pa |- | bmp085 height PRESSNN | Get height in cm, pressure at N0 needed |- | bmp085 pressnn HEIGHT | Get pressure at N0, height in cm needed |- | bmp085 temp | Get temperature in 0.1°C |- | ds1631 convert ADDR VALUE | Initiate temperature conversions (0: stop, 1: convert) |- | ds1631 temp ADDR | Read last converted temperature |- | i2c detect | list detected I2C Chips |- | i2c rbb ADDR | read byte from I2C chip |- | i2c rbd CHIPADDR REGADDR | read byte from register address at I2C chip |- | i2c rwd CHIPADDR REGADDR | read word from register address at I2C chip |- | i2c wbb ADDR HEXVALUE | write byte to I2C chip |- | i2c wbd CHIPADDR REGADDR HEXVALUE | write byte to register address on I2C chip |- | i2c wwd CHIPADDR REGADDR HEXVALUE | write word to register address on I2C chip |- | lm75 ADDR | Get temperature |- | max7311 getDDRw ADDR | Get Direction-Register DDR |- | max7311 getINw ADDR | Get Input-Register IN |- | max7311 getOUTw ADDR | Get Output-Register OUT |- | max7311 pulse ADDR BIT TIME | Toggle Output-BIT for TIME (in ms) |- | max7311 set ADDR BIT VALUE | Set Output-BIT to VALUE (bool) |- | max7311 setDDRw ADDR VALUE | Set Direction-Register DDR (VALUE as hex) |- | max7311 setOUTw ADDR VALUE | Set Output-Register OUT (VALUE as hex) |- | pca9531 ADDR PERIODPWM1 DUTYPWM1 PERIODPWM2 DUTYPWM2 LED0..3 LED4..7 | set PWM1 and PWM2 and LED states |- | pca9685m ADDR | OUTDRV, IVRT, PRESCALE |- | pca9685s ADDR | LED, ON, OFF |- | pcf8574x read ADDR CHIP | Get bits |- | pcf8574x set ADDR CHIP HEXVALUE | Set bits |- | tsl2550 lux | Show light level by reading adc registers and computing level |- | tsl2550 mode VALUE | Set the TSL2550s operating mode (0: standard range, 1: extended range) |- | tsl2550 power VALUE | Set the TSL2550s power state (0: down, 1:up) |- |} == [[Jabber]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | jabber_host [HOSTNAME] | JABBER hostname |- | jabber_pass [PASSWORD] | JABBER password |- | jabber_resrc [RESOURCE] | JABBER resource |- | jabber_user [USERNAME] | JABBER username |- |} == [[KTY]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | kty autocalibrate CHANNEL | Calibrate to 1000 Ohm precision Resistor. |- | kty cal get | Return the calibration difference to 2k2 Resistor. |- | kty get [CHANNEL] | Get the temperature in xxx.x °C of CHANNEL or if no channel set of all channels. |- |} == [[MotorCurtain]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | curtain VALUE | Set value of curtain. 0=closed..7=open. If you use fewer sensors, use the corrent value instead of 7. |- | curtainlast | Return last known position |- | curtainmax | Return maximum position |- | curtainoff | Switch motor off |- |} == [[Named_PIN]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | pin get NAME | Read and display the status of pin NAME. |- | pin list | List all known named-pins. |- | pin set NAME STATUS | Set the status of pin NAME to STATUS. |- | pin toggle NAME | Toggle the status of pin NAME. |- |} == [[PWM]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dtmf CHARS | send CHARS as DTMF |- | freq set FREQUENCY DELAY | Set frequency for DELAY ms |- | pwm fade [channel +-diff startvalue] | Set fading at channel with startvalue and change each stepp to diff (must be signed 3 digit) |- | pwm set [channel value] | Set channel to value |- |} == [[RFM12]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | rfm12 reinit | Re-initialize RFM12 module. |- | rfm12 setbandwidth BW | Set RX bandwidth to BW. |- | rfm12 setbaud BAUD | Set baudrate to BAUD. |- | rfm12 setdrssi DRSSI | Set the drssi to DRSSI. |- | rfm12 setgain GAIN | Set preamplifier gain to GAIN. |- | rfm12 setmod MOD | Set modulation to MOD. |- | rfm12 status | Display internal status. |- |} == [[RFM12_ASK]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | rfm12 1527 | housecodeCommand delay cnt |- | rfm12 2272 | housecodeCommand delay cnt |- | rfm12 ask sense | Trigger (Tevion) ASK sensing. Enable ext. filter pin before! |- | rfm12 external filter [1] | Enable ext. filter pin if argument is present (disable otherwise) |- | rfm12 intertechno | family group device command |- | rfm12 tevion | housecode command delay cnt |- |} == [[RFM12_FS20]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fht send | housecode addr command data |- | fs20 send | housecode addr command data |- |} == [[SD-Karte]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sd dir | List contents of current SD directory. |- | sd mkdir PATH | Create directory hierarchy PATH. |- |} == [[SHT]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sht humid | Return humidity of SHT sensor |- | sht raw | Return raw hex temp (first line) and humidity value (second line) of SHT sensor |- | sht temp | Return temperature of SHT sensor |- |} == [[SMS77]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sms77 MESSAGE | Send MESSAGE to compiled in sms77 service |- | sms77_pass [PASSWORD] | SMS77 password |- | sms77_recv [RECEIVER] | SMS receiver |- | sms77_type [TYPE] | SMS type |- | sms77_user [USERNAME] | SMS77 username |- |} == [[Servo_Ansteuerung|PWM Servo Control]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | pwm servo_dec SERVONR | Decrement position of servo SERVONR |- | pwm servo_inc SERVONR | Increment position of servo SERVONR |- | pwm servo_set SERVONR POSITION | Set servo with SERVONR to POSITION |- |} == [[Sound]]/WAV support == {| border='1' | ''Command syntax'' | ''Short description'' |- | pwm stop | Stop wav |- | pwm wav <FILENAME> | Play wave file. Use VFS if compiled in. More details at [[Sound]] |- |} == [[Stella_Light]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | channel CHANNEL VALUE FUNCTION | Get/Set stella channel to value. Second and third parameters are optional. Function: You may use 's' for instant set, 'f' for fade and 'y' for flashy fade. |- | channels | Return stella channel size |- | fadestep FADESTEP | Get/Set stella fade step |- | stella load | Load values from eeprom |- | stella store | Store values in eeprom |- |} == [[USB]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | keyboard MESSAGE | Send MESSAGE as HID keyboard |- | mouse BUTTON DELTAX DELTAY | Send data as HID mouse |- |} == [[ZACwire]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | zac 306 PORT BIT | Return temperature of TSic 306 at BIT of PORT |- | zac 506 PORT BIT | Return temperature of TSic 506 at BIT of PORT |- | zac raw PORT BIT | Return raw hex temperature value of zacwire at BIT of PORT |- |} == lome6 == {| border='1' | ''Command syntax'' | ''Short description'' |- | lome6 get_t TYPE | get temperature command |- | lome6 power TYPE | press power command |- | lome6 reset | press reset command |- | lome6 set_t TYPE TEMPERATURE | set temperature command |- | lome6 state | get state command |- | lome6 uptime UPTIME | set/get uptime command |- |} == Miscelleanous == {| border='1' | ''Command syntax'' | ''Short description'' |- | alias list | List all available aliases |- | artnet test | artnet test |- | cw send MESSAGE | Send MESSAGE in Morce Code |- | d ADDR | Dump the memory at ADDR (16 bytes). |- | eeprom reinit | Force reinitialization of the EEPROM config area |- | free | Display free space. |- | help | List which commands are available. |- | ht MESSAGE | Send MESSAGE to compiled in httplog service |- | ipstats | Display IP statistics. |- | mb recv | Receive data from modbus |- | moodlight CHANNEL ONOFF | Set CHANNEL moodlight on=1 or off=0. If no channel is given return on if channel CHANNEL is moodlighted |- | motd [MESSAGE] | Save MESSAGE as new message of the day, otherwise just show current message |- | msr1 get | Get data |- | mysql query QUERY | Send specified MySQL query to the configured server |- | ns | update net statistic for public anouncment of currently running ethersex |- | pam USER PASSWORD | Use pam for user and password |- | push NUMBER | Push button identified by NUMBER |- | pwm melody [NUMBER] | Play melody |- | sanyoz700 CMD | Send command to projector |- | sll get | Request the logged data |- | sram memtest | Perform a memory test |- | srf05 | Read SRF05 measurement |- | to1 get | Request data from sensor |- | tw MESSAGE | Send MESSAGE to compiled in twitter service |- | upnp send | Manually send UPnP broadcast packet |- | usart baud BAUD | Set the USART baudrate to BAUD. |- | version | Display the version number. |- | wol MAC | Send WAKE-ON-LAN command to MAC |- | yport stats | Report statistic counters |- | zbus stats | Report statistic counters |- |} [[Category:Ethersex]] [[Category:ECMD]] ec2e5c0a7acb5fca68f5b12a127a0681e3023b95 1734 1733 2016-09-22T20:40:58Z Daniel 725 wikitext text/x-wiki <div class="errorbox"> This page is automatically generated from the files in the Ethersex source code repository. Do not edit this page but send [[patches]] for those files! </div> <br> <br> __NOTOC__ <br> <br> == Analog/Digital Conversion ([[ADC]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | adc get [CHANNEL] | Get the ADC value in hex of CHANNEL or if no channel set of all channels. |- | hr20 temp | Read HR20 temperature sensor. |- |} == DNS Resolver == {| border='1' | ''Command syntax'' | ''Short description'' |- | dns server [IPADDR] | Display/Set the IP address of the DNS server to use to IPADDR. |- | nslookup HOSTNAME | Do DNS lookup for HOSTNAME (call twice). |- |} == Digital/Analog Conversion ([[DAC]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ltc1257_delay `[VALUE] | Set (if VALUE given) or get (no VALUE) delay for LTC1257 output bit changes in µs' |- | ltc1257_set `[VALUE0] [VALUE1] ... | Set output to value (value: 0-4095)' |- | tlc5620 `[CHANNEL] [VALUE] | Set Output to value (Value: 0-0xff)' |- |} == Fnordlicht == {| border='1' | ''Command syntax'' | ''Short description'' |- | fnordlicht "ADDRESS RED | GREEN,BLUE",fnordlicht command to set RGB color |- | fnordlicht_init | fnordlicht init |- |} == HD44780 [[LCD]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | hr20 hourbar START STOP | Update hourbar to show ticks between START and STOP (range 0..23) |- | hr20 toggle SEG | Toggle segment SEG (a number, not a symbolic name!) |- | lcd backlight STATE | switch back light STATE to ON or OFF |- | lcd char N D1 D2 D3 D4 D5 D6 D7 D8 | Define use-definable char N with data D1..D8 (provide DATA in hex) |- | lcd clear [LINE] | Clear line LINE (0..3) or the whole display (if parameter is omitted) |- | lcd goto LINE COL | Move cursor to LINE and column COL (origin is 0/0) |- | lcd reinit CURSOR BLINK | Reinitialize the display, set whether to show the cursor (CURSOR, 0 or 1) and whether the cursor shall BLINK |- | lcd shift DIR | Shift the display to DIR (either ''left'' or ''right'') |- | lcd write TEXT | Write TEXT to the current cursor location |- |} == Infrared Send/Receive ([[IR-TRX]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ir receive | receive an IR command |- | ir send DEVICE COMMAND | send COMMAND to DEVICE |- |} == Infrared Send/Receive ([[IRMP]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | irmp receive | receive an IR command |- | irmp send PROTOCOL DEVICE COMMAND REPEAT | send COMMAND with REPEAT flag to DEVICE using PROTOCOL |- |} == NTP Client == {| border='1' | ''Command syntax'' | ''Short description'' |- | ntp query | Query the NTP server to get an NTP update. |- | ntp server [IPADDR] | Display/Set the IP address of the NTP server to use to IPADDR. |- | ntp status | Display NTP server status |- |} == Network configuration == {| border='1' | ''Command syntax'' | ''Short description'' |- | enc dump | Dump the internal state of the enc to serial |- | gw [IP] | Display/Set the address of the default router. |- | ip [IP] | Display/Set the IP address. |- | mac [xx:xx:xx:xx:xx:xx] | Display/Set the MAC address. |- | netmask [IP] | Display/Set the network mask. |- |} == Port I/O == {| border='1' | ''Command syntax'' | ''Short description'' |- | io get ddr PORTNUM | Display the current value of the DDR PORTNUM. |- | io get mask PORTNUM | Display the mask of the port PORTNUM. |- | io get pin PORTNUM | Display the current value of the PIN-register of the port PORTNUM. |- | io get port NUM | Display the current value of the PORT NUM. |- | io set ddr PORTNUM HEXVALUE [MASK] | Set the DDR of port PORTNUM to VALUE (possibly using the provided MASK). |- | io set port NUM HEXVALUE [MASK] | Set the PORT NUM to VALUE (possibly using the provided MASK). |- |} == Reading and Writing EEPROM Space on Device == {| border='1' | ''Command syntax'' | ''Short description'' |- | eer eer <ADDR> <LENGTH> | Read n bytes from address after the config in eeprom. |- | eew eew <ADDR> <HEXBYTES> | Write Hexbytes at address after the config in epprom. |- | fuse | Display current fuse settings |- | hostname | Display hostname. |- |} == Resetting the controller == {| border='1' | ''Command syntax'' | ''Short description'' |- | bootloader | Call the bootloader. |- | reset | Reset the Ethersex. |- | wdreset | Go into endless loop to trigger a watchdog timeout. |- |} == [[ADS]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | adc get | Get the ADC value in hex. |- | adc mean [COUNT] | Get the mean of power of 2 COUNT ADC values in hex. |- |} == [[Am_Puls_der_Zeit|Clock]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | date | Print the current date. |- | lastdcf | Print when last valid DCF signal was received. |- | time [UNIXTIME] | Display/Set the current time in seconds since January 1st 1970. |- | uptime | Display ethersex uptime in unix format. |- | whm | Display ethersex uptime. |- |} == [[Application_Sample]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sample | Manually call application sample commands |- | sample_init | Manually call application sample init method |- | sample_periodic | Manually call application sample periodic method |- |} == [[Blinkenlights_MCUF|MCUF]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | mcuf modul N | Select module N |- | mcuf modul list | List all modules |- | mcuf showclock | Show digital clock |- | mcuf showstring MESSAGE | Show scrolling MESSAGE on the display |- |} == [[CRC]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | crc calc | "read the ethersex program code and calc a crc16 of it" |- | crc read | "read out the crc16 value at the end of the program space" |- |} == [[CRON-Dienst]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | cron_add MIN HOUR DAY MONTH DOW ECMD | Add ECMD to cron to be executed at given time |- | cron_list | Show all cron entries |- | cron_make_persistent | Mark a Job as persistent |- | cron_rm POSITION | Remove one cron entry |- | cron_save | Saves all persistent jobs |- |} == [[DALI]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dali cmd [TARGET] [COMMAND] [!][?] | "send the given command (decimal) to targets (all, g00 to g15, s00 to s63), auto repeat with !, read reply with ?" |- | dali dim [TARGET] [LEVEL] | "dim targets (all, g00 to g15, s00 to s63) to given level (0-254)" |- | dali raw [BYTE1] [BYTE2] | "send a raw frame (two bytes, given in hex) over the DALI bus" |- | dali scmd [SPECIAL COMMAND] [DATA] [!][?] | "send special command (256-287) with data, auto repeat with !, read reply with ?" |- |} == [[DMX_FXSlot]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx fxslot devices | set the device settings |- | dmx fxslot effect | set the effect settings |- | dmx fxslot reset | reset all fxslots and clear saved ones in EEPROM |- | dmx fxslot restore | restore the settings from EEPROM |- | dmx fxslot save | save the current fxslots to EEPROM |- |} == [[DMX_Storage]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx channels | Get channels per universe |- | dmx get | Return channel value |- | dmx set | Set channel values |- | dmx universe | Get a whole universe |- | dmx universes | Get universes |- |} == [[Dallas_1-wire_Bus]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | 1w convert [DEVICE] | Trigger temperature conversion of either DEVICE or all connected devices |- | 1w ds2450 convert [DEVICE] | `start conversion (with optional input mask and read out control)' |- | 1w ds2450 get [DEVICE] | `get conversion result (one or all channels)' |- | 1w ds2450 oc [DEVICE] | `get/set output control (per channel)' |- | 1w ds2450 oe [DEVICE] | `get/set output enable (per channel)' |- | 1w ds2450 por [DEVICE] | `get/set power on reset (per channel)' |- | 1w ds2450 power [DEVICE] | `get/set power supply of device (global)' |- | 1w ds2450 range [DEVICE] | `get/set input voltage range (per channel)' |- | 1w ds2450 res [DEVICE] | `get/set bit resolution of AD convert (per channel)' |- | 1w get DEVICE | Return temperature value of onewire DEVICE (provide 64-bit ID as 16-hex-digits) |- | 1w list | Return a list of the connected onewire devices |- |} == [[DataFlash]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | df status | Display internal status. |- | fs format | Format the filesystem. |- | fs inspect inode INODE | Inspect INODE (and associated page). |- | fs inspect node NODE | Inspect NODE and dump to serial. |- | fs list | List the directory. |- | fs mkfile NAME | Create a new file NAME. |- | fs remove NAME | Delete the file NAME. |- | fs truncate NAME LEN | Truncate the file NAME to LEN bytes. |- |} == [[Dc3840_camera|DC3840 mobil camera support]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dc3840 capture | Take a picture. Access 'dc3840' via VFS afterwards. See [[DC3840 Camera]] for details. |- | dc3840 light | Light level of camera |- | dc3840 send A B C D E | Send provided command bytes to the camera. |- | dc3840 sync | Re-sync to the camera |- | dc3840 zoom | Enable zoom of camera |- |} == [[ECMDScript]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | call FILENAME | Start script named FILENAME |- | cat FILENAME | cat file content (with debug only) |- | dec VAR | Decrement variable VAR (a number) |- | echo <any> | Print out all arguments of echo |- | exit | Exit currently running script |- | get VAR | Get value of variable VAR |- | goto N | Goto line N in currently running script |- | if ( CMD/VAR == CONST ) then CMD2 | If condition matches execute CMD2 |- | inc VAR | Increment variable VAR (a number) |- | rem <any> | Remark for anything |- | set VAR VALUE | Set variable VAR to VALUE |- | wait I | Wait I milliseconds |- |} == [[FS20]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fht send HOUSECODE ADDR CMD [CMD2] | Send FHT command. See [[FS20]] for details. |- | fs20 receive | Receive FS20/FHT sequence and display it. |- | fs20 send HOUSECODE ADDR CMD [CMD2] | Send FS20 command. See [[FS20]] for details. |- | fs20 ws300 | Receive FS20 sequence from WS300 weather station and decode it. |- |} == [[Frequency Counter]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fc %duty [CHANNEL] | "returns last on duty cycle in percent for given channel" |- | fc duty [CHANNEL] | "returns last on duty cycle (0-255) for given channel" |- | fc freq [CHANNEL] | "returns last frequency in Hz for given channel" |- | fc off [CHANNEL] | "switch off frequency counting on given channel" |- | fc on [CHANNEL] | "switch on frequency counting on given channel" |- | fc ticks [CHANNEL] | "returns last frequency in CPU ticks for given channel" |- |} == [[GLCD_Menu]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | glcdmenu key VALUE | Send a keypress to the menu |- | glcdmenu update | Update the menu |- |} == [[GPS]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | nmea get | Get latitude and longitude data |- | nmea satellites | Get satellites |- |} == [[H-Bridge]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | hbridge [action] [enable_l] [enable_r] | Set H-Bridge command |- | hbridge pwm int | Set H-Bridge enable line valueeg. speed |- |} == [[I2C]] (TWI) == {| border='1' | ''Command syntax'' | ''Short description'' |- | bmp085 apress | Get absolute pressure in Pa |- | bmp085 height PRESSNN | Get height in cm, pressure at N0 needed |- | bmp085 pressnn HEIGHT | Get pressure at N0, height in cm needed |- | bmp085 temp | Get temperature in 0.1°C |- | ds1631 convert ADDR VALUE | Initiate temperature conversions (0: stop, 1: convert) |- | ds1631 temp ADDR | Read last converted temperature |- | i2c detect | list detected I2C Chips |- | i2c rbb ADDR | read byte from I2C chip |- | i2c rbd CHIPADDR REGADDR | read byte from register address at I2C chip |- | i2c rwd CHIPADDR REGADDR | read word from register address at I2C chip |- | i2c wbb ADDR HEXVALUE | write byte to I2C chip |- | i2c wbd CHIPADDR REGADDR HEXVALUE | write byte to register address on I2C chip |- | i2c wwd CHIPADDR REGADDR HEXVALUE | write word to register address on I2C chip |- | lm75 ADDR | Get temperature |- | max7311 getDDRw ADDR | Get Direction-Register DDR |- | max7311 getINw ADDR | Get Input-Register IN |- | max7311 getOUTw ADDR | Get Output-Register OUT |- | max7311 pulse ADDR BIT TIME | Toggle Output-BIT for TIME (in ms) |- | max7311 set ADDR BIT VALUE | Set Output-BIT to VALUE (bool) |- | max7311 setDDRw ADDR VALUE | Set Direction-Register DDR (VALUE as hex) |- | max7311 setOUTw ADDR VALUE | Set Output-Register OUT (VALUE as hex) |- | pca9531 ADDR PERIODPWM1 DUTYPWM1 PERIODPWM2 DUTYPWM2 LED0..3 LED4..7 | set PWM1 and PWM2 and LED states |- | pca9685m ADDR | OUTDRV, IVRT, PRESCALE |- | pca9685s ADDR | LED, ON, OFF |- | pcf8574x read ADDR CHIP | Get bits |- | pcf8574x set ADDR CHIP HEXVALUE | Set bits |- | tsl2550 lux | Show light level by reading adc registers and computing level |- | tsl2550 mode VALUE | Set the TSL2550s operating mode (0: standard range, 1: extended range) |- | tsl2550 power VALUE | Set the TSL2550s power state (0: down, 1:up) |- |} == [[Jabber]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | jabber_host [HOSTNAME] | JABBER hostname |- | jabber_pass [PASSWORD] | JABBER password |- | jabber_resrc [RESOURCE] | JABBER resource |- | jabber_user [USERNAME] | JABBER username |- |} == [[KTY]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | kty autocalibrate CHANNEL | Calibrate to 1000 Ohm precision Resistor. |- | kty cal get | Return the calibration difference to 2k2 Resistor. |- | kty get [CHANNEL] | Get the temperature in xxx.x °C of CHANNEL or if no channel set of all channels. |- |} == [[MotorCurtain]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | curtain VALUE | Set value of curtain. 0=closed..7=open. If you use fewer sensors, use the corrent value instead of 7. |- | curtainlast | Return last known position |- | curtainmax | Return maximum position |- | curtainoff | Switch motor off |- |} == [[Named_PIN]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | pin get NAME | Read and display the status of pin NAME. |- | pin list | List all known named-pins. |- | pin set NAME STATUS | Set the status of pin NAME to STATUS. |- | pin toggle NAME | Toggle the status of pin NAME. |- |} == [[PWM]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dtmf CHARS | send CHARS as DTMF |- | freq set FREQUENCY DELAY | Set frequency for DELAY ms |- | pwm fade [channel +-diff startvalue] | Set fading at channel with startvalue and change each stepp to diff (must be signed 3 digit) |- | pwm set [channel value] | Set channel to value |- |} == [[RFM12]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | rfm12 reinit | Re-initialize RFM12 module. |- | rfm12 setbandwidth BW | Set RX bandwidth to BW. |- | rfm12 setbaud BAUD | Set baudrate to BAUD. |- | rfm12 setdrssi DRSSI | Set the drssi to DRSSI. |- | rfm12 setgain GAIN | Set preamplifier gain to GAIN. |- | rfm12 setmod MOD | Set modulation to MOD. |- | rfm12 status | Display internal status. |- |} == [[RFM12_ASK]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | rfm12 1527 | housecodeCommand delay cnt |- | rfm12 2272 | housecodeCommand delay cnt |- | rfm12 ask sense | Trigger (Tevion) ASK sensing. Enable ext. filter pin before! |- | rfm12 external filter [1] | Enable ext. filter pin if argument is present (disable otherwise) |- | rfm12 intertechno | family group device command |- | rfm12 tevion | housecode command delay cnt |- |} == [[RFM12_FS20]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fht send | housecode addr command data |- | fs20 send | housecode addr command data |- |} == [[SD-Karte]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sd dir | List contents of current SD directory. |- | sd mkdir PATH | Create directory hierarchy PATH. |- |} == [[SHT]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sht humid | Return humidity of SHT sensor |- | sht raw | Return raw hex temp (first line) and humidity value (second line) of SHT sensor |- | sht temp | Return temperature of SHT sensor |- |} == [[SMS77]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sms77 MESSAGE | Send MESSAGE to compiled in sms77 service |- | sms77_pass [PASSWORD] | SMS77 password |- | sms77_recv [RECEIVER] | SMS receiver |- | sms77_type [TYPE] | SMS type |- | sms77_user [USERNAME] | SMS77 username |- |} == [[Servo_Ansteuerung|PWM Servo Control]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | pwm servo_dec SERVONR | Decrement position of servo SERVONR |- | pwm servo_inc SERVONR | Increment position of servo SERVONR |- | pwm servo_set SERVONR POSITION | Set servo with SERVONR to POSITION |- |} == [[Sound]]/WAV support == {| border='1' | ''Command syntax'' | ''Short description'' |- | pwm stop | Stop wav |- | pwm wav <FILENAME> | Play wave file. Use VFS if compiled in. More details at [[Sound]] |- |} == [[Stella_Light]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | channel CHANNEL VALUE FUNCTION | Get/Set stella channel to value. Second and third parameters are optional. Function: You may use 's' for instant set, 'f' for fade and 'y' for flashy fade. |- | channels | Return stella channel size |- | fadestep FADESTEP | Get/Set stella fade step |- | stella load | Load values from eeprom |- | stella store | Store values in eeprom |- |} == [[USB]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | keyboard MESSAGE | Send MESSAGE as HID keyboard |- | mouse BUTTON DELTAX DELTAY | Send data as HID mouse |- |} == [[ZACwire]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | zac 306 PORT BIT | Return temperature of TSic 306 at BIT of PORT |- | zac 506 PORT BIT | Return temperature of TSic 506 at BIT of PORT |- | zac raw PORT BIT | Return raw hex temperature value of zacwire at BIT of PORT |- |} == lome6 == {| border='1' | ''Command syntax'' | ''Short description'' |- | lome6 get_t TYPE | get temperature command |- | lome6 power TYPE | press power command |- | lome6 reset | press reset command |- | lome6 set_t TYPE TEMPERATURE | set temperature command |- | lome6 state | get state command |- | lome6 uptime UPTIME | set/get uptime command |- |} == Miscelleanous == {| border='1' | ''Command syntax'' | ''Short description'' |- | alias list | List all available aliases |- | artnet test | artnet test |- | cw send MESSAGE | Send MESSAGE in Morce Code |- | d ADDR | Dump the memory at ADDR (16 bytes). |- | eeprom reinit | Force reinitialization of the EEPROM config area |- | free | Display free space. |- | help | List which commands are available. |- | ht MESSAGE | Send MESSAGE to compiled in httplog service |- | ipstats | Display IP statistics. |- | mb recv | Receive data from modbus |- | moodlight CHANNEL ONOFF | Set CHANNEL moodlight on=1 or off=0. If no channel is given return on if channel CHANNEL is moodlighted |- | motd [MESSAGE] | Save MESSAGE as new message of the day, otherwise just show current message |- | msr1 get | Get data |- | mysql query QUERY | Send specified MySQL query to the configured server |- | ns | update net statistic for public anouncment of currently running ethersex |- | pam USER PASSWORD | Use pam for user and password |- | push NUMBER | Push button identified by NUMBER |- | pwm melody [NUMBER] | Play melody |- | sanyoz700 CMD | Send command to projector |- | sll get | Request the logged data |- | sram memtest | Perform a memory test |- | srf05 | Read SRF05 measurement |- | to1 get | Request data from sensor |- | tw MESSAGE | Send MESSAGE to compiled in twitter service |- | upnp send | Manually send UPnP broadcast packet |- | usart baud BAUD | Set the USART baudrate to BAUD. |- | version | Display the version number. |- | wol MAC | Send WAKE-ON-LAN command to MAC |- | yport stats | Report statistic counters |- | zbus stats | Report statistic counters |- |} [[Category:Ethersex]] [[Category:ECMD]] 390f78470ce3192f8e2f0f76d2c091c6c688de47 1735 1734 2016-10-14T19:00:02Z Michaelb 718 Seite komplett regeneriert. wikitext text/x-wiki <div class="errorbox"> This page is automatically generated from the files in the Ethersex source code repository. Do not edit this page but send [[patches]] for those files! </div> __NOTOC__ == DNS Resolver == {| border='1' | ''Command syntax'' | ''Short description'' |- | dns server [IPADDR] | Display/Set the IP address of the DNS server to use to IPADDR. |- | nslookup HOSTNAME | Do DNS lookup for HOSTNAME (call twice). |- |} == Digital/Analog Conversion ([[DAC]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ltc1257_delay `[VALUE] | Set (if VALUE given) or get (no VALUE) delay for LTC1257 output bit changes in µs' |- | ltc1257_set `[VALUE0] [VALUE1] ... | Set output to value (value: 0-4095)' |- | tlc5620 `[CHANNEL] [VALUE] | Set Output to value (Value: 0-0xff)' |- |} == Fnordlicht == {| border='1' | ''Command syntax'' | ''Short description'' |- | fnordlicht "ADDRESS RED | GREEN,BLUE",fnordlicht command to set RGB color |- | fnordlicht_init | fnordlicht init |- |} == HD44780 [[LCD]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | hr20 hourbar START STOP | Update hourbar to show ticks between START and STOP (range 0..23) |- | hr20 toggle SEG | Toggle segment SEG (a number, not a symbolic name!) |- | lcd backlight [STATE] | get or set the state of the lcd backlight |- | lcd char N D1 D2 D3 D4 D5 D6 D7 D8 | Define use-definable char N with data D1..D8 (provide DATA in hex) |- | lcd clear [LINE] | Clear line LINE (0..3) or the whole display (if parameter is omitted) |- | lcd goto LINE COL | Move cursor to LINE and column COL (origin is 0/0) |- | lcd reinit CURSOR BLINK | Reinitialize the display, set whether to show the cursor (CURSOR, 0 or 1) and whether the cursor shall BLINK |- | lcd shift DIR | Shift the display to DIR (either ''left'' or ''right'') |- | lcd write TEXT | Write TEXT to the current cursor location |- |} == Infrared Send/Receive ([[IRMP]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | irmp receive | receive an IR command |- | irmp send PROTOCOL DEVICE COMMAND REPEAT | send COMMAND with REPEAT flag to DEVICE using PROTOCOL |- |} == Infrared Send/Receive ([[RC5]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ir receive | receive an IR command |- | ir send DEVICE COMMAND | send COMMAND to DEVICE |- |} == Miscellaneous == {| border='1' | ''Command syntax'' | ''Short description'' |- | periodic adjust OFFSET | Adjust periodic timers TOP value by adding OFFSET ticks. |- | periodic reset | Reset debug statistics for periodic module. |- | periodic stats | Print debug statistics for periodic module. |- |} == NTP Client == {| border='1' | ''Command syntax'' | ''Short description'' |- | ntp query | Query the NTP server to get an NTP update. |- | ntp server [IPADDR] | Display/Set the IP address of the NTP server to use to IPADDR. |- | ntp status | Display NTP server status |- |} == Network configuration == {| border='1' | ''Command syntax'' | ''Short description'' |- | enc dump | Dump the internal state of the enc to serial |- | gw [IP] | Display/Set the address of the default router. |- | ip [IP] | Display/Set the IP address. |- | mac [xx:xx:xx:xx:xx:xx] | Display/Set the MAC address. |- | netmask [IP] | Display/Set the network mask. |- |} == Port I/O == {| border='1' | ''Command syntax'' | ''Short description'' |- | io get ddr PORTNUM | Display the current value of the DDR PORTNUM. |- | io get mask PORTNUM | Display the mask of the port PORTNUM. |- | io get pin PORTNUM | Display the current value of the PIN-register of the port PORTNUM. |- | io get port NUM | Display the current value of the PORT NUM. |- | io set ddr PORTNUM HEXVALUE [MASK] | Set the DDR of port PORTNUM to VALUE (possibly using the provided MASK). |- | io set port NUM HEXVALUE [MASK] | Set the PORT NUM to VALUE (possibly using the provided MASK). |- |} == Reading and Writing EEPROM Space on Device == {| border='1' | ''Command syntax'' | ''Short description'' |- | eer eer <ADDR> <LENGTH> | Read n bytes from address after the config in eeprom. |- | eew eew <ADDR> <HEXBYTES> | Write Hexbytes at address after the config in epprom. |- | hostname | Display hostname. |- |} == Resetting the controller == {| border='1' | ''Command syntax'' | ''Short description'' |- | bootloader | Call the bootloader. |- | reset | Reset the Ethersex. |- | wdreset | Go into endless loop to trigger a watchdog timeout. |- |} == [[ADS]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | ads get | Get the ADC value in hex. |- | ads mean [COUNT] | Get the mean of power of 2 COUNT ADC values in hex. |- | fuse | Display current fuse settings |- |} == [[ASK]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | ask 1527 HOUSECODE COMMAND DELAY CNT | |- | ask 2272 HOUSECODE COMMAND [DELAY] [CNT] [SYNC] | |- | ask fa20rf DEVICE [REPEAT] | |- | ask intertechno FAMILY GROUP DEVICE COMMAND | "Send Command to Intertechno switches (with coding wheel). FAMILY: A=1, ..." |- | ask itsl HOUSECODE COMMAND BUTTON [DIM] | "Send Command to Intertechno Self learning switches and dimmers. DIM works only with dimmers and values 0-15." |- | ask oase FAMILY GROUP DEVICE COMMAND | |- | ask tevion HOUSECODE COMMAND DELAY CNT | |- |} == [[Am_Puls_der_Zeit|Clock]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | date | Print the current date. |- | lastdcf | Print when last valid DCF signal was received. |- | time [UNIXTIME] | Display/Set the current time in seconds since January 1st 1970. |- | uptime | Display ethersex uptime in unix format. |- | whm | Display ethersex uptime. |- |} == [[Application_Sample]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sample | Manually call application sample commands |- | sample_init | Manually call application sample init method |- | sample_periodic | Manually call application sample periodic method |- |} == [[BSBPORT]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | bsbport get P1 P2 P3 P4 SRC TYPE | Show specific message currently in buffer format value as TYPE type is one of RAW STA TMP FP1 FP5 |- | bsbport list | List all messages currently in buffer output in RAW TMP FP1 FP5 |- | bsbport query P1 P2 P3 P4 [DEST] | Send Message to query for a value DEST is optional defaults to 0 |- | bsbport set P1 P2 P3 P4 DEST TYPE VALUE | Send Message to set value type is one of RAW SEL TMP FP1 FP5 |- | bsbport stats | Report statistic counters OK/CRC/Lenght under/Lenght over/Droped/Buffer/BufferNet/Retransmit |- |} == [[Blinkenlights_MCUF|MCUF]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | mcuf modul N | Select module N |- | mcuf modul list | List all modules |- | mcuf showclock | Show digital clock |- | mcuf showstring MESSAGE | Show scrolling MESSAGE on the display |- |} == [[CRC]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | adc get [CHANNEL] | Get the ADC value in hex of CHANNEL or if no channel set of all channels. |- | adc vget [CHANNEL] | Get the ADC value in volt of CHANNEL or if no channel set of all channels. |- | adc vref [VOLTAGE] | Get/Set ADC reference voltage calibration. |- | crc calc | "read the ethersex program code and calc a crc16 of it" |- | crc read | "read out the crc16 value at the end of the program space" |- | hr20 temp | Read HR20 temperature sensor. |- |} == [[CRON-Dienst]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | cron add MIN HOUR DAY MONTH DOW ECMD | Add ECMD to cron to be executed at given time |- | cron anacron POSITION [STATE] | show/set job anacron state |- | cron list | Show all cron entries |- | cron persistent POSITION [STATE] | show/set job persistance state |- | cron rm [POSITION] | Remove one cron entry |- | cron save | Saves all persistent jobs |- | cron utc POSITION [STATE] | show/set utc state |- |} == [[DALI]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dali cmd [TARGET] [COMMAND] [!][?] | "send the given command (decimal) to targets (all, g00 to g15, s00 to s63), auto repeat with !, read reply with ?" |- | dali dim [TARGET] [LEVEL] | "dim targets (all, g00 to g15, s00 to s63) to given level (0-254)" |- | dali raw [BYTE1] [BYTE2] | "send a raw frame (two bytes, given in hex) over the DALI bus" |- | dali scmd [SPECIAL COMMAND] [DATA] [!][?] | "send special command (256-287) with data, auto repeat with !, read reply with ?" |- |} == [[DHT]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dht humid [SENSORNUMBER] | Return humidity of DHT sensor |- | dht list | Return a list of mapped sensor names |- | dht temp [SENSORNUMBER] | Return temperature of DHT sensor |- |} == [[DMX_FXSlot]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx fxslot devices | set the device settings |- | dmx fxslot effect | set the effect settings |- | dmx fxslot reset | reset all fxslots and clear saved ones in EEPROM |- | dmx fxslot restore | restore the settings from EEPROM |- | dmx fxslot save | save the current fxslots to EEPROM |- |} == [[DMX_Storage]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx channels | Get channels per universe |- | dmx get | Return channel value |- | dmx set | Set channel values |- | dmx universe | Get a whole universe |- | dmx universes | Get universes |- |} == [[Dallas_1-wire_Bus]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | 1w convert DEVICE | Trigger temperature conversion of either DEVICE or all connected devices |- | 1w ds2450 convert [DEVICE] | `start conversion (with optional input mask and read out control)' |- | 1w ds2450 get [DEVICE] | `get conversion result (one or all channels)' |- | 1w ds2450 oc [DEVICE] | `get/set output control (per channel)' |- | 1w ds2450 oe [DEVICE] | `get/set output enable (per channel)' |- | 1w ds2450 por [DEVICE] | `get/set power on reset (per channel)' |- | 1w ds2450 power [DEVICE] | `get/set power supply of device (global)' |- | 1w ds2450 range [DEVICE] | `get/set input voltage range (per channel)' |- | 1w ds2450 res [DEVICE] | `get/set bit resolution of AD convert (per channel)' |- | 1w get DEVICE | Return temperature value of onewire device (provide 64-bit ID as 16-hex-digits) |- | 1w list | Return a list of the connected onewire devices |- | 1w name clear ID | Delete a name mapping |- | 1w name list | Return a list of mapped device names |- | 1w name save | Save name mappings to EEPROM |- | 1w name set ID DEVICE NAME | Assign a name to/from an device address |- |} == [[DataFlash]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | df status | Display internal status. |- | fs format | Format the filesystem. |- | fs inspect inode INODE | Inspect INODE (and associated page). |- | fs inspect node NODE | Inspect NODE and dump to serial. |- | fs list | List the directory. |- | fs mkfile NAME | Create a new file NAME. |- | fs remove NAME | Delete the file NAME. |- | fs truncate NAME LEN | Truncate the file NAME to LEN bytes. |- |} == [[Dc3840_camera|DC3840 mobil camera support]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dc3840 capture | Take a picture. Access 'dc3840' via VFS afterwards. See [[DC3840 Camera]] for details. |- | dc3840 light | Light level of camera |- | dc3840 send A B C D E | Send provided command bytes to the camera. |- | dc3840 sync | Re-sync to the camera |- | dc3840 zoom | Enable zoom of camera |- |} == [[ECMDScript]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | call FILENAME | Start script named FILENAME |- | cat FILENAME | cat file content (with debug only) |- | dec VAR | Decrement variable VAR (a number) |- | echo <any> | Print out all arguments of echo |- | exit | Exit currently running script |- | get VAR | Get value of variable VAR |- | goto N | Goto line N in currently running script |- | if ( CMD/VAR == CONST ) then CMD2 | If condition matches execute CMD2 |- | inc VAR | Increment variable VAR (a number) |- | rem <any> | Remark for anything |- | set VAR VALUE | Set variable VAR to VALUE |- | wait I | Wait I milliseconds |- |} == [[FS20]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fht send HOUSECODE ADDR CMD [CMD2] | Send FHT command. See [[FS20]] for details. |- | fs20 receive | Receive FS20/FHT sequence and display it. |- | fs20 send HOUSECODE ADDR CMD [CMD2] | Send FS20 command. See [[FS20]] for details. |- | fs20 ws300 | Receive FS20 sequence from WS300 weather station and decode it. |- |} == [[Frequency Counter]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fc %duty [CHANNEL] | "returns last on duty cycle in percent for given channel" |- | fc duty [CHANNEL] | "returns last on duty cycle (0-255) for given channel" |- | fc freq [CHANNEL] | "returns last frequency in Hz for given channel" |- | fc off [CHANNEL] | "switch off frequency counting on given channel" |- | fc on [CHANNEL] | "switch on frequency counting on given channel" |- | fc ticks [CHANNEL] | "returns last frequency in CPU ticks for given channel" |- |} == [[GLCD_Menu]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | glcdmenu key VALUE | Send a keypress to the menu |- | glcdmenu update | Update the menu |- |} == [[GPS]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | nmea get | Get latitude and longitude data |- | nmea satellites | Get satellites |- |} == [[H-Bridge]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | hbridge [action] [enable_l] [enable_r] | Set H-Bridge command |- | hbridge pwm int | Set H-Bridge enable line valueeg. speed |- |} == [[I2C]] (TWI) == {| border='1' | ''Command syntax'' | ''Short description'' |- | bmp085 apress | Get absolute pressure in Pa |- | bmp085 height PRESSNN | Get height in cm, pressure at N0 needed |- | bmp085 pressnn HEIGHT | Get pressure at N0, height in cm needed |- | bmp085 temp | Get temperature in 0.1°C |- | ds1631 convert ADDR VALUE | Initiate temperature conversions (0: stop, 1: convert) |- | ds1631 temp ADDR | Read last converted temperature |- | ee dir | List files in I2C EEPROM. |- | ee rm PATH | Remove file PATH. |- | i2c detect | list detected I2C Chips |- | i2c pca9555 in | read word from register address on I2C chip |- | i2c pca9555 mode VALUE | select input or output mode for pins on I2C chip |- | i2c pca9555 out VALUE | write word to register address on I2C chip |- | i2c rbb ADDR | read byte from I2C chip |- | i2c rbd CHIPADDR REGADDR | read byte from register address at I2C chip |- | i2c rwd CHIPADDR REGADDR | read word from register address at I2C chip |- | i2c wbb ADDR HEXVALUE | write byte to I2C chip |- | i2c wbd CHIPADDR REGADDR HEXVALUE | write byte to register address on I2C chip |- | i2c wwd CHIPADDR REGADDR HEXVALUE | write word to register address on I2C chip |- | lm75 ADDR | Get temperature |- | max7311 getDDRw ADDR | Get Direction-Register DDR |- | max7311 getINw ADDR | Get Input-Register IN |- | max7311 getOUTw ADDR | Get Output-Register OUT |- | max7311 pulse ADDR BIT TIME | Toggle Output-BIT for TIME (in ms) |- | max7311 set ADDR BIT VALUE | Set Output-BIT to VALUE (bool) |- | max7311 setDDRw ADDR VALUE | Set Direction-Register DDR (VALUE as hex) |- | max7311 setOUTw ADDR VALUE | Set Output-Register OUT (VALUE as hex) |- | mcp23017 clear pin ADDR PORT BIT | Clear Port BIT for PORT A or B |- | mcp23017 get iodir ADDR PORT | Get I/O Direction Register for PORT A or B |- | mcp23017 get olat ADDR PORT | Get Output Latch Register for PORT A or B |- | mcp23017 get port ADDR PORT | Get Port Register (i.e. Port Pin State) for PORT A or B |- | mcp23017 getreg ADDR REGADDR | Get Register REGADDR |- | mcp23017 pulse pin ADDR PORT BIT TIME | Toggle-Pulse Port BIT for PORT A or B for TIME ms |- | mcp23017 set iodir ADDR PORT VALUE | Set I/O Direction Register for PORT A or B (VALUE as hex) |- | mcp23017 set olat ADDR PORT VALUE | Set Output Latch Register for PORT A or B (VALUE as hex) |- | mcp23017 set pin ADDR PORT BIT | Set Port BIT for PORT A or B |- | mcp23017 setreg ADDR REGADDR VALUE | Set Register REGADDR (VALUE as hex) |- | mcp23017 toggle pin ADDR PORT BIT | Toggle Port BIT for PORT A or B |- | pca9531 ADDR PERIODPWM1 DUTYPWM1 PERIODPWM2 DUTYPWM2 LED0..3 LED4..7 | set PWM1 and PWM2 and LED states |- | pcf8574x read ADDR CHIP | Get bits |- | pcf8574x set ADDR CHIP HEXVALUE | Set bits |- | tmp175 ADDR | Get temperature |- | tsl2550 lux | Show light level by reading adc registers and computing level |- | tsl2550 mode VALUE | Set the TSL2550s operating mode (0: standard range, 1: extended range) |- | tsl2550 power VALUE | Set the TSL2550s power state (0: down, 1:up) |- | tsl2561 lux DEVNUM | Get LUX value |- | tsl2561 raw DEVNUM | Get RAW channel values |- | tsl2561 setmode DEVNUM TIME GAIN PACKAGE | Set device mode |- |} == [[Jabber]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | jabber_host [HOSTNAME] | JABBER hostname |- | jabber_pass [PASSWORD] | JABBER password |- | jabber_resrc [RESOURCE] | JABBER resource |- | jabber_user [USERNAME] | JABBER username |- |} == [[KTY]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | kty autocalibrate CHANNEL | Calibrate to 1000 Ohm precision Resistor. |- | kty cal get | Return the calibration difference to 2k2 Resistor. |- | kty get [CHANNEL] | Get the temperature in xxx.x °C of CHANNEL or if no channel set of all channels. |- |} == [[MotorCurtain]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | curtain VALUE | Set value of curtain. 0=closed..7=open. If you use fewer sensors, use the corrent value instead of 7. |- | curtainlast | Return last known position |- | curtainmax | Return maximum position |- | curtainoff | Switch motor off |- |} == [[Named_PIN]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | pin get NAME | Read and display the status of pin NAME. |- | pin list | List all known named-pins. |- | pin set NAME STATUS | Set the status of pin NAME to STATUS. |- | pin toggle NAME | Toggle the status of pin NAME. |- |} == [[PWM]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dtmf CHARS | send CHARS as DTMF |- | freq set FREQUENCY DELAY | Set frequency for DELAY ms |- | pwm fade [channel +-diff startvalue] | Set fading at channel with startvalue and change each stepp to diff (must be signed 3 digit) |- | pwm set [channel value] | Set channel to value |- |} == [[RFM12]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | rfm12 reinit | Re-initialize the RFM12 FSK module. |- | rfm12 setbandwidth MODULE BW | Set receiver bandwidth of MODULE to BW. |- | rfm12 setbaud MODULE BAUD | Set baudrate of MODULE to BAUD. |- | rfm12 setdrssi MODULE DRSSI | Set the drssi of MODULE to DRSSI. |- | rfm12 setgain MODULE GAIN | Set preamplifier gain of MODULE to GAIN. |- | rfm12 setmod MOD | Set modulation of the RFM12 FSK module to MOD. |- | rfm12 status MODULE | Display internal status of MODULE. |- |} == [[RFM12_ASK]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | rfm12 ask sense | Trigger (Tevion) ASK sensing. Enable ext. filter pin before! |- | rfm12 external filter [1] | Enable ext. filter pin if argument is present (disable otherwise) |- |} == [[RFM12_FS20]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fht send | housecode addr command data |- | fs20 receive | Receive FS20/FHT sequence and display it. |- | fs20 send | housecode addr command data |- | fs20 setdebug DEBUG | Set debug to DEBUG. |- |} == [[SD-Karte]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sd dir | List contents of current SD directory. |- | sd info | List information about SD card. |- | sd mkdir PATH | Create directory hierarchy PATH. |- | sd rm PATH | Remove file PATH. |- |} == [[SGC]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | sgc adduc ADDR CH0 CH1 CH2 CH3 CH4 CH5 CH6 CH7 | Add user character: address 0..0x1F and 8 bytes character |- | sgc circle X Y RADIUS | Draw circle with parameters and colour specified in sgc_colour |- | sgc cls | Clear screen |- | sgc colour RED GREEN BLUE | Set pen / font colour:red-green-blue 0..0x1F or 2-byte RGB with only two parameters |- | sgc contrast CONTRAST | Set contrast value 0..0x0F |- | sgc druc ADDR X Y | Draw user character saved from sgc_adduc at address 0..0x1F and with colour specified in sgc_colour |- | sgc font FONT PROPORTIONAL | Set font type:0..2 and 0:not proportional 1:proportional |- | sgc gchar X Y WIDTH HEIGHT CHAR | Draw ASCII character in graphics format at specified position and size with colour specified in sgc_colour |- | sgc getpwr | Get Power Status |- | sgc line X1 Y1 X2 Y2 | Draw line between specified points with colour specified in sgc_colour |- | sgc object UMSB ULSB LMSB LLSB | Display object from SD card at specified address |- | sgc onoff ONOFF | Turn display on:1 or off:0 |- | sgc opacity OPACITY | Set text opacity 0:transparent 1:opaque |- | sgc pensize PENSIZE | Set pen size 0:solid 1:lines |- | sgc pixel X Y | Draw pixel at specified point with colour specified in sgc_colour |- | sgc rectangle X1 Y1 X2 Y2 | Draw rectangle with specified edges and with colour specified in sgc_colour |- | sgc repbgc RED GREEN BLUE | Replace background colour:red-green-blue 0..0x1F or 2-byte RGB with only two parameters |- | sgc repcol X_START Y_START X_END Y_END OLD_RED OLD_GREEN OLD_BLUE | Replace old colour - red-green-blue 0..0x1F or 2-byte RGB with only two parameters in selected area - with colour specified in sgc_colour |- | sgc result | Get result from last command |- | sgc scrcp SRC_X SRC_Y DST_X DST_Y WIDTH HEIGHT | Copy-Paste selected screen area |- | sgc script UMSB ULSB LMSB LLSB | Run 4DSL script from SD card at specified address |- | sgc sdicon X Y WIDTH HEIGHT SECTOR0 SECTOR1 SECTOR2 | Display icon from SD card at specified position and size stored at specified SD card sector |- | sgc setbgc RED GREEN BLUE | Set background colour:red-green-blue 0..0x1F or 2-byte RGB with only two parameters |- | sgc setip IPADDR | Change response IP address - volatile |- | sgc setpwr PWR | Set Power Status: 1:on 0:off |- | sgc setsleep AUTO MODE | Set Auto Shutdown Sleep 1:on 0:off / Set wakeup mode 0:Serial 1: Joystick |- | sgc settimeout TIMEOUT | Change auto-off idle time - volatile |- | sgc sleep SLEEP | Sleep mode 0:turn off SD 1:wake on serial 2:wake on joystick |- | sgc stg X Y WIDTH HEIGHT STRING | Draw ASCII string in graphics format at specified position and size with colour specified in sgc_colour) |- | sgc stt COL ROW STRING | Draw ASCII string in text format at specified col and row and with colour specified in sgc_colour |- | sgc tchar COL ROW CHAR | Draw ASCII character in text format at specified col and row and with colour specified in sgc_colour |- | sgc triangle X1 Y1 X2 Y2 X3 Y3 | Draw triangle with edges counter-clockwise and with colour specified in sgc_colour |- | sgc video X Y WIDTH HEIGHT DELAY NUM_FRAMES0 NUM_FRAMES1 SECTOR0 SECTOR1 SECTOR2 | Display video / animation from SD card at specified position and size and with specified inter-frame delay and frame number stored at specified SD card sector |- |} == [[SHT]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sht humid | Return humidity of SHT sensor |- | sht raw | Return raw hex temp (first line) and humidity value (second line) of SHT sensor |- | sht temp | Return temperature of SHT sensor |- |} == [[SMS77]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sms77 MESSAGE | Send MESSAGE to compiled in sms77 service |- | sms77_pass [PASSWORD] | SMS77 password |- | sms77_recv [RECEIVER] | SMS receiver |- | sms77_type [TYPE] | SMS type |- | sms77_user [USERNAME] | SMS77 username |- |} == [[Servo_Ansteuerung|PWM Servo Control]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | pwm servo_dec SERVONR | Decrement position of servo SERVONR |- | pwm servo_inc SERVONR | Increment position of servo SERVONR |- | pwm servo_set SERVONR POSITION | Set servo with SERVONR to POSITION |- |} == [[Sound]]/WAV support == {| border='1' | ''Command syntax'' | ''Short description'' |- | pwm stop | Stop wav |- | pwm wav <FILENAME> | Play wave file. Use VFS if compiled in. More details at [[Sound]] |- |} == [[Stella_Light]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | channel CHANNEL VALUE FUNCTION | Get/Set stella channel to value. Second and third parameters are optional. Function: You may use 's' for instant set, 'f' for fade and 'y' for flashy fade. |- | channels | Return stella channel size |- | fadestep FADESTEP | Get/Set stella fade step |- | stella load | Load values from eeprom |- | stella store | Store values in eeprom |- | tank get | get last value |- | tank param save | write tank parameter to EEPROM |- | tank param set PARAM VALUE | set tank parameter |- | tank param show | show tanklevel parameters |- | tank start | start measure |- | tank zero | probe sensor zero offset |- |} == [[USB]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | keyboard MESSAGE | Send MESSAGE as HID keyboard |- | mouse BUTTON DELTAX DELTAY | Send data as HID mouse |- |} == [[ZACwire]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | zac 306 PORT BIT | Return temperature of TSic 306 at BIT of PORT |- | zac 506 PORT BIT | Return temperature of TSic 506 at BIT of PORT |- | zac raw PORT BIT | Return raw hex temperature value of zacwire at BIT of PORT |- |} == lome6 == {| border='1' | ''Command syntax'' | ''Short description'' |- | lome6 get_t TYPE | get temperature command |- | lome6 power TYPE | press power command |- | lome6 reset | press reset command |- | lome6 set_t TYPE TEMPERATURE | set temperature command |- | lome6 state | get state command |- | lome6 uptime UPTIME | set/get uptime command |- |} == Miscelleanous == {| border='1' | ''Command syntax'' | ''Short description'' |- | alias list | List all available aliases |- | artnet test | artnet test |- | cw send MESSAGE | Send MESSAGE in Morce Code |- | d ADDR | Dump the memory at ADDR (16 bytes). |- | eeprom reinit | Force reinitialization of the EEPROM config area |- | ems stats | Report statistic counters |- | free | Display free space. |- | help | List which commands are available. |- | ht MESSAGE | Send MESSAGE to compiled in httplog service |- | ipstats | Display IP statistics. |- | mb recv | Receive data from modbus |- | moodlight CHANNEL ONOFF | Set CHANNEL moodlight on=1 or off=0. If no channel is given return on if channel CHANNEL is moodlighted |- | motd [MESSAGE] | Save MESSAGE as new message of the day, otherwise just show current message |- | msr1 get | Get data |- | mysql query QUERY | Send specified MySQL query to the configured server |- | ns | update net statistic for public anouncment of currently running ethersex |- | pam USER PASSWORD | Use pam for user and password |- | push NUMBER | Push button identified by NUMBER |- | pwm melody [NUMBER] | Play melody |- | sanyoz700 CMD | Send command to projector |- | sll get | Request the logged data |- | sram memtest | Perform a memory test |- | srf05 | Read SRF05 measurement |- | to1 get | Request data from sensor |- | tw MESSAGE | Send MESSAGE to compiled in twitter service |- | upnp send | Manually send UPnP broadcast packet |- | usart baud BAUD | Set the USART baudrate to BAUD. |- | version | Display the version number. |- | weather | Get eltako weather data |- | wol MAC | Send WAKE-ON-LAN command to MAC |- | yport stats | Report statistic counters |- | zbus stats | Report statistic counters |- |} [[Category:Ethersex]] [[Category:ECMD]] 082de2128b414be59db0f83bff0ea0651850dc99 1736 1735 2016-10-14T19:01:16Z Michaelb 718 wikitext text/x-wiki <div class="errorbox"> This page is automatically generated from the files in the Ethersex source code repository. Do not edit this page but send [[patches]] for those files! </div> __NOTOC__ == DNS Resolver == {| border='1' | ''Command syntax'' | ''Short description'' |- | dns server [IPADDR] | Display/Set the IP address of the DNS server to use to IPADDR. |- | nslookup HOSTNAME | Do DNS lookup for HOSTNAME (call twice). |- |} == Digital/Analog Conversion ([[DAC]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ltc1257_delay `[VALUE] | Set (if VALUE given) or get (no VALUE) delay for LTC1257 output bit changes in µs' |- | ltc1257_set `[VALUE0] [VALUE1] ... | Set output to value (value: 0-4095)' |- | tlc5620 `[CHANNEL] [VALUE] | Set Output to value (Value: 0-0xff)' |- |} == Fnordlicht == {| border='1' | ''Command syntax'' | ''Short description'' |- | fnordlicht "ADDRESS RED | GREEN,BLUE",fnordlicht command to set RGB color |- | fnordlicht_init | fnordlicht init |- |} == HD44780 [[LCD]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | hr20 hourbar START STOP | Update hourbar to show ticks between START and STOP (range 0..23) |- | hr20 toggle SEG | Toggle segment SEG (a number, not a symbolic name!) |- | lcd backlight [STATE] | get or set the state of the lcd backlight |- | lcd char N D1 D2 D3 D4 D5 D6 D7 D8 | Define use-definable char N with data D1..D8 (provide DATA in hex) |- | lcd clear [LINE] | Clear line LINE (0..3) or the whole display (if parameter is omitted) |- | lcd goto LINE COL | Move cursor to LINE and column COL (origin is 0/0) |- | lcd reinit CURSOR BLINK | Reinitialize the display, set whether to show the cursor (CURSOR, 0 or 1) and whether the cursor shall BLINK |- | lcd shift DIR | Shift the display to DIR (either ''left'' or ''right'') |- | lcd write TEXT | Write TEXT to the current cursor location |- |} == Infrared Send/Receive ([[IRMP]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | irmp receive | receive an IR command |- | irmp send PROTOCOL DEVICE COMMAND REPEAT | send COMMAND with REPEAT flag to DEVICE using PROTOCOL |- |} == Infrared Send/Receive ([[RC5]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ir receive | receive an IR command |- | ir send DEVICE COMMAND | send COMMAND to DEVICE |- |} == Miscellaneous == {| border='1' | ''Command syntax'' | ''Short description'' |- | periodic adjust OFFSET | Adjust periodic timers TOP value by adding OFFSET ticks. |- | periodic reset | Reset debug statistics for periodic module. |- | periodic stats | Print debug statistics for periodic module. |- |} == NTP Client == {| border='1' | ''Command syntax'' | ''Short description'' |- | ntp query | Query the NTP server to get an NTP update. |- | ntp server [IPADDR] | Display/Set the IP address of the NTP server to use to IPADDR. |- | ntp status | Display NTP server status |- |} == Network configuration == {| border='1' | ''Command syntax'' | ''Short description'' |- | enc dump | Dump the internal state of the enc to serial |- | gw [IP] | Display/Set the address of the default router. |- | ip [IP] | Display/Set the IP address. |- | mac [xx:xx:xx:xx:xx:xx] | Display/Set the MAC address. |- | netmask [IP] | Display/Set the network mask. |- |} == Port I/O == {| border='1' | ''Command syntax'' | ''Short description'' |- | io get ddr PORTNUM | Display the current value of the DDR PORTNUM. |- | io get mask PORTNUM | Display the mask of the port PORTNUM. |- | io get pin PORTNUM | Display the current value of the PIN-register of the port PORTNUM. |- | io get port NUM | Display the current value of the PORT NUM. |- | io set ddr PORTNUM HEXVALUE [MASK] | Set the DDR of port PORTNUM to VALUE (possibly using the provided MASK). |- | io set port NUM HEXVALUE [MASK] | Set the PORT NUM to VALUE (possibly using the provided MASK). |- |} == Reading and Writing EEPROM Space on Device == {| border='1' | ''Command syntax'' | ''Short description'' |- | eer eer <ADDR> <LENGTH> | Read n bytes from address after the config in eeprom. |- | eew eew <ADDR> <HEXBYTES> | Write Hexbytes at address after the config in epprom. |- | hostname | Display hostname. |- |} == Resetting the controller == {| border='1' | ''Command syntax'' | ''Short description'' |- | bootloader | Call the bootloader. |- | reset | Reset the Ethersex. |- | wdreset | Go into endless loop to trigger a watchdog timeout. |- |} == [[ADS]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | ads get | Get the ADC value in hex. |- | ads mean [COUNT] | Get the mean of power of 2 COUNT ADC values in hex. |- | fuse | Display current fuse settings |- |} == [[ASK]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | ask 1527 HOUSECODE COMMAND DELAY CNT | |- | ask 2272 HOUSECODE COMMAND [DELAY] [CNT] [SYNC] | |- | ask fa20rf DEVICE [REPEAT] | |- | ask intertechno FAMILY GROUP DEVICE COMMAND | "Send Command to Intertechno switches (with coding wheel). FAMILY: A=1, ..." |- | ask itsl HOUSECODE COMMAND BUTTON [DIM] | "Send Command to Intertechno Self learning switches and dimmers. DIM works only with dimmers and values 0-15." |- | ask oase FAMILY GROUP DEVICE COMMAND | |- | ask tevion HOUSECODE COMMAND DELAY CNT | |- |} == [[Am_Puls_der_Zeit|Clock]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | date | Print the current date. |- | lastdcf | Print when last valid DCF signal was received. |- | time [UNIXTIME] | Display/Set the current time in seconds since January 1st 1970. |- | uptime | Display ethersex uptime in unix format. |- | whm | Display ethersex uptime. |- |} == [[Application_Sample]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sample | Manually call application sample commands |- | sample_init | Manually call application sample init method |- | sample_periodic | Manually call application sample periodic method |- |} == [[BSBPORT]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | bsbport get P1 P2 P3 P4 SRC TYPE | Show specific message currently in buffer format value as TYPE type is one of RAW STA TMP FP1 FP5 |- | bsbport list | List all messages currently in buffer output in RAW TMP FP1 FP5 |- | bsbport query P1 P2 P3 P4 [DEST] | Send Message to query for a value DEST is optional defaults to 0 |- | bsbport set P1 P2 P3 P4 DEST TYPE VALUE | Send Message to set value type is one of RAW SEL TMP FP1 FP5 |- | bsbport stats | Report statistic counters OK/CRC/Lenght under/Lenght over/Droped/Buffer/BufferNet/Retransmit |- |} == [[Blinkenlights_MCUF|MCUF]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | mcuf modul N | Select module N |- | mcuf modul list | List all modules |- | mcuf showclock | Show digital clock |- | mcuf showstring MESSAGE | Show scrolling MESSAGE on the display |- |} == [[CRC]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | adc get [CHANNEL] | Get the ADC value in hex of CHANNEL or if no channel set of all channels. |- | adc vget [CHANNEL] | Get the ADC value in volt of CHANNEL or if no channel set of all channels. |- | adc vref [VOLTAGE] | Get/Set ADC reference voltage calibration. |- | crc calc | "read the ethersex program code and calc a crc16 of it" |- | crc read | "read out the crc16 value at the end of the program space" |- | hr20 temp | Read HR20 temperature sensor. |- |} == [[CRON-Dienst]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | cron add MIN HOUR DAY MONTH DOW ECMD | Add ECMD to cron to be executed at given time |- | cron anacron POSITION [STATE] | show/set job anacron state |- | cron list | Show all cron entries |- | cron persistent POSITION [STATE] | show/set job persistance state |- | cron rm [POSITION] | Remove one cron entry |- | cron save | Saves all persistent jobs |- | cron utc POSITION [STATE] | show/set utc state |- |} == [[DALI]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dali cmd [TARGET] [COMMAND] [!][?] | "send the given command (decimal) to targets (all, g00 to g15, s00 to s63), auto repeat with !, read reply with ?" |- | dali dim [TARGET] [LEVEL] | "dim targets (all, g00 to g15, s00 to s63) to given level (0-254)" |- | dali raw [BYTE1] [BYTE2] | "send a raw frame (two bytes, given in hex) over the DALI bus" |- | dali scmd [SPECIAL COMMAND] [DATA] [!][?] | "send special command (256-287) with data, auto repeat with !, read reply with ?" |- |} == [[DHT]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dht humid [SENSORNUMBER] | Return humidity of DHT sensor |- | dht list | Return a list of mapped sensor names |- | dht temp [SENSORNUMBER] | Return temperature of DHT sensor |- |} == [[DMX_FXSlot]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx fxslot devices | set the device settings |- | dmx fxslot effect | set the effect settings |- | dmx fxslot reset | reset all fxslots and clear saved ones in EEPROM |- | dmx fxslot restore | restore the settings from EEPROM |- | dmx fxslot save | save the current fxslots to EEPROM |- |} == [[DMX_Storage]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx channels | Get channels per universe |- | dmx get | Return channel value |- | dmx set | Set channel values |- | dmx universe | Get a whole universe |- | dmx universes | Get universes |- |} == [[Dallas_1-wire_Bus]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | 1w convert DEVICE | Trigger temperature conversion of either DEVICE or all connected devices |- | 1w ds2450 convert [DEVICE] | `start conversion (with optional input mask and read out control)' |- | 1w ds2450 get [DEVICE] | `get conversion result (one or all channels)' |- | 1w ds2450 oc [DEVICE] | `get/set output control (per channel)' |- | 1w ds2450 oe [DEVICE] | `get/set output enable (per channel)' |- | 1w ds2450 por [DEVICE] | `get/set power on reset (per channel)' |- | 1w ds2450 power [DEVICE] | `get/set power supply of device (global)' |- | 1w ds2450 range [DEVICE] | `get/set input voltage range (per channel)' |- | 1w ds2450 res [DEVICE] | `get/set bit resolution of AD convert (per channel)' |- | 1w get DEVICE | Return temperature value of onewire device (provide 64-bit ID as 16-hex-digits) |- | 1w list | Return a list of the connected onewire devices |- | 1w name clear ID | Delete a name mapping |- | 1w name list | Return a list of mapped device names |- | 1w name save | Save name mappings to EEPROM |- | 1w name set ID DEVICE NAME | Assign a name to/from an device address |- |} == [[DataFlash]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | df status | Display internal status. |- | fs format | Format the filesystem. |- | fs inspect inode INODE | Inspect INODE (and associated page). |- | fs inspect node NODE | Inspect NODE and dump to serial. |- | fs list | List the directory. |- | fs mkfile NAME | Create a new file NAME. |- | fs remove NAME | Delete the file NAME. |- | fs truncate NAME LEN | Truncate the file NAME to LEN bytes. |- |} == [[Dc3840_camera|DC3840 mobil camera support]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dc3840 capture | Take a picture. Access 'dc3840' via VFS afterwards. See [[DC3840 Camera]] for details. |- | dc3840 light | Light level of camera |- | dc3840 send A B C D E | Send provided command bytes to the camera. |- | dc3840 sync | Re-sync to the camera |- | dc3840 zoom | Enable zoom of camera |- |} == [[ECMDScript]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | call FILENAME | Start script named FILENAME |- | cat FILENAME | cat file content (with debug only) |- | dec VAR | Decrement variable VAR (a number) |- | echo <any> | Print out all arguments of echo |- | exit | Exit currently running script |- | get VAR | Get value of variable VAR |- | goto N | Goto line N in currently running script |- | if ( CMD/VAR == CONST ) then CMD2 | If condition matches execute CMD2 |- | inc VAR | Increment variable VAR (a number) |- | rem <any> | Remark for anything |- | set VAR VALUE | Set variable VAR to VALUE |- | wait I | Wait I milliseconds |- |} == [[FS20]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fht send HOUSECODE ADDR CMD [CMD2] | Send FHT command. See [[FS20]] for details. |- | fs20 receive | Receive FS20/FHT sequence and display it. |- | fs20 send HOUSECODE ADDR CMD [CMD2] | Send FS20 command. See [[FS20]] for details. |- | fs20 ws300 | Receive FS20 sequence from WS300 weather station and decode it. |- |} == [[Frequency Counter]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fc %duty [CHANNEL] | "returns last on duty cycle in percent for given channel" |- | fc duty [CHANNEL] | "returns last on duty cycle (0-255) for given channel" |- | fc freq [CHANNEL] | "returns last frequency in Hz for given channel" |- | fc off [CHANNEL] | "switch off frequency counting on given channel" |- | fc on [CHANNEL] | "switch on frequency counting on given channel" |- | fc ticks [CHANNEL] | "returns last frequency in CPU ticks for given channel" |- |} == [[GLCD_Menu]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | glcdmenu key VALUE | Send a keypress to the menu |- | glcdmenu update | Update the menu |- |} == [[GPS]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | nmea get | Get latitude and longitude data |- | nmea satellites | Get satellites |- |} == [[H-Bridge]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | hbridge [action] [enable_l] [enable_r] | Set H-Bridge command |- | hbridge pwm int | Set H-Bridge enable line valueeg. speed |- |} == [[I2C]] (TWI) == {| border='1' | ''Command syntax'' | ''Short description'' |- | bmp085 apress | Get absolute pressure in Pa |- | bmp085 height PRESSNN | Get height in cm, pressure at N0 needed |- | bmp085 pressnn HEIGHT | Get pressure at N0, height in cm needed |- | bmp085 temp | Get temperature in 0.1°C |- | ds1631 convert ADDR VALUE | Initiate temperature conversions (0: stop, 1: convert) |- | ds1631 temp ADDR | Read last converted temperature |- | ee dir | List files in I2C EEPROM. |- | ee rm PATH | Remove file PATH. |- | i2c detect | list detected I2C Chips |- | i2c pca9555 in | read word from register address on I2C chip |- | i2c pca9555 mode VALUE | select input or output mode for pins on I2C chip |- | i2c pca9555 out VALUE | write word to register address on I2C chip |- | i2c rbb ADDR | read byte from I2C chip |- | i2c rbd CHIPADDR REGADDR | read byte from register address at I2C chip |- | i2c rwd CHIPADDR REGADDR | read word from register address at I2C chip |- | i2c wbb ADDR HEXVALUE | write byte to I2C chip |- | i2c wbd CHIPADDR REGADDR HEXVALUE | write byte to register address on I2C chip |- | i2c wwd CHIPADDR REGADDR HEXVALUE | write word to register address on I2C chip |- | lm75 ADDR | Get temperature |- | max7311 getDDRw ADDR | Get Direction-Register DDR |- | max7311 getINw ADDR | Get Input-Register IN |- | max7311 getOUTw ADDR | Get Output-Register OUT |- | max7311 pulse ADDR BIT TIME | Toggle Output-BIT for TIME (in ms) |- | max7311 set ADDR BIT VALUE | Set Output-BIT to VALUE (bool) |- | max7311 setDDRw ADDR VALUE | Set Direction-Register DDR (VALUE as hex) |- | max7311 setOUTw ADDR VALUE | Set Output-Register OUT (VALUE as hex) |- | mcp23017 clear pin ADDR PORT BIT | Clear Port BIT for PORT A or B |- | mcp23017 get iodir ADDR PORT | Get I/O Direction Register for PORT A or B |- | mcp23017 get olat ADDR PORT | Get Output Latch Register for PORT A or B |- | mcp23017 get port ADDR PORT | Get Port Register (i.e. Port Pin State) for PORT A or B |- | mcp23017 getreg ADDR REGADDR | Get Register REGADDR |- | mcp23017 pulse pin ADDR PORT BIT TIME | Toggle-Pulse Port BIT for PORT A or B for TIME ms |- | mcp23017 set iodir ADDR PORT VALUE | Set I/O Direction Register for PORT A or B (VALUE as hex) |- | mcp23017 set olat ADDR PORT VALUE | Set Output Latch Register for PORT A or B (VALUE as hex) |- | mcp23017 set pin ADDR PORT BIT | Set Port BIT for PORT A or B |- | mcp23017 setreg ADDR REGADDR VALUE | Set Register REGADDR (VALUE as hex) |- | mcp23017 toggle pin ADDR PORT BIT | Toggle Port BIT for PORT A or B |- | pca9531 ADDR PERIODPWM1 DUTYPWM1 PERIODPWM2 DUTYPWM2 LED0..3 LED4..7 | set PWM1 and PWM2 and LED states |- | pcf8574x read ADDR CHIP | Get bits |- | pcf8574x set ADDR CHIP HEXVALUE | Set bits |- | tmp175 ADDR | Get temperature |- | tsl2550 lux | Show light level by reading adc registers and computing level |- | tsl2550 mode VALUE | Set the TSL2550s operating mode (0: standard range, 1: extended range) |- | tsl2550 power VALUE | Set the TSL2550s power state (0: down, 1:up) |- | tsl2561 lux DEVNUM | Get LUX value |- | tsl2561 raw DEVNUM | Get RAW channel values |- | tsl2561 setmode DEVNUM TIME GAIN PACKAGE | Set device mode |- |} == [[Jabber]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | jabber_host [HOSTNAME] | JABBER hostname |- | jabber_pass [PASSWORD] | JABBER password |- | jabber_resrc [RESOURCE] | JABBER resource |- | jabber_user [USERNAME] | JABBER username |- |} == [[KTY]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | kty autocalibrate CHANNEL | Calibrate to 1000 Ohm precision Resistor. |- | kty cal get | Return the calibration difference to 2k2 Resistor. |- | kty get [CHANNEL] | Get the temperature in xxx.x °C of CHANNEL or if no channel set of all channels. |- |} == [[MotorCurtain]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | curtain VALUE | Set value of curtain. 0=closed..7=open. If you use fewer sensors, use the corrent value instead of 7. |- | curtainlast | Return last known position |- | curtainmax | Return maximum position |- | curtainoff | Switch motor off |- |} == [[Named_PIN]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | pin get NAME | Read and display the status of pin NAME. |- | pin list | List all known named-pins. |- | pin set NAME STATUS | Set the status of pin NAME to STATUS. |- | pin toggle NAME | Toggle the status of pin NAME. |- |} == [[PWM]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dtmf CHARS | send CHARS as DTMF |- | freq set FREQUENCY DELAY | Set frequency for DELAY ms |- | pwm fade [channel +-diff startvalue] | Set fading at channel with startvalue and change each stepp to diff (must be signed 3 digit) |- | pwm set [channel value] | Set channel to value |- |} == [[RFM12]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | rfm12 reinit | Re-initialize the RFM12 FSK module. |- | rfm12 setbandwidth MODULE BW | Set receiver bandwidth of MODULE to BW. |- | rfm12 setbaud MODULE BAUD | Set baudrate of MODULE to BAUD. |- | rfm12 setdrssi MODULE DRSSI | Set the drssi of MODULE to DRSSI. |- | rfm12 setgain MODULE GAIN | Set preamplifier gain of MODULE to GAIN. |- | rfm12 setmod MOD | Set modulation of the RFM12 FSK module to MOD. |- | rfm12 status MODULE | Display internal status of MODULE. |- |} == [[RFM12_ASK]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | rfm12 ask sense | Trigger (Tevion) ASK sensing. Enable ext. filter pin before! |- | rfm12 external filter [1] | Enable ext. filter pin if argument is present (disable otherwise) |- |} == [[RFM12_FS20]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fht send | housecode addr command data |- | fs20 receive | Receive FS20/FHT sequence and display it. |- | fs20 send | housecode addr command data |- | fs20 setdebug DEBUG | Set debug to DEBUG. |- |} == [[SD-Karte]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sd dir | List contents of current SD directory. |- | sd info | List information about SD card. |- | sd mkdir PATH | Create directory hierarchy PATH. |- | sd rm PATH | Remove file PATH. |- |} == [[SGC]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | sgc adduc ADDR CH0 CH1 CH2 CH3 CH4 CH5 CH6 CH7 | Add user character: address 0..0x1F and 8 bytes character |- | sgc circle X Y RADIUS | Draw circle with parameters and colour specified in sgc_colour |- | sgc cls | Clear screen |- | sgc colour RED GREEN BLUE | Set pen / font colour:red-green-blue 0..0x1F or 2-byte RGB with only two parameters |- | sgc contrast CONTRAST | Set contrast value 0..0x0F |- | sgc druc ADDR X Y | Draw user character saved from sgc_adduc at address 0..0x1F and with colour specified in sgc_colour |- | sgc font FONT PROPORTIONAL | Set font type:0..2 and 0:not proportional 1:proportional |- | sgc gchar X Y WIDTH HEIGHT CHAR | Draw ASCII character in graphics format at specified position and size with colour specified in sgc_colour |- | sgc getpwr | Get Power Status |- | sgc line X1 Y1 X2 Y2 | Draw line between specified points with colour specified in sgc_colour |- | sgc object UMSB ULSB LMSB LLSB | Display object from SD card at specified address |- | sgc onoff ONOFF | Turn display on:1 or off:0 |- | sgc opacity OPACITY | Set text opacity 0:transparent 1:opaque |- | sgc pensize PENSIZE | Set pen size 0:solid 1:lines |- | sgc pixel X Y | Draw pixel at specified point with colour specified in sgc_colour |- | sgc rectangle X1 Y1 X2 Y2 | Draw rectangle with specified edges and with colour specified in sgc_colour |- | sgc repbgc RED GREEN BLUE | Replace background colour:red-green-blue 0..0x1F or 2-byte RGB with only two parameters |- | sgc repcol X_START Y_START X_END Y_END OLD_RED OLD_GREEN OLD_BLUE | Replace old colour - red-green-blue 0..0x1F or 2-byte RGB with only two parameters in selected area - with colour specified in sgc_colour |- | sgc result | Get result from last command |- | sgc scrcp SRC_X SRC_Y DST_X DST_Y WIDTH HEIGHT | Copy-Paste selected screen area |- | sgc script UMSB ULSB LMSB LLSB | Run 4DSL script from SD card at specified address |- | sgc sdicon X Y WIDTH HEIGHT SECTOR0 SECTOR1 SECTOR2 | Display icon from SD card at specified position and size stored at specified SD card sector |- | sgc setbgc RED GREEN BLUE | Set background colour:red-green-blue 0..0x1F or 2-byte RGB with only two parameters |- | sgc setip IPADDR | Change response IP address - volatile |- | sgc setpwr PWR | Set Power Status: 1:on 0:off |- | sgc setsleep AUTO MODE | Set Auto Shutdown Sleep 1:on 0:off / Set wakeup mode 0:Serial 1: Joystick |- | sgc settimeout TIMEOUT | Change auto-off idle time - volatile |- | sgc sleep SLEEP | Sleep mode 0:turn off SD 1:wake on serial 2:wake on joystick |- | sgc stg X Y WIDTH HEIGHT STRING | Draw ASCII string in graphics format at specified position and size with colour specified in sgc_colour) |- | sgc stt COL ROW STRING | Draw ASCII string in text format at specified col and row and with colour specified in sgc_colour |- | sgc tchar COL ROW CHAR | Draw ASCII character in text format at specified col and row and with colour specified in sgc_colour |- | sgc triangle X1 Y1 X2 Y2 X3 Y3 | Draw triangle with edges counter-clockwise and with colour specified in sgc_colour |- | sgc video X Y WIDTH HEIGHT DELAY NUM_FRAMES0 NUM_FRAMES1 SECTOR0 SECTOR1 SECTOR2 | Display video / animation from SD card at specified position and size and with specified inter-frame delay and frame number stored at specified SD card sector |- |} == [[SHT]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sht humid | Return humidity of SHT sensor |- | sht raw | Return raw hex temp (first line) and humidity value (second line) of SHT sensor |- | sht temp | Return temperature of SHT sensor |- |} == [[SMS77]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sms77 MESSAGE | Send MESSAGE to compiled in sms77 service |- | sms77_pass [PASSWORD] | SMS77 password |- | sms77_recv [RECEIVER] | SMS receiver |- | sms77_type [TYPE] | SMS type |- | sms77_user [USERNAME] | SMS77 username |- |} == [[Servo_Ansteuerung|PWM Servo Control]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | pwm servo_dec SERVONR | Decrement position of servo SERVONR |- | pwm servo_inc SERVONR | Increment position of servo SERVONR |- | pwm servo_set SERVONR POSITION | Set servo with SERVONR to POSITION |- |} == [[Sound]]/WAV support == {| border='1' | ''Command syntax'' | ''Short description'' |- | pwm stop | Stop wav |- | pwm wav <FILENAME> | Play wave file. Use VFS if compiled in. More details at [[Sound]] |- |} == [[Stella_Light]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | channel CHANNEL VALUE FUNCTION | Get/Set stella channel to value. Second and third parameters are optional. Function: You may use 's' for instant set, 'f' for fade and 'y' for flashy fade. |- | channels | Return stella channel size |- | fadestep FADESTEP | Get/Set stella fade step |- | stella load | Load values from eeprom |- | stella store | Store values in eeprom |- | tank get | get last value |- | tank param save | write tank parameter to EEPROM |- | tank param set PARAM VALUE | set tank parameter |- | tank param show | show tanklevel parameters |- | tank start | start measure |- | tank zero | probe sensor zero offset |- |} == [[USB]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | keyboard MESSAGE | Send MESSAGE as HID keyboard |- | mouse BUTTON DELTAX DELTAY | Send data as HID mouse |- |} == [[ZACwire]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | zac 306 PORT BIT | Return temperature of TSic 306 at BIT of PORT |- | zac 506 PORT BIT | Return temperature of TSic 506 at BIT of PORT |- | zac raw PORT BIT | Return raw hex temperature value of zacwire at BIT of PORT |- |} == lome6 == {| border='1' | ''Command syntax'' | ''Short description'' |- | lome6 get_t TYPE | get temperature command |- | lome6 power TYPE | press power command |- | lome6 reset | press reset command |- | lome6 set_t TYPE TEMPERATURE | set temperature command |- | lome6 state | get state command |- | lome6 uptime UPTIME | set/get uptime command |- |} == Miscelleanous == {| border='1' | ''Command syntax'' | ''Short description'' |- | alias list | List all available aliases |- | artnet test | artnet test |- | cw send MESSAGE | Send MESSAGE in Morce Code |- | d ADDR | Dump the memory at ADDR (16 bytes). |- | eeprom reinit | Force reinitialization of the EEPROM config area |- | ems stats | Report statistic counters |- | free | Display free space. |- | help | List which commands are available. |- | ht MESSAGE | Send MESSAGE to compiled in httplog service |- | ipstats | Display IP statistics. |- | mb recv | Receive data from modbus |- | moodlight CHANNEL ONOFF | Set CHANNEL moodlight on=1 or off=0. If no channel is given return on if channel CHANNEL is moodlighted |- | motd [MESSAGE] | Save MESSAGE as new message of the day, otherwise just show current message |- | msr1 get | Get data |- | mysql query QUERY | Send specified MySQL query to the configured server |- | ns | update net statistic for public anouncment of currently running ethersex |- | pam USER PASSWORD | Use pam for user and password |- | push NUMBER | Push button identified by NUMBER |- | pwm melody [NUMBER] | Play melody |- | sanyoz700 CMD | Send command to projector |- | sll get | Request the logged data |- | sram memtest | Perform a memory test |- | srf05 | Read SRF05 measurement |- | to1 get | Request data from sensor |- | tw MESSAGE | Send MESSAGE to compiled in twitter service |- | upnp send | Manually send UPnP broadcast packet |- | usart baud BAUD | Set the USART baudrate to BAUD. |- | version | Display the version number. |- | weather | Get eltako weather data |- | wol MAC | Send WAKE-ON-LAN command to MAC |- | yport stats | Report statistic counters |- | zbus stats | Report statistic counters |- |} [[Category:Ethersex]] [[Category:ECMD]] 27e08041e7fa3521d3ba1c820a9a6f631621ef4c 1737 1736 2016-10-14T19:02:20Z Michaelb 718 wikitext text/x-wiki <div class="errorbox"> This page is automatically generated from the files in the Ethersex source code repository. Do not edit this page but send [[patches]] for those files! </div> <br> <br> __NOTOC__ <br> <br> == DNS Resolver == {| border='1' | ''Command syntax'' | ''Short description'' |- | dns server [IPADDR] | Display/Set the IP address of the DNS server to use to IPADDR. |- | nslookup HOSTNAME | Do DNS lookup for HOSTNAME (call twice). |- |} == Digital/Analog Conversion ([[DAC]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ltc1257_delay `[VALUE] | Set (if VALUE given) or get (no VALUE) delay for LTC1257 output bit changes in µs' |- | ltc1257_set `[VALUE0] [VALUE1] ... | Set output to value (value: 0-4095)' |- | tlc5620 `[CHANNEL] [VALUE] | Set Output to value (Value: 0-0xff)' |- |} == Fnordlicht == {| border='1' | ''Command syntax'' | ''Short description'' |- | fnordlicht "ADDRESS RED | GREEN,BLUE",fnordlicht command to set RGB color |- | fnordlicht_init | fnordlicht init |- |} == HD44780 [[LCD]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | hr20 hourbar START STOP | Update hourbar to show ticks between START and STOP (range 0..23) |- | hr20 toggle SEG | Toggle segment SEG (a number, not a symbolic name!) |- | lcd backlight [STATE] | get or set the state of the lcd backlight |- | lcd char N D1 D2 D3 D4 D5 D6 D7 D8 | Define use-definable char N with data D1..D8 (provide DATA in hex) |- | lcd clear [LINE] | Clear line LINE (0..3) or the whole display (if parameter is omitted) |- | lcd goto LINE COL | Move cursor to LINE and column COL (origin is 0/0) |- | lcd reinit CURSOR BLINK | Reinitialize the display, set whether to show the cursor (CURSOR, 0 or 1) and whether the cursor shall BLINK |- | lcd shift DIR | Shift the display to DIR (either ''left'' or ''right'') |- | lcd write TEXT | Write TEXT to the current cursor location |- |} == Infrared Send/Receive ([[IRMP]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | irmp receive | receive an IR command |- | irmp send PROTOCOL DEVICE COMMAND REPEAT | send COMMAND with REPEAT flag to DEVICE using PROTOCOL |- |} == Infrared Send/Receive ([[RC5]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ir receive | receive an IR command |- | ir send DEVICE COMMAND | send COMMAND to DEVICE |- |} == Miscellaneous == {| border='1' | ''Command syntax'' | ''Short description'' |- | periodic adjust OFFSET | Adjust periodic timers TOP value by adding OFFSET ticks. |- | periodic reset | Reset debug statistics for periodic module. |- | periodic stats | Print debug statistics for periodic module. |- |} == NTP Client == {| border='1' | ''Command syntax'' | ''Short description'' |- | ntp query | Query the NTP server to get an NTP update. |- | ntp server [IPADDR] | Display/Set the IP address of the NTP server to use to IPADDR. |- | ntp status | Display NTP server status |- |} == Network configuration == {| border='1' | ''Command syntax'' | ''Short description'' |- | enc dump | Dump the internal state of the enc to serial |- | gw [IP] | Display/Set the address of the default router. |- | ip [IP] | Display/Set the IP address. |- | mac [xx:xx:xx:xx:xx:xx] | Display/Set the MAC address. |- | netmask [IP] | Display/Set the network mask. |- |} == Port I/O == {| border='1' | ''Command syntax'' | ''Short description'' |- | io get ddr PORTNUM | Display the current value of the DDR PORTNUM. |- | io get mask PORTNUM | Display the mask of the port PORTNUM. |- | io get pin PORTNUM | Display the current value of the PIN-register of the port PORTNUM. |- | io get port NUM | Display the current value of the PORT NUM. |- | io set ddr PORTNUM HEXVALUE [MASK] | Set the DDR of port PORTNUM to VALUE (possibly using the provided MASK). |- | io set port NUM HEXVALUE [MASK] | Set the PORT NUM to VALUE (possibly using the provided MASK). |- |} == Reading and Writing EEPROM Space on Device == {| border='1' | ''Command syntax'' | ''Short description'' |- | eer eer <ADDR> <LENGTH> | Read n bytes from address after the config in eeprom. |- | eew eew <ADDR> <HEXBYTES> | Write Hexbytes at address after the config in epprom. |- | hostname | Display hostname. |- |} == Resetting the controller == {| border='1' | ''Command syntax'' | ''Short description'' |- | bootloader | Call the bootloader. |- | reset | Reset the Ethersex. |- | wdreset | Go into endless loop to trigger a watchdog timeout. |- |} == [[ADS]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | ads get | Get the ADC value in hex. |- | ads mean [COUNT] | Get the mean of power of 2 COUNT ADC values in hex. |- | fuse | Display current fuse settings |- |} == [[ASK]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | ask 1527 HOUSECODE COMMAND DELAY CNT | |- | ask 2272 HOUSECODE COMMAND [DELAY] [CNT] [SYNC] | |- | ask fa20rf DEVICE [REPEAT] | |- | ask intertechno FAMILY GROUP DEVICE COMMAND | "Send Command to Intertechno switches (with coding wheel). FAMILY: A=1, ..." |- | ask itsl HOUSECODE COMMAND BUTTON [DIM] | "Send Command to Intertechno Self learning switches and dimmers. DIM works only with dimmers and values 0-15." |- | ask oase FAMILY GROUP DEVICE COMMAND | |- | ask tevion HOUSECODE COMMAND DELAY CNT | |- |} == [[Am_Puls_der_Zeit|Clock]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | date | Print the current date. |- | lastdcf | Print when last valid DCF signal was received. |- | time [UNIXTIME] | Display/Set the current time in seconds since January 1st 1970. |- | uptime | Display ethersex uptime in unix format. |- | whm | Display ethersex uptime. |- |} == [[Application_Sample]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sample | Manually call application sample commands |- | sample_init | Manually call application sample init method |- | sample_periodic | Manually call application sample periodic method |- |} == [[BSBPORT]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | bsbport get P1 P2 P3 P4 SRC TYPE | Show specific message currently in buffer format value as TYPE type is one of RAW STA TMP FP1 FP5 |- | bsbport list | List all messages currently in buffer output in RAW TMP FP1 FP5 |- | bsbport query P1 P2 P3 P4 [DEST] | Send Message to query for a value DEST is optional defaults to 0 |- | bsbport set P1 P2 P3 P4 DEST TYPE VALUE | Send Message to set value type is one of RAW SEL TMP FP1 FP5 |- | bsbport stats | Report statistic counters OK/CRC/Lenght under/Lenght over/Droped/Buffer/BufferNet/Retransmit |- |} == [[Blinkenlights_MCUF|MCUF]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | mcuf modul N | Select module N |- | mcuf modul list | List all modules |- | mcuf showclock | Show digital clock |- | mcuf showstring MESSAGE | Show scrolling MESSAGE on the display |- |} == [[CRC]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | adc get [CHANNEL] | Get the ADC value in hex of CHANNEL or if no channel set of all channels. |- | adc vget [CHANNEL] | Get the ADC value in volt of CHANNEL or if no channel set of all channels. |- | adc vref [VOLTAGE] | Get/Set ADC reference voltage calibration. |- | crc calc | "read the ethersex program code and calc a crc16 of it" |- | crc read | "read out the crc16 value at the end of the program space" |- | hr20 temp | Read HR20 temperature sensor. |- |} == [[CRON-Dienst]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | cron add MIN HOUR DAY MONTH DOW ECMD | Add ECMD to cron to be executed at given time |- | cron anacron POSITION [STATE] | show/set job anacron state |- | cron list | Show all cron entries |- | cron persistent POSITION [STATE] | show/set job persistance state |- | cron rm [POSITION] | Remove one cron entry |- | cron save | Saves all persistent jobs |- | cron utc POSITION [STATE] | show/set utc state |- |} == [[DALI]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dali cmd [TARGET] [COMMAND] [!][?] | "send the given command (decimal) to targets (all, g00 to g15, s00 to s63), auto repeat with !, read reply with ?" |- | dali dim [TARGET] [LEVEL] | "dim targets (all, g00 to g15, s00 to s63) to given level (0-254)" |- | dali raw [BYTE1] [BYTE2] | "send a raw frame (two bytes, given in hex) over the DALI bus" |- | dali scmd [SPECIAL COMMAND] [DATA] [!][?] | "send special command (256-287) with data, auto repeat with !, read reply with ?" |- |} == [[DHT]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dht humid [SENSORNUMBER] | Return humidity of DHT sensor |- | dht list | Return a list of mapped sensor names |- | dht temp [SENSORNUMBER] | Return temperature of DHT sensor |- |} == [[DMX_FXSlot]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx fxslot devices | set the device settings |- | dmx fxslot effect | set the effect settings |- | dmx fxslot reset | reset all fxslots and clear saved ones in EEPROM |- | dmx fxslot restore | restore the settings from EEPROM |- | dmx fxslot save | save the current fxslots to EEPROM |- |} == [[DMX_Storage]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx channels | Get channels per universe |- | dmx get | Return channel value |- | dmx set | Set channel values |- | dmx universe | Get a whole universe |- | dmx universes | Get universes |- |} == [[Dallas_1-wire_Bus]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | 1w convert DEVICE | Trigger temperature conversion of either DEVICE or all connected devices |- | 1w ds2450 convert [DEVICE] | `start conversion (with optional input mask and read out control)' |- | 1w ds2450 get [DEVICE] | `get conversion result (one or all channels)' |- | 1w ds2450 oc [DEVICE] | `get/set output control (per channel)' |- | 1w ds2450 oe [DEVICE] | `get/set output enable (per channel)' |- | 1w ds2450 por [DEVICE] | `get/set power on reset (per channel)' |- | 1w ds2450 power [DEVICE] | `get/set power supply of device (global)' |- | 1w ds2450 range [DEVICE] | `get/set input voltage range (per channel)' |- | 1w ds2450 res [DEVICE] | `get/set bit resolution of AD convert (per channel)' |- | 1w get DEVICE | Return temperature value of onewire device (provide 64-bit ID as 16-hex-digits) |- | 1w list | Return a list of the connected onewire devices |- | 1w name clear ID | Delete a name mapping |- | 1w name list | Return a list of mapped device names |- | 1w name save | Save name mappings to EEPROM |- | 1w name set ID DEVICE NAME | Assign a name to/from an device address |- |} == [[DataFlash]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | df status | Display internal status. |- | fs format | Format the filesystem. |- | fs inspect inode INODE | Inspect INODE (and associated page). |- | fs inspect node NODE | Inspect NODE and dump to serial. |- | fs list | List the directory. |- | fs mkfile NAME | Create a new file NAME. |- | fs remove NAME | Delete the file NAME. |- | fs truncate NAME LEN | Truncate the file NAME to LEN bytes. |- |} == [[Dc3840_camera|DC3840 mobil camera support]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dc3840 capture | Take a picture. Access 'dc3840' via VFS afterwards. See [[DC3840 Camera]] for details. |- | dc3840 light | Light level of camera |- | dc3840 send A B C D E | Send provided command bytes to the camera. |- | dc3840 sync | Re-sync to the camera |- | dc3840 zoom | Enable zoom of camera |- |} == [[ECMDScript]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | call FILENAME | Start script named FILENAME |- | cat FILENAME | cat file content (with debug only) |- | dec VAR | Decrement variable VAR (a number) |- | echo <any> | Print out all arguments of echo |- | exit | Exit currently running script |- | get VAR | Get value of variable VAR |- | goto N | Goto line N in currently running script |- | if ( CMD/VAR == CONST ) then CMD2 | If condition matches execute CMD2 |- | inc VAR | Increment variable VAR (a number) |- | rem <any> | Remark for anything |- | set VAR VALUE | Set variable VAR to VALUE |- | wait I | Wait I milliseconds |- |} == [[FS20]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fht send HOUSECODE ADDR CMD [CMD2] | Send FHT command. See [[FS20]] for details. |- | fs20 receive | Receive FS20/FHT sequence and display it. |- | fs20 send HOUSECODE ADDR CMD [CMD2] | Send FS20 command. See [[FS20]] for details. |- | fs20 ws300 | Receive FS20 sequence from WS300 weather station and decode it. |- |} == [[Frequency Counter]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fc %duty [CHANNEL] | "returns last on duty cycle in percent for given channel" |- | fc duty [CHANNEL] | "returns last on duty cycle (0-255) for given channel" |- | fc freq [CHANNEL] | "returns last frequency in Hz for given channel" |- | fc off [CHANNEL] | "switch off frequency counting on given channel" |- | fc on [CHANNEL] | "switch on frequency counting on given channel" |- | fc ticks [CHANNEL] | "returns last frequency in CPU ticks for given channel" |- |} == [[GLCD_Menu]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | glcdmenu key VALUE | Send a keypress to the menu |- | glcdmenu update | Update the menu |- |} == [[GPS]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | nmea get | Get latitude and longitude data |- | nmea satellites | Get satellites |- |} == [[H-Bridge]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | hbridge [action] [enable_l] [enable_r] | Set H-Bridge command |- | hbridge pwm int | Set H-Bridge enable line valueeg. speed |- |} == [[I2C]] (TWI) == {| border='1' | ''Command syntax'' | ''Short description'' |- | bmp085 apress | Get absolute pressure in Pa |- | bmp085 height PRESSNN | Get height in cm, pressure at N0 needed |- | bmp085 pressnn HEIGHT | Get pressure at N0, height in cm needed |- | bmp085 temp | Get temperature in 0.1°C |- | ds1631 convert ADDR VALUE | Initiate temperature conversions (0: stop, 1: convert) |- | ds1631 temp ADDR | Read last converted temperature |- | ee dir | List files in I2C EEPROM. |- | ee rm PATH | Remove file PATH. |- | i2c detect | list detected I2C Chips |- | i2c pca9555 in | read word from register address on I2C chip |- | i2c pca9555 mode VALUE | select input or output mode for pins on I2C chip |- | i2c pca9555 out VALUE | write word to register address on I2C chip |- | i2c rbb ADDR | read byte from I2C chip |- | i2c rbd CHIPADDR REGADDR | read byte from register address at I2C chip |- | i2c rwd CHIPADDR REGADDR | read word from register address at I2C chip |- | i2c wbb ADDR HEXVALUE | write byte to I2C chip |- | i2c wbd CHIPADDR REGADDR HEXVALUE | write byte to register address on I2C chip |- | i2c wwd CHIPADDR REGADDR HEXVALUE | write word to register address on I2C chip |- | lm75 ADDR | Get temperature |- | max7311 getDDRw ADDR | Get Direction-Register DDR |- | max7311 getINw ADDR | Get Input-Register IN |- | max7311 getOUTw ADDR | Get Output-Register OUT |- | max7311 pulse ADDR BIT TIME | Toggle Output-BIT for TIME (in ms) |- | max7311 set ADDR BIT VALUE | Set Output-BIT to VALUE (bool) |- | max7311 setDDRw ADDR VALUE | Set Direction-Register DDR (VALUE as hex) |- | max7311 setOUTw ADDR VALUE | Set Output-Register OUT (VALUE as hex) |- | mcp23017 clear pin ADDR PORT BIT | Clear Port BIT for PORT A or B |- | mcp23017 get iodir ADDR PORT | Get I/O Direction Register for PORT A or B |- | mcp23017 get olat ADDR PORT | Get Output Latch Register for PORT A or B |- | mcp23017 get port ADDR PORT | Get Port Register (i.e. Port Pin State) for PORT A or B |- | mcp23017 getreg ADDR REGADDR | Get Register REGADDR |- | mcp23017 pulse pin ADDR PORT BIT TIME | Toggle-Pulse Port BIT for PORT A or B for TIME ms |- | mcp23017 set iodir ADDR PORT VALUE | Set I/O Direction Register for PORT A or B (VALUE as hex) |- | mcp23017 set olat ADDR PORT VALUE | Set Output Latch Register for PORT A or B (VALUE as hex) |- | mcp23017 set pin ADDR PORT BIT | Set Port BIT for PORT A or B |- | mcp23017 setreg ADDR REGADDR VALUE | Set Register REGADDR (VALUE as hex) |- | mcp23017 toggle pin ADDR PORT BIT | Toggle Port BIT for PORT A or B |- | pca9531 ADDR PERIODPWM1 DUTYPWM1 PERIODPWM2 DUTYPWM2 LED0..3 LED4..7 | set PWM1 and PWM2 and LED states |- | pcf8574x read ADDR CHIP | Get bits |- | pcf8574x set ADDR CHIP HEXVALUE | Set bits |- | tmp175 ADDR | Get temperature |- | tsl2550 lux | Show light level by reading adc registers and computing level |- | tsl2550 mode VALUE | Set the TSL2550s operating mode (0: standard range, 1: extended range) |- | tsl2550 power VALUE | Set the TSL2550s power state (0: down, 1:up) |- | tsl2561 lux DEVNUM | Get LUX value |- | tsl2561 raw DEVNUM | Get RAW channel values |- | tsl2561 setmode DEVNUM TIME GAIN PACKAGE | Set device mode |- |} == [[Jabber]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | jabber_host [HOSTNAME] | JABBER hostname |- | jabber_pass [PASSWORD] | JABBER password |- | jabber_resrc [RESOURCE] | JABBER resource |- | jabber_user [USERNAME] | JABBER username |- |} == [[KTY]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | kty autocalibrate CHANNEL | Calibrate to 1000 Ohm precision Resistor. |- | kty cal get | Return the calibration difference to 2k2 Resistor. |- | kty get [CHANNEL] | Get the temperature in xxx.x °C of CHANNEL or if no channel set of all channels. |- |} == [[MotorCurtain]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | curtain VALUE | Set value of curtain. 0=closed..7=open. If you use fewer sensors, use the corrent value instead of 7. |- | curtainlast | Return last known position |- | curtainmax | Return maximum position |- | curtainoff | Switch motor off |- |} == [[Named_PIN]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | pin get NAME | Read and display the status of pin NAME. |- | pin list | List all known named-pins. |- | pin set NAME STATUS | Set the status of pin NAME to STATUS. |- | pin toggle NAME | Toggle the status of pin NAME. |- |} == [[PWM]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dtmf CHARS | send CHARS as DTMF |- | freq set FREQUENCY DELAY | Set frequency for DELAY ms |- | pwm fade [channel +-diff startvalue] | Set fading at channel with startvalue and change each stepp to diff (must be signed 3 digit) |- | pwm set [channel value] | Set channel to value |- |} == [[RFM12]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | rfm12 reinit | Re-initialize the RFM12 FSK module. |- | rfm12 setbandwidth MODULE BW | Set receiver bandwidth of MODULE to BW. |- | rfm12 setbaud MODULE BAUD | Set baudrate of MODULE to BAUD. |- | rfm12 setdrssi MODULE DRSSI | Set the drssi of MODULE to DRSSI. |- | rfm12 setgain MODULE GAIN | Set preamplifier gain of MODULE to GAIN. |- | rfm12 setmod MOD | Set modulation of the RFM12 FSK module to MOD. |- | rfm12 status MODULE | Display internal status of MODULE. |- |} == [[RFM12_ASK]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | rfm12 ask sense | Trigger (Tevion) ASK sensing. Enable ext. filter pin before! |- | rfm12 external filter [1] | Enable ext. filter pin if argument is present (disable otherwise) |- |} == [[RFM12_FS20]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fht send | housecode addr command data |- | fs20 receive | Receive FS20/FHT sequence and display it. |- | fs20 send | housecode addr command data |- | fs20 setdebug DEBUG | Set debug to DEBUG. |- |} == [[SD-Karte]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sd dir | List contents of current SD directory. |- | sd info | List information about SD card. |- | sd mkdir PATH | Create directory hierarchy PATH. |- | sd rm PATH | Remove file PATH. |- |} == [[SGC]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | sgc adduc ADDR CH0 CH1 CH2 CH3 CH4 CH5 CH6 CH7 | Add user character: address 0..0x1F and 8 bytes character |- | sgc circle X Y RADIUS | Draw circle with parameters and colour specified in sgc_colour |- | sgc cls | Clear screen |- | sgc colour RED GREEN BLUE | Set pen / font colour:red-green-blue 0..0x1F or 2-byte RGB with only two parameters |- | sgc contrast CONTRAST | Set contrast value 0..0x0F |- | sgc druc ADDR X Y | Draw user character saved from sgc_adduc at address 0..0x1F and with colour specified in sgc_colour |- | sgc font FONT PROPORTIONAL | Set font type:0..2 and 0:not proportional 1:proportional |- | sgc gchar X Y WIDTH HEIGHT CHAR | Draw ASCII character in graphics format at specified position and size with colour specified in sgc_colour |- | sgc getpwr | Get Power Status |- | sgc line X1 Y1 X2 Y2 | Draw line between specified points with colour specified in sgc_colour |- | sgc object UMSB ULSB LMSB LLSB | Display object from SD card at specified address |- | sgc onoff ONOFF | Turn display on:1 or off:0 |- | sgc opacity OPACITY | Set text opacity 0:transparent 1:opaque |- | sgc pensize PENSIZE | Set pen size 0:solid 1:lines |- | sgc pixel X Y | Draw pixel at specified point with colour specified in sgc_colour |- | sgc rectangle X1 Y1 X2 Y2 | Draw rectangle with specified edges and with colour specified in sgc_colour |- | sgc repbgc RED GREEN BLUE | Replace background colour:red-green-blue 0..0x1F or 2-byte RGB with only two parameters |- | sgc repcol X_START Y_START X_END Y_END OLD_RED OLD_GREEN OLD_BLUE | Replace old colour - red-green-blue 0..0x1F or 2-byte RGB with only two parameters in selected area - with colour specified in sgc_colour |- | sgc result | Get result from last command |- | sgc scrcp SRC_X SRC_Y DST_X DST_Y WIDTH HEIGHT | Copy-Paste selected screen area |- | sgc script UMSB ULSB LMSB LLSB | Run 4DSL script from SD card at specified address |- | sgc sdicon X Y WIDTH HEIGHT SECTOR0 SECTOR1 SECTOR2 | Display icon from SD card at specified position and size stored at specified SD card sector |- | sgc setbgc RED GREEN BLUE | Set background colour:red-green-blue 0..0x1F or 2-byte RGB with only two parameters |- | sgc setip IPADDR | Change response IP address - volatile |- | sgc setpwr PWR | Set Power Status: 1:on 0:off |- | sgc setsleep AUTO MODE | Set Auto Shutdown Sleep 1:on 0:off / Set wakeup mode 0:Serial 1: Joystick |- | sgc settimeout TIMEOUT | Change auto-off idle time - volatile |- | sgc sleep SLEEP | Sleep mode 0:turn off SD 1:wake on serial 2:wake on joystick |- | sgc stg X Y WIDTH HEIGHT STRING | Draw ASCII string in graphics format at specified position and size with colour specified in sgc_colour) |- | sgc stt COL ROW STRING | Draw ASCII string in text format at specified col and row and with colour specified in sgc_colour |- | sgc tchar COL ROW CHAR | Draw ASCII character in text format at specified col and row and with colour specified in sgc_colour |- | sgc triangle X1 Y1 X2 Y2 X3 Y3 | Draw triangle with edges counter-clockwise and with colour specified in sgc_colour |- | sgc video X Y WIDTH HEIGHT DELAY NUM_FRAMES0 NUM_FRAMES1 SECTOR0 SECTOR1 SECTOR2 | Display video / animation from SD card at specified position and size and with specified inter-frame delay and frame number stored at specified SD card sector |- |} == [[SHT]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sht humid | Return humidity of SHT sensor |- | sht raw | Return raw hex temp (first line) and humidity value (second line) of SHT sensor |- | sht temp | Return temperature of SHT sensor |- |} == [[SMS77]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sms77 MESSAGE | Send MESSAGE to compiled in sms77 service |- | sms77_pass [PASSWORD] | SMS77 password |- | sms77_recv [RECEIVER] | SMS receiver |- | sms77_type [TYPE] | SMS type |- | sms77_user [USERNAME] | SMS77 username |- |} == [[Servo_Ansteuerung|PWM Servo Control]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | pwm servo_dec SERVONR | Decrement position of servo SERVONR |- | pwm servo_inc SERVONR | Increment position of servo SERVONR |- | pwm servo_set SERVONR POSITION | Set servo with SERVONR to POSITION |- |} == [[Sound]]/WAV support == {| border='1' | ''Command syntax'' | ''Short description'' |- | pwm stop | Stop wav |- | pwm wav <FILENAME> | Play wave file. Use VFS if compiled in. More details at [[Sound]] |- |} == [[Stella_Light]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | channel CHANNEL VALUE FUNCTION | Get/Set stella channel to value. Second and third parameters are optional. Function: You may use 's' for instant set, 'f' for fade and 'y' for flashy fade. |- | channels | Return stella channel size |- | fadestep FADESTEP | Get/Set stella fade step |- | stella load | Load values from eeprom |- | stella store | Store values in eeprom |- | tank get | get last value |- | tank param save | write tank parameter to EEPROM |- | tank param set PARAM VALUE | set tank parameter |- | tank param show | show tanklevel parameters |- | tank start | start measure |- | tank zero | probe sensor zero offset |- |} == [[USB]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | keyboard MESSAGE | Send MESSAGE as HID keyboard |- | mouse BUTTON DELTAX DELTAY | Send data as HID mouse |- |} == [[ZACwire]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | zac 306 PORT BIT | Return temperature of TSic 306 at BIT of PORT |- | zac 506 PORT BIT | Return temperature of TSic 506 at BIT of PORT |- | zac raw PORT BIT | Return raw hex temperature value of zacwire at BIT of PORT |- |} == lome6 == {| border='1' | ''Command syntax'' | ''Short description'' |- | lome6 get_t TYPE | get temperature command |- | lome6 power TYPE | press power command |- | lome6 reset | press reset command |- | lome6 set_t TYPE TEMPERATURE | set temperature command |- | lome6 state | get state command |- | lome6 uptime UPTIME | set/get uptime command |- |} == Miscelleanous == {| border='1' | ''Command syntax'' | ''Short description'' |- | alias list | List all available aliases |- | artnet test | artnet test |- | cw send MESSAGE | Send MESSAGE in Morce Code |- | d ADDR | Dump the memory at ADDR (16 bytes). |- | eeprom reinit | Force reinitialization of the EEPROM config area |- | ems stats | Report statistic counters |- | free | Display free space. |- | help | List which commands are available. |- | ht MESSAGE | Send MESSAGE to compiled in httplog service |- | ipstats | Display IP statistics. |- | mb recv | Receive data from modbus |- | moodlight CHANNEL ONOFF | Set CHANNEL moodlight on=1 or off=0. If no channel is given return on if channel CHANNEL is moodlighted |- | motd [MESSAGE] | Save MESSAGE as new message of the day, otherwise just show current message |- | msr1 get | Get data |- | mysql query QUERY | Send specified MySQL query to the configured server |- | ns | update net statistic for public anouncment of currently running ethersex |- | pam USER PASSWORD | Use pam for user and password |- | push NUMBER | Push button identified by NUMBER |- | pwm melody [NUMBER] | Play melody |- | sanyoz700 CMD | Send command to projector |- | sll get | Request the logged data |- | sram memtest | Perform a memory test |- | srf05 | Read SRF05 measurement |- | to1 get | Request data from sensor |- | tw MESSAGE | Send MESSAGE to compiled in twitter service |- | upnp send | Manually send UPnP broadcast packet |- | usart baud BAUD | Set the USART baudrate to BAUD. |- | version | Display the version number. |- | weather | Get eltako weather data |- | wol MAC | Send WAKE-ON-LAN command to MAC |- | yport stats | Report statistic counters |- | zbus stats | Report statistic counters |- |} [[Category:Ethersex]] [[Category:ECMD]] b470a44457db30830471755b1e829a9df729af33 0 319 1738 1548 2016-12-04T19:59:34Z Michaelb 718 /* Hardware Drivers */ wikitext text/x-wiki {{i18n|Features}} == Supported Network Hardware == * Ethernet [[ENC28J60 | Microchip's ENC28J60]] with IEEE 802.1q VLAN tagging * [[USB]] * [[RFM12]] * [[ZBUS]] == Network Protocols == * IPv4, IPv4 * TCP/IP, UDP/IP and ICMP * DNS * mDNS (Avahi) * [[BOOTP]] * [[DHCP]] * TFTP (can be used in combination with the [[Ethernet Loader]]) * SYSLOG * [[SNMP]] * SMTP * [[NTP]] (Client and Server) * DynDNS * MySQL (Client) * IRC (Client) * [[XMPP | XMPP / Jabber Client]] * MPD (Music Player Daemon) * [[SOAP]] / XMLRPC * [[UPnP]] * [[Artnet]] == Hardware Drivers == * [[Onewire]] * [[I2C | I2C Master / Slave]] * [[ADC input]] * [[PWM Generator]] * [[RFM12_FS20]] * [[RFM12_ASK]] * [[Generic ASK Modules]] * [[Bluetooth|Bluetooth SPP]] * [[USB]] * [[PS/2 Keyboard]] * [[Button Input]] * [[HC595]] * [[HC165]] * [[HD44780 | alphanumeric LCD]] * [[IRMP | IR Receivers]] * [[SRAM]] == Software Modules == * [[Ethersex Lighting Architecture]] ** [[Starburst]] ** [[StellaLight]] ** [[DMX Storage]] ** [[DMX FXSlot]] * [[Cron | Cron Daemon]] * [[System Clock | Clock ]] * [[VNC Server]] * [[lome6]] * [[Frequency Counter]] 2b56ceae57e276125843baf2bc61a8a3e648223c 1739 1738 2016-12-04T19:59:56Z Michaelb 718 /* Hardware Drivers */ wikitext text/x-wiki {{i18n|Features}} == Supported Network Hardware == * Ethernet [[ENC28J60 | Microchip's ENC28J60]] with IEEE 802.1q VLAN tagging * [[USB]] * [[RFM12]] * [[ZBUS]] == Network Protocols == * IPv4, IPv4 * TCP/IP, UDP/IP and ICMP * DNS * mDNS (Avahi) * [[BOOTP]] * [[DHCP]] * TFTP (can be used in combination with the [[Ethernet Loader]]) * SYSLOG * [[SNMP]] * SMTP * [[NTP]] (Client and Server) * DynDNS * MySQL (Client) * IRC (Client) * [[XMPP | XMPP / Jabber Client]] * MPD (Music Player Daemon) * [[SOAP]] / XMLRPC * [[UPnP]] * [[Artnet]] == Hardware Drivers == * [[Onewire]] * [[I2C | I2C Master / Slave]] * [[ADC input]] * [[PWM Generator]] * [[RFM12_FS20]] * [[RFM12_ASK]] * [[Generic ASK Modules]] * [[Bluetooth|Bluetooth SPP]] * [[USB]] * [[PS/2 Keyboard]] * [[Button Input]] * [[HC595]] * [[HC165]] * [[HD44780]] * [[IRMP | IR Receivers]] * [[SRAM]] == Software Modules == * [[Ethersex Lighting Architecture]] ** [[Starburst]] ** [[StellaLight]] ** [[DMX Storage]] ** [[DMX FXSlot]] * [[Cron | Cron Daemon]] * [[System Clock | Clock ]] * [[VNC Server]] * [[lome6]] * [[Frequency Counter]] 801fbd3c0d1507ab5af508d3d42064f0ef73b9f6 1744 1739 2016-12-04T22:00:00Z Michaelb 718 /* Hardware Drivers */ wikitext text/x-wiki {{i18n|Features}} == Supported Network Hardware == * Ethernet [[ENC28J60 | Microchip's ENC28J60]] with IEEE 802.1q VLAN tagging * [[USB]] * [[RFM12]] * [[ZBUS]] == Network Protocols == * IPv4, IPv4 * TCP/IP, UDP/IP and ICMP * DNS * mDNS (Avahi) * [[BOOTP]] * [[DHCP]] * TFTP (can be used in combination with the [[Ethernet Loader]]) * SYSLOG * [[SNMP]] * SMTP * [[NTP]] (Client and Server) * DynDNS * MySQL (Client) * IRC (Client) * [[XMPP | XMPP / Jabber Client]] * MPD (Music Player Daemon) * [[SOAP]] / XMLRPC * [[UPnP]] * [[Artnet]] == Hardware Drivers == * [[Onewire]] * [[I2C | I2C Master / Slave]] * [[ADC input]] * [[PWM Generator]] * [[RFM12_FS20]] * [[RFM12_ASK]] * [[Generic ASK Modules]] * [[Bluetooth|Bluetooth SPP]] * [[USB]] * [[PS/2 Keyboard]] * [[Button Input]] * [[HC595]] * [[HC165]] * [[HD44780]] alphanumeric character LCDs * [[IRMP | IR Receivers]] * [[SRAM]] == Software Modules == * [[Ethersex Lighting Architecture]] ** [[Starburst]] ** [[StellaLight]] ** [[DMX Storage]] ** [[DMX FXSlot]] * [[Cron | Cron Daemon]] * [[System Clock | Clock ]] * [[VNC Server]] * [[lome6]] * [[Frequency Counter]] f8907ee0e28256a68a694aa75c24bd5748bab88b 0 558 1740 2016-12-04T21:44:54Z Michaelb 718 Created page with "{{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->HD44780 module driver (Character-LCD) |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |..." wikitext text/x-wiki {{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->HD44780 module driver (Character-LCD) |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/onewire https://github.com/ethersex/ethersex/tree/master/hardware/lcd] }} 9e769fd8391741b7f342538aa96c8c02c88d97a7 1741 1740 2016-12-04T21:45:25Z Michaelb 718 wikitext text/x-wiki {{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->HD44780 module driver (Character-LCD) |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/lcd https://github.com/ethersex/ethersex/tree/master/hardware/lcd] }} e8012759e7a055af7be4906c0e32c6c85ca6bbce 1742 1741 2016-12-04T21:52:54Z Michaelb 718 wikitext text/x-wiki {{i18n|HD44780}} {{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->HD44780 module driver (Character-LCD) |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/lcd https://github.com/ethersex/ethersex/tree/master/hardware/lcd] }} The HD44780 module provides support for common alphanumeric character LCDs using Hitachis HD44780 and compatible controllers. = Supported LC-Displays = = Pinning = = ECMD = 90ea046992ee920926daf7d6e13b6b9fb18a6b50 1743 1742 2016-12-04T21:58:25Z Michaelb 718 wikitext text/x-wiki {{i18n|HD44780}} {{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->HD44780 module driver (Character-LCD) |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/lcd https://github.com/ethersex/ethersex/tree/master/hardware/lcd] }} The HD44780 module provides support for common alphanumeric character LCDs using Hitachis HD44780 and compatible controllers. = Supported LC-Displays = = Pinning = == Direct == == I2C == == Serial (using 74HCT164) == == 2-Wire (using 74HCT4094) == = ECMD = 3b88b2e1a1435f23736591389d53aa95becccfbc 1746 1743 2016-12-04T22:04:21Z Michaelb 718 wikitext text/x-wiki {{i18n|HD44780}} {{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->HD44780 module driver (Character-LCD) |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/lcd https://github.com/ethersex/ethersex/tree/master/hardware/lcd] }} The HD44780 module provides support for common alphanumeric character LCDs using Hitachis HD44780 and compatible controllers. = Supported LC-Displays = = Pinning = == Direct == == I2C == === using PCF8574x === <pre> -/* - * HD44780-Display über PCF8574 ansteuern. - * Belegung Pollin Add-On-Board: - * - * Pin PCF8574 Pin am LCD - * 4 (P0) -> 11 (DB4) - * 5 (P1) -> 12 (DB5) - * 6 (P2) -> 13 (DB6) - * 7 (P3) -> 14 (DB7) - * 9 (P4) -> 4 (RS) - * 10 (P5) -> 5 (R/W) nicht benutzt ! - * 11 (P6) -> 6 (EN) - * 12 (P7) -> 15 (Beleuchtung) - * - * Die LCD-Beleuchtung an Pin 12 wird über einen - * PNP-Transistor geschaltet. - * Beleuchtung an: Bit 7=0 - * Beleuchtung aus: Bit 7=1 - * Die Address-Eingänge A0 bis A2 des PCF8574 liegen alle auf GND. - * Die Basis-Addresse des Chips ist daher immer 0x20. - */ - </pre> Pinning: <pre> ifelse(value_HD44780_CONNECTION,`HD44780_I2CSUPPORT',`dnl dnl HD44780_PCF8574x_MAPPING(ADR,RS,RW,EN,DB4,DB5,DB6,DB7,BL) HD44780_PCF8574x_MAPPING(0x20, 4, 5, 6, 0, 1, 2, 3, 7) ')dnl </pre> === using MCP23017 === == Serial (using 74HCT164) == == 2-Wire (using 74HCT4094) == = ECMD = b47cf7978890012b64350c7ff3cf6d62c0e049fd 1747 1746 2016-12-04T22:07:33Z Michaelb 718 wikitext text/x-wiki {{i18n|HD44780}} {{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->HD44780 module driver (Character-LCD) |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/lcd https://github.com/ethersex/ethersex/tree/master/hardware/lcd] }} '''THIS WIKI PAGE IS CURRENTLY WORK IN PROGRESS''' The HD44780 module provides support for common alphanumeric character LCDs using Hitachis HD44780 and compatible controllers. = Supported LC-Displays = = Pinning = == Direct == == I2C == === using PCF8574x === <pre> -/* - * HD44780-Display über PCF8574 ansteuern. - * Belegung Pollin Add-On-Board: - * - * Pin PCF8574 Pin am LCD - * 4 (P0) -> 11 (DB4) - * 5 (P1) -> 12 (DB5) - * 6 (P2) -> 13 (DB6) - * 7 (P3) -> 14 (DB7) - * 9 (P4) -> 4 (RS) - * 10 (P5) -> 5 (R/W) nicht benutzt ! - * 11 (P6) -> 6 (EN) - * 12 (P7) -> 15 (Beleuchtung) - * - * Die LCD-Beleuchtung an Pin 12 wird über einen - * PNP-Transistor geschaltet. - * Beleuchtung an: Bit 7=0 - * Beleuchtung aus: Bit 7=1 - * Die Address-Eingänge A0 bis A2 des PCF8574 liegen alle auf GND. - * Die Basis-Addresse des Chips ist daher immer 0x20. - */ - </pre> Pinning: <pre> ifelse(value_HD44780_CONNECTION,`HD44780_I2CSUPPORT',`dnl dnl HD44780_PCF8574x_MAPPING(ADR,RS,RW,EN,DB4,DB5,DB6,DB7,BL) HD44780_PCF8574x_MAPPING(0x20, 4, 5, 6, 0, 1, 2, 3, 7) ')dnl </pre> === using MCP23017 === == Serial (using 74HCT164) == == 2-Wire (using 74HCT4094) == = ECMD = c77632da769252cd0bebe5624cf7db532bd6ab9d 1748 1747 2016-12-05T20:11:19Z Michaelb 718 wikitext text/x-wiki {{i18n|HD44780}} {{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->HD44780 module driver (Character-LCD) |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/lcd https://github.com/ethersex/ethersex/tree/master/hardware/lcd] }} '''THIS WIKI PAGE IS CURRENTLY WORK IN PROGRESS''' The HD44780 module provides support for common alphanumeric character LCDs using Hitachis HD44780 and compatible controllers. = Supported LC-Displays = = Pinning = == Direct == <pre> dnl Direct connection example dnl map LCD pins to Pollin AVR Net-IO dnl 25 pin extension port ifdef(`conf_HD44780', ` pin(HD44780_RS, PC4) pin(HD44780_RW, PC3) pin(HD44780_EN1, PC2) dnl pin(HD44780_EN2, PC5) pin(HD44780_D4, PA0) pin(HD44780_D5, PA1) pin(HD44780_D6, PA2) pin(HD44780_D7, PA3) ') ifdef(`conf_HD44780_BACKLIGHT', ` pin(HD44780_BL, PC6, OUTPUT) ') </pre> == I2C == === using PCF8574x === <pre> /* * HD44780-Display über PCF8574 ansteuern. * Belegung Pollin Add-On-Board: * * Pin PCF8574 Pin am LCD * 4 (P0) -> 11 (DB4) * 5 (P1) -> 12 (DB5) * 6 (P2) -> 13 (DB6) * 7 (P3) -> 14 (DB7) * 9 (P4) -> 4 (RS) * 10 (P5) -> 5 (R/W) nicht benutzt ! * 11 (P6) -> 6 (EN) * 12 (P7) -> 15 (Beleuchtung) * * Die LCD-Beleuchtung an Pin 12 wird über einen * PNP-Transistor geschaltet. * Beleuchtung an: Bit 7=0 * Beleuchtung aus: Bit 7=1 * Die Address-Eingänge A0 bis A2 des PCF8574 liegen alle auf GND. * Die Basis-Addresse des Chips ist daher immer 0x20. */ </pre> Pinning: <pre> ifelse(value_HD44780_CONNECTION,`HD44780_I2CSUPPORT',`dnl dnl HD44780_PCF8574x_MAPPING(ADR,RS,RW,EN,DB4,DB5,DB6,DB7,BL) HD44780_PCF8574x_MAPPING(0x20, 4, 5, 6, 0, 1, 2, 3, 7) ')dnl </pre> === using MCP23017 === == Serial (using 74HCT164) == == 2-Wire (using 74HCT4094) == = ECMD = 5fd1ab372002ec1fa5aa154c6e2a7b91c85533f0 1749 1748 2016-12-05T20:18:49Z Michaelb 718 wikitext text/x-wiki {{i18n|HD44780}} {{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->HD44780 module driver (Character-LCD) |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/lcd https://github.com/ethersex/ethersex/tree/master/hardware/lcd] }} '''THIS WIKI PAGE IS CURRENTLY WORK IN PROGRESS''' The HD44780 module provides support for common alphanumeric character LCDs using Hitachis HD44780 and compatible controllers. = Supported LC-Displays = = Pinning = == Direct == The following example maps the LCD pins to AVR port pins found on the 25 pin Sub-D connector of the Pollin AVR Net-IO board: <code> dnl Direct connection example dnl map LCD pins to Pollin AVR Net-IO dnl 25 pin extension port ifdef(`conf_HD44780', ` pin(HD44780_RS, PC4) pin(HD44780_RW, PC3) pin(HD44780_EN1, PC2) dnl pin(HD44780_EN2, PC5) pin(HD44780_D4, PA0) pin(HD44780_D5, PA1) pin(HD44780_D6, PA2) pin(HD44780_D7, PA3) ') ifdef(`conf_HD44780_BACKLIGHT', ` pin(HD44780_BL, PC6, OUTPUT) ') </code> == I2C == === using PCF8574x === <pre> /* * HD44780-Display über PCF8574 ansteuern. * Belegung Pollin Add-On-Board: * * Pin PCF8574 Pin am LCD * 4 (P0) -> 11 (DB4) * 5 (P1) -> 12 (DB5) * 6 (P2) -> 13 (DB6) * 7 (P3) -> 14 (DB7) * 9 (P4) -> 4 (RS) * 10 (P5) -> 5 (R/W) nicht benutzt ! * 11 (P6) -> 6 (EN) * 12 (P7) -> 15 (Beleuchtung) * * Die LCD-Beleuchtung an Pin 12 wird über einen * PNP-Transistor geschaltet. * Beleuchtung an: Bit 7=0 * Beleuchtung aus: Bit 7=1 * Die Address-Eingänge A0 bis A2 des PCF8574 liegen alle auf GND. * Die Basis-Addresse des Chips ist daher immer 0x20. */ </pre> Pinning: <code> ifelse(value_HD44780_CONNECTION,`HD44780_I2CSUPPORT',`dnl dnl HD44780_PCF8574x_MAPPING(ADR,RS,RW,EN,DB4,DB5,DB6,DB7,BL) HD44780_PCF8574x_MAPPING(0x20, 4, 5, 6, 0, 1, 2, 3, 7) ')dnl </code> === using MCP23017 === == Serial (using 74HCT164) == == 2-Wire (using 74HCT4094) == = ECMD = 98ceffc666d3704d32c54c21743100b4c621ed63 1750 1749 2016-12-06T20:09:25Z Michaelb 718 wikitext text/x-wiki {{i18n|HD44780}} {{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->HD44780 module driver (Character-LCD) |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/lcd https://github.com/ethersex/ethersex/tree/master/hardware/lcd] }} '''THIS WIKI PAGE IS CURRENTLY WORK IN PROGRESS''' The HD44780 module provides support for common alphanumeric character LCDs using Hitachis HD44780 and compatible controllers. = Supported LC-Displays = = Pinning = == Direct == The following example maps the LCD pins to AVR port pins found on the 25 pin Sub-D connector of the Pollin AVR Net-IO board: <code> dnl Direct connection example dnl map LCD pins to Pollin AVR Net-IO dnl 25 pin extension port ifdef(`conf_HD44780', ` pin(HD44780_RS, PC4) pin(HD44780_RW, PC3) pin(HD44780_EN1, PC2) dnl pin(HD44780_EN2, PC5) pin(HD44780_D4, PA0) pin(HD44780_D5, PA1) pin(HD44780_D6, PA2) pin(HD44780_D7, PA3) ') ifdef(`conf_HD44780_BACKLIGHT', ` pin(HD44780_BL, PC6, OUTPUT) ') </code> == I2C == <pre> /* * HD44780-Display über PCF8574 ansteuern. * Belegung Pollin Add-On-Board: * * Pin PCF8574 Pin am LCD * 4 (P0) -> 11 (DB4) * 5 (P1) -> 12 (DB5) * 6 (P2) -> 13 (DB6) * 7 (P3) -> 14 (DB7) * 9 (P4) -> 4 (RS) * 10 (P5) -> 5 (R/W) nicht benutzt ! * 11 (P6) -> 6 (EN) * 12 (P7) -> 15 (Beleuchtung) * * Die LCD-Beleuchtung an Pin 12 wird über einen * PNP-Transistor geschaltet. * Beleuchtung an: Bit 7=0 * Beleuchtung aus: Bit 7=1 * Die Address-Eingänge A0 bis A2 des PCF8574 liegen alle auf GND. * Die Basis-Addresse des Chips ist daher immer 0x20. */ </pre> Pinning: <code> ifelse(value_HD44780_CONNECTION,`HD44780_I2CSUPPORT',`dnl ifelse(value_HD44780_I2C_PORTEXP,`HD44780_I2C_PCF8574', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_PCF8574x_MULTI_MAPPING(ADR, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_PCF8574x_MULTI_MAPPING(0x20, 4, 5, 6, 7, 0, 1, 2, 3)', `dnl dnl HD44780_PCF8574x_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_PCF8574x_MAPPING(0x20, 4, 5, 6, 0, 1, 2, 3, 7)')', value_HD44780_I2C_PORTEXP,`HD44780_I2C_MCP23017', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_MCP23017_MULTI_MAPPING(ADR, PORT, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_MCP23017_MULTI_MAPPING(0x24, B, 4, 5, 6, 7, 0, 1, 2, 3) HD44780_MCP23017_MULTI_MAPPING_BL(0x24, A, 7)', `dnl dnl HD44780_MCP23017_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_MCP23017_MAPPING(0x24, B, 4, 5, 6, 0, 1, 2, 3, 7)')' )dnl ')dnl </code> == Serial (using 74HCT164) == == 2-Wire (using 74HCT4094) == = ECMD = 3a6b912e88a94b758c79a7797103746137a2d87e 1751 1750 2016-12-07T20:32:51Z Michaelb 718 wikitext text/x-wiki {{i18n|HD44780}} {{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->HD44780 module driver (Character-LCD) |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/lcd https://github.com/ethersex/ethersex/tree/master/hardware/lcd] }} '''THIS WIKI PAGE IS CURRENTLY WORK IN PROGRESS''' The HD44780 module provides support for common alphanumeric character LCDs using Hitachis HD44780 and compatible controllers. = Supported LC-Displays = The vast majority of all alphanumeric LC-Displays use Hitachis [https://en.wikipedia.org/wiki/Hitachi_HD44780_LCD_controller HD44780] dot matrix liquid crystal display (LCD) controller. The e6 HD44780 module supports displays of many different sizes utilizing the original HD44780 and compatible controllers. Alphanumeric LCDs are distinguished by their size, the start-address of the per line Display Data-RAM (DDRAM) and the controller type. The original HD44780 controllers can drive up to 80 characters, most displays with more characters simply use two controllers. The following table lists the LC-displays supported by the e6 HD44780 module by size and per line DDRAM start-address: {| class="wikitable" !colspan="1"|Menuconfig !colspan="2"|Size !colspan="4"|DDRAM Startaddress !rowspan="2"|Note: |- !LCD size/type||Characters||Lines||Line 1||Line 2||Line 3||Line 4 |- |8_Characters_1_Line||8||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line||16||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line_Mux16||16||1||0x00||n/a||n/a||n/a||organized as 8 chars, 2 lines |- |20_Characters_1_Line||20||1||0x00||n/a||n/a||n/a|| |- |40_Characters_1_Line||40||1||0x00||n/a||n/a||n/a|| |- |8_Characters_2_Lines||8||2||0x00||0x40||n/a||n/a|| |- |12_Characters_2_Lines||12||2||0x00||0x40||n/a||n/a|| |- |16_Characters_2_Lines||16||2||0x00||0x40||n/a||n/a|| |- |20_Characters_2_Lines||20||2||0x00||0x40||n/a||n/a|| |- |24_Characters_2_Lines||24||2||0x00||0x40||n/a||n/a|| |- |40_Characters_2_Lines||40||2||0x00||0x40||n/a||n/a|| |- |16_Characters_4_Lines||16||4||0x00||0x40||0x10||0x50|| |- |20_Characters_4_Lines||20||4||0x00||0x40||0x14||0x54||Note DDRAM addresses |- |20_Characters_4_Lines_KS0073||20||4||0x00||0x20||0x40||0x60||Note DDRAM addresses |- |27_Characters_4_Lines_2_EN||27||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |- |40_Characters_4_Lines_2_EN||40||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |} = Pinning = == Direct == The following example maps the LCD pins to AVR port pins found on the 25 pin Sub-D connector of the Pollin AVR Net-IO board: <code> dnl Direct connection example dnl map LCD pins to Pollin AVR Net-IO dnl 25 pin extension port ifdef(`conf_HD44780', ` pin(HD44780_RS, PC4) pin(HD44780_RW, PC3) pin(HD44780_EN1, PC2) dnl pin(HD44780_EN2, PC5) pin(HD44780_D4, PA0) pin(HD44780_D5, PA1) pin(HD44780_D6, PA2) pin(HD44780_D7, PA3) ') ifdef(`conf_HD44780_BACKLIGHT', ` pin(HD44780_BL, PC6, OUTPUT) ') </code> == I2C == <pre> /* * HD44780-Display über PCF8574 ansteuern. * Belegung Pollin Add-On-Board: * * Pin PCF8574 Pin am LCD * 4 (P0) -> 11 (DB4) * 5 (P1) -> 12 (DB5) * 6 (P2) -> 13 (DB6) * 7 (P3) -> 14 (DB7) * 9 (P4) -> 4 (RS) * 10 (P5) -> 5 (R/W) nicht benutzt ! * 11 (P6) -> 6 (EN) * 12 (P7) -> 15 (Beleuchtung) * * Die LCD-Beleuchtung an Pin 12 wird über einen * PNP-Transistor geschaltet. * Beleuchtung an: Bit 7=0 * Beleuchtung aus: Bit 7=1 * Die Address-Eingänge A0 bis A2 des PCF8574 liegen alle auf GND. * Die Basis-Addresse des Chips ist daher immer 0x20. */ </pre> Pinning: <code> ifelse(value_HD44780_CONNECTION,`HD44780_I2CSUPPORT',`dnl ifelse(value_HD44780_I2C_PORTEXP,`HD44780_I2C_PCF8574', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_PCF8574x_MULTI_MAPPING(ADR, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_PCF8574x_MULTI_MAPPING(0x20, 4, 5, 6, 7, 0, 1, 2, 3)', `dnl dnl HD44780_PCF8574x_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_PCF8574x_MAPPING(0x20, 4, 5, 6, 0, 1, 2, 3, 7)')', value_HD44780_I2C_PORTEXP,`HD44780_I2C_MCP23017', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_MCP23017_MULTI_MAPPING(ADR, PORT, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_MCP23017_MULTI_MAPPING(0x24, B, 4, 5, 6, 7, 0, 1, 2, 3) HD44780_MCP23017_MULTI_MAPPING_BL(0x24, A, 7)', `dnl dnl HD44780_MCP23017_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_MCP23017_MAPPING(0x24, B, 4, 5, 6, 0, 1, 2, 3, 7)')' )dnl ')dnl </code> == Serial (using 74HCT164) == == 2-Wire (using 74HCT4094) == = ECMD = 0f318c2a03100b8a1aff716004468bd4889f595a 1752 1751 2016-12-07T20:34:29Z Michaelb 718 wikitext text/x-wiki {{i18n|HD44780}} {{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->HD44780 module driver (Character-LCD) |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/lcd https://github.com/ethersex/ethersex/tree/master/hardware/lcd] }} '''THIS WIKI PAGE IS CURRENTLY WORK IN PROGRESS''' The HD44780 module provides support for common alphanumeric character LCDs using Hitachis HD44780 and compatible controllers. = Supported LC-Displays = The vast majority of all alphanumeric LC-Displays use Hitachis [https://en.wikipedia.org/wiki/Hitachi_HD44780_LCD_controller HD44780] dot matrix liquid crystal display (LCD) controller. The e6 HD44780 module supports displays of many different sizes utilizing the original HD44780 and compatible controllers. Alphanumeric LCDs are distinguished by their size, the start-address of the per line Display Data-RAM (DDRAM) and the controller type. The original HD44780 controllers can drive up to 80 characters - most displays with more characters use two independent controllers. The following table lists the LC-displays supported by the e6 HD44780 module by size and per line DDRAM start-address: {| class="wikitable" !colspan="1"|Menuconfig !colspan="2"|Size !colspan="4"|DDRAM Startaddress !rowspan="2"|Note: |- !LCD size/type||Characters||Lines||Line 1||Line 2||Line 3||Line 4 |- |8_Characters_1_Line||8||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line||16||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line_Mux16||16||1||0x00||n/a||n/a||n/a||organized as 8 chars, 2 lines |- |20_Characters_1_Line||20||1||0x00||n/a||n/a||n/a|| |- |40_Characters_1_Line||40||1||0x00||n/a||n/a||n/a|| |- |8_Characters_2_Lines||8||2||0x00||0x40||n/a||n/a|| |- |12_Characters_2_Lines||12||2||0x00||0x40||n/a||n/a|| |- |16_Characters_2_Lines||16||2||0x00||0x40||n/a||n/a|| |- |20_Characters_2_Lines||20||2||0x00||0x40||n/a||n/a|| |- |24_Characters_2_Lines||24||2||0x00||0x40||n/a||n/a|| |- |40_Characters_2_Lines||40||2||0x00||0x40||n/a||n/a|| |- |16_Characters_4_Lines||16||4||0x00||0x40||0x10||0x50|| |- |20_Characters_4_Lines||20||4||0x00||0x40||0x14||0x54||Note DDRAM addresses |- |20_Characters_4_Lines_KS0073||20||4||0x00||0x20||0x40||0x60||Note DDRAM addresses |- |27_Characters_4_Lines_2_EN||27||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |- |40_Characters_4_Lines_2_EN||40||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |} = Pinning = == Direct == The following example maps the LCD pins to AVR port pins found on the 25 pin Sub-D connector of the Pollin AVR Net-IO board: <code> dnl Direct connection example dnl map LCD pins to Pollin AVR Net-IO dnl 25 pin extension port ifdef(`conf_HD44780', ` pin(HD44780_RS, PC4) pin(HD44780_RW, PC3) pin(HD44780_EN1, PC2) dnl pin(HD44780_EN2, PC5) pin(HD44780_D4, PA0) pin(HD44780_D5, PA1) pin(HD44780_D6, PA2) pin(HD44780_D7, PA3) ') ifdef(`conf_HD44780_BACKLIGHT', ` pin(HD44780_BL, PC6, OUTPUT) ') </code> == I2C == <pre> /* * HD44780-Display über PCF8574 ansteuern. * Belegung Pollin Add-On-Board: * * Pin PCF8574 Pin am LCD * 4 (P0) -> 11 (DB4) * 5 (P1) -> 12 (DB5) * 6 (P2) -> 13 (DB6) * 7 (P3) -> 14 (DB7) * 9 (P4) -> 4 (RS) * 10 (P5) -> 5 (R/W) nicht benutzt ! * 11 (P6) -> 6 (EN) * 12 (P7) -> 15 (Beleuchtung) * * Die LCD-Beleuchtung an Pin 12 wird über einen * PNP-Transistor geschaltet. * Beleuchtung an: Bit 7=0 * Beleuchtung aus: Bit 7=1 * Die Address-Eingänge A0 bis A2 des PCF8574 liegen alle auf GND. * Die Basis-Addresse des Chips ist daher immer 0x20. */ </pre> Pinning: <code> ifelse(value_HD44780_CONNECTION,`HD44780_I2CSUPPORT',`dnl ifelse(value_HD44780_I2C_PORTEXP,`HD44780_I2C_PCF8574', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_PCF8574x_MULTI_MAPPING(ADR, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_PCF8574x_MULTI_MAPPING(0x20, 4, 5, 6, 7, 0, 1, 2, 3)', `dnl dnl HD44780_PCF8574x_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_PCF8574x_MAPPING(0x20, 4, 5, 6, 0, 1, 2, 3, 7)')', value_HD44780_I2C_PORTEXP,`HD44780_I2C_MCP23017', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_MCP23017_MULTI_MAPPING(ADR, PORT, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_MCP23017_MULTI_MAPPING(0x24, B, 4, 5, 6, 7, 0, 1, 2, 3) HD44780_MCP23017_MULTI_MAPPING_BL(0x24, A, 7)', `dnl dnl HD44780_MCP23017_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_MCP23017_MAPPING(0x24, B, 4, 5, 6, 0, 1, 2, 3, 7)')' )dnl ')dnl </code> == Serial (using 74HCT164) == == 2-Wire (using 74HCT4094) == = ECMD = ee855d6375cd097f7167c42ed27c60276c1b0839 1753 1752 2016-12-07T20:40:21Z Michaelb 718 wikitext text/x-wiki {{i18n|HD44780}} {{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->HD44780 module driver (Character-LCD) |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/lcd https://github.com/ethersex/ethersex/tree/master/hardware/lcd] }} '''THIS WIKI PAGE IS CURRENTLY WORK IN PROGRESS''' The '''HD44780 module''' provides support for common '''alphanumeric character LCDs''' using Hitachis HD44780 and compatible controllers. = Supported LC-Displays = The vast majority of all alphanumeric LC-Displays use Hitachis [https://en.wikipedia.org/wiki/Hitachi_HD44780_LCD_controller HD44780] dot matrix liquid crystal display (LCD) controller. The e6 HD44780 module supports displays of many different sizes utilizing the original HD44780 and compatible controllers. Alphanumeric LCDs are distinguished by their size, the start-address of the per line Display Data-RAM (DDRAM) and the controller type. The original HD44780 controllers can drive up to 80 characters - most displays with more characters use two independent controllers. The following table lists the LC-displays supported by the e6 HD44780 module by size and per line DDRAM start-address: {| class="wikitable" !colspan="1"|Menuconfig !colspan="2"|Size !colspan="4"|DDRAM Startaddress !rowspan="2"|Note: |- !LCD size/type||Characters||Lines||Line 1||Line 2||Line 3||Line 4 |- |8_Characters_1_Line||8||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line||16||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line_Mux16||16||1||0x00||n/a||n/a||n/a||organized as 8 chars, 2 lines |- |20_Characters_1_Line||20||1||0x00||n/a||n/a||n/a|| |- |40_Characters_1_Line||40||1||0x00||n/a||n/a||n/a|| |- |8_Characters_2_Lines||8||2||0x00||0x40||n/a||n/a|| |- |12_Characters_2_Lines||12||2||0x00||0x40||n/a||n/a|| |- |16_Characters_2_Lines||16||2||0x00||0x40||n/a||n/a|| |- |20_Characters_2_Lines||20||2||0x00||0x40||n/a||n/a|| |- |24_Characters_2_Lines||24||2||0x00||0x40||n/a||n/a|| |- |40_Characters_2_Lines||40||2||0x00||0x40||n/a||n/a|| |- |16_Characters_4_Lines||16||4||0x00||0x40||0x10||0x50|| |- |20_Characters_4_Lines||20||4||0x00||0x40||0x14||0x54||Note DDRAM addresses |- |20_Characters_4_Lines_KS0073||20||4||0x00||0x20||0x40||0x60||Note DDRAM addresses |- |27_Characters_4_Lines_2_EN||27||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |- |40_Characters_4_Lines_2_EN||40||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |} '''Note:''' The HD44780 module drivers supports '''alphanumeric character LCDs''' only. Ethersex also has limited support for some graphical displays. Have a look at the LCD Display configuration. = Pinning = == Direct == The following example maps the LCD pins to AVR port pins found on the 25 pin Sub-D connector of the Pollin AVR Net-IO board: <code> dnl Direct connection example dnl map LCD pins to Pollin AVR Net-IO dnl 25 pin extension port ifdef(`conf_HD44780', ` pin(HD44780_RS, PC4) pin(HD44780_RW, PC3) pin(HD44780_EN1, PC2) dnl pin(HD44780_EN2, PC5) pin(HD44780_D4, PA0) pin(HD44780_D5, PA1) pin(HD44780_D6, PA2) pin(HD44780_D7, PA3) ') ifdef(`conf_HD44780_BACKLIGHT', ` pin(HD44780_BL, PC6, OUTPUT) ') </code> == I2C == <pre> /* * HD44780-Display über PCF8574 ansteuern. * Belegung Pollin Add-On-Board: * * Pin PCF8574 Pin am LCD * 4 (P0) -> 11 (DB4) * 5 (P1) -> 12 (DB5) * 6 (P2) -> 13 (DB6) * 7 (P3) -> 14 (DB7) * 9 (P4) -> 4 (RS) * 10 (P5) -> 5 (R/W) nicht benutzt ! * 11 (P6) -> 6 (EN) * 12 (P7) -> 15 (Beleuchtung) * * Die LCD-Beleuchtung an Pin 12 wird über einen * PNP-Transistor geschaltet. * Beleuchtung an: Bit 7=0 * Beleuchtung aus: Bit 7=1 * Die Address-Eingänge A0 bis A2 des PCF8574 liegen alle auf GND. * Die Basis-Addresse des Chips ist daher immer 0x20. */ </pre> Pinning: <code> ifelse(value_HD44780_CONNECTION,`HD44780_I2CSUPPORT',`dnl ifelse(value_HD44780_I2C_PORTEXP,`HD44780_I2C_PCF8574', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_PCF8574x_MULTI_MAPPING(ADR, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_PCF8574x_MULTI_MAPPING(0x20, 4, 5, 6, 7, 0, 1, 2, 3)', `dnl dnl HD44780_PCF8574x_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_PCF8574x_MAPPING(0x20, 4, 5, 6, 0, 1, 2, 3, 7)')', value_HD44780_I2C_PORTEXP,`HD44780_I2C_MCP23017', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_MCP23017_MULTI_MAPPING(ADR, PORT, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_MCP23017_MULTI_MAPPING(0x24, B, 4, 5, 6, 7, 0, 1, 2, 3) HD44780_MCP23017_MULTI_MAPPING_BL(0x24, A, 7)', `dnl dnl HD44780_MCP23017_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_MCP23017_MAPPING(0x24, B, 4, 5, 6, 0, 1, 2, 3, 7)')' )dnl ')dnl </code> == Serial (using 74HCT164) == == 2-Wire (using 74HCT4094) == = ECMD = eb7efa8d92e1ebb149cefe046795103c1a320202 1754 1753 2016-12-07T21:17:45Z Michaelb 718 wikitext text/x-wiki {{i18n|HD44780}} {{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->HD44780 module driver (Character-LCD) |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/lcd https://github.com/ethersex/ethersex/tree/master/hardware/lcd] }} '''THIS WIKI PAGE IS CURRENTLY WORK IN PROGRESS''' The '''HD44780 module''' provides support for common '''alphanumeric character LCDs''' using Hitachis HD44780 and compatible controllers. = Supported LC-Displays = The vast majority of all alphanumeric LC-Displays use Hitachis [https://en.wikipedia.org/wiki/Hitachi_HD44780_LCD_controller HD44780] dot matrix liquid crystal display (LCD) controller. The e6 HD44780 module supports displays of many different sizes utilizing the original HD44780 and compatible controllers. Alphanumeric LCDs are mainly distinguished by their size, the start-address of the per line Display Data-RAM (DDRAM) and the controller type. The original HD44780 controllers can drive up to 80 characters - most displays with more characters use two independent controllers. The following table lists the LC-displays supported by the e6 HD44780 module by size and per line DDRAM start-address: {| class="wikitable" !colspan="1"|Menuconfig !colspan="2"|Size !colspan="4"|DDRAM Startaddress !rowspan="2"|Note: |- !LCD size/type||Characters||Lines||Line 1||Line 2||Line 3||Line 4 |- |8_Characters_1_Line||8||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line||16||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line_Mux16||16||1||0x00||n/a||n/a||n/a||organized as 8 chars, 2 lines |- |20_Characters_1_Line||20||1||0x00||n/a||n/a||n/a|| |- |40_Characters_1_Line||40||1||0x00||n/a||n/a||n/a|| |- |8_Characters_2_Lines||8||2||0x00||0x40||n/a||n/a|| |- |12_Characters_2_Lines||12||2||0x00||0x40||n/a||n/a|| |- |16_Characters_2_Lines||16||2||0x00||0x40||n/a||n/a|| |- |20_Characters_2_Lines||20||2||0x00||0x40||n/a||n/a|| |- |24_Characters_2_Lines||24||2||0x00||0x40||n/a||n/a|| |- |40_Characters_2_Lines||40||2||0x00||0x40||n/a||n/a|| |- |16_Characters_4_Lines||16||4||0x00||0x40||0x10||0x50|| |- |20_Characters_4_Lines||20||4||0x00||0x40||0x14||0x54||Note DDRAM addresses |- |20_Characters_4_Lines_KS0073||20||4||0x00||0x20||0x40||0x60||Note DDRAM addresses |- |27_Characters_4_Lines_2_EN||27||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |- |40_Characters_4_Lines_2_EN||40||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |} '''Note:''' The HD44780 module drivers supports '''alphanumeric character LCDs''' only. Ethersex also has limited support for some graphical displays. Have a look at the LC-Display configuration. = Configuration = Although it is technically possible to connect more than one display, the HD44780 module supports only one LC-Display at a time. ... │ │ Network ---> │ │ I/O ---> ... │ │ ADC / DAC ---> │ │ LCD Displays ---> ... │ │ [*] HD44780 module driver (Character-LCD) ---> │ │ [-] HR20-style LCD Display ... │ │ (16_Characters_2_Lines) LCD size/type │ │ (HD44780_Compat) LCD controller type │ │ (None) LCD charset conversion │ │ (I2C) Connection type │ │ (PCF8574) I2C Port Expander │ │ [*] Readback support │ │ [*] Backlight support │ │ [*] Backlight on at power-on │ │ [*] Invert Backlight switch === Configuration options: === ;LCD size/type : Select one of the defined display sizes and address configurations shown in the table above. ;LCD controller type : Select LCD controller circuit: : :* HD44780_Compat - most controllers are compatible to Hitachis HD44780 :* KS0066U - Samsungs KS0066U requires a different init routine : : Almost all controllers for alphanumeric character LCDs are more or less HD44780-compatible at least at the feature- and function- level required by e6. : : If in doubt, choose HD44780_Compat. ;LCD charset conversion : Select charset conversion used while writing to the lcd: : :* None - use no charset conversion at all (safes program mem) :* HD44780_Compat - map characters from ISO8859-1 to the original HD44780 charset : : Allmost all controllers use their own non-ISO-compatible charset, varying between manufacturers, rom versions, etc. that provides characters from western languages as well as japanese, chinese and graphical glyphs. : : Charset conversion might become useful if you have to display messages and texts from external resources that uses standard encodings for their charset like ISO8859-1. : : '''Note:''' Charset conversion uses a lookup table and requires about 272 byte program memory (flash rom). ;Connection type : Select the connection type for the LCD: : :* Direct - direct connection using avr io-pins :* I2C - uses sub-selection of I2C port expander :* SER_LCD(74hct164) - serial connection using HCT164 shift register :* 2WIRE(74hct4094) - serial connection using HCT4094 shift register : : See section [[#Pinning]] below for further explanations. : ;I2C Port Expander : Select I2C Port Expander to use: : :* PCF8574 - use PCF8574x as I2C port expander :* MCP23017 - use MCP23017 as I2C port expander : : Note: automatically enables I2C_MASTER_SUPPORT and I2C_PCF8574X_SUPPORT resp. I2C_MCP23017_SUPPORT when selected. : : Note: Selection is only valid when '''I2C''' was selected under '''Connection type'''. : See section [[#Pinning]] below for further explanations. ;Readback support : Enable support for bi-directional lcd bus to read LCDs busy flag. Supported by direct and I2C connection only. : : '''You definitly should use a readback capable hardware and enable this feature''', saves lots of delays. ;Backlight support : Backlight support for LCDs based on the HD44780 controller. : : Enable backlight on/off control via API and ECMD. ;Backlight on at power-on : Switch on backlight at power-on/reset. ;Invert Backlight switch : Invert backlight logic for low active backlight circuits e.g. found on Pollin AVR NET-IO Add-on. = Pinning = == Direct == The following example maps the LCD pins to AVR port pins found on the 25 pin Sub-D connector of the Pollin AVR Net-IO board: <code> dnl Direct connection example dnl map LCD pins to Pollin AVR Net-IO dnl 25 pin extension port ifdef(`conf_HD44780', ` pin(HD44780_RS, PC4) pin(HD44780_RW, PC3) pin(HD44780_EN1, PC2) dnl pin(HD44780_EN2, PC5) pin(HD44780_D4, PA0) pin(HD44780_D5, PA1) pin(HD44780_D6, PA2) pin(HD44780_D7, PA3) ') ifdef(`conf_HD44780_BACKLIGHT', ` pin(HD44780_BL, PC6, OUTPUT) ') </code> == I2C == <pre> /* * HD44780-Display über PCF8574 ansteuern. * Belegung Pollin Add-On-Board: * * Pin PCF8574 Pin am LCD * 4 (P0) -> 11 (DB4) * 5 (P1) -> 12 (DB5) * 6 (P2) -> 13 (DB6) * 7 (P3) -> 14 (DB7) * 9 (P4) -> 4 (RS) * 10 (P5) -> 5 (R/W) nicht benutzt ! * 11 (P6) -> 6 (EN) * 12 (P7) -> 15 (Beleuchtung) * * Die LCD-Beleuchtung an Pin 12 wird über einen * PNP-Transistor geschaltet. * Beleuchtung an: Bit 7=0 * Beleuchtung aus: Bit 7=1 * Die Address-Eingänge A0 bis A2 des PCF8574 liegen alle auf GND. * Die Basis-Addresse des Chips ist daher immer 0x20. */ </pre> Pinning: <code> ifelse(value_HD44780_CONNECTION,`HD44780_I2CSUPPORT',`dnl ifelse(value_HD44780_I2C_PORTEXP,`HD44780_I2C_PCF8574', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_PCF8574x_MULTI_MAPPING(ADR, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_PCF8574x_MULTI_MAPPING(0x20, 4, 5, 6, 7, 0, 1, 2, 3)', `dnl dnl HD44780_PCF8574x_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_PCF8574x_MAPPING(0x20, 4, 5, 6, 0, 1, 2, 3, 7)')', value_HD44780_I2C_PORTEXP,`HD44780_I2C_MCP23017', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_MCP23017_MULTI_MAPPING(ADR, PORT, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_MCP23017_MULTI_MAPPING(0x24, B, 4, 5, 6, 7, 0, 1, 2, 3) HD44780_MCP23017_MULTI_MAPPING_BL(0x24, A, 7)', `dnl dnl HD44780_MCP23017_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_MCP23017_MAPPING(0x24, B, 4, 5, 6, 0, 1, 2, 3, 7)')' )dnl ')dnl </code> == Serial (using 74HCT164) == == 2-Wire (using 74HCT4094) == = ECMD = f79ded70317dedc9e19412e4e3480cf39ca7f39d 0 145 1745 1341 2016-12-04T22:01:43Z Michaelb 718 /* 74HC164 als Ausgangserweiterung */ wikitext text/x-wiki {{i18n|Porterweiterungen}} ==Porterweiterungen== Wenn am AVR schon viele Erweiterungen angeschlossen sind und die freien Ports langsam zur Neige gehen, kann man mit Schieberegistern arbeiten. Zwei dieser Bausteine sind bereits in der SW vorgesehen und können per menuconfig freigeschaltet werden. === 74HC165 als Eingangserweiterung === Der 74HC165 ist ein 8-bit Parallel-in/Seriell-out Schieberegister. Das kann man z.B. dazu benutzen um mehrere Schalteingänge seriell abzufragen. So könnte man z.B. 8 Taster mit nur 3 Leitungen abfragen und spart in diesem Fall 5 Portleitungen. Diese Schaltung ist kaskadierbar, so daß weitere Eingänge abgefragt werden können ohne mehr Portleitungen zu benötigen. ==== Anschluss ==== <pre> HC165_DATA: QH (erster 74HC165) HC165_CLOCK: CLOCK (alle) HC165_LOAD: Shift/Load (alle) GND: Clock Inhibit SERIAL INPUT: QH (zweiter 74HC165) </pre> Schaltbild siehe bei [http://www.mikrocontroller.net/articles/Porterweiterung_mit_SPI#Eing.C3.A4nge www.mikrocontroller.net] ==== Konfiguration ==== │ │ I/O ---> ... │ │ [*] HC165 input expansion ---> ... │ │ [ ] Inverse output │ │ (1) Number of HC165 registers In der bei "Hardware/Periphery Class" ausgewählten .m4-Datei muss angegeben werden, wo der erste 74HC165 angeschlossen ist, z.B.: <pre> pin(HC165_DATA, PC3) pin(HC165_CLOCK, PC4) pin(HC165_LOAD, PC5) </pre> ==== ECMD ==== {| border=1 | '''Syntax''' | '''Kurze Beschreibung''' |- | io get pin NUM | Liefert als Rückgabewert den Hexadezimalwert vom 74HC165. Pin 4 ist der erste, Pin 5 der zweite etc. |- |} === 74HC595 als Ausgangserweiterung === Der 74HC595 ist ein 8-bit Seriell-in/Parallel-out Schieberegister mit Latch. Das Latch braucht man, damit beim seriellen reinschieben der Bits diese nicht nacheinander an den Ausgängen erscheinen, sondern erst wenn das ganze Datenwort reingeschoben ist. Der 74HC595 ist sogar kaskadierbar, d.h. man kann theoretisch beliebig viele Ausgänge realisieren, ohne weitere Portleitungen zu benötigen. ==== Anschluss ==== <pre> HC595_DATA: Serial Data Input (SI) (erster 74HC595) HC595_CLOCK: SCK (an alle) HC595_STORE: RCK (an alle) QH* bzw. Q7*: Serial Data Input (SI) (zweiter 74HC595) </pre> [[File:Hc595_example.png|thumb|Schaltbild 74HC595]] Weitere Informationen siehe bei [http://www.mikrocontroller.net/articles/Porterweiterung_mit_SPI#Ausg.C3.A4nge www.mikrocontroller.net] ==== Konfiguration ==== │ │ I/O ---> ... │ │ [*] HC595 output expansion ---> ... │ │ (1) Number of HC595 registers In der bei "Hardware/Periphery Class" ausgewählten .m4-Datei muss angegeben werden, wo der erste 74HC595 angeschlossen ist, z.B.: <pre> pin(HC595_DATA, PC0) pin(HC595_CLOCK, PC1) pin(HC595_STORE, PC2) </pre> ==== ECMD ==== {| border=1 | '''Syntax''' | '''Kurze Beschreibung''' |- | io set port NUM HEXVALUE [MASK] | Setzt Port NUM auf den Wert HEXVALUE (ggf. wird die angegebene MASK verwendet). Port 4 ist der erste, Port 5 der zweite 74HC595 etc. |- |} Hinweis zur Portnummer: Die internen Ports (IO_HARD_PORTS) werden soweit vorhanden von 0 .. n nummeriert. Beim ATMega8 also 0..2 ( B,C,D ). Die Porterweiterungen belegen die darauf folgenden Nummern; beim m8 also ab 3. ECMD funktioniert mit den Porterweiterungen '''NUR WENN''' beim Konfigurieren ( make menuconfig ) unter I/O als "I/O abstraction model" '''Full-featured''' aktiviert wurde. === 74HC164 als Ausgangserweiterung === Der 74HC164 ist ein 8-bit Seriell-in/Parallel-out Schieberegister. Das kann man z.B. dazu benutzen um ein handelsübliches LCD mit HD44780-Controller mit nur 3 Leitungen anzusteuern (bei direkter Ansteuerung würden 7 Portleitungen benötigt), so wird das bei U. Radig's Webserver gemacht.<br> In diesem Fall wird kein Latch benötigt, da das LCD erst beim Schalten seiner "E"-Leitung (enable) die Daten aus dem Schieberegister übernimmt. Schaltbild siehe bei [http://www.ulrichradig.de/home/index.php/software/avr-webserver-software AVR Webserver Software] { ''menuconfig todo'' } { ''pinning todo'' } ==D/A-Wandler mit LTC1257== Der LTC1257 ist ein 12bit Digital-Analog-Wandler mit seriellem Eingang und interner Referenzspannung. Zur Steuerung benötigt er lediglich 3 Portleitungen. Da er laut [http://cds.linear.com/docs/Datasheet/1257fb.pdf Datenblatt] mindestens 4,75 Volt Versorgungsspannung braucht, ist er nicht in Systemen mit 3,3 Volt einsetzbar. === Anschluss === Für eine einfache Form der Anbindung siehe Schaltbild. [[File:LTC1257.png|thumb|Schaltbild LTC1257]] === Konfiguration === │ │ I/O ---> ... │ │ [*] digital-to-analog converter (DAC) ---> ... │ │ [*] LTC1257 Output │ │ (4) LTC1257: Maximum number of devices Das nötige Pinning ist für AVR-NET-IO bereits vorhanden, in der Zuordnung <pre> pin(LTC1257_CLK, PA2, OUTPUT) pin(LTC1257_DATA, PA1, OUTPUT) pin(LTC1257_LOAD, PA0, OUTPUT) </pre> Mit <code>ltc1257_init</code> werden die Portleitungen passend initialisiert (lt. Datenblatt). Mit <code>ltc1257_delay</code> kann die interne Wartezeit in µs gesetzt werden, die zum Erkennen des Flankenwechsels durch den DAC beim Schreiben eines Bits gewartet wird (ist vor allem hilfreich, wenn der LTC1257 über Optopkoppler (z.B. CNY17) entkoppelt ist). Mit <code>ltc1257_set</code> werden die tatsächlichen Werte gesetzt, die der LTC1257 dann als Analogsignal ausgibt. Bei der Verwendung von mehreren LTC1257 im Daisy Chain muss die Reihenfolge der Werte für <code>ltc1257_set</code> in der <b>umgekehrten</b> Reihenfolge der DACs gesendet werden (d.h. das erste Argument ist für den letzten DAC). [[Category:Ethersex]] [[Category:Hardware]] 34a133f8126b7cfd6b7323b65a4c9c133955c613 0 558 1755 1754 2016-12-07T21:18:43Z Michaelb 718 wikitext text/x-wiki {{i18n|HD44780}} {{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->HD44780 module driver (Character-LCD) |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/lcd https://github.com/ethersex/ethersex/tree/master/hardware/lcd] }} '''THIS WIKI PAGE IS CURRENTLY WORK IN PROGRESS''' The '''HD44780 module''' provides support for common '''alphanumeric character LCDs''' using Hitachis HD44780 and compatible controllers. = Supported LC-Displays = The vast majority of all alphanumeric LC-Displays use Hitachis [https://en.wikipedia.org/wiki/Hitachi_HD44780_LCD_controller HD44780] dot matrix liquid crystal display (LCD) controller. The e6 HD44780 module supports displays of many different sizes utilizing the original HD44780 and compatible controllers. Alphanumeric LCDs are mainly distinguished by their size, the start-address of the per line Display Data-RAM (DDRAM) and the controller type. The original HD44780 controllers can drive up to 80 characters - most displays with more characters use two independent controllers. The following table lists the LC-displays supported by the e6 HD44780 module by size and per line DDRAM start-address: {| class="wikitable" !colspan="1"|Menuconfig !colspan="2"|Size !colspan="4"|DDRAM Startaddress !rowspan="2"|Note: |- !LCD size/type||Characters||Lines||Line 1||Line 2||Line 3||Line 4 |- |8_Characters_1_Line||8||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line||16||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line_Mux16||16||1||0x00||n/a||n/a||n/a||organized as 8 chars, 2 lines |- |20_Characters_1_Line||20||1||0x00||n/a||n/a||n/a|| |- |40_Characters_1_Line||40||1||0x00||n/a||n/a||n/a|| |- |8_Characters_2_Lines||8||2||0x00||0x40||n/a||n/a|| |- |12_Characters_2_Lines||12||2||0x00||0x40||n/a||n/a|| |- |16_Characters_2_Lines||16||2||0x00||0x40||n/a||n/a|| |- |20_Characters_2_Lines||20||2||0x00||0x40||n/a||n/a|| |- |24_Characters_2_Lines||24||2||0x00||0x40||n/a||n/a|| |- |40_Characters_2_Lines||40||2||0x00||0x40||n/a||n/a|| |- |16_Characters_4_Lines||16||4||0x00||0x40||0x10||0x50|| |- |20_Characters_4_Lines||20||4||0x00||0x40||0x14||0x54||Note DDRAM addresses |- |20_Characters_4_Lines_KS0073||20||4||0x00||0x20||0x40||0x60||Note DDRAM addresses |- |27_Characters_4_Lines_2_EN||27||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |- |40_Characters_4_Lines_2_EN||40||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |} '''Note:''' The HD44780 module drivers supports '''alphanumeric character LCDs''' only. Ethersex also has limited support for some graphical displays. Have a look at the LC-Display configuration. = Configuration = Although it is technically possible to connect more than one display, the HD44780 module supports only one LC-Display at a time. ... │ │ Network ---> │ │ I/O ---> ... │ │ ADC / DAC ---> │ │ LCD Displays ---> ... │ │ [*] HD44780 module driver (Character-LCD) ---> │ │ [-] HR20-style LCD Display ... │ │ (16_Characters_2_Lines) LCD size/type │ │ (HD44780_Compat) LCD controller type │ │ (None) LCD charset conversion │ │ (I2C) Connection type │ │ (PCF8574) I2C Port Expander │ │ [*] Readback support │ │ [*] Backlight support │ │ [*] Backlight on at power-on │ │ [*] Invert Backlight switch === Configuration options: === ;LCD size/type : Select one of the defined display sizes and address configurations shown in the table above. ;LCD controller type : Select LCD controller circuit: : :* HD44780_Compat - most controllers are compatible to Hitachis HD44780 :* KS0066U - Samsungs KS0066U requires a different init routine : : Almost all controllers for alphanumeric character LCDs are more or less HD44780-compatible at least at the feature- and function- level required by e6. : : If in doubt, choose HD44780_Compat. ;LCD charset conversion : Select charset conversion used while writing to the lcd: : :* None - use no charset conversion at all (safes program mem) :* HD44780_Compat - map characters from ISO8859-1 to the original HD44780 charset : : Allmost all controllers use their own non-ISO-compatible charset, varying between manufacturers, rom versions, etc. that provides characters from western languages as well as japanese, chinese and graphical glyphs. : : Charset conversion might become useful if you have to display messages and texts from external resources that uses standard encodings for their charset like ISO8859-1. : : '''Note:''' Charset conversion uses a lookup table and requires about 272 byte program memory (flash rom). ;Connection type : Select the connection type for the LCD: : :* Direct - direct connection using avr io-pins :* I2C - uses sub-selection of I2C port expander :* SER_LCD(74hct164) - serial connection using HCT164 shift register :* 2WIRE(74hct4094) - serial connection using HCT4094 shift register : : See section [[#Pinning]] below for further explanations. : ;I2C Port Expander : Select I2C Port Expander to use: : :* PCF8574 - use PCF8574x as I2C port expander :* MCP23017 - use MCP23017 as I2C port expander : : Note: automatically enables I2C_MASTER_SUPPORT and I2C_PCF8574X_SUPPORT resp. I2C_MCP23017_SUPPORT when selected. : : Note: Selection is only valid when '''I2C''' was selected under '''Connection type'''. : See section [[#Pinning]] below for further explanations. ;Readback support : Enable support for bi-directional lcd bus to read LCDs busy flag. Supported by direct and I2C connection only. : : You '''definitly should use a readback capable hardware and enable this feature''', saves lots of delays. ;Backlight support : Backlight support for LCDs based on the HD44780 controller. : : Enable backlight on/off control via API and ECMD. ;Backlight on at power-on : Switch on backlight at power-on/reset. ;Invert Backlight switch : Invert backlight logic for low active backlight circuits e.g. found on Pollin AVR NET-IO Add-on. = Pinning = == Direct == The following example maps the LCD pins to AVR port pins found on the 25 pin Sub-D connector of the Pollin AVR Net-IO board: <code> dnl Direct connection example dnl map LCD pins to Pollin AVR Net-IO dnl 25 pin extension port ifdef(`conf_HD44780', ` pin(HD44780_RS, PC4) pin(HD44780_RW, PC3) pin(HD44780_EN1, PC2) dnl pin(HD44780_EN2, PC5) pin(HD44780_D4, PA0) pin(HD44780_D5, PA1) pin(HD44780_D6, PA2) pin(HD44780_D7, PA3) ') ifdef(`conf_HD44780_BACKLIGHT', ` pin(HD44780_BL, PC6, OUTPUT) ') </code> == I2C == <pre> /* * HD44780-Display über PCF8574 ansteuern. * Belegung Pollin Add-On-Board: * * Pin PCF8574 Pin am LCD * 4 (P0) -> 11 (DB4) * 5 (P1) -> 12 (DB5) * 6 (P2) -> 13 (DB6) * 7 (P3) -> 14 (DB7) * 9 (P4) -> 4 (RS) * 10 (P5) -> 5 (R/W) nicht benutzt ! * 11 (P6) -> 6 (EN) * 12 (P7) -> 15 (Beleuchtung) * * Die LCD-Beleuchtung an Pin 12 wird über einen * PNP-Transistor geschaltet. * Beleuchtung an: Bit 7=0 * Beleuchtung aus: Bit 7=1 * Die Address-Eingänge A0 bis A2 des PCF8574 liegen alle auf GND. * Die Basis-Addresse des Chips ist daher immer 0x20. */ </pre> Pinning: <code> ifelse(value_HD44780_CONNECTION,`HD44780_I2CSUPPORT',`dnl ifelse(value_HD44780_I2C_PORTEXP,`HD44780_I2C_PCF8574', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_PCF8574x_MULTI_MAPPING(ADR, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_PCF8574x_MULTI_MAPPING(0x20, 4, 5, 6, 7, 0, 1, 2, 3)', `dnl dnl HD44780_PCF8574x_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_PCF8574x_MAPPING(0x20, 4, 5, 6, 0, 1, 2, 3, 7)')', value_HD44780_I2C_PORTEXP,`HD44780_I2C_MCP23017', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_MCP23017_MULTI_MAPPING(ADR, PORT, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_MCP23017_MULTI_MAPPING(0x24, B, 4, 5, 6, 7, 0, 1, 2, 3) HD44780_MCP23017_MULTI_MAPPING_BL(0x24, A, 7)', `dnl dnl HD44780_MCP23017_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_MCP23017_MAPPING(0x24, B, 4, 5, 6, 0, 1, 2, 3, 7)')' )dnl ')dnl </code> == Serial (using 74HCT164) == == 2-Wire (using 74HCT4094) == = ECMD = d87e68e022408e6edfd90e9ae3f79d1847282f3b 1756 1755 2016-12-07T21:21:44Z Michaelb 718 /* Configuration */ wikitext text/x-wiki {{i18n|HD44780}} {{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->HD44780 module driver (Character-LCD) |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/lcd https://github.com/ethersex/ethersex/tree/master/hardware/lcd] }} '''THIS WIKI PAGE IS CURRENTLY WORK IN PROGRESS''' The '''HD44780 module''' provides support for common '''alphanumeric character LCDs''' using Hitachis HD44780 and compatible controllers. = Supported LC-Displays = The vast majority of all alphanumeric LC-Displays use Hitachis [https://en.wikipedia.org/wiki/Hitachi_HD44780_LCD_controller HD44780] dot matrix liquid crystal display (LCD) controller. The e6 HD44780 module supports displays of many different sizes utilizing the original HD44780 and compatible controllers. Alphanumeric LCDs are mainly distinguished by their size, the start-address of the per line Display Data-RAM (DDRAM) and the controller type. The original HD44780 controllers can drive up to 80 characters - most displays with more characters use two independent controllers. The following table lists the LC-displays supported by the e6 HD44780 module by size and per line DDRAM start-address: {| class="wikitable" !colspan="1"|Menuconfig !colspan="2"|Size !colspan="4"|DDRAM Startaddress !rowspan="2"|Note: |- !LCD size/type||Characters||Lines||Line 1||Line 2||Line 3||Line 4 |- |8_Characters_1_Line||8||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line||16||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line_Mux16||16||1||0x00||n/a||n/a||n/a||organized as 8 chars, 2 lines |- |20_Characters_1_Line||20||1||0x00||n/a||n/a||n/a|| |- |40_Characters_1_Line||40||1||0x00||n/a||n/a||n/a|| |- |8_Characters_2_Lines||8||2||0x00||0x40||n/a||n/a|| |- |12_Characters_2_Lines||12||2||0x00||0x40||n/a||n/a|| |- |16_Characters_2_Lines||16||2||0x00||0x40||n/a||n/a|| |- |20_Characters_2_Lines||20||2||0x00||0x40||n/a||n/a|| |- |24_Characters_2_Lines||24||2||0x00||0x40||n/a||n/a|| |- |40_Characters_2_Lines||40||2||0x00||0x40||n/a||n/a|| |- |16_Characters_4_Lines||16||4||0x00||0x40||0x10||0x50|| |- |20_Characters_4_Lines||20||4||0x00||0x40||0x14||0x54||Note DDRAM addresses |- |20_Characters_4_Lines_KS0073||20||4||0x00||0x20||0x40||0x60||Note DDRAM addresses |- |27_Characters_4_Lines_2_EN||27||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |- |40_Characters_4_Lines_2_EN||40||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |} '''Note:''' The HD44780 module drivers supports '''alphanumeric character LCDs''' only. Ethersex also has limited support for some graphical displays. Have a look at the LC-Display configuration. = Configuration = ... │ │ Network ---> │ │ I/O ---> ... │ │ ADC / DAC ---> │ │ LCD Displays ---> ... │ │ [*] HD44780 module driver (Character-LCD) ---> │ │ [-] HR20-style LCD Display ... │ │ (16_Characters_2_Lines) LCD size/type │ │ (HD44780_Compat) LCD controller type │ │ (None) LCD charset conversion │ │ (I2C) Connection type │ │ (PCF8574) I2C Port Expander │ │ [*] Readback support │ │ [*] Backlight support │ │ [*] Backlight on at power-on │ │ [*] Invert Backlight switch '''Configuration options:''' ;LCD size/type : Select one of the defined display sizes and address configurations shown in the table above. : : Although it is technically possible to connect more than one display, the HD44780 module supports only one LC-Display at a time. ;LCD controller type : Select LCD controller circuit: : :* HD44780_Compat - most controllers are compatible to Hitachis HD44780 :* KS0066U - Samsungs KS0066U requires a different init routine : : Almost all controllers for alphanumeric character LCDs are more or less HD44780-compatible at least at the feature- and function- level required by e6. : : If in doubt, choose HD44780_Compat. ;LCD charset conversion : Select charset conversion used while writing to the lcd: : :* None - use no charset conversion at all (safes program mem) :* HD44780_Compat - map characters from ISO8859-1 to the original HD44780 charset : : Allmost all controllers use their own non-ISO-compatible charset, varying between manufacturers, rom versions, etc. that provides characters from western languages as well as japanese, chinese and graphical glyphs. : : Charset conversion might become useful if you have to display messages and texts from external resources that uses standard encodings for their charset like ISO8859-1. : : Note: Charset conversion uses a lookup table and requires about 272 byte program memory (flash rom). ;Connection type : Select the connection type for the LCD: : :* Direct - direct connection using avr io-pins :* I2C - uses sub-selection of I2C port expander :* SER_LCD(74hct164) - serial connection using HCT164 shift register :* 2WIRE(74hct4094) - serial connection using HCT4094 shift register : : See section [[#Pinning]] below for further explanations. : ;I2C Port Expander : Select I2C Port Expander to use: : :* PCF8574 - use PCF8574x as I2C port expander :* MCP23017 - use MCP23017 as I2C port expander : : Note: automatically enables I2C_MASTER_SUPPORT and I2C_PCF8574X_SUPPORT resp. I2C_MCP23017_SUPPORT when selected. : : Note: Selection is only valid when '''I2C''' was selected under '''Connection type'''. : See section [[#Pinning]] below for further explanations. ;Readback support : Enable support for bi-directional lcd bus to read LCDs busy flag. Supported by direct and I2C connection only. : : You '''definitly should use a readback capable hardware and enable this feature''', saves lots of delays. ;Backlight support : Backlight support for LCDs based on the HD44780 controller. : : Enable backlight on/off control via API and ECMD. ;Backlight on at power-on : Switch on backlight at power-on/reset. ;Invert Backlight switch : Invert backlight logic for low active backlight circuits e.g. found on Pollin AVR NET-IO Add-on. = Pinning = == Direct == The following example maps the LCD pins to AVR port pins found on the 25 pin Sub-D connector of the Pollin AVR Net-IO board: <code> dnl Direct connection example dnl map LCD pins to Pollin AVR Net-IO dnl 25 pin extension port ifdef(`conf_HD44780', ` pin(HD44780_RS, PC4) pin(HD44780_RW, PC3) pin(HD44780_EN1, PC2) dnl pin(HD44780_EN2, PC5) pin(HD44780_D4, PA0) pin(HD44780_D5, PA1) pin(HD44780_D6, PA2) pin(HD44780_D7, PA3) ') ifdef(`conf_HD44780_BACKLIGHT', ` pin(HD44780_BL, PC6, OUTPUT) ') </code> == I2C == <pre> /* * HD44780-Display über PCF8574 ansteuern. * Belegung Pollin Add-On-Board: * * Pin PCF8574 Pin am LCD * 4 (P0) -> 11 (DB4) * 5 (P1) -> 12 (DB5) * 6 (P2) -> 13 (DB6) * 7 (P3) -> 14 (DB7) * 9 (P4) -> 4 (RS) * 10 (P5) -> 5 (R/W) nicht benutzt ! * 11 (P6) -> 6 (EN) * 12 (P7) -> 15 (Beleuchtung) * * Die LCD-Beleuchtung an Pin 12 wird über einen * PNP-Transistor geschaltet. * Beleuchtung an: Bit 7=0 * Beleuchtung aus: Bit 7=1 * Die Address-Eingänge A0 bis A2 des PCF8574 liegen alle auf GND. * Die Basis-Addresse des Chips ist daher immer 0x20. */ </pre> Pinning: <code> ifelse(value_HD44780_CONNECTION,`HD44780_I2CSUPPORT',`dnl ifelse(value_HD44780_I2C_PORTEXP,`HD44780_I2C_PCF8574', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_PCF8574x_MULTI_MAPPING(ADR, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_PCF8574x_MULTI_MAPPING(0x20, 4, 5, 6, 7, 0, 1, 2, 3)', `dnl dnl HD44780_PCF8574x_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_PCF8574x_MAPPING(0x20, 4, 5, 6, 0, 1, 2, 3, 7)')', value_HD44780_I2C_PORTEXP,`HD44780_I2C_MCP23017', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_MCP23017_MULTI_MAPPING(ADR, PORT, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_MCP23017_MULTI_MAPPING(0x24, B, 4, 5, 6, 7, 0, 1, 2, 3) HD44780_MCP23017_MULTI_MAPPING_BL(0x24, A, 7)', `dnl dnl HD44780_MCP23017_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_MCP23017_MAPPING(0x24, B, 4, 5, 6, 0, 1, 2, 3, 7)')' )dnl ')dnl </code> == Serial (using 74HCT164) == == 2-Wire (using 74HCT4094) == = ECMD = 636193323f8da54f27df2963f55cf24dda7b10bb 1757 1756 2016-12-07T21:24:02Z Michaelb 718 wikitext text/x-wiki {{i18n|HD44780}} {{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->HD44780 module driver (Character-LCD) |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/lcd https://github.com/ethersex/ethersex/tree/master/hardware/lcd] }} '''THIS WIKI PAGE IS CURRENTLY WORK IN PROGRESS''' The '''HD44780 module''' provides support for common '''alphanumeric character LCDs''' using Hitachis HD44780 and compatible controllers. = Supported LC-Displays = The vast majority of all alphanumeric LC-Displays use Hitachis [https://en.wikipedia.org/wiki/Hitachi_HD44780_LCD_controller HD44780] dot matrix liquid crystal display (LCD) controller. The e6 HD44780 module supports displays of many different sizes utilizing the original HD44780 and compatible controllers. Alphanumeric LCDs are mainly distinguished by their size, the start-address of the per line Display Data-RAM (DDRAM) and the controller type. The original HD44780 controllers can drive up to 80 characters - most displays with more characters use two independent controllers. The following table lists the LC-displays supported by the e6 HD44780 module by size and per line DDRAM start-address: {| class="wikitable" !colspan="1"|Menuconfig !colspan="2"|Size !colspan="4"|DDRAM Startaddress !rowspan="2"|Note: |- !LCD size/type||Characters||Lines||Line 1||Line 2||Line 3||Line 4 |- |8_Characters_1_Line||8||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line||16||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line_Mux16||16||1||0x00||n/a||n/a||n/a||organized as 8 chars, 2 lines |- |20_Characters_1_Line||20||1||0x00||n/a||n/a||n/a|| |- |40_Characters_1_Line||40||1||0x00||n/a||n/a||n/a|| |- |8_Characters_2_Lines||8||2||0x00||0x40||n/a||n/a|| |- |12_Characters_2_Lines||12||2||0x00||0x40||n/a||n/a|| |- |16_Characters_2_Lines||16||2||0x00||0x40||n/a||n/a|| |- |20_Characters_2_Lines||20||2||0x00||0x40||n/a||n/a|| |- |24_Characters_2_Lines||24||2||0x00||0x40||n/a||n/a|| |- |40_Characters_2_Lines||40||2||0x00||0x40||n/a||n/a|| |- |16_Characters_4_Lines||16||4||0x00||0x40||0x10||0x50|| |- |20_Characters_4_Lines||20||4||0x00||0x40||0x14||0x54||Note DDRAM addresses |- |20_Characters_4_Lines_KS0073||20||4||0x00||0x20||0x40||0x60||Note DDRAM addresses |- |27_Characters_4_Lines_2_EN||27||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |- |40_Characters_4_Lines_2_EN||40||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |} '''Note:''' The HD44780 module drivers supports '''alphanumeric character LCDs''' only. Ethersex also has limited support for some graphical displays. Have a look at the LC-Display configuration. = Configuration = ... │ │ Network ---> │ │ I/O ---> ... │ │ ADC / DAC ---> │ │ LCD Displays ---> ... │ │ [*] HD44780 module driver (Character-LCD) ---> │ │ [-] HR20-style LCD Display ... │ │ (16_Characters_2_Lines) LCD size/type │ │ (HD44780_Compat) LCD controller type │ │ (None) LCD charset conversion │ │ (I2C) Connection type │ │ (PCF8574) I2C Port Expander │ │ [*] Readback support │ │ [*] Backlight support │ │ [*] Backlight on at power-on │ │ [*] Invert Backlight switch '''Configuration options:''' ;LCD size/type : Select one of the defined display sizes and address configurations shown in the table [[#Supported LC-Displays]] above. : : Although it is technically possible to connect more than one display, the HD44780 module supports only one LC-Display at a time. ;LCD controller type : Select LCD controller circuit: : :* HD44780_Compat - most controllers are compatible to Hitachis HD44780 :* KS0066U - Samsungs KS0066U requires a different init routine : : Almost all controllers for alphanumeric character LCDs are more or less HD44780-compatible at least at the feature- and function- level required by e6. : : If in doubt, choose HD44780_Compat. ;LCD charset conversion : Select charset conversion used while writing to the lcd: : :* None - use no charset conversion at all (safes program mem) :* HD44780_Compat - map characters from ISO8859-1 to the original HD44780 charset : : Allmost all controllers use their own non-ISO-compatible charset, varying between manufacturers, rom versions, etc. that provides characters from western languages as well as japanese, chinese and graphical glyphs. : : Charset conversion might become useful if you have to display messages and texts from external resources that uses standard encodings for their charset like ISO8859-1. : : Note: Charset conversion uses a lookup table and requires about 272 byte program memory (flash rom). ;Connection type : Select the connection type for the LCD: : :* Direct - direct connection using avr io-pins :* I2C - uses sub-selection of I2C port expander :* SER_LCD(74hct164) - serial connection using HCT164 shift register :* 2WIRE(74hct4094) - serial connection using HCT4094 shift register : : See section [[#Pinning]] below for further explanations. : ;I2C Port Expander : Select I2C Port Expander to use: : :* PCF8574 - use PCF8574x as I2C port expander :* MCP23017 - use MCP23017 as I2C port expander : : Note: automatically enables I2C_MASTER_SUPPORT and I2C_PCF8574X_SUPPORT resp. I2C_MCP23017_SUPPORT when selected. : : Note: Selection is only valid when '''I2C''' was selected under '''Connection type'''. : See section [[#Pinning]] below for further explanations. ;Readback support : Enable support for bi-directional lcd bus to read LCDs busy flag. Supported by direct and I2C connection only. : : You '''definitly should use a readback capable hardware and enable this feature''', saves lots of delays. ;Backlight support : Backlight support for LCDs based on the HD44780 controller. : : Enable backlight on/off control via API and ECMD. ;Backlight on at power-on : Switch on backlight at power-on/reset. ;Invert Backlight switch : Invert backlight logic for low active backlight circuits e.g. found on Pollin AVR NET-IO Add-on. = Pinning = == Direct == The following example maps the LCD pins to AVR port pins found on the 25 pin Sub-D connector of the Pollin AVR Net-IO board: <code> dnl Direct connection example dnl map LCD pins to Pollin AVR Net-IO dnl 25 pin extension port ifdef(`conf_HD44780', ` pin(HD44780_RS, PC4) pin(HD44780_RW, PC3) pin(HD44780_EN1, PC2) dnl pin(HD44780_EN2, PC5) pin(HD44780_D4, PA0) pin(HD44780_D5, PA1) pin(HD44780_D6, PA2) pin(HD44780_D7, PA3) ') ifdef(`conf_HD44780_BACKLIGHT', ` pin(HD44780_BL, PC6, OUTPUT) ') </code> == I2C == <pre> /* * HD44780-Display über PCF8574 ansteuern. * Belegung Pollin Add-On-Board: * * Pin PCF8574 Pin am LCD * 4 (P0) -> 11 (DB4) * 5 (P1) -> 12 (DB5) * 6 (P2) -> 13 (DB6) * 7 (P3) -> 14 (DB7) * 9 (P4) -> 4 (RS) * 10 (P5) -> 5 (R/W) nicht benutzt ! * 11 (P6) -> 6 (EN) * 12 (P7) -> 15 (Beleuchtung) * * Die LCD-Beleuchtung an Pin 12 wird über einen * PNP-Transistor geschaltet. * Beleuchtung an: Bit 7=0 * Beleuchtung aus: Bit 7=1 * Die Address-Eingänge A0 bis A2 des PCF8574 liegen alle auf GND. * Die Basis-Addresse des Chips ist daher immer 0x20. */ </pre> Pinning: <code> ifelse(value_HD44780_CONNECTION,`HD44780_I2CSUPPORT',`dnl ifelse(value_HD44780_I2C_PORTEXP,`HD44780_I2C_PCF8574', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_PCF8574x_MULTI_MAPPING(ADR, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_PCF8574x_MULTI_MAPPING(0x20, 4, 5, 6, 7, 0, 1, 2, 3)', `dnl dnl HD44780_PCF8574x_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_PCF8574x_MAPPING(0x20, 4, 5, 6, 0, 1, 2, 3, 7)')', value_HD44780_I2C_PORTEXP,`HD44780_I2C_MCP23017', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_MCP23017_MULTI_MAPPING(ADR, PORT, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_MCP23017_MULTI_MAPPING(0x24, B, 4, 5, 6, 7, 0, 1, 2, 3) HD44780_MCP23017_MULTI_MAPPING_BL(0x24, A, 7)', `dnl dnl HD44780_MCP23017_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_MCP23017_MAPPING(0x24, B, 4, 5, 6, 0, 1, 2, 3, 7)')' )dnl ')dnl </code> == Serial (using 74HCT164) == == 2-Wire (using 74HCT4094) == = ECMD = a88b8466aa2435cc899f3941a9b7ea50ff53475d 1758 1757 2016-12-07T23:37:23Z Michaelb 718 wikitext text/x-wiki {{i18n|HD44780}} {{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->HD44780 module driver (Character-LCD) |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/lcd https://github.com/ethersex/ethersex/tree/master/hardware/lcd] }} '''THIS WIKI PAGE IS CURRENTLY WORK IN PROGRESS''' The '''HD44780 module''' provides support for common '''alphanumeric character LCDs''' using Hitachis HD44780 and compatible controllers. = Supported LC-Displays = The vast majority of all alphanumeric LC-Displays use Hitachis [https://en.wikipedia.org/wiki/Hitachi_HD44780_LCD_controller HD44780] dot matrix liquid crystal display (LCD) controller. The e6 HD44780 module supports displays of many different sizes utilizing the original HD44780 and compatible controllers. Alphanumeric LCDs are mainly distinguished by their size, the start-address of the per line Display Data-RAM (DDRAM) and the controller type. The original HD44780 controllers can drive up to 80 characters - most displays with more characters use two independent controllers. The following table lists the LC-displays supported by the e6 HD44780 module by size and per line DDRAM start-address: {| class="wikitable" !colspan="1"|Menuconfig !colspan="2"|Size !colspan="4"|DDRAM Startaddress !rowspan="2"|Note: |- !LCD size/type||Characters||Lines||Line 1||Line 2||Line 3||Line 4 |- |8_Characters_1_Line||8||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line||16||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line_Mux16||16||1||0x00||n/a||n/a||n/a||organized as 8 chars, 2 lines |- |20_Characters_1_Line||20||1||0x00||n/a||n/a||n/a|| |- |40_Characters_1_Line||40||1||0x00||n/a||n/a||n/a|| |- |8_Characters_2_Lines||8||2||0x00||0x40||n/a||n/a|| |- |12_Characters_2_Lines||12||2||0x00||0x40||n/a||n/a|| |- |16_Characters_2_Lines||16||2||0x00||0x40||n/a||n/a|| |- |20_Characters_2_Lines||20||2||0x00||0x40||n/a||n/a|| |- |24_Characters_2_Lines||24||2||0x00||0x40||n/a||n/a|| |- |40_Characters_2_Lines||40||2||0x00||0x40||n/a||n/a|| |- |16_Characters_4_Lines||16||4||0x00||0x40||0x10||0x50|| |- |20_Characters_4_Lines||20||4||0x00||0x40||0x14||0x54||Note DDRAM addresses |- |20_Characters_4_Lines_KS0073||20||4||0x00||0x20||0x40||0x60||Note DDRAM addresses |- |27_Characters_4_Lines_2_EN||27||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |- |40_Characters_4_Lines_2_EN||40||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |} '''Note:''' The HD44780 module drivers supports '''alphanumeric character LCDs''' only. Ethersex also has limited support for some graphical displays. Have a look at the LC-Display configuration. = Configuration = ... │ │ Network ---> │ │ I/O ---> ... │ │ ADC / DAC ---> │ │ LCD Displays ---> ... │ │ [*] HD44780 module driver (Character-LCD) ---> │ │ [-] HR20-style LCD Display ... │ │ (16_Characters_2_Lines) LCD size/type │ │ (HD44780_Compat) LCD controller type │ │ (None) LCD charset conversion │ │ (I2C) Connection type │ │ (PCF8574) I2C Port Expander │ │ [*] Readback support │ │ [*] Backlight support │ │ [*] Backlight on at power-on │ │ [*] Invert Backlight switch '''Configuration options:''' ;LCD size/type : Select one of the defined display sizes and address configurations shown in the table [[#Supported LC-Displays]] above. : : Although it is technically possible to connect more than one display, the HD44780 module supports only one LC-Display at a time. ;LCD controller type : Select LCD controller circuit: : :* HD44780_Compat - most controllers are compatible to Hitachis HD44780 :* KS0066U - Samsungs KS0066U requires a different init routine : : Almost all controllers for alphanumeric character LCDs are more or less HD44780-compatible at least at the feature- and function-level required by e6. : : If in doubt, choose HD44780_Compat. ;LCD charset conversion : Select charset conversion used while writing to the lcd: : :* None - use no charset conversion at all (safes program mem) :* HD44780_Compat - map characters from ISO8859-1 to the original HD44780 charset : : Allmost all controllers use their own non-ISO-compatible charset, varying between manufacturers, rom versions, etc. that provides characters from western languages as well as japanese, chinese and graphical glyphs. : : Charset conversion might become useful if you have to display messages and texts from external resources that uses standard encodings for their charset like ISO8859-1. : : Note: Charset conversion uses a lookup table and requires about 272 byte program memory (flash rom). ;Connection type : Select the connection type for the LCD: : :* Direct - direct connection using avr io-pins :* I2C - uses sub-selection of I2C port expander :* SER_LCD(74hct164) - serial connection using HCT164 shift register :* 2WIRE(74hct4094) - serial connection using HCT4094 shift register : : See section [[#Pinning]] below for further explanations. : ;I2C Port Expander : Select I2C Port Expander to use: : :* PCF8574 - use PCF8574x as I2C port expander :* MCP23017 - use MCP23017 as I2C port expander : : Note: automatically enables I2C_MASTER_SUPPORT and I2C_PCF8574X_SUPPORT resp. I2C_MCP23017_SUPPORT when selected. : : Note: Selection is only valid when '''I2C''' was selected under '''Connection type'''. : See section [[#Pinning]] below for further explanations. ;Readback support : Enable support for bi-directional lcd bus to read LCDs busy flag. Supported by direct and I2C connection only. : : You '''definitly should use a readback capable hardware and enable this feature''', saves lots of delays. ;Backlight support : Backlight support for LCDs based on the HD44780 controller. : : Enable backlight on/off control via API and ECMD. ;Backlight on at power-on : Switch on backlight at power-on/reset. ;Invert Backlight switch : Invert backlight logic for low active backlight circuits e.g. found on Pollin AVR NET-IO Add-on. = Pinning = HD44780-based alphanumeric LCDs are connected via 8 databus-lines (D0..D7) and 3 control-lines (RS, EN, R/W). Displays with more than 80 characters usually utilize a second controller and require two EN-signals EN1 and EN2. Another signal BL is needed if backlight control ist required. To save some i/o-pins the HD44780 controller also supports a 4 Bit mode, using only D4..D7. The HD44780 module supports this 4 Bit mode only. Note that in general the signals D0..D3 should not be left open, use a pull-down or tie them to ground. Most displays use 14, 16 or 18-pin connectors with common pinouts but there are sometimes subtle differences. Beside the control- and data-signals all displays require a supply voltage Vdd, usually +5 V, for the logic circuits and another voltage Vo for the display itself. The later is usually derived using a trimmer which allows for contrast adjustment. Some displays require a ''negative'' voltage for the display. Please refer to the datasheet of '''your''' display! Wrong connections may lead to a permanent damage. The HD44780 module supports four different types of connection: Direct, I2C, Serial and 2-Wire. == Direct == The LCD signals RS, RW, EN (resp. EN1 and EN2), D4..D7 and BL are directly connected to AVR port pins. The driver makes no assumptions about the pin mapping, arbitrary pins from different ports may be used to drive the LCD signals. This connection type is Readback-capable. The following example maps the LCD pins to AVR port pins found on the 25 pin Sub-D connector of the Pollin AVR Net-IO board: <code> dnl Direct connection example dnl map LCD pins to Pollin AVR Net-IO dnl 25 pin extension port ifdef(`conf_HD44780', ` pin(HD44780_RS, PC4) pin(HD44780_RW, PC3) pin(HD44780_EN1, PC2) dnl pin(HD44780_EN2, PC5) pin(HD44780_D4, PA0) pin(HD44780_D5, PA1) pin(HD44780_D6, PA2) pin(HD44780_D7, PA3) ') ifdef(`conf_HD44780_BACKLIGHT', ` pin(HD44780_BL, PC6, OUTPUT) ') </code> == I2C == <pre> /* * HD44780-Display über PCF8574 ansteuern. * Belegung Pollin Add-On-Board: * * Pin PCF8574 Pin am LCD * 4 (P0) -> 11 (DB4) * 5 (P1) -> 12 (DB5) * 6 (P2) -> 13 (DB6) * 7 (P3) -> 14 (DB7) * 9 (P4) -> 4 (RS) * 10 (P5) -> 5 (R/W) nicht benutzt ! * 11 (P6) -> 6 (EN) * 12 (P7) -> 15 (Beleuchtung) * * Die LCD-Beleuchtung an Pin 12 wird über einen * PNP-Transistor geschaltet. * Beleuchtung an: Bit 7=0 * Beleuchtung aus: Bit 7=1 * Die Address-Eingänge A0 bis A2 des PCF8574 liegen alle auf GND. * Die Basis-Addresse des Chips ist daher immer 0x20. */ </pre> Pinning: <code> ifelse(value_HD44780_CONNECTION,`HD44780_I2CSUPPORT',`dnl ifelse(value_HD44780_I2C_PORTEXP,`HD44780_I2C_PCF8574', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_PCF8574x_MULTI_MAPPING(ADR, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_PCF8574x_MULTI_MAPPING(0x20, 4, 5, 6, 7, 0, 1, 2, 3)', `dnl dnl HD44780_PCF8574x_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_PCF8574x_MAPPING(0x20, 4, 5, 6, 0, 1, 2, 3, 7)')', value_HD44780_I2C_PORTEXP,`HD44780_I2C_MCP23017', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_MCP23017_MULTI_MAPPING(ADR, PORT, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_MCP23017_MULTI_MAPPING(0x24, B, 4, 5, 6, 7, 0, 1, 2, 3) HD44780_MCP23017_MULTI_MAPPING_BL(0x24, A, 7)', `dnl dnl HD44780_MCP23017_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_MCP23017_MAPPING(0x24, B, 4, 5, 6, 0, 1, 2, 3, 7)')' )dnl ')dnl </code> == Serial (using 74HCT164) == The LCD is connected using a 74HC(T)164 shift register. Refer to Ulrich Radig's [http://www.ulrichradig.de/home/index.php/software/avr-webserver-software avr-webserver] for an example of this connection type. <code> dnl serial connection requires three AVR port pins pin(HD44780_SER_D, PD4) pin(HD44780_SER_CLK, PD3) pin(HD44780_SER_EN1, PD2) </code> == 2-Wire (using 74HCT4094) == = ECMD = 98c96f856198aed98a0905f48a6c737e9684a6ed 1759 1758 2016-12-07T23:43:56Z Michaelb 718 /* Serial (using 74HCT164) */ wikitext text/x-wiki {{i18n|HD44780}} {{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->HD44780 module driver (Character-LCD) |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/lcd https://github.com/ethersex/ethersex/tree/master/hardware/lcd] }} '''THIS WIKI PAGE IS CURRENTLY WORK IN PROGRESS''' The '''HD44780 module''' provides support for common '''alphanumeric character LCDs''' using Hitachis HD44780 and compatible controllers. = Supported LC-Displays = The vast majority of all alphanumeric LC-Displays use Hitachis [https://en.wikipedia.org/wiki/Hitachi_HD44780_LCD_controller HD44780] dot matrix liquid crystal display (LCD) controller. The e6 HD44780 module supports displays of many different sizes utilizing the original HD44780 and compatible controllers. Alphanumeric LCDs are mainly distinguished by their size, the start-address of the per line Display Data-RAM (DDRAM) and the controller type. The original HD44780 controllers can drive up to 80 characters - most displays with more characters use two independent controllers. The following table lists the LC-displays supported by the e6 HD44780 module by size and per line DDRAM start-address: {| class="wikitable" !colspan="1"|Menuconfig !colspan="2"|Size !colspan="4"|DDRAM Startaddress !rowspan="2"|Note: |- !LCD size/type||Characters||Lines||Line 1||Line 2||Line 3||Line 4 |- |8_Characters_1_Line||8||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line||16||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line_Mux16||16||1||0x00||n/a||n/a||n/a||organized as 8 chars, 2 lines |- |20_Characters_1_Line||20||1||0x00||n/a||n/a||n/a|| |- |40_Characters_1_Line||40||1||0x00||n/a||n/a||n/a|| |- |8_Characters_2_Lines||8||2||0x00||0x40||n/a||n/a|| |- |12_Characters_2_Lines||12||2||0x00||0x40||n/a||n/a|| |- |16_Characters_2_Lines||16||2||0x00||0x40||n/a||n/a|| |- |20_Characters_2_Lines||20||2||0x00||0x40||n/a||n/a|| |- |24_Characters_2_Lines||24||2||0x00||0x40||n/a||n/a|| |- |40_Characters_2_Lines||40||2||0x00||0x40||n/a||n/a|| |- |16_Characters_4_Lines||16||4||0x00||0x40||0x10||0x50|| |- |20_Characters_4_Lines||20||4||0x00||0x40||0x14||0x54||Note DDRAM addresses |- |20_Characters_4_Lines_KS0073||20||4||0x00||0x20||0x40||0x60||Note DDRAM addresses |- |27_Characters_4_Lines_2_EN||27||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |- |40_Characters_4_Lines_2_EN||40||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |} '''Note:''' The HD44780 module drivers supports '''alphanumeric character LCDs''' only. Ethersex also has limited support for some graphical displays. Have a look at the LC-Display configuration. = Configuration = ... │ │ Network ---> │ │ I/O ---> ... │ │ ADC / DAC ---> │ │ LCD Displays ---> ... │ │ [*] HD44780 module driver (Character-LCD) ---> │ │ [-] HR20-style LCD Display ... │ │ (16_Characters_2_Lines) LCD size/type │ │ (HD44780_Compat) LCD controller type │ │ (None) LCD charset conversion │ │ (I2C) Connection type │ │ (PCF8574) I2C Port Expander │ │ [*] Readback support │ │ [*] Backlight support │ │ [*] Backlight on at power-on │ │ [*] Invert Backlight switch '''Configuration options:''' ;LCD size/type : Select one of the defined display sizes and address configurations shown in the table [[#Supported LC-Displays]] above. : : Although it is technically possible to connect more than one display, the HD44780 module supports only one LC-Display at a time. ;LCD controller type : Select LCD controller circuit: : :* HD44780_Compat - most controllers are compatible to Hitachis HD44780 :* KS0066U - Samsungs KS0066U requires a different init routine : : Almost all controllers for alphanumeric character LCDs are more or less HD44780-compatible at least at the feature- and function-level required by e6. : : If in doubt, choose HD44780_Compat. ;LCD charset conversion : Select charset conversion used while writing to the lcd: : :* None - use no charset conversion at all (safes program mem) :* HD44780_Compat - map characters from ISO8859-1 to the original HD44780 charset : : Allmost all controllers use their own non-ISO-compatible charset, varying between manufacturers, rom versions, etc. that provides characters from western languages as well as japanese, chinese and graphical glyphs. : : Charset conversion might become useful if you have to display messages and texts from external resources that uses standard encodings for their charset like ISO8859-1. : : Note: Charset conversion uses a lookup table and requires about 272 byte program memory (flash rom). ;Connection type : Select the connection type for the LCD: : :* Direct - direct connection using avr io-pins :* I2C - uses sub-selection of I2C port expander :* SER_LCD(74hct164) - serial connection using HCT164 shift register :* 2WIRE(74hct4094) - serial connection using HCT4094 shift register : : See section [[#Pinning]] below for further explanations. : ;I2C Port Expander : Select I2C Port Expander to use: : :* PCF8574 - use PCF8574x as I2C port expander :* MCP23017 - use MCP23017 as I2C port expander : : Note: automatically enables I2C_MASTER_SUPPORT and I2C_PCF8574X_SUPPORT resp. I2C_MCP23017_SUPPORT when selected. : : Note: Selection is only valid when '''I2C''' was selected under '''Connection type'''. : See section [[#Pinning]] below for further explanations. ;Readback support : Enable support for bi-directional lcd bus to read LCDs busy flag. Supported by direct and I2C connection only. : : You '''definitly should use a readback capable hardware and enable this feature''', saves lots of delays. ;Backlight support : Backlight support for LCDs based on the HD44780 controller. : : Enable backlight on/off control via API and ECMD. ;Backlight on at power-on : Switch on backlight at power-on/reset. ;Invert Backlight switch : Invert backlight logic for low active backlight circuits e.g. found on Pollin AVR NET-IO Add-on. = Pinning = HD44780-based alphanumeric LCDs are connected via 8 databus-lines (D0..D7) and 3 control-lines (RS, EN, R/W). Displays with more than 80 characters usually utilize a second controller and require two EN-signals EN1 and EN2. Another signal BL is needed if backlight control ist required. To save some i/o-pins the HD44780 controller also supports a 4 Bit mode, using only D4..D7. The HD44780 module supports this 4 Bit mode only. Note that in general the signals D0..D3 should not be left open, use a pull-down or tie them to ground. Most displays use 14, 16 or 18-pin connectors with common pinouts but there are sometimes subtle differences. Beside the control- and data-signals all displays require a supply voltage Vdd, usually +5 V, for the logic circuits and another voltage Vo for the display itself. The later is usually derived using a trimmer which allows for contrast adjustment. Some displays require a ''negative'' voltage for the display. Please refer to the datasheet of '''your''' display! Wrong connections may lead to a permanent damage. The HD44780 module supports four different types of connection: Direct, I2C, Serial and 2-Wire. == Direct == The LCD signals RS, RW, EN (resp. EN1 and EN2), D4..D7 and BL are directly connected to AVR port pins. The driver makes no assumptions about the pin mapping, arbitrary pins from different ports may be used to drive the LCD signals. This connection type is Readback-capable. The following example maps the LCD pins to AVR port pins found on the 25 pin Sub-D connector of the Pollin AVR Net-IO board: <code> dnl Direct connection example dnl map LCD pins to Pollin AVR Net-IO dnl 25 pin extension port ifdef(`conf_HD44780', ` pin(HD44780_RS, PC4) pin(HD44780_RW, PC3) pin(HD44780_EN1, PC2) dnl pin(HD44780_EN2, PC5) pin(HD44780_D4, PA0) pin(HD44780_D5, PA1) pin(HD44780_D6, PA2) pin(HD44780_D7, PA3) ') ifdef(`conf_HD44780_BACKLIGHT', ` pin(HD44780_BL, PC6, OUTPUT) ') </code> == I2C == <pre> /* * HD44780-Display über PCF8574 ansteuern. * Belegung Pollin Add-On-Board: * * Pin PCF8574 Pin am LCD * 4 (P0) -> 11 (DB4) * 5 (P1) -> 12 (DB5) * 6 (P2) -> 13 (DB6) * 7 (P3) -> 14 (DB7) * 9 (P4) -> 4 (RS) * 10 (P5) -> 5 (R/W) nicht benutzt ! * 11 (P6) -> 6 (EN) * 12 (P7) -> 15 (Beleuchtung) * * Die LCD-Beleuchtung an Pin 12 wird über einen * PNP-Transistor geschaltet. * Beleuchtung an: Bit 7=0 * Beleuchtung aus: Bit 7=1 * Die Address-Eingänge A0 bis A2 des PCF8574 liegen alle auf GND. * Die Basis-Addresse des Chips ist daher immer 0x20. */ </pre> Pinning: <code> ifelse(value_HD44780_CONNECTION,`HD44780_I2CSUPPORT',`dnl ifelse(value_HD44780_I2C_PORTEXP,`HD44780_I2C_PCF8574', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_PCF8574x_MULTI_MAPPING(ADR, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_PCF8574x_MULTI_MAPPING(0x20, 4, 5, 6, 7, 0, 1, 2, 3)', `dnl dnl HD44780_PCF8574x_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_PCF8574x_MAPPING(0x20, 4, 5, 6, 0, 1, 2, 3, 7)')', value_HD44780_I2C_PORTEXP,`HD44780_I2C_MCP23017', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_MCP23017_MULTI_MAPPING(ADR, PORT, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_MCP23017_MULTI_MAPPING(0x24, B, 4, 5, 6, 7, 0, 1, 2, 3) HD44780_MCP23017_MULTI_MAPPING_BL(0x24, A, 7)', `dnl dnl HD44780_MCP23017_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_MCP23017_MAPPING(0x24, B, 4, 5, 6, 0, 1, 2, 3, 7)')' )dnl ')dnl </code> == Serial (using 74HCT164) == The LCD is connected using a 74HC(T)164 shift register. Refer to Ulrich Radig's [http://www.ulrichradig.de/home/index.php/software/avr-webserver-software avr-webserver] for an example of this connection type. This connection type is not capable of reading the displays busy-flag, no Readback possible. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection requires three AVR port pins pin(HD44780_SER_D, PD4) pin(HD44780_SER_CLK, PD3) pin(HD44780_SER_EN1, PD2) </code> == 2-Wire (using 74HCT4094) == = ECMD = d7d8bfcc7b49595ee419a7b515e6bc3bba57d1d2 1760 1759 2016-12-07T23:45:39Z Michaelb 718 /* Serial (using 74HCT164) */ wikitext text/x-wiki {{i18n|HD44780}} {{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->HD44780 module driver (Character-LCD) |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/lcd https://github.com/ethersex/ethersex/tree/master/hardware/lcd] }} '''THIS WIKI PAGE IS CURRENTLY WORK IN PROGRESS''' The '''HD44780 module''' provides support for common '''alphanumeric character LCDs''' using Hitachis HD44780 and compatible controllers. = Supported LC-Displays = The vast majority of all alphanumeric LC-Displays use Hitachis [https://en.wikipedia.org/wiki/Hitachi_HD44780_LCD_controller HD44780] dot matrix liquid crystal display (LCD) controller. The e6 HD44780 module supports displays of many different sizes utilizing the original HD44780 and compatible controllers. Alphanumeric LCDs are mainly distinguished by their size, the start-address of the per line Display Data-RAM (DDRAM) and the controller type. The original HD44780 controllers can drive up to 80 characters - most displays with more characters use two independent controllers. The following table lists the LC-displays supported by the e6 HD44780 module by size and per line DDRAM start-address: {| class="wikitable" !colspan="1"|Menuconfig !colspan="2"|Size !colspan="4"|DDRAM Startaddress !rowspan="2"|Note: |- !LCD size/type||Characters||Lines||Line 1||Line 2||Line 3||Line 4 |- |8_Characters_1_Line||8||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line||16||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line_Mux16||16||1||0x00||n/a||n/a||n/a||organized as 8 chars, 2 lines |- |20_Characters_1_Line||20||1||0x00||n/a||n/a||n/a|| |- |40_Characters_1_Line||40||1||0x00||n/a||n/a||n/a|| |- |8_Characters_2_Lines||8||2||0x00||0x40||n/a||n/a|| |- |12_Characters_2_Lines||12||2||0x00||0x40||n/a||n/a|| |- |16_Characters_2_Lines||16||2||0x00||0x40||n/a||n/a|| |- |20_Characters_2_Lines||20||2||0x00||0x40||n/a||n/a|| |- |24_Characters_2_Lines||24||2||0x00||0x40||n/a||n/a|| |- |40_Characters_2_Lines||40||2||0x00||0x40||n/a||n/a|| |- |16_Characters_4_Lines||16||4||0x00||0x40||0x10||0x50|| |- |20_Characters_4_Lines||20||4||0x00||0x40||0x14||0x54||Note DDRAM addresses |- |20_Characters_4_Lines_KS0073||20||4||0x00||0x20||0x40||0x60||Note DDRAM addresses |- |27_Characters_4_Lines_2_EN||27||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |- |40_Characters_4_Lines_2_EN||40||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |} '''Note:''' The HD44780 module drivers supports '''alphanumeric character LCDs''' only. Ethersex also has limited support for some graphical displays. Have a look at the LC-Display configuration. = Configuration = ... │ │ Network ---> │ │ I/O ---> ... │ │ ADC / DAC ---> │ │ LCD Displays ---> ... │ │ [*] HD44780 module driver (Character-LCD) ---> │ │ [-] HR20-style LCD Display ... │ │ (16_Characters_2_Lines) LCD size/type │ │ (HD44780_Compat) LCD controller type │ │ (None) LCD charset conversion │ │ (I2C) Connection type │ │ (PCF8574) I2C Port Expander │ │ [*] Readback support │ │ [*] Backlight support │ │ [*] Backlight on at power-on │ │ [*] Invert Backlight switch '''Configuration options:''' ;LCD size/type : Select one of the defined display sizes and address configurations shown in the table [[#Supported LC-Displays]] above. : : Although it is technically possible to connect more than one display, the HD44780 module supports only one LC-Display at a time. ;LCD controller type : Select LCD controller circuit: : :* HD44780_Compat - most controllers are compatible to Hitachis HD44780 :* KS0066U - Samsungs KS0066U requires a different init routine : : Almost all controllers for alphanumeric character LCDs are more or less HD44780-compatible at least at the feature- and function-level required by e6. : : If in doubt, choose HD44780_Compat. ;LCD charset conversion : Select charset conversion used while writing to the lcd: : :* None - use no charset conversion at all (safes program mem) :* HD44780_Compat - map characters from ISO8859-1 to the original HD44780 charset : : Allmost all controllers use their own non-ISO-compatible charset, varying between manufacturers, rom versions, etc. that provides characters from western languages as well as japanese, chinese and graphical glyphs. : : Charset conversion might become useful if you have to display messages and texts from external resources that uses standard encodings for their charset like ISO8859-1. : : Note: Charset conversion uses a lookup table and requires about 272 byte program memory (flash rom). ;Connection type : Select the connection type for the LCD: : :* Direct - direct connection using avr io-pins :* I2C - uses sub-selection of I2C port expander :* SER_LCD(74hct164) - serial connection using HCT164 shift register :* 2WIRE(74hct4094) - serial connection using HCT4094 shift register : : See section [[#Pinning]] below for further explanations. : ;I2C Port Expander : Select I2C Port Expander to use: : :* PCF8574 - use PCF8574x as I2C port expander :* MCP23017 - use MCP23017 as I2C port expander : : Note: automatically enables I2C_MASTER_SUPPORT and I2C_PCF8574X_SUPPORT resp. I2C_MCP23017_SUPPORT when selected. : : Note: Selection is only valid when '''I2C''' was selected under '''Connection type'''. : See section [[#Pinning]] below for further explanations. ;Readback support : Enable support for bi-directional lcd bus to read LCDs busy flag. Supported by direct and I2C connection only. : : You '''definitly should use a readback capable hardware and enable this feature''', saves lots of delays. ;Backlight support : Backlight support for LCDs based on the HD44780 controller. : : Enable backlight on/off control via API and ECMD. ;Backlight on at power-on : Switch on backlight at power-on/reset. ;Invert Backlight switch : Invert backlight logic for low active backlight circuits e.g. found on Pollin AVR NET-IO Add-on. = Pinning = HD44780-based alphanumeric LCDs are connected via 8 databus-lines (D0..D7) and 3 control-lines (RS, EN, R/W). Displays with more than 80 characters usually utilize a second controller and require two EN-signals EN1 and EN2. Another signal BL is needed if backlight control ist required. To save some i/o-pins the HD44780 controller also supports a 4 Bit mode, using only D4..D7. The HD44780 module supports this 4 Bit mode only. Note that in general the signals D0..D3 should not be left open, use a pull-down or tie them to ground. Most displays use 14, 16 or 18-pin connectors with common pinouts but there are sometimes subtle differences. Beside the control- and data-signals all displays require a supply voltage Vdd, usually +5 V, for the logic circuits and another voltage Vo for the display itself. The later is usually derived using a trimmer which allows for contrast adjustment. Some displays require a ''negative'' voltage for the display. Please refer to the datasheet of '''your''' display! Wrong connections may lead to a permanent damage. The HD44780 module supports four different types of connection: Direct, I2C, Serial and 2-Wire. == Direct == The LCD signals RS, RW, EN (resp. EN1 and EN2), D4..D7 and BL are directly connected to AVR port pins. The driver makes no assumptions about the pin mapping, arbitrary pins from different ports may be used to drive the LCD signals. This connection type is Readback-capable. The following example maps the LCD pins to AVR port pins found on the 25 pin Sub-D connector of the Pollin AVR Net-IO board: <code> dnl Direct connection example dnl map LCD pins to Pollin AVR Net-IO dnl 25 pin extension port ifdef(`conf_HD44780', ` pin(HD44780_RS, PC4) pin(HD44780_RW, PC3) pin(HD44780_EN1, PC2) dnl pin(HD44780_EN2, PC5) pin(HD44780_D4, PA0) pin(HD44780_D5, PA1) pin(HD44780_D6, PA2) pin(HD44780_D7, PA3) ') ifdef(`conf_HD44780_BACKLIGHT', ` pin(HD44780_BL, PC6, OUTPUT) ') </code> == I2C == <pre> /* * HD44780-Display über PCF8574 ansteuern. * Belegung Pollin Add-On-Board: * * Pin PCF8574 Pin am LCD * 4 (P0) -> 11 (DB4) * 5 (P1) -> 12 (DB5) * 6 (P2) -> 13 (DB6) * 7 (P3) -> 14 (DB7) * 9 (P4) -> 4 (RS) * 10 (P5) -> 5 (R/W) nicht benutzt ! * 11 (P6) -> 6 (EN) * 12 (P7) -> 15 (Beleuchtung) * * Die LCD-Beleuchtung an Pin 12 wird über einen * PNP-Transistor geschaltet. * Beleuchtung an: Bit 7=0 * Beleuchtung aus: Bit 7=1 * Die Address-Eingänge A0 bis A2 des PCF8574 liegen alle auf GND. * Die Basis-Addresse des Chips ist daher immer 0x20. */ </pre> Pinning: <code> ifelse(value_HD44780_CONNECTION,`HD44780_I2CSUPPORT',`dnl ifelse(value_HD44780_I2C_PORTEXP,`HD44780_I2C_PCF8574', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_PCF8574x_MULTI_MAPPING(ADR, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_PCF8574x_MULTI_MAPPING(0x20, 4, 5, 6, 7, 0, 1, 2, 3)', `dnl dnl HD44780_PCF8574x_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_PCF8574x_MAPPING(0x20, 4, 5, 6, 0, 1, 2, 3, 7)')', value_HD44780_I2C_PORTEXP,`HD44780_I2C_MCP23017', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_MCP23017_MULTI_MAPPING(ADR, PORT, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_MCP23017_MULTI_MAPPING(0x24, B, 4, 5, 6, 7, 0, 1, 2, 3) HD44780_MCP23017_MULTI_MAPPING_BL(0x24, A, 7)', `dnl dnl HD44780_MCP23017_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_MCP23017_MAPPING(0x24, B, 4, 5, 6, 0, 1, 2, 3, 7)')' )dnl ')dnl </code> == Serial (using 74HCT164) == The LCD is connected using a 74HC(T)164 shift register. Refer to Ulrich Radig's [http://www.ulrichradig.de/home/index.php/software/avr-webserver-software avr-webserver] for an example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection requires three AVR port pins pin(HD44780_SER_D, PD4) pin(HD44780_SER_CLK, PD3) pin(HD44780_SER_EN1, PD2) </code> == 2-Wire (using 74HCT4094) == = ECMD = 5d301455fcaabd1980bc74f17902d88152abb869 1761 1760 2016-12-07T23:56:04Z Michaelb 718 wikitext text/x-wiki {{i18n|HD44780}} {{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->HD44780 module driver (Character-LCD) |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/lcd https://github.com/ethersex/ethersex/tree/master/hardware/lcd] }} '''THIS WIKI PAGE IS CURRENTLY WORK IN PROGRESS''' The '''HD44780 module''' provides support for common '''alphanumeric character LCDs''' using Hitachis HD44780 and compatible controllers. = Supported LC-Displays = The vast majority of all alphanumeric LC-Displays use Hitachis [https://en.wikipedia.org/wiki/Hitachi_HD44780_LCD_controller HD44780] dot matrix liquid crystal display (LCD) controller. The e6 HD44780 module supports displays of many different sizes utilizing the original HD44780 and compatible controllers. Alphanumeric LCDs are mainly distinguished by their size, the start-address of the per line Display Data-RAM (DDRAM) and the controller type. The original HD44780 controllers can drive up to 80 characters - most displays with more characters use two independent controllers. The following table lists the LC-displays supported by the e6 HD44780 module by size and per line DDRAM start-address: {| class="wikitable" !colspan="1"|Menuconfig !colspan="2"|Size !colspan="4"|DDRAM Startaddress !rowspan="2"|Note: |- !LCD size/type||Characters||Lines||Line 1||Line 2||Line 3||Line 4 |- |8_Characters_1_Line||8||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line||16||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line_Mux16||16||1||0x00||n/a||n/a||n/a||organized as 8 chars, 2 lines |- |20_Characters_1_Line||20||1||0x00||n/a||n/a||n/a|| |- |40_Characters_1_Line||40||1||0x00||n/a||n/a||n/a|| |- |8_Characters_2_Lines||8||2||0x00||0x40||n/a||n/a|| |- |12_Characters_2_Lines||12||2||0x00||0x40||n/a||n/a|| |- |16_Characters_2_Lines||16||2||0x00||0x40||n/a||n/a|| |- |20_Characters_2_Lines||20||2||0x00||0x40||n/a||n/a|| |- |24_Characters_2_Lines||24||2||0x00||0x40||n/a||n/a|| |- |40_Characters_2_Lines||40||2||0x00||0x40||n/a||n/a|| |- |16_Characters_4_Lines||16||4||0x00||0x40||0x10||0x50|| |- |20_Characters_4_Lines||20||4||0x00||0x40||0x14||0x54||Note DDRAM addresses |- |20_Characters_4_Lines_KS0073||20||4||0x00||0x20||0x40||0x60||Note DDRAM addresses |- |27_Characters_4_Lines_2_EN||27||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |- |40_Characters_4_Lines_2_EN||40||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |} '''Note:''' The HD44780 module drivers supports '''alphanumeric character LCDs''' only. Ethersex also has limited support for some graphical displays. Have a look at the LC-Display configuration. = Configuration = ... │ │ Network ---> │ │ I/O ---> ... │ │ ADC / DAC ---> │ │ LCD Displays ---> ... │ │ [*] HD44780 module driver (Character-LCD) ---> │ │ [-] HR20-style LCD Display ... │ │ (16_Characters_2_Lines) LCD size/type │ │ (HD44780_Compat) LCD controller type │ │ (None) LCD charset conversion │ │ (I2C) Connection type │ │ (PCF8574) I2C Port Expander │ │ [*] Readback support │ │ [*] Backlight support │ │ [*] Backlight on at power-on │ │ [*] Invert Backlight switch '''Configuration options:''' ;LCD size/type : Select one of the defined display sizes and address configurations shown in the table [[#Supported LC-Displays]] above. : : Although it is technically possible to connect more than one display, the HD44780 module supports only one LC-Display at a time. ;LCD controller type : Select LCD controller circuit: : :* HD44780_Compat - most controllers are compatible to Hitachis HD44780 :* KS0066U - Samsungs KS0066U requires a different init routine : : Almost all controllers for alphanumeric character LCDs are more or less HD44780-compatible at least at the feature- and function-level required by e6. : : If in doubt, choose HD44780_Compat. ;LCD charset conversion : Select charset conversion used while writing to the lcd: : :* None - use no charset conversion at all (safes program mem) :* HD44780_Compat - map characters from ISO8859-1 to the original HD44780 charset : : Almost all controllers use their own non-ISO-compatible charset, varying between manufacturers, rom versions, etc. that provides characters from western languages as well as japanese, chinese and graphical glyphs. : : Charset conversion might become useful if you have to display messages and texts from external resources that uses standard encodings for their charset like ISO8859-1. : : Note: Charset conversion uses a lookup table and requires about 272 byte program memory (flash rom). ;Connection type : Select the connection type for the LCD: : :* Direct - direct connection using avr io-pins :* I2C - uses sub-selection of I2C port expander :* SER_LCD(74hct164) - serial connection using HCT164 shift register :* 2WIRE(74hct4094) - serial connection using HCT4094 shift register : : See section [[#Pinning]] below for further explanations. : ;I2C Port Expander : Select I2C Port Expander to use: : :* PCF8574 - use PCF8574x as I2C port expander :* MCP23017 - use MCP23017 as I2C port expander : : Note: automatically enables I2C_MASTER_SUPPORT and I2C_PCF8574X_SUPPORT resp. I2C_MCP23017_SUPPORT when selected. : : Note: Selection is only valid when '''I2C''' was selected under '''Connection type'''. : See section [[#Pinning]] below for further explanations. ;Readback support : Enable support for bi-directional lcd bus to read LCDs busy flag. Supported by direct and I2C connection only. : : You '''definitly should use a readback capable hardware and enable this feature''', saves lots of delays. ;Backlight support : Backlight support for LCDs based on the HD44780 controller. : : Enable backlight on/off control via API and ECMD. ;Backlight on at power-on : Switch on backlight at power-on/reset. ;Invert Backlight switch : Invert backlight logic for low active backlight circuits e.g. found on Pollin AVR NET-IO Add-on. = Pinning = HD44780-based alphanumeric LCDs are connected via 8 databus-lines (D0..D7) and 3 control-lines (RS, EN, R/W). Displays with more than 80 characters usually utilize a second controller and require two EN-signals EN1 and EN2. Another signal BL is needed if backlight control ist required. To save some i/o-pins the HD44780 controller also supports a 4 Bit mode, using only D4..D7. The HD44780 module supports this 4 Bit mode only. Note that in general the signals D0..D3 should not be left open, use a pull-down or tie them to ground. Most displays use 14, 16 or 18-pin connectors with common pinouts but there are sometimes subtle differences. Beside the control- and data-signals all displays require a supply voltage Vdd, usually +5 V, for the logic circuits and another voltage Vo for the display itself. The later is usually derived using a trimmer which allows for contrast adjustment. Some displays require a ''negative'' voltage for the display. Please refer to the datasheet of '''your''' display! Wrong connections may lead to a permanent damage. The HD44780 module supports four different types of connection: Direct, I2C, Serial and 2-Wire. == Direct == The LCD signals RS, RW, EN (resp. EN1 and EN2), D4..D7 and BL are directly connected to AVR port pins. The driver makes no assumptions about the pin mapping, arbitrary pins from different ports may be used to drive the LCD signals. This connection type is Readback-capable. The following example maps the LCD pins to AVR port pins found on the 25 pin Sub-D connector of the Pollin AVR Net-IO board: <code> dnl Direct connection example dnl map LCD pins to Pollin AVR Net-IO dnl 25 pin extension port ifdef(`conf_HD44780', ` pin(HD44780_RS, PC4) pin(HD44780_RW, PC3) pin(HD44780_EN1, PC2) dnl pin(HD44780_EN2, PC5) pin(HD44780_D4, PA0) pin(HD44780_D5, PA1) pin(HD44780_D6, PA2) pin(HD44780_D7, PA3) ') ifdef(`conf_HD44780_BACKLIGHT', ` pin(HD44780_BL, PC6, OUTPUT) ') </code> == I2C == <pre> /* * HD44780-Display über PCF8574 ansteuern. * Belegung Pollin Add-On-Board: * * Pin PCF8574 Pin am LCD * 4 (P0) -> 11 (DB4) * 5 (P1) -> 12 (DB5) * 6 (P2) -> 13 (DB6) * 7 (P3) -> 14 (DB7) * 9 (P4) -> 4 (RS) * 10 (P5) -> 5 (R/W) nicht benutzt ! * 11 (P6) -> 6 (EN) * 12 (P7) -> 15 (Beleuchtung) * * Die LCD-Beleuchtung an Pin 12 wird über einen * PNP-Transistor geschaltet. * Beleuchtung an: Bit 7=0 * Beleuchtung aus: Bit 7=1 * Die Address-Eingänge A0 bis A2 des PCF8574 liegen alle auf GND. * Die Basis-Addresse des Chips ist daher immer 0x20. */ </pre> Pinning: <code> ifelse(value_HD44780_CONNECTION,`HD44780_I2CSUPPORT',`dnl ifelse(value_HD44780_I2C_PORTEXP,`HD44780_I2C_PCF8574', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_PCF8574x_MULTI_MAPPING(ADR, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_PCF8574x_MULTI_MAPPING(0x20, 4, 5, 6, 7, 0, 1, 2, 3)', `dnl dnl HD44780_PCF8574x_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_PCF8574x_MAPPING(0x20, 4, 5, 6, 0, 1, 2, 3, 7)')', value_HD44780_I2C_PORTEXP,`HD44780_I2C_MCP23017', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_MCP23017_MULTI_MAPPING(ADR, PORT, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_MCP23017_MULTI_MAPPING(0x24, B, 4, 5, 6, 7, 0, 1, 2, 3) HD44780_MCP23017_MULTI_MAPPING_BL(0x24, A, 7)', `dnl dnl HD44780_MCP23017_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_MCP23017_MAPPING(0x24, B, 4, 5, 6, 0, 1, 2, 3, 7)')' )dnl ')dnl </code> == Serial (using 74HCT164) == The LCD is connected using a 74HC(T)164 shift register. Refer to Ulrich Radig's [http://www.ulrichradig.de/home/index.php/software/avr-webserver-software avr-webserver] for an example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection requires three AVR port pins pin(HD44780_SER_D, PD4) pin(HD44780_SER_CLK, PD3) pin(HD44780_SER_EN1, PD2) </code> == 2-Wire (using 74HCT4094) == = ECMD = bb61133cbcc4efa57634562e2630712bdce9b09f 1762 1761 2016-12-09T20:06:36Z Michaelb 718 /* I2C */ wikitext text/x-wiki {{i18n|HD44780}} {{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->HD44780 module driver (Character-LCD) |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/lcd https://github.com/ethersex/ethersex/tree/master/hardware/lcd] }} '''THIS WIKI PAGE IS CURRENTLY WORK IN PROGRESS''' The '''HD44780 module''' provides support for common '''alphanumeric character LCDs''' using Hitachis HD44780 and compatible controllers. = Supported LC-Displays = The vast majority of all alphanumeric LC-Displays use Hitachis [https://en.wikipedia.org/wiki/Hitachi_HD44780_LCD_controller HD44780] dot matrix liquid crystal display (LCD) controller. The e6 HD44780 module supports displays of many different sizes utilizing the original HD44780 and compatible controllers. Alphanumeric LCDs are mainly distinguished by their size, the start-address of the per line Display Data-RAM (DDRAM) and the controller type. The original HD44780 controllers can drive up to 80 characters - most displays with more characters use two independent controllers. The following table lists the LC-displays supported by the e6 HD44780 module by size and per line DDRAM start-address: {| class="wikitable" !colspan="1"|Menuconfig !colspan="2"|Size !colspan="4"|DDRAM Startaddress !rowspan="2"|Note: |- !LCD size/type||Characters||Lines||Line 1||Line 2||Line 3||Line 4 |- |8_Characters_1_Line||8||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line||16||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line_Mux16||16||1||0x00||n/a||n/a||n/a||organized as 8 chars, 2 lines |- |20_Characters_1_Line||20||1||0x00||n/a||n/a||n/a|| |- |40_Characters_1_Line||40||1||0x00||n/a||n/a||n/a|| |- |8_Characters_2_Lines||8||2||0x00||0x40||n/a||n/a|| |- |12_Characters_2_Lines||12||2||0x00||0x40||n/a||n/a|| |- |16_Characters_2_Lines||16||2||0x00||0x40||n/a||n/a|| |- |20_Characters_2_Lines||20||2||0x00||0x40||n/a||n/a|| |- |24_Characters_2_Lines||24||2||0x00||0x40||n/a||n/a|| |- |40_Characters_2_Lines||40||2||0x00||0x40||n/a||n/a|| |- |16_Characters_4_Lines||16||4||0x00||0x40||0x10||0x50|| |- |20_Characters_4_Lines||20||4||0x00||0x40||0x14||0x54||Note DDRAM addresses |- |20_Characters_4_Lines_KS0073||20||4||0x00||0x20||0x40||0x60||Note DDRAM addresses |- |27_Characters_4_Lines_2_EN||27||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |- |40_Characters_4_Lines_2_EN||40||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |} '''Note:''' The HD44780 module drivers supports '''alphanumeric character LCDs''' only. Ethersex also has limited support for some graphical displays. Have a look at the LC-Display configuration. = Configuration = ... │ │ Network ---> │ │ I/O ---> ... │ │ ADC / DAC ---> │ │ LCD Displays ---> ... │ │ [*] HD44780 module driver (Character-LCD) ---> │ │ [-] HR20-style LCD Display ... │ │ (16_Characters_2_Lines) LCD size/type │ │ (HD44780_Compat) LCD controller type │ │ (None) LCD charset conversion │ │ (I2C) Connection type │ │ (PCF8574) I2C Port Expander │ │ [*] Readback support │ │ [*] Backlight support │ │ [*] Backlight on at power-on │ │ [*] Invert Backlight switch '''Configuration options:''' ;LCD size/type : Select one of the defined display sizes and address configurations shown in the table [[#Supported LC-Displays]] above. : : Although it is technically possible to connect more than one display, the HD44780 module supports only one LC-Display at a time. ;LCD controller type : Select LCD controller circuit: : :* HD44780_Compat - most controllers are compatible to Hitachis HD44780 :* KS0066U - Samsungs KS0066U requires a different init routine : : Almost all controllers for alphanumeric character LCDs are more or less HD44780-compatible at least at the feature- and function-level required by e6. : : If in doubt, choose HD44780_Compat. ;LCD charset conversion : Select charset conversion used while writing to the lcd: : :* None - use no charset conversion at all (safes program mem) :* HD44780_Compat - map characters from ISO8859-1 to the original HD44780 charset : : Almost all controllers use their own non-ISO-compatible charset, varying between manufacturers, rom versions, etc. that provides characters from western languages as well as japanese, chinese and graphical glyphs. : : Charset conversion might become useful if you have to display messages and texts from external resources that uses standard encodings for their charset like ISO8859-1. : : Note: Charset conversion uses a lookup table and requires about 272 byte program memory (flash rom). ;Connection type : Select the connection type for the LCD: : :* Direct - direct connection using avr io-pins :* I2C - uses sub-selection of I2C port expander :* SER_LCD(74hct164) - serial connection using HCT164 shift register :* 2WIRE(74hct4094) - serial connection using HCT4094 shift register : : See section [[#Pinning]] below for further explanations. : ;I2C Port Expander : Select I2C Port Expander to use: : :* PCF8574 - use PCF8574x as I2C port expander :* MCP23017 - use MCP23017 as I2C port expander : : Note: automatically enables I2C_MASTER_SUPPORT and I2C_PCF8574X_SUPPORT resp. I2C_MCP23017_SUPPORT when selected. : : Note: Selection is only valid when '''I2C''' was selected under '''Connection type'''. : See section [[#Pinning]] below for further explanations. ;Readback support : Enable support for bi-directional lcd bus to read LCDs busy flag. Supported by direct and I2C connection only. : : You '''definitly should use a readback capable hardware and enable this feature''', saves lots of delays. ;Backlight support : Backlight support for LCDs based on the HD44780 controller. : : Enable backlight on/off control via API and ECMD. ;Backlight on at power-on : Switch on backlight at power-on/reset. ;Invert Backlight switch : Invert backlight logic for low active backlight circuits e.g. found on Pollin AVR NET-IO Add-on. = Pinning = HD44780-based alphanumeric LCDs are connected via 8 databus-lines (D0..D7) and 3 control-lines (RS, EN, R/W). Displays with more than 80 characters usually utilize a second controller and require two EN-signals EN1 and EN2. Another signal BL is needed if backlight control ist required. To save some i/o-pins the HD44780 controller also supports a 4 Bit mode, using only D4..D7. The HD44780 module supports this 4 Bit mode only. Note that in general the signals D0..D3 should not be left open, use a pull-down or tie them to ground. Most displays use 14, 16 or 18-pin connectors with common pinouts but there are sometimes subtle differences. Beside the control- and data-signals all displays require a supply voltage Vdd, usually +5 V, for the logic circuits and another voltage Vo for the display itself. The later is usually derived using a trimmer which allows for contrast adjustment. Some displays require a ''negative'' voltage for the display. Please refer to the datasheet of '''your''' display! Wrong connections may lead to a permanent damage. The HD44780 module supports four different types of connection: Direct, I2C, Serial and 2-Wire. == Direct == The LCD signals RS, RW, EN (resp. EN1 and EN2), D4..D7 and BL are directly connected to AVR port pins. The driver makes no assumptions about the pin mapping, arbitrary pins from different ports may be used to drive the LCD signals. This connection type is Readback-capable. The following example maps the LCD pins to AVR port pins found on the 25 pin Sub-D connector of the Pollin AVR Net-IO board: <code> dnl Direct connection example dnl map LCD pins to Pollin AVR Net-IO dnl 25 pin extension port ifdef(`conf_HD44780', ` pin(HD44780_RS, PC4) pin(HD44780_RW, PC3) pin(HD44780_EN1, PC2) dnl pin(HD44780_EN2, PC5) pin(HD44780_D4, PA0) pin(HD44780_D5, PA1) pin(HD44780_D6, PA2) pin(HD44780_D7, PA3) ') ifdef(`conf_HD44780_BACKLIGHT', ` pin(HD44780_BL, PC6, OUTPUT) ') </code> == I2C == The I2C connection type supports either the 8 Bit PCF8574x, as it is found on the Pollin AVR Net-IO Add-On board, or the 16 Bit MCP23017 I2C Port Expander. LCDs up to 80 characters and only one HD44780 controller may be connected to a PCD8574x including the backlight control pin. LCDs with more than 80 characters require a second enable pin. The address of the port expander and the pinning for the LCD has to be specified for your hardware using the macros shown below. The macro HD44780_PCF8574x_MAPPING defines the pinning for displays with only one enable signal and backlight control, the macro HD44780_PCF8574x_MULTI_MAPPING for displays with two enable signals. Note that backlight control is not supported when using the HD44780_PCF8574x_MULTI_MAPPING macro. The pinning shown below matches the pinning found on the Pollin AVR Net-IO Add-On board. Remember that you have to replace the inverting backlight control circuitry with a direct connection to connect displays with two enable signals to this board. The macros HD44780_MCP23017_MAPPING and HD44780_MCP23017_MULTI_MAPPING are used to map the LCD pins to one port of the MCP23017. Note that you have to specify either port A or B as shown below, mapping using mixed pins of both ports is not supported by the driver. The additional macro HD44780_MCP23017_MULTI_MAPPING_BL may be used to specify a backlight control signal on another MCP23017 port when the first port is occupied by a display with two enable signals. <code> ifelse(value_HD44780_CONNECTION,`HD44780_I2CSUPPORT',`dnl ifelse(value_HD44780_I2C_PORTEXP,`HD44780_I2C_PCF8574', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_PCF8574x_MULTI_MAPPING(ADR, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_PCF8574x_MULTI_MAPPING(0x20, 4, 5, 6, 7, 0, 1, 2, 3)', `dnl dnl HD44780_PCF8574x_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_PCF8574x_MAPPING(0x20, 4, 5, 6, 0, 1, 2, 3, 7)')', value_HD44780_I2C_PORTEXP,`HD44780_I2C_MCP23017', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_MCP23017_MULTI_MAPPING(ADR, PORT, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_MCP23017_MULTI_MAPPING(0x24, B, 4, 5, 6, 7, 0, 1, 2, 3) HD44780_MCP23017_MULTI_MAPPING_BL(0x24, A, 7)', `dnl dnl HD44780_MCP23017_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_MCP23017_MAPPING(0x24, B, 4, 5, 6, 0, 1, 2, 3, 7)')' )dnl ')dnl </code> == Serial (using 74HCT164) == The LCD is connected using a 74HC(T)164 shift register. Refer to Ulrich Radig's [http://www.ulrichradig.de/home/index.php/software/avr-webserver-software avr-webserver] for an example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection requires three AVR port pins pin(HD44780_SER_D, PD4) pin(HD44780_SER_CLK, PD3) pin(HD44780_SER_EN1, PD2) </code> == 2-Wire (using 74HCT4094) == = ECMD = 6fb70ceeb92bc21e181c9ca2f934abca38a3501b 1763 1762 2016-12-09T20:12:34Z Michaelb 718 /* I2C */ wikitext text/x-wiki {{i18n|HD44780}} {{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->HD44780 module driver (Character-LCD) |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/lcd https://github.com/ethersex/ethersex/tree/master/hardware/lcd] }} '''THIS WIKI PAGE IS CURRENTLY WORK IN PROGRESS''' The '''HD44780 module''' provides support for common '''alphanumeric character LCDs''' using Hitachis HD44780 and compatible controllers. = Supported LC-Displays = The vast majority of all alphanumeric LC-Displays use Hitachis [https://en.wikipedia.org/wiki/Hitachi_HD44780_LCD_controller HD44780] dot matrix liquid crystal display (LCD) controller. The e6 HD44780 module supports displays of many different sizes utilizing the original HD44780 and compatible controllers. Alphanumeric LCDs are mainly distinguished by their size, the start-address of the per line Display Data-RAM (DDRAM) and the controller type. The original HD44780 controllers can drive up to 80 characters - most displays with more characters use two independent controllers. The following table lists the LC-displays supported by the e6 HD44780 module by size and per line DDRAM start-address: {| class="wikitable" !colspan="1"|Menuconfig !colspan="2"|Size !colspan="4"|DDRAM Startaddress !rowspan="2"|Note: |- !LCD size/type||Characters||Lines||Line 1||Line 2||Line 3||Line 4 |- |8_Characters_1_Line||8||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line||16||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line_Mux16||16||1||0x00||n/a||n/a||n/a||organized as 8 chars, 2 lines |- |20_Characters_1_Line||20||1||0x00||n/a||n/a||n/a|| |- |40_Characters_1_Line||40||1||0x00||n/a||n/a||n/a|| |- |8_Characters_2_Lines||8||2||0x00||0x40||n/a||n/a|| |- |12_Characters_2_Lines||12||2||0x00||0x40||n/a||n/a|| |- |16_Characters_2_Lines||16||2||0x00||0x40||n/a||n/a|| |- |20_Characters_2_Lines||20||2||0x00||0x40||n/a||n/a|| |- |24_Characters_2_Lines||24||2||0x00||0x40||n/a||n/a|| |- |40_Characters_2_Lines||40||2||0x00||0x40||n/a||n/a|| |- |16_Characters_4_Lines||16||4||0x00||0x40||0x10||0x50|| |- |20_Characters_4_Lines||20||4||0x00||0x40||0x14||0x54||Note DDRAM addresses |- |20_Characters_4_Lines_KS0073||20||4||0x00||0x20||0x40||0x60||Note DDRAM addresses |- |27_Characters_4_Lines_2_EN||27||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |- |40_Characters_4_Lines_2_EN||40||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |} '''Note:''' The HD44780 module drivers supports '''alphanumeric character LCDs''' only. Ethersex also has limited support for some graphical displays. Have a look at the LC-Display configuration. = Configuration = ... │ │ Network ---> │ │ I/O ---> ... │ │ ADC / DAC ---> │ │ LCD Displays ---> ... │ │ [*] HD44780 module driver (Character-LCD) ---> │ │ [-] HR20-style LCD Display ... │ │ (16_Characters_2_Lines) LCD size/type │ │ (HD44780_Compat) LCD controller type │ │ (None) LCD charset conversion │ │ (I2C) Connection type │ │ (PCF8574) I2C Port Expander │ │ [*] Readback support │ │ [*] Backlight support │ │ [*] Backlight on at power-on │ │ [*] Invert Backlight switch '''Configuration options:''' ;LCD size/type : Select one of the defined display sizes and address configurations shown in the table [[#Supported LC-Displays]] above. : : Although it is technically possible to connect more than one display, the HD44780 module supports only one LC-Display at a time. ;LCD controller type : Select LCD controller circuit: : :* HD44780_Compat - most controllers are compatible to Hitachis HD44780 :* KS0066U - Samsungs KS0066U requires a different init routine : : Almost all controllers for alphanumeric character LCDs are more or less HD44780-compatible at least at the feature- and function-level required by e6. : : If in doubt, choose HD44780_Compat. ;LCD charset conversion : Select charset conversion used while writing to the lcd: : :* None - use no charset conversion at all (safes program mem) :* HD44780_Compat - map characters from ISO8859-1 to the original HD44780 charset : : Almost all controllers use their own non-ISO-compatible charset, varying between manufacturers, rom versions, etc. that provides characters from western languages as well as japanese, chinese and graphical glyphs. : : Charset conversion might become useful if you have to display messages and texts from external resources that uses standard encodings for their charset like ISO8859-1. : : Note: Charset conversion uses a lookup table and requires about 272 byte program memory (flash rom). ;Connection type : Select the connection type for the LCD: : :* Direct - direct connection using avr io-pins :* I2C - uses sub-selection of I2C port expander :* SER_LCD(74hct164) - serial connection using HCT164 shift register :* 2WIRE(74hct4094) - serial connection using HCT4094 shift register : : See section [[#Pinning]] below for further explanations. : ;I2C Port Expander : Select I2C Port Expander to use: : :* PCF8574 - use PCF8574x as I2C port expander :* MCP23017 - use MCP23017 as I2C port expander : : Note: automatically enables I2C_MASTER_SUPPORT and I2C_PCF8574X_SUPPORT resp. I2C_MCP23017_SUPPORT when selected. : : Note: Selection is only valid when '''I2C''' was selected under '''Connection type'''. : See section [[#Pinning]] below for further explanations. ;Readback support : Enable support for bi-directional lcd bus to read LCDs busy flag. Supported by direct and I2C connection only. : : You '''definitly should use a readback capable hardware and enable this feature''', saves lots of delays. ;Backlight support : Backlight support for LCDs based on the HD44780 controller. : : Enable backlight on/off control via API and ECMD. ;Backlight on at power-on : Switch on backlight at power-on/reset. ;Invert Backlight switch : Invert backlight logic for low active backlight circuits e.g. found on Pollin AVR NET-IO Add-on. = Pinning = HD44780-based alphanumeric LCDs are connected via 8 databus-lines (D0..D7) and 3 control-lines (RS, EN, R/W). Displays with more than 80 characters usually utilize a second controller and require two EN-signals EN1 and EN2. Another signal BL is needed if backlight control ist required. To save some i/o-pins the HD44780 controller also supports a 4 Bit mode, using only D4..D7. The HD44780 module supports this 4 Bit mode only. Note that in general the signals D0..D3 should not be left open, use a pull-down or tie them to ground. Most displays use 14, 16 or 18-pin connectors with common pinouts but there are sometimes subtle differences. Beside the control- and data-signals all displays require a supply voltage Vdd, usually +5 V, for the logic circuits and another voltage Vo for the display itself. The later is usually derived using a trimmer which allows for contrast adjustment. Some displays require a ''negative'' voltage for the display. Please refer to the datasheet of '''your''' display! Wrong connections may lead to a permanent damage. The HD44780 module supports four different types of connection: Direct, I2C, Serial and 2-Wire. == Direct == The LCD signals RS, RW, EN (resp. EN1 and EN2), D4..D7 and BL are directly connected to AVR port pins. The driver makes no assumptions about the pin mapping, arbitrary pins from different ports may be used to drive the LCD signals. This connection type is Readback-capable. The following example maps the LCD pins to AVR port pins found on the 25 pin Sub-D connector of the Pollin AVR Net-IO board: <code> dnl Direct connection example dnl map LCD pins to Pollin AVR Net-IO dnl 25 pin extension port ifdef(`conf_HD44780', ` pin(HD44780_RS, PC4) pin(HD44780_RW, PC3) pin(HD44780_EN1, PC2) dnl pin(HD44780_EN2, PC5) pin(HD44780_D4, PA0) pin(HD44780_D5, PA1) pin(HD44780_D6, PA2) pin(HD44780_D7, PA3) ') ifdef(`conf_HD44780_BACKLIGHT', ` pin(HD44780_BL, PC6, OUTPUT) ') </code> == I2C == The I2C connection type supports either the 8 Bit PCF8574x, as it is found on the Pollin AVR Net-IO Add-On board, or the 16 Bit MCP23017 I2C Port Expander. LCDs up to 80 characters and only one HD44780 controller may be connected to a PCF8574x including the backlight control pin. LCDs with more than 80 characters require a second enable pin. The address of the port expander and the pinning for the LCD has to be specified for your hardware using the macros shown below. The macro HD44780_PCF8574x_MAPPING defines the pinning for displays with only one enable signal and backlight control, the macro HD44780_PCF8574x_MULTI_MAPPING for displays with two enable signals. Note that backlight control is not supported when using the HD44780_PCF8574x_MULTI_MAPPING macro. The pinning shown in the examples below matches the pinning found on the Pollin AVR Net-IO Add-On board. Remember that you have to replace the inverting backlight control circuitry with a direct connection to connect displays with two enable signals to this board. The macros HD44780_MCP23017_MAPPING and HD44780_MCP23017_MULTI_MAPPING are used to map the LCD pins to one port of the MCP23017. Note that you have to specify either port A or B as shown below, mapping using mixed pins of both ports is not supported by the driver. The additional macro HD44780_MCP23017_MULTI_MAPPING_BL may be used to specify a backlight control signal on another MCP23017 port when the first port is occupied by a display with two enable signals. The driver exclusively controls the pin specified, the other 7 port pins may be used for different purposes. <code> ifelse(value_HD44780_CONNECTION,`HD44780_I2CSUPPORT',`dnl ifelse(value_HD44780_I2C_PORTEXP,`HD44780_I2C_PCF8574', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_PCF8574x_MULTI_MAPPING(ADR, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_PCF8574x_MULTI_MAPPING(0x20, 4, 5, 6, 7, 0, 1, 2, 3)', `dnl dnl HD44780_PCF8574x_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_PCF8574x_MAPPING(0x20, 4, 5, 6, 0, 1, 2, 3, 7)')', value_HD44780_I2C_PORTEXP,`HD44780_I2C_MCP23017', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_MCP23017_MULTI_MAPPING(ADR, PORT, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_MCP23017_MULTI_MAPPING(0x24, B, 4, 5, 6, 7, 0, 1, 2, 3) HD44780_MCP23017_MULTI_MAPPING_BL(0x24, A, 7)', `dnl dnl HD44780_MCP23017_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_MCP23017_MAPPING(0x24, B, 4, 5, 6, 0, 1, 2, 3, 7)')' )dnl ')dnl </code> == Serial (using 74HCT164) == The LCD is connected using a 74HC(T)164 shift register. Refer to Ulrich Radig's [http://www.ulrichradig.de/home/index.php/software/avr-webserver-software avr-webserver] for an example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection requires three AVR port pins pin(HD44780_SER_D, PD4) pin(HD44780_SER_CLK, PD3) pin(HD44780_SER_EN1, PD2) </code> == 2-Wire (using 74HCT4094) == = ECMD = b7ccd7d050704e737bf16acb84a7888faceadeb9 1764 1763 2016-12-09T20:20:09Z Michaelb 718 wikitext text/x-wiki {{i18n|HD44780}} {{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->HD44780 module driver (Character-LCD) |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/lcd https://github.com/ethersex/ethersex/tree/master/hardware/lcd] }} '''THIS WIKI PAGE IS CURRENTLY WORK IN PROGRESS''' The '''HD44780 module''' provides support for common '''alphanumeric character LCDs''' using Hitachis HD44780 and compatible controllers. = Supported LC-Displays = The vast majority of all alphanumeric LC-Displays use Hitachis [https://en.wikipedia.org/wiki/Hitachi_HD44780_LCD_controller HD44780] dot matrix liquid crystal display (LCD) controller. The e6 HD44780 module supports displays of many different sizes utilizing the original HD44780 and compatible controllers. Alphanumeric LCDs are mainly distinguished by their size, the start-address of the per line Display Data-RAM (DDRAM) and the controller type. The original HD44780 controllers can drive up to 80 characters - most displays with more characters use two independent controllers. The following table lists the LC-displays supported by the e6 HD44780 module by size and per line DDRAM start-address: {| class="wikitable" !colspan="1"|Menuconfig !colspan="2"|Size !colspan="4"|DDRAM Startaddress !rowspan="2"|Note: |- !LCD size/type||Characters||Lines||Line 1||Line 2||Line 3||Line 4 |- |8_Characters_1_Line||8||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line||16||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line_Mux16||16||1||0x00||n/a||n/a||n/a||organized as 8 chars, 2 lines |- |20_Characters_1_Line||20||1||0x00||n/a||n/a||n/a|| |- |40_Characters_1_Line||40||1||0x00||n/a||n/a||n/a|| |- |8_Characters_2_Lines||8||2||0x00||0x40||n/a||n/a|| |- |12_Characters_2_Lines||12||2||0x00||0x40||n/a||n/a|| |- |16_Characters_2_Lines||16||2||0x00||0x40||n/a||n/a|| |- |20_Characters_2_Lines||20||2||0x00||0x40||n/a||n/a|| |- |24_Characters_2_Lines||24||2||0x00||0x40||n/a||n/a|| |- |40_Characters_2_Lines||40||2||0x00||0x40||n/a||n/a|| |- |16_Characters_4_Lines||16||4||0x00||0x40||0x10||0x50|| |- |20_Characters_4_Lines||20||4||0x00||0x40||0x14||0x54||Note DDRAM addresses |- |20_Characters_4_Lines_KS0073||20||4||0x00||0x20||0x40||0x60||Note DDRAM addresses |- |27_Characters_4_Lines_2_EN||27||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |- |40_Characters_4_Lines_2_EN||40||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |} '''Note:''' The HD44780 module drivers supports '''alphanumeric character LCDs''' only. Ethersex also has limited support for some graphical displays. Have a look at the LC-Display configuration. = Configuration = ... │ │ Network ---> │ │ I/O ---> ... │ │ ADC / DAC ---> │ │ LCD Displays ---> ... │ │ [*] HD44780 module driver (Character-LCD) ---> │ │ [-] HR20-style LCD Display ... │ │ (16_Characters_2_Lines) LCD size/type │ │ (HD44780_Compat) LCD controller type │ │ (None) LCD charset conversion │ │ (I2C) Connection type │ │ (PCF8574) I2C Port Expander │ │ [*] Readback support │ │ [*] Backlight support │ │ [*] Backlight on at power-on │ │ [*] Invert Backlight switch '''Configuration options:''' ;LCD size/type : Select one of the defined display sizes and address configurations shown in the table [[#Supported LC-Displays]] above. : : Although it is technically possible to connect more than one display, the HD44780 module supports only one LC-Display at a time. ;LCD controller type : Select LCD controller circuit: : :* HD44780_Compat - most controllers are compatible to Hitachis HD44780 :* KS0066U - Samsungs KS0066U requires a different init routine : : Almost all controllers for alphanumeric character LCDs are more or less HD44780-compatible at least at the feature- and function-level required by e6. : : If in doubt, choose HD44780_Compat. ;LCD charset conversion : Select charset conversion used while writing to the lcd: : :* None - use no charset conversion at all (safes program mem) :* HD44780_Compat - map characters from ISO8859-1 to the original HD44780 charset : : Almost all controllers use their own non-ISO-compatible charset, varying between manufacturers, rom versions, etc. that provides characters from western languages as well as japanese, chinese and graphical glyphs. : : Charset conversion might become useful if you have to display messages and texts from external resources that uses standard encodings for their charset like ISO8859-1. : : Note: Charset conversion uses a lookup table and requires about 272 byte program memory (flash rom). ;Connection type : Select the connection type for the LCD: : :* Direct - direct connection using avr io-pins :* I2C - uses sub-selection of I2C port expander :* SER_LCD(74hct164) - serial connection using HCT164 shift register :* 2WIRE(74hct4094) - serial connection using HCT4094 shift register : : See section [[#Pinning]] below for further explanations. : ;I2C Port Expander : Select I2C Port Expander to use: : :* PCF8574 - use PCF8574x as I2C port expander :* MCP23017 - use MCP23017 as I2C port expander : : Note: automatically enables I2C_MASTER_SUPPORT and I2C_PCF8574X_SUPPORT resp. I2C_MCP23017_SUPPORT when selected. : : Note: Selection is only valid when '''I2C''' was selected under '''Connection type'''. : See section [[#Pinning]] below for further explanations. ;Readback support : Enable support for bi-directional lcd bus to read LCDs busy flag. Supported by direct and I2C connection only. : : You '''definitly should use a readback capable hardware and enable this feature''', saves lots of delays. ;Backlight support : Backlight support for LCDs based on the HD44780 controller. : : Enable backlight on/off control via API and ECMD. ;Backlight on at power-on : Switch on backlight at power-on/reset. ;Invert Backlight switch : Invert backlight logic for low active backlight circuits e.g. found on Pollin AVR NET-IO Add-on. = Pinning = HD44780-based alphanumeric LCDs are connected via 8 databus-lines (D0..D7) and 3 control-lines (RS, EN, R/W). Displays with more than 80 characters usually utilize a second controller and require two EN-signals EN1 and EN2. Another signal BL is needed if backlight control ist required. To save some i/o-pins the HD44780 controller also supports a 4 Bit mode, using only D4..D7. The HD44780 module supports this 4 Bit mode only. Note that in general the signals D0..D3 should not be left open, use a pull-down or tie them to ground. Most displays use 14, 16 or 18-pin connectors with common pinouts but there are sometimes subtle differences. Beside the control- and data-signals all displays require a supply voltage Vdd, usually +5 V, for the logic circuits and another voltage Vo for the display itself. The later is usually derived using a trimmer which allows for contrast adjustment. Some displays require a ''negative'' voltage for the display. Please refer to the datasheet of '''your''' display! Wrong connections may lead to a permanent damage. The HD44780 module supports four different types of connection: Direct, I2C, Serial and 2-Wire. == Direct == The LCD signals RS, RW, EN (resp. EN1 and EN2), D4..D7 and BL are directly connected to AVR port pins. The driver makes no assumptions about the pin mapping, arbitrary pins from different ports may be used to drive the LCD signals. This connection type is Readback-capable. The following example maps the LCD pins to AVR port pins found on the 25 pin Sub-D connector of the Pollin AVR Net-IO board: <code> dnl Direct connection example dnl map LCD pins to Pollin AVR Net-IO dnl 25 pin extension port ifdef(`conf_HD44780', ` pin(HD44780_RS, PC4) pin(HD44780_RW, PC3) pin(HD44780_EN1, PC2) dnl pin(HD44780_EN2, PC5) pin(HD44780_D4, PA0) pin(HD44780_D5, PA1) pin(HD44780_D6, PA2) pin(HD44780_D7, PA3) ') ifdef(`conf_HD44780_BACKLIGHT', ` pin(HD44780_BL, PC6, OUTPUT) ') </code> == I2C == The I2C connection type supports either the 8 Bit PCF8574x, as it is found on the Pollin AVR Net-IO Add-On board, or the 16 Bit MCP23017 I2C Port Expander. LCDs up to 80 characters and only one HD44780 controller may be connected to a PCF8574x including the backlight control pin. LCDs with more than 80 characters require a second enable pin. The address of the port expander and the pinning for the LCD has to be specified for your hardware using the macros shown below. The macro HD44780_PCF8574x_MAPPING defines the pinning for displays with only one enable signal and backlight control, the macro HD44780_PCF8574x_MULTI_MAPPING for displays with two enable signals. Note that backlight control is not supported when using the HD44780_PCF8574x_MULTI_MAPPING macro. The pinning shown in the examples below matches the pinning found on the Pollin AVR Net-IO Add-On board. Remember that you have to replace the inverting backlight control circuitry with a direct connection to connect displays with two enable signals to this board. The macros HD44780_MCP23017_MAPPING and HD44780_MCP23017_MULTI_MAPPING are used to map the LCD pins to one port of the MCP23017. Note that you have to specify either port A or B as shown below, mapping using mixed pins of both ports is not supported by the driver. The additional macro HD44780_MCP23017_MULTI_MAPPING_BL may be used to specify a backlight control signal on another MCP23017 port when the first port is occupied by a display with two enable signals. The driver exclusively controls the pin specified, the other 7 port pins may be used for different purposes. <code> ifelse(value_HD44780_CONNECTION,`HD44780_I2CSUPPORT',`dnl ifelse(value_HD44780_I2C_PORTEXP,`HD44780_I2C_PCF8574', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_PCF8574x_MULTI_MAPPING(ADR, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_PCF8574x_MULTI_MAPPING(0x20, 4, 5, 6, 7, 0, 1, 2, 3)', `dnl dnl HD44780_PCF8574x_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_PCF8574x_MAPPING(0x20, 4, 5, 6, 0, 1, 2, 3, 7)')', value_HD44780_I2C_PORTEXP,`HD44780_I2C_MCP23017', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_MCP23017_MULTI_MAPPING(ADR, PORT, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_MCP23017_MULTI_MAPPING(0x24, B, 4, 5, 6, 7, 0, 1, 2, 3) HD44780_MCP23017_MULTI_MAPPING_BL(0x24, A, 7)', `dnl dnl HD44780_MCP23017_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_MCP23017_MAPPING(0x24, B, 4, 5, 6, 0, 1, 2, 3, 7)')' )dnl ')dnl </code> == Serial (using 74HCT164) == The LCD is connected using a 74HC(T)164 shift register. Refer to Ulrich Radig's [http://www.ulrichradig.de/home/index.php/software/avr-webserver-software avr-webserver] for an example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection requires three AVR port pins pin(HD44780_SER_D, PD4) pin(HD44780_SER_CLK, PD3) pin(HD44780_SER_EN1, PD2) </code> == 2-Wire (using 74HCT4094) == The LCD is connected using a 74HC(T)4094 shift register. Refer to [http://www.cczwei.de/atm18_downloads/071148-D%20CC2-AVR-board-2.pdf this] paper for an explanation and example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection using a 4094 shift register requires two AVR port pins ifdef(`HD44780_2WIRE', ` pin(HD44780_2WIRE_D, PC0) pin(HD44780_2WIRE_CLK, PC1) ') </code> f1ecb8a55c8b5ee8940a1d343003bfc51efed4e4 1765 1764 2016-12-09T20:24:05Z Michaelb 718 wikitext text/x-wiki {{i18n|HD44780}} {{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->HD44780 module driver (Character-LCD) |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/lcd https://github.com/ethersex/ethersex/tree/master/hardware/lcd] }} ---- '''''THIS WIKI PAGE IS CURRENTLY WORK IN PROGRESS''''' ---- The '''HD44780 module''' provides support for common '''alphanumeric character LCDs''' using Hitachis HD44780 and compatible controllers. = Supported LC-Displays = The vast majority of all alphanumeric LC-Displays use Hitachis [https://en.wikipedia.org/wiki/Hitachi_HD44780_LCD_controller HD44780] dot matrix liquid crystal display (LCD) controller. The e6 HD44780 module supports displays of many different sizes utilizing the original HD44780 and compatible controllers. Alphanumeric LCDs are mainly distinguished by their size, the start-address of the per line Display Data-RAM (DDRAM) and the controller type. The original HD44780 controllers can drive up to 80 characters - most displays with more characters use two independent controllers. The following table lists the LC-displays supported by the e6 HD44780 module by size and per line DDRAM start-address: {| class="wikitable" !colspan="1"|Menuconfig !colspan="2"|Size !colspan="4"|DDRAM Startaddress !rowspan="2"|Note: |- !LCD size/type||Characters||Lines||Line 1||Line 2||Line 3||Line 4 |- |8_Characters_1_Line||8||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line||16||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line_Mux16||16||1||0x00||n/a||n/a||n/a||organized as 8 chars, 2 lines |- |20_Characters_1_Line||20||1||0x00||n/a||n/a||n/a|| |- |40_Characters_1_Line||40||1||0x00||n/a||n/a||n/a|| |- |8_Characters_2_Lines||8||2||0x00||0x40||n/a||n/a|| |- |12_Characters_2_Lines||12||2||0x00||0x40||n/a||n/a|| |- |16_Characters_2_Lines||16||2||0x00||0x40||n/a||n/a|| |- |20_Characters_2_Lines||20||2||0x00||0x40||n/a||n/a|| |- |24_Characters_2_Lines||24||2||0x00||0x40||n/a||n/a|| |- |40_Characters_2_Lines||40||2||0x00||0x40||n/a||n/a|| |- |16_Characters_4_Lines||16||4||0x00||0x40||0x10||0x50|| |- |20_Characters_4_Lines||20||4||0x00||0x40||0x14||0x54||Note DDRAM addresses |- |20_Characters_4_Lines_KS0073||20||4||0x00||0x20||0x40||0x60||Note DDRAM addresses |- |27_Characters_4_Lines_2_EN||27||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |- |40_Characters_4_Lines_2_EN||40||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |} '''Note:''' The HD44780 module drivers supports '''alphanumeric character LCDs''' only. Ethersex also has limited support for some graphical displays. Have a look at the LC-Display configuration. = Configuration = ... │ │ Network ---> │ │ I/O ---> ... │ │ ADC / DAC ---> │ │ LCD Displays ---> ... │ │ [*] HD44780 module driver (Character-LCD) ---> │ │ [-] HR20-style LCD Display ... │ │ (16_Characters_2_Lines) LCD size/type │ │ (HD44780_Compat) LCD controller type │ │ (None) LCD charset conversion │ │ (I2C) Connection type │ │ (PCF8574) I2C Port Expander │ │ [*] Readback support │ │ [*] Backlight support │ │ [*] Backlight on at power-on │ │ [*] Invert Backlight switch '''Configuration options:''' ;LCD size/type : Select one of the defined display sizes and address configurations shown in the table [[#Supported LC-Displays]] above. : : Although it is technically possible to connect more than one display, the HD44780 module supports only one LC-Display at a time. ;LCD controller type : Select LCD controller circuit: : :* HD44780_Compat - most controllers are compatible to Hitachis HD44780 :* KS0066U - Samsungs KS0066U requires a different init routine : : Almost all controllers for alphanumeric character LCDs are more or less HD44780-compatible at least at the feature- and function-level required by e6. : : If in doubt, choose HD44780_Compat. ;LCD charset conversion : Select charset conversion used while writing to the lcd: : :* None - use no charset conversion at all (safes program mem) :* HD44780_Compat - map characters from ISO8859-1 to the original HD44780 charset : : Almost all controllers use their own non-ISO-compatible charset, varying between manufacturers, rom versions, etc. that provides characters from western languages as well as japanese, chinese and graphical glyphs. : : Charset conversion might become useful if you have to display messages and texts from external resources that uses standard encodings for their charset like ISO8859-1. : : Note: Charset conversion uses a lookup table and requires about 272 byte program memory (flash rom). ;Connection type : Select the connection type for the LCD: : :* Direct - direct connection using avr io-pins :* I2C - uses sub-selection of I2C port expander :* SER_LCD(74hct164) - serial connection using HCT164 shift register :* 2WIRE(74hct4094) - serial connection using HCT4094 shift register : : See section [[#Pinning]] below for further explanations. : ;I2C Port Expander : Select I2C Port Expander to use: : :* PCF8574 - use PCF8574x as I2C port expander :* MCP23017 - use MCP23017 as I2C port expander : : Note: automatically enables I2C_MASTER_SUPPORT and I2C_PCF8574X_SUPPORT resp. I2C_MCP23017_SUPPORT when selected. : : Note: Selection is only valid when '''I2C''' was selected under '''Connection type'''. : See section [[#Pinning]] below for further explanations. ;Readback support : Enable support for bi-directional lcd bus to read LCDs busy flag. Supported by direct and I2C connection only. : : You '''definitly should use a readback capable hardware and enable this feature''', saves lots of delays. ;Backlight support : Backlight support for LCDs based on the HD44780 controller. : : Enable backlight on/off control via API and ECMD. ;Backlight on at power-on : Switch on backlight at power-on/reset. ;Invert Backlight switch : Invert backlight logic for low active backlight circuits e.g. found on Pollin AVR NET-IO Add-on. = Pinning = HD44780-based alphanumeric LCDs are connected via 8 databus-lines (D0..D7) and 3 control-lines (RS, EN, R/W). Displays with more than 80 characters usually utilize a second controller and require two EN-signals EN1 and EN2. Another signal BL is needed if backlight control ist required. To save some i/o-pins the HD44780 controller also supports a 4 Bit mode, using only D4..D7. The HD44780 module supports this 4 Bit mode only. Note that in general the signals D0..D3 should not be left open, use a pull-down or tie them to ground. Most displays use 14, 16 or 18-pin connectors with common pinouts but there are sometimes subtle differences. Beside the control- and data-signals all displays require a supply voltage Vdd, usually +5 V, for the logic circuits and another voltage Vo for the display itself. The later is usually derived using a trimmer which allows for contrast adjustment. Some displays require a ''negative'' voltage for the display. Please refer to the datasheet of '''your''' display! Wrong connections may lead to a permanent damage. The HD44780 module supports four different types of connection: Direct, I2C, Serial and 2-Wire. == Direct == The LCD signals RS, RW, EN (resp. EN1 and EN2), D4..D7 and BL are directly connected to AVR port pins. The driver makes no assumptions about the pin mapping, arbitrary pins from different ports may be used to drive the LCD signals. This connection type is Readback-capable. The following example maps the LCD pins to AVR port pins found on the 25 pin Sub-D connector of the Pollin AVR Net-IO board: <code> dnl Direct connection example dnl map LCD pins to Pollin AVR Net-IO dnl 25 pin extension port ifdef(`conf_HD44780', ` pin(HD44780_RS, PC4) pin(HD44780_RW, PC3) pin(HD44780_EN1, PC2) dnl pin(HD44780_EN2, PC5) pin(HD44780_D4, PA0) pin(HD44780_D5, PA1) pin(HD44780_D6, PA2) pin(HD44780_D7, PA3) ') ifdef(`conf_HD44780_BACKLIGHT', ` pin(HD44780_BL, PC6, OUTPUT) ') </code> == I2C == The I2C connection type supports either the 8 Bit PCF8574x, as it is found on the Pollin AVR Net-IO Add-On board, or the 16 Bit MCP23017 I2C Port Expander. LCDs up to 80 characters and only one HD44780 controller may be connected to a PCF8574x including the backlight control pin. LCDs with more than 80 characters require a second enable pin. The address of the port expander and the pinning for the LCD has to be specified for your hardware using the macros shown below. The macro HD44780_PCF8574x_MAPPING defines the pinning for displays with only one enable signal and backlight control, the macro HD44780_PCF8574x_MULTI_MAPPING for displays with two enable signals. Note that backlight control is not supported when using the HD44780_PCF8574x_MULTI_MAPPING macro. The pinning shown in the examples below matches the pinning found on the Pollin AVR Net-IO Add-On board. Remember that you have to replace the inverting backlight control circuitry with a direct connection to connect displays with two enable signals to this board. The macros HD44780_MCP23017_MAPPING and HD44780_MCP23017_MULTI_MAPPING are used to map the LCD pins to one port of the MCP23017. Note that you have to specify either port A or B as shown below, mapping using mixed pins of both ports is not supported by the driver. The additional macro HD44780_MCP23017_MULTI_MAPPING_BL may be used to specify a backlight control signal on another MCP23017 port when the first port is occupied by a display with two enable signals. The driver exclusively controls the pin specified, the other 7 port pins may be used for different purposes. <code> ifelse(value_HD44780_CONNECTION,`HD44780_I2CSUPPORT',`dnl ifelse(value_HD44780_I2C_PORTEXP,`HD44780_I2C_PCF8574', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_PCF8574x_MULTI_MAPPING(ADR, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_PCF8574x_MULTI_MAPPING(0x20, 4, 5, 6, 7, 0, 1, 2, 3)', `dnl dnl HD44780_PCF8574x_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_PCF8574x_MAPPING(0x20, 4, 5, 6, 0, 1, 2, 3, 7)')', value_HD44780_I2C_PORTEXP,`HD44780_I2C_MCP23017', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_MCP23017_MULTI_MAPPING(ADR, PORT, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_MCP23017_MULTI_MAPPING(0x24, B, 4, 5, 6, 7, 0, 1, 2, 3) HD44780_MCP23017_MULTI_MAPPING_BL(0x24, A, 7)', `dnl dnl HD44780_MCP23017_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_MCP23017_MAPPING(0x24, B, 4, 5, 6, 0, 1, 2, 3, 7)')' )dnl ')dnl </code> == Serial (using 74HCT164) == The LCD is connected using a 74HC(T)164 shift register. Refer to Ulrich Radig's [http://www.ulrichradig.de/home/index.php/software/avr-webserver-software avr-webserver] for an example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection requires three AVR port pins pin(HD44780_SER_D, PD4) pin(HD44780_SER_CLK, PD3) pin(HD44780_SER_EN1, PD2) </code> == 2-Wire (using 74HCT4094) == The LCD is connected using a 74HC(T)4094 shift register. Refer to [http://www.cczwei.de/atm18_downloads/071148-D%20CC2-AVR-board-2.pdf this] paper for an explanation and example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection using a 4094 shift register requires two AVR port pins ifdef(`HD44780_2WIRE', ` pin(HD44780_2WIRE_D, PC0) pin(HD44780_2WIRE_CLK, PC1) ') </code> 3a7b968d53007f6185c263a2072dc96f759cfb79 1767 1765 2016-12-09T20:52:46Z Michaelb 718 /* Supported LC-Displays */ wikitext text/x-wiki {{i18n|HD44780}} {{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->HD44780 module driver (Character-LCD) |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/lcd https://github.com/ethersex/ethersex/tree/master/hardware/lcd] }} ---- '''''THIS WIKI PAGE IS CURRENTLY WORK IN PROGRESS''''' ---- The '''HD44780 module''' provides support for common '''alphanumeric character LCDs''' using Hitachis HD44780 and compatible controllers. = Supported LC-Displays = The vast majority of all alphanumeric LC-Displays use Hitachis [https://en.wikipedia.org/wiki/Hitachi_HD44780_LCD_controller HD44780] dot matrix liquid crystal display (LCD) controller. The e6 HD44780 module supports displays of many different sizes utilizing the original HD44780 and compatible controllers. Alphanumeric LCDs are mainly distinguished by their size, the start-address of the per line Display Data-RAM (DDRAM) and the controller type. The original HD44780 controllers can drive up to 80 characters - most displays with more characters use two independent controllers. The following table lists the LC-displays supported by the e6 HD44780 module by size and per line DDRAM start-address: [[File:HD44780 Testbed.jpg|thumb|400px|right|HD44780 module test]] {| class="wikitable" !colspan="1"|Menuconfig !colspan="2"|Size !colspan="4"|DDRAM Startaddress !rowspan="2"|Note: |- !LCD size/type||Characters||Lines||Line 1||Line 2||Line 3||Line 4 |- |8_Characters_1_Line||8||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line||16||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line_Mux16||16||1||0x00||n/a||n/a||n/a||organized as 8 chars, 2 lines |- |20_Characters_1_Line||20||1||0x00||n/a||n/a||n/a|| |- |40_Characters_1_Line||40||1||0x00||n/a||n/a||n/a|| |- |8_Characters_2_Lines||8||2||0x00||0x40||n/a||n/a|| |- |12_Characters_2_Lines||12||2||0x00||0x40||n/a||n/a|| |- |16_Characters_2_Lines||16||2||0x00||0x40||n/a||n/a|| |- |20_Characters_2_Lines||20||2||0x00||0x40||n/a||n/a|| |- |24_Characters_2_Lines||24||2||0x00||0x40||n/a||n/a|| |- |40_Characters_2_Lines||40||2||0x00||0x40||n/a||n/a|| |- |16_Characters_4_Lines||16||4||0x00||0x40||0x10||0x50|| |- |20_Characters_4_Lines||20||4||0x00||0x40||0x14||0x54||Note DDRAM addresses |- |20_Characters_4_Lines_KS0073||20||4||0x00||0x20||0x40||0x60||Note DDRAM addresses |- |27_Characters_4_Lines_2_EN||27||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |- |40_Characters_4_Lines_2_EN||40||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |} '''Note:''' The HD44780 module drivers supports '''alphanumeric character LCDs''' only. Ethersex also has limited support for some graphical displays. Have a look at the LC-Display configuration. = Configuration = ... │ │ Network ---> │ │ I/O ---> ... │ │ ADC / DAC ---> │ │ LCD Displays ---> ... │ │ [*] HD44780 module driver (Character-LCD) ---> │ │ [-] HR20-style LCD Display ... │ │ (16_Characters_2_Lines) LCD size/type │ │ (HD44780_Compat) LCD controller type │ │ (None) LCD charset conversion │ │ (I2C) Connection type │ │ (PCF8574) I2C Port Expander │ │ [*] Readback support │ │ [*] Backlight support │ │ [*] Backlight on at power-on │ │ [*] Invert Backlight switch '''Configuration options:''' ;LCD size/type : Select one of the defined display sizes and address configurations shown in the table [[#Supported LC-Displays]] above. : : Although it is technically possible to connect more than one display, the HD44780 module supports only one LC-Display at a time. ;LCD controller type : Select LCD controller circuit: : :* HD44780_Compat - most controllers are compatible to Hitachis HD44780 :* KS0066U - Samsungs KS0066U requires a different init routine : : Almost all controllers for alphanumeric character LCDs are more or less HD44780-compatible at least at the feature- and function-level required by e6. : : If in doubt, choose HD44780_Compat. ;LCD charset conversion : Select charset conversion used while writing to the lcd: : :* None - use no charset conversion at all (safes program mem) :* HD44780_Compat - map characters from ISO8859-1 to the original HD44780 charset : : Almost all controllers use their own non-ISO-compatible charset, varying between manufacturers, rom versions, etc. that provides characters from western languages as well as japanese, chinese and graphical glyphs. : : Charset conversion might become useful if you have to display messages and texts from external resources that uses standard encodings for their charset like ISO8859-1. : : Note: Charset conversion uses a lookup table and requires about 272 byte program memory (flash rom). ;Connection type : Select the connection type for the LCD: : :* Direct - direct connection using avr io-pins :* I2C - uses sub-selection of I2C port expander :* SER_LCD(74hct164) - serial connection using HCT164 shift register :* 2WIRE(74hct4094) - serial connection using HCT4094 shift register : : See section [[#Pinning]] below for further explanations. : ;I2C Port Expander : Select I2C Port Expander to use: : :* PCF8574 - use PCF8574x as I2C port expander :* MCP23017 - use MCP23017 as I2C port expander : : Note: automatically enables I2C_MASTER_SUPPORT and I2C_PCF8574X_SUPPORT resp. I2C_MCP23017_SUPPORT when selected. : : Note: Selection is only valid when '''I2C''' was selected under '''Connection type'''. : See section [[#Pinning]] below for further explanations. ;Readback support : Enable support for bi-directional lcd bus to read LCDs busy flag. Supported by direct and I2C connection only. : : You '''definitly should use a readback capable hardware and enable this feature''', saves lots of delays. ;Backlight support : Backlight support for LCDs based on the HD44780 controller. : : Enable backlight on/off control via API and ECMD. ;Backlight on at power-on : Switch on backlight at power-on/reset. ;Invert Backlight switch : Invert backlight logic for low active backlight circuits e.g. found on Pollin AVR NET-IO Add-on. = Pinning = HD44780-based alphanumeric LCDs are connected via 8 databus-lines (D0..D7) and 3 control-lines (RS, EN, R/W). Displays with more than 80 characters usually utilize a second controller and require two EN-signals EN1 and EN2. Another signal BL is needed if backlight control ist required. To save some i/o-pins the HD44780 controller also supports a 4 Bit mode, using only D4..D7. The HD44780 module supports this 4 Bit mode only. Note that in general the signals D0..D3 should not be left open, use a pull-down or tie them to ground. Most displays use 14, 16 or 18-pin connectors with common pinouts but there are sometimes subtle differences. Beside the control- and data-signals all displays require a supply voltage Vdd, usually +5 V, for the logic circuits and another voltage Vo for the display itself. The later is usually derived using a trimmer which allows for contrast adjustment. Some displays require a ''negative'' voltage for the display. Please refer to the datasheet of '''your''' display! Wrong connections may lead to a permanent damage. The HD44780 module supports four different types of connection: Direct, I2C, Serial and 2-Wire. == Direct == The LCD signals RS, RW, EN (resp. EN1 and EN2), D4..D7 and BL are directly connected to AVR port pins. The driver makes no assumptions about the pin mapping, arbitrary pins from different ports may be used to drive the LCD signals. This connection type is Readback-capable. The following example maps the LCD pins to AVR port pins found on the 25 pin Sub-D connector of the Pollin AVR Net-IO board: <code> dnl Direct connection example dnl map LCD pins to Pollin AVR Net-IO dnl 25 pin extension port ifdef(`conf_HD44780', ` pin(HD44780_RS, PC4) pin(HD44780_RW, PC3) pin(HD44780_EN1, PC2) dnl pin(HD44780_EN2, PC5) pin(HD44780_D4, PA0) pin(HD44780_D5, PA1) pin(HD44780_D6, PA2) pin(HD44780_D7, PA3) ') ifdef(`conf_HD44780_BACKLIGHT', ` pin(HD44780_BL, PC6, OUTPUT) ') </code> == I2C == The I2C connection type supports either the 8 Bit PCF8574x, as it is found on the Pollin AVR Net-IO Add-On board, or the 16 Bit MCP23017 I2C Port Expander. LCDs up to 80 characters and only one HD44780 controller may be connected to a PCF8574x including the backlight control pin. LCDs with more than 80 characters require a second enable pin. The address of the port expander and the pinning for the LCD has to be specified for your hardware using the macros shown below. The macro HD44780_PCF8574x_MAPPING defines the pinning for displays with only one enable signal and backlight control, the macro HD44780_PCF8574x_MULTI_MAPPING for displays with two enable signals. Note that backlight control is not supported when using the HD44780_PCF8574x_MULTI_MAPPING macro. The pinning shown in the examples below matches the pinning found on the Pollin AVR Net-IO Add-On board. Remember that you have to replace the inverting backlight control circuitry with a direct connection to connect displays with two enable signals to this board. The macros HD44780_MCP23017_MAPPING and HD44780_MCP23017_MULTI_MAPPING are used to map the LCD pins to one port of the MCP23017. Note that you have to specify either port A or B as shown below, mapping using mixed pins of both ports is not supported by the driver. The additional macro HD44780_MCP23017_MULTI_MAPPING_BL may be used to specify a backlight control signal on another MCP23017 port when the first port is occupied by a display with two enable signals. The driver exclusively controls the pin specified, the other 7 port pins may be used for different purposes. <code> ifelse(value_HD44780_CONNECTION,`HD44780_I2CSUPPORT',`dnl ifelse(value_HD44780_I2C_PORTEXP,`HD44780_I2C_PCF8574', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_PCF8574x_MULTI_MAPPING(ADR, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_PCF8574x_MULTI_MAPPING(0x20, 4, 5, 6, 7, 0, 1, 2, 3)', `dnl dnl HD44780_PCF8574x_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_PCF8574x_MAPPING(0x20, 4, 5, 6, 0, 1, 2, 3, 7)')', value_HD44780_I2C_PORTEXP,`HD44780_I2C_MCP23017', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_MCP23017_MULTI_MAPPING(ADR, PORT, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_MCP23017_MULTI_MAPPING(0x24, B, 4, 5, 6, 7, 0, 1, 2, 3) HD44780_MCP23017_MULTI_MAPPING_BL(0x24, A, 7)', `dnl dnl HD44780_MCP23017_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_MCP23017_MAPPING(0x24, B, 4, 5, 6, 0, 1, 2, 3, 7)')' )dnl ')dnl </code> == Serial (using 74HCT164) == The LCD is connected using a 74HC(T)164 shift register. Refer to Ulrich Radig's [http://www.ulrichradig.de/home/index.php/software/avr-webserver-software avr-webserver] for an example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection requires three AVR port pins pin(HD44780_SER_D, PD4) pin(HD44780_SER_CLK, PD3) pin(HD44780_SER_EN1, PD2) </code> == 2-Wire (using 74HCT4094) == The LCD is connected using a 74HC(T)4094 shift register. Refer to [http://www.cczwei.de/atm18_downloads/071148-D%20CC2-AVR-board-2.pdf this] paper for an explanation and example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection using a 4094 shift register requires two AVR port pins ifdef(`HD44780_2WIRE', ` pin(HD44780_2WIRE_D, PC0) pin(HD44780_2WIRE_CLK, PC1) ') </code> 3626ce4cf8048d2bb261909aaf50143d1d437378 1769 1767 2016-12-09T22:49:21Z Michaelb 718 wikitext text/x-wiki {{i18n|HD44780}} {{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->HD44780 module driver (Character-LCD) |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/lcd https://github.com/ethersex/ethersex/tree/master/hardware/lcd] }} ---- '''''THIS WIKI PAGE IS CURRENTLY WORK IN PROGRESS''''' ---- The '''HD44780 module''' provides support for common '''alphanumeric character LCDs''' using Hitachis HD44780 and compatible controllers. = Supported LC-Displays = The vast majority of all alphanumeric LC-Displays use Hitachis [https://en.wikipedia.org/wiki/Hitachi_HD44780_LCD_controller HD44780] dot matrix liquid crystal display (LCD) controller. The e6 HD44780 module supports displays of many different sizes utilizing the original HD44780 and compatible controllers. Alphanumeric LCDs are mainly distinguished by their size, the start-address of the per line Display Data-RAM (DDRAM) and the controller type. The original HD44780 controllers can drive up to 80 characters - most displays with more characters use two independent controllers. The following table lists the LC-displays supported by the e6 HD44780 module by size and per line DDRAM start-address: [[File:HD44780 Testbed.jpg|thumb|400px|right|HD44780 module test]] {| class="wikitable" !colspan="1"|Menuconfig !colspan="2"|Size !colspan="4"|DDRAM Startaddress !rowspan="2"|Note: |- !LCD size/type||Characters||Lines||Line 1||Line 2||Line 3||Line 4 |- |8_Characters_1_Line||8||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line||16||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line_Mux16||16||1||0x00||n/a||n/a||n/a||organized as 8 chars, 2 lines |- |20_Characters_1_Line||20||1||0x00||n/a||n/a||n/a|| |- |40_Characters_1_Line||40||1||0x00||n/a||n/a||n/a|| |- |8_Characters_2_Lines||8||2||0x00||0x40||n/a||n/a|| |- |12_Characters_2_Lines||12||2||0x00||0x40||n/a||n/a|| |- |16_Characters_2_Lines||16||2||0x00||0x40||n/a||n/a|| |- |20_Characters_2_Lines||20||2||0x00||0x40||n/a||n/a|| |- |24_Characters_2_Lines||24||2||0x00||0x40||n/a||n/a|| |- |40_Characters_2_Lines||40||2||0x00||0x40||n/a||n/a|| |- |16_Characters_4_Lines||16||4||0x00||0x40||0x10||0x50|| |- |20_Characters_4_Lines||20||4||0x00||0x40||0x14||0x54||Note DDRAM addresses |- |20_Characters_4_Lines_KS0073||20||4||0x00||0x20||0x40||0x60||Note DDRAM addresses |- |27_Characters_4_Lines_2_EN||27||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |- |40_Characters_4_Lines_2_EN||40||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |} '''Note:''' The HD44780 module drivers supports '''alphanumeric character LCDs''' only. Ethersex also has limited support for some graphical displays. Have a look at the LC-Display configuration. = Configuration = ... │ │ Network ---> │ │ I/O ---> ... │ │ ADC / DAC ---> │ │ LCD Displays ---> ... │ │ [*] HD44780 module driver (Character-LCD) ---> │ │ [-] HR20-style LCD Display ... │ │ (16_Characters_2_Lines) LCD size/type │ │ (HD44780_Compat) LCD controller type │ │ (None) LCD charset conversion │ │ (I2C) Connection type │ │ (PCF8574) I2C Port Expander │ │ [*] Readback support │ │ [*] Backlight support │ │ [*] Backlight on at power-on │ │ [*] Invert Backlight switch '''Configuration options:''' ;LCD size/type : Select one of the defined display sizes and address configurations shown in the table [[#Supported LC-Displays]] above. : : Although it is technically possible to connect more than one display, the HD44780 module supports only one LC-Display at a time. ;LCD controller type : Select LCD controller circuit: : :* HD44780_Compat - most controllers are compatible to Hitachis HD44780 :* KS0066U - Samsungs KS0066U requires a different init routine : : Almost all controllers for alphanumeric character LCDs are more or less HD44780-compatible at least at the feature- and function-level required by e6. : : If in doubt, choose HD44780_Compat. ;LCD charset conversion : Select charset conversion used while writing to the lcd: : :* None - use no charset conversion at all (safes program mem) :* HD44780_Compat - map characters from ISO8859-1 to the original HD44780 charset : : Almost all controllers use their own non-ISO-compatible charset, varying between manufacturers, rom versions, etc. that provides characters from western languages as well as japanese, chinese and graphical glyphs. : : Charset conversion might become useful if you have to display messages and texts from external resources that uses standard encodings for their charset like ISO8859-1. : : Note: Charset conversion uses a lookup table and requires about 272 byte program memory (flash rom). ;Connection type : Select the connection type for the LCD: : :* Direct - direct connection using avr io-pins :* I2C - uses sub-selection of I2C port expander :* SER_LCD(74hct164) - serial connection using HCT164 shift register :* 2WIRE(74hct4094) - serial connection using HCT4094 shift register : : See section [[#Pinning]] below for further explanations. : ;I2C Port Expander : Select I2C Port Expander to use: : :* PCF8574 - use PCF8574x as I2C port expander :* MCP23017 - use MCP23017 as I2C port expander : : Note: automatically enables I2C_MASTER_SUPPORT and I2C_PCF8574X_SUPPORT resp. I2C_MCP23017_SUPPORT when selected. : : Note: Selection is only valid when '''I2C''' was selected under '''Connection type'''. : See section [[#Pinning]] below for further explanations. ;Readback support : Enable support for bi-directional lcd bus to read LCDs busy flag. Supported by direct and I2C connection only. : : You '''definitly should use a readback capable hardware and enable this feature''', saves lots of delays. ;Backlight support : Backlight support for LCDs based on the HD44780 controller. : : Enable backlight on/off control via API and ECMD. ;Backlight on at power-on : Switch on backlight at power-on/reset. ;Invert Backlight switch : Invert backlight logic for low active backlight circuits e.g. found on Pollin AVR NET-IO Add-on. = Pinning = HD44780-based alphanumeric LCDs are connected via 8 databus-lines (D0..D7) and 3 control-lines (RS, EN, R/W). Displays with more than 80 characters usually utilize a second controller and require two EN-signals EN1 and EN2. Another signal BL is needed if backlight control ist required. To save some i/o-pins the HD44780 controller also supports a 4 Bit mode, using only D4..D7. The HD44780 module supports this 4 Bit mode only. Note that in general the signals D0..D3 should not be left open, use a pull-down or tie them to ground. Most displays use 14, 16 or 18-pin connectors with common pinouts but there are sometimes subtle differences. Beside the control- and data-signals all displays require a supply voltage Vdd, usually +5 V, for the logic circuits and another voltage Vo for the display itself. The later is usually derived using a trimmer which allows for contrast adjustment. Some displays require a ''negative'' voltage for the display. Please refer to the datasheet of '''your''' display! Wrong connections may lead to a permanent damage. The HD44780 module supports four different types of connection: Direct, I2C, Serial and 2-Wire. == Direct == The LCD signals RS, RW, EN (resp. EN1 and EN2), D4..D7 and BL are directly connected to AVR port pins. The driver makes no assumptions about the pin mapping, arbitrary pins from different ports may be used to drive the LCD signals. This connection type is Readback-capable. The following example maps the LCD pins to AVR port pins found on the 25 pin Sub-D connector of the Pollin AVR Net-IO board: <code> dnl Direct connection example dnl map LCD pins to Pollin AVR Net-IO dnl 25 pin extension port ifdef(`conf_HD44780', ` pin(HD44780_RS, PC4) pin(HD44780_RW, PC3) pin(HD44780_EN1, PC2) dnl pin(HD44780_EN2, PC5) pin(HD44780_D4, PA0) pin(HD44780_D5, PA1) pin(HD44780_D6, PA2) pin(HD44780_D7, PA3) ') ifdef(`conf_HD44780_BACKLIGHT', ` pin(HD44780_BL, PC6, OUTPUT) ') </code> == I2C == The I2C connection type supports either the 8 Bit PCF8574x, as it is found on the Pollin AVR Net-IO Add-On board, or the 16 Bit MCP23017 I2C Port Expander. LCDs up to 80 characters and only one HD44780 controller may be connected to a PCF8574x including the backlight control pin. LCDs with more than 80 characters require a second enable pin. The address of the port expander and the pinning for the LCD has to be specified for your hardware using the macros shown below. The macro HD44780_PCF8574x_MAPPING defines the pinning for displays with only one enable signal and backlight control, the macro HD44780_PCF8574x_MULTI_MAPPING for displays with two enable signals. Note that backlight control is not supported when using the HD44780_PCF8574x_MULTI_MAPPING macro. The pinning shown in the examples below matches the pinning found on the Pollin AVR Net-IO Add-On board. Remember that you have to replace the inverting backlight control circuitry with a direct connection to connect displays with two enable signals to this board. The macros HD44780_MCP23017_MAPPING and HD44780_MCP23017_MULTI_MAPPING are used to map the LCD pins to one port of the MCP23017. Note that you have to specify either port A or B as shown below, mapping using mixed pins of both ports is not supported by the driver. The additional macro HD44780_MCP23017_MULTI_MAPPING_BL may be used to specify a backlight control signal on another MCP23017 port when the first port is occupied by a display with two enable signals. The driver exclusively controls the pin specified, the other 7 port pins may be used for different purposes. [[FILE:foo.jpg|thumb|400px|right|Displaytech 404b showing ECMD lcd print charset 0 128 with activated charset conversion]] <code> ifelse(value_HD44780_CONNECTION,`HD44780_I2CSUPPORT',`dnl ifelse(value_HD44780_I2C_PORTEXP,`HD44780_I2C_PCF8574', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_PCF8574x_MULTI_MAPPING(ADR, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_PCF8574x_MULTI_MAPPING(0x20, 4, 5, 6, 7, 0, 1, 2, 3)', `dnl dnl HD44780_PCF8574x_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_PCF8574x_MAPPING(0x20, 4, 5, 6, 0, 1, 2, 3, 7)')', value_HD44780_I2C_PORTEXP,`HD44780_I2C_MCP23017', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_MCP23017_MULTI_MAPPING(ADR, PORT, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_MCP23017_MULTI_MAPPING(0x24, B, 4, 5, 6, 7, 0, 1, 2, 3) HD44780_MCP23017_MULTI_MAPPING_BL(0x24, A, 7)', `dnl dnl HD44780_MCP23017_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_MCP23017_MAPPING(0x24, B, 4, 5, 6, 0, 1, 2, 3, 7)')' )dnl ')dnl </code> == Serial (using 74HCT164) == The LCD is connected using a 74HC(T)164 shift register. Refer to Ulrich Radig's [http://www.ulrichradig.de/home/index.php/software/avr-webserver-software avr-webserver] for an example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection requires three AVR port pins pin(HD44780_SER_D, PD4) pin(HD44780_SER_CLK, PD3) pin(HD44780_SER_EN1, PD2) </code> == 2-Wire (using 74HCT4094) == The LCD is connected using a 74HC(T)4094 shift register. Refer to [http://www.cczwei.de/atm18_downloads/071148-D%20CC2-AVR-board-2.pdf this] paper for an explanation and example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection using a 4094 shift register requires two AVR port pins ifdef(`HD44780_2WIRE', ` pin(HD44780_2WIRE_D, PC0) pin(HD44780_2WIRE_CLK, PC1) ') </code> 4898a076cae400e0bea226debf407ee70065dafc 1770 1769 2016-12-09T22:58:32Z Michaelb 718 wikitext text/x-wiki {{i18n|HD44780}} {{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->HD44780 module driver (Character-LCD) |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/lcd https://github.com/ethersex/ethersex/tree/master/hardware/lcd] }} ---- '''''THIS WIKI PAGE IS CURRENTLY WORK IN PROGRESS''''' ---- The '''HD44780 module''' provides support for common '''alphanumeric character LCDs''' using Hitachis HD44780 and compatible controllers. = Supported LC-Displays = The vast majority of all alphanumeric LC-Displays use Hitachis [https://en.wikipedia.org/wiki/Hitachi_HD44780_LCD_controller HD44780] dot matrix liquid crystal display (LCD) controller. The e6 HD44780 module supports displays of many different sizes utilizing the original HD44780 and compatible controllers. Alphanumeric LCDs are mainly distinguished by their size, the start-address of the per line Display Data-RAM (DDRAM) and the controller type. The original HD44780 controllers can drive up to 80 characters - most displays with more characters use two independent controllers. The following table lists the LC-displays supported by the e6 HD44780 module by size and per line DDRAM start-address: [[File:HD44780 Testbed.jpg|thumb|400px|right|text top|HD44780 module test]] {| class="wikitable" !colspan="1"|Menuconfig !colspan="2"|Size !colspan="4"|DDRAM Startaddress !rowspan="2"|Note: |- !LCD size/type||Characters||Lines||Line 1||Line 2||Line 3||Line 4 |- |8_Characters_1_Line||8||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line||16||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line_Mux16||16||1||0x00||n/a||n/a||n/a||organized as 8 chars, 2 lines |- |20_Characters_1_Line||20||1||0x00||n/a||n/a||n/a|| |- |40_Characters_1_Line||40||1||0x00||n/a||n/a||n/a|| |- |8_Characters_2_Lines||8||2||0x00||0x40||n/a||n/a|| |- |12_Characters_2_Lines||12||2||0x00||0x40||n/a||n/a|| |- |16_Characters_2_Lines||16||2||0x00||0x40||n/a||n/a|| |- |20_Characters_2_Lines||20||2||0x00||0x40||n/a||n/a|| |- |24_Characters_2_Lines||24||2||0x00||0x40||n/a||n/a|| |- |40_Characters_2_Lines||40||2||0x00||0x40||n/a||n/a|| |- |16_Characters_4_Lines||16||4||0x00||0x40||0x10||0x50|| |- |20_Characters_4_Lines||20||4||0x00||0x40||0x14||0x54||Note DDRAM addresses |- |20_Characters_4_Lines_KS0073||20||4||0x00||0x20||0x40||0x60||Note DDRAM addresses |- |27_Characters_4_Lines_2_EN||27||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |- |40_Characters_4_Lines_2_EN||40||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |} '''Note:''' The HD44780 module drivers supports '''alphanumeric character LCDs''' only. Ethersex also has limited support for some graphical displays. Have a look at the LC-Display configuration. = Configuration = ... │ │ Network ---> │ │ I/O ---> ... │ │ ADC / DAC ---> │ │ LCD Displays ---> ... │ │ [*] HD44780 module driver (Character-LCD) ---> │ │ [-] HR20-style LCD Display ... │ │ (16_Characters_2_Lines) LCD size/type │ │ (HD44780_Compat) LCD controller type │ │ (None) LCD charset conversion │ │ (I2C) Connection type │ │ (PCF8574) I2C Port Expander │ │ [*] Readback support │ │ [*] Backlight support │ │ [*] Backlight on at power-on │ │ [*] Invert Backlight switch '''Configuration options:''' ;LCD size/type : Select one of the defined display sizes and address configurations shown in the table [[#Supported LC-Displays]] above. : : Although it is technically possible to connect more than one display, the HD44780 module supports only one LC-Display at a time. ;LCD controller type : Select LCD controller circuit: : :* HD44780_Compat - most controllers are compatible to Hitachis HD44780 :* KS0066U - Samsungs KS0066U requires a different init routine : : Almost all controllers for alphanumeric character LCDs are more or less HD44780-compatible at least at the feature- and function-level required by e6. : : If in doubt, choose HD44780_Compat. [[File:Displaytech 404b charconv.jpg|thumb|400px|right|text top|Displaytech 404b showing output of ECMD lcd print charset 0 128 with selected HD44780_Compat charset conversion]] ;LCD charset conversion : Select charset conversion used while writing to the lcd: : :* None - use no charset conversion at all (safes program mem) :* HD44780_Compat - map characters from ISO8859-1 to the original HD44780 charset : : Almost all controllers use their own non-ISO-compatible charset, varying between manufacturers, rom versions, etc. that provides characters from western languages as well as japanese, chinese and graphical glyphs. : : Charset conversion might become useful if you have to display messages and texts from external resources that uses standard encodings for their charset like ISO8859-1. : : Note: Charset conversion uses a lookup table and requires about 272 byte program memory (flash rom). ;Connection type : Select the connection type for the LCD: : :* Direct - direct connection using avr io-pins :* I2C - uses sub-selection of I2C port expander :* SER_LCD(74hct164) - serial connection using HCT164 shift register :* 2WIRE(74hct4094) - serial connection using HCT4094 shift register : : See section [[#Pinning]] below for further explanations. : ;I2C Port Expander : Select I2C Port Expander to use: : :* PCF8574 - use PCF8574x as I2C port expander :* MCP23017 - use MCP23017 as I2C port expander : : Note: automatically enables I2C_MASTER_SUPPORT and I2C_PCF8574X_SUPPORT resp. I2C_MCP23017_SUPPORT when selected. : : Note: Selection is only valid when '''I2C''' was selected under '''Connection type'''. : See section [[#Pinning]] below for further explanations. ;Readback support : Enable support for bi-directional lcd bus to read LCDs busy flag. Supported by direct and I2C connection only. : : You '''definitly should use a readback capable hardware and enable this feature''', saves lots of delays. ;Backlight support : Backlight support for LCDs based on the HD44780 controller. : : Enable backlight on/off control via API and ECMD. ;Backlight on at power-on : Switch on backlight at power-on/reset. ;Invert Backlight switch : Invert backlight logic for low active backlight circuits e.g. found on Pollin AVR NET-IO Add-on. = Pinning = HD44780-based alphanumeric LCDs are connected via 8 databus-lines (D0..D7) and 3 control-lines (RS, EN, R/W). Displays with more than 80 characters usually utilize a second controller and require two EN-signals EN1 and EN2. Another signal BL is needed if backlight control ist required. To save some i/o-pins the HD44780 controller also supports a 4 Bit mode, using only D4..D7. The HD44780 module supports this 4 Bit mode only. Note that in general the signals D0..D3 should not be left open, use a pull-down or tie them to ground. Most displays use 14, 16 or 18-pin connectors with common pinouts but there are sometimes subtle differences. Beside the control- and data-signals all displays require a supply voltage Vdd, usually +5 V, for the logic circuits and another voltage Vo for the display itself. The later is usually derived using a trimmer which allows for contrast adjustment. Some displays require a ''negative'' voltage for the display. Please refer to the datasheet of '''your''' display! Wrong connections may lead to a permanent damage. The HD44780 module supports four different types of connection: Direct, I2C, Serial and 2-Wire. == Direct == The LCD signals RS, RW, EN (resp. EN1 and EN2), D4..D7 and BL are directly connected to AVR port pins. The driver makes no assumptions about the pin mapping, arbitrary pins from different ports may be used to drive the LCD signals. This connection type is Readback-capable. The following example maps the LCD pins to AVR port pins found on the 25 pin Sub-D connector of the Pollin AVR Net-IO board: <code> dnl Direct connection example dnl map LCD pins to Pollin AVR Net-IO dnl 25 pin extension port ifdef(`conf_HD44780', ` pin(HD44780_RS, PC4) pin(HD44780_RW, PC3) pin(HD44780_EN1, PC2) dnl pin(HD44780_EN2, PC5) pin(HD44780_D4, PA0) pin(HD44780_D5, PA1) pin(HD44780_D6, PA2) pin(HD44780_D7, PA3) ') ifdef(`conf_HD44780_BACKLIGHT', ` pin(HD44780_BL, PC6, OUTPUT) ') </code> == I2C == The I2C connection type supports either the 8 Bit PCF8574x, as it is found on the Pollin AVR Net-IO Add-On board, or the 16 Bit MCP23017 I2C Port Expander. LCDs up to 80 characters and only one HD44780 controller may be connected to a PCF8574x including the backlight control pin. LCDs with more than 80 characters require a second enable pin. The address of the port expander and the pinning for the LCD has to be specified for your hardware using the macros shown below. The macro HD44780_PCF8574x_MAPPING defines the pinning for displays with only one enable signal and backlight control, the macro HD44780_PCF8574x_MULTI_MAPPING for displays with two enable signals. Note that backlight control is not supported when using the HD44780_PCF8574x_MULTI_MAPPING macro. The pinning shown in the examples below matches the pinning found on the Pollin AVR Net-IO Add-On board. Remember that you have to replace the inverting backlight control circuitry with a direct connection to connect displays with two enable signals to this board. The macros HD44780_MCP23017_MAPPING and HD44780_MCP23017_MULTI_MAPPING are used to map the LCD pins to one port of the MCP23017. Note that you have to specify either port A or B as shown below, mapping using mixed pins of both ports is not supported by the driver. The additional macro HD44780_MCP23017_MULTI_MAPPING_BL may be used to specify a backlight control signal on another MCP23017 port when the first port is occupied by a display with two enable signals. The driver exclusively controls the pin specified, the other 7 port pins may be used for different purposes. <code> ifelse(value_HD44780_CONNECTION,`HD44780_I2CSUPPORT',`dnl ifelse(value_HD44780_I2C_PORTEXP,`HD44780_I2C_PCF8574', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_PCF8574x_MULTI_MAPPING(ADR, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_PCF8574x_MULTI_MAPPING(0x20, 4, 5, 6, 7, 0, 1, 2, 3)', `dnl dnl HD44780_PCF8574x_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_PCF8574x_MAPPING(0x20, 4, 5, 6, 0, 1, 2, 3, 7)')', value_HD44780_I2C_PORTEXP,`HD44780_I2C_MCP23017', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_MCP23017_MULTI_MAPPING(ADR, PORT, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_MCP23017_MULTI_MAPPING(0x24, B, 4, 5, 6, 7, 0, 1, 2, 3) HD44780_MCP23017_MULTI_MAPPING_BL(0x24, A, 7)', `dnl dnl HD44780_MCP23017_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_MCP23017_MAPPING(0x24, B, 4, 5, 6, 0, 1, 2, 3, 7)')' )dnl ')dnl </code> == Serial (using 74HCT164) == The LCD is connected using a 74HC(T)164 shift register. Refer to Ulrich Radig's [http://www.ulrichradig.de/home/index.php/software/avr-webserver-software avr-webserver] for an example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection requires three AVR port pins pin(HD44780_SER_D, PD4) pin(HD44780_SER_CLK, PD3) pin(HD44780_SER_EN1, PD2) </code> == 2-Wire (using 74HCT4094) == The LCD is connected using a 74HC(T)4094 shift register. Refer to [http://www.cczwei.de/atm18_downloads/071148-D%20CC2-AVR-board-2.pdf this] paper for an explanation and example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection using a 4094 shift register requires two AVR port pins ifdef(`HD44780_2WIRE', ` pin(HD44780_2WIRE_D, PC0) pin(HD44780_2WIRE_CLK, PC1) ') </code> 62a235c8c0de10888ca6598cc9ecab955a098dbe 1771 1770 2016-12-09T23:03:01Z Michaelb 718 /* Configuration */ wikitext text/x-wiki {{i18n|HD44780}} {{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->HD44780 module driver (Character-LCD) |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/lcd https://github.com/ethersex/ethersex/tree/master/hardware/lcd] }} ---- '''''THIS WIKI PAGE IS CURRENTLY WORK IN PROGRESS''''' ---- The '''HD44780 module''' provides support for common '''alphanumeric character LCDs''' using Hitachis HD44780 and compatible controllers. = Supported LC-Displays = The vast majority of all alphanumeric LC-Displays use Hitachis [https://en.wikipedia.org/wiki/Hitachi_HD44780_LCD_controller HD44780] dot matrix liquid crystal display (LCD) controller. The e6 HD44780 module supports displays of many different sizes utilizing the original HD44780 and compatible controllers. Alphanumeric LCDs are mainly distinguished by their size, the start-address of the per line Display Data-RAM (DDRAM) and the controller type. The original HD44780 controllers can drive up to 80 characters - most displays with more characters use two independent controllers. The following table lists the LC-displays supported by the e6 HD44780 module by size and per line DDRAM start-address: [[File:HD44780 Testbed.jpg|thumb|400px|right|text top|HD44780 module test]] {| class="wikitable" !colspan="1"|Menuconfig !colspan="2"|Size !colspan="4"|DDRAM Startaddress !rowspan="2"|Note: |- !LCD size/type||Characters||Lines||Line 1||Line 2||Line 3||Line 4 |- |8_Characters_1_Line||8||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line||16||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line_Mux16||16||1||0x00||n/a||n/a||n/a||organized as 8 chars, 2 lines |- |20_Characters_1_Line||20||1||0x00||n/a||n/a||n/a|| |- |40_Characters_1_Line||40||1||0x00||n/a||n/a||n/a|| |- |8_Characters_2_Lines||8||2||0x00||0x40||n/a||n/a|| |- |12_Characters_2_Lines||12||2||0x00||0x40||n/a||n/a|| |- |16_Characters_2_Lines||16||2||0x00||0x40||n/a||n/a|| |- |20_Characters_2_Lines||20||2||0x00||0x40||n/a||n/a|| |- |24_Characters_2_Lines||24||2||0x00||0x40||n/a||n/a|| |- |40_Characters_2_Lines||40||2||0x00||0x40||n/a||n/a|| |- |16_Characters_4_Lines||16||4||0x00||0x40||0x10||0x50|| |- |20_Characters_4_Lines||20||4||0x00||0x40||0x14||0x54||Note DDRAM addresses |- |20_Characters_4_Lines_KS0073||20||4||0x00||0x20||0x40||0x60||Note DDRAM addresses |- |27_Characters_4_Lines_2_EN||27||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |- |40_Characters_4_Lines_2_EN||40||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |} '''Note:''' The HD44780 module drivers supports '''alphanumeric character LCDs''' only. Ethersex also has limited support for some graphical displays. Have a look at the LC-Display configuration. = Configuration = ... │ │ Network ---> │ │ I/O ---> ... │ │ ADC / DAC ---> │ │ LCD Displays ---> ... │ │ [*] HD44780 module driver (Character-LCD) ---> │ │ [-] HR20-style LCD Display ... │ │ (16_Characters_2_Lines) LCD size/type │ │ (HD44780_Compat) LCD controller type │ │ (None) LCD charset conversion │ │ (I2C) Connection type │ │ (PCF8574) I2C Port Expander │ │ [*] Readback support │ │ [*] Backlight support │ │ [*] Backlight on at power-on │ │ [*] Invert Backlight switch '''Configuration options:''' [[File:Displaytech 404b charconv.jpg|thumb|400px|right|text top|Displaytech 404b 4x40 showing output of ECMD lcd print charset 0 128 with selected HD44780_Compat charset conversion]] ;LCD size/type : Select one of the defined display sizes and address configurations shown in the table [[#Supported LC-Displays]] above. : : Although it is technically possible to connect more than one display, the HD44780 module supports only one LC-Display at a time. ;LCD controller type : Select LCD controller circuit: : :* HD44780_Compat - most controllers are compatible to Hitachis HD44780 :* KS0066U - Samsungs KS0066U requires a different init routine : : Almost all controllers for alphanumeric character LCDs are more or less HD44780-compatible at least at the feature- and function-level required by e6. : : If in doubt, choose HD44780_Compat. ;LCD charset conversion : Select charset conversion used while writing to the lcd: : :* None - use no charset conversion at all (safes program mem) :* HD44780_Compat - map characters from ISO8859-1 to the original HD44780 charset : : Almost all controllers use their own non-ISO-compatible charset, varying between manufacturers, rom versions, etc. that provides characters from western languages as well as japanese, chinese and graphical glyphs. : : Charset conversion might become useful if you have to display messages and texts from external resources that uses standard encodings for their charset like ISO8859-1. : : Note: Charset conversion uses a lookup table and requires about 272 byte program memory (flash rom). ;Connection type : Select the connection type for the LCD: : :* Direct - direct connection using avr io-pins :* I2C - uses sub-selection of I2C port expander :* SER_LCD(74hct164) - serial connection using HCT164 shift register :* 2WIRE(74hct4094) - serial connection using HCT4094 shift register : : See section [[#Pinning]] below for further explanations. : ;I2C Port Expander : Select I2C Port Expander to use: : :* PCF8574 - use PCF8574x as I2C port expander :* MCP23017 - use MCP23017 as I2C port expander : : Note: automatically enables I2C_MASTER_SUPPORT and I2C_PCF8574X_SUPPORT resp. I2C_MCP23017_SUPPORT when selected. : : Note: Selection is only valid when '''I2C''' was selected under '''Connection type'''. : See section [[#Pinning]] below for further explanations. ;Readback support : Enable support for bi-directional lcd bus to read LCDs busy flag. Supported by direct and I2C connection only. : : You '''definitly should use a readback capable hardware and enable this feature''', saves lots of delays. ;Backlight support : Backlight support for LCDs based on the HD44780 controller. : : Enable backlight on/off control via API and ECMD. ;Backlight on at power-on : Switch on backlight at power-on/reset. ;Invert Backlight switch : Invert backlight logic for low active backlight circuits e.g. found on Pollin AVR NET-IO Add-on. = Pinning = HD44780-based alphanumeric LCDs are connected via 8 databus-lines (D0..D7) and 3 control-lines (RS, EN, R/W). Displays with more than 80 characters usually utilize a second controller and require two EN-signals EN1 and EN2. Another signal BL is needed if backlight control ist required. To save some i/o-pins the HD44780 controller also supports a 4 Bit mode, using only D4..D7. The HD44780 module supports this 4 Bit mode only. Note that in general the signals D0..D3 should not be left open, use a pull-down or tie them to ground. Most displays use 14, 16 or 18-pin connectors with common pinouts but there are sometimes subtle differences. Beside the control- and data-signals all displays require a supply voltage Vdd, usually +5 V, for the logic circuits and another voltage Vo for the display itself. The later is usually derived using a trimmer which allows for contrast adjustment. Some displays require a ''negative'' voltage for the display. Please refer to the datasheet of '''your''' display! Wrong connections may lead to a permanent damage. The HD44780 module supports four different types of connection: Direct, I2C, Serial and 2-Wire. == Direct == The LCD signals RS, RW, EN (resp. EN1 and EN2), D4..D7 and BL are directly connected to AVR port pins. The driver makes no assumptions about the pin mapping, arbitrary pins from different ports may be used to drive the LCD signals. This connection type is Readback-capable. The following example maps the LCD pins to AVR port pins found on the 25 pin Sub-D connector of the Pollin AVR Net-IO board: <code> dnl Direct connection example dnl map LCD pins to Pollin AVR Net-IO dnl 25 pin extension port ifdef(`conf_HD44780', ` pin(HD44780_RS, PC4) pin(HD44780_RW, PC3) pin(HD44780_EN1, PC2) dnl pin(HD44780_EN2, PC5) pin(HD44780_D4, PA0) pin(HD44780_D5, PA1) pin(HD44780_D6, PA2) pin(HD44780_D7, PA3) ') ifdef(`conf_HD44780_BACKLIGHT', ` pin(HD44780_BL, PC6, OUTPUT) ') </code> == I2C == The I2C connection type supports either the 8 Bit PCF8574x, as it is found on the Pollin AVR Net-IO Add-On board, or the 16 Bit MCP23017 I2C Port Expander. LCDs up to 80 characters and only one HD44780 controller may be connected to a PCF8574x including the backlight control pin. LCDs with more than 80 characters require a second enable pin. The address of the port expander and the pinning for the LCD has to be specified for your hardware using the macros shown below. The macro HD44780_PCF8574x_MAPPING defines the pinning for displays with only one enable signal and backlight control, the macro HD44780_PCF8574x_MULTI_MAPPING for displays with two enable signals. Note that backlight control is not supported when using the HD44780_PCF8574x_MULTI_MAPPING macro. The pinning shown in the examples below matches the pinning found on the Pollin AVR Net-IO Add-On board. Remember that you have to replace the inverting backlight control circuitry with a direct connection to connect displays with two enable signals to this board. The macros HD44780_MCP23017_MAPPING and HD44780_MCP23017_MULTI_MAPPING are used to map the LCD pins to one port of the MCP23017. Note that you have to specify either port A or B as shown below, mapping using mixed pins of both ports is not supported by the driver. The additional macro HD44780_MCP23017_MULTI_MAPPING_BL may be used to specify a backlight control signal on another MCP23017 port when the first port is occupied by a display with two enable signals. The driver exclusively controls the pin specified, the other 7 port pins may be used for different purposes. <code> ifelse(value_HD44780_CONNECTION,`HD44780_I2CSUPPORT',`dnl ifelse(value_HD44780_I2C_PORTEXP,`HD44780_I2C_PCF8574', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_PCF8574x_MULTI_MAPPING(ADR, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_PCF8574x_MULTI_MAPPING(0x20, 4, 5, 6, 7, 0, 1, 2, 3)', `dnl dnl HD44780_PCF8574x_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_PCF8574x_MAPPING(0x20, 4, 5, 6, 0, 1, 2, 3, 7)')', value_HD44780_I2C_PORTEXP,`HD44780_I2C_MCP23017', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_MCP23017_MULTI_MAPPING(ADR, PORT, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_MCP23017_MULTI_MAPPING(0x24, B, 4, 5, 6, 7, 0, 1, 2, 3) HD44780_MCP23017_MULTI_MAPPING_BL(0x24, A, 7)', `dnl dnl HD44780_MCP23017_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_MCP23017_MAPPING(0x24, B, 4, 5, 6, 0, 1, 2, 3, 7)')' )dnl ')dnl </code> == Serial (using 74HCT164) == The LCD is connected using a 74HC(T)164 shift register. Refer to Ulrich Radig's [http://www.ulrichradig.de/home/index.php/software/avr-webserver-software avr-webserver] for an example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection requires three AVR port pins pin(HD44780_SER_D, PD4) pin(HD44780_SER_CLK, PD3) pin(HD44780_SER_EN1, PD2) </code> == 2-Wire (using 74HCT4094) == The LCD is connected using a 74HC(T)4094 shift register. Refer to [http://www.cczwei.de/atm18_downloads/071148-D%20CC2-AVR-board-2.pdf this] paper for an explanation and example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection using a 4094 shift register requires two AVR port pins ifdef(`HD44780_2WIRE', ` pin(HD44780_2WIRE_D, PC0) pin(HD44780_2WIRE_CLK, PC1) ') </code> 2adc3d47d783163ded85b36c80487de617951bfd 1772 1771 2016-12-09T23:06:58Z Michaelb 718 /* Configuration */ wikitext text/x-wiki {{i18n|HD44780}} {{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->HD44780 module driver (Character-LCD) |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/lcd https://github.com/ethersex/ethersex/tree/master/hardware/lcd] }} ---- '''''THIS WIKI PAGE IS CURRENTLY WORK IN PROGRESS''''' ---- The '''HD44780 module''' provides support for common '''alphanumeric character LCDs''' using Hitachis HD44780 and compatible controllers. = Supported LC-Displays = The vast majority of all alphanumeric LC-Displays use Hitachis [https://en.wikipedia.org/wiki/Hitachi_HD44780_LCD_controller HD44780] dot matrix liquid crystal display (LCD) controller. The e6 HD44780 module supports displays of many different sizes utilizing the original HD44780 and compatible controllers. Alphanumeric LCDs are mainly distinguished by their size, the start-address of the per line Display Data-RAM (DDRAM) and the controller type. The original HD44780 controllers can drive up to 80 characters - most displays with more characters use two independent controllers. The following table lists the LC-displays supported by the e6 HD44780 module by size and per line DDRAM start-address: [[File:HD44780 Testbed.jpg|thumb|400px|right|text top|HD44780 module test]] {| class="wikitable" !colspan="1"|Menuconfig !colspan="2"|Size !colspan="4"|DDRAM Startaddress !rowspan="2"|Note: |- !LCD size/type||Characters||Lines||Line 1||Line 2||Line 3||Line 4 |- |8_Characters_1_Line||8||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line||16||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line_Mux16||16||1||0x00||n/a||n/a||n/a||organized as 8 chars, 2 lines |- |20_Characters_1_Line||20||1||0x00||n/a||n/a||n/a|| |- |40_Characters_1_Line||40||1||0x00||n/a||n/a||n/a|| |- |8_Characters_2_Lines||8||2||0x00||0x40||n/a||n/a|| |- |12_Characters_2_Lines||12||2||0x00||0x40||n/a||n/a|| |- |16_Characters_2_Lines||16||2||0x00||0x40||n/a||n/a|| |- |20_Characters_2_Lines||20||2||0x00||0x40||n/a||n/a|| |- |24_Characters_2_Lines||24||2||0x00||0x40||n/a||n/a|| |- |40_Characters_2_Lines||40||2||0x00||0x40||n/a||n/a|| |- |16_Characters_4_Lines||16||4||0x00||0x40||0x10||0x50|| |- |20_Characters_4_Lines||20||4||0x00||0x40||0x14||0x54||Note DDRAM addresses |- |20_Characters_4_Lines_KS0073||20||4||0x00||0x20||0x40||0x60||Note DDRAM addresses |- |27_Characters_4_Lines_2_EN||27||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |- |40_Characters_4_Lines_2_EN||40||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |} '''Note:''' The HD44780 module drivers supports '''alphanumeric character LCDs''' only. Ethersex also has limited support for some graphical displays. Have a look at the LC-Display configuration. = Configuration = ... │ │ Network ---> │ │ I/O ---> ... │ │ ADC / DAC ---> │ │ LCD Displays ---> ... │ │ [*] HD44780 module driver (Character-LCD) ---> │ │ [-] HR20-style LCD Display ... │ │ (16_Characters_2_Lines) LCD size/type │ │ (HD44780_Compat) LCD controller type │ │ (None) LCD charset conversion │ │ (I2C) Connection type │ │ (PCF8574) I2C Port Expander │ │ [*] Readback support │ │ [*] Backlight support │ │ [*] Backlight on at power-on │ │ [*] Invert Backlight switch '''Configuration options:''' [[File:Displaytech 404b charconv.jpg|thumb|400px|right|text top|Displaytech 404b 4x40 LCD with output of ECMD lcd print charset 0 128 and selected HD44780_Compat charset conversion]] ;LCD size/type : Select one of the defined display sizes and address configurations shown in the table [[#Supported LC-Displays]] above. : : Although it is technically possible to connect more than one display, the HD44780 module supports only one LC-Display at a time. ;LCD controller type : Select LCD controller circuit: : :* HD44780_Compat - most controllers are compatible to Hitachis HD44780 :* KS0066U - Samsungs KS0066U requires a different init routine : : Almost all controllers for alphanumeric character LCDs are more or less HD44780-compatible at least at the feature- and function-level required by e6. : : If in doubt, choose HD44780_Compat. ;LCD charset conversion : Select charset conversion used while writing to the lcd: : :* None - use no charset conversion at all (safes program mem) :* HD44780_Compat - map characters from ISO8859-1 to the original HD44780 charset : : Almost all controllers use their own non-ISO-compatible charset, varying between manufacturers, rom versions, etc. that provides characters from western languages as well as japanese, chinese and graphical glyphs. : : Charset conversion might become useful if you have to display messages and texts from external resources that uses standard encodings for their charset like ISO8859-1. : : Note: Charset conversion uses a lookup table and requires about 272 byte program memory (flash rom). ;Connection type : Select the connection type for the LCD: : :* Direct - direct connection using avr io-pins :* I2C - uses sub-selection of I2C port expander :* SER_LCD(74hct164) - serial connection using HCT164 shift register :* 2WIRE(74hct4094) - serial connection using HCT4094 shift register : : See section [[#Pinning]] below for further explanations. : ;I2C Port Expander : Select I2C Port Expander to use: : :* PCF8574 - use PCF8574x as I2C port expander :* MCP23017 - use MCP23017 as I2C port expander : : Note: automatically enables I2C_MASTER_SUPPORT and I2C_PCF8574X_SUPPORT resp. I2C_MCP23017_SUPPORT when selected. : : Note: Selection is only valid when '''I2C''' was selected under '''Connection type'''. : See section [[#Pinning]] below for further explanations. ;Readback support : Enable support for bi-directional lcd bus to read LCDs busy flag. Supported by direct and I2C connection only. : : You '''definitly should use a readback capable hardware and enable this feature''', saves lots of delays. ;Backlight support : Backlight support for LCDs based on the HD44780 controller. : : Enable backlight on/off control via API and ECMD. ;Backlight on at power-on : Switch on backlight at power-on/reset. ;Invert Backlight switch : Invert backlight logic for low active backlight circuits e.g. found on Pollin AVR NET-IO Add-on. = Pinning = HD44780-based alphanumeric LCDs are connected via 8 databus-lines (D0..D7) and 3 control-lines (RS, EN, R/W). Displays with more than 80 characters usually utilize a second controller and require two EN-signals EN1 and EN2. Another signal BL is needed if backlight control ist required. To save some i/o-pins the HD44780 controller also supports a 4 Bit mode, using only D4..D7. The HD44780 module supports this 4 Bit mode only. Note that in general the signals D0..D3 should not be left open, use a pull-down or tie them to ground. Most displays use 14, 16 or 18-pin connectors with common pinouts but there are sometimes subtle differences. Beside the control- and data-signals all displays require a supply voltage Vdd, usually +5 V, for the logic circuits and another voltage Vo for the display itself. The later is usually derived using a trimmer which allows for contrast adjustment. Some displays require a ''negative'' voltage for the display. Please refer to the datasheet of '''your''' display! Wrong connections may lead to a permanent damage. The HD44780 module supports four different types of connection: Direct, I2C, Serial and 2-Wire. == Direct == The LCD signals RS, RW, EN (resp. EN1 and EN2), D4..D7 and BL are directly connected to AVR port pins. The driver makes no assumptions about the pin mapping, arbitrary pins from different ports may be used to drive the LCD signals. This connection type is Readback-capable. The following example maps the LCD pins to AVR port pins found on the 25 pin Sub-D connector of the Pollin AVR Net-IO board: <code> dnl Direct connection example dnl map LCD pins to Pollin AVR Net-IO dnl 25 pin extension port ifdef(`conf_HD44780', ` pin(HD44780_RS, PC4) pin(HD44780_RW, PC3) pin(HD44780_EN1, PC2) dnl pin(HD44780_EN2, PC5) pin(HD44780_D4, PA0) pin(HD44780_D5, PA1) pin(HD44780_D6, PA2) pin(HD44780_D7, PA3) ') ifdef(`conf_HD44780_BACKLIGHT', ` pin(HD44780_BL, PC6, OUTPUT) ') </code> == I2C == The I2C connection type supports either the 8 Bit PCF8574x, as it is found on the Pollin AVR Net-IO Add-On board, or the 16 Bit MCP23017 I2C Port Expander. LCDs up to 80 characters and only one HD44780 controller may be connected to a PCF8574x including the backlight control pin. LCDs with more than 80 characters require a second enable pin. The address of the port expander and the pinning for the LCD has to be specified for your hardware using the macros shown below. The macro HD44780_PCF8574x_MAPPING defines the pinning for displays with only one enable signal and backlight control, the macro HD44780_PCF8574x_MULTI_MAPPING for displays with two enable signals. Note that backlight control is not supported when using the HD44780_PCF8574x_MULTI_MAPPING macro. The pinning shown in the examples below matches the pinning found on the Pollin AVR Net-IO Add-On board. Remember that you have to replace the inverting backlight control circuitry with a direct connection to connect displays with two enable signals to this board. The macros HD44780_MCP23017_MAPPING and HD44780_MCP23017_MULTI_MAPPING are used to map the LCD pins to one port of the MCP23017. Note that you have to specify either port A or B as shown below, mapping using mixed pins of both ports is not supported by the driver. The additional macro HD44780_MCP23017_MULTI_MAPPING_BL may be used to specify a backlight control signal on another MCP23017 port when the first port is occupied by a display with two enable signals. The driver exclusively controls the pin specified, the other 7 port pins may be used for different purposes. <code> ifelse(value_HD44780_CONNECTION,`HD44780_I2CSUPPORT',`dnl ifelse(value_HD44780_I2C_PORTEXP,`HD44780_I2C_PCF8574', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_PCF8574x_MULTI_MAPPING(ADR, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_PCF8574x_MULTI_MAPPING(0x20, 4, 5, 6, 7, 0, 1, 2, 3)', `dnl dnl HD44780_PCF8574x_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_PCF8574x_MAPPING(0x20, 4, 5, 6, 0, 1, 2, 3, 7)')', value_HD44780_I2C_PORTEXP,`HD44780_I2C_MCP23017', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_MCP23017_MULTI_MAPPING(ADR, PORT, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_MCP23017_MULTI_MAPPING(0x24, B, 4, 5, 6, 7, 0, 1, 2, 3) HD44780_MCP23017_MULTI_MAPPING_BL(0x24, A, 7)', `dnl dnl HD44780_MCP23017_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_MCP23017_MAPPING(0x24, B, 4, 5, 6, 0, 1, 2, 3, 7)')' )dnl ')dnl </code> == Serial (using 74HCT164) == The LCD is connected using a 74HC(T)164 shift register. Refer to Ulrich Radig's [http://www.ulrichradig.de/home/index.php/software/avr-webserver-software avr-webserver] for an example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection requires three AVR port pins pin(HD44780_SER_D, PD4) pin(HD44780_SER_CLK, PD3) pin(HD44780_SER_EN1, PD2) </code> == 2-Wire (using 74HCT4094) == The LCD is connected using a 74HC(T)4094 shift register. Refer to [http://www.cczwei.de/atm18_downloads/071148-D%20CC2-AVR-board-2.pdf this] paper for an explanation and example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection using a 4094 shift register requires two AVR port pins ifdef(`HD44780_2WIRE', ` pin(HD44780_2WIRE_D, PC0) pin(HD44780_2WIRE_CLK, PC1) ') </code> 9293a3cfd75b646eb5fa4398ab2bd7348fa65c1a 1773 1772 2016-12-09T23:08:52Z Michaelb 718 /* I2C */ wikitext text/x-wiki {{i18n|HD44780}} {{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->HD44780 module driver (Character-LCD) |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/lcd https://github.com/ethersex/ethersex/tree/master/hardware/lcd] }} ---- '''''THIS WIKI PAGE IS CURRENTLY WORK IN PROGRESS''''' ---- The '''HD44780 module''' provides support for common '''alphanumeric character LCDs''' using Hitachis HD44780 and compatible controllers. = Supported LC-Displays = The vast majority of all alphanumeric LC-Displays use Hitachis [https://en.wikipedia.org/wiki/Hitachi_HD44780_LCD_controller HD44780] dot matrix liquid crystal display (LCD) controller. The e6 HD44780 module supports displays of many different sizes utilizing the original HD44780 and compatible controllers. Alphanumeric LCDs are mainly distinguished by their size, the start-address of the per line Display Data-RAM (DDRAM) and the controller type. The original HD44780 controllers can drive up to 80 characters - most displays with more characters use two independent controllers. The following table lists the LC-displays supported by the e6 HD44780 module by size and per line DDRAM start-address: [[File:HD44780 Testbed.jpg|thumb|400px|right|text top|HD44780 module test]] {| class="wikitable" !colspan="1"|Menuconfig !colspan="2"|Size !colspan="4"|DDRAM Startaddress !rowspan="2"|Note: |- !LCD size/type||Characters||Lines||Line 1||Line 2||Line 3||Line 4 |- |8_Characters_1_Line||8||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line||16||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line_Mux16||16||1||0x00||n/a||n/a||n/a||organized as 8 chars, 2 lines |- |20_Characters_1_Line||20||1||0x00||n/a||n/a||n/a|| |- |40_Characters_1_Line||40||1||0x00||n/a||n/a||n/a|| |- |8_Characters_2_Lines||8||2||0x00||0x40||n/a||n/a|| |- |12_Characters_2_Lines||12||2||0x00||0x40||n/a||n/a|| |- |16_Characters_2_Lines||16||2||0x00||0x40||n/a||n/a|| |- |20_Characters_2_Lines||20||2||0x00||0x40||n/a||n/a|| |- |24_Characters_2_Lines||24||2||0x00||0x40||n/a||n/a|| |- |40_Characters_2_Lines||40||2||0x00||0x40||n/a||n/a|| |- |16_Characters_4_Lines||16||4||0x00||0x40||0x10||0x50|| |- |20_Characters_4_Lines||20||4||0x00||0x40||0x14||0x54||Note DDRAM addresses |- |20_Characters_4_Lines_KS0073||20||4||0x00||0x20||0x40||0x60||Note DDRAM addresses |- |27_Characters_4_Lines_2_EN||27||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |- |40_Characters_4_Lines_2_EN||40||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |} '''Note:''' The HD44780 module drivers supports '''alphanumeric character LCDs''' only. Ethersex also has limited support for some graphical displays. Have a look at the LC-Display configuration. = Configuration = ... │ │ Network ---> │ │ I/O ---> ... │ │ ADC / DAC ---> │ │ LCD Displays ---> ... │ │ [*] HD44780 module driver (Character-LCD) ---> │ │ [-] HR20-style LCD Display ... │ │ (16_Characters_2_Lines) LCD size/type │ │ (HD44780_Compat) LCD controller type │ │ (None) LCD charset conversion │ │ (I2C) Connection type │ │ (PCF8574) I2C Port Expander │ │ [*] Readback support │ │ [*] Backlight support │ │ [*] Backlight on at power-on │ │ [*] Invert Backlight switch '''Configuration options:''' [[File:Displaytech 404b charconv.jpg|thumb|400px|right|text top|Displaytech 404b 4x40 LCD with output of ECMD lcd print charset 0 128 and selected HD44780_Compat charset conversion]] ;LCD size/type : Select one of the defined display sizes and address configurations shown in the table [[#Supported LC-Displays]] above. : : Although it is technically possible to connect more than one display, the HD44780 module supports only one LC-Display at a time. ;LCD controller type : Select LCD controller circuit: : :* HD44780_Compat - most controllers are compatible to Hitachis HD44780 :* KS0066U - Samsungs KS0066U requires a different init routine : : Almost all controllers for alphanumeric character LCDs are more or less HD44780-compatible at least at the feature- and function-level required by e6. : : If in doubt, choose HD44780_Compat. ;LCD charset conversion : Select charset conversion used while writing to the lcd: : :* None - use no charset conversion at all (safes program mem) :* HD44780_Compat - map characters from ISO8859-1 to the original HD44780 charset : : Almost all controllers use their own non-ISO-compatible charset, varying between manufacturers, rom versions, etc. that provides characters from western languages as well as japanese, chinese and graphical glyphs. : : Charset conversion might become useful if you have to display messages and texts from external resources that uses standard encodings for their charset like ISO8859-1. : : Note: Charset conversion uses a lookup table and requires about 272 byte program memory (flash rom). ;Connection type : Select the connection type for the LCD: : :* Direct - direct connection using avr io-pins :* I2C - uses sub-selection of I2C port expander :* SER_LCD(74hct164) - serial connection using HCT164 shift register :* 2WIRE(74hct4094) - serial connection using HCT4094 shift register : : See section [[#Pinning]] below for further explanations. : ;I2C Port Expander : Select I2C Port Expander to use: : :* PCF8574 - use PCF8574x as I2C port expander :* MCP23017 - use MCP23017 as I2C port expander : : Note: automatically enables I2C_MASTER_SUPPORT and I2C_PCF8574X_SUPPORT resp. I2C_MCP23017_SUPPORT when selected. : : Note: Selection is only valid when '''I2C''' was selected under '''Connection type'''. : See section [[#Pinning]] below for further explanations. ;Readback support : Enable support for bi-directional lcd bus to read LCDs busy flag. Supported by direct and I2C connection only. : : You '''definitly should use a readback capable hardware and enable this feature''', saves lots of delays. ;Backlight support : Backlight support for LCDs based on the HD44780 controller. : : Enable backlight on/off control via API and ECMD. ;Backlight on at power-on : Switch on backlight at power-on/reset. ;Invert Backlight switch : Invert backlight logic for low active backlight circuits e.g. found on Pollin AVR NET-IO Add-on. = Pinning = HD44780-based alphanumeric LCDs are connected via 8 databus-lines (D0..D7) and 3 control-lines (RS, EN, R/W). Displays with more than 80 characters usually utilize a second controller and require two EN-signals EN1 and EN2. Another signal BL is needed if backlight control ist required. To save some i/o-pins the HD44780 controller also supports a 4 Bit mode, using only D4..D7. The HD44780 module supports this 4 Bit mode only. Note that in general the signals D0..D3 should not be left open, use a pull-down or tie them to ground. Most displays use 14, 16 or 18-pin connectors with common pinouts but there are sometimes subtle differences. Beside the control- and data-signals all displays require a supply voltage Vdd, usually +5 V, for the logic circuits and another voltage Vo for the display itself. The later is usually derived using a trimmer which allows for contrast adjustment. Some displays require a ''negative'' voltage for the display. Please refer to the datasheet of '''your''' display! Wrong connections may lead to a permanent damage. The HD44780 module supports four different types of connection: Direct, I2C, Serial and 2-Wire. == Direct == The LCD signals RS, RW, EN (resp. EN1 and EN2), D4..D7 and BL are directly connected to AVR port pins. The driver makes no assumptions about the pin mapping, arbitrary pins from different ports may be used to drive the LCD signals. This connection type is Readback-capable. The following example maps the LCD pins to AVR port pins found on the 25 pin Sub-D connector of the Pollin AVR Net-IO board: <code> dnl Direct connection example dnl map LCD pins to Pollin AVR Net-IO dnl 25 pin extension port ifdef(`conf_HD44780', ` pin(HD44780_RS, PC4) pin(HD44780_RW, PC3) pin(HD44780_EN1, PC2) dnl pin(HD44780_EN2, PC5) pin(HD44780_D4, PA0) pin(HD44780_D5, PA1) pin(HD44780_D6, PA2) pin(HD44780_D7, PA3) ') ifdef(`conf_HD44780_BACKLIGHT', ` pin(HD44780_BL, PC6, OUTPUT) ') </code> == I2C == The I2C connection type supports either the 8 Bit PCF8574x, as it is found on the Pollin AVR Net-IO Add-On board, or the 16 Bit MCP23017 I2C Port Expander. LCDs up to 80 characters and only one HD44780 controller may be connected to a PCF8574x including the backlight control pin. LCDs with more than 80 characters require a second enable pin. The address of the port expander and the pinning for the LCD has to be specified for your hardware using the macros shown below. The macro HD44780_PCF8574x_MAPPING defines the pinning for displays with only one enable signal and backlight control, the macro HD44780_PCF8574x_MULTI_MAPPING for displays with two enable signals. Note that backlight control is not supported when using the HD44780_PCF8574x_MULTI_MAPPING macro. The pinning shown in the examples below matches the pinning found on the Pollin AVR Net-IO Add-On board. Remember that you have to replace the inverting backlight control circuitry with a direct connection to connect displays with two enable signals to this board. The macros HD44780_MCP23017_MAPPING and HD44780_MCP23017_MULTI_MAPPING are used to map the LCD pins to one port of the MCP23017. Note that you have to specify either port A or B as shown below, mapping using mixed pins of both ports is not supported by the driver. The additional macro HD44780_MCP23017_MULTI_MAPPING_BL may be used to specify a backlight control signal on another MCP23017 port when the first port is occupied by a display with two enable signals. The driver exclusively controls the pin specified, the other 7 port pins may be used for different purposes. LCDs connected via I2C may be read back. <code> ifelse(value_HD44780_CONNECTION,`HD44780_I2CSUPPORT',`dnl ifelse(value_HD44780_I2C_PORTEXP,`HD44780_I2C_PCF8574', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_PCF8574x_MULTI_MAPPING(ADR, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_PCF8574x_MULTI_MAPPING(0x20, 4, 5, 6, 7, 0, 1, 2, 3)', `dnl dnl HD44780_PCF8574x_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_PCF8574x_MAPPING(0x20, 4, 5, 6, 0, 1, 2, 3, 7)')', value_HD44780_I2C_PORTEXP,`HD44780_I2C_MCP23017', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_MCP23017_MULTI_MAPPING(ADR, PORT, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_MCP23017_MULTI_MAPPING(0x24, B, 4, 5, 6, 7, 0, 1, 2, 3) HD44780_MCP23017_MULTI_MAPPING_BL(0x24, A, 7)', `dnl dnl HD44780_MCP23017_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_MCP23017_MAPPING(0x24, B, 4, 5, 6, 0, 1, 2, 3, 7)')' )dnl ')dnl </code> == Serial (using 74HCT164) == The LCD is connected using a 74HC(T)164 shift register. Refer to Ulrich Radig's [http://www.ulrichradig.de/home/index.php/software/avr-webserver-software avr-webserver] for an example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection requires three AVR port pins pin(HD44780_SER_D, PD4) pin(HD44780_SER_CLK, PD3) pin(HD44780_SER_EN1, PD2) </code> == 2-Wire (using 74HCT4094) == The LCD is connected using a 74HC(T)4094 shift register. Refer to [http://www.cczwei.de/atm18_downloads/071148-D%20CC2-AVR-board-2.pdf this] paper for an explanation and example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection using a 4094 shift register requires two AVR port pins ifdef(`HD44780_2WIRE', ` pin(HD44780_2WIRE_D, PC0) pin(HD44780_2WIRE_CLK, PC1) ') </code> 6b774bbcd04f8098b48dadafc4668287f74dd781 1774 1773 2016-12-09T23:10:10Z Michaelb 718 /* I2C */ wikitext text/x-wiki {{i18n|HD44780}} {{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->HD44780 module driver (Character-LCD) |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/lcd https://github.com/ethersex/ethersex/tree/master/hardware/lcd] }} ---- '''''THIS WIKI PAGE IS CURRENTLY WORK IN PROGRESS''''' ---- The '''HD44780 module''' provides support for common '''alphanumeric character LCDs''' using Hitachis HD44780 and compatible controllers. = Supported LC-Displays = The vast majority of all alphanumeric LC-Displays use Hitachis [https://en.wikipedia.org/wiki/Hitachi_HD44780_LCD_controller HD44780] dot matrix liquid crystal display (LCD) controller. The e6 HD44780 module supports displays of many different sizes utilizing the original HD44780 and compatible controllers. Alphanumeric LCDs are mainly distinguished by their size, the start-address of the per line Display Data-RAM (DDRAM) and the controller type. The original HD44780 controllers can drive up to 80 characters - most displays with more characters use two independent controllers. The following table lists the LC-displays supported by the e6 HD44780 module by size and per line DDRAM start-address: [[File:HD44780 Testbed.jpg|thumb|400px|right|text top|HD44780 module test]] {| class="wikitable" !colspan="1"|Menuconfig !colspan="2"|Size !colspan="4"|DDRAM Startaddress !rowspan="2"|Note: |- !LCD size/type||Characters||Lines||Line 1||Line 2||Line 3||Line 4 |- |8_Characters_1_Line||8||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line||16||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line_Mux16||16||1||0x00||n/a||n/a||n/a||organized as 8 chars, 2 lines |- |20_Characters_1_Line||20||1||0x00||n/a||n/a||n/a|| |- |40_Characters_1_Line||40||1||0x00||n/a||n/a||n/a|| |- |8_Characters_2_Lines||8||2||0x00||0x40||n/a||n/a|| |- |12_Characters_2_Lines||12||2||0x00||0x40||n/a||n/a|| |- |16_Characters_2_Lines||16||2||0x00||0x40||n/a||n/a|| |- |20_Characters_2_Lines||20||2||0x00||0x40||n/a||n/a|| |- |24_Characters_2_Lines||24||2||0x00||0x40||n/a||n/a|| |- |40_Characters_2_Lines||40||2||0x00||0x40||n/a||n/a|| |- |16_Characters_4_Lines||16||4||0x00||0x40||0x10||0x50|| |- |20_Characters_4_Lines||20||4||0x00||0x40||0x14||0x54||Note DDRAM addresses |- |20_Characters_4_Lines_KS0073||20||4||0x00||0x20||0x40||0x60||Note DDRAM addresses |- |27_Characters_4_Lines_2_EN||27||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |- |40_Characters_4_Lines_2_EN||40||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |} '''Note:''' The HD44780 module drivers supports '''alphanumeric character LCDs''' only. Ethersex also has limited support for some graphical displays. Have a look at the LC-Display configuration. = Configuration = ... │ │ Network ---> │ │ I/O ---> ... │ │ ADC / DAC ---> │ │ LCD Displays ---> ... │ │ [*] HD44780 module driver (Character-LCD) ---> │ │ [-] HR20-style LCD Display ... │ │ (16_Characters_2_Lines) LCD size/type │ │ (HD44780_Compat) LCD controller type │ │ (None) LCD charset conversion │ │ (I2C) Connection type │ │ (PCF8574) I2C Port Expander │ │ [*] Readback support │ │ [*] Backlight support │ │ [*] Backlight on at power-on │ │ [*] Invert Backlight switch '''Configuration options:''' [[File:Displaytech 404b charconv.jpg|thumb|400px|right|text top|Displaytech 404b 4x40 LCD with output of ECMD lcd print charset 0 128 and selected HD44780_Compat charset conversion]] ;LCD size/type : Select one of the defined display sizes and address configurations shown in the table [[#Supported LC-Displays]] above. : : Although it is technically possible to connect more than one display, the HD44780 module supports only one LC-Display at a time. ;LCD controller type : Select LCD controller circuit: : :* HD44780_Compat - most controllers are compatible to Hitachis HD44780 :* KS0066U - Samsungs KS0066U requires a different init routine : : Almost all controllers for alphanumeric character LCDs are more or less HD44780-compatible at least at the feature- and function-level required by e6. : : If in doubt, choose HD44780_Compat. ;LCD charset conversion : Select charset conversion used while writing to the lcd: : :* None - use no charset conversion at all (safes program mem) :* HD44780_Compat - map characters from ISO8859-1 to the original HD44780 charset : : Almost all controllers use their own non-ISO-compatible charset, varying between manufacturers, rom versions, etc. that provides characters from western languages as well as japanese, chinese and graphical glyphs. : : Charset conversion might become useful if you have to display messages and texts from external resources that uses standard encodings for their charset like ISO8859-1. : : Note: Charset conversion uses a lookup table and requires about 272 byte program memory (flash rom). ;Connection type : Select the connection type for the LCD: : :* Direct - direct connection using avr io-pins :* I2C - uses sub-selection of I2C port expander :* SER_LCD(74hct164) - serial connection using HCT164 shift register :* 2WIRE(74hct4094) - serial connection using HCT4094 shift register : : See section [[#Pinning]] below for further explanations. : ;I2C Port Expander : Select I2C Port Expander to use: : :* PCF8574 - use PCF8574x as I2C port expander :* MCP23017 - use MCP23017 as I2C port expander : : Note: automatically enables I2C_MASTER_SUPPORT and I2C_PCF8574X_SUPPORT resp. I2C_MCP23017_SUPPORT when selected. : : Note: Selection is only valid when '''I2C''' was selected under '''Connection type'''. : See section [[#Pinning]] below for further explanations. ;Readback support : Enable support for bi-directional lcd bus to read LCDs busy flag. Supported by direct and I2C connection only. : : You '''definitly should use a readback capable hardware and enable this feature''', saves lots of delays. ;Backlight support : Backlight support for LCDs based on the HD44780 controller. : : Enable backlight on/off control via API and ECMD. ;Backlight on at power-on : Switch on backlight at power-on/reset. ;Invert Backlight switch : Invert backlight logic for low active backlight circuits e.g. found on Pollin AVR NET-IO Add-on. = Pinning = HD44780-based alphanumeric LCDs are connected via 8 databus-lines (D0..D7) and 3 control-lines (RS, EN, R/W). Displays with more than 80 characters usually utilize a second controller and require two EN-signals EN1 and EN2. Another signal BL is needed if backlight control ist required. To save some i/o-pins the HD44780 controller also supports a 4 Bit mode, using only D4..D7. The HD44780 module supports this 4 Bit mode only. Note that in general the signals D0..D3 should not be left open, use a pull-down or tie them to ground. Most displays use 14, 16 or 18-pin connectors with common pinouts but there are sometimes subtle differences. Beside the control- and data-signals all displays require a supply voltage Vdd, usually +5 V, for the logic circuits and another voltage Vo for the display itself. The later is usually derived using a trimmer which allows for contrast adjustment. Some displays require a ''negative'' voltage for the display. Please refer to the datasheet of '''your''' display! Wrong connections may lead to a permanent damage. The HD44780 module supports four different types of connection: Direct, I2C, Serial and 2-Wire. == Direct == The LCD signals RS, RW, EN (resp. EN1 and EN2), D4..D7 and BL are directly connected to AVR port pins. The driver makes no assumptions about the pin mapping, arbitrary pins from different ports may be used to drive the LCD signals. This connection type is Readback-capable. The following example maps the LCD pins to AVR port pins found on the 25 pin Sub-D connector of the Pollin AVR Net-IO board: <code> dnl Direct connection example dnl map LCD pins to Pollin AVR Net-IO dnl 25 pin extension port ifdef(`conf_HD44780', ` pin(HD44780_RS, PC4) pin(HD44780_RW, PC3) pin(HD44780_EN1, PC2) dnl pin(HD44780_EN2, PC5) pin(HD44780_D4, PA0) pin(HD44780_D5, PA1) pin(HD44780_D6, PA2) pin(HD44780_D7, PA3) ') ifdef(`conf_HD44780_BACKLIGHT', ` pin(HD44780_BL, PC6, OUTPUT) ') </code> == I2C == The I2C connection type supports either the 8 Bit PCF8574x, as it is found on the Pollin AVR Net-IO Add-On board, or the 16 Bit MCP23017 I2C Port Expander. LCDs up to 80 characters and only one HD44780 controller may be connected to a PCF8574x including the backlight control pin. LCDs with more than 80 characters require a second enable pin. The address of the port expander and the pinning for the LCD has to be specified for your hardware using the macros shown below. The macro HD44780_PCF8574x_MAPPING defines the pinning for displays with only one enable signal and backlight control, the macro HD44780_PCF8574x_MULTI_MAPPING for displays with two enable signals. Note that backlight control is not supported when using the HD44780_PCF8574x_MULTI_MAPPING macro. The pinning shown in the examples below matches the pinning found on the Pollin AVR Net-IO Add-On board. Remember that you have to replace the inverting backlight control circuitry with a direct connection to connect displays with two enable signals to this board. The macros HD44780_MCP23017_MAPPING and HD44780_MCP23017_MULTI_MAPPING are used to map the LCD pins to one port of the MCP23017. Note that you have to specify either port A or B as shown below, mapping using mixed pins of both ports is not supported by the driver. The additional macro HD44780_MCP23017_MULTI_MAPPING_BL may be used to specify a backlight control signal on another MCP23017 port when the first port is occupied by a display with two enable signals. The driver exclusively controls the pin specified, the other 7 port pins may be used for different purposes. Connection type I2C is Readback-capable with both types of I2C Port Expanders. <code> ifelse(value_HD44780_CONNECTION,`HD44780_I2CSUPPORT',`dnl ifelse(value_HD44780_I2C_PORTEXP,`HD44780_I2C_PCF8574', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_PCF8574x_MULTI_MAPPING(ADR, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_PCF8574x_MULTI_MAPPING(0x20, 4, 5, 6, 7, 0, 1, 2, 3)', `dnl dnl HD44780_PCF8574x_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_PCF8574x_MAPPING(0x20, 4, 5, 6, 0, 1, 2, 3, 7)')', value_HD44780_I2C_PORTEXP,`HD44780_I2C_MCP23017', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_MCP23017_MULTI_MAPPING(ADR, PORT, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_MCP23017_MULTI_MAPPING(0x24, B, 4, 5, 6, 7, 0, 1, 2, 3) HD44780_MCP23017_MULTI_MAPPING_BL(0x24, A, 7)', `dnl dnl HD44780_MCP23017_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_MCP23017_MAPPING(0x24, B, 4, 5, 6, 0, 1, 2, 3, 7)')' )dnl ')dnl </code> == Serial (using 74HCT164) == The LCD is connected using a 74HC(T)164 shift register. Refer to Ulrich Radig's [http://www.ulrichradig.de/home/index.php/software/avr-webserver-software avr-webserver] for an example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection requires three AVR port pins pin(HD44780_SER_D, PD4) pin(HD44780_SER_CLK, PD3) pin(HD44780_SER_EN1, PD2) </code> == 2-Wire (using 74HCT4094) == The LCD is connected using a 74HC(T)4094 shift register. Refer to [http://www.cczwei.de/atm18_downloads/071148-D%20CC2-AVR-board-2.pdf this] paper for an explanation and example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection using a 4094 shift register requires two AVR port pins ifdef(`HD44780_2WIRE', ` pin(HD44780_2WIRE_D, PC0) pin(HD44780_2WIRE_CLK, PC1) ') </code> a0d59f25c5505d28edb60bb5c24181defdfabb6a 1775 1774 2016-12-09T23:12:09Z Michaelb 718 /* I2C */ wikitext text/x-wiki {{i18n|HD44780}} {{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->HD44780 module driver (Character-LCD) |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/lcd https://github.com/ethersex/ethersex/tree/master/hardware/lcd] }} ---- '''''THIS WIKI PAGE IS CURRENTLY WORK IN PROGRESS''''' ---- The '''HD44780 module''' provides support for common '''alphanumeric character LCDs''' using Hitachis HD44780 and compatible controllers. = Supported LC-Displays = The vast majority of all alphanumeric LC-Displays use Hitachis [https://en.wikipedia.org/wiki/Hitachi_HD44780_LCD_controller HD44780] dot matrix liquid crystal display (LCD) controller. The e6 HD44780 module supports displays of many different sizes utilizing the original HD44780 and compatible controllers. Alphanumeric LCDs are mainly distinguished by their size, the start-address of the per line Display Data-RAM (DDRAM) and the controller type. The original HD44780 controllers can drive up to 80 characters - most displays with more characters use two independent controllers. The following table lists the LC-displays supported by the e6 HD44780 module by size and per line DDRAM start-address: [[File:HD44780 Testbed.jpg|thumb|400px|right|text top|HD44780 module test]] {| class="wikitable" !colspan="1"|Menuconfig !colspan="2"|Size !colspan="4"|DDRAM Startaddress !rowspan="2"|Note: |- !LCD size/type||Characters||Lines||Line 1||Line 2||Line 3||Line 4 |- |8_Characters_1_Line||8||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line||16||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line_Mux16||16||1||0x00||n/a||n/a||n/a||organized as 8 chars, 2 lines |- |20_Characters_1_Line||20||1||0x00||n/a||n/a||n/a|| |- |40_Characters_1_Line||40||1||0x00||n/a||n/a||n/a|| |- |8_Characters_2_Lines||8||2||0x00||0x40||n/a||n/a|| |- |12_Characters_2_Lines||12||2||0x00||0x40||n/a||n/a|| |- |16_Characters_2_Lines||16||2||0x00||0x40||n/a||n/a|| |- |20_Characters_2_Lines||20||2||0x00||0x40||n/a||n/a|| |- |24_Characters_2_Lines||24||2||0x00||0x40||n/a||n/a|| |- |40_Characters_2_Lines||40||2||0x00||0x40||n/a||n/a|| |- |16_Characters_4_Lines||16||4||0x00||0x40||0x10||0x50|| |- |20_Characters_4_Lines||20||4||0x00||0x40||0x14||0x54||Note DDRAM addresses |- |20_Characters_4_Lines_KS0073||20||4||0x00||0x20||0x40||0x60||Note DDRAM addresses |- |27_Characters_4_Lines_2_EN||27||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |- |40_Characters_4_Lines_2_EN||40||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |} '''Note:''' The HD44780 module drivers supports '''alphanumeric character LCDs''' only. Ethersex also has limited support for some graphical displays. Have a look at the LC-Display configuration. = Configuration = ... │ │ Network ---> │ │ I/O ---> ... │ │ ADC / DAC ---> │ │ LCD Displays ---> ... │ │ [*] HD44780 module driver (Character-LCD) ---> │ │ [-] HR20-style LCD Display ... │ │ (16_Characters_2_Lines) LCD size/type │ │ (HD44780_Compat) LCD controller type │ │ (None) LCD charset conversion │ │ (I2C) Connection type │ │ (PCF8574) I2C Port Expander │ │ [*] Readback support │ │ [*] Backlight support │ │ [*] Backlight on at power-on │ │ [*] Invert Backlight switch '''Configuration options:''' [[File:Displaytech 404b charconv.jpg|thumb|400px|right|text top|Displaytech 404b 4x40 LCD with output of ECMD lcd print charset 0 128 and selected HD44780_Compat charset conversion]] ;LCD size/type : Select one of the defined display sizes and address configurations shown in the table [[#Supported LC-Displays]] above. : : Although it is technically possible to connect more than one display, the HD44780 module supports only one LC-Display at a time. ;LCD controller type : Select LCD controller circuit: : :* HD44780_Compat - most controllers are compatible to Hitachis HD44780 :* KS0066U - Samsungs KS0066U requires a different init routine : : Almost all controllers for alphanumeric character LCDs are more or less HD44780-compatible at least at the feature- and function-level required by e6. : : If in doubt, choose HD44780_Compat. ;LCD charset conversion : Select charset conversion used while writing to the lcd: : :* None - use no charset conversion at all (safes program mem) :* HD44780_Compat - map characters from ISO8859-1 to the original HD44780 charset : : Almost all controllers use their own non-ISO-compatible charset, varying between manufacturers, rom versions, etc. that provides characters from western languages as well as japanese, chinese and graphical glyphs. : : Charset conversion might become useful if you have to display messages and texts from external resources that uses standard encodings for their charset like ISO8859-1. : : Note: Charset conversion uses a lookup table and requires about 272 byte program memory (flash rom). ;Connection type : Select the connection type for the LCD: : :* Direct - direct connection using avr io-pins :* I2C - uses sub-selection of I2C port expander :* SER_LCD(74hct164) - serial connection using HCT164 shift register :* 2WIRE(74hct4094) - serial connection using HCT4094 shift register : : See section [[#Pinning]] below for further explanations. : ;I2C Port Expander : Select I2C Port Expander to use: : :* PCF8574 - use PCF8574x as I2C port expander :* MCP23017 - use MCP23017 as I2C port expander : : Note: automatically enables I2C_MASTER_SUPPORT and I2C_PCF8574X_SUPPORT resp. I2C_MCP23017_SUPPORT when selected. : : Note: Selection is only valid when '''I2C''' was selected under '''Connection type'''. : See section [[#Pinning]] below for further explanations. ;Readback support : Enable support for bi-directional lcd bus to read LCDs busy flag. Supported by direct and I2C connection only. : : You '''definitly should use a readback capable hardware and enable this feature''', saves lots of delays. ;Backlight support : Backlight support for LCDs based on the HD44780 controller. : : Enable backlight on/off control via API and ECMD. ;Backlight on at power-on : Switch on backlight at power-on/reset. ;Invert Backlight switch : Invert backlight logic for low active backlight circuits e.g. found on Pollin AVR NET-IO Add-on. = Pinning = HD44780-based alphanumeric LCDs are connected via 8 databus-lines (D0..D7) and 3 control-lines (RS, EN, R/W). Displays with more than 80 characters usually utilize a second controller and require two EN-signals EN1 and EN2. Another signal BL is needed if backlight control ist required. To save some i/o-pins the HD44780 controller also supports a 4 Bit mode, using only D4..D7. The HD44780 module supports this 4 Bit mode only. Note that in general the signals D0..D3 should not be left open, use a pull-down or tie them to ground. Most displays use 14, 16 or 18-pin connectors with common pinouts but there are sometimes subtle differences. Beside the control- and data-signals all displays require a supply voltage Vdd, usually +5 V, for the logic circuits and another voltage Vo for the display itself. The later is usually derived using a trimmer which allows for contrast adjustment. Some displays require a ''negative'' voltage for the display. Please refer to the datasheet of '''your''' display! Wrong connections may lead to a permanent damage. The HD44780 module supports four different types of connection: Direct, I2C, Serial and 2-Wire. == Direct == The LCD signals RS, RW, EN (resp. EN1 and EN2), D4..D7 and BL are directly connected to AVR port pins. The driver makes no assumptions about the pin mapping, arbitrary pins from different ports may be used to drive the LCD signals. This connection type is Readback-capable. The following example maps the LCD pins to AVR port pins found on the 25 pin Sub-D connector of the Pollin AVR Net-IO board: <code> dnl Direct connection example dnl map LCD pins to Pollin AVR Net-IO dnl 25 pin extension port ifdef(`conf_HD44780', ` pin(HD44780_RS, PC4) pin(HD44780_RW, PC3) pin(HD44780_EN1, PC2) dnl pin(HD44780_EN2, PC5) pin(HD44780_D4, PA0) pin(HD44780_D5, PA1) pin(HD44780_D6, PA2) pin(HD44780_D7, PA3) ') ifdef(`conf_HD44780_BACKLIGHT', ` pin(HD44780_BL, PC6, OUTPUT) ') </code> == I2C == The I2C connection type supports either the 8 Bit PCF8574x, as it is found on the Pollin AVR Net-IO Add-On board, or the 16 Bit MCP23017 I2C Port Expander. LCDs up to 80 characters and only one HD44780 controller may be connected to a PCF8574x including the backlight control pin. LCDs with more than 80 characters require a second enable pin. The address of the port expander and the pinning for the LCD has to be specified for your hardware using the macros shown below. The macro HD44780_PCF8574x_MAPPING defines the pinning for displays with only one enable signal and backlight control, the macro HD44780_PCF8574x_MULTI_MAPPING for displays with two enable signals. Note that backlight control is not supported when using the HD44780_PCF8574x_MULTI_MAPPING macro. The pinning shown in the examples below matches the pinning found on the Pollin AVR Net-IO Add-On board. Remember that you have to replace the inverting backlight control circuitry with a direct connection to connect displays with two enable signals to this board. The macros HD44780_MCP23017_MAPPING and HD44780_MCP23017_MULTI_MAPPING are used to map the LCD pins to one port of the MCP23017. Note that you have to specify either port A or B as shown below, mapping using mixed pins of both ports is not supported by the driver. The additional macro HD44780_MCP23017_MULTI_MAPPING_BL may be used to specify a backlight control signal on another MCP23017 port when the first port is occupied by a display with two enable signals. The driver exclusively controls the BL pin specified, the other 7 port pins may be used for different purposes. Connection type I2C is Readback-capable with both types of I2C Port Expanders. <code> ifelse(value_HD44780_CONNECTION,`HD44780_I2CSUPPORT',`dnl ifelse(value_HD44780_I2C_PORTEXP,`HD44780_I2C_PCF8574', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_PCF8574x_MULTI_MAPPING(ADR, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_PCF8574x_MULTI_MAPPING(0x20, 4, 5, 6, 7, 0, 1, 2, 3)', `dnl dnl HD44780_PCF8574x_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_PCF8574x_MAPPING(0x20, 4, 5, 6, 0, 1, 2, 3, 7)')', value_HD44780_I2C_PORTEXP,`HD44780_I2C_MCP23017', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_MCP23017_MULTI_MAPPING(ADR, PORT, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_MCP23017_MULTI_MAPPING(0x24, B, 4, 5, 6, 7, 0, 1, 2, 3) HD44780_MCP23017_MULTI_MAPPING_BL(0x24, A, 7)', `dnl dnl HD44780_MCP23017_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_MCP23017_MAPPING(0x24, B, 4, 5, 6, 0, 1, 2, 3, 7)')' )dnl ')dnl </code> == Serial (using 74HCT164) == The LCD is connected using a 74HC(T)164 shift register. Refer to Ulrich Radig's [http://www.ulrichradig.de/home/index.php/software/avr-webserver-software avr-webserver] for an example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection requires three AVR port pins pin(HD44780_SER_D, PD4) pin(HD44780_SER_CLK, PD3) pin(HD44780_SER_EN1, PD2) </code> == 2-Wire (using 74HCT4094) == The LCD is connected using a 74HC(T)4094 shift register. Refer to [http://www.cczwei.de/atm18_downloads/071148-D%20CC2-AVR-board-2.pdf this] paper for an explanation and example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection using a 4094 shift register requires two AVR port pins ifdef(`HD44780_2WIRE', ` pin(HD44780_2WIRE_D, PC0) pin(HD44780_2WIRE_CLK, PC1) ') </code> 50eb032d2d37c179e7bda391c82e74ec3d32c9c8 1776 1775 2016-12-09T23:14:46Z Michaelb 718 /* I2C */ wikitext text/x-wiki {{i18n|HD44780}} {{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->HD44780 module driver (Character-LCD) |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/lcd https://github.com/ethersex/ethersex/tree/master/hardware/lcd] }} ---- '''''THIS WIKI PAGE IS CURRENTLY WORK IN PROGRESS''''' ---- The '''HD44780 module''' provides support for common '''alphanumeric character LCDs''' using Hitachis HD44780 and compatible controllers. = Supported LC-Displays = The vast majority of all alphanumeric LC-Displays use Hitachis [https://en.wikipedia.org/wiki/Hitachi_HD44780_LCD_controller HD44780] dot matrix liquid crystal display (LCD) controller. The e6 HD44780 module supports displays of many different sizes utilizing the original HD44780 and compatible controllers. Alphanumeric LCDs are mainly distinguished by their size, the start-address of the per line Display Data-RAM (DDRAM) and the controller type. The original HD44780 controllers can drive up to 80 characters - most displays with more characters use two independent controllers. The following table lists the LC-displays supported by the e6 HD44780 module by size and per line DDRAM start-address: [[File:HD44780 Testbed.jpg|thumb|400px|right|text top|HD44780 module test]] {| class="wikitable" !colspan="1"|Menuconfig !colspan="2"|Size !colspan="4"|DDRAM Startaddress !rowspan="2"|Note: |- !LCD size/type||Characters||Lines||Line 1||Line 2||Line 3||Line 4 |- |8_Characters_1_Line||8||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line||16||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line_Mux16||16||1||0x00||n/a||n/a||n/a||organized as 8 chars, 2 lines |- |20_Characters_1_Line||20||1||0x00||n/a||n/a||n/a|| |- |40_Characters_1_Line||40||1||0x00||n/a||n/a||n/a|| |- |8_Characters_2_Lines||8||2||0x00||0x40||n/a||n/a|| |- |12_Characters_2_Lines||12||2||0x00||0x40||n/a||n/a|| |- |16_Characters_2_Lines||16||2||0x00||0x40||n/a||n/a|| |- |20_Characters_2_Lines||20||2||0x00||0x40||n/a||n/a|| |- |24_Characters_2_Lines||24||2||0x00||0x40||n/a||n/a|| |- |40_Characters_2_Lines||40||2||0x00||0x40||n/a||n/a|| |- |16_Characters_4_Lines||16||4||0x00||0x40||0x10||0x50|| |- |20_Characters_4_Lines||20||4||0x00||0x40||0x14||0x54||Note DDRAM addresses |- |20_Characters_4_Lines_KS0073||20||4||0x00||0x20||0x40||0x60||Note DDRAM addresses |- |27_Characters_4_Lines_2_EN||27||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |- |40_Characters_4_Lines_2_EN||40||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |} '''Note:''' The HD44780 module drivers supports '''alphanumeric character LCDs''' only. Ethersex also has limited support for some graphical displays. Have a look at the LC-Display configuration. = Configuration = ... │ │ Network ---> │ │ I/O ---> ... │ │ ADC / DAC ---> │ │ LCD Displays ---> ... │ │ [*] HD44780 module driver (Character-LCD) ---> │ │ [-] HR20-style LCD Display ... │ │ (16_Characters_2_Lines) LCD size/type │ │ (HD44780_Compat) LCD controller type │ │ (None) LCD charset conversion │ │ (I2C) Connection type │ │ (PCF8574) I2C Port Expander │ │ [*] Readback support │ │ [*] Backlight support │ │ [*] Backlight on at power-on │ │ [*] Invert Backlight switch '''Configuration options:''' [[File:Displaytech 404b charconv.jpg|thumb|400px|right|text top|Displaytech 404b 4x40 LCD with output of ECMD lcd print charset 0 128 and selected HD44780_Compat charset conversion]] ;LCD size/type : Select one of the defined display sizes and address configurations shown in the table [[#Supported LC-Displays]] above. : : Although it is technically possible to connect more than one display, the HD44780 module supports only one LC-Display at a time. ;LCD controller type : Select LCD controller circuit: : :* HD44780_Compat - most controllers are compatible to Hitachis HD44780 :* KS0066U - Samsungs KS0066U requires a different init routine : : Almost all controllers for alphanumeric character LCDs are more or less HD44780-compatible at least at the feature- and function-level required by e6. : : If in doubt, choose HD44780_Compat. ;LCD charset conversion : Select charset conversion used while writing to the lcd: : :* None - use no charset conversion at all (safes program mem) :* HD44780_Compat - map characters from ISO8859-1 to the original HD44780 charset : : Almost all controllers use their own non-ISO-compatible charset, varying between manufacturers, rom versions, etc. that provides characters from western languages as well as japanese, chinese and graphical glyphs. : : Charset conversion might become useful if you have to display messages and texts from external resources that uses standard encodings for their charset like ISO8859-1. : : Note: Charset conversion uses a lookup table and requires about 272 byte program memory (flash rom). ;Connection type : Select the connection type for the LCD: : :* Direct - direct connection using avr io-pins :* I2C - uses sub-selection of I2C port expander :* SER_LCD(74hct164) - serial connection using HCT164 shift register :* 2WIRE(74hct4094) - serial connection using HCT4094 shift register : : See section [[#Pinning]] below for further explanations. : ;I2C Port Expander : Select I2C Port Expander to use: : :* PCF8574 - use PCF8574x as I2C port expander :* MCP23017 - use MCP23017 as I2C port expander : : Note: automatically enables I2C_MASTER_SUPPORT and I2C_PCF8574X_SUPPORT resp. I2C_MCP23017_SUPPORT when selected. : : Note: Selection is only valid when '''I2C''' was selected under '''Connection type'''. : See section [[#Pinning]] below for further explanations. ;Readback support : Enable support for bi-directional lcd bus to read LCDs busy flag. Supported by direct and I2C connection only. : : You '''definitly should use a readback capable hardware and enable this feature''', saves lots of delays. ;Backlight support : Backlight support for LCDs based on the HD44780 controller. : : Enable backlight on/off control via API and ECMD. ;Backlight on at power-on : Switch on backlight at power-on/reset. ;Invert Backlight switch : Invert backlight logic for low active backlight circuits e.g. found on Pollin AVR NET-IO Add-on. = Pinning = HD44780-based alphanumeric LCDs are connected via 8 databus-lines (D0..D7) and 3 control-lines (RS, EN, R/W). Displays with more than 80 characters usually utilize a second controller and require two EN-signals EN1 and EN2. Another signal BL is needed if backlight control ist required. To save some i/o-pins the HD44780 controller also supports a 4 Bit mode, using only D4..D7. The HD44780 module supports this 4 Bit mode only. Note that in general the signals D0..D3 should not be left open, use a pull-down or tie them to ground. Most displays use 14, 16 or 18-pin connectors with common pinouts but there are sometimes subtle differences. Beside the control- and data-signals all displays require a supply voltage Vdd, usually +5 V, for the logic circuits and another voltage Vo for the display itself. The later is usually derived using a trimmer which allows for contrast adjustment. Some displays require a ''negative'' voltage for the display. Please refer to the datasheet of '''your''' display! Wrong connections may lead to a permanent damage. The HD44780 module supports four different types of connection: Direct, I2C, Serial and 2-Wire. == Direct == The LCD signals RS, RW, EN (resp. EN1 and EN2), D4..D7 and BL are directly connected to AVR port pins. The driver makes no assumptions about the pin mapping, arbitrary pins from different ports may be used to drive the LCD signals. This connection type is Readback-capable. The following example maps the LCD pins to AVR port pins found on the 25 pin Sub-D connector of the Pollin AVR Net-IO board: <code> dnl Direct connection example dnl map LCD pins to Pollin AVR Net-IO dnl 25 pin extension port ifdef(`conf_HD44780', ` pin(HD44780_RS, PC4) pin(HD44780_RW, PC3) pin(HD44780_EN1, PC2) dnl pin(HD44780_EN2, PC5) pin(HD44780_D4, PA0) pin(HD44780_D5, PA1) pin(HD44780_D6, PA2) pin(HD44780_D7, PA3) ') ifdef(`conf_HD44780_BACKLIGHT', ` pin(HD44780_BL, PC6, OUTPUT) ') </code> == I2C == The I2C connection type supports either the 8 Bit PCF8574x, as it is found on the Pollin AVR Net-IO Add-On board, or the 16 Bit MCP23017 I2C Port Expander. LCDs up to 80 characters and only one HD44780 controller may be connected to a PCF8574x including the backlight control pin. LCDs with more than 80 characters require a second enable pin. The address of the port expander and the pinning for the LCD has to be specified for your hardware using the macros shown below. The macro HD44780_PCF8574x_MAPPING defines the pinning for displays with only one enable signal and backlight control, the macro HD44780_PCF8574x_MULTI_MAPPING for displays with two enable signals. Note that backlight control is not supported when using the HD44780_PCF8574x_MULTI_MAPPING macro. The pinning shown in the examples below matches the pinning found on the Pollin AVR Net-IO Add-On board. Remember that you have to replace the inverting backlight control circuitry with a direct connection to connect displays with two enable signals to this board. The macros HD44780_MCP23017_MAPPING and HD44780_MCP23017_MULTI_MAPPING are used to map the LCD pins to one port of the MCP23017. Note that you have to specify either port A or B as shown below, mapping using mixed pins of both ports is not supported by the driver. The additional macro HD44780_MCP23017_MULTI_MAPPING_BL may be used to specify a backlight control signal on another MCP23017 port when the first port is occupied by a display with two enable signals. The driver exclusively controls the BL pin specified, the other 7 port pins may be used for different purposes. Connection type I2C is Readback-capable with both types of I2C Port Expanders. <code> dnl HD44780 LCD to I2C Port Expander mapping ifelse(value_HD44780_CONNECTION,`HD44780_I2CSUPPORT',`dnl ifelse(value_HD44780_I2C_PORTEXP,`HD44780_I2C_PCF8574', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_PCF8574x_MULTI_MAPPING(ADR, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_PCF8574x_MULTI_MAPPING(0x20, 4, 5, 6, 7, 0, 1, 2, 3)', `dnl dnl HD44780_PCF8574x_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_PCF8574x_MAPPING(0x20, 4, 5, 6, 0, 1, 2, 3, 7)')', value_HD44780_I2C_PORTEXP,`HD44780_I2C_MCP23017', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_MCP23017_MULTI_MAPPING(ADR, PORT, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_MCP23017_MULTI_MAPPING(0x24, B, 4, 5, 6, 7, 0, 1, 2, 3) HD44780_MCP23017_MULTI_MAPPING_BL(0x24, A, 7)', `dnl dnl HD44780_MCP23017_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_MCP23017_MAPPING(0x24, B, 4, 5, 6, 0, 1, 2, 3, 7)')' )dnl ')dnl </code> == Serial (using 74HCT164) == The LCD is connected using a 74HC(T)164 shift register. Refer to Ulrich Radig's [http://www.ulrichradig.de/home/index.php/software/avr-webserver-software avr-webserver] for an example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection requires three AVR port pins pin(HD44780_SER_D, PD4) pin(HD44780_SER_CLK, PD3) pin(HD44780_SER_EN1, PD2) </code> == 2-Wire (using 74HCT4094) == The LCD is connected using a 74HC(T)4094 shift register. Refer to [http://www.cczwei.de/atm18_downloads/071148-D%20CC2-AVR-board-2.pdf this] paper for an explanation and example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection using a 4094 shift register requires two AVR port pins ifdef(`HD44780_2WIRE', ` pin(HD44780_2WIRE_D, PC0) pin(HD44780_2WIRE_CLK, PC1) ') </code> 19111d3a86c0ffc257fee00063ba43e5853f1068 1777 1776 2016-12-09T23:15:22Z Michaelb 718 /* Direct */ wikitext text/x-wiki {{i18n|HD44780}} {{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->HD44780 module driver (Character-LCD) |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/lcd https://github.com/ethersex/ethersex/tree/master/hardware/lcd] }} ---- '''''THIS WIKI PAGE IS CURRENTLY WORK IN PROGRESS''''' ---- The '''HD44780 module''' provides support for common '''alphanumeric character LCDs''' using Hitachis HD44780 and compatible controllers. = Supported LC-Displays = The vast majority of all alphanumeric LC-Displays use Hitachis [https://en.wikipedia.org/wiki/Hitachi_HD44780_LCD_controller HD44780] dot matrix liquid crystal display (LCD) controller. The e6 HD44780 module supports displays of many different sizes utilizing the original HD44780 and compatible controllers. Alphanumeric LCDs are mainly distinguished by their size, the start-address of the per line Display Data-RAM (DDRAM) and the controller type. The original HD44780 controllers can drive up to 80 characters - most displays with more characters use two independent controllers. The following table lists the LC-displays supported by the e6 HD44780 module by size and per line DDRAM start-address: [[File:HD44780 Testbed.jpg|thumb|400px|right|text top|HD44780 module test]] {| class="wikitable" !colspan="1"|Menuconfig !colspan="2"|Size !colspan="4"|DDRAM Startaddress !rowspan="2"|Note: |- !LCD size/type||Characters||Lines||Line 1||Line 2||Line 3||Line 4 |- |8_Characters_1_Line||8||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line||16||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line_Mux16||16||1||0x00||n/a||n/a||n/a||organized as 8 chars, 2 lines |- |20_Characters_1_Line||20||1||0x00||n/a||n/a||n/a|| |- |40_Characters_1_Line||40||1||0x00||n/a||n/a||n/a|| |- |8_Characters_2_Lines||8||2||0x00||0x40||n/a||n/a|| |- |12_Characters_2_Lines||12||2||0x00||0x40||n/a||n/a|| |- |16_Characters_2_Lines||16||2||0x00||0x40||n/a||n/a|| |- |20_Characters_2_Lines||20||2||0x00||0x40||n/a||n/a|| |- |24_Characters_2_Lines||24||2||0x00||0x40||n/a||n/a|| |- |40_Characters_2_Lines||40||2||0x00||0x40||n/a||n/a|| |- |16_Characters_4_Lines||16||4||0x00||0x40||0x10||0x50|| |- |20_Characters_4_Lines||20||4||0x00||0x40||0x14||0x54||Note DDRAM addresses |- |20_Characters_4_Lines_KS0073||20||4||0x00||0x20||0x40||0x60||Note DDRAM addresses |- |27_Characters_4_Lines_2_EN||27||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |- |40_Characters_4_Lines_2_EN||40||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |} '''Note:''' The HD44780 module drivers supports '''alphanumeric character LCDs''' only. Ethersex also has limited support for some graphical displays. Have a look at the LC-Display configuration. = Configuration = ... │ │ Network ---> │ │ I/O ---> ... │ │ ADC / DAC ---> │ │ LCD Displays ---> ... │ │ [*] HD44780 module driver (Character-LCD) ---> │ │ [-] HR20-style LCD Display ... │ │ (16_Characters_2_Lines) LCD size/type │ │ (HD44780_Compat) LCD controller type │ │ (None) LCD charset conversion │ │ (I2C) Connection type │ │ (PCF8574) I2C Port Expander │ │ [*] Readback support │ │ [*] Backlight support │ │ [*] Backlight on at power-on │ │ [*] Invert Backlight switch '''Configuration options:''' [[File:Displaytech 404b charconv.jpg|thumb|400px|right|text top|Displaytech 404b 4x40 LCD with output of ECMD lcd print charset 0 128 and selected HD44780_Compat charset conversion]] ;LCD size/type : Select one of the defined display sizes and address configurations shown in the table [[#Supported LC-Displays]] above. : : Although it is technically possible to connect more than one display, the HD44780 module supports only one LC-Display at a time. ;LCD controller type : Select LCD controller circuit: : :* HD44780_Compat - most controllers are compatible to Hitachis HD44780 :* KS0066U - Samsungs KS0066U requires a different init routine : : Almost all controllers for alphanumeric character LCDs are more or less HD44780-compatible at least at the feature- and function-level required by e6. : : If in doubt, choose HD44780_Compat. ;LCD charset conversion : Select charset conversion used while writing to the lcd: : :* None - use no charset conversion at all (safes program mem) :* HD44780_Compat - map characters from ISO8859-1 to the original HD44780 charset : : Almost all controllers use their own non-ISO-compatible charset, varying between manufacturers, rom versions, etc. that provides characters from western languages as well as japanese, chinese and graphical glyphs. : : Charset conversion might become useful if you have to display messages and texts from external resources that uses standard encodings for their charset like ISO8859-1. : : Note: Charset conversion uses a lookup table and requires about 272 byte program memory (flash rom). ;Connection type : Select the connection type for the LCD: : :* Direct - direct connection using avr io-pins :* I2C - uses sub-selection of I2C port expander :* SER_LCD(74hct164) - serial connection using HCT164 shift register :* 2WIRE(74hct4094) - serial connection using HCT4094 shift register : : See section [[#Pinning]] below for further explanations. : ;I2C Port Expander : Select I2C Port Expander to use: : :* PCF8574 - use PCF8574x as I2C port expander :* MCP23017 - use MCP23017 as I2C port expander : : Note: automatically enables I2C_MASTER_SUPPORT and I2C_PCF8574X_SUPPORT resp. I2C_MCP23017_SUPPORT when selected. : : Note: Selection is only valid when '''I2C''' was selected under '''Connection type'''. : See section [[#Pinning]] below for further explanations. ;Readback support : Enable support for bi-directional lcd bus to read LCDs busy flag. Supported by direct and I2C connection only. : : You '''definitly should use a readback capable hardware and enable this feature''', saves lots of delays. ;Backlight support : Backlight support for LCDs based on the HD44780 controller. : : Enable backlight on/off control via API and ECMD. ;Backlight on at power-on : Switch on backlight at power-on/reset. ;Invert Backlight switch : Invert backlight logic for low active backlight circuits e.g. found on Pollin AVR NET-IO Add-on. = Pinning = HD44780-based alphanumeric LCDs are connected via 8 databus-lines (D0..D7) and 3 control-lines (RS, EN, R/W). Displays with more than 80 characters usually utilize a second controller and require two EN-signals EN1 and EN2. Another signal BL is needed if backlight control ist required. To save some i/o-pins the HD44780 controller also supports a 4 Bit mode, using only D4..D7. The HD44780 module supports this 4 Bit mode only. Note that in general the signals D0..D3 should not be left open, use a pull-down or tie them to ground. Most displays use 14, 16 or 18-pin connectors with common pinouts but there are sometimes subtle differences. Beside the control- and data-signals all displays require a supply voltage Vdd, usually +5 V, for the logic circuits and another voltage Vo for the display itself. The later is usually derived using a trimmer which allows for contrast adjustment. Some displays require a ''negative'' voltage for the display. Please refer to the datasheet of '''your''' display! Wrong connections may lead to a permanent damage. The HD44780 module supports four different types of connection: Direct, I2C, Serial and 2-Wire. == Direct == The LCD signals RS, RW, EN (resp. EN1 and EN2), D4..D7 and BL are directly connected to AVR port pins. The driver makes no assumptions about the pin mapping, arbitrary pins from different ports may be used to drive the LCD signals. This connection type is Readback-capable. The following example maps the LCD pins to AVR port pins found on the 25 pin Sub-D connector of the Pollin AVR Net-IO board: <code> dnl Direct connection example dnl map LCD pins to Pollin AVR Net-IO 25 pin extension port ifdef(`conf_HD44780', ` pin(HD44780_RS, PC4) pin(HD44780_RW, PC3) pin(HD44780_EN1, PC2) dnl pin(HD44780_EN2, PC5) pin(HD44780_D4, PA0) pin(HD44780_D5, PA1) pin(HD44780_D6, PA2) pin(HD44780_D7, PA3) ') ifdef(`conf_HD44780_BACKLIGHT', ` pin(HD44780_BL, PC6, OUTPUT) ') </code> == I2C == The I2C connection type supports either the 8 Bit PCF8574x, as it is found on the Pollin AVR Net-IO Add-On board, or the 16 Bit MCP23017 I2C Port Expander. LCDs up to 80 characters and only one HD44780 controller may be connected to a PCF8574x including the backlight control pin. LCDs with more than 80 characters require a second enable pin. The address of the port expander and the pinning for the LCD has to be specified for your hardware using the macros shown below. The macro HD44780_PCF8574x_MAPPING defines the pinning for displays with only one enable signal and backlight control, the macro HD44780_PCF8574x_MULTI_MAPPING for displays with two enable signals. Note that backlight control is not supported when using the HD44780_PCF8574x_MULTI_MAPPING macro. The pinning shown in the examples below matches the pinning found on the Pollin AVR Net-IO Add-On board. Remember that you have to replace the inverting backlight control circuitry with a direct connection to connect displays with two enable signals to this board. The macros HD44780_MCP23017_MAPPING and HD44780_MCP23017_MULTI_MAPPING are used to map the LCD pins to one port of the MCP23017. Note that you have to specify either port A or B as shown below, mapping using mixed pins of both ports is not supported by the driver. The additional macro HD44780_MCP23017_MULTI_MAPPING_BL may be used to specify a backlight control signal on another MCP23017 port when the first port is occupied by a display with two enable signals. The driver exclusively controls the BL pin specified, the other 7 port pins may be used for different purposes. Connection type I2C is Readback-capable with both types of I2C Port Expanders. <code> dnl HD44780 LCD to I2C Port Expander mapping ifelse(value_HD44780_CONNECTION,`HD44780_I2CSUPPORT',`dnl ifelse(value_HD44780_I2C_PORTEXP,`HD44780_I2C_PCF8574', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_PCF8574x_MULTI_MAPPING(ADR, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_PCF8574x_MULTI_MAPPING(0x20, 4, 5, 6, 7, 0, 1, 2, 3)', `dnl dnl HD44780_PCF8574x_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_PCF8574x_MAPPING(0x20, 4, 5, 6, 0, 1, 2, 3, 7)')', value_HD44780_I2C_PORTEXP,`HD44780_I2C_MCP23017', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_MCP23017_MULTI_MAPPING(ADR, PORT, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_MCP23017_MULTI_MAPPING(0x24, B, 4, 5, 6, 7, 0, 1, 2, 3) HD44780_MCP23017_MULTI_MAPPING_BL(0x24, A, 7)', `dnl dnl HD44780_MCP23017_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_MCP23017_MAPPING(0x24, B, 4, 5, 6, 0, 1, 2, 3, 7)')' )dnl ')dnl </code> == Serial (using 74HCT164) == The LCD is connected using a 74HC(T)164 shift register. Refer to Ulrich Radig's [http://www.ulrichradig.de/home/index.php/software/avr-webserver-software avr-webserver] for an example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection requires three AVR port pins pin(HD44780_SER_D, PD4) pin(HD44780_SER_CLK, PD3) pin(HD44780_SER_EN1, PD2) </code> == 2-Wire (using 74HCT4094) == The LCD is connected using a 74HC(T)4094 shift register. Refer to [http://www.cczwei.de/atm18_downloads/071148-D%20CC2-AVR-board-2.pdf this] paper for an explanation and example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection using a 4094 shift register requires two AVR port pins ifdef(`HD44780_2WIRE', ` pin(HD44780_2WIRE_D, PC0) pin(HD44780_2WIRE_CLK, PC1) ') </code> ea3ae8e6f2d512d98b3890ebea1db2ce56d82b15 1778 1777 2016-12-09T23:24:23Z Michaelb 718 /* Pinning */ wikitext text/x-wiki {{i18n|HD44780}} {{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->HD44780 module driver (Character-LCD) |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/lcd https://github.com/ethersex/ethersex/tree/master/hardware/lcd] }} ---- '''''THIS WIKI PAGE IS CURRENTLY WORK IN PROGRESS''''' ---- The '''HD44780 module''' provides support for common '''alphanumeric character LCDs''' using Hitachis HD44780 and compatible controllers. = Supported LC-Displays = The vast majority of all alphanumeric LC-Displays use Hitachis [https://en.wikipedia.org/wiki/Hitachi_HD44780_LCD_controller HD44780] dot matrix liquid crystal display (LCD) controller. The e6 HD44780 module supports displays of many different sizes utilizing the original HD44780 and compatible controllers. Alphanumeric LCDs are mainly distinguished by their size, the start-address of the per line Display Data-RAM (DDRAM) and the controller type. The original HD44780 controllers can drive up to 80 characters - most displays with more characters use two independent controllers. The following table lists the LC-displays supported by the e6 HD44780 module by size and per line DDRAM start-address: [[File:HD44780 Testbed.jpg|thumb|400px|right|text top|HD44780 module test]] {| class="wikitable" !colspan="1"|Menuconfig !colspan="2"|Size !colspan="4"|DDRAM Startaddress !rowspan="2"|Note: |- !LCD size/type||Characters||Lines||Line 1||Line 2||Line 3||Line 4 |- |8_Characters_1_Line||8||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line||16||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line_Mux16||16||1||0x00||n/a||n/a||n/a||organized as 8 chars, 2 lines |- |20_Characters_1_Line||20||1||0x00||n/a||n/a||n/a|| |- |40_Characters_1_Line||40||1||0x00||n/a||n/a||n/a|| |- |8_Characters_2_Lines||8||2||0x00||0x40||n/a||n/a|| |- |12_Characters_2_Lines||12||2||0x00||0x40||n/a||n/a|| |- |16_Characters_2_Lines||16||2||0x00||0x40||n/a||n/a|| |- |20_Characters_2_Lines||20||2||0x00||0x40||n/a||n/a|| |- |24_Characters_2_Lines||24||2||0x00||0x40||n/a||n/a|| |- |40_Characters_2_Lines||40||2||0x00||0x40||n/a||n/a|| |- |16_Characters_4_Lines||16||4||0x00||0x40||0x10||0x50|| |- |20_Characters_4_Lines||20||4||0x00||0x40||0x14||0x54||Note DDRAM addresses |- |20_Characters_4_Lines_KS0073||20||4||0x00||0x20||0x40||0x60||Note DDRAM addresses |- |27_Characters_4_Lines_2_EN||27||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |- |40_Characters_4_Lines_2_EN||40||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |} '''Note:''' The HD44780 module drivers supports '''alphanumeric character LCDs''' only. Ethersex also has limited support for some graphical displays. Have a look at the LC-Display configuration. = Configuration = ... │ │ Network ---> │ │ I/O ---> ... │ │ ADC / DAC ---> │ │ LCD Displays ---> ... │ │ [*] HD44780 module driver (Character-LCD) ---> │ │ [-] HR20-style LCD Display ... │ │ (16_Characters_2_Lines) LCD size/type │ │ (HD44780_Compat) LCD controller type │ │ (None) LCD charset conversion │ │ (I2C) Connection type │ │ (PCF8574) I2C Port Expander │ │ [*] Readback support │ │ [*] Backlight support │ │ [*] Backlight on at power-on │ │ [*] Invert Backlight switch '''Configuration options:''' [[File:Displaytech 404b charconv.jpg|thumb|400px|right|text top|Displaytech 404b 4x40 LCD with output of ECMD lcd print charset 0 128 and selected HD44780_Compat charset conversion]] ;LCD size/type : Select one of the defined display sizes and address configurations shown in the table [[#Supported LC-Displays]] above. : : Although it is technically possible to connect more than one display, the HD44780 module supports only one LC-Display at a time. ;LCD controller type : Select LCD controller circuit: : :* HD44780_Compat - most controllers are compatible to Hitachis HD44780 :* KS0066U - Samsungs KS0066U requires a different init routine : : Almost all controllers for alphanumeric character LCDs are more or less HD44780-compatible at least at the feature- and function-level required by e6. : : If in doubt, choose HD44780_Compat. ;LCD charset conversion : Select charset conversion used while writing to the lcd: : :* None - use no charset conversion at all (safes program mem) :* HD44780_Compat - map characters from ISO8859-1 to the original HD44780 charset : : Almost all controllers use their own non-ISO-compatible charset, varying between manufacturers, rom versions, etc. that provides characters from western languages as well as japanese, chinese and graphical glyphs. : : Charset conversion might become useful if you have to display messages and texts from external resources that uses standard encodings for their charset like ISO8859-1. : : Note: Charset conversion uses a lookup table and requires about 272 byte program memory (flash rom). ;Connection type : Select the connection type for the LCD: : :* Direct - direct connection using avr io-pins :* I2C - uses sub-selection of I2C port expander :* SER_LCD(74hct164) - serial connection using HCT164 shift register :* 2WIRE(74hct4094) - serial connection using HCT4094 shift register : : See section [[#Pinning]] below for further explanations. : ;I2C Port Expander : Select I2C Port Expander to use: : :* PCF8574 - use PCF8574x as I2C port expander :* MCP23017 - use MCP23017 as I2C port expander : : Note: automatically enables I2C_MASTER_SUPPORT and I2C_PCF8574X_SUPPORT resp. I2C_MCP23017_SUPPORT when selected. : : Note: Selection is only valid when '''I2C''' was selected under '''Connection type'''. : See section [[#Pinning]] below for further explanations. ;Readback support : Enable support for bi-directional lcd bus to read LCDs busy flag. Supported by direct and I2C connection only. : : You '''definitly should use a readback capable hardware and enable this feature''', saves lots of delays. ;Backlight support : Backlight support for LCDs based on the HD44780 controller. : : Enable backlight on/off control via API and ECMD. ;Backlight on at power-on : Switch on backlight at power-on/reset. ;Invert Backlight switch : Invert backlight logic for low active backlight circuits e.g. found on Pollin AVR NET-IO Add-on. = Pinning = HD44780-based alphanumeric LCDs are connected via 8 databus-lines (D0..D7) and 3 control-lines (RS, EN, R/W). Displays with more than 80 characters usually utilize a second controller and require two EN-signals EN1 and EN2. Another signal BL is needed if backlight control ist required. To save some i/o-pins the HD44780 controller also supports a 4 Bit mode, using only D4..D7. The HD44780 module supports this 4 Bit mode only. Note that in general the signals D0..D3 should not be left open, use a pull-down or tie them to ground. Most displays use 14, 16 or 18-pin connectors with common pinouts but there are sometimes subtle differences. Beside the control- and data-signals all displays require a supply voltage Vdd, usually +5 V, for the logic circuits and another voltage Vo for the display itself. The later is usually derived using a trimming potentiometer that allows for contrast adjustment. Some displays require a ''negative'' voltage for the display. Please refer to the datasheet of '''your''' display! Wrong connections may lead to a permanent damage. The HD44780 module supports four different types of connection for the LCD: Direct, I2C, Serial and 2-Wire. == Direct == The LCD signals RS, RW, EN (resp. EN1 and EN2), D4..D7 and BL are directly connected to AVR port pins. The driver makes no assumptions about the pin mapping, arbitrary pins from different ports may be used to drive the LCD signals. This connection type is Readback-capable. The following example maps the LCD pins to AVR port pins found on the 25 pin Sub-D connector of the Pollin AVR Net-IO board: <code> dnl Direct connection example dnl map LCD pins to Pollin AVR Net-IO 25 pin extension port ifdef(`conf_HD44780', ` pin(HD44780_RS, PC4) pin(HD44780_RW, PC3) pin(HD44780_EN1, PC2) dnl pin(HD44780_EN2, PC5) pin(HD44780_D4, PA0) pin(HD44780_D5, PA1) pin(HD44780_D6, PA2) pin(HD44780_D7, PA3) ') ifdef(`conf_HD44780_BACKLIGHT', ` pin(HD44780_BL, PC6, OUTPUT) ') </code> == I2C == The I2C connection type supports either the 8 Bit PCF8574x, as it is found on the Pollin AVR Net-IO Add-On board, or the 16 Bit MCP23017 I2C Port Expander. LCDs up to 80 characters and only one HD44780 controller may be connected to a PCF8574x including the backlight control pin. LCDs with more than 80 characters require a second enable pin. The address of the port expander and the pinning for the LCD has to be specified for your hardware using the macros shown below. The macro HD44780_PCF8574x_MAPPING defines the pinning for displays with only one enable signal and backlight control, the macro HD44780_PCF8574x_MULTI_MAPPING for displays with two enable signals. Note that backlight control is not supported when using the HD44780_PCF8574x_MULTI_MAPPING macro. The pinning shown in the examples below matches the pinning found on the Pollin AVR Net-IO Add-On board. Remember that you have to replace the inverting backlight control circuitry with a direct connection to connect displays with two enable signals to this board. The macros HD44780_MCP23017_MAPPING and HD44780_MCP23017_MULTI_MAPPING are used to map the LCD pins to one port of the MCP23017. Note that you have to specify either port A or B as shown below, mapping using mixed pins of both ports is not supported by the driver. The additional macro HD44780_MCP23017_MULTI_MAPPING_BL may be used to specify a backlight control signal on another MCP23017 port when the first port is occupied by a display with two enable signals. The driver exclusively controls the BL pin specified, the other 7 port pins may be used for different purposes. Connection type I2C is Readback-capable with both types of I2C Port Expanders. <code> dnl HD44780 LCD to I2C Port Expander mapping ifelse(value_HD44780_CONNECTION,`HD44780_I2CSUPPORT',`dnl ifelse(value_HD44780_I2C_PORTEXP,`HD44780_I2C_PCF8574', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_PCF8574x_MULTI_MAPPING(ADR, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_PCF8574x_MULTI_MAPPING(0x20, 4, 5, 6, 7, 0, 1, 2, 3)', `dnl dnl HD44780_PCF8574x_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_PCF8574x_MAPPING(0x20, 4, 5, 6, 0, 1, 2, 3, 7)')', value_HD44780_I2C_PORTEXP,`HD44780_I2C_MCP23017', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_MCP23017_MULTI_MAPPING(ADR, PORT, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_MCP23017_MULTI_MAPPING(0x24, B, 4, 5, 6, 7, 0, 1, 2, 3) HD44780_MCP23017_MULTI_MAPPING_BL(0x24, A, 7)', `dnl dnl HD44780_MCP23017_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_MCP23017_MAPPING(0x24, B, 4, 5, 6, 0, 1, 2, 3, 7)')' )dnl ')dnl </code> == Serial (using 74HCT164) == The LCD is connected using a 74HC(T)164 shift register. Refer to Ulrich Radig's [http://www.ulrichradig.de/home/index.php/software/avr-webserver-software avr-webserver] for an example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection requires three AVR port pins pin(HD44780_SER_D, PD4) pin(HD44780_SER_CLK, PD3) pin(HD44780_SER_EN1, PD2) </code> == 2-Wire (using 74HCT4094) == The LCD is connected using a 74HC(T)4094 shift register. Refer to [http://www.cczwei.de/atm18_downloads/071148-D%20CC2-AVR-board-2.pdf this] paper for an explanation and example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection using a 4094 shift register requires two AVR port pins ifdef(`HD44780_2WIRE', ` pin(HD44780_2WIRE_D, PC0) pin(HD44780_2WIRE_CLK, PC1) ') </code> c431c600f7b0b5a3ec354af0d24308e28a90976d 1779 1778 2016-12-09T23:34:40Z Michaelb 718 wikitext text/x-wiki {{i18n|HD44780}} {{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->HD44780 module driver (Character-LCD) |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/lcd https://github.com/ethersex/ethersex/tree/master/hardware/lcd] }} ---- '''''THIS WIKI PAGE IS CURRENTLY WORK IN PROGRESS''''' ---- The '''HD44780 module''' provides support for common '''alphanumeric character LCDs''' using Hitachis HD44780 and compatible controllers. == Supported LC-Displays == The vast majority of all alphanumeric LC-Displays use Hitachis [https://en.wikipedia.org/wiki/Hitachi_HD44780_LCD_controller HD44780] dot matrix liquid crystal display (LCD) controller. The e6 HD44780 module supports displays of many different sizes utilizing the original HD44780 and compatible controllers. Alphanumeric LCDs are mainly distinguished by their size, the start-address of the per line Display Data-RAM (DDRAM) and the controller type. The original HD44780 controllers can drive up to 80 characters - most displays with more characters use two independent controllers. The following table lists the LC-displays supported by the e6 HD44780 module by size and per line DDRAM start-address: [[File:HD44780 Testbed.jpg|thumb|400px|right|text top|HD44780 module test]] {| class="wikitable" !colspan="1"|Menuconfig !colspan="2"|Size !colspan="4"|DDRAM Startaddress !rowspan="2"|Note: |- !LCD size/type||Characters||Lines||Line 1||Line 2||Line 3||Line 4 |- |8_Characters_1_Line||8||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line||16||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line_Mux16||16||1||0x00||n/a||n/a||n/a||organized as 8 chars, 2 lines |- |20_Characters_1_Line||20||1||0x00||n/a||n/a||n/a|| |- |40_Characters_1_Line||40||1||0x00||n/a||n/a||n/a|| |- |8_Characters_2_Lines||8||2||0x00||0x40||n/a||n/a|| |- |12_Characters_2_Lines||12||2||0x00||0x40||n/a||n/a|| |- |16_Characters_2_Lines||16||2||0x00||0x40||n/a||n/a|| |- |20_Characters_2_Lines||20||2||0x00||0x40||n/a||n/a|| |- |24_Characters_2_Lines||24||2||0x00||0x40||n/a||n/a|| |- |40_Characters_2_Lines||40||2||0x00||0x40||n/a||n/a|| |- |16_Characters_4_Lines||16||4||0x00||0x40||0x10||0x50|| |- |20_Characters_4_Lines||20||4||0x00||0x40||0x14||0x54||Note DDRAM addresses |- |20_Characters_4_Lines_KS0073||20||4||0x00||0x20||0x40||0x60||Note DDRAM addresses |- |27_Characters_4_Lines_2_EN||27||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |- |40_Characters_4_Lines_2_EN||40||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |} '''Note:''' The HD44780 module drivers supports '''alphanumeric character LCDs''' only. Ethersex also has limited support for some graphical displays. Have a look at the LC-Display configuration. == Configuration == ... │ │ Network ---> │ │ I/O ---> ... │ │ ADC / DAC ---> │ │ LCD Displays ---> ... │ │ [*] HD44780 module driver (Character-LCD) ---> │ │ [-] HR20-style LCD Display ... │ │ (16_Characters_2_Lines) LCD size/type │ │ (HD44780_Compat) LCD controller type │ │ (None) LCD charset conversion │ │ (I2C) Connection type │ │ (PCF8574) I2C Port Expander │ │ [*] Readback support │ │ [*] Backlight support │ │ [*] Backlight on at power-on │ │ [*] Invert Backlight switch '''Configuration options:''' [[File:Displaytech 404b charconv.jpg|thumb|400px|right|text top|Displaytech 404b 4x40 LCD with output of ECMD lcd print charset 0 128 and selected HD44780_Compat charset conversion]] ;LCD size/type : Select one of the defined display sizes and address configurations shown in the table [[#Supported LC-Displays]] above. : : Although it is technically possible to connect more than one display, the HD44780 module supports only one LC-Display at a time. ;LCD controller type : Select LCD controller circuit: : :* HD44780_Compat - most controllers are compatible to Hitachis HD44780 :* KS0066U - Samsungs KS0066U requires a different init routine : : Almost all controllers for alphanumeric character LCDs are more or less HD44780-compatible at least at the feature- and function-level required by e6. : : If in doubt, choose HD44780_Compat. ;LCD charset conversion : Select charset conversion used while writing to the lcd: : :* None - use no charset conversion at all (safes program mem) :* HD44780_Compat - map characters from ISO8859-1 to the original HD44780 charset : : Almost all controllers use their own non-ISO-compatible charset, varying between manufacturers, rom versions, etc. that provides characters from western languages as well as japanese, chinese and graphical glyphs. : : Charset conversion might become useful if you have to display messages and texts from external resources that uses standard encodings for their charset like ISO8859-1. : : Note: Charset conversion uses a lookup table and requires about 272 byte program memory (flash rom). ;Connection type : Select the connection type for the LCD: : :* Direct - direct connection using avr io-pins :* I2C - uses sub-selection of I2C port expander :* SER_LCD(74hct164) - serial connection using HCT164 shift register :* 2WIRE(74hct4094) - serial connection using HCT4094 shift register : : See section [[#Pinning]] below for further explanations. : ;I2C Port Expander : Select I2C Port Expander to use: : :* PCF8574 - use PCF8574x as I2C port expander :* MCP23017 - use MCP23017 as I2C port expander : : Note: automatically enables I2C_MASTER_SUPPORT and I2C_PCF8574X_SUPPORT resp. I2C_MCP23017_SUPPORT when selected. : : Note: Selection is only valid when '''I2C''' was selected under '''Connection type'''. : See section [[#Pinning]] below for further explanations. ;Readback support : Enable support for bi-directional lcd bus to read LCDs busy flag. Supported by direct and I2C connection only. : : You '''definitly should use a readback capable hardware and enable this feature''', saves lots of delays. ;Backlight support : Backlight support for LCDs based on the HD44780 controller. : : Enable backlight on/off control via API and ECMD. ;Backlight on at power-on : Switch on backlight at power-on/reset. ;Invert Backlight switch : Invert backlight logic for low active backlight circuits e.g. found on Pollin AVR NET-IO Add-on. == Pinning == HD44780-based alphanumeric LCDs are connected via 8 databus-lines (D0..D7) and 3 control-lines (RS, EN, R/W). Displays with more than 80 characters usually utilize a second controller and require two EN-signals EN1 and EN2. Another signal BL is needed if backlight control ist required. To save some i/o-pins the HD44780 controller also supports a 4 Bit mode, using only D4..D7. The HD44780 module supports this 4 Bit mode only. Note that in general the signals D0..D3 should not be left open, use a pull-down or tie them to ground. Most displays use 14, 16 or 18-pin connectors with common pinouts but there are sometimes subtle differences. Beside the control- and data-signals all displays require a supply voltage Vdd, usually +5 V, for the logic circuits and another voltage Vo for the display itself. The later is usually derived using a trimming potentiometer that allows for contrast adjustment. Some displays require a ''negative'' voltage for the display. Please refer to the datasheet of '''your''' display! Wrong connections may lead to a permanent damage. The HD44780 module supports four different types of connection for the LCD: Direct, I2C, Serial and 2-Wire. === Direct === The LCD signals RS, RW, EN (resp. EN1 and EN2), D4..D7 and BL are directly connected to AVR port pins. The driver makes no assumptions about the pin mapping, arbitrary pins from different ports may be used to drive the LCD signals. This connection type is Readback-capable. The following example maps the LCD pins to AVR port pins found on the 25 pin Sub-D connector of the Pollin AVR Net-IO board: <code> dnl Direct connection example dnl map LCD pins to Pollin AVR Net-IO 25 pin extension port ifdef(`conf_HD44780', ` pin(HD44780_RS, PC4) pin(HD44780_RW, PC3) pin(HD44780_EN1, PC2) dnl pin(HD44780_EN2, PC5) pin(HD44780_D4, PA0) pin(HD44780_D5, PA1) pin(HD44780_D6, PA2) pin(HD44780_D7, PA3) ') ifdef(`conf_HD44780_BACKLIGHT', ` pin(HD44780_BL, PC6, OUTPUT) ') </code> === I2C === The I2C connection type supports either the 8 Bit PCF8574x, as it is found on the Pollin AVR Net-IO Add-On board, or the 16 Bit MCP23017 I2C Port Expander. LCDs up to 80 characters and only one HD44780 controller may be connected to a PCF8574x including the backlight control pin. LCDs with more than 80 characters require a second enable pin. The address of the port expander and the pinning for the LCD has to be specified for your hardware using the macros shown below. The macro HD44780_PCF8574x_MAPPING defines the pinning for displays with only one enable signal and backlight control, the macro HD44780_PCF8574x_MULTI_MAPPING for displays with two enable signals. Note that backlight control is not supported when using the HD44780_PCF8574x_MULTI_MAPPING macro. The pinning shown in the examples below matches the pinning found on the Pollin AVR Net-IO Add-On board. Remember that you have to replace the inverting backlight control circuitry with a direct connection to connect displays with two enable signals to this board. The macros HD44780_MCP23017_MAPPING and HD44780_MCP23017_MULTI_MAPPING are used to map the LCD pins to one port of the MCP23017. Note that you have to specify either port A or B as shown below, mapping using mixed pins of both ports is not supported by the driver. The additional macro HD44780_MCP23017_MULTI_MAPPING_BL may be used to specify a backlight control signal on another MCP23017 port when the first port is occupied by a display with two enable signals. The driver exclusively controls the BL pin specified, the other 7 port pins may be used for different purposes. Connection type I2C is Readback-capable with both types of I2C Port Expanders. <code> dnl HD44780 LCD to I2C Port Expander mapping ifelse(value_HD44780_CONNECTION,`HD44780_I2CSUPPORT',`dnl ifelse(value_HD44780_I2C_PORTEXP,`HD44780_I2C_PCF8574', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_PCF8574x_MULTI_MAPPING(ADR, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_PCF8574x_MULTI_MAPPING(0x20, 4, 5, 6, 7, 0, 1, 2, 3)', `dnl dnl HD44780_PCF8574x_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_PCF8574x_MAPPING(0x20, 4, 5, 6, 0, 1, 2, 3, 7)')', value_HD44780_I2C_PORTEXP,`HD44780_I2C_MCP23017', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_MCP23017_MULTI_MAPPING(ADR, PORT, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_MCP23017_MULTI_MAPPING(0x24, B, 4, 5, 6, 7, 0, 1, 2, 3) HD44780_MCP23017_MULTI_MAPPING_BL(0x24, A, 7)', `dnl dnl HD44780_MCP23017_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_MCP23017_MAPPING(0x24, B, 4, 5, 6, 0, 1, 2, 3, 7)')' )dnl ')dnl </code> === Serial (using 74HCT164) === The LCD is connected using a 74HC(T)164 shift register. Refer to Ulrich Radig's [http://www.ulrichradig.de/home/index.php/software/avr-webserver-software avr-webserver] for an example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection requires three AVR port pins pin(HD44780_SER_D, PD4) pin(HD44780_SER_CLK, PD3) pin(HD44780_SER_EN1, PD2) </code> === 2-Wire (using 74HCT4094) === The LCD is connected using a 74HC(T)4094 shift register. Refer to [http://www.cczwei.de/atm18_downloads/071148-D%20CC2-AVR-board-2.pdf this] paper for an explanation and example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection using a 4094 shift register requires two AVR port pins ifdef(`HD44780_2WIRE', ` pin(HD44780_2WIRE_D, PC0) pin(HD44780_2WIRE_CLK, PC1) ') </code> 56150c07fe7bbd427ac9fdaa2cca490d57642887 1780 1779 2016-12-09T23:38:11Z Michaelb 718 wikitext text/x-wiki {{i18n|HD44780}} {{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->HD44780 module driver (Character-LCD) |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/lcd https://github.com/ethersex/ethersex/tree/master/hardware/lcd] }} ---- '''''THIS WIKI PAGE IS CURRENTLY WORK IN PROGRESS''''' ---- The '''HD44780 module''' provides support for common '''alphanumeric character LCDs''' using Hitachis HD44780 and compatible controllers. == Supported LC-Displays == The vast majority of all alphanumeric LC-Displays use Hitachis [https://en.wikipedia.org/wiki/Hitachi_HD44780_LCD_controller HD44780] dot matrix liquid crystal display (LCD) controller. The e6 HD44780 module supports displays of many different sizes utilizing the original HD44780 and compatible controllers. Alphanumeric LCDs are mainly distinguished by their size, the start-address of the per line Display Data-RAM (DDRAM) and the controller type. The original HD44780 controllers can drive up to 80 characters - most displays with more characters use two independent controllers. The following table lists the LC-displays supported by the e6 HD44780 module by size and per line DDRAM start-address: [[File:HD44780 Testbed.jpg|thumb|400px|right|text top|HD44780 module test]] {| class="wikitable" !colspan="1"|Menuconfig !colspan="2"|Size !colspan="4"|DDRAM Startaddress !rowspan="2"|Note: |- !LCD size/type||Characters||Lines||Line 1||Line 2||Line 3||Line 4 |- |8_Characters_1_Line||8||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line||16||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line_Mux16||16||1||0x00||n/a||n/a||n/a||organized as 8 chars, 2 lines |- |20_Characters_1_Line||20||1||0x00||n/a||n/a||n/a|| |- |40_Characters_1_Line||40||1||0x00||n/a||n/a||n/a|| |- |8_Characters_2_Lines||8||2||0x00||0x40||n/a||n/a|| |- |12_Characters_2_Lines||12||2||0x00||0x40||n/a||n/a|| |- |16_Characters_2_Lines||16||2||0x00||0x40||n/a||n/a|| |- |20_Characters_2_Lines||20||2||0x00||0x40||n/a||n/a|| |- |24_Characters_2_Lines||24||2||0x00||0x40||n/a||n/a|| |- |40_Characters_2_Lines||40||2||0x00||0x40||n/a||n/a|| |- |16_Characters_4_Lines||16||4||0x00||0x40||0x10||0x50|| |- |20_Characters_4_Lines||20||4||0x00||0x40||0x14||0x54||Note DDRAM addresses |- |20_Characters_4_Lines_KS0073||20||4||0x00||0x20||0x40||0x60||Note DDRAM addresses |- |27_Characters_4_Lines_2_EN||27||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |- |40_Characters_4_Lines_2_EN||40||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |} '''Note:''' The HD44780 module drivers supports '''alphanumeric character LCDs''' only. Ethersex also has limited support for some graphical displays. Have a look at the LC-Display configuration. == Configuration == ... │ │ Network ---> │ │ I/O ---> ... │ │ ADC / DAC ---> │ │ LCD Displays ---> ... │ │ [*] HD44780 module driver (Character-LCD) ---> │ │ [-] HR20-style LCD Display ... │ │ (16_Characters_2_Lines) LCD size/type │ │ (HD44780_Compat) LCD controller type │ │ (None) LCD charset conversion │ │ (I2C) Connection type │ │ (PCF8574) I2C Port Expander │ │ [*] Readback support │ │ [*] Backlight support │ │ [*] Backlight on at power-on │ │ [*] Invert Backlight switch '''Configuration options:''' [[File:Displaytech 404b charconv.jpg|thumb|400px|right|text top|Displaytech 404b 4x40 LCD with output of ECMD lcd print charset 0 128 and selected HD44780_Compat charset conversion]] ;LCD size/type : Select one of the defined display sizes and address configurations shown in the table [[#Supported LC-Displays]] above. : : Although it is technically possible to connect more than one display, the HD44780 module supports only one LC-Display at a time. ;LCD controller type : Select LCD controller circuit: : :* HD44780_Compat - most controllers are compatible to Hitachis HD44780 :* KS0066U - Samsungs KS0066U requires a different init routine : : Almost all controllers for alphanumeric character LCDs are more or less HD44780-compatible at least at the feature- and function-level required by e6. : : If in doubt, choose HD44780_Compat. ;LCD charset conversion : Select charset conversion used while writing to the lcd: : :* None - use no charset conversion at all (safes program mem) :* HD44780_Compat - map characters from ISO8859-1 to the original HD44780 charset : : Almost all controllers use their own non-ISO-compatible charset, varying between manufacturers, rom versions, etc. that provides characters from western languages as well as japanese, chinese and graphical glyphs. : : Charset conversion might become useful if you have to display messages and texts from external resources that uses standard encodings for their charset like ISO8859-1. : : Note: Charset conversion uses a lookup table and requires about 272 byte program memory (flash rom). ;Connection type : Select the connection type for the LCD: : :* Direct - direct connection using avr io-pins :* I2C - uses sub-selection of I2C port expander :* SER_LCD(74hct164) - serial connection using HCT164 shift register :* 2WIRE(74hct4094) - serial connection using HCT4094 shift register : : See section [[#Pinning]] below for further explanations. : ;I2C Port Expander : Select I2C Port Expander to use: : :* PCF8574 - use PCF8574x as I2C port expander :* MCP23017 - use MCP23017 as I2C port expander : : Note: automatically enables I2C_MASTER_SUPPORT and I2C_PCF8574X_SUPPORT resp. I2C_MCP23017_SUPPORT when selected. : : Note: Selection is only valid when '''I2C''' was selected under '''Connection type'''. : See section [[#Pinning]] below for further explanations. ;Readback support : Enable support for bi-directional lcd bus to read LCDs busy flag. Supported by direct and I2C connection only. : : You '''definitly should use a readback capable hardware and enable this feature''', saves lots of delays. ;Backlight support : Backlight support for LCDs based on the HD44780 controller. : : Enable backlight on/off control via API and ECMD. ;Backlight on at power-on : Switch on backlight at power-on/reset. ;Invert Backlight switch : Invert backlight logic for low active backlight circuits e.g. found on Pollin AVR NET-IO Add-on. == Pinning == HD44780-based alphanumeric LCDs are connected via 8 databus-lines (D0..D7) and 3 control-lines (RS, EN, R/W). Displays with more than 80 characters usually utilize a second controller and require two EN-signals EN1 and EN2. Another signal BL is needed if backlight control ist required. To save some i/o-pins the HD44780 controller also supports a 4 Bit mode, using only D4..D7. The HD44780 module supports this 4 Bit mode only. Note that in general the signals D0..D3 should not be left open, use a pull-down or tie them to ground. Most displays use 14, 16 or 18-pin connectors with common pinouts but there are sometimes subtle differences. Beside the control- and data-signals all displays require a supply voltage Vdd, usually +5 V, for the logic circuits and another voltage Vo for the display itself. The later is usually derived using a trimming potentiometer that allows for contrast adjustment. Some displays require a ''negative'' voltage for the display. Please refer to the datasheet of '''your''' display! Wrong connections may lead to a permanent damage. The HD44780 module supports four different types of connection for the LCD: Direct, I2C, Serial and 2-Wire. === Direct === The LCD signals RS, RW, EN (resp. EN1 and EN2), D4..D7 and BL are directly connected to AVR port pins. The driver makes no assumptions about the pin mapping, arbitrary pins from different ports may be used to drive the LCD signals. This connection type is Readback-capable. The following example maps the LCD pins to AVR port pins found on the 25 pin Sub-D connector of the Pollin AVR Net-IO board: <code> dnl Direct connection example dnl map LCD pins to Pollin AVR Net-IO 25 pin extension port ifdef(`conf_HD44780', ` pin(HD44780_RS, PC4) pin(HD44780_RW, PC3) pin(HD44780_EN1, PC2) dnl pin(HD44780_EN2, PC5) pin(HD44780_D4, PA0) pin(HD44780_D5, PA1) pin(HD44780_D6, PA2) pin(HD44780_D7, PA3) ') ifdef(`conf_HD44780_BACKLIGHT', ` pin(HD44780_BL, PC6, OUTPUT) ') </code> === I2C === The I2C connection type supports either the 8 Bit PCF8574x, as it is found on the Pollin AVR Net-IO Add-On board, or the 16 Bit MCP23017 I2C Port Expander. LCDs up to 80 characters and only one HD44780 controller may be connected to a PCF8574x including the backlight control pin. LCDs with more than 80 characters require a second enable pin. The address of the port expander and the pinning for the LCD has to be specified for your hardware using the macros shown below. The macro HD44780_PCF8574x_MAPPING defines the pinning for displays with only one enable signal and backlight control, the macro HD44780_PCF8574x_MULTI_MAPPING for displays with two enable signals. Note that backlight control is not supported when using the HD44780_PCF8574x_MULTI_MAPPING macro. The pinning shown in the examples below matches the pinning found on the Pollin AVR Net-IO Add-On board. Remember that you have to replace the inverting backlight control circuitry with a direct connection to connect displays with two enable signals to this board. The macros HD44780_MCP23017_MAPPING and HD44780_MCP23017_MULTI_MAPPING are used to map the LCD pins to one port of the MCP23017. Note that you have to specify either port A or B as shown below, mapping using mixed pins of both ports is not supported by the driver. The additional macro HD44780_MCP23017_MULTI_MAPPING_BL may be used to specify a backlight control signal on another MCP23017 port when the first port is occupied by a display with two enable signals. The driver exclusively controls the BL pin specified, the other 7 port pins may be used for different purposes. Connection type I2C is Readback-capable with both types of I2C Port Expanders. <code> dnl HD44780 LCD to I2C Port Expander mapping ifelse(value_HD44780_CONNECTION,`HD44780_I2CSUPPORT',`dnl ifelse(value_HD44780_I2C_PORTEXP,`HD44780_I2C_PCF8574', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_PCF8574x_MULTI_MAPPING(ADR, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_PCF8574x_MULTI_MAPPING(0x20, 4, 5, 6, 7, 0, 1, 2, 3)', `dnl dnl HD44780_PCF8574x_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_PCF8574x_MAPPING(0x20, 4, 5, 6, 0, 1, 2, 3, 7)')', value_HD44780_I2C_PORTEXP,`HD44780_I2C_MCP23017', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_MCP23017_MULTI_MAPPING(ADR, PORT, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_MCP23017_MULTI_MAPPING(0x24, B, 4, 5, 6, 7, 0, 1, 2, 3) HD44780_MCP23017_MULTI_MAPPING_BL(0x24, A, 7)', `dnl dnl HD44780_MCP23017_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_MCP23017_MAPPING(0x24, B, 4, 5, 6, 0, 1, 2, 3, 7)')' )dnl ')dnl </code> === Serial (using 74HCT164) === The LCD is connected using a 74HC(T)164 shift register. Refer to Ulrich Radig's [http://www.ulrichradig.de/home/index.php/software/avr-webserver-software avr-webserver] for an example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection requires three AVR port pins pin(HD44780_SER_D, PD4) pin(HD44780_SER_CLK, PD3) pin(HD44780_SER_EN1, PD2) </code> === 2-Wire (using 74HCT4094) === The LCD is connected using a 74HC(T)4094 shift register. Refer to [http://www.cczwei.de/atm18_downloads/071148-D%20CC2-AVR-board-2.pdf this] paper for an explanation and example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection using a 4094 shift register requires two AVR port pins ifdef(`HD44780_2WIRE', ` pin(HD44780_2WIRE_D, PC0) pin(HD44780_2WIRE_CLK, PC1) ') </code> == See also == [https://en.wikipedia.org/wiki/Hitachi_HD44780_LCD_controller wikipedia:Hitachi_HD44780_LCD_controller] [https://www.mikrocontroller.net/articles/HD44780 mikrocontroller.net:HD44780] c26beeb93dfd4caa1c342de32a3fb9540d81ee60 1781 1780 2016-12-09T23:45:02Z Michaelb 718 /* See also */ wikitext text/x-wiki {{i18n|HD44780}} {{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->HD44780 module driver (Character-LCD) |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/lcd https://github.com/ethersex/ethersex/tree/master/hardware/lcd] }} ---- '''''THIS WIKI PAGE IS CURRENTLY WORK IN PROGRESS''''' ---- The '''HD44780 module''' provides support for common '''alphanumeric character LCDs''' using Hitachis HD44780 and compatible controllers. == Supported LC-Displays == The vast majority of all alphanumeric LC-Displays use Hitachis [https://en.wikipedia.org/wiki/Hitachi_HD44780_LCD_controller HD44780] dot matrix liquid crystal display (LCD) controller. The e6 HD44780 module supports displays of many different sizes utilizing the original HD44780 and compatible controllers. Alphanumeric LCDs are mainly distinguished by their size, the start-address of the per line Display Data-RAM (DDRAM) and the controller type. The original HD44780 controllers can drive up to 80 characters - most displays with more characters use two independent controllers. The following table lists the LC-displays supported by the e6 HD44780 module by size and per line DDRAM start-address: [[File:HD44780 Testbed.jpg|thumb|400px|right|text top|HD44780 module test]] {| class="wikitable" !colspan="1"|Menuconfig !colspan="2"|Size !colspan="4"|DDRAM Startaddress !rowspan="2"|Note: |- !LCD size/type||Characters||Lines||Line 1||Line 2||Line 3||Line 4 |- |8_Characters_1_Line||8||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line||16||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line_Mux16||16||1||0x00||n/a||n/a||n/a||organized as 8 chars, 2 lines |- |20_Characters_1_Line||20||1||0x00||n/a||n/a||n/a|| |- |40_Characters_1_Line||40||1||0x00||n/a||n/a||n/a|| |- |8_Characters_2_Lines||8||2||0x00||0x40||n/a||n/a|| |- |12_Characters_2_Lines||12||2||0x00||0x40||n/a||n/a|| |- |16_Characters_2_Lines||16||2||0x00||0x40||n/a||n/a|| |- |20_Characters_2_Lines||20||2||0x00||0x40||n/a||n/a|| |- |24_Characters_2_Lines||24||2||0x00||0x40||n/a||n/a|| |- |40_Characters_2_Lines||40||2||0x00||0x40||n/a||n/a|| |- |16_Characters_4_Lines||16||4||0x00||0x40||0x10||0x50|| |- |20_Characters_4_Lines||20||4||0x00||0x40||0x14||0x54||Note DDRAM addresses |- |20_Characters_4_Lines_KS0073||20||4||0x00||0x20||0x40||0x60||Note DDRAM addresses |- |27_Characters_4_Lines_2_EN||27||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |- |40_Characters_4_Lines_2_EN||40||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |} '''Note:''' The HD44780 module drivers supports '''alphanumeric character LCDs''' only. Ethersex also has limited support for some graphical displays. Have a look at the LC-Display configuration. == Configuration == ... │ │ Network ---> │ │ I/O ---> ... │ │ ADC / DAC ---> │ │ LCD Displays ---> ... │ │ [*] HD44780 module driver (Character-LCD) ---> │ │ [-] HR20-style LCD Display ... │ │ (16_Characters_2_Lines) LCD size/type │ │ (HD44780_Compat) LCD controller type │ │ (None) LCD charset conversion │ │ (I2C) Connection type │ │ (PCF8574) I2C Port Expander │ │ [*] Readback support │ │ [*] Backlight support │ │ [*] Backlight on at power-on │ │ [*] Invert Backlight switch '''Configuration options:''' [[File:Displaytech 404b charconv.jpg|thumb|400px|right|text top|Displaytech 404b 4x40 LCD with output of ECMD lcd print charset 0 128 and selected HD44780_Compat charset conversion]] ;LCD size/type : Select one of the defined display sizes and address configurations shown in the table [[#Supported LC-Displays]] above. : : Although it is technically possible to connect more than one display, the HD44780 module supports only one LC-Display at a time. ;LCD controller type : Select LCD controller circuit: : :* HD44780_Compat - most controllers are compatible to Hitachis HD44780 :* KS0066U - Samsungs KS0066U requires a different init routine : : Almost all controllers for alphanumeric character LCDs are more or less HD44780-compatible at least at the feature- and function-level required by e6. : : If in doubt, choose HD44780_Compat. ;LCD charset conversion : Select charset conversion used while writing to the lcd: : :* None - use no charset conversion at all (safes program mem) :* HD44780_Compat - map characters from ISO8859-1 to the original HD44780 charset : : Almost all controllers use their own non-ISO-compatible charset, varying between manufacturers, rom versions, etc. that provides characters from western languages as well as japanese, chinese and graphical glyphs. : : Charset conversion might become useful if you have to display messages and texts from external resources that uses standard encodings for their charset like ISO8859-1. : : Note: Charset conversion uses a lookup table and requires about 272 byte program memory (flash rom). ;Connection type : Select the connection type for the LCD: : :* Direct - direct connection using avr io-pins :* I2C - uses sub-selection of I2C port expander :* SER_LCD(74hct164) - serial connection using HCT164 shift register :* 2WIRE(74hct4094) - serial connection using HCT4094 shift register : : See section [[#Pinning]] below for further explanations. : ;I2C Port Expander : Select I2C Port Expander to use: : :* PCF8574 - use PCF8574x as I2C port expander :* MCP23017 - use MCP23017 as I2C port expander : : Note: automatically enables I2C_MASTER_SUPPORT and I2C_PCF8574X_SUPPORT resp. I2C_MCP23017_SUPPORT when selected. : : Note: Selection is only valid when '''I2C''' was selected under '''Connection type'''. : See section [[#Pinning]] below for further explanations. ;Readback support : Enable support for bi-directional lcd bus to read LCDs busy flag. Supported by direct and I2C connection only. : : You '''definitly should use a readback capable hardware and enable this feature''', saves lots of delays. ;Backlight support : Backlight support for LCDs based on the HD44780 controller. : : Enable backlight on/off control via API and ECMD. ;Backlight on at power-on : Switch on backlight at power-on/reset. ;Invert Backlight switch : Invert backlight logic for low active backlight circuits e.g. found on Pollin AVR NET-IO Add-on. == Pinning == HD44780-based alphanumeric LCDs are connected via 8 databus-lines (D0..D7) and 3 control-lines (RS, EN, R/W). Displays with more than 80 characters usually utilize a second controller and require two EN-signals EN1 and EN2. Another signal BL is needed if backlight control ist required. To save some i/o-pins the HD44780 controller also supports a 4 Bit mode, using only D4..D7. The HD44780 module supports this 4 Bit mode only. Note that in general the signals D0..D3 should not be left open, use a pull-down or tie them to ground. Most displays use 14, 16 or 18-pin connectors with common pinouts but there are sometimes subtle differences. Beside the control- and data-signals all displays require a supply voltage Vdd, usually +5 V, for the logic circuits and another voltage Vo for the display itself. The later is usually derived using a trimming potentiometer that allows for contrast adjustment. Some displays require a ''negative'' voltage for the display. Please refer to the datasheet of '''your''' display! Wrong connections may lead to a permanent damage. The HD44780 module supports four different types of connection for the LCD: Direct, I2C, Serial and 2-Wire. === Direct === The LCD signals RS, RW, EN (resp. EN1 and EN2), D4..D7 and BL are directly connected to AVR port pins. The driver makes no assumptions about the pin mapping, arbitrary pins from different ports may be used to drive the LCD signals. This connection type is Readback-capable. The following example maps the LCD pins to AVR port pins found on the 25 pin Sub-D connector of the Pollin AVR Net-IO board: <code> dnl Direct connection example dnl map LCD pins to Pollin AVR Net-IO 25 pin extension port ifdef(`conf_HD44780', ` pin(HD44780_RS, PC4) pin(HD44780_RW, PC3) pin(HD44780_EN1, PC2) dnl pin(HD44780_EN2, PC5) pin(HD44780_D4, PA0) pin(HD44780_D5, PA1) pin(HD44780_D6, PA2) pin(HD44780_D7, PA3) ') ifdef(`conf_HD44780_BACKLIGHT', ` pin(HD44780_BL, PC6, OUTPUT) ') </code> === I2C === The I2C connection type supports either the 8 Bit PCF8574x, as it is found on the Pollin AVR Net-IO Add-On board, or the 16 Bit MCP23017 I2C Port Expander. LCDs up to 80 characters and only one HD44780 controller may be connected to a PCF8574x including the backlight control pin. LCDs with more than 80 characters require a second enable pin. The address of the port expander and the pinning for the LCD has to be specified for your hardware using the macros shown below. The macro HD44780_PCF8574x_MAPPING defines the pinning for displays with only one enable signal and backlight control, the macro HD44780_PCF8574x_MULTI_MAPPING for displays with two enable signals. Note that backlight control is not supported when using the HD44780_PCF8574x_MULTI_MAPPING macro. The pinning shown in the examples below matches the pinning found on the Pollin AVR Net-IO Add-On board. Remember that you have to replace the inverting backlight control circuitry with a direct connection to connect displays with two enable signals to this board. The macros HD44780_MCP23017_MAPPING and HD44780_MCP23017_MULTI_MAPPING are used to map the LCD pins to one port of the MCP23017. Note that you have to specify either port A or B as shown below, mapping using mixed pins of both ports is not supported by the driver. The additional macro HD44780_MCP23017_MULTI_MAPPING_BL may be used to specify a backlight control signal on another MCP23017 port when the first port is occupied by a display with two enable signals. The driver exclusively controls the BL pin specified, the other 7 port pins may be used for different purposes. Connection type I2C is Readback-capable with both types of I2C Port Expanders. <code> dnl HD44780 LCD to I2C Port Expander mapping ifelse(value_HD44780_CONNECTION,`HD44780_I2CSUPPORT',`dnl ifelse(value_HD44780_I2C_PORTEXP,`HD44780_I2C_PCF8574', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_PCF8574x_MULTI_MAPPING(ADR, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_PCF8574x_MULTI_MAPPING(0x20, 4, 5, 6, 7, 0, 1, 2, 3)', `dnl dnl HD44780_PCF8574x_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_PCF8574x_MAPPING(0x20, 4, 5, 6, 0, 1, 2, 3, 7)')', value_HD44780_I2C_PORTEXP,`HD44780_I2C_MCP23017', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_MCP23017_MULTI_MAPPING(ADR, PORT, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_MCP23017_MULTI_MAPPING(0x24, B, 4, 5, 6, 7, 0, 1, 2, 3) HD44780_MCP23017_MULTI_MAPPING_BL(0x24, A, 7)', `dnl dnl HD44780_MCP23017_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_MCP23017_MAPPING(0x24, B, 4, 5, 6, 0, 1, 2, 3, 7)')' )dnl ')dnl </code> === Serial (using 74HCT164) === The LCD is connected using a 74HC(T)164 shift register. Refer to Ulrich Radig's [http://www.ulrichradig.de/home/index.php/software/avr-webserver-software avr-webserver] for an example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection requires three AVR port pins pin(HD44780_SER_D, PD4) pin(HD44780_SER_CLK, PD3) pin(HD44780_SER_EN1, PD2) </code> === 2-Wire (using 74HCT4094) === The LCD is connected using a 74HC(T)4094 shift register. Refer to [http://www.cczwei.de/atm18_downloads/071148-D%20CC2-AVR-board-2.pdf this] paper for an explanation and example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection using a 4094 shift register requires two AVR port pins ifdef(`HD44780_2WIRE', ` pin(HD44780_2WIRE_D, PC0) pin(HD44780_2WIRE_CLK, PC1) ') </code> == See also == * [https://www.sparkfun.com/datasheets/LCD/HD44780.pdf Original HD44780 Datasheet at sparkfun] * [https://en.wikipedia.org/wiki/Hitachi_HD44780_LCD_controller wikipedia:Hitachi_HD44780_LCD_controller] * [https://www.mikrocontroller.net/articles/HD44780 mikrocontroller.net:HD44780] 7a2863400e228ed8038ca4e7c882f2d30e542cba 1782 1781 2016-12-09T23:45:59Z Michaelb 718 /* See also */ wikitext text/x-wiki {{i18n|HD44780}} {{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->HD44780 module driver (Character-LCD) |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/lcd https://github.com/ethersex/ethersex/tree/master/hardware/lcd] }} ---- '''''THIS WIKI PAGE IS CURRENTLY WORK IN PROGRESS''''' ---- The '''HD44780 module''' provides support for common '''alphanumeric character LCDs''' using Hitachis HD44780 and compatible controllers. == Supported LC-Displays == The vast majority of all alphanumeric LC-Displays use Hitachis [https://en.wikipedia.org/wiki/Hitachi_HD44780_LCD_controller HD44780] dot matrix liquid crystal display (LCD) controller. The e6 HD44780 module supports displays of many different sizes utilizing the original HD44780 and compatible controllers. Alphanumeric LCDs are mainly distinguished by their size, the start-address of the per line Display Data-RAM (DDRAM) and the controller type. The original HD44780 controllers can drive up to 80 characters - most displays with more characters use two independent controllers. The following table lists the LC-displays supported by the e6 HD44780 module by size and per line DDRAM start-address: [[File:HD44780 Testbed.jpg|thumb|400px|right|text top|HD44780 module test]] {| class="wikitable" !colspan="1"|Menuconfig !colspan="2"|Size !colspan="4"|DDRAM Startaddress !rowspan="2"|Note: |- !LCD size/type||Characters||Lines||Line 1||Line 2||Line 3||Line 4 |- |8_Characters_1_Line||8||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line||16||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line_Mux16||16||1||0x00||n/a||n/a||n/a||organized as 8 chars, 2 lines |- |20_Characters_1_Line||20||1||0x00||n/a||n/a||n/a|| |- |40_Characters_1_Line||40||1||0x00||n/a||n/a||n/a|| |- |8_Characters_2_Lines||8||2||0x00||0x40||n/a||n/a|| |- |12_Characters_2_Lines||12||2||0x00||0x40||n/a||n/a|| |- |16_Characters_2_Lines||16||2||0x00||0x40||n/a||n/a|| |- |20_Characters_2_Lines||20||2||0x00||0x40||n/a||n/a|| |- |24_Characters_2_Lines||24||2||0x00||0x40||n/a||n/a|| |- |40_Characters_2_Lines||40||2||0x00||0x40||n/a||n/a|| |- |16_Characters_4_Lines||16||4||0x00||0x40||0x10||0x50|| |- |20_Characters_4_Lines||20||4||0x00||0x40||0x14||0x54||Note DDRAM addresses |- |20_Characters_4_Lines_KS0073||20||4||0x00||0x20||0x40||0x60||Note DDRAM addresses |- |27_Characters_4_Lines_2_EN||27||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |- |40_Characters_4_Lines_2_EN||40||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |} '''Note:''' The HD44780 module drivers supports '''alphanumeric character LCDs''' only. Ethersex also has limited support for some graphical displays. Have a look at the LC-Display configuration. == Configuration == ... │ │ Network ---> │ │ I/O ---> ... │ │ ADC / DAC ---> │ │ LCD Displays ---> ... │ │ [*] HD44780 module driver (Character-LCD) ---> │ │ [-] HR20-style LCD Display ... │ │ (16_Characters_2_Lines) LCD size/type │ │ (HD44780_Compat) LCD controller type │ │ (None) LCD charset conversion │ │ (I2C) Connection type │ │ (PCF8574) I2C Port Expander │ │ [*] Readback support │ │ [*] Backlight support │ │ [*] Backlight on at power-on │ │ [*] Invert Backlight switch '''Configuration options:''' [[File:Displaytech 404b charconv.jpg|thumb|400px|right|text top|Displaytech 404b 4x40 LCD with output of ECMD lcd print charset 0 128 and selected HD44780_Compat charset conversion]] ;LCD size/type : Select one of the defined display sizes and address configurations shown in the table [[#Supported LC-Displays]] above. : : Although it is technically possible to connect more than one display, the HD44780 module supports only one LC-Display at a time. ;LCD controller type : Select LCD controller circuit: : :* HD44780_Compat - most controllers are compatible to Hitachis HD44780 :* KS0066U - Samsungs KS0066U requires a different init routine : : Almost all controllers for alphanumeric character LCDs are more or less HD44780-compatible at least at the feature- and function-level required by e6. : : If in doubt, choose HD44780_Compat. ;LCD charset conversion : Select charset conversion used while writing to the lcd: : :* None - use no charset conversion at all (safes program mem) :* HD44780_Compat - map characters from ISO8859-1 to the original HD44780 charset : : Almost all controllers use their own non-ISO-compatible charset, varying between manufacturers, rom versions, etc. that provides characters from western languages as well as japanese, chinese and graphical glyphs. : : Charset conversion might become useful if you have to display messages and texts from external resources that uses standard encodings for their charset like ISO8859-1. : : Note: Charset conversion uses a lookup table and requires about 272 byte program memory (flash rom). ;Connection type : Select the connection type for the LCD: : :* Direct - direct connection using avr io-pins :* I2C - uses sub-selection of I2C port expander :* SER_LCD(74hct164) - serial connection using HCT164 shift register :* 2WIRE(74hct4094) - serial connection using HCT4094 shift register : : See section [[#Pinning]] below for further explanations. : ;I2C Port Expander : Select I2C Port Expander to use: : :* PCF8574 - use PCF8574x as I2C port expander :* MCP23017 - use MCP23017 as I2C port expander : : Note: automatically enables I2C_MASTER_SUPPORT and I2C_PCF8574X_SUPPORT resp. I2C_MCP23017_SUPPORT when selected. : : Note: Selection is only valid when '''I2C''' was selected under '''Connection type'''. : See section [[#Pinning]] below for further explanations. ;Readback support : Enable support for bi-directional lcd bus to read LCDs busy flag. Supported by direct and I2C connection only. : : You '''definitly should use a readback capable hardware and enable this feature''', saves lots of delays. ;Backlight support : Backlight support for LCDs based on the HD44780 controller. : : Enable backlight on/off control via API and ECMD. ;Backlight on at power-on : Switch on backlight at power-on/reset. ;Invert Backlight switch : Invert backlight logic for low active backlight circuits e.g. found on Pollin AVR NET-IO Add-on. == Pinning == HD44780-based alphanumeric LCDs are connected via 8 databus-lines (D0..D7) and 3 control-lines (RS, EN, R/W). Displays with more than 80 characters usually utilize a second controller and require two EN-signals EN1 and EN2. Another signal BL is needed if backlight control ist required. To save some i/o-pins the HD44780 controller also supports a 4 Bit mode, using only D4..D7. The HD44780 module supports this 4 Bit mode only. Note that in general the signals D0..D3 should not be left open, use a pull-down or tie them to ground. Most displays use 14, 16 or 18-pin connectors with common pinouts but there are sometimes subtle differences. Beside the control- and data-signals all displays require a supply voltage Vdd, usually +5 V, for the logic circuits and another voltage Vo for the display itself. The later is usually derived using a trimming potentiometer that allows for contrast adjustment. Some displays require a ''negative'' voltage for the display. Please refer to the datasheet of '''your''' display! Wrong connections may lead to a permanent damage. The HD44780 module supports four different types of connection for the LCD: Direct, I2C, Serial and 2-Wire. === Direct === The LCD signals RS, RW, EN (resp. EN1 and EN2), D4..D7 and BL are directly connected to AVR port pins. The driver makes no assumptions about the pin mapping, arbitrary pins from different ports may be used to drive the LCD signals. This connection type is Readback-capable. The following example maps the LCD pins to AVR port pins found on the 25 pin Sub-D connector of the Pollin AVR Net-IO board: <code> dnl Direct connection example dnl map LCD pins to Pollin AVR Net-IO 25 pin extension port ifdef(`conf_HD44780', ` pin(HD44780_RS, PC4) pin(HD44780_RW, PC3) pin(HD44780_EN1, PC2) dnl pin(HD44780_EN2, PC5) pin(HD44780_D4, PA0) pin(HD44780_D5, PA1) pin(HD44780_D6, PA2) pin(HD44780_D7, PA3) ') ifdef(`conf_HD44780_BACKLIGHT', ` pin(HD44780_BL, PC6, OUTPUT) ') </code> === I2C === The I2C connection type supports either the 8 Bit PCF8574x, as it is found on the Pollin AVR Net-IO Add-On board, or the 16 Bit MCP23017 I2C Port Expander. LCDs up to 80 characters and only one HD44780 controller may be connected to a PCF8574x including the backlight control pin. LCDs with more than 80 characters require a second enable pin. The address of the port expander and the pinning for the LCD has to be specified for your hardware using the macros shown below. The macro HD44780_PCF8574x_MAPPING defines the pinning for displays with only one enable signal and backlight control, the macro HD44780_PCF8574x_MULTI_MAPPING for displays with two enable signals. Note that backlight control is not supported when using the HD44780_PCF8574x_MULTI_MAPPING macro. The pinning shown in the examples below matches the pinning found on the Pollin AVR Net-IO Add-On board. Remember that you have to replace the inverting backlight control circuitry with a direct connection to connect displays with two enable signals to this board. The macros HD44780_MCP23017_MAPPING and HD44780_MCP23017_MULTI_MAPPING are used to map the LCD pins to one port of the MCP23017. Note that you have to specify either port A or B as shown below, mapping using mixed pins of both ports is not supported by the driver. The additional macro HD44780_MCP23017_MULTI_MAPPING_BL may be used to specify a backlight control signal on another MCP23017 port when the first port is occupied by a display with two enable signals. The driver exclusively controls the BL pin specified, the other 7 port pins may be used for different purposes. Connection type I2C is Readback-capable with both types of I2C Port Expanders. <code> dnl HD44780 LCD to I2C Port Expander mapping ifelse(value_HD44780_CONNECTION,`HD44780_I2CSUPPORT',`dnl ifelse(value_HD44780_I2C_PORTEXP,`HD44780_I2C_PCF8574', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_PCF8574x_MULTI_MAPPING(ADR, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_PCF8574x_MULTI_MAPPING(0x20, 4, 5, 6, 7, 0, 1, 2, 3)', `dnl dnl HD44780_PCF8574x_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_PCF8574x_MAPPING(0x20, 4, 5, 6, 0, 1, 2, 3, 7)')', value_HD44780_I2C_PORTEXP,`HD44780_I2C_MCP23017', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_MCP23017_MULTI_MAPPING(ADR, PORT, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_MCP23017_MULTI_MAPPING(0x24, B, 4, 5, 6, 7, 0, 1, 2, 3) HD44780_MCP23017_MULTI_MAPPING_BL(0x24, A, 7)', `dnl dnl HD44780_MCP23017_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_MCP23017_MAPPING(0x24, B, 4, 5, 6, 0, 1, 2, 3, 7)')' )dnl ')dnl </code> === Serial (using 74HCT164) === The LCD is connected using a 74HC(T)164 shift register. Refer to Ulrich Radig's [http://www.ulrichradig.de/home/index.php/software/avr-webserver-software avr-webserver] for an example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection requires three AVR port pins pin(HD44780_SER_D, PD4) pin(HD44780_SER_CLK, PD3) pin(HD44780_SER_EN1, PD2) </code> === 2-Wire (using 74HCT4094) === The LCD is connected using a 74HC(T)4094 shift register. Refer to [http://www.cczwei.de/atm18_downloads/071148-D%20CC2-AVR-board-2.pdf this] paper for an explanation and example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection using a 4094 shift register requires two AVR port pins ifdef(`HD44780_2WIRE', ` pin(HD44780_2WIRE_D, PC0) pin(HD44780_2WIRE_CLK, PC1) ') </code> == See also == * [https://www.sparkfun.com/datasheets/LCD/HD44780.pdf Original HD44780 Datasheet at sparkfun] * [https://en.wikipedia.org/wiki/Hitachi_HD44780_LCD_controller wikipedia:Hitachi_HD44780_LCD_controller] * [https://www.mikrocontroller.net/articles/HD44780 mikrocontroller.net:HD44780] 61cd11adb912281df350bcfc33091bc9a62ef1e1 1783 1782 2016-12-09T23:46:48Z Michaelb 718 /* Pinning */ wikitext text/x-wiki {{i18n|HD44780}} {{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->HD44780 module driver (Character-LCD) |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/lcd https://github.com/ethersex/ethersex/tree/master/hardware/lcd] }} ---- '''''THIS WIKI PAGE IS CURRENTLY WORK IN PROGRESS''''' ---- The '''HD44780 module''' provides support for common '''alphanumeric character LCDs''' using Hitachis HD44780 and compatible controllers. == Supported LC-Displays == The vast majority of all alphanumeric LC-Displays use Hitachis [https://en.wikipedia.org/wiki/Hitachi_HD44780_LCD_controller HD44780] dot matrix liquid crystal display (LCD) controller. The e6 HD44780 module supports displays of many different sizes utilizing the original HD44780 and compatible controllers. Alphanumeric LCDs are mainly distinguished by their size, the start-address of the per line Display Data-RAM (DDRAM) and the controller type. The original HD44780 controllers can drive up to 80 characters - most displays with more characters use two independent controllers. The following table lists the LC-displays supported by the e6 HD44780 module by size and per line DDRAM start-address: [[File:HD44780 Testbed.jpg|thumb|400px|right|text top|HD44780 module test]] {| class="wikitable" !colspan="1"|Menuconfig !colspan="2"|Size !colspan="4"|DDRAM Startaddress !rowspan="2"|Note: |- !LCD size/type||Characters||Lines||Line 1||Line 2||Line 3||Line 4 |- |8_Characters_1_Line||8||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line||16||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line_Mux16||16||1||0x00||n/a||n/a||n/a||organized as 8 chars, 2 lines |- |20_Characters_1_Line||20||1||0x00||n/a||n/a||n/a|| |- |40_Characters_1_Line||40||1||0x00||n/a||n/a||n/a|| |- |8_Characters_2_Lines||8||2||0x00||0x40||n/a||n/a|| |- |12_Characters_2_Lines||12||2||0x00||0x40||n/a||n/a|| |- |16_Characters_2_Lines||16||2||0x00||0x40||n/a||n/a|| |- |20_Characters_2_Lines||20||2||0x00||0x40||n/a||n/a|| |- |24_Characters_2_Lines||24||2||0x00||0x40||n/a||n/a|| |- |40_Characters_2_Lines||40||2||0x00||0x40||n/a||n/a|| |- |16_Characters_4_Lines||16||4||0x00||0x40||0x10||0x50|| |- |20_Characters_4_Lines||20||4||0x00||0x40||0x14||0x54||Note DDRAM addresses |- |20_Characters_4_Lines_KS0073||20||4||0x00||0x20||0x40||0x60||Note DDRAM addresses |- |27_Characters_4_Lines_2_EN||27||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |- |40_Characters_4_Lines_2_EN||40||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |} '''Note:''' The HD44780 module drivers supports '''alphanumeric character LCDs''' only. Ethersex also has limited support for some graphical displays. Have a look at the LC-Display configuration. == Configuration == ... │ │ Network ---> │ │ I/O ---> ... │ │ ADC / DAC ---> │ │ LCD Displays ---> ... │ │ [*] HD44780 module driver (Character-LCD) ---> │ │ [-] HR20-style LCD Display ... │ │ (16_Characters_2_Lines) LCD size/type │ │ (HD44780_Compat) LCD controller type │ │ (None) LCD charset conversion │ │ (I2C) Connection type │ │ (PCF8574) I2C Port Expander │ │ [*] Readback support │ │ [*] Backlight support │ │ [*] Backlight on at power-on │ │ [*] Invert Backlight switch '''Configuration options:''' [[File:Displaytech 404b charconv.jpg|thumb|400px|right|text top|Displaytech 404b 4x40 LCD with output of ECMD lcd print charset 0 128 and selected HD44780_Compat charset conversion]] ;LCD size/type : Select one of the defined display sizes and address configurations shown in the table [[#Supported LC-Displays]] above. : : Although it is technically possible to connect more than one display, the HD44780 module supports only one LC-Display at a time. ;LCD controller type : Select LCD controller circuit: : :* HD44780_Compat - most controllers are compatible to Hitachis HD44780 :* KS0066U - Samsungs KS0066U requires a different init routine : : Almost all controllers for alphanumeric character LCDs are more or less HD44780-compatible at least at the feature- and function-level required by e6. : : If in doubt, choose HD44780_Compat. ;LCD charset conversion : Select charset conversion used while writing to the lcd: : :* None - use no charset conversion at all (safes program mem) :* HD44780_Compat - map characters from ISO8859-1 to the original HD44780 charset : : Almost all controllers use their own non-ISO-compatible charset, varying between manufacturers, rom versions, etc. that provides characters from western languages as well as japanese, chinese and graphical glyphs. : : Charset conversion might become useful if you have to display messages and texts from external resources that uses standard encodings for their charset like ISO8859-1. : : Note: Charset conversion uses a lookup table and requires about 272 byte program memory (flash rom). ;Connection type : Select the connection type for the LCD: : :* Direct - direct connection using avr io-pins :* I2C - uses sub-selection of I2C port expander :* SER_LCD(74hct164) - serial connection using HCT164 shift register :* 2WIRE(74hct4094) - serial connection using HCT4094 shift register : : See section [[#Pinning]] below for further explanations. : ;I2C Port Expander : Select I2C Port Expander to use: : :* PCF8574 - use PCF8574x as I2C port expander :* MCP23017 - use MCP23017 as I2C port expander : : Note: automatically enables I2C_MASTER_SUPPORT and I2C_PCF8574X_SUPPORT resp. I2C_MCP23017_SUPPORT when selected. : : Note: Selection is only valid when '''I2C''' was selected under '''Connection type'''. : See section [[#Pinning]] below for further explanations. ;Readback support : Enable support for bi-directional lcd bus to read LCDs busy flag. Supported by direct and I2C connection only. : : You '''definitly should use a readback capable hardware and enable this feature''', saves lots of delays. ;Backlight support : Backlight support for LCDs based on the HD44780 controller. : : Enable backlight on/off control via API and ECMD. ;Backlight on at power-on : Switch on backlight at power-on/reset. ;Invert Backlight switch : Invert backlight logic for low active backlight circuits e.g. found on Pollin AVR NET-IO Add-on. == Pinning == HD44780-based alphanumeric LCDs are connected via 8 databus-lines (D0..D7) and 3 control-lines (RS, EN, R/W). Displays with more than 80 characters usually utilize a second controller and require two EN-signals EN1 and EN2. Another signal BL is needed if backlight control ist required. To save some i/o-pins the HD44780 controller also supports a 4 Bit mode, using only D4..D7. The HD44780 module supports this 4 Bit mode only. Note that in general the signals D0..D3 should not be left open, use a pull-down or tie them to ground. Most displays use 14, 16 or 18-pin connectors with common pinouts but there are sometimes subtle differences. Beside the control- and data-signals all displays require a supply voltage Vdd, usually +5 V, for the logic circuits and another voltage Vo for the display itself. The later is usually derived using a trimming potentiometer that allows for contrast adjustment. Some displays require a ''negative'' voltage for the display. Please refer to the datasheet of '''your''' display! Wrong connections may lead to a permanent damage. The HD44780 module supports four different types of connection for the LCD: '''Direct''', '''I2C''', '''Serial''' and '''2-Wire'''. === Direct === The LCD signals RS, RW, EN (resp. EN1 and EN2), D4..D7 and BL are directly connected to AVR port pins. The driver makes no assumptions about the pin mapping, arbitrary pins from different ports may be used to drive the LCD signals. This connection type is Readback-capable. The following example maps the LCD pins to AVR port pins found on the 25 pin Sub-D connector of the Pollin AVR Net-IO board: <code> dnl Direct connection example dnl map LCD pins to Pollin AVR Net-IO 25 pin extension port ifdef(`conf_HD44780', ` pin(HD44780_RS, PC4) pin(HD44780_RW, PC3) pin(HD44780_EN1, PC2) dnl pin(HD44780_EN2, PC5) pin(HD44780_D4, PA0) pin(HD44780_D5, PA1) pin(HD44780_D6, PA2) pin(HD44780_D7, PA3) ') ifdef(`conf_HD44780_BACKLIGHT', ` pin(HD44780_BL, PC6, OUTPUT) ') </code> === I2C === The I2C connection type supports either the 8 Bit PCF8574x, as it is found on the Pollin AVR Net-IO Add-On board, or the 16 Bit MCP23017 I2C Port Expander. LCDs up to 80 characters and only one HD44780 controller may be connected to a PCF8574x including the backlight control pin. LCDs with more than 80 characters require a second enable pin. The address of the port expander and the pinning for the LCD has to be specified for your hardware using the macros shown below. The macro HD44780_PCF8574x_MAPPING defines the pinning for displays with only one enable signal and backlight control, the macro HD44780_PCF8574x_MULTI_MAPPING for displays with two enable signals. Note that backlight control is not supported when using the HD44780_PCF8574x_MULTI_MAPPING macro. The pinning shown in the examples below matches the pinning found on the Pollin AVR Net-IO Add-On board. Remember that you have to replace the inverting backlight control circuitry with a direct connection to connect displays with two enable signals to this board. The macros HD44780_MCP23017_MAPPING and HD44780_MCP23017_MULTI_MAPPING are used to map the LCD pins to one port of the MCP23017. Note that you have to specify either port A or B as shown below, mapping using mixed pins of both ports is not supported by the driver. The additional macro HD44780_MCP23017_MULTI_MAPPING_BL may be used to specify a backlight control signal on another MCP23017 port when the first port is occupied by a display with two enable signals. The driver exclusively controls the BL pin specified, the other 7 port pins may be used for different purposes. Connection type I2C is Readback-capable with both types of I2C Port Expanders. <code> dnl HD44780 LCD to I2C Port Expander mapping ifelse(value_HD44780_CONNECTION,`HD44780_I2CSUPPORT',`dnl ifelse(value_HD44780_I2C_PORTEXP,`HD44780_I2C_PCF8574', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_PCF8574x_MULTI_MAPPING(ADR, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_PCF8574x_MULTI_MAPPING(0x20, 4, 5, 6, 7, 0, 1, 2, 3)', `dnl dnl HD44780_PCF8574x_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_PCF8574x_MAPPING(0x20, 4, 5, 6, 0, 1, 2, 3, 7)')', value_HD44780_I2C_PORTEXP,`HD44780_I2C_MCP23017', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_MCP23017_MULTI_MAPPING(ADR, PORT, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_MCP23017_MULTI_MAPPING(0x24, B, 4, 5, 6, 7, 0, 1, 2, 3) HD44780_MCP23017_MULTI_MAPPING_BL(0x24, A, 7)', `dnl dnl HD44780_MCP23017_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_MCP23017_MAPPING(0x24, B, 4, 5, 6, 0, 1, 2, 3, 7)')' )dnl ')dnl </code> === Serial (using 74HCT164) === The LCD is connected using a 74HC(T)164 shift register. Refer to Ulrich Radig's [http://www.ulrichradig.de/home/index.php/software/avr-webserver-software avr-webserver] for an example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection requires three AVR port pins pin(HD44780_SER_D, PD4) pin(HD44780_SER_CLK, PD3) pin(HD44780_SER_EN1, PD2) </code> === 2-Wire (using 74HCT4094) === The LCD is connected using a 74HC(T)4094 shift register. Refer to [http://www.cczwei.de/atm18_downloads/071148-D%20CC2-AVR-board-2.pdf this] paper for an explanation and example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection using a 4094 shift register requires two AVR port pins ifdef(`HD44780_2WIRE', ` pin(HD44780_2WIRE_D, PC0) pin(HD44780_2WIRE_CLK, PC1) ') </code> == See also == * [https://www.sparkfun.com/datasheets/LCD/HD44780.pdf Original HD44780 Datasheet at sparkfun] * [https://en.wikipedia.org/wiki/Hitachi_HD44780_LCD_controller wikipedia:Hitachi_HD44780_LCD_controller] * [https://www.mikrocontroller.net/articles/HD44780 mikrocontroller.net:HD44780] 5f957bb8b68cde712bdb876e183ac7415cb9e7ea 1784 1783 2016-12-09T23:48:22Z Michaelb 718 wikitext text/x-wiki {{i18n|HD44780}} {{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->HD44780 module driver (Character-LCD) |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/lcd https://github.com/ethersex/ethersex/tree/master/hardware/lcd] }} ---- '''''THIS WIKI PAGE IS CURRENTLY WORK IN PROGRESS AND REFLECTS UPCOMING CHANGES''''' ---- The '''HD44780 module''' provides support for common '''alphanumeric character LCDs''' using Hitachis HD44780 and compatible controllers. == Supported LC-Displays == The vast majority of all alphanumeric LC-Displays use Hitachis [https://en.wikipedia.org/wiki/Hitachi_HD44780_LCD_controller HD44780] dot matrix liquid crystal display (LCD) controller. The e6 HD44780 module supports displays of many different sizes utilizing the original HD44780 and compatible controllers. Alphanumeric LCDs are mainly distinguished by their size, the start-address of the per line Display Data-RAM (DDRAM) and the controller type. The original HD44780 controllers can drive up to 80 characters - most displays with more characters use two independent controllers. The following table lists the LC-displays supported by the e6 HD44780 module by size and per line DDRAM start-address: [[File:HD44780 Testbed.jpg|thumb|400px|right|text top|HD44780 module test]] {| class="wikitable" !colspan="1"|Menuconfig !colspan="2"|Size !colspan="4"|DDRAM Startaddress !rowspan="2"|Note: |- !LCD size/type||Characters||Lines||Line 1||Line 2||Line 3||Line 4 |- |8_Characters_1_Line||8||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line||16||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line_Mux16||16||1||0x00||n/a||n/a||n/a||organized as 8 chars, 2 lines |- |20_Characters_1_Line||20||1||0x00||n/a||n/a||n/a|| |- |40_Characters_1_Line||40||1||0x00||n/a||n/a||n/a|| |- |8_Characters_2_Lines||8||2||0x00||0x40||n/a||n/a|| |- |12_Characters_2_Lines||12||2||0x00||0x40||n/a||n/a|| |- |16_Characters_2_Lines||16||2||0x00||0x40||n/a||n/a|| |- |20_Characters_2_Lines||20||2||0x00||0x40||n/a||n/a|| |- |24_Characters_2_Lines||24||2||0x00||0x40||n/a||n/a|| |- |40_Characters_2_Lines||40||2||0x00||0x40||n/a||n/a|| |- |16_Characters_4_Lines||16||4||0x00||0x40||0x10||0x50|| |- |20_Characters_4_Lines||20||4||0x00||0x40||0x14||0x54||Note DDRAM addresses |- |20_Characters_4_Lines_KS0073||20||4||0x00||0x20||0x40||0x60||Note DDRAM addresses |- |27_Characters_4_Lines_2_EN||27||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |- |40_Characters_4_Lines_2_EN||40||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |} '''Note:''' The HD44780 module drivers supports '''alphanumeric character LCDs''' only. Ethersex also has limited support for some graphical displays. Have a look at the LC-Display configuration. == Configuration == ... │ │ Network ---> │ │ I/O ---> ... │ │ ADC / DAC ---> │ │ LCD Displays ---> ... │ │ [*] HD44780 module driver (Character-LCD) ---> │ │ [-] HR20-style LCD Display ... │ │ (16_Characters_2_Lines) LCD size/type │ │ (HD44780_Compat) LCD controller type │ │ (None) LCD charset conversion │ │ (I2C) Connection type │ │ (PCF8574) I2C Port Expander │ │ [*] Readback support │ │ [*] Backlight support │ │ [*] Backlight on at power-on │ │ [*] Invert Backlight switch '''Configuration options:''' [[File:Displaytech 404b charconv.jpg|thumb|400px|right|text top|Displaytech 404b 4x40 LCD with output of ECMD lcd print charset 0 128 and selected HD44780_Compat charset conversion]] ;LCD size/type : Select one of the defined display sizes and address configurations shown in the table [[#Supported LC-Displays]] above. : : Although it is technically possible to connect more than one display, the HD44780 module supports only one LC-Display at a time. ;LCD controller type : Select LCD controller circuit: : :* HD44780_Compat - most controllers are compatible to Hitachis HD44780 :* KS0066U - Samsungs KS0066U requires a different init routine : : Almost all controllers for alphanumeric character LCDs are more or less HD44780-compatible at least at the feature- and function-level required by e6. : : If in doubt, choose HD44780_Compat. ;LCD charset conversion : Select charset conversion used while writing to the lcd: : :* None - use no charset conversion at all (safes program mem) :* HD44780_Compat - map characters from ISO8859-1 to the original HD44780 charset : : Almost all controllers use their own non-ISO-compatible charset, varying between manufacturers, rom versions, etc. that provides characters from western languages as well as japanese, chinese and graphical glyphs. : : Charset conversion might become useful if you have to display messages and texts from external resources that uses standard encodings for their charset like ISO8859-1. : : Note: Charset conversion uses a lookup table and requires about 272 byte program memory (flash rom). ;Connection type : Select the connection type for the LCD: : :* Direct - direct connection using avr io-pins :* I2C - uses sub-selection of I2C port expander :* SER_LCD(74hct164) - serial connection using HCT164 shift register :* 2WIRE(74hct4094) - serial connection using HCT4094 shift register : : See section [[#Pinning]] below for further explanations. : ;I2C Port Expander : Select I2C Port Expander to use: : :* PCF8574 - use PCF8574x as I2C port expander :* MCP23017 - use MCP23017 as I2C port expander : : Note: automatically enables I2C_MASTER_SUPPORT and I2C_PCF8574X_SUPPORT resp. I2C_MCP23017_SUPPORT when selected. : : Note: Selection is only valid when '''I2C''' was selected under '''Connection type'''. : See section [[#Pinning]] below for further explanations. ;Readback support : Enable support for bi-directional lcd bus to read LCDs busy flag. Supported by direct and I2C connection only. : : You '''definitly should use a readback capable hardware and enable this feature''', saves lots of delays. ;Backlight support : Backlight support for LCDs based on the HD44780 controller. : : Enable backlight on/off control via API and ECMD. ;Backlight on at power-on : Switch on backlight at power-on/reset. ;Invert Backlight switch : Invert backlight logic for low active backlight circuits e.g. found on Pollin AVR NET-IO Add-on. == Pinning == HD44780-based alphanumeric LCDs are connected via 8 databus-lines (D0..D7) and 3 control-lines (RS, EN, R/W). Displays with more than 80 characters usually utilize a second controller and require two EN-signals EN1 and EN2. Another signal BL is needed if backlight control ist required. To save some i/o-pins the HD44780 controller also supports a 4 Bit mode, using only D4..D7. The HD44780 module supports this 4 Bit mode only. Note that in general the signals D0..D3 should not be left open, use a pull-down or tie them to ground. Most displays use 14, 16 or 18-pin connectors with common pinouts but there are sometimes subtle differences. Beside the control- and data-signals all displays require a supply voltage Vdd, usually +5 V, for the logic circuits and another voltage Vo for the display itself. The later is usually derived using a trimming potentiometer that allows for contrast adjustment. Some displays require a ''negative'' voltage for the display. Please refer to the datasheet of '''your''' display! Wrong connections may lead to a permanent damage. The HD44780 module supports four different types of connection for the LCD: '''Direct''', '''I2C''', '''Serial''' and '''2-Wire'''. === Direct === The LCD signals RS, RW, EN (resp. EN1 and EN2), D4..D7 and BL are directly connected to AVR port pins. The driver makes no assumptions about the pin mapping, arbitrary pins from different ports may be used to drive the LCD signals. This connection type is Readback-capable. The following example maps the LCD pins to AVR port pins found on the 25 pin Sub-D connector of the Pollin AVR Net-IO board: <code> dnl Direct connection example dnl map LCD pins to Pollin AVR Net-IO 25 pin extension port ifdef(`conf_HD44780', ` pin(HD44780_RS, PC4) pin(HD44780_RW, PC3) pin(HD44780_EN1, PC2) dnl pin(HD44780_EN2, PC5) pin(HD44780_D4, PA0) pin(HD44780_D5, PA1) pin(HD44780_D6, PA2) pin(HD44780_D7, PA3) ') ifdef(`conf_HD44780_BACKLIGHT', ` pin(HD44780_BL, PC6, OUTPUT) ') </code> === I2C === The I2C connection type supports either the 8 Bit PCF8574x, as it is found on the Pollin AVR Net-IO Add-On board, or the 16 Bit MCP23017 I2C Port Expander. LCDs up to 80 characters and only one HD44780 controller may be connected to a PCF8574x including the backlight control pin. LCDs with more than 80 characters require a second enable pin. The address of the port expander and the pinning for the LCD has to be specified for your hardware using the macros shown below. The macro HD44780_PCF8574x_MAPPING defines the pinning for displays with only one enable signal and backlight control, the macro HD44780_PCF8574x_MULTI_MAPPING for displays with two enable signals. Note that backlight control is not supported when using the HD44780_PCF8574x_MULTI_MAPPING macro. The pinning shown in the examples below matches the pinning found on the Pollin AVR Net-IO Add-On board. Remember that you have to replace the inverting backlight control circuitry with a direct connection to connect displays with two enable signals to this board. The macros HD44780_MCP23017_MAPPING and HD44780_MCP23017_MULTI_MAPPING are used to map the LCD pins to one port of the MCP23017. Note that you have to specify either port A or B as shown below, mapping using mixed pins of both ports is not supported by the driver. The additional macro HD44780_MCP23017_MULTI_MAPPING_BL may be used to specify a backlight control signal on another MCP23017 port when the first port is occupied by a display with two enable signals. The driver exclusively controls the BL pin specified, the other 7 port pins may be used for different purposes. Connection type I2C is Readback-capable with both types of I2C Port Expanders. <code> dnl HD44780 LCD to I2C Port Expander mapping ifelse(value_HD44780_CONNECTION,`HD44780_I2CSUPPORT',`dnl ifelse(value_HD44780_I2C_PORTEXP,`HD44780_I2C_PCF8574', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_PCF8574x_MULTI_MAPPING(ADR, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_PCF8574x_MULTI_MAPPING(0x20, 4, 5, 6, 7, 0, 1, 2, 3)', `dnl dnl HD44780_PCF8574x_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_PCF8574x_MAPPING(0x20, 4, 5, 6, 0, 1, 2, 3, 7)')', value_HD44780_I2C_PORTEXP,`HD44780_I2C_MCP23017', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_MCP23017_MULTI_MAPPING(ADR, PORT, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_MCP23017_MULTI_MAPPING(0x24, B, 4, 5, 6, 7, 0, 1, 2, 3) HD44780_MCP23017_MULTI_MAPPING_BL(0x24, A, 7)', `dnl dnl HD44780_MCP23017_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_MCP23017_MAPPING(0x24, B, 4, 5, 6, 0, 1, 2, 3, 7)')' )dnl ')dnl </code> === Serial (using 74HCT164) === The LCD is connected using a 74HC(T)164 shift register. Refer to Ulrich Radig's [http://www.ulrichradig.de/home/index.php/software/avr-webserver-software avr-webserver] for an example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection requires three AVR port pins pin(HD44780_SER_D, PD4) pin(HD44780_SER_CLK, PD3) pin(HD44780_SER_EN1, PD2) </code> === 2-Wire (using 74HCT4094) === The LCD is connected using a 74HC(T)4094 shift register. Refer to [http://www.cczwei.de/atm18_downloads/071148-D%20CC2-AVR-board-2.pdf this] paper for an explanation and example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection using a 4094 shift register requires two AVR port pins ifdef(`HD44780_2WIRE', ` pin(HD44780_2WIRE_D, PC0) pin(HD44780_2WIRE_CLK, PC1) ') </code> == See also == * [https://www.sparkfun.com/datasheets/LCD/HD44780.pdf Original HD44780 Datasheet at sparkfun] * [https://en.wikipedia.org/wiki/Hitachi_HD44780_LCD_controller wikipedia:Hitachi_HD44780_LCD_controller] * [https://www.mikrocontroller.net/articles/HD44780 mikrocontroller.net:HD44780] ce123d2f191adb99472766620a300b22bf04eee9 1785 1784 2016-12-09T23:51:15Z Michaelb 718 /* I2C */ wikitext text/x-wiki {{i18n|HD44780}} {{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->HD44780 module driver (Character-LCD) |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/lcd https://github.com/ethersex/ethersex/tree/master/hardware/lcd] }} ---- '''''THIS WIKI PAGE IS CURRENTLY WORK IN PROGRESS AND REFLECTS UPCOMING CHANGES''''' ---- The '''HD44780 module''' provides support for common '''alphanumeric character LCDs''' using Hitachis HD44780 and compatible controllers. == Supported LC-Displays == The vast majority of all alphanumeric LC-Displays use Hitachis [https://en.wikipedia.org/wiki/Hitachi_HD44780_LCD_controller HD44780] dot matrix liquid crystal display (LCD) controller. The e6 HD44780 module supports displays of many different sizes utilizing the original HD44780 and compatible controllers. Alphanumeric LCDs are mainly distinguished by their size, the start-address of the per line Display Data-RAM (DDRAM) and the controller type. The original HD44780 controllers can drive up to 80 characters - most displays with more characters use two independent controllers. The following table lists the LC-displays supported by the e6 HD44780 module by size and per line DDRAM start-address: [[File:HD44780 Testbed.jpg|thumb|400px|right|text top|HD44780 module test]] {| class="wikitable" !colspan="1"|Menuconfig !colspan="2"|Size !colspan="4"|DDRAM Startaddress !rowspan="2"|Note: |- !LCD size/type||Characters||Lines||Line 1||Line 2||Line 3||Line 4 |- |8_Characters_1_Line||8||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line||16||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line_Mux16||16||1||0x00||n/a||n/a||n/a||organized as 8 chars, 2 lines |- |20_Characters_1_Line||20||1||0x00||n/a||n/a||n/a|| |- |40_Characters_1_Line||40||1||0x00||n/a||n/a||n/a|| |- |8_Characters_2_Lines||8||2||0x00||0x40||n/a||n/a|| |- |12_Characters_2_Lines||12||2||0x00||0x40||n/a||n/a|| |- |16_Characters_2_Lines||16||2||0x00||0x40||n/a||n/a|| |- |20_Characters_2_Lines||20||2||0x00||0x40||n/a||n/a|| |- |24_Characters_2_Lines||24||2||0x00||0x40||n/a||n/a|| |- |40_Characters_2_Lines||40||2||0x00||0x40||n/a||n/a|| |- |16_Characters_4_Lines||16||4||0x00||0x40||0x10||0x50|| |- |20_Characters_4_Lines||20||4||0x00||0x40||0x14||0x54||Note DDRAM addresses |- |20_Characters_4_Lines_KS0073||20||4||0x00||0x20||0x40||0x60||Note DDRAM addresses |- |27_Characters_4_Lines_2_EN||27||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |- |40_Characters_4_Lines_2_EN||40||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |} '''Note:''' The HD44780 module drivers supports '''alphanumeric character LCDs''' only. Ethersex also has limited support for some graphical displays. Have a look at the LC-Display configuration. == Configuration == ... │ │ Network ---> │ │ I/O ---> ... │ │ ADC / DAC ---> │ │ LCD Displays ---> ... │ │ [*] HD44780 module driver (Character-LCD) ---> │ │ [-] HR20-style LCD Display ... │ │ (16_Characters_2_Lines) LCD size/type │ │ (HD44780_Compat) LCD controller type │ │ (None) LCD charset conversion │ │ (I2C) Connection type │ │ (PCF8574) I2C Port Expander │ │ [*] Readback support │ │ [*] Backlight support │ │ [*] Backlight on at power-on │ │ [*] Invert Backlight switch '''Configuration options:''' [[File:Displaytech 404b charconv.jpg|thumb|400px|right|text top|Displaytech 404b 4x40 LCD with output of ECMD lcd print charset 0 128 and selected HD44780_Compat charset conversion]] ;LCD size/type : Select one of the defined display sizes and address configurations shown in the table [[#Supported LC-Displays]] above. : : Although it is technically possible to connect more than one display, the HD44780 module supports only one LC-Display at a time. ;LCD controller type : Select LCD controller circuit: : :* HD44780_Compat - most controllers are compatible to Hitachis HD44780 :* KS0066U - Samsungs KS0066U requires a different init routine : : Almost all controllers for alphanumeric character LCDs are more or less HD44780-compatible at least at the feature- and function-level required by e6. : : If in doubt, choose HD44780_Compat. ;LCD charset conversion : Select charset conversion used while writing to the lcd: : :* None - use no charset conversion at all (safes program mem) :* HD44780_Compat - map characters from ISO8859-1 to the original HD44780 charset : : Almost all controllers use their own non-ISO-compatible charset, varying between manufacturers, rom versions, etc. that provides characters from western languages as well as japanese, chinese and graphical glyphs. : : Charset conversion might become useful if you have to display messages and texts from external resources that uses standard encodings for their charset like ISO8859-1. : : Note: Charset conversion uses a lookup table and requires about 272 byte program memory (flash rom). ;Connection type : Select the connection type for the LCD: : :* Direct - direct connection using avr io-pins :* I2C - uses sub-selection of I2C port expander :* SER_LCD(74hct164) - serial connection using HCT164 shift register :* 2WIRE(74hct4094) - serial connection using HCT4094 shift register : : See section [[#Pinning]] below for further explanations. : ;I2C Port Expander : Select I2C Port Expander to use: : :* PCF8574 - use PCF8574x as I2C port expander :* MCP23017 - use MCP23017 as I2C port expander : : Note: automatically enables I2C_MASTER_SUPPORT and I2C_PCF8574X_SUPPORT resp. I2C_MCP23017_SUPPORT when selected. : : Note: Selection is only valid when '''I2C''' was selected under '''Connection type'''. : See section [[#Pinning]] below for further explanations. ;Readback support : Enable support for bi-directional lcd bus to read LCDs busy flag. Supported by direct and I2C connection only. : : You '''definitly should use a readback capable hardware and enable this feature''', saves lots of delays. ;Backlight support : Backlight support for LCDs based on the HD44780 controller. : : Enable backlight on/off control via API and ECMD. ;Backlight on at power-on : Switch on backlight at power-on/reset. ;Invert Backlight switch : Invert backlight logic for low active backlight circuits e.g. found on Pollin AVR NET-IO Add-on. == Pinning == HD44780-based alphanumeric LCDs are connected via 8 databus-lines (D0..D7) and 3 control-lines (RS, EN, R/W). Displays with more than 80 characters usually utilize a second controller and require two EN-signals EN1 and EN2. Another signal BL is needed if backlight control ist required. To save some i/o-pins the HD44780 controller also supports a 4 Bit mode, using only D4..D7. The HD44780 module supports this 4 Bit mode only. Note that in general the signals D0..D3 should not be left open, use a pull-down or tie them to ground. Most displays use 14, 16 or 18-pin connectors with common pinouts but there are sometimes subtle differences. Beside the control- and data-signals all displays require a supply voltage Vdd, usually +5 V, for the logic circuits and another voltage Vo for the display itself. The later is usually derived using a trimming potentiometer that allows for contrast adjustment. Some displays require a ''negative'' voltage for the display. Please refer to the datasheet of '''your''' display! Wrong connections may lead to a permanent damage. The HD44780 module supports four different types of connection for the LCD: '''Direct''', '''I2C''', '''Serial''' and '''2-Wire'''. === Direct === The LCD signals RS, RW, EN (resp. EN1 and EN2), D4..D7 and BL are directly connected to AVR port pins. The driver makes no assumptions about the pin mapping, arbitrary pins from different ports may be used to drive the LCD signals. This connection type is Readback-capable. The following example maps the LCD pins to AVR port pins found on the 25 pin Sub-D connector of the Pollin AVR Net-IO board: <code> dnl Direct connection example dnl map LCD pins to Pollin AVR Net-IO 25 pin extension port ifdef(`conf_HD44780', ` pin(HD44780_RS, PC4) pin(HD44780_RW, PC3) pin(HD44780_EN1, PC2) dnl pin(HD44780_EN2, PC5) pin(HD44780_D4, PA0) pin(HD44780_D5, PA1) pin(HD44780_D6, PA2) pin(HD44780_D7, PA3) ') ifdef(`conf_HD44780_BACKLIGHT', ` pin(HD44780_BL, PC6, OUTPUT) ') </code> === I2C === The I2C connection type supports either the 8 Bit PCF8574x, as it is found on the Pollin AVR Net-IO Add-On board, or the 16 Bit MCP23017 I2C Port Expander. LCDs up to 80 characters and only one HD44780 controller may be connected to a PCF8574x including the backlight control pin. LCDs with more than 80 characters require a second enable pin. The address of the port expander and the pinning for the LCD has to be specified for your hardware using the macros shown below. The macro HD44780_PCF8574x_MAPPING defines the pinning for displays with only one enable signal and backlight control, the macro HD44780_PCF8574x_MULTI_MAPPING for displays with two enable signals. Note that backlight control is not supported when using the HD44780_PCF8574x_MULTI_MAPPING macro. The pinning shown in the examples below matches the pinning found on the Pollin AVR Net-IO Add-On board. Remember that you have to replace the inverting backlight control circuitry with a direct connection from the PCF8574x to the 16 pin header to connect displays with two enable signals to this board. The macros HD44780_MCP23017_MAPPING and HD44780_MCP23017_MULTI_MAPPING are used to map the LCD pins to one port of the MCP23017. Note that you have to specify either port A or B as shown below, mapping using mixed pins of both ports is not supported by the driver. The additional macro HD44780_MCP23017_MULTI_MAPPING_BL may be used to specify a backlight control signal on another MCP23017 port when the first port is occupied by a display with two enable signals. The driver exclusively controls the BL pin specified, the other 7 port pins may be used for different purposes. Connection type I2C is Readback-capable with both types of I2C Port Expanders. <code> dnl HD44780 LCD to I2C Port Expander mapping ifelse(value_HD44780_CONNECTION,`HD44780_I2CSUPPORT',`dnl ifelse(value_HD44780_I2C_PORTEXP,`HD44780_I2C_PCF8574', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_PCF8574x_MULTI_MAPPING(ADR, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_PCF8574x_MULTI_MAPPING(0x20, 4, 5, 6, 7, 0, 1, 2, 3)', `dnl dnl HD44780_PCF8574x_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_PCF8574x_MAPPING(0x20, 4, 5, 6, 0, 1, 2, 3, 7)')', value_HD44780_I2C_PORTEXP,`HD44780_I2C_MCP23017', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_MCP23017_MULTI_MAPPING(ADR, PORT, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_MCP23017_MULTI_MAPPING(0x24, B, 4, 5, 6, 7, 0, 1, 2, 3) HD44780_MCP23017_MULTI_MAPPING_BL(0x24, A, 7)', `dnl dnl HD44780_MCP23017_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_MCP23017_MAPPING(0x24, B, 4, 5, 6, 0, 1, 2, 3, 7)')' )dnl ')dnl </code> === Serial (using 74HCT164) === The LCD is connected using a 74HC(T)164 shift register. Refer to Ulrich Radig's [http://www.ulrichradig.de/home/index.php/software/avr-webserver-software avr-webserver] for an example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection requires three AVR port pins pin(HD44780_SER_D, PD4) pin(HD44780_SER_CLK, PD3) pin(HD44780_SER_EN1, PD2) </code> === 2-Wire (using 74HCT4094) === The LCD is connected using a 74HC(T)4094 shift register. Refer to [http://www.cczwei.de/atm18_downloads/071148-D%20CC2-AVR-board-2.pdf this] paper for an explanation and example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection using a 4094 shift register requires two AVR port pins ifdef(`HD44780_2WIRE', ` pin(HD44780_2WIRE_D, PC0) pin(HD44780_2WIRE_CLK, PC1) ') </code> == See also == * [https://www.sparkfun.com/datasheets/LCD/HD44780.pdf Original HD44780 Datasheet at sparkfun] * [https://en.wikipedia.org/wiki/Hitachi_HD44780_LCD_controller wikipedia:Hitachi_HD44780_LCD_controller] * [https://www.mikrocontroller.net/articles/HD44780 mikrocontroller.net:HD44780] a882a12ee9bae033120734621e75239869199de6 1786 1785 2016-12-09T23:53:48Z Michaelb 718 /* I2C */ wikitext text/x-wiki {{i18n|HD44780}} {{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->HD44780 module driver (Character-LCD) |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/lcd https://github.com/ethersex/ethersex/tree/master/hardware/lcd] }} ---- '''''THIS WIKI PAGE IS CURRENTLY WORK IN PROGRESS AND REFLECTS UPCOMING CHANGES''''' ---- The '''HD44780 module''' provides support for common '''alphanumeric character LCDs''' using Hitachis HD44780 and compatible controllers. == Supported LC-Displays == The vast majority of all alphanumeric LC-Displays use Hitachis [https://en.wikipedia.org/wiki/Hitachi_HD44780_LCD_controller HD44780] dot matrix liquid crystal display (LCD) controller. The e6 HD44780 module supports displays of many different sizes utilizing the original HD44780 and compatible controllers. Alphanumeric LCDs are mainly distinguished by their size, the start-address of the per line Display Data-RAM (DDRAM) and the controller type. The original HD44780 controllers can drive up to 80 characters - most displays with more characters use two independent controllers. The following table lists the LC-displays supported by the e6 HD44780 module by size and per line DDRAM start-address: [[File:HD44780 Testbed.jpg|thumb|400px|right|text top|HD44780 module test]] {| class="wikitable" !colspan="1"|Menuconfig !colspan="2"|Size !colspan="4"|DDRAM Startaddress !rowspan="2"|Note: |- !LCD size/type||Characters||Lines||Line 1||Line 2||Line 3||Line 4 |- |8_Characters_1_Line||8||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line||16||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line_Mux16||16||1||0x00||n/a||n/a||n/a||organized as 8 chars, 2 lines |- |20_Characters_1_Line||20||1||0x00||n/a||n/a||n/a|| |- |40_Characters_1_Line||40||1||0x00||n/a||n/a||n/a|| |- |8_Characters_2_Lines||8||2||0x00||0x40||n/a||n/a|| |- |12_Characters_2_Lines||12||2||0x00||0x40||n/a||n/a|| |- |16_Characters_2_Lines||16||2||0x00||0x40||n/a||n/a|| |- |20_Characters_2_Lines||20||2||0x00||0x40||n/a||n/a|| |- |24_Characters_2_Lines||24||2||0x00||0x40||n/a||n/a|| |- |40_Characters_2_Lines||40||2||0x00||0x40||n/a||n/a|| |- |16_Characters_4_Lines||16||4||0x00||0x40||0x10||0x50|| |- |20_Characters_4_Lines||20||4||0x00||0x40||0x14||0x54||Note DDRAM addresses |- |20_Characters_4_Lines_KS0073||20||4||0x00||0x20||0x40||0x60||Note DDRAM addresses |- |27_Characters_4_Lines_2_EN||27||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |- |40_Characters_4_Lines_2_EN||40||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |} '''Note:''' The HD44780 module drivers supports '''alphanumeric character LCDs''' only. Ethersex also has limited support for some graphical displays. Have a look at the LC-Display configuration. == Configuration == ... │ │ Network ---> │ │ I/O ---> ... │ │ ADC / DAC ---> │ │ LCD Displays ---> ... │ │ [*] HD44780 module driver (Character-LCD) ---> │ │ [-] HR20-style LCD Display ... │ │ (16_Characters_2_Lines) LCD size/type │ │ (HD44780_Compat) LCD controller type │ │ (None) LCD charset conversion │ │ (I2C) Connection type │ │ (PCF8574) I2C Port Expander │ │ [*] Readback support │ │ [*] Backlight support │ │ [*] Backlight on at power-on │ │ [*] Invert Backlight switch '''Configuration options:''' [[File:Displaytech 404b charconv.jpg|thumb|400px|right|text top|Displaytech 404b 4x40 LCD with output of ECMD lcd print charset 0 128 and selected HD44780_Compat charset conversion]] ;LCD size/type : Select one of the defined display sizes and address configurations shown in the table [[#Supported LC-Displays]] above. : : Although it is technically possible to connect more than one display, the HD44780 module supports only one LC-Display at a time. ;LCD controller type : Select LCD controller circuit: : :* HD44780_Compat - most controllers are compatible to Hitachis HD44780 :* KS0066U - Samsungs KS0066U requires a different init routine : : Almost all controllers for alphanumeric character LCDs are more or less HD44780-compatible at least at the feature- and function-level required by e6. : : If in doubt, choose HD44780_Compat. ;LCD charset conversion : Select charset conversion used while writing to the lcd: : :* None - use no charset conversion at all (safes program mem) :* HD44780_Compat - map characters from ISO8859-1 to the original HD44780 charset : : Almost all controllers use their own non-ISO-compatible charset, varying between manufacturers, rom versions, etc. that provides characters from western languages as well as japanese, chinese and graphical glyphs. : : Charset conversion might become useful if you have to display messages and texts from external resources that uses standard encodings for their charset like ISO8859-1. : : Note: Charset conversion uses a lookup table and requires about 272 byte program memory (flash rom). ;Connection type : Select the connection type for the LCD: : :* Direct - direct connection using avr io-pins :* I2C - uses sub-selection of I2C port expander :* SER_LCD(74hct164) - serial connection using HCT164 shift register :* 2WIRE(74hct4094) - serial connection using HCT4094 shift register : : See section [[#Pinning]] below for further explanations. : ;I2C Port Expander : Select I2C Port Expander to use: : :* PCF8574 - use PCF8574x as I2C port expander :* MCP23017 - use MCP23017 as I2C port expander : : Note: automatically enables I2C_MASTER_SUPPORT and I2C_PCF8574X_SUPPORT resp. I2C_MCP23017_SUPPORT when selected. : : Note: Selection is only valid when '''I2C''' was selected under '''Connection type'''. : See section [[#Pinning]] below for further explanations. ;Readback support : Enable support for bi-directional lcd bus to read LCDs busy flag. Supported by direct and I2C connection only. : : You '''definitly should use a readback capable hardware and enable this feature''', saves lots of delays. ;Backlight support : Backlight support for LCDs based on the HD44780 controller. : : Enable backlight on/off control via API and ECMD. ;Backlight on at power-on : Switch on backlight at power-on/reset. ;Invert Backlight switch : Invert backlight logic for low active backlight circuits e.g. found on Pollin AVR NET-IO Add-on. == Pinning == HD44780-based alphanumeric LCDs are connected via 8 databus-lines (D0..D7) and 3 control-lines (RS, EN, R/W). Displays with more than 80 characters usually utilize a second controller and require two EN-signals EN1 and EN2. Another signal BL is needed if backlight control ist required. To save some i/o-pins the HD44780 controller also supports a 4 Bit mode, using only D4..D7. The HD44780 module supports this 4 Bit mode only. Note that in general the signals D0..D3 should not be left open, use a pull-down or tie them to ground. Most displays use 14, 16 or 18-pin connectors with common pinouts but there are sometimes subtle differences. Beside the control- and data-signals all displays require a supply voltage Vdd, usually +5 V, for the logic circuits and another voltage Vo for the display itself. The later is usually derived using a trimming potentiometer that allows for contrast adjustment. Some displays require a ''negative'' voltage for the display. Please refer to the datasheet of '''your''' display! Wrong connections may lead to a permanent damage. The HD44780 module supports four different types of connection for the LCD: '''Direct''', '''I2C''', '''Serial''' and '''2-Wire'''. === Direct === The LCD signals RS, RW, EN (resp. EN1 and EN2), D4..D7 and BL are directly connected to AVR port pins. The driver makes no assumptions about the pin mapping, arbitrary pins from different ports may be used to drive the LCD signals. This connection type is Readback-capable. The following example maps the LCD pins to AVR port pins found on the 25 pin Sub-D connector of the Pollin AVR Net-IO board: <code> dnl Direct connection example dnl map LCD pins to Pollin AVR Net-IO 25 pin extension port ifdef(`conf_HD44780', ` pin(HD44780_RS, PC4) pin(HD44780_RW, PC3) pin(HD44780_EN1, PC2) dnl pin(HD44780_EN2, PC5) pin(HD44780_D4, PA0) pin(HD44780_D5, PA1) pin(HD44780_D6, PA2) pin(HD44780_D7, PA3) ') ifdef(`conf_HD44780_BACKLIGHT', ` pin(HD44780_BL, PC6, OUTPUT) ') </code> === I2C === The I2C connection type supports either the 8 Bit PCF8574x, as it is found on the Pollin AVR Net-IO Add-On board, or the 16 Bit MCP23017 I2C Port Expander. LCDs up to 80 characters and only one HD44780 controller may be connected to a PCF8574x including the backlight control pin. LCDs with more than 80 characters require a second enable pin connected to the PCF8574x instead of the backlight control pin. The address of the port expander and the pinning for the LCD has to be specified for your hardware using the macros shown below. The macro HD44780_PCF8574x_MAPPING defines the pinning for displays with only one enable signal and backlight control, the macro HD44780_PCF8574x_MULTI_MAPPING for displays with two enable signals. Note that backlight control is not supported when using the HD44780_PCF8574x_MULTI_MAPPING macro. The pinning shown in the examples below matches the pinning found on the Pollin AVR Net-IO Add-On board. Remember that you have to replace the inverting backlight control circuitry with a direct connection from the PCF8574x to the 16 pin header to connect displays with two enable signals to this board. The macros HD44780_MCP23017_MAPPING and HD44780_MCP23017_MULTI_MAPPING are used to map the LCD pins to one port of the MCP23017. Note that you have to specify either port A or B as shown below, mapping using mixed pins of both ports is not supported by the driver. The additional macro HD44780_MCP23017_MULTI_MAPPING_BL may be used to specify a backlight control signal on another MCP23017 port when the first port is occupied by a display with two enable signals. The driver exclusively controls the BL pin specified, the other 7 port pins may be used for different purposes. Connection type I2C is Readback-capable with both types of I2C Port Expanders. <code> dnl HD44780 LCD to I2C Port Expander mapping ifelse(value_HD44780_CONNECTION,`HD44780_I2CSUPPORT',`dnl ifelse(value_HD44780_I2C_PORTEXP,`HD44780_I2C_PCF8574', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_PCF8574x_MULTI_MAPPING(ADR, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_PCF8574x_MULTI_MAPPING(0x20, 4, 5, 6, 7, 0, 1, 2, 3)', `dnl dnl HD44780_PCF8574x_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_PCF8574x_MAPPING(0x20, 4, 5, 6, 0, 1, 2, 3, 7)')', value_HD44780_I2C_PORTEXP,`HD44780_I2C_MCP23017', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_MCP23017_MULTI_MAPPING(ADR, PORT, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_MCP23017_MULTI_MAPPING(0x24, B, 4, 5, 6, 7, 0, 1, 2, 3) HD44780_MCP23017_MULTI_MAPPING_BL(0x24, A, 7)', `dnl dnl HD44780_MCP23017_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_MCP23017_MAPPING(0x24, B, 4, 5, 6, 0, 1, 2, 3, 7)')' )dnl ')dnl </code> === Serial (using 74HCT164) === The LCD is connected using a 74HC(T)164 shift register. Refer to Ulrich Radig's [http://www.ulrichradig.de/home/index.php/software/avr-webserver-software avr-webserver] for an example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection requires three AVR port pins pin(HD44780_SER_D, PD4) pin(HD44780_SER_CLK, PD3) pin(HD44780_SER_EN1, PD2) </code> === 2-Wire (using 74HCT4094) === The LCD is connected using a 74HC(T)4094 shift register. Refer to [http://www.cczwei.de/atm18_downloads/071148-D%20CC2-AVR-board-2.pdf this] paper for an explanation and example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection using a 4094 shift register requires two AVR port pins ifdef(`HD44780_2WIRE', ` pin(HD44780_2WIRE_D, PC0) pin(HD44780_2WIRE_CLK, PC1) ') </code> == See also == * [https://www.sparkfun.com/datasheets/LCD/HD44780.pdf Original HD44780 Datasheet at sparkfun] * [https://en.wikipedia.org/wiki/Hitachi_HD44780_LCD_controller wikipedia:Hitachi_HD44780_LCD_controller] * [https://www.mikrocontroller.net/articles/HD44780 mikrocontroller.net:HD44780] 2792dda6eaff4b982a32984e31313f961ca6243c 1788 1786 2017-01-21T16:18:40Z Michaelb 718 wikitext text/x-wiki {{i18n|HD44780}} {{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->HD44780 module driver (Character-LCD) |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/lcd https://github.com/ethersex/ethersex/tree/master/hardware/lcd] }} The '''HD44780 module''' provides support for common '''alphanumeric character LCDs''' using Hitachis HD44780 and compatible controllers. == Supported LC-Displays == The vast majority of all alphanumeric LC-Displays use Hitachis [https://en.wikipedia.org/wiki/Hitachi_HD44780_LCD_controller HD44780] dot matrix liquid crystal display (LCD) controller. The e6 HD44780 module supports displays of many different sizes utilizing the original HD44780 and compatible controllers. Alphanumeric LCDs are mainly distinguished by their size, the start-address of the per line Display Data-RAM (DDRAM) and the controller type. The original HD44780 controllers can drive up to 80 characters - most displays with more characters use two independent controllers. The following table lists the LC-displays supported by the e6 HD44780 module by size and per line DDRAM start-address: [[File:HD44780 Testbed.jpg|thumb|400px|right|text top|HD44780 module test]] {| class="wikitable" !colspan="1"|Menuconfig !colspan="2"|Size !colspan="4"|DDRAM Startaddress !rowspan="2"|Note: |- !LCD size/type||Characters||Lines||Line 1||Line 2||Line 3||Line 4 |- |8_Characters_1_Line||8||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line||16||1||0x00||n/a||n/a||n/a|| |- |16_Characters_1_Line_Mux16||16||1||0x00||n/a||n/a||n/a||organized as 8 chars, 2 lines |- |20_Characters_1_Line||20||1||0x00||n/a||n/a||n/a|| |- |40_Characters_1_Line||40||1||0x00||n/a||n/a||n/a|| |- |8_Characters_2_Lines||8||2||0x00||0x40||n/a||n/a|| |- |12_Characters_2_Lines||12||2||0x00||0x40||n/a||n/a|| |- |16_Characters_2_Lines||16||2||0x00||0x40||n/a||n/a|| |- |20_Characters_2_Lines||20||2||0x00||0x40||n/a||n/a|| |- |24_Characters_2_Lines||24||2||0x00||0x40||n/a||n/a|| |- |40_Characters_2_Lines||40||2||0x00||0x40||n/a||n/a|| |- |16_Characters_4_Lines||16||4||0x00||0x40||0x10||0x50|| |- |20_Characters_4_Lines||20||4||0x00||0x40||0x14||0x54||Note DDRAM addresses |- |20_Characters_4_Lines_KS0073||20||4||0x00||0x20||0x40||0x60||Note DDRAM addresses |- |27_Characters_4_Lines_2_EN||27||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |- |40_Characters_4_Lines_2_EN||40||4||0x00||0x40||0x00||0x40||Two Enable-Pins/Controllers |} '''Note:''' The HD44780 module drivers supports '''alphanumeric character LCDs''' only. Ethersex also has limited support for some graphical displays. Have a look at the LC-Display configuration. == Configuration == ... │ │ Network ---> │ │ I/O ---> ... │ │ ADC / DAC ---> │ │ LCD Displays ---> ... │ │ [*] HD44780 module driver (Character-LCD) ---> │ │ [-] HR20-style LCD Display ... │ │ (16_Characters_2_Lines) LCD size/type │ │ (HD44780_Compat) LCD controller type │ │ (None) LCD charset conversion │ │ (I2C) Connection type │ │ (PCF8574) I2C Port Expander │ │ [*] Readback support │ │ [*] Backlight support │ │ [*] Backlight on at power-on │ │ [*] Invert Backlight switch '''Configuration options:''' [[File:Displaytech 404b charconv.jpg|thumb|400px|right|text top|Displaytech 404b 4x40 LCD with output of ECMD lcd print charset 0 128 and selected HD44780_Compat charset conversion]] ;LCD size/type : Select one of the defined display sizes and address configurations shown in the table [[#Supported LC-Displays]] above. : : Although it is technically possible to connect more than one display, the HD44780 module supports only one LC-Display at a time. ;LCD controller type : Select LCD controller circuit: : :* HD44780_Compat - most controllers are compatible to Hitachis HD44780 :* KS0066U - Samsungs KS0066U requires a different init routine : : Almost all controllers for alphanumeric character LCDs are more or less HD44780-compatible at least at the feature- and function-level required by e6. : : If in doubt, choose HD44780_Compat. ;LCD charset conversion : Select charset conversion used while writing to the lcd: : :* None - use no charset conversion at all (safes program mem) :* HD44780_Compat - map characters from ISO8859-1 to the original HD44780 charset : : Almost all controllers use their own non-ISO-compatible charset, varying between manufacturers, rom versions, etc. that provides characters from western languages as well as japanese, chinese and graphical glyphs. : : Charset conversion might become useful if you have to display messages and texts from external resources that uses standard encodings for their charset like ISO8859-1. : : Note: Charset conversion uses a lookup table and requires about 272 byte program memory (flash rom). ;Connection type : Select the connection type for the LCD: : :* Direct - direct connection using avr io-pins :* I2C - uses sub-selection of I2C port expander :* SER_LCD(74hct164) - serial connection using HCT164 shift register :* 2WIRE(74hct4094) - serial connection using HCT4094 shift register : : See section [[#Pinning]] below for further explanations. : ;I2C Port Expander : Select I2C Port Expander to use: : :* PCF8574 - use PCF8574x as I2C port expander :* MCP23017 - use MCP23017 as I2C port expander : : Note: automatically enables I2C_MASTER_SUPPORT and I2C_PCF8574X_SUPPORT resp. I2C_MCP23017_SUPPORT when selected. : : Note: Selection is only valid when '''I2C''' was selected under '''Connection type'''. : See section [[#Pinning]] below for further explanations. ;Readback support : Enable support for bi-directional lcd bus to read LCDs busy flag. Supported by direct and I2C connection only. : : You '''definitly should use a readback capable hardware and enable this feature''', saves lots of delays. ;Backlight support : Backlight support for LCDs based on the HD44780 controller. : : Enable backlight on/off control via API and ECMD. ;Backlight on at power-on : Switch on backlight at power-on/reset. ;Invert Backlight switch : Invert backlight logic for low active backlight circuits e.g. found on Pollin AVR NET-IO Add-on. == Pinning == HD44780-based alphanumeric LCDs are connected via 8 databus-lines (D0..D7) and 3 control-lines (RS, EN, R/W). Displays with more than 80 characters usually utilize a second controller and require two EN-signals EN1 and EN2. Another signal BL is needed if backlight control ist required. To save some i/o-pins the HD44780 controller also supports a 4 Bit mode, using only D4..D7. The HD44780 module supports this 4 Bit mode only. Note that in general the signals D0..D3 should not be left open, use a pull-down or tie them to ground. Most displays use 14, 16 or 18-pin connectors with common pinouts but there are sometimes subtle differences. Beside the control- and data-signals all displays require a supply voltage Vdd, usually +5 V, for the logic circuits and another voltage Vo for the display itself. The later is usually derived using a trimming potentiometer that allows for contrast adjustment. Some displays require a ''negative'' voltage for the display. Please refer to the datasheet of '''your''' display! Wrong connections may lead to a permanent damage. The HD44780 module supports four different types of connection for the LCD: '''Direct''', '''I2C''', '''Serial''' and '''2-Wire'''. === Direct === The LCD signals RS, RW, EN (resp. EN1 and EN2), D4..D7 and BL are directly connected to AVR port pins. The driver makes no assumptions about the pin mapping, arbitrary pins from different ports may be used to drive the LCD signals. This connection type is Readback-capable. The following example maps the LCD pins to AVR port pins found on the 25 pin Sub-D connector of the Pollin AVR Net-IO board: <code> dnl Direct connection example dnl map LCD pins to Pollin AVR Net-IO 25 pin extension port ifdef(`conf_HD44780', ` pin(HD44780_RS, PC4) pin(HD44780_RW, PC3) pin(HD44780_EN1, PC2) dnl pin(HD44780_EN2, PC5) pin(HD44780_D4, PA0) pin(HD44780_D5, PA1) pin(HD44780_D6, PA2) pin(HD44780_D7, PA3) ') ifdef(`conf_HD44780_BACKLIGHT', ` pin(HD44780_BL, PC6, OUTPUT) ') </code> === I2C === The I2C connection type supports either the 8 Bit PCF8574x, as it is found on the Pollin AVR Net-IO Add-On board, or the 16 Bit MCP23017 I2C Port Expander. LCDs up to 80 characters and only one HD44780 controller may be connected to a PCF8574x including the backlight control pin. LCDs with more than 80 characters require a second enable pin connected to the PCF8574x instead of the backlight control pin. The address of the port expander and the pinning for the LCD has to be specified for your hardware using the macros shown below. The macro HD44780_PCF8574x_MAPPING defines the pinning for displays with only one enable signal and backlight control, the macro HD44780_PCF8574x_MULTI_MAPPING for displays with two enable signals. Note that backlight control is not supported when using the HD44780_PCF8574x_MULTI_MAPPING macro. The pinning shown in the examples below matches the pinning found on the Pollin AVR Net-IO Add-On board. Remember that you have to replace the inverting backlight control circuitry with a direct connection from the PCF8574x to the 16 pin header to connect displays with two enable signals to this board. The macros HD44780_MCP23017_MAPPING and HD44780_MCP23017_MULTI_MAPPING are used to map the LCD pins to one port of the MCP23017. Note that you have to specify either port A or B as shown below, mapping using mixed pins of both ports is not supported by the driver. The additional macro HD44780_MCP23017_MULTI_MAPPING_BL may be used to specify a backlight control signal on another MCP23017 port when the first port is occupied by a display with two enable signals. The driver exclusively controls the BL pin specified, the other 7 port pins may be used for different purposes. Connection type I2C is Readback-capable with both types of I2C Port Expanders. <code> dnl HD44780 LCD to I2C Port Expander mapping ifelse(value_HD44780_CONNECTION,`HD44780_I2CSUPPORT',`dnl ifelse(value_HD44780_I2C_PORTEXP,`HD44780_I2C_PCF8574', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_PCF8574x_MULTI_MAPPING(ADR, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_PCF8574x_MULTI_MAPPING(0x20, 4, 5, 6, 7, 0, 1, 2, 3)', `dnl dnl HD44780_PCF8574x_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_PCF8574x_MAPPING(0x20, 4, 5, 6, 0, 1, 2, 3, 7)')', value_HD44780_I2C_PORTEXP,`HD44780_I2C_MCP23017', `ifdef(`conf_HD44780_MULTIEN', `dnl dnl HD44780_MCP23017_MULTI_MAPPING(ADR, PORT, RS, RW, EN1, EN2, DB4, DB5, DB6, DB7) HD44780_MCP23017_MULTI_MAPPING(0x24, B, 4, 5, 6, 7, 0, 1, 2, 3) HD44780_MCP23017_MULTI_MAPPING_BL(0x24, A, 7)', `dnl dnl HD44780_MCP23017_MAPPING(ADR, RS, RW, EN, DB4, DB5, DB6, DB7, BL) HD44780_MCP23017_MAPPING(0x24, B, 4, 5, 6, 0, 1, 2, 3, 7)')' )dnl ')dnl </code> === Serial (using 74HCT164) === The LCD is connected using a 74HC(T)164 shift register. Refer to Ulrich Radig's [http://www.ulrichradig.de/home/index.php/software/avr-webserver-software avr-webserver] for an example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection requires three AVR port pins pin(HD44780_SER_D, PD4) pin(HD44780_SER_CLK, PD3) pin(HD44780_SER_EN1, PD2) </code> === 2-Wire (using 74HCT4094) === The LCD is connected using a 74HC(T)4094 shift register. Refer to [http://www.cczwei.de/atm18_downloads/071148-D%20CC2-AVR-board-2.pdf this] paper for an explanation and example of this connection type. The connection is uni-directional, so no Readback. Don't use if speed is important, especially not for larger displays. <code> dnl serial connection using a 4094 shift register requires two AVR port pins ifdef(`HD44780_2WIRE', ` pin(HD44780_2WIRE_D, PC0) pin(HD44780_2WIRE_CLK, PC1) ') </code> == See also == * [https://www.sparkfun.com/datasheets/LCD/HD44780.pdf Original HD44780 Datasheet at sparkfun] * [https://en.wikipedia.org/wiki/Hitachi_HD44780_LCD_controller wikipedia:Hitachi_HD44780_LCD_controller] * [https://www.mikrocontroller.net/articles/HD44780 mikrocontroller.net:HD44780] 629e7a8b12d4618c7bd54c4736cf61c8920a0d21 6 559 1766 2016-12-09T20:46:31Z Michaelb 718 (C) 2016 by M.Brakemeier CC-BY-SA wikitext text/x-wiki (C) 2016 by M.Brakemeier CC-BY-SA 9c5eed71794fa63291ee4c48817e87f44d43ed4b 6 560 1768 2016-12-09T22:47:16Z Michaelb 718 Displaytech 404b showing ECMD lcd print charset 0 128 with activated charset conversion (C) 2016 by M.Brakemeier CC-BY-SA wikitext text/x-wiki Displaytech 404b showing ECMD lcd print charset 0 128 with activated charset conversion (C) 2016 by M.Brakemeier CC-BY-SA aff8da1839159b77cb42d552623c415af295fcf3 0 498 1787 1712 2016-12-17T13:36:46Z Djmaster 255 /* Bootloader bauen */ wikitext text/x-wiki {{i18n|Temperaturmesssystem}} [[File:Tempmess_pcb_01.jpg|thumb|250px|meine Testplatine, Layout stimmt bis auf Kleinigkeiten überein]] [[File:Tempmess_pcb_02.jpg|thumb|250px|Testplatine beim Programmieren mit avrdude via ISP]] =PROJEKT Temperaturmessung= ===Einleitung=== * ZIEL: Eine einfache Temperaturmessung mit dem [[Onewire_(Deutsch)#Anschluss_AVR-NET-IO | DS1820 im parasitären Modus]]. * ZIEL: Die Ausgabe einer Temperaturvariable via integrierten Webbrowser oder telnet. * ZIEL: Die Firmware muss via Netzwerk neu flashbar sein. * Abgeändertes vereinfachtes [http://www.lochraster.org/etherrape/ etherrape] Board. * Zwei Spannungsregler, ein atmega644p, ein enc28j60, und etwas 0805 Hühnerfutter. ===Schaltung=== Das Layout passt in folgendes Gehäuse. Vorher am besten nochmal genau nachmessen. ;)<br> Conrad Bestell-Nr.: [https://www.conrad.at/de/hutschienen-gehaeuse-90-x-360-x-58-polycarbonat-axxatronic-cnmb-2-kit-con-1-st-531441.html 531441] / Axxatronic CNMB-2-KIT-CON <div><ul> <li style="display: inline-block;"> [[File:Sch_tempmess.png|thumb|none|210px|Schaltung]] </li> <li style="display: inline-block;"> [[File:Pcb_tempmess.png|thumb|none|280px|Layout]] </li> </ul></div> * Erstellt mit Eagle Version 7.1.0 für Windows * [http://wiki.senseye.org/adir/tempmesssystem/tempmess_schematic_001.pdf PDF Schaltung] * [http://wiki.senseye.org/adir/tempmesssystem/tempmess_layout_001.pdf PDF Layout gespiegelt] * [http://wiki.senseye.org/adir/tempmesssystem/tempmess001.sch Eagle Schaltung] * [http://wiki.senseye.org/adir/tempmesssystem/tempmess001.brd Eagle Layout] ===Software=== Ethersex (Linux) - https://github.com/ethersex/ethersex Avrdude (Windows) - http://download.savannah.gnu.org/releases/avrdude/ (avrdude-6.1-mingw32.zip) tftpd (Windows) - http://tftpd32.jounin.net/tftpd32_download.html (v4.52 tftpd64 standard edition (zip)) ===Firmware/Bootloader=== Die ethersex Firmware selbst wird für zwei Sachen verwendet. Den <b>Bootloader</b> UND die <b>Firmware</b>. Der Bootloader wird sozusagen einmal in den ersten Bereich des Mikrocontrollers geschrieben und bleibt dort auch. Er wird später die Firmware via Netzwerk entgegennehmen und in den Controller schreiben. Somit befindet sich in den ersten 10% unser Bootloader und in den restlichen 90% der Code den wir wollen. Das zu Verstehen war für mich an Anfang der schwierigste Teil, ist aber dann doch sehr einfach. Ich kann somit ohne ISP-Programmer eine Firmware in den Controller schreiben. Hier grob noch die nächsten Schritte: * Als erstes ist der Bootloader zu konfigurieren, dann via ISP zu programmieren. * Der ISP-Programmer wegräumen. ;) * Als zweites ist die Firmware zu konfigurieren, dann holt sich der Bootloader unsere Firmware via Netzerk/tftpd. =BOOTLOADER= ===Bootloader bauen=== <div><ul> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess01.png|thumb|none|200px|Putty Bild 1]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess02.png|thumb|none|200px|Putty Bild 2]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess03.png|thumb|none|200px|Putty Bild 3]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess04.png|thumb|none|200px|Putty Bild 4]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess05.png|thumb|none|200px|Putty Bild 5]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess06.png|thumb|none|200px|Putty Bild 6]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess07.png|thumb|none|200px|Putty Bild 7]] </li> <li style="display: inline-block;"> [[File:Putty_bootl_tempmess08.png|thumb|none|200px|Putty Bild 8]] </li> </ul></div> Ab nun befinde ich mich auf einem <b>virtuellen Debian Rechner</b> wo ich die Firmware herunterlade und daraus den Bootloader erstelle.<br> <b>WICHTIG:</b> Die IP und MAC-Adresse müssen natürlich verändert werden. Die selbe IP und MAC-Adresse müssen in der Firmware später auch benutzt werden. <br> * Bei einem neuen Debian System müssen mit "apt-get" ein paar Sachen nachinstalliert werden. Hier zu finden [[Quick_Start_Guide/Preparation_(Deutsch)]] * So eine art DHCP wäre auch möglich, nennt sich [[BOOTP_(Deutsch) | BOOTP]]. Darauf gehe ich hier nicht ein. # cd /home/avr/ # mkdir ethersex_IP_60 // Mein "Arbeitsordner" # cd ethersex_IP_60/ // Ordner für das Board mit der IP 192.168.123.60 # git clone git://github.com/ethersex/ethersex.git // ethersex Firmware herunterladen ..... oder http://github.com/ethersex/ethersex.git Cloning into ethersex... remote: Counting objects: 37366, done. remote: Total 37366 (delta 0), reused 0 (delta 0), pack-reused 37366 Receiving objects: 100% (37366/37366), 11.27 MiB | 1.22 MiB/s, done. Resolving deltas: 100% (26538/26538), done. # cp -r ethersex bootloader // Ich kopiere den ethersex Ordner zu dem bootloader Ordner. 1:1 Kopie # cd bootloader/ // In den Bootloader Ordner wechseln # make menuconfig // Einstellungen für Bootloader im nächsten Schritt │ │ Load a Default Configuration ---> │ │ (*) Ethernet Bootloader │ │ General Setup ---> │ │ (ATmega644) Target MCU │ │ (20000000) MCU frequency │ │ [*] Build a bootloader │ │ [*] Teensy build │ │ Network ---> │ │ Hostname: "esex060" // Hostname ändern │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" // MAC ändern mit "Randomize MAC address" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" // Wenn IP nicht vorhanden BOOTP deaktivieren! │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ [ ] BOOTP (DHCP-like) support // BOOTP deaktivieren! │ │ Applications ---> │ │ [*] TFTP support ---> │ │ [*] TFTP-o-matic │ │ TFTP-server IPv4 address: "192.168.123.233" // Server wo TFTPD läuft │ │ TFTP image to load: "esex060.bin" // Diesen Dateinamen ladet später unser Board via Netzwerk/tftpd jetzt noch EXIT und SPEICHERN. # make clean && make // Befehl zum kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 5902/8192 bytes (72.4%) [=====================---------] Program (.text + .data) : 5902 bytes Data (.data + .bss) : 1902 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.hex</b> ===Bootloader flashen via ISP=== <div><ul> <li style="display: inline-block;"> [[File:Avrdude tempmess01.png|thumb|none|200px|avrdude Bild 1]] </li> <li style="display: inline-block;"> [[File:Avrdude tempmess01.png|thumb|none|200px|avrdude Bild 2]] </li> <li style="display: inline-block;"> [[File:Avrdude tempmess01.png|thumb|none|200px|avrdude Bild 3]] </li> <li style="display: inline-block;"> [[File:Avrdude tempmess01.png|thumb|none|200px|avrdude Bild 4]] </li> </ul></div> Ich flashe hier einfacher weise mit meinem Windows 7 Notebook. Ich habe avrdude einfach unter C:\ liegen. Dort kopiere ich nun die ethersex.hex hin.<br> Somit kann man mit dem flashen den Bootloaders loslegen. avrdude -cusbasp -pm644p -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m // gilt nur für atmega644p und vermutlich auch 644 avrdude -cusbasp -pm644p -U flash:w:ethersex.hex avrdude -cusbasp -pm644p -U lock:w:0x0F:m Der Mikrocontrollerboard ist nun vorbereitet für die eigentliche Firmware. Der ISP-Programmer kann nun bei Seite gelegt werden und wird soweit alles richtig konfiguriert ist auch nicht mehr benötigt.<br> Nun erfolgt das Erstellen der Firmware. =FIRMWARE= ===Firmware bauen=== <div><ul> <li style="display: inline-block;"> [[File:Putty_c6_m4_tempmess01.png|thumb|none|200px|c6_m4 Bild 1]] </li> <li style="display: inline-block;"> [[File:Putty_c6_m4_tempmess02.png|thumb|none|200px|c6_m4 Bild 2]] </li> <li style="display: inline-block;"> [[File:Putty_c6_m4_tempmess03.png|thumb|none|200px|c6_m4 Bild 3]] </li> </ul></div> * <b>WICHTIG:</b> IP, MAC Adresse, Gateway, Netmask, Hostname <b>MUSS</b> gleich sein wie bei dem Bootloader! * Der integrierte Webserver ist in der original Firmware schon aktiviert. ( Applications --> [*] HTTP Server ) # cd /home/avr/ethersex_IP_60/ # cd ethersex/ # make menuconfig │ │ Load a Default Configuration ---> │ │ (*) Etherrape │ │ General Setup ---> │ │ (ATmega644) Target MCU // atmega644p bei mir │ │ (20000000) MCU frequency // 20MHz Quarz │ │ [ ] VFS (Virtual File System) support // Benötige ich hier nicht. │ │ [*] control6 script // Hier wird unsere DS1820 Temperatur in eine Variable geschrieben für den implementieren Webserver. │ │ Network ---> // WICHTIG: IP, MAC Adresse, Gateway, Netmask, Hostname MUSS gleich sein wie bei dem Bootloader! │ │ Hostname: "esex060" │ │ [*] Ethernet (ENC28J60) support ---> │ │ MAC address: "02:ca:fe:3f:10:07" │ │ Randomize MAC address │ │ --Static IPv4 configuration │ │ IP address: "192.168.123.60" │ │ Netmask: "255.255.255.0" │ │ │ │ Default gateway: "192.168.123.10" │ │ I/O ---> │ │ [*] Onewire support ---> // Die allgemeine Onewire Unterstützung. │ │ [*] Onewire device detection support // Automatische Bauteilerkennung In der etherrape.m4 Datei wird nun noch der Pin des atmega geändert wo der DS1820 angeschlossen ist. Im NANO Editor wird mit "STRG-O dann Enter" gespeichert und mit STRG-X beendet. # nano pinning/hardware/etherrape.m4 // editieren der m4 Datei ----- ONEWIRE PIN ändern bei "ONEWIRE_PORT_RANGE(PD6, PD6)" zb. auf PD0 ----- Nun schreiben wir uns ein Script welches den Temperatursensor regelmäßig abfragt und in eine Globale Variable schiebt. # rm control6/control6.src // Original Datei löschen # nano control6/control6.src // Anlegen der c6 Datei. Die Datei ist nun neu und leer. C6_HEADER(`/* This will be in control6.h */') CONTROL_START ECMD_GLOBAL(temp01, 0, uint16_t); THREAD(start) temp01 = ONEWIRE_GET(1054698802080017); // Die ID muss vorher aus dem Sensor ausgelesen werden. Erklärung ganz am Schluss. WAIT(5) THREAD_END(start) ON STARTUP DO THREAD_START(start) END CONTROL_END Kompilieren der eigentlichen Firmware. # make clean && make // Befehl zum bereinigen & kompilieren =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 24072/65536 bytes (36.73%) [===========-------------------] Program (.text + .data) : 24072 bytes Data (.data + .bss) : 2250 bytes =================================== * Kompilierte Datei die wir benötigen <b>ethersex.bin</b> Die eigentliche Firmware ist nun kompiliert und fertig um via Netzwerk/tftpd aufgespielt zu werden. Ich verwende im folgenden Schritt Windows 7. Beschreibung im nächsten Schritt. ===Firmware flashen via TFTPD=== <div><ul> <li style="display: inline-block;"> [[File:Tftpd_tempmess01.png|thumb|none|130px|tftpd Bild 1]] </li> <li style="display: inline-block;"> [[File:Tftpd_tempmess02.png|thumb|none|130px|tftpd Bild 2]] </li> <li style="display: inline-block;"> [[File:Tftpd_tempmess03.png|thumb|none|200px|tftpd Bild 3]] </li> <li style="display: inline-block;"> [[File:Tftpd_tempmess04.png|thumb|none|180px|tftpd Bild 4]] </li> </ul></div> Nun ladet ihr euch [http://tftpd32.jounin.net/tftpd32_download.html tftpd] herunter und entpackt es. Ich habe dazu einen Ordner Namens "tftpd" in mein Benutzerverzeichnis "C:\Users\BANANE\tftpd\". Dort wird alles hinein kopiert.<br> Es muss eigentlich nicht viel eingestellt werden. Unter <b>GLOBAL</b> muss TFTP aktiviert sein und unter <b>TFTP</b> sollte das "Base Directory" angepasst werden. Eventuell noch die Bind IP berichtigen. Seht Ihr ja auf den Fotos. Jetzt das Programm noch einmal neu starten. * Mikrocontrollerplatine ist <b>abgesteckt</b>. * tftpd starten * die Datei vom vorigen Schritt in den tftpd Ordner kopieren. <b>ethersex.bin</b> * ethersex.bin umbenennen in "<b>esex060.bin</b>". * Mikrocontrollerplatine Einstecken. Jetzt sollte auch schon was passieren, wie auf Bild 4 zu sehen ist. * Der Mikrocontroller ist nun via Webinterface erreichbar. Es können nur ecmd Befehle entgegengenommen werden. * erste Testverbindung zu unserem Mikrocontroller - http://192.168.123.60/ecmd?help ----AUSGABE---- c6 get c6 set wdreset .... 1w list 1w get 1w convert help version * <b>Sollten wir eine neue Firmware kompiliert haben können wir den Controller via Webinterface neu starten. Befehl dazu ist "wdreset"</b>. * Also neue esex060.bin wieder in den tftpd Ordner kopieren, tftpd starten und via Web "wdreset" ausführen. * http://192.168.123.60/ecmd?wdreset * Nun ladet sich der Controller die esex060.bin wieder via tftpd. ===Hinweise=== ''- Bei meiner Firewall musste ich tftpd noch akzeptieren. tftpd hing beim ersten mal in einer Schleife.'' ''- Und nochmals via Netzwerk wird die .bin geflasht, nicht die .hex Datei!'' =ONEWIRE= ===Auslesen der Sensor ID=== * Die ID kann via Webinterface mit dem Befehl "1w list" ausgelesen werden. * [http://192.168.123.60/ecmd?1w%20list http://192.168.123.60/ecmd?1w list] ----AUSGABE---- 1054698802080017 OK * Nun könnt Ihr die richtige ID oben im Control6 Script einsetzten und die Firmware neu kompilieren. * Wir haben im C6 Script eine Temperatur variable definiert welche "temp01" lautet. * Aktualisiert wird die Variable alle 5 Sekunden, das ist ebenfalls im C6 Script angegeben. * Diese kann ich nun via Webinterface abfragen - [http://192.168.123.60/ecmd?c6%20get%20temp01 http://192.168.123.60/ecmd?c6 get temp01] ----AUSGABE---- temp01 241 // 24.1 Grad [[User_talk:Djmaster#1 | Todoliste]] [[Category:Tutorials]] 41cc28c22abbfd0bb73362d3ef661527fce702aa 0 390 1789 1722 2017-01-22T13:26:21Z Kpwg 721 /* HD44780 Punktmatrixdisplays */ wikitext text/x-wiki {{i18n|Nutzung in FHEM}} [http://www.fhemwiki.de/wiki/Hauptseite FHEM] ist ein Hausautomations-Server von Rudolf Koenig et al. in Perl geschrieben, um diverse per Funk und Kabel angebundene Komponenten aus dem Bereich der Hausautomation zu steuern. Er ist lizensiert unter der GPL v2. Das [http://www.pollin.de/shop/suchergebnis.html?S_TEXT=810+058 AVR-Net-IO] von [http://www.pollin.de Pollin] mit [[Ethersex]] dient als [http://www.fhemwiki.de/wiki/AVR-NET-IO preisgünstiger Einstieg in die Hausautomatisierung]. Verwendbar ist aber auch jede andere [[Supported_Boards_(Deutsch) | Hardware]], die von Ethersex unterstützt wird (Arduino, eigene Entwicklungen, etc.). Über [[ECMD]] lassen sich dabei theoretisch alle in [[Ethersex]] vorhandenen [[ECMD_Protocols_%28Deutsch%29 | Möglichkeiten]] nutzen, sofern in FHEM entsprechende [http://fhem.de/commandref.html#ECMD ECMD-Devices] definiert und eingebunden werden, die passende Klassendefinition exisitert und die Aktion ausgelöst wird. == Grundlagen == Ausgehend von einem fertigen und per Telnet erreichbaren Ethersex muss in FHEM zuerst das entsprechende Device definiert werden. <pre> define NETIO_WZ ECMD telnet 192.168.3.81:2701 </pre> Eine serielle Anbindung kann mit ''define <name> ECMD serial <SerialDevice>[<@BaudRate>]'' alternativ erfolgen. Anschließend werden die erstellten .classdef-Konfigurationsdateien der einzelnen Funktionen dem System bekannt gemacht. In diesen .classdef-Dateien (Name und Endung sind frei wählbar!) wird die Schnittstelle zwischen FHEM und ECMD/Ethersex definiert. Dabei können mit perl übergebene Parameter und empfangene Daten bearbeitet sowie die in FHEM gebräuchlichen Readings erstellt werden. <pre> attr NETIO_WZ classdefs RFM12_2272=/opt/fhem/FHEM/rfm12_2272.classdef:RFM12_IT=/opt/fhem/FHEM/rfm12_it.classdef:LCD=/opt/fhem/FHEM/lcd.classdef:DHT22=/opt/fhem/FHEM/dht22.classdef:1WIRE=/opt/fhem/FHEM/1wire.classdef </pre> Die Definitionen für IC2272, Intertechno, HD44780-LCD, DHT22 und 1wire sind nun eingebunden. In den folgenden Abschnitten wird auf die einzelnen Devices näher eingegangen. Generell sind Pfade und IP-Adressen sowie übergebene Parameter noch entsprechend der eigenen Konfiguration anzupassen. == [[Onewire_(Deutsch) | 1-Wire Temperatursensoren]] == [[File:DS18B20.jpg|150px|thumb|right|DS18B20-Sensoren]] Die 1wire-Temperatursensoren DS18B20 oder DS18S20 werden im [[Onewire_(Deutsch)#Polling_Modus | Polling Modus]] abgefragt. Das macht die zyklische Abfrage aus FHEM heraus wesentlich einfacher. Eine Polling-Zeit von mindestens 30 Sekunden ist absolut ausreichend.Im Vorfeld sollte man sich die [[Onewire_(Deutsch)#Benennung_von_Sensoren | ROM-Codes der Sensoren]] notieren, da diese nachher benötigt werden. 1w-temp.classdef erstellen: <source lang="perl"> # Uebergabeparameter Onewire Rom-Code params devID # Umsetzung in ECMD Befehle 1w get = Temperatur auslesen get 1W cmd {"1w get %devID\n"} get 1W expect "\d+.\d+\n" get 1W postproc {\ s/\n//g;\ my $hash = $defs{%NAME};\ my $temperature = $_;\ my $state = "T: $temperature";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die classdef wird eingebunden: <pre> define NETIO_KU ECMD telnet 192.168.3.82:2701 attr NETIO_KU classdefs 1W-TEMP=/opt/fhem/FHEM/1w-temp.classdef </pre> Die Sensoren werden anhand des ROM-Code definiert: <pre> define HZ_WW ECMDDevice 1W-TEMP 284c8820050003d4 attr HZ_WW IODev NETIO_KU define HZ_VL ECMDDevice 1W-TEMP 2890a520050003d7 attr HZ_VL IODev NETIO_KU </pre> Eine zyklische Messung pro Minute lässt sich in dieser Form auslösen: <pre> define Messung_1w at +*00:01 get HZ_WW 1W;; get HZ_VL 1W attr Messung_1w verbose 0 </pre> == [[DHT|DHT22 Temperatur-/Feuchtesensoren]] == [[File:DHT22.jpg|150px|thumb|right|DHT22-Sensoren]] [[Ethersex]] unterstützt die preiswerten Temperatur-/Feuchtesensoren [[DHT|DHT11 und DHT22]], wobei letztere [[DHT#DHT11_vs_DHT22|um einiges genauer sind]]. Die Sensoren benötigen 5V Betriebsspannung und kommunizieren über je einen Pin mit dem Prozessor. Der Preis pro Stück liegt derzeit bei etwa 3.50 Euro (ebay/China). Wer die Trägheit und Ungenauigkeit der S300TH oder TX29DTH kennt, wünscht sich vermutlich Besseres; vor allem bei Berechnung von [http://de.wikipedia.org/wiki/Taupunkt Taupunkt] und [http://de.wikipedia.org/wiki/Luftfeuchtigkeit#Absolute_Luftfeuchtigkeit absoluter Feuchte], welche von der Genauigkeit der gemessenen Eingangsgrößen sehr profitieren. Berechnungen von Hand kann man beim [http://www.wetterochs.de/wetter/feuchte.html Wetterochs] durchführen. Die automatische Berechnung der absoluten Feuchte in FHEM wird im [http://forum.fhem.de/index.php/topic,21458.0.html Forum] erklärt. '''Einbindung in FHEM''' dht22m.classdef erstellen: <source lang="perl"> # Uebergabeparameter DHT22 ID 0...n params devID # Umsetzung in ECMD Befehle fuer DHT22 get DHT cmd {"dht temp %devID\n\000dht humid %devID\n"} get DHT expect "-?\d+.\d\n" get DHT postproc {\ s/(.*)\n(.*)\n/T: $1 H: $2/;\ my $hash = $defs{%NAME};\ my $temperature = $1;\ my $humidity = $2;\ my $state = $_;\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "humidity", $humidity, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs DHT22M=/opt/fhem/FHEM/dht22m.classdef </pre> Die Sensoren werden definiert: <pre> define Test0 ECMDDevice DHT22M 0 attr Test0 IODev NETIO_TEST define Test1 ECMDDevice DHT22M 1 attr Test1 IODev NETIO_TEST define Test2 ECMDDevice DHT22M 2 attr Test2 IODev NETIO_TEST define Test3 ECMDDevice DHT22M 3 attr Test3 IODev NETIO_TEST </pre> Eine zyklische Messung alle 4 Minuten könnte so aussehen: <pre> define Messung_DHT at +*00:04 get Test0 DHT;; get Test1 DHT;; get Test2 DHT;; get Test3 DHT attr Messung_DHT verbose 0 </pre> Fünfzehn Messwerte pro Stunde genügen den allermeisten Anforderungen. == [[BMP085 | BMP085/BMP180 Luftdrucksensor]] == [[File:BMP180.jpg|150px|thumb|right|BMP180 (unten links)]] Ethersex unterstützt den BMP085 (bzw. den BMP180; der Code ist identisch) über das [[I2C_(Deutsch) | I2C]]-Interface. Da der Sensor für 3.3V Betriebsspannung ausgelegt ist, muss entweder der I2C-Pegel angepasst oder der ATMega auf 3.3V adaptiert werden. Weiterhin sollte die Höhe über Null bekannt sein. Beispiel: Eine Abfrage per [[ECMD]] mit ''bmp085 pressnn 59000'' bedeutet, das ich 590m (59000cm) über NN wohne. Sollte der Befehl ''bmp085 pressnn'' aus Platzgründen nicht mehr in Image passen, kann man die Umrechnung auf Normal Null alternativ auch in der classdef erledigen. Die im Sensor verfügbare Temperatur wird parallel ausgelesen. '''Einbindung in FHEM''' bmp085.classdef erstellen, falls ''presnn'' unterstützt wird (59000 durch eigene Höhe in cm ersetzen!): <source lang="perl"> get BMP cmd {"bmp085 temp\n\000bmp085 pressnn 59000\n"} get BMP expect ".*" get BMP postproc {\ s/(.*)\n(.*)\n/T: $1 P: $2/;\ my $hash = $defs{%NAME};\ my $temperature = $1/10;\ my $pressure = sprintf("%.1f",$2/100);\ my $state = "T: $temperature P: $pressure";\ \ readingsSingleUpdate($hash, "temperature", $temperature, 1);\ readingsSingleUpdate($hash, "pressure", $pressure, 1);\ readingsSingleUpdate($hash, "state", $state, 1);\ \ } </source> Die Temperatur wird in °C mit einer Nachkommastelle gelesen, der Luftdruck in hPa bzw. mbar auf eine Nachkommastelle gerundet. Passende Readings werden erstellt. Das expect .* kann noch angepasst werden, um bei fehlerhaften Messwerten entsprechend zu reagieren. Die classdef wird in FHEM eingebunden (mehrere .classdef mit Doppelpunkt trennen: siehe [[Nutzung_in_FHEM_(Deutsch)#Grundlagen | Grundlagen]]): <pre> define NETIO_STK ECMD telnet 192.168.3.89:2701 attr NETIO_STK classdefs BMP=/opt/fhem/FHEM/bmp085.classdef </pre> Der Sensor wird definiert: <pre> define BMP180 ECMDDevice BMP attr BMP180 IODev NETIO_STK </pre> Das STATE ''kann'' mit Maßeinheiten versehen werden: <pre> attr BMP180 stateFormat { sprintf("%s°C %shPa", ReadingsVal("BMP180","temperature",0), ReadingsVal("BMP180","pressure",0)) ;; } </pre> Eine zyklische Messung alle 4 Minuten erfolgt wieder mit ''at'': <pre> define Messung_BMP at +*00:04 get BMP180 BMP attr Messung_BMP verbose 0 </pre> Dabei unterdrückt verbose 0 einen zusätzlichen (doppelten) Logeintrag des Messvorganges. Alternative bmp085.classdef, die die Umrechnung auf Normal Null in Perl macht (590 durch eigene Höhe in m ersetzen): <source lang="perl"> get pressure cmd {"bmp085 apress\n"} get pressure expect "\d+\n" get pressure postproc { s/(..)\n/.$1/; $_/=(1-(590/44330.7692))**5.255; $_ } get temp cmd {"bmp085 temp\n"} get temp expect "\d+\n" get temp postproc { s/(.)\n/.$1/; $_ } </source> Bei diesem Beispiel können Temperatur und Druck separat ausgelesen werden, hier ein Beispiel für das zyklische Auslesen beider Werte: <pre> define Messung_BMP at +*00:04 get BMP180 pressure ;; get BMP180 temp </pre> == analoge Eingänge abfragen == Die analogen Eingänge des ATMega sind recht simpel abzufragen. Dabei werden die hexadezimalen Werte gleich dezimal gewandelt, um die Weiterverarbeitung zu erleichtern. '''Einbindung in FHEM''' adc.classdef erstellen: <source lang="perl"> get value cmd {"adc get %PortID\n"} params PortID get value expect ".*" get value postproc {\ my $hexval = hex(trim("$_"));\ my $hash = $defs{%NAME};\ readingsSingleUpdate($hash, "state", $hexval, 1);\ } </source> Die classdef wird eingebunden: <pre> define NETIO_KU ECMD telnet 192.168.3.89:2701 attr NETIO_KU classdefs ADC=/opt/fhem/FHEM/adc.classdef </pre> Die Sensoren an den ersten beiden Ports werden definiert: <pre> define MP_0 ECMDDevice ADC 0 attr MP_0 IODev NETIO_KU define MP_1 ECMDDevice ADC 1 attr MP_1 IODev NETIO_KU </pre> Eine zyklische Messung alle 60 Sekunden funktioniert damit: <pre> define Messung_adc at +*00:01 get MP_0 value;; get MP_1 value attr Messung_adc verbose 0 </pre> == digitale Eingänge abfragen == todo == digitale Eingänge - proaktiv == Kontakte, die bei Zustandsänderung sofort in FHEM eine Meldung erzeugen sollen, kann man nicht zeitnah mit Polling abfragen. Diese Ereignisse, welche auch aus einem Control6-Script heraus generiert sein können, sollen selbst Meldung machen. Hierbei wird die ESEND-Funktion benutzt, mit welcher auch mehrere Ethersex'e untereinander kommunizieren können. Dabei ist es nicht relevant, ob das Device in FHEM per ECMDDevice bereits eingebunden wurde. Zuerst muss FHEM auf Port 2701 für Telnet-Verbindungen empfänglich werden: <pre> define telnetECMD telnet 2701 global </pre> Mit ''Watch io changes and react'' lässt sich per menuconfig bereits auf einfache Weise eine Abfrage von Portpins mit Generierung eines ESEND-Befehles bewerkstelligen. Das Beispiel soll zeigen, wie bei entsprechender Zustandsänderung an Pin PA0 an 192.168.178.10 ein FHEM-Befehl gesendet wird: <pre> ECMDTCP(PA0, RISING, 192.168.178.10, set Lampe on\n\n) ECMDTCP(PA0, FALLING, 192.168.178.10, set Lampe off\n\n) </pre> Jede Sequenz muss mit \n\n abgeschlossen werden, damit FHEM für weitere Befehle empfangsbereit bleibt. Falls man in FHEM flexibler bei der Weiterverarbeitung sein möchte, bietet sich eine dummy-notify-Kombination an. == [[Porterweiterungen_%28Deutsch%29#D.2FA-Wandler_mit_LTC1257 | LTC1257 D/A-Wandler]] == [[File:LTC1257.jpg|150px|thumb|right|LTC1257 Digital-Analog-Wandler innerhalb einer Schaltung]] Die 12bit Digital-Analog-Wandler von LINEAR TECHNOLOGY werden mit drei Pins bedient. Er wandelt (bei interner Referenzspannung) einen digital übermittelten Wert in eine Spannung von 0-2,048V um. Ein nachgeschalteter OPV als nichtinvertierender Verstärker kann diesen Bereich entsprechend skalieren. ltc1257.classdef erstellen: <source lang="perl"> # Umsetzung in ECMD Befehle # Ein Uebergabeparameter -> Sollwert set setDAC params dacValue set setDAC cmd {"ltc1257_set %dacValue\n"} set setDAC expect "OK\n" # Keine Uebergabeparameter set init cmd {"ltc1257_init\n"} set init expect "OK\n" # } </source> Die classdef wird eingebunden: <pre> define NETIO_KU ECMD telnet 192.168.3.82:2701 attr NETIO_KU classdefs LTC1257=/opt/fhem/FHEM/ltc1257.classdef </pre> Der LTC wird entsprechend definiert: <pre> define HZ_DAC ECMDDevice LTC1257 attr HZ_DAC IODev NETIO_KU </pre> Nun lässt sich mit einem '''set HZ_DAC init''' der LTC initialisieren (die gemessene Ausgangsspannung sollte 0V sein) und mit '''set HZ_DAC setDAC [0...4095]''' der gewünschte Wert setzen. Hier muss vorab experimentell entsprechend der nachfolgenden Beschaltung die tatsächliche Spannung ermittelt werden. == [[HD44780 | HD44780 LCD Punktmatrixdisplays]] == [[File:HD44780.jpg|150px|thumb|right|verschiedene HD44780 Displays (16x1 bis 40x4)]] Die beliebten Punktmatrix-Displays auf Basis [http://de.wikipedia.org/wiki/HD44780 HD44780] können vollumfänglich in FHEM beschrieben werden. '''Einbindung in FHEM''' lcd.classdef erstellen: <source lang="perl"> # Umsetzung der ECMD Befehle set write params line col text set write cmd {"lcd goto %line %col\n\000lcd write %text\n"} set write expect "OK\n" set write postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set clear params col set clear cmd {"lcd clear %col\n"} set clear expect "OK\n" set clear postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set clear_all cmd {"lcd clear\n"} set clear_all expect "OK\n" set clear_all postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} set lcd_bl params state set lcd_bl cmd {"lcd backlight %state\n"} set lcd_bl expect "OK\n" set lcd_bl postproc {s/([OK\n|;]*)/success/; "$_" eq "success" ? "ok" : "error";} </source> Die classdef wird eingebunden: <pre> define NETIO_TEST ECMD telnet 192.168.3.89:2701 attr NETIO_TEST classdefs LCD=/opt/fhem/FHEM/lcd.classdef </pre> Das Display wird definiert: <pre> define WZ_LCD ECMDDevice LCD attr WZ_LCD IODev NETIO_TEST </pre> Es stehen in FHEM folgende Befehle für das LCD bereit: {| border='1' | ''Befehl'' | ''Funktion'' |- | set WZ_LCD clear [ZEILE] | löscht den Inhalt einer ZEILE (0...3) |- | set WZ_LCD clear_all | löscht den Inhalt aller Zeilen |- | set WZ_LCD lcd_bl STATE | schaltet die Hintergrundbeleuchtung ein oder aus (STATE on oder off) |- | set WZ_LCD write [ZEILE] [SPALTE] [TEXT] | schreibt einen TEXT auf Position ZEILE SPALTE (0...n) |- |} Da ein im TEXT übergebenes Leerzeichen als weiterer Befehl interpretiert wird und zu einer Fehlermeldung führt, ist eine Übergabe nur mit \x20 im Text möglich. Das gilt auch für Umlaute. Anhand der [http://de.wikipedia.org/wiki/HD44780#Schrift_und_Zeichensatz Zeichensatztabelle] lassen sich ä durch \xE1, ü durch \xF5 und ö durch \xEF darstellen. Das ß wird mit \xE2 erreicht. Die Tabelle kann für manche Displays abweichend sein.<br /> Beispiel: ''set WZ_LCD write 0 0 Fenster\x20schlie\xE2en'' schreibt ein '''Fenster schließen''' auf's LCD. '''Komfortable Nutzung in FHEM mit DLCD''' Mit dem DLCD-Modul ([http://www.fhemwiki.de/wiki/DLCD Wiki-Beitrag] / [http://forum.fhem.de/index.php/topic,24519.0.html Foren-Beitrag]) für FHEM lässt sich jedes Display auf einfache Weise beschreiben. Dabei lassen sich bequem Readings von allen Devices nutzen, aufbereiten (formatieren, umrechnen, etc.) und entsprechend darstellen. Eine genaue Beschreibung hält der Wiki-Beitrag bereit; hier soll ein Beispiel gezeigt werden. Ziel war es, auf einem 16x1 LCD wechselweise ''Datum/Zeit => Klimadaten Keller => Datum/Zeit => Klimadaten Garten'' darzustellen. Die Anzeige rotiert im 15-Sekunden-Takt, so das zu 50% Datum/Zeit und je 25% die Werte aus dem Garten und dem Keller angezeigt werden. Es wird bereits im Modul jedes Leerzeichen mit \x20 übersetzt. Der Außensensor ist ein [http://www.elv.de/elv-funk-kombi-wettersensor-ks-300-2-br-inkl-hochwertigem-2-m-edelstahlmast-br-und-qualitaetsbatterien.html KS300] (bzw. KS200) von ELV. Mit etwas Formatierung und ein paar Leerzeichen lässt sich eine stets gleiche Positionierung der Daten erreichen, da die Zeile nicht explizit gelöscht wird. Auszug aus der fhem.cfg: <pre> define DLCD_WZ DLCD attr DLCD_WZ dlcdBlankspaceReplace \x20 attr DLCD_WZ dlcdCols 16 attr DLCD_WZ dlcdLine1 %date_WD_ger% %date_D%.%date_M_ger% %time_h%:%time_m% attr DLCD_WZ dlcdLine2 Keller:%1%/%2% attr DLCD_WZ dlcdLine3 %date_WD_ger% %date_D%.%date_M_ger% %time_h%:%time_m% attr DLCD_WZ dlcdLine4 Garten: %3%/%4% attr DLCD_WZ dlcdPhysicalRows 1 attr DLCD_WZ dlcdPollInterval 15 attr DLCD_WZ dlcdRows 4 attr DLCD_WZ dlcdScrolling 1 attr DLCD_WZ dlcdTriggerCmd set WZ_LCD write %L% 0 %T% attr DLCD_WZ dlcdVal1 Keller:temperature attr DLCD_WZ dlcdVal1formatnum 3+1 attr DLCD_WZ dlcdVal2 Keller:humidity attr DLCD_WZ dlcdVal2formatnum 3+1 attr DLCD_WZ dlcdVal3 KS300:temperature attr DLCD_WZ dlcdVal3formatnum 3+1+- attr DLCD_WZ dlcdVal4 KS300:humidity attr DLCD_WZ dlcdVal4formatnum 2+0 </pre> Das Ergebnis kann so aussehen: <gallery> DLCD_1.jpg|Zustand 1.-15. Sekunde DLCD_2.jpg|Zustand 16.-30. Sekunde DLCD_3.jpg|Zustand 31.-45. Sekunde DLCD_4.jpg|Zustand 46.-60. Sekunde </gallery> Die Formatierung bewirkt eine immer identische Platzierung der Daten. Der Außensensor hat keine Zehntelwerte bei der Feuchte, muss dafür aber negative Temperaturen darstellen. Der Innensensor zeigt Zehntelwerte, womit sich Tendenzen eher erkennen lassen. == [[RFM12_ASK_(Deutsch) | Intertechno schalten mit RFM12]] == todo == [[RFM12_ASK_(Deutsch) | IC2272 schalten mit RFM12]] == todo [[Category:Application|Application]] 7edc78510a30cfee6f9957442f23602a94b73b15 0 319 1790 1744 2017-06-25T18:13:39Z GooPie4o 265 wikitext text/x-wiki {{i18n|Features}} == Supported Network Hardware == * Ethernet [[ENC28J60 | Microchip's ENC28J60]] with IEEE 802.1q VLAN tagging * [[USB]] * [[RFM12]] * [[ZBUS]] == Network Protocols == * IPv4, IPv4 * TCP/IP, UDP/IP and ICMP * DNS * mDNS (Avahi) * [[BOOTP]] * [[DHCP]] * TFTP (can be used in combination with the [[Ethernet Loader]]) * SYSLOG * [[SNMP]] * SMTP * [[NTP]] (Client and Server) * DynDNS * MySQL (Client) * IRC (Client) * [[XMPP | XMPP / Jabber Client]] * MPD (Music Player Daemon) * [[SOAP]] / XMLRPC * [[UPnP]] * [[Artnet]] == Hardware Drivers == * [[Onewire]] * [[I2C | I2C Master / Slave]] * [[ADC input]] * [[PWM Generator]] * [[RFM12_FS20]] * [[RFM12_ASK]] * [[Generic ASK Modules]] * [[Bluetooth|Bluetooth SPP]] * [[USB]] * [[Bluetooth]] * [[PS/2 Keyboard]] * [[Button Input]] * [[HC595]] * [[HC165]] * [[HD44780]] alphanumeric character LCDs * [[IRMP | IR Receivers]] * [[SRAM]] == Software Modules == * [[Ethersex Lighting Architecture]] ** [[Starburst]] ** [[StellaLight]] ** [[DMX Storage]] ** [[DMX FXSlot]] * [[Cron | Cron Daemon]] * [[System Clock | Clock ]] * [[VNC Server]] * [[lome6]] * [[Frequency Counter]] c3040b1a3163da07629c70f9ecc3dd446b8c67f1 1792 1790 2017-06-25T18:15:06Z GooPie4o 265 wikitext text/x-wiki {{i18n|Features}} == Supported Network Hardware == * Ethernet [[ENC28J60 | Microchip's ENC28J60]] with IEEE 802.1q VLAN tagging * [[USB]] * [[RFM12]] * [[ZBUS]] == Network Protocols == * IPv4, IPv4 * TCP/IP, UDP/IP and ICMP * DNS * mDNS (Avahi) * [[BOOTP]] * [[DHCP]] * TFTP (can be used in combination with the [[Ethernet Loader]]) * SYSLOG * [[SNMP]] * SMTP * [[NTP]] (Client and Server) * DynDNS * MySQL (Client) * IRC (Client) * [[XMPP | XMPP / Jabber Client]] * MPD (Music Player Daemon) * [[SOAP]] / XMLRPC * [[UPnP]] * [[Artnet]] == Hardware Drivers == * [[Onewire]] * [[I2C | I2C Master / Slave]] * [[ADC input]] * [[PWM Generator]] * [[RFM12_FS20]] * [[RFM12_ASK]] * [[Generic ASK Modules]] * [[Bluetooth|Bluetooth SPP]] * [[USB]] * [[PS/2 Keyboard]] * [[Button Input]] * [[HC595]] * [[HC165]] * [[HD44780]] alphanumeric character LCDs * [[IRMP | IR Receivers]] * [[SRAM]] == Software Modules == * [[Ethersex Lighting Architecture]] ** [[Starburst]] ** [[StellaLight]] ** [[DMX Storage]] ** [[DMX FXSlot]] * [[Cron | Cron Daemon]] * [[System Clock | Clock ]] * [[VNC Server]] * [[lome6]] * [[Frequency Counter]] f8907ee0e28256a68a694aa75c24bd5748bab88b 0 497 1791 1683 2017-06-25T18:14:51Z GooPie4o 265 wikitext text/x-wiki {{i18n|Features}} == Unterstützte Netzwerk Hardware == * Ethernet Microchip's [[ENC28J60_(Deutsch) | ENC28J60]] mit IEEE 802.1q VLAN tagging * [[USB_(Deutsch) | IP über USB serial host]] * [[RFM12_(Deutsch) | IP über RFM12]] * [[ZBus_(Deutsch) | ZBus: IP über RS485]] == Netzwerk Protokolle == * IPv4, IPv4 * TCP/IP, UDP/IP and ICMP * DNS * mDNS (Avahi) * [[BOOTP_(Deutsch)]] * [[DHCP]] * TFTP (can be used in combination with the [[Ethernet Loader_(Deutsch)]]) * SYSLOG * [[SNMP]] * SMTP * [[NTP]] (Client and Server) * DynDNS * MySQL (Client) * IRC (Client) * [[XMPP | XMPP / Jabber Client]] * MPD (Music Player Daemon) * [[SOAP_(Deutsch)]] / XMLRPC * [[UPnP]] * [[Artnet]] == Hardware Treiber == * [[Onewire_(Deutsch) | Onewire / 1Wire]] * [[I2C_(Deutsch) | I2C Master / Slave]] * [[ADC_(Deutsch) | ADC input]] * [[PWM Generator]] * [[RFM12_FS20_(Deutsch) | FS20 mit RFM12]] * [[RFM12_ASK_(Deutsch) | ASK mit RFM12]] * [[Generic ASK Modules | ASK mit generischen Modulen]] * [[Bluetooth_(Deutsch)|Bluetooth SPP]] * [[USB_(Deutsch) | USB]] * [[PS/2 Keyboard]] * [[Button Input]] * [[Porterweiterungen_(Deutsch)#74HC595_als_Ausgangserweiterung | 74HC595 Ausgangserweiterung]] * [[Porterweiterungen_(Deutsch)#74HC164_als_Ausgangserweiterung | 74HC164 Ausgangserweiterung]] * [[Porterweiterungen_(Deutsch)#74HC165_als_Eingangserweiterung | 74HC165 Eingangserweiterung]] * [[IRMP_(Deutsch) | IRMP Infrarot Empfänger]] * [[SRAM]] == Software Module == * [[Ethersex Lighting Architecture]] ** [[Starburst]] ** [[StellaLight]] ** [[DMX Storage]] ** [[DMX FXSlot]] * [[Cron_(Deutsch) | Cron Daemon_(Deutsch)]] * [[System Clock | Clock ]] * [[VNC Server]] * [[lome6]] * [[Frequency Counter]] b0a0edf7b19f087d9e3511a6295e6b07a2bed203 0 368 1793 1175 2017-06-27T17:16:44Z GooPie4o 265 wikitext text/x-wiki {{i18n|Bluetooth}} {{Module |NAME=Bluetooth |MENUCONFIG={{I/O}}->Radio->Bluetooth |STATUS={{In_Development}} |PINNING= - |ECMD= - |CONTROL6= - |DEPENDS= - |REQUIRES= - |TIMER= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/bluetooth https://github.com/ethersex/ethersex/tree/master/hardware/radio/bluetooth] }} BT0417C is a generic Bluetooth module loaded with SPP firmware for UART wireless cable replacement functions. It allows your target device to both send or receive the TTL data via Bluetooth technology without connecting a serial cable to your computer. Features: * TTL data transparent transfer between a host Bluetooth device * Compatible with all Bluetooth adapters that support SPP * Default baud rate: 9600,8,1,N * Pair code: 1234 * Built in antenna * Bluetooth Technology v2.0 compatible * Power input:3.3VDC * Compact Size == Connection == When used with 5V microcontrollers, the TXD output logic swing of the module still falls within the valid 5V TTL range, hence, can be connected directly to the UART RXD of the 5V microcontroller host. The RXD and inputs, however, are not 5V tolerant, and can be damaged by 5V level logic going in. Some level translation circuit must be added to protect the inputs. A simple diode level translator circuit like the ones shown in Figure 2 will suffice in most applications. A better alternative is with the use of 5V input tolerant tiny logic chips such as 74LVC1G125 – a single buffer chip housed in SMD SOT23-5 package. <gallery> File:bt0417c.jpg|BT0417C and breakout board File:bt0417c_5v.jpg|BT0417C to MCU (5V) File:bt0417c_3_3v.jpg|BT0417C to MCU (3,3V) </gallery> Attention: there are different version of the module and breakout board around with different firmware and pin assignment. == Configuration == == [[ECMD]] == == Links == [http://www.multiwii.com/forum/viewtopic.php?f=6&t=133 Serial Bluetooth RF Transceiver Module RS232]<br> [http://byron76.blogspot.de/ Firmware programmer]<br> [http://www.martyncurrey.com/category/bluetooth/ Martyn Currey's Blog]<br> [http://www.instructables.com/id/AT-command-mode-of-HC-05-Bluetooth-module/ AT Command Mode of HC-05 and HC-06 Bluetooth Module] 8c5cf5f450d375a47c4dbec9d6b53a605d00aece 1794 1793 2017-07-09T16:54:42Z GooPie4o 265 wikitext text/x-wiki {{i18n|Bluetooth}} {{Module |NAME=Bluetooth |MENUCONFIG={{I/O}}->Radio->Bluetooth |STATUS={{In_Development}} |PINNING= yes |ECMD= yes |CONTROL6= - |DEPENDS= - |REQUIRES= Free UART |TIMER= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/bluetooth https://github.com/ethersex/ethersex/tree/master/hardware/radio/bluetooth] }} BT0417C is a generic Bluetooth module loaded with SPP firmware for UART wireless cable replacement functions. It allows your target device to both send or receive the TTL data via Bluetooth technology without connecting a serial cable to your computer. Features: * TTL data transparent transfer between a host Bluetooth device * Compatible with all Bluetooth adapters that support SPP * Default baud rate: 9600,8,1,N * Pair code: 1234 * Built in antenna * Bluetooth Technology v2.0 compatible * Power input:3.3VDC * Compact Size == Connection == When used with 5V microcontrollers, the TXD output logic swing of the module still falls within the valid 5V TTL range, hence, can be connected directly to the UART RXD of the 5V microcontroller host. The RXD and inputs, however, are not 5V tolerant, and can be damaged by 5V level logic going in. Some level translation circuit must be added to protect the inputs. A simple diode level translator circuit like the ones shown in Figure 2 will suffice in most applications. A better alternative is with the use of 5V input tolerant tiny logic chips such as 74LVC1G125 – a single buffer chip housed in SMD SOT23-5 package. <gallery> File:bt0417c.jpg|BT0417C and breakout board File:bt0417c_5v.jpg|BT0417C to MCU (5V) File:bt0417c_3_3v.jpg|BT0417C to MCU (3,3V) </gallery> Attention: there are different version of the module and breakout board around with different firmware and pin assignment. == Configuration == The base configuration of the module: | | I/O ---> | | ... | | Radio ---> | | | | [ ] FS20 RF-control ---> | | | | [ ] RFM12 ASK ---> | | | | [ ] Generic ASK (433MHz) | | | | [*] Bluetooth ---> | | ... | | (3) Bluetooth usart select | | | | (115200) USART Baudrate | | | | Device Name: "ethersex" | | | | Device PIN: "1234" | | | | --- ECMD | | | | [ ] AT Command Interface | | | | --- Debugging Flags | | | | [ ] Bluetooth | | Optionally the module can be used with ECMD: | | Protocols ---> | | ... | | [*] ECMD (Ethersex Command) support ---> | | ... | | --- ECMD interfaces | | ... | | [-] USB | | | | [*] Bluetooth | | == [[ECMD]] == == Links == [http://www.multiwii.com/forum/viewtopic.php?f=6&t=133 Serial Bluetooth RF Transceiver Module RS232]<br> [http://byron76.blogspot.de/ Firmware programmer]<br> [http://www.martyncurrey.com/category/bluetooth/ Martyn Currey's Blog]<br> [http://www.instructables.com/id/AT-command-mode-of-HC-05-Bluetooth-module/ AT Command Mode of HC-05 and HC-06 Bluetooth Module] a9777d8f0e916b17dd730847fb978340d11a0003 1795 1794 2017-07-09T17:00:36Z GooPie4o 265 /* Connection */ wikitext text/x-wiki {{i18n|Bluetooth}} {{Module |NAME=Bluetooth |MENUCONFIG={{I/O}}->Radio->Bluetooth |STATUS={{In_Development}} |PINNING= yes |ECMD= yes |CONTROL6= - |DEPENDS= - |REQUIRES= Free UART |TIMER= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/bluetooth https://github.com/ethersex/ethersex/tree/master/hardware/radio/bluetooth] }} BT0417C is a generic Bluetooth module loaded with SPP firmware for UART wireless cable replacement functions. It allows your target device to both send or receive the TTL data via Bluetooth technology without connecting a serial cable to your computer. Features: * TTL data transparent transfer between a host Bluetooth device * Compatible with all Bluetooth adapters that support SPP * Default baud rate: 9600,8,1,N * Pair code: 1234 * Built in antenna * Bluetooth Technology v2.0 compatible * Power input:3.3VDC * Compact Size == Connection == When used with 5V microcontrollers, the TXD output logic swing of the module still falls within the valid 5V TTL range, hence, can be connected directly to the UART RXD of the 5V microcontroller host. The RXD and inputs, however, are not 5V tolerant, and can be damaged by 5V level logic going in. Some level translation circuit must be added to protect the inputs. A simple diode level translator circuit like the ones shown in Figure 2 will suffice in most applications. A better alternative is with the use of 5V input tolerant tiny logic chips such as 74LVC1G125 – a single buffer chip housed in SMD SOT23-5 package. <gallery> File:bt0417c.jpg|BT0417C and breakout board File:bt0417c_5v.jpg|BT0417C to MCU (5V) File:bt0417c_3_3v.jpg|BT0417C to MCU (3,3V) </gallery> Attention: there are different version of the module and breakout board around with different firmware and pin assignment. The module is connected to a free UART (TX/RX). In addition it requires at least an free I/O pin. /* switch between data and command mode pin(BT_MODULE_KEY, PC1, OUTPUT) /* read back pairing state of module */ pin(BT_MODULE_STATE, PC3, INPUT) == Configuration == The base configuration of the module: | | I/O ---> | | ... | | Radio ---> | | | | [ ] FS20 RF-control ---> | | | | [ ] RFM12 ASK ---> | | | | [ ] Generic ASK (433MHz) | | | | [*] Bluetooth ---> | | ... | | (3) Bluetooth usart select | | | | (115200) USART Baudrate | | | | Device Name: "ethersex" | | | | Device PIN: "1234" | | | | --- ECMD | | | | [ ] AT Command Interface | | | | --- Debugging Flags | | | | [ ] Bluetooth | | Optionally the module can be used with ECMD: | | Protocols ---> | | ... | | [*] ECMD (Ethersex Command) support ---> | | ... | | --- ECMD interfaces | | ... | | [-] USB | | | | [*] Bluetooth | | == [[ECMD]] == == Links == [http://www.multiwii.com/forum/viewtopic.php?f=6&t=133 Serial Bluetooth RF Transceiver Module RS232]<br> [http://byron76.blogspot.de/ Firmware programmer]<br> [http://www.martyncurrey.com/category/bluetooth/ Martyn Currey's Blog]<br> [http://www.instructables.com/id/AT-command-mode-of-HC-05-Bluetooth-module/ AT Command Mode of HC-05 and HC-06 Bluetooth Module] 416357f8d99fe97c04a15cc776252f5eef677f54 1796 1795 2017-07-09T17:01:09Z GooPie4o 265 /* Connection */ wikitext text/x-wiki {{i18n|Bluetooth}} {{Module |NAME=Bluetooth |MENUCONFIG={{I/O}}->Radio->Bluetooth |STATUS={{In_Development}} |PINNING= yes |ECMD= yes |CONTROL6= - |DEPENDS= - |REQUIRES= Free UART |TIMER= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/bluetooth https://github.com/ethersex/ethersex/tree/master/hardware/radio/bluetooth] }} BT0417C is a generic Bluetooth module loaded with SPP firmware for UART wireless cable replacement functions. It allows your target device to both send or receive the TTL data via Bluetooth technology without connecting a serial cable to your computer. Features: * TTL data transparent transfer between a host Bluetooth device * Compatible with all Bluetooth adapters that support SPP * Default baud rate: 9600,8,1,N * Pair code: 1234 * Built in antenna * Bluetooth Technology v2.0 compatible * Power input:3.3VDC * Compact Size == Connection == When used with 5V microcontrollers, the TXD output logic swing of the module still falls within the valid 5V TTL range, hence, can be connected directly to the UART RXD of the 5V microcontroller host. The RXD and inputs, however, are not 5V tolerant, and can be damaged by 5V level logic going in. Some level translation circuit must be added to protect the inputs. A simple diode level translator circuit like the ones shown in Figure 2 will suffice in most applications. A better alternative is with the use of 5V input tolerant tiny logic chips such as 74LVC1G125 – a single buffer chip housed in SMD SOT23-5 package. <gallery> File:bt0417c.jpg|BT0417C and breakout board File:bt0417c_5v.jpg|BT0417C to MCU (5V) File:bt0417c_3_3v.jpg|BT0417C to MCU (3,3V) </gallery> Attention: there are different version of the module and breakout board around with different firmware and pin assignment. The module is connected to a free UART (TX/RX). In addition it requires at least an free I/O pin. /* switch between data and command mode (mandatory) */ pin(BT_MODULE_KEY, PC1, OUTPUT) /* read back pairing state of module (optional) */ pin(BT_MODULE_STATE, PC3, INPUT) == Configuration == The base configuration of the module: | | I/O ---> | | ... | | Radio ---> | | | | [ ] FS20 RF-control ---> | | | | [ ] RFM12 ASK ---> | | | | [ ] Generic ASK (433MHz) | | | | [*] Bluetooth ---> | | ... | | (3) Bluetooth usart select | | | | (115200) USART Baudrate | | | | Device Name: "ethersex" | | | | Device PIN: "1234" | | | | --- ECMD | | | | [ ] AT Command Interface | | | | --- Debugging Flags | | | | [ ] Bluetooth | | Optionally the module can be used with ECMD: | | Protocols ---> | | ... | | [*] ECMD (Ethersex Command) support ---> | | ... | | --- ECMD interfaces | | ... | | [-] USB | | | | [*] Bluetooth | | == [[ECMD]] == == Links == [http://www.multiwii.com/forum/viewtopic.php?f=6&t=133 Serial Bluetooth RF Transceiver Module RS232]<br> [http://byron76.blogspot.de/ Firmware programmer]<br> [http://www.martyncurrey.com/category/bluetooth/ Martyn Currey's Blog]<br> [http://www.instructables.com/id/AT-command-mode-of-HC-05-Bluetooth-module/ AT Command Mode of HC-05 and HC-06 Bluetooth Module] 4d1fc55e6a944502dce01f10f758f706988ec6c3 1797 1796 2017-07-09T17:01:37Z GooPie4o 265 /* Connection */ wikitext text/x-wiki {{i18n|Bluetooth}} {{Module |NAME=Bluetooth |MENUCONFIG={{I/O}}->Radio->Bluetooth |STATUS={{In_Development}} |PINNING= yes |ECMD= yes |CONTROL6= - |DEPENDS= - |REQUIRES= Free UART |TIMER= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/bluetooth https://github.com/ethersex/ethersex/tree/master/hardware/radio/bluetooth] }} BT0417C is a generic Bluetooth module loaded with SPP firmware for UART wireless cable replacement functions. It allows your target device to both send or receive the TTL data via Bluetooth technology without connecting a serial cable to your computer. Features: * TTL data transparent transfer between a host Bluetooth device * Compatible with all Bluetooth adapters that support SPP * Default baud rate: 9600,8,1,N * Pair code: 1234 * Built in antenna * Bluetooth Technology v2.0 compatible * Power input:3.3VDC * Compact Size == Connection == When used with 5V microcontrollers, the TXD output logic swing of the module still falls within the valid 5V TTL range, hence, can be connected directly to the UART RXD of the 5V microcontroller host. The RXD and inputs, however, are not 5V tolerant, and can be damaged by 5V level logic going in. Some level translation circuit must be added to protect the inputs. A simple diode level translator circuit like the ones shown in Figure 2 will suffice in most applications. A better alternative is with the use of 5V input tolerant tiny logic chips such as 74LVC1G125 – a single buffer chip housed in SMD SOT23-5 package. <gallery> File:bt0417c.jpg|BT0417C and breakout board File:bt0417c_5v.jpg|BT0417C to MCU (5V) File:bt0417c_3_3v.jpg|BT0417C to MCU (3,3V) </gallery> Attention: there are different version of the module and breakout board around with different firmware and pin assignment. The module is connected to a free USART (TX/RX). In addition it requires at least an free I/O pin. /* switch between data and command mode (mandatory) */ pin(BT_MODULE_KEY, PC1, OUTPUT) /* read back pairing state of module (optional) */ pin(BT_MODULE_STATE, PC3, INPUT) == Configuration == The base configuration of the module: | | I/O ---> | | ... | | Radio ---> | | | | [ ] FS20 RF-control ---> | | | | [ ] RFM12 ASK ---> | | | | [ ] Generic ASK (433MHz) | | | | [*] Bluetooth ---> | | ... | | (3) Bluetooth usart select | | | | (115200) USART Baudrate | | | | Device Name: "ethersex" | | | | Device PIN: "1234" | | | | --- ECMD | | | | [ ] AT Command Interface | | | | --- Debugging Flags | | | | [ ] Bluetooth | | Optionally the module can be used with ECMD: | | Protocols ---> | | ... | | [*] ECMD (Ethersex Command) support ---> | | ... | | --- ECMD interfaces | | ... | | [-] USB | | | | [*] Bluetooth | | == [[ECMD]] == == Links == [http://www.multiwii.com/forum/viewtopic.php?f=6&t=133 Serial Bluetooth RF Transceiver Module RS232]<br> [http://byron76.blogspot.de/ Firmware programmer]<br> [http://www.martyncurrey.com/category/bluetooth/ Martyn Currey's Blog]<br> [http://www.instructables.com/id/AT-command-mode-of-HC-05-Bluetooth-module/ AT Command Mode of HC-05 and HC-06 Bluetooth Module] 84ba0a8932a41b61f527cdacedf9b2bae631586d 0 183 1798 1527 2017-09-14T16:28:32Z Djmaster 255 /* TSL2561 Licht/Digital-Wandler */ wikitext text/x-wiki {{i18n|I2C}} {{Module |NAME=I2C |MENUCONFIG={{I/O}}-{{I2C Master}} |STATUS={{stable}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6= - |DEPENDS= - |REQUIRES= CONFIG_EXPERIMENTAL |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/i2c/master https://github.com/ethersex/ethersex/tree/master/hardware/i2c/master] }} Der I2C-Bus (Inter Integrated Circuit) ist ein einfacher Zweidraht-Bus, der für die Kommunikation zwischen ICs innerhalb eines größeren Systems verwendet wird. Insbesondere bietet er sich an zur Kommunikation zwischen Microcontrollern und Peripheriegeräten. Das [[Ethersex]]-System kann sowohl als Master als auch als Slave in einem I2C-Bus arbeiten. In der Atmel-Dokumentation wird I2C als TWI (Two Wire Interface) geführt. =Allgemeines= ==Master Mode== Im Master-Mode kann das Ethersex-System auf angeschlossene I2C-Slaves zugreifen. Unterstützt werden im Moment: * 24cXX EEPROMs (Als Storage Backend für das Virtuelle Dateisystem) * LM75 Temperatursensoren * PCA9531 8 bit LED Dimmer * PCF8574x Port Extension ==Slave Mode== * Kann per I2C auf die [[ECMD (Deutsch) | ECMD ]] Schnittstelle zugegriffen werden. * In menuconfig -> Protocols -> ECMD -> I2C aktivieren [[I2C/Slave Example (Deutsch) | Beispielimplementierung]] mit Ethersex (Slave) und einem zweiten AVR (Master). ==Anschluss== Die Leitungen SCL (Clock) und SDA (Data) liegen als "Alternate Function" auf I/O Leitungen der Controller. Beim ATmega32/644/644p sind dies PC0 (SCL) und PC1 (SDA). ==Levelshifter 3,3V 5V== Link: [[User:Djmaster#Levelshifter_3.3V_5V|Levelshifter 3,3V 5V]] =Etherrape= Beim [[Etherrape_(Deutsch)|Etherrape]] ist der I2C-Bus auf einem separaten Steckverbinder herausgeführt. =Pollin AVR-NET-IO= Beim Pollin [[AVR-NET-IO_(Deutsch)|AVR-NET-IO]] liegen die Leitungen des Ports C auf J3, dem 25poligen SUB-D Steckverbinder. Dort lassen sich auch Versorgungsspannung und Masse für die angeschlossenen Slaves abgreifen: {|class=wikitable !Pin !Funktion |- |2 |PC0 (SCL) |- |3 |PC1 (SDA) |- |15 |5V |- |18 |GND |} =Konfiguration= Die Leitungen sind fest vorgegeben, daher muss <b>keine</b> Konfiguration des Pinnings erfolgen. Die Einstellungen für den Master-Mode finden sich unter: │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ Network ---> │ │ I/O ---> │ │ I2C ---> │ │ [*] I2C master ---> │ │ [*] I2C detection support = ECMD = == I2C == Mittels "i2c detect" werden die gefundenen I2C Adressen aufgelistet i2c detect detected at: 0x20 (32) detected at: 0x48 (72) detected at: 0x60 (96) Mit den allgemeinen I2C-Kommandos können alle I2C-Chips angesprochen werden. Mit dem Befehl i2c wbb 72 81 wird z. B. die Temperatur-Konvertierung auf einem DS1631 gestartet. Geschrieben wird ein Byte mit dem Wert 81 an den Chip mit der Adresse 72. Mit dem Befehl i2c rwd 72 170 wird ein Word von der Adresse 170 des Chips mit der Adresse 72 gelesen. Damit wird die Temperatur des DS1631 ausgelesen. Die Umrechung muß man dann per Hand durchführen. =I2C Sensoren= == DS1631 == Ein DS1631 Temperatursensor muß nach dem Einschalten der Stromversorgung erst aktiviert werden. Der erste DS1631 mit der Adresse 0x48 hat im Befehl die Adresse 0. Mit dem folgenden Befehl wird die Temperatur-Konvertierung eingeschaltet: ds1631 convert 0 1 Jetzt kann die Temperatur ausgelesen werden. Die Genauigkeit beträgt immer die vollen 12bits. ds1631 temp 0 22.875 Wahrscheinlich können auch DS1621-Sensoren ausgelesen werden, das wurde aber noch nicht getestet! == LM75 == Um den LM75 Temperatursensor auszulesen (Basisadresse 0x48) muss die IC Adresse angegeben werden. In diesem Falle ist das "0" weil die IC Adresse a0 bis a2 auf Masse gesetzt werden. -> binär 000 = 0 lm75 0 21.5 == PCF8574 == Für die Porterweiterung gilt das Schema "pcf8574x read adresse chip" wobei die adresse 0-7 sein kann, und chip "0" oder "1", je nachdem ob man den pcf8574 oder den pcf8574A benutzt. pcf8574x read 0 0 FFFF Schalten von Ausgängen mit Wert 0xF0 am PCF8574 mit Adresse 5 (Das bedeutet das a0=1 und a2=1 ist, ergo 101) d.h. die ersten 4 Ausgänge werden auf "1" die anderen 4 Ausgänge auf "0" gesetzt. pcf8574x set 5 0 F0 == TSL2561 Licht/Digital-Wandler == (tested commit e927b0e) I/O --> I2C--> [*]I2C master --> [*] I2C detection support [*] I2C TSL2561 light sensor <b>Abfrage via http ecmd:</b> /ecmd?i2c detect // detected at: 0x39 (57), funktioniert und wird erkannt. /ecmd?tsl2561 raw // parse error, funktioniert derzeit nicht?. 24.01.2016 /ecmd?tsl2561 lux // parse error, funktioniert derzeit nicht?. 24.01.2016 /ecmd?tsl2561 lux 0 // -1 [[Category:Ethersex]] [[Category:StepByStep]] [[Category:I2C]] [[Category:ECMD]] a87bfbe5a126b47fa406d43662a323a7407802cc 0 561 1799 2017-11-16T15:44:30Z GooPie4o 265 new module wikitext text/x-wiki {{i18n|GLCD}} {{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->Graphic Displays |STATUS={{In_Development}} |PINNING=yes |ECMD= - |CONTROL6= - |DEPENDS= - |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/lcd/glcd https://github.com/ethersex/ethersex/tree/master/hardware/lcd/glcd] }} The '''GLCD module''' provides support for common '''monochrome and color graphic LCDs''' with the help of [https://github.com/olikraus/u8g2 U8G2] and [https://github.com/olikraus/ucglib UCGLIB] by Oliver Kraus. b9df799593dc557c0235d1ac0d459b7c721ebae8 0 562 1800 2017-11-16T15:48:28Z GooPie4o 265 Created page with "{{i18n|GLCD}} {{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->Graphic Displays |STATUS={{In_Development}} |PINNING=yes |ECMD= - |CONTROL6= - |DEPENDS= - |REQUIRES= ..." wikitext text/x-wiki {{i18n|GLCD}} {{Module |NAME=HD44780 |MENUCONFIG={{I/O}}->LCD Displays->Graphic Displays |STATUS={{In_Development}} |PINNING=yes |ECMD= - |CONTROL6= - |DEPENDS= - |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/lcd/glcd https://github.com/ethersex/ethersex/tree/master/hardware/lcd/glcd] }} Das '''GLCD Modul''' unterstützt '''monochrome and farbige Grafik-LCDs''' mit Hilfe von [https://github.com/olikraus/u8g2 U8G2] und [https://github.com/olikraus/ucglib UCGLIB] von Oliver Kraus. 0f6787b5b9505923369128052fedace8ece8a410 0 338 1801 1515 2017-11-16T15:52:54Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{Protocols}}->Radio->Radio outlets (433MHz) |STATUS={{Stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/protocols/radio/ask https://github.com/ethersex/ethersex/tree/master/protocols/radio/ask] }} In ASK mode the RFM12 module is used to switch radio outlets. Alternatively you can also receive the radio transmission between the transmitter and radio socket outlet. Currently, the following systems are supported: * Self-learning systems (drive "tevion") * Systems based on the chips or PT2262/PT2272 HX2262/2272 (driver "2272") * Concealed remote dimmer with the transmitter located HS1527 chip (driver "1527") * Transmitter type Intertechno ITS-150 * Oase Inscenio FM Master system * Flamingo FA20RF/ELRO KD101 smoke detectors == Connection == The RFM12 is connected to the AVRlike in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FFIT signal (Pin 4) is connected to one of the INT pins of the AVR. This modul does not work in interrupt mode, so the output nRQ signal (Pin 2) can be left unconnected. The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_ASK_SENSE_USE_INT(0) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_ASK_SENSE_USE_INT defines whether FFIT is connected to INT0, INT1 or INT2 of the AVR. == Configuration == | | I/O ---> | | ... | | Radio ---> | | ... | | [*] RFM12 ASK ---> | | ... | | [*] 433MHz | | | | (0) RFM12 select | | | | Protocols ---> | | ... | | Radio ---> | | | | [*] Radio outlets (433MHz) ---> | | ... | | (RFM12) Transmitter hardware | | | | [ ] Pollin/Kangtai Powerswitch (IC 2272) | | | | [ ] Pollin Powerswitch buried (IC 1527) | | | | [*] Tevion Powerswitch | | | | [ ] Intertechno ITS-150 | | | | [*] Oase FM Master | | | | [ ] Flamingo FA20RF/ELRO KD101 | | == [[ECMD]] == RFM12 ASK implements an [[ECMD]] interface to control to switch radio outlets. See [[ECMD_Reference|ECMD reference]]. [[Category:RFM12]] c893b113c8ba367004692ec3b49a372e99e4f3a8 0 156 1802 1516 2017-11-16T15:53:07Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 ASK}} {{Module |NAME=RFM12 ASK |MENUCONFIG={{Protocols}}->Radio->Radio outlets (433MHz) |STATUS={{Stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS= |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/protocols/radio/ask https://github.com/ethersex/ethersex/tree/master/protocols/radio/ask] }} RFM12 ASK schaltet Funksteckdosen verschiedener Hersteller. == Unterstützte Systeme == ===Tevion=== Funksteckdosen mit einer 'Anlern-Taste' können mit Hilfe des LERN-Buttons auf der embeded Website des etherrapes */rf.ht auf den gesendeten Hauscode programmiert werden. Erstaunlicherweise können mit diesem Modul auch die Codes der X10 Fernbedienung von Pollin gesendet werden. Eine Code-Sammlung gibts [[X10-codes|hier]]. [[Category:RFM12]] Getestet: * Tevion * MMANDOLYN LIBRA GmbH, Model No. WRC001 * X10 Pollin Best.Nr. 721 379 ===Intertechno (ITS-150)=== Bei Sender vom Typ Intertechno ITS-150 wird über einen Drehschalter auf der Rückseite der Familiencode eingestellt. Auf der Vorderseite gibt es einen Schieberegler für die Auswahl von Gruppe 1-4 sowie Ein/Aus Knöpfe für die Geräte 1-4 (siehe Bild). Die zusätzlich vorhandenen Gruppentaste funktioniert mit den Empfängern Intertechno CMR-500 nicht (deshalb nicht implementiert). [[Image:Intertechno-its150.jpg|150px]] ===2272=== Diese Steckdosen werden üblicherweise über einen Block von 10 DIP-Switches konfiguriert. Dabei wird mit den ersten fünf Schaltern der Hauscode gesetzt. Es ergeben sich also 32 mögliche Einstellungen. Die übrigen fünf Schalter geben die Adresse der Steckdose an. Bei Verwendung des mitgelieferten Senders wird jeweils einer der Adressschalter auf "1" gesetzt: In Dose A setzt man Dip 6 auf '1'; in Dose B Dip 7 auf '1'... Bei Ansteuerung mit dem Ethersex-System besteht diese Einschränkung nicht, so dass hier 32 verschiedene Adressen möglich sind. Getestet: {|class=wikitable |[http://www.elro.eu/uploads/products/img/_w200/AB440RA_1.jpg] |[[Image:Duewiaktor.jpg|134px]] |[[Image:Globusaktoren.jpg|134px]] |[[Image:Kangtai2605.jpg|101px]] |[[Image:Kangtai6899s.jpg|100px]] |- |valign=top|ELRO AB440R |valign=top|Düwi Modell 0369-3 |valign=top|Kangtai<br>v. Globus |valign=top|Kangtai<br>Model 2605 |valign=top|Kangtai<br>Model 6899s<br>[[Warnung vor Kangtai 6899s|'''Warnung!''']] |- |Delay 100 |Delay 60 |Delay 72 |Delay 72 |Delay 72 |} ====Funkleuchten lassen sich auch schalten!==== Neben den hier aufgeführten Funksteckdosen, lassen sich mit diesem Modul auch wunderbar diverse "neumodische" Funk-Leuchten, wie man sie aus Einrichtungshäusern kennt schalten. Die Fernbedienungen der Leuchten arbeiten dabei nicht mit dem 2262 Codierchip, sondern mit dem W0369DGP Codierchip. Dieser codiert genau wie der 2262 jedoch ist die Aufteilung der Codierbits (DIP-Schalter; in meinem Fall Lötbrücken) auf Hauscode und Gerätecode anders als bei den Funk Steckdosen. Die ersten 8 Codierbits sind sowohl in der Fernbedienung als auch in der Leuchte als Geräteadresse über Lötbrücken fest codiert. Dabei ist zu beachten, dass nur diese 8 Bits tri-state sind, also den Zustand "0", "1" oder "f" haben dürfen. Die weiteren 4 Bits sind die Schaltbefehle. WICHTIG: Die 4 Schalt-Bits können nur "0" oder "1" sein. === 1527 === Anlernbare Unterputz-Dimmer (zB. Pollin Funkdimmerset FD-UP003) mit Fernbedienung. Die mitgelieferte Fernbedienung besitzt einen HS1527 Encoder (baugleich RT1527/ EV1527/FP1527/SC1527). Der gesendete Code bestehtaus 24 Bits, welche per ASK gesendet werden. Davon sind die ersten 20 Bits fest programmiert - der Hauscode sozusagen. Die letzten 4 Bits sind der eigentliche Schalt-Befehl. Getestet: {|class=wikitable |[[Image:FD-UP003.jpg‎|150px|Pollin Electronic FD-UP003]] |- |valign=top|Pollin FD-UP003<br>[[Hinweis FD-UP003|'''Hinweis!''']] |} === Oase Inscenio FM Master === Das Baukastensystem für Gartensteckdosen der Serie [http://www.oase-livingwater.com/de_DE/wasser-garten/produkte/illumination-und-strom/strommanagement/inscenio.html InScenio] organisiert die gesamte Garten- und Teichtechnik. === Flamingo FA20RF/ELRO KD101 Rauchmelder === Die Rauchmelder Flamingo FA20RF, ELRO KD101 haben folgendes Verhalten: * Wenn der Sensor selbst Rauch feststellt, kann man diesen Alarm über Funk nicht stoppen. Er sendet seine ID über Funk. * Wenn man die ID über Funk an einen Rauchmelder sendet, dauert der Alarm nur wenige Sekunden. Für einen dauerhaften Alarm muss man also die ID immer wieder senden. * Wenn man die Sensoren pairt, bekommen alle gepairten Sensoren dieselbe ID. * Wenn einer Rauch erkennt, triggert er alle Sensoren mit derselben ID (also die gepairten). * Ein Sensor sendet kein Keepalive-Signal. Man kann also nur testen, ob ein Rauchmelder noch funktioniert, indem man die Test-Taste drückt. Mittels [[Ethersex]] kann man die ID an einen/eine Gruppe senden und damit für einige Sekunden einen Alarm auslösen. == Anschluss == == Konfiguration == == [[ECMD]] == RFM12 ASK implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle zur Steuerung von Funksteckdosen. Siehe [[ECMD_Reference|ECMD Referenz]]. 87a8bea4f399a98fa594e6281a4136f9ef5b2351 0 312 1803 1264 2017-11-16T15:54:01Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->Radio->RFM12 ASK->868MHz |STATUS={{Stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |TIMER={{occupies_timer|2}} (RX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} The FS20 / FHT system by ELV is currently the most successful wireless home control system in the low cost sector. This arises from the large number of components and the continuous expansion of the system. But the relatively low price, the comprehensive home control systems far below the price of such EIB systems permits, plays a crucial role. This modul is based on [http://culfw.de CULFW by Rudolf Koenig] and supports a wide range of protocols: * FS20: send/receive<br>There are numerous FS20 devices, all of them are fully supported. * FHT: send/receive<br>Communication to the FHT80b is supported. * S300: receive<br>Examples of such devices: S300TH, KS300-2 * EM1000: receive<br>Devices: EM1000FM, EM1000GZ, EM1000WZ * HMS: receive<br>Devices: There are numerous HMS devices, all of them are fully supported. * ESA2000: receive * Lacrosse TX2/TX3: receive == Connection == The RFM12 is connected to the AVR like in [[RFM12_FSK#Connection|FSK Mode]] with a small difference. The output FSK/DATA/nFSS signal (Pin 3) is connected to one of the INT pins of the AVR. This modul does not work in interrupt mode, so the output nRQ signal (Pin 2) can be left unconnected. The software uses the digital filter of the RFM12. To improve sensitivity on short and long distances the [http://jeelabs.net/projects/cafe/wiki/Receiving_OOKASK_with_a_modified_RFM12B C_arssi capacitor needs to be replaced] with a value of 150 pF. The SPI connection is pretty fixed and does not need special pinnings. For the chip select (CS) of the modul and the optional LEDs the pinning must be defined. /* port the rfm12 module CS is attached to */ pin(SPI_CS_RFM12_0, PB0, OUTPUT) /* port the LEDS for rfm12 tx/rx attached to */ pin(STATUSLED_RFM12_TX, PB3, OUTPUT) pin(STATUSLED_RFM12_RX, PB1, OUTPUT) RFM12_FS20_USE_INT(1) If more than one RFM12 are used with Ethersex, the number in SPI_CS_RFM12_0 defines the number of the module. Each needs its own pinning. The RFM12_FS20_USE_INT defines whether FSK/DATA/nFSS is connected to INT0, INT1 or INT2 of the AVR. == Configuration == The FS20 system sends on 868,35 MHz, so the 868MHz option is the right one. | | I/O ---> | | ... | | Radio ---> | | ... | | [*] RFM12 ASK ---> | | ... | | [*] 868MHz | | | | (0) RFM12 select | | | | Protocols ---> | | ... | | Radio ---> | | ... | | [*] FS20 (868MHz) ---> | | ... | | (RFM12) Transmitter/receiver hardware | | | | [*] FS20 Send | | | | [*] FS20 Receive | | | | [*] FHT | | | | [ ] ESA | | | | [ ] TX3 | | | | [ ] Send received data via syslog | | | | --- Debugging Flags | | | | [ ] FS20 | | The modul uses Timer 2 of the AVR '''exclusively'''. Currently there is no option to use Timer 1, but this will change in the future. == [[ECMD]] == RFM12 FS20 implements an [[ECMD]] interface for send and receive FS20/FHT commands. The received data is formatted as described in the [http://culfw.de/commandref.html#protocol2 CULFW reference]. See [[ECMD_Reference|ECMD reference]] for a command list. == Troubleshooting == It may happen that not all of the RFM12 FS20 sensors are received. Here are some points that may help to improve reception: * Location: ** Avoid RF transmitter near the RFM12 ** Choose a position in the center of the sensors * Antenna: ** It is recommended to choose an antenna with a length not shorter than Lamda/2 (17,3cm) * Bandwidth: Default 400kHz ** Can be changed via ECMD from 400kHz to 67kHz (rfm12 setbandwidth <modulnumber> 1-6) * Gain: Default -14dB ** Can be changed via ECMD from 0dB to -20dB (rfm12 setgain <modulnumber> 0-3) * DRSSI: Default -97dB ** Can be changed via ECMD from -103dB to -61dB (rfm12 setdrssi <modulnumber> 0-7) Checkout the RFM12 datasheet for details on bandwidth, gain and DRSSI. == Decoding received data == The received data is formatted as described in the [http://culfw.de/commandref.html#protocol2 CULFW reference]. One could use the perl scripts from [http://culfw.de/ CULFW] to decode the data. [[Category:RFM12]] cd8bf8496a4a4f75b532090e09c4b46297e6a3af 0 311 1804 1087 2017-11-16T15:54:14Z GooPie4o 265 wikitext text/x-wiki {{i18n|RFM12 FS20}} {{Module |NAME=RFM12 FS20 |MENUCONFIG={{I/O}}->Radio->RFM12 ASK->868MHz |STATUS={{Stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] [[RFM12 ASK]] |REQUIRES= - |TIMER={{occupies_timer|2}} (RX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12 https://github.com/ethersex/ethersex/tree/master/hardware/radio/rfm12] }} Das FS20- / FHT-System von ELV ist derzeit das wohl erfolgreichste Funk-Haussteuerungssystem im Niedrigpreissektor. Dies ergibt sich aus der Vielzahl von Komponenten und der ständigen Erweiterung des Systems. Aber auch der relativ günstige Preis, der umfangreiche Haussteuerungen weit unter dem Preis von z.B. EIB-Systemen zulässt, spielt eine entscheidende Rolle. Das Modul basiert auf [http://culfw.de CULFW von Rudolf Koenig] und unterstützt folgende Protokolle: * FS20: senden/empfangen<br>Es gibt eine Vielzahl von FS20 Geräten, die alle unterstützt werden. * FHT: senden/empfangen<br>Die Kommunikation mit FHT80b wird unterstützt. * S300: empfangen<br>Beispiele dieser Geräte: S300TH, KS300-2 * EM1000: empfangen<br>Geräte: EM1000FM, EM1000GZ, EM1000WZ * HMS: empfangen<br>Es gibt eine Vielzahl von HMS Geräten, die alle unterstützt werden. * ESA2000: empfangen * Lacrosse TX2/TX3: empfangen [[Category:RFM12]] 807d68586055376fe22835b9422a0d891725c39f 0 169 1805 1729 2017-12-17T18:15:36Z TheSmartGerman 728 /* Linux Debian / Ubuntu */ wikitext text/x-wiki {{i18n|Quick Start Guide/Preparation}} = Requirements = * Native GCC-Compiler (for the lxdialog utility required by make menuconfig) * AVR GCC-Compiler >= 4.7 * AVR LIBC >= 1.8 * AVR Binutils >= 2.22 * GNU-Tools (Bash, Make, m4, awk) * AVR-Programmer (e.g. avrdude) <s>'''Attention:''' binutils ''2.22'' has a bug that causes the compilation of ethersex to fail. Install version 2.21 until [http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52692 GCC 4.7.1 has been released].</s> == Linux Debian / Ubuntu == apt-get install gcc gcc-avr avr-libc binutils-avr m4 gawk libncurses5-dev make dialog git-core avrdude == Arch Linux == pacman -Sy m4 avr-binutils avr-libc avrdude avr-gcc git gawk ncurses make perl == FreeBSD == add gmake avr-binutils avr-gcc avr-libc (to compile) add gsed m4 gawk (need for ethersex), add avrdude git use add_page -r PKG-NAME or use ports (goggle freebsd ports install) == Mac OS X == Before compiling Ethersex on Mac OS X additional software packages need to be installed. [http://www.macports.org MacPorts] are used for that. In case MacPorts are outdated, there is a [http://www.heise.de/ct/projekte/machmit/ctbot/wiki/AVRToolchain guide] for building the AVR toolchain manually. Using MacPorts is easier and faster. Who already programmed and flashed an Atmel AVR has a proper working environment. Else the packages for programming an AVR need to be installed: sudo port install avr-binutils avr-gcc avr-libc avrdude For newbies it is recommended to connect a LED and have that flashing by the AVR before jumping into the Ethersex adventure. Who already uses git, can skip the next step: sudo port install git-core Now install the software packages that are required by Ethersex: sudo port install bash gsed gawk dialog = Download the Source from GitHub = You can download Ethersex from github via git protocol git clone git://github.com/ethersex/ethersex.git or via http git clone http://github.com/ethersex/ethersex.git Updating a local version of ethersex is possible with: git pull origin [[Quick_Start_Guide/Configuration | next step]] d6175597def2e79eec1e31d89b9a5a1b870d26bf 0 374 1806 1707 2017-12-17T18:15:48Z TheSmartGerman 728 /* Linux Debian / Ubuntu */ wikitext text/x-wiki {{i18n|Quick Start Guide/Preparation}} = Voraussetzungen = * AVR GCC-Compiler >= 4.7 * AVR LIBC >= 1.8 * AVR Binutils >= 2.22 * GNU-Tools (Bash, Make, m4, awk) * AVR-Programmier Werkzeug (z.B.: avrdude) <s>'''Achtung:''' binutils ''2.22'' hat einen Fehler, der das Übersetzen von Ethersex abbricht. Installiere Version 2.21 bis [http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52692 GCC 4.7.1] verfügbar ist.</s> == Linux Debian / Ubuntu == apt-get install gcc gcc-avr avr-libc binutils-avr m4 gawk libncurses5-dev make dialog git-core avrdude == Arch Linux == pacman -Sy m4 avr-binutils avr-libc avrdude avr-gcc git gawk ncurses make perl == FreeBSD == add gmake avr-binutils avr-gcc avr-libc (to compile) add gsed m4 gawk (need for ethersex), add avrdude git use add_page -r PKG-NAME or use ports (goggle freebsd ports install) == Mac OS X == Zum Einsatz von Ethersex müssen auf Mac OS X noch Softwarepakete installiert werden. Dazu wird [http://www.macports.org MacPorts] benutzt. Sollten die Softwarepakete von MacPorts nicht aktuell sein, gibt es eine [http://www.heise.de/ct/projekte/machmit/ctbot/wiki/AVRToolchain Anleitung], die Arbeitsumgebung für AVR manuell zu bauen. Die Nutzung von MacPorts ist einfacher und führt schneller zum Ziel. Wer schon einen Atmel AVR programmiert und geflasht hat, besitzt bereits eine funktionierende Arbeitsumgebung. Wenn nicht, müssen zuerst die Softwarepakete zur Programmierung eines AVR installiert werden: sudo port install avr-binutils avr-gcc avr-libc avrdude Für Neueinsteiger wird als Fingerübung empfohlen, eine LED auf dem AVR zum Blinken zu bringen, bevor man sich in das Ethersex Abenteuer stürzt. Wer bereits git nutzt, kann den nächsten Schritt überspringen: sudo port install git-core Es folgen die Softwarepakete, die von Ethersex benötigt werden: sudo port install bash gsed gawk dialog = Sourcen von GitHub holen= Entweder mit git clone git://github.com/ethersex/ethersex.git oder via http git clone http://github.com/ethersex/ethersex.git Die lokale Version von Ethersex wird aktualisiert mit: git pull origin [[Quick_Start_Guide/Configuration | Nächster Schritt]] 0e994a62d8c67fe973ea6dc4a765041098ff2c3a 1807 1806 2017-12-17T18:19:18Z TheSmartGerman 728 /* Voraussetzungen */ wikitext text/x-wiki {{i18n|Quick Start Guide/Preparation}} = Voraussetzungen = * GCC-Compiler (GCC wird benötigt um die Dialog des menuconfig zu erstellen) * AVR GCC-Compiler >= 4.7 * AVR LIBC >= 1.8 * AVR Binutils >= 2.22 * GNU-Tools (Bash, Make, m4, awk) * AVR-Programmier Werkzeug (z.B.: avrdude) <s>'''Achtung:''' binutils ''2.22'' hat einen Fehler, der das Übersetzen von Ethersex abbricht. Installiere Version 2.21 bis [http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52692 GCC 4.7.1] verfügbar ist.</s> == Linux Debian / Ubuntu == apt-get install gcc gcc-avr avr-libc binutils-avr m4 gawk libncurses5-dev make dialog git-core avrdude == Arch Linux == pacman -Sy m4 avr-binutils avr-libc avrdude avr-gcc git gawk ncurses make perl == FreeBSD == add gmake avr-binutils avr-gcc avr-libc (to compile) add gsed m4 gawk (need for ethersex), add avrdude git use add_page -r PKG-NAME or use ports (goggle freebsd ports install) == Mac OS X == Zum Einsatz von Ethersex müssen auf Mac OS X noch Softwarepakete installiert werden. Dazu wird [http://www.macports.org MacPorts] benutzt. Sollten die Softwarepakete von MacPorts nicht aktuell sein, gibt es eine [http://www.heise.de/ct/projekte/machmit/ctbot/wiki/AVRToolchain Anleitung], die Arbeitsumgebung für AVR manuell zu bauen. Die Nutzung von MacPorts ist einfacher und führt schneller zum Ziel. Wer schon einen Atmel AVR programmiert und geflasht hat, besitzt bereits eine funktionierende Arbeitsumgebung. Wenn nicht, müssen zuerst die Softwarepakete zur Programmierung eines AVR installiert werden: sudo port install avr-binutils avr-gcc avr-libc avrdude Für Neueinsteiger wird als Fingerübung empfohlen, eine LED auf dem AVR zum Blinken zu bringen, bevor man sich in das Ethersex Abenteuer stürzt. Wer bereits git nutzt, kann den nächsten Schritt überspringen: sudo port install git-core Es folgen die Softwarepakete, die von Ethersex benötigt werden: sudo port install bash gsed gawk dialog = Sourcen von GitHub holen= Entweder mit git clone git://github.com/ethersex/ethersex.git oder via http git clone http://github.com/ethersex/ethersex.git Die lokale Version von Ethersex wird aktualisiert mit: git pull origin [[Quick_Start_Guide/Configuration | Nächster Schritt]] 3a74276d3619d456414826b9a71e756402c94912 8 313 1810 1225 2018-02-25T14:33:34Z Djmaster 255 wikitext text/x-wiki * * navigation ** mainpage|mainpage-description ** https://github.com/ethersex/ethersex|Sourcecode ** https://github.com/ethersex/ethersex/issues/new|Report a Bug ** currentevents-url|currentevents ** recentchanges-url|recentchanges ** randompage-url|randompage ** helppage|help * SEARCH * TOOLBOX * LANGUAGES 93d07d2e73c1fec80835de7c5225fc3ed51a5571 10 2 1811 31 2018-02-25T14:58:36Z Djmaster 255 wikitext text/x-wiki <noinclude>{{Template}} {{DISPLAYTITLE:Template:i18n}} '''An 'i18n' box used to display inter-language links. See [[Help:i18n]].''' ====Usage==== This template should be added at the beginning of every article (ideally below category markers but above any other content). <pre>{{i18n|Template:i18n}}</pre> The argument should be modified to match the English title of the article (i.e. without any language tag). Inter-language links are sorted alphabetically via JavaScript; see the language table ([[Help:i18n#Languages]]) and [[Wikipedia:Help:Sorting]] for details. If you want to contribute some translations in a language not listed in the box, feel free to contact us! ====Example==== {{i18n|Template:i18n}}</noinclude><includeonly><div class="toc noprint" style="width:100%; text-align: center; margin-bottom: 1em"> '''[[Help:i18n|Language]]''' ---- [[{{{2|{{{1}}}}}}|English]]&nbsp;&ndash; <!-- English is special --> {{Lang|{{{1}}}|Deutsch}} {{Lang|{{{1}}}|Nederlands}} {{Lang|{{{1}}}|Français}} {{Lang|{{{1}}}|Español}} [[{{{1}}} (Italiano)|Italiano]]<!-- last entry is special (don't display trailing dash) --> </div></includeonly> 662835cf85fe514b5e2c78b64dd0929dada0db43 0 43 1812 1737 2018-03-12T20:34:23Z Djmaster 255 wikitext text/x-wiki <div class="errorbox"> This page is automatically generated from the files in the Ethersex source code repository. Do not edit this page but send [[patches]] for those files! </div> __NOTOC__ == Bluetooth SPP Module ([[Bluetooth]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | bt cmd | send an AT command |- | bt stats | report statistics counter |- |} == DNS Resolver == {| border='1' | ''Command syntax'' | ''Short description'' |- | dns server [IPADDR] | Display/Set the IP address of the DNS server to use to IPADDR. |- | nslookup HOSTNAME | Do DNS lookup for HOSTNAME (call twice). |- |} == Digital/Analog Conversion ([[DAC]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ltc1257_delay `[VALUE] | Set (if VALUE given) or get (no VALUE) delay for LTC1257 output bit changes in µs' |- | ltc1257_set `[VALUE0] [VALUE1] ... | Set output to value (value: 0-4095)' |- | tlc5620 `[CHANNEL] [VALUE] | Set Output to value (Value: 0-0xff)' |- |} == Fnordlicht == {| border='1' | ''Command syntax'' | ''Short description'' |- | fnordlicht "ADDRESS RED | GREEN,BLUE",fnordlicht command to set RGB color |- | fnordlicht_init | fnordlicht init |- |} == HD44780 [[LCD]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | hr20 hourbar START STOP | Update hourbar to show ticks between START and STOP (range 0..23) |- | hr20 toggle SEG | Toggle segment SEG (a number, not a symbolic name!) |- | lcd backlight [STATE] | get or set the state of the lcd backlight |- | lcd char N D1 D2 D3 D4 D5 D6 D7 D8 | Define use-definable char N with data D1..D8 (provide DATA in hex) |- | lcd clear [LINE] | Clear line LINE (0..3) or the whole display (if parameter is omitted) |- | lcd goto LINE COL | Move cursor to LINE and column COL (origin is 0/0) |- | lcd print charset FROM TO | Print char FROM up to char TO |- | lcd reinit CURSOR BLINK | Reinitialize the display, set whether to show the cursor (CURSOR, 0 or 1) and whether the cursor shall BLINK |- | lcd shift DIR | Shift the display to DIR (either ''left'' or ''right'') |- | lcd write TEXT | Write TEXT to the current cursor location |- |} == Infrared Send/Receive ([[IRMP]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | irmp receive | receive an IR command |- | irmp send PROTOCOL DEVICE COMMAND REPEAT | send COMMAND with REPEAT flag to DEVICE using PROTOCOL |- |} == Infrared Send/Receive ([[RC5]]) == {| border='1' | ''Command syntax'' | ''Short description'' |- | ir receive | receive an IR command |- | ir send DEVICE COMMAND | send COMMAND to DEVICE |- |} == Miscellaneous == {| border='1' | ''Command syntax'' | ''Short description'' |- | periodic adjust OFFSET | Adjust periodic timers TOP value by adding OFFSET ticks. |- | periodic reset | Reset debug statistics for periodic module. |- | periodic stats | Print debug statistics for periodic module. |- |} == NTP Client == {| border='1' | ''Command syntax'' | ''Short description'' |- | ntp query | Query the NTP server to get an NTP update. |- | ntp server [IPADDR] | Display/Set the IP address of the NTP server to use to IPADDR. |- | ntp status | Display NTP server status |- |} == Network configuration == {| border='1' | ''Command syntax'' | ''Short description'' |- | enc dump | Dump the internal state of the enc to serial |- | gw [IP] | Display/Set the address of the default router. |- | ip [IP] | Display/Set the IP address. |- | mac [xx:xx:xx:xx:xx:xx] | Display/Set the MAC address. |- | netmask [IP] | Display/Set the network mask. |- |} == Port I/O == {| border='1' | ''Command syntax'' | ''Short description'' |- | io get ddr PORTNUM | Display the current value of the DDR PORTNUM. |- | io get mask PORTNUM | Display the mask of the port PORTNUM. |- | io get pin PORTNUM | Display the current value of the PIN-register of the port PORTNUM. |- | io get port NUM | Display the current value of the PORT NUM. |- | io set ddr PORTNUM HEXVALUE [MASK] | Set the DDR of port PORTNUM to VALUE (possibly using the provided MASK). |- | io set port NUM HEXVALUE [MASK] | Set the PORT NUM to VALUE (possibly using the provided MASK). |- |} == Reading and Writing EEPROM Space on Device == {| border='1' | ''Command syntax'' | ''Short description'' |- | eer eer <ADDR> <LENGTH> | Read n bytes from address after the config in eeprom. |- | eew eew <ADDR> <HEXBYTES> | Write Hexbytes at address after the config in epprom. |- | hostname | Display hostname. |- |} == Resetting the controller == {| border='1' | ''Command syntax'' | ''Short description'' |- | bootloader | Call the bootloader. |- | reset | Reset the Ethersex. |- | wdreset | Go into endless loop to trigger a watchdog timeout. |- |} == [[ADS]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | ads get | Get the ADC value in hex. |- | ads mean [COUNT] | Get the mean of power of 2 COUNT ADC values in hex. |- | fuse | Display current fuse settings |- |} == [[ASK]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | ask 1527 HOUSECODE COMMAND DELAY CNT | |- | ask 2272 HOUSECODE COMMAND [DELAY] [CNT] [SYNC] | |- | ask fa20rf DEVICE [REPEAT] | |- | ask intertechno FAMILY GROUP DEVICE COMMAND | "Send Command to Intertechno switches (with coding wheel). FAMILY: A=1, ..." |- | ask itsl HOUSECODE COMMAND BUTTON [DIM] | "Send Command to Intertechno Self learning switches and dimmers. DIM works only with dimmers and values 0-15." |- | ask oase FAMILY GROUP DEVICE COMMAND | |- | ask tevion HOUSECODE COMMAND DELAY CNT | |- |} == [[Am_Puls_der_Zeit|Clock]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | date | Print the current date. |- | lastdcf | Print when last valid DCF signal was received. |- | time [UNIXTIME] | Display/Set the current time in seconds since January 1st 1970. |- | uptime | Display ethersex uptime in unix format. |- | whm | Display ethersex uptime. |- |} == [[Application_Sample]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sample | Manually call application sample commands |- | sample_init | Manually call application sample init method |- | sample_periodic | Manually call application sample periodic method |- |} == [[BSBPORT]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | bsbport get P1 P2 P3 P4 SRC TYPE | Show specific message currently in buffer format value as TYPE type is one of RAW STA TMP FP1 FP5 |- | bsbport list | List all messages currently in buffer output in RAW TMP FP1 FP5 |- | bsbport query P1 P2 P3 P4 [DEST] | Send Message to query for a value DEST is optional defaults to 0 |- | bsbport set P1 P2 P3 P4 DEST TYPE VALUE | Send Message to set value type is one of RAW SEL TMP FP1 FP5 |- | bsbport stats | Report statistic counters OK/CRC/Lenght under/Lenght over/Droped/Buffer/BufferNet/Retransmit |- |} == [[Blinkenlights_MCUF|MCUF]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | mcuf modul N | Select module N |- | mcuf modul list | List all modules |- | mcuf showclock | Show digital clock |- | mcuf showstring MESSAGE | Show scrolling MESSAGE on the display |- |} == [[CRC]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | adc get [CHANNEL] | Get the ADC value in hex of CHANNEL or if no channel set of all channels. |- | adc vget [CHANNEL] | Get the ADC value in volt of CHANNEL or if no channel set of all channels. |- | adc vref [VOLTAGE] | Get/Set ADC reference voltage calibration. |- | crc calc | "read the ethersex program code and calc a crc16 of it" |- | crc read | "read out the crc16 value at the end of the program space" |- | hr20 temp | Read HR20 temperature sensor. |- |} == [[CRON-Dienst]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | cron add MIN HOUR DAY MONTH DOW ECMD | Add ECMD to cron to be executed at given time |- | cron anacron POSITION [STATE] | show/set job anacron state |- | cron list | Show all cron entries |- | cron persistent POSITION [STATE] | show/set job persistance state |- | cron rm [POSITION] | Remove one cron entry |- | cron save | Saves all persistent jobs |- | cron utc POSITION [STATE] | show/set utc state |- |} == [[DALI]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dali cmd [TARGET] [COMMAND] [!][?] | "send the given command (decimal) to targets (all, g00 to g15, s00 to s63), auto repeat with !, read reply with ?" |- | dali dim [TARGET] [LEVEL] | "dim targets (all, g00 to g15, s00 to s63) to given level (0-254)" |- | dali raw [BYTE1] [BYTE2] | "send a raw frame (two bytes, given in hex) over the DALI bus" |- | dali scmd [SPECIAL COMMAND] [DATA] [!][?] | "send special command (256-287) with data, auto repeat with !, read reply with ?" |- |} == [[DHT]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dht humid [SENSORNUMBER] | Return humidity of DHT sensor |- | dht list | Return a list of mapped sensor names |- | dht temp [SENSORNUMBER] | Return temperature of DHT sensor |- |} == [[DMX_FXSlot]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx fxslot devices | set the device settings |- | dmx fxslot effect | set the effect settings |- | dmx fxslot reset | reset all fxslots and clear saved ones in EEPROM |- | dmx fxslot restore | restore the settings from EEPROM |- | dmx fxslot save | save the current fxslots to EEPROM |- |} == [[DMX_Storage]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | dmx channels | Get channels per universe |- | dmx get | Return channel value |- | dmx set | Set channel values |- | dmx universe | Get a whole universe |- | dmx universes | Get universes |- |} == [[Dallas_1-wire_Bus]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | 1w ds2450 convert [DEVICE] | `start conversion (with optional input mask and read out control)' |- | 1w ds2450 get [DEVICE] | `get conversion result (one or all channels)' |- | 1w ds2450 oc [DEVICE] | `get/set output control (per channel)' |- | 1w ds2450 oe [DEVICE] | `get/set output enable (per channel)' |- | 1w ds2450 por [DEVICE] | `get/set power on reset (per channel)' |- | 1w ds2450 power [DEVICE] | `get/set power supply of device (global)' |- | 1w ds2450 range [DEVICE] | `get/set input voltage range (per channel)' |- | 1w ds2450 res [DEVICE] | `get/set bit resolution of AD convert (per channel)' |- | 1w get DEVICE | Return temperature value of onewire device (provide 64-bit ID as 16-hex-digits) |- | 1w list | Return a list of the connected onewire devices |- | 1w name clear ID | Delete a name mapping |- | 1w name list | Return a list of mapped device names |- | 1w name save | Save name mappings to EEPROM |- | 1w name set ID DEVICE NAME | Assign a name to/from an device address |- |} == [[DataFlash]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | df status | Display internal status. |- | fs format | Format the filesystem. |- | fs inspect inode INODE | Inspect INODE (and associated page). |- | fs inspect node NODE | Inspect NODE and dump to serial. |- | fs list | List the directory. |- | fs mkfile NAME | Create a new file NAME. |- | fs remove NAME | Delete the file NAME. |- | fs truncate NAME LEN | Truncate the file NAME to LEN bytes. |- |} == [[Dc3840_camera|DC3840 mobil camera support]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dc3840 capture | Take a picture. Access 'dc3840' via VFS afterwards. See [[DC3840 Camera]] for details. |- | dc3840 light | Light level of camera |- | dc3840 send A B C D E | Send provided command bytes to the camera. |- | dc3840 sync | Re-sync to the camera |- | dc3840 zoom | Enable zoom of camera |- |} == [[ECMDScript]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | call FILENAME | Start script named FILENAME |- | cat FILENAME | cat file content (with debug only) |- | dec VAR | Decrement variable VAR (a number) |- | echo <any> | Print out all arguments of echo |- | exit | Exit currently running script |- | get VAR | Get value of variable VAR |- | goto N | Goto line N in currently running script |- | if ( CMD/VAR == CONST ) then CMD2 | If condition matches execute CMD2 |- | inc VAR | Increment variable VAR (a number) |- | rem <any> | Remark for anything |- | set VAR VALUE | Set variable VAR to VALUE |- | wait I | Wait I milliseconds |- |} == [[FS20]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fht send HOUSECODE ADDR CMD [CMD2] | Send FHT command. See [[FS20]] for details. |- | fs20 receive | Receive FS20/FHT sequence and display it. |- | fs20 send HOUSECODE ADDR CMD [CMD2] | Send FS20 command. See [[FS20]] for details. |- | fs20 ws300 | Receive FS20 sequence from WS300 weather station and decode it. |- |} == [[Frequency Counter]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fc %duty [CHANNEL] | "returns last on duty cycle in percent for given channel" |- | fc duty [CHANNEL] | "returns last on duty cycle (0-255) for given channel" |- | fc freq [CHANNEL] | "returns last frequency in Hz for given channel" |- | fc off [CHANNEL] | "switch off frequency counting on given channel" |- | fc on [CHANNEL] | "switch on frequency counting on given channel" |- | fc ticks [CHANNEL] | "returns last frequency in CPU ticks for given channel" |- |} == [[GLCD_Menu]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | glcdmenu key VALUE | Send a keypress to the menu |- | glcdmenu update | Update the menu |- |} == [[GPS]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | nmea get | Get latitude and longitude data |- | nmea satellites | Get satellites |- |} == [[H-Bridge]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | hbridge [action] [enable_l] [enable_r] | Set H-Bridge command |- | hbridge pwm int | Set H-Bridge enable line valueeg. speed |- |} == [[I2C]] (TWI) == {| border='1' | ''Command syntax'' | ''Short description'' |- | bmp085 apress | Get absolute pressure in Pa |- | bmp085 height PRESSNN | Get height in cm, pressure at N0 needed |- | bmp085 pressnn HEIGHT | Get pressure at N0, height in cm needed |- | bmp085 temp | Get temperature in 0.1°C |- | ds1631 convert ADDR VALUE | Initiate temperature conversions (0: stop, 1: convert) |- | ds1631 temp ADDR | Read last converted temperature |- | ee dir | List files in I2C EEPROM. |- | ee rm PATH | Remove file PATH. |- | i2c detect | list detected I2C Chips |- | i2c pca9555 in | read word from register address on I2C chip |- | i2c pca9555 mode VALUE | select input or output mode for pins on I2C chip |- | i2c pca9555 out VALUE | write word to register address on I2C chip |- | i2c rbb ADDR | read byte from I2C chip |- | i2c rbd CHIPADDR REGADDR | read byte from register address at I2C chip |- | i2c rwd CHIPADDR REGADDR | read word from register address at I2C chip |- | i2c wbb ADDR HEXVALUE | write byte to I2C chip |- | i2c wbd CHIPADDR REGADDR HEXVALUE | write byte to register address on I2C chip |- | i2c wwd CHIPADDR REGADDR HEXVALUE | write word to register address on I2C chip |- | lm75 ADDR | Get temperature |- | max7311 getDDRw ADDR | Get Direction-Register DDR |- | max7311 getINw ADDR | Get Input-Register IN |- | max7311 getOUTw ADDR | Get Output-Register OUT |- | max7311 pulse ADDR BIT TIME | Toggle Output-BIT for TIME (in ms) |- | max7311 set ADDR BIT VALUE | Set Output-BIT to VALUE (bool) |- | max7311 setDDRw ADDR VALUE | Set Direction-Register DDR (VALUE as hex) |- | max7311 setOUTw ADDR VALUE | Set Output-Register OUT (VALUE as hex) |- | mcp23017 clear pin ADDR PORT BIT | Clear Port BIT for PORT A or B |- | mcp23017 get iodir ADDR PORT | Get I/O Direction Register for PORT A or B |- | mcp23017 get olat ADDR PORT | Get Output Latch Register for PORT A or B |- | mcp23017 get port ADDR PORT | Get Port Register (i.e. Port Pin State) for PORT A or B |- | mcp23017 getreg ADDR REGADDR | Get Register REGADDR |- | mcp23017 pulse pin ADDR PORT BIT TIME | Toggle-Pulse Port BIT for PORT A or B for TIME ms |- | mcp23017 set iodir ADDR PORT VALUE | Set I/O Direction Register for PORT A or B (VALUE as hex) |- | mcp23017 set olat ADDR PORT VALUE | Set Output Latch Register for PORT A or B (VALUE as hex) |- | mcp23017 set pin ADDR PORT BIT | Set Port BIT for PORT A or B |- | mcp23017 setreg ADDR REGADDR VALUE | Set Register REGADDR (VALUE as hex) |- | mcp23017 toggle pin ADDR PORT BIT | Toggle Port BIT for PORT A or B |- | pca9531 ADDR PERIODPWM1 DUTYPWM1 PERIODPWM2 DUTYPWM2 LED0..3 LED4..7 | set PWM1 and PWM2 and LED states |- | pcf8574x read ADDR CHIP | Get bits |- | pcf8574x set ADDR CHIP HEXVALUE | Set bits |- | tmp175 ADDR | Get temperature |- | tsl2550 lux | Show light level by reading adc registers and computing level |- | tsl2550 mode VALUE | Set the TSL2550s operating mode (0: standard range, 1: extended range) |- | tsl2550 power VALUE | Set the TSL2550s power state (0: down, 1:up) |- | tsl2561 lux DEVNUM | Get LUX value |- | tsl2561 raw DEVNUM | Get RAW channel values |- | tsl2561 setmode DEVNUM TIME GAIN PACKAGE | Set device mode |- |} == [[Jabber]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | jabber_host [HOSTNAME] | JABBER hostname |- | jabber_pass [PASSWORD] | JABBER password |- | jabber_resrc [RESOURCE] | JABBER resource |- | jabber_user [USERNAME] | JABBER username |- |} == [[KTY]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | kty autocalibrate CHANNEL | Calibrate to 1000 Ohm precision Resistor. |- | kty cal get | Return the calibration difference to 2k2 Resistor. |- | kty get [CHANNEL] | Get the temperature in xxx.x °C of CHANNEL or if no channel set of all channels. |- |} == [[MotorCurtain]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | curtain VALUE | Set value of curtain. 0=closed..7=open. If you use fewer sensors, use the corrent value instead of 7. |- | curtainlast | Return last known position |- | curtainmax | Return maximum position |- | curtainoff | Switch motor off |- |} == [[Named_PIN]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | pin get NAME | Read and display the status of pin NAME. |- | pin list | List all known named-pins. |- | pin set NAME STATUS | Set the status of pin NAME to STATUS. |- | pin toggle NAME | Toggle the status of pin NAME. |- |} == [[PWM]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | dtmf CHARS | send CHARS as DTMF |- | freq set FREQUENCY DELAY | Set frequency for DELAY ms |- | pwm fade [channel +-diff startvalue] | Set fading at channel with startvalue and change each stepp to diff (must be signed 3 digit) |- | pwm set [channel value] | Set channel to value |- |} == [[RFM12]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | rfm12 reinit | Re-initialize the RFM12 FSK module. |- | rfm12 setbandwidth MODULE BW | Set receiver bandwidth of MODULE to BW. |- | rfm12 setbaud MODULE BAUD | Set baudrate of MODULE to BAUD. |- | rfm12 setdrssi MODULE DRSSI | Set the drssi of MODULE to DRSSI. |- | rfm12 setgain MODULE GAIN | Set preamplifier gain of MODULE to GAIN. |- | rfm12 setmod MOD | Set modulation of the RFM12 FSK module to MOD. |- | rfm12 status MODULE | Display internal status of MODULE. |- |} == [[RFM12_ASK]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | rfm12 ask sense | Trigger (Tevion) ASK sensing. Enable ext. filter pin before! |- | rfm12 external filter [1] | Enable ext. filter pin if argument is present (disable otherwise) |- |} == [[RFM12_FS20]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | fht send | housecode addr command data |- | fs20 receive | Receive FS20/FHT sequence and display it. |- | fs20 send | housecode addr command data |- | fs20 setdebug DEBUG | Set debug to DEBUG. |- |} == [[SD-Karte]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sd dir | List contents of current SD directory. |- | sd info | List information about SD card. |- | sd mkdir PATH | Create directory hierarchy PATH. |- | sd rm PATH | Remove file PATH. |- |} == [[SGC]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | sgc adduc ADDR CH0 CH1 CH2 CH3 CH4 CH5 CH6 CH7 | Add user character: address 0..0x1F and 8 bytes character |- | sgc circle X Y RADIUS | Draw circle with parameters and colour specified in sgc_colour |- | sgc cls | Clear screen |- | sgc colour RED GREEN BLUE | Set pen / font colour:red-green-blue 0..0x1F or 2-byte RGB with only two parameters |- | sgc contrast CONTRAST | Set contrast value 0..0x0F |- | sgc druc ADDR X Y | Draw user character saved from sgc_adduc at address 0..0x1F and with colour specified in sgc_colour |- | sgc font FONT PROPORTIONAL | Set font type:0..2 and 0:not proportional 1:proportional |- | sgc gchar X Y WIDTH HEIGHT CHAR | Draw ASCII character in graphics format at specified position and size with colour specified in sgc_colour |- | sgc getpwr | Get Power Status |- | sgc line X1 Y1 X2 Y2 | Draw line between specified points with colour specified in sgc_colour |- | sgc object UMSB ULSB LMSB LLSB | Display object from SD card at specified address |- | sgc onoff ONOFF | Turn display on:1 or off:0 |- | sgc opacity OPACITY | Set text opacity 0:transparent 1:opaque |- | sgc pensize PENSIZE | Set pen size 0:solid 1:lines |- | sgc pixel X Y | Draw pixel at specified point with colour specified in sgc_colour |- | sgc rectangle X1 Y1 X2 Y2 | Draw rectangle with specified edges and with colour specified in sgc_colour |- | sgc repbgc RED GREEN BLUE | Replace background colour:red-green-blue 0..0x1F or 2-byte RGB with only two parameters |- | sgc repcol X_START Y_START X_END Y_END OLD_RED OLD_GREEN OLD_BLUE | Replace old colour - red-green-blue 0..0x1F or 2-byte RGB with only two parameters in selected area - with colour specified in sgc_colour |- | sgc result | Get result from last command |- | sgc scrcp SRC_X SRC_Y DST_X DST_Y WIDTH HEIGHT | Copy-Paste selected screen area |- | sgc script UMSB ULSB LMSB LLSB | Run 4DSL script from SD card at specified address |- | sgc sdicon X Y WIDTH HEIGHT SECTOR0 SECTOR1 SECTOR2 | Display icon from SD card at specified position and size stored at specified SD card sector |- | sgc setbgc RED GREEN BLUE | Set background colour:red-green-blue 0..0x1F or 2-byte RGB with only two parameters |- | sgc setip IPADDR | Change response IP address - volatile |- | sgc setpwr PWR | Set Power Status: 1:on 0:off |- | sgc setsleep AUTO MODE | Set Auto Shutdown Sleep 1:on 0:off / Set wakeup mode 0:Serial 1: Joystick |- | sgc settimeout TIMEOUT | Change auto-off idle time - volatile |- | sgc sleep SLEEP | Sleep mode 0:turn off SD 1:wake on serial 2:wake on joystick |- | sgc stg X Y WIDTH HEIGHT STRING | Draw ASCII string in graphics format at specified position and size with colour specified in sgc_colour) |- | sgc stt COL ROW STRING | Draw ASCII string in text format at specified col and row and with colour specified in sgc_colour |- | sgc tchar COL ROW CHAR | Draw ASCII character in text format at specified col and row and with colour specified in sgc_colour |- | sgc triangle X1 Y1 X2 Y2 X3 Y3 | Draw triangle with edges counter-clockwise and with colour specified in sgc_colour |- | sgc video X Y WIDTH HEIGHT DELAY NUM_FRAMES0 NUM_FRAMES1 SECTOR0 SECTOR1 SECTOR2 | Display video / animation from SD card at specified position and size and with specified inter-frame delay and frame number stored at specified SD card sector |- |} == [[SHT]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sht humid | Return humidity of SHT sensor |- | sht raw | Return raw hex temp (first line) and humidity value (second line) of SHT sensor |- | sht temp | Return temperature of SHT sensor |- |} == [[SMS77]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | sms77 MESSAGE | Send MESSAGE to compiled in sms77 service |- | sms77_pass [PASSWORD] | SMS77 password |- | sms77_recv [RECEIVER] | SMS receiver |- | sms77_type [TYPE] | SMS type |- | sms77_user [USERNAME] | SMS77 username |- |} == [[Servo_Ansteuerung|PWM Servo Control]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | pwm servo_dec SERVONR | Decrement position of servo SERVONR |- | pwm servo_inc SERVONR | Increment position of servo SERVONR |- | pwm servo_set SERVONR POSITION | Set servo with SERVONR to POSITION |- |} == [[Sound]]/WAV support == {| border='1' | ''Command syntax'' | ''Short description'' |- | pwm stop | Stop wav |- | pwm wav <FILENAME> | Play wave file. Use VFS if compiled in. More details at [[Sound]] |- |} == [[Stella_Light]] commands == {| border='1' | ''Command syntax'' | ''Short description'' |- | channel CHANNEL VALUE FUNCTION | Get/Set stella channel to value. Second and third parameters are optional. Function: You may use 's' for instant set, 'f' for fade and 'y' for flashy fade. |- | channels | Return stella channel size |- | fadestep FADESTEP | Get/Set stella fade step |- | stella load | Load values from eeprom |- | stella store | Store values in eeprom |- | tank get | get last value |- | tank param save | write tank parameter to EEPROM |- | tank param set PARAM VALUE | set tank parameter |- | tank param show | show tanklevel parameters |- | tank start | start measure |- | tank zero | probe sensor zero offset |- |} == [[USB]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | keyboard MESSAGE | Send MESSAGE as HID keyboard |- | mouse BUTTON DELTAX DELTAY | Send data as HID mouse |- |} == [[ZACwire]] == {| border='1' | ''Command syntax'' | ''Short description'' |- | zac 306 PORT BIT | Return temperature of TSic 306 at BIT of PORT |- | zac 506 PORT BIT | Return temperature of TSic 506 at BIT of PORT |- | zac raw PORT BIT | Return raw hex temperature value of zacwire at BIT of PORT |- |} == lome6 == {| border='1' | ''Command syntax'' | ''Short description'' |- | lome6 get_t TYPE | get temperature command |- | lome6 power TYPE | press power command |- | lome6 reset | press reset command |- | lome6 set_t TYPE TEMPERATURE | set temperature command |- | lome6 state | get state command |- | lome6 uptime UPTIME | set/get uptime command |- |} == Miscelleanous == {| border='1' | ''Command syntax'' | ''Short description'' |- | alias list | List all available aliases |- | artnet test | artnet test |- | cw send MESSAGE | Send MESSAGE in Morce Code |- | d ADDR | Dump the memory at ADDR (16 bytes). |- | eeprom reinit | Force reinitialization of the EEPROM config area |- | ems stats | Report statistic counters |- | free | Display free space. |- | help | List which commands are available. |- | ht MESSAGE | Send MESSAGE to compiled in httplog service |- | ipstats | Display IP statistics. |- | mb recv | Receive data from modbus |- | moodlight CHANNEL ONOFF | Set CHANNEL moodlight on=1 or off=0. If no channel is given return on if channel CHANNEL is moodlighted |- | motd [MESSAGE] | Save MESSAGE as new message of the day, otherwise just show current message |- | msr1 get | Get data |- | mysql query QUERY | Send specified MySQL query to the configured server |- | ns | update net statistic for public anouncment of currently running ethersex |- | pam USER PASSWORD | Use pam for user and password |- | push NUMBER | Push button identified by NUMBER |- | pwm melody [NUMBER] | Play melody |- | sanyoz700 CMD | Send command to projector |- | sll get | Request the logged data |- | sram memtest | Perform a memory test |- | srf05 | Read SRF05 measurement |- | to1 get | Request data from sensor |- | tw MESSAGE | Send MESSAGE to compiled in twitter service |- | upnp send | Manually send UPnP broadcast packet |- | usart baud BAUD | Set the USART baudrate to BAUD. |- | version | Display the version number. |- | weather | Get eltako weather data |- | wol MAC | Send WAKE-ON-LAN command to MAC |- | yport stats | Report statistic counters |- | zbus stats | Report statistic counters |- |} [[Category:Ethersex]] [[Category:ECMD]] 5808089bd6ab6accea95b639f70324f6a82f331a 3 495 1813 1709 2018-05-10T14:56:54Z Djmaster 255 wikitext text/x-wiki =Todo Liste= ==1== test *[[Temperaturmesssystem_(Deutsch)]] ** <s>webabfrage</s> ** <s>wdreset</s> ** <s>make clean && make</s> ** <s>Paar Bilder und tftpd win32</s> ** <s>ds1820 id herausbekommen</s> ** schaltung ds1820 4k7 ==2== *[[BOOTP_%28Deutsch%29]] ** <s>Links prüfen</s> ** <s>Bilder prüfen</s> ** <s>Text anpassen</s> ==3== *[[I2C_%28Deutsch%29]] **Levelshifter **Aufteilung =4== *ETHERNET LOADER??? old wiki *ENC28J60_(Deutsch) = LÖSCHEN?? ee27008d77c6d61aa903a92cc76ed39b1bae785d 2 329 1814 1711 2018-05-10T14:58:53Z Djmaster 255 wikitext text/x-wiki [[File:RJ45Buchse_Pinout.png|400px|thumb|RJ45 Buchse]] ==Person== test<br> Nick im IRC: djmaster oder djmaster2<br> Web: http://wiki.senseye.org/ ==Bauteile== Für [http://www.lochraster.org/etherrape/ Etherrape] Module {| | {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%;" |- ! Bauteil !! Hersteller !! HerstellerNr !! Lieferant !! Bestellnummer !! Dokumente !! Sonstiges |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/products/en?q=6605424-1 6605424-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154361/ 615-4361] || [http://www.te.com/catalog/pn/en/6605424-1?RQPN=6605424-1 Link] || Netzwerkbuchse ohne LED, Verriegelung Unten |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/pn/en/5-6605308-1 5-6605308-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154383/ 615-4383] || [http://www.te.com/catalog/pn/en/5-6605308-1?RQPN=5-6605308-1 Link] || Netzwerkbuchse mit LED, Verriegelung Unten |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/products/en?q=6605759-1 6605759-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154399/ 615-4399] || [http://www.te.com/catalog/pn/en/6605759-1?RQPN=6605759-1 Link] || Netzwerkbuchse ohne LED, Verriegelung Oben |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/products/en?q=5-6605758-1 5-6605758-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154412/ 615-4412] || [http://www.te.com/catalog/pn/en/5-6605758-1?RQPN=5-6605758-1 Link] || Netzwerkbuchse mit LED, Verriegelung Oben |- align="right" | Hutschienen Gehäuse || Axxatronic || [http://www.axxatronic.de/serie-cnmb.html CNMB-4-KIT-CON] || Conrad || [http://www.conrad.at/ce/de/product/531443/Axxatronic-Hutschienen-Gehaeuse-CNMB-4-KIT-CON-Polycarbonat-L-x-B-x-H-90-x-710-x-58-mm 531443 - 62] || [http://www.axxatronic.de/serie-cnmb.html Link] || (L x B x H) 90 x 71.0 x 58 mm |- align="right" | DS2450 || Maxim || [http://www.maximintegrated.com/datasheet/index.mvp/id/2921 DS2450] || RS-Components || [http://at.rs-online.com/web/p/products/07327557/ 732-7557] || [http://datasheets.maximintegrated.com/en/ds/DS2450.pdf Link] || Onewire quad AD Converter |- align="right" | HIH4000-001 || Honeywell || [http://sensing.honeywell.com/product%20page?pr_id=53944 HIH4000-001] || RS-Components || [http://at.rs-online.com/web/p/products/05283171/ 528-3171] || [http://sensing.honeywell.com/product%20page?pr_id=53944 Link] || Luftfeuchte Sensor von Honeywell |- align="right" | MPXH6115AC6U || Freescale || xx || RS-Components || [http://at.rs-online.com/web/p/products/07176536/ 717-6536] || [http://www.freescale.com/files/sensors/doc/data_sheet/MPXA6115A.pdf Link] || Luftdruck Sensor von Freescale |} ==Die Software== [[File:Ethersex det ssr.png|400px|thumb|die Theorie]] [[File:Hausbus v1.JPG|400px|thumb|die Praxis]] ===TFTP-Bootloader & Fuses=== Menuconfig: │ │ Load a Default Configuration ---> │ │ [*] Ethernet Bootloader │ │ Network ---> │ │ [*] Ethernet (ENC28J60) support ---> │ │ Etherrape IP address: "192.168.12.220" │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ Applications ---> │ │ [*] TFTP support ---> │ │ Bootloader configuration ---> │ │ [*] TFTP-o-matic │ │ --- TFTP-o-matic configuration │ │ TFTP IP address: "192.168.12.120" │ │ TFTP image to load: "ethersex.bin" make clean && make --> ethersex.hex =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 6064/65536 bytes (9.25%) [==----------------------------] Program (.text + .data) : 6064 bytes Data (.data + .bss) : 826 bytes =================================== sudo avrdude -cusbasp -pm644 -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m sudo avrdude -cusbasp -pm644 -U flash:w:ethersex.hex sudo avrdude -cusbasp -pm644 -U lock:w:0x0F:m Achtung bei den SMD Typen vom mega644, ich habe mega644P bekommen, wobei ich jetzt nicht weiß ob die SMD immer P Typen sind. Egal das Problem ist man sollte avrdude genau lesen und auch "-p m644p" anhängen da der P Type eine andere Signatur aufweist. Hat mich ne Stunde gekostet. ;) ==Bilder== ===Testsystem=== <gallery perrow=7> File:1_stella_all_off.jpg File:2_stella_all_on.jpg File:3_mosfets.jpg File:4_schaltung_fet.png File:IMG_5286.JPG File:IMG_6592.JPG File:IMG_6594.JPG File:S0-zaehler_img.JPG File:Esex sensor1.JPG </gallery><br> ==Probleme== 25.1.2011 - ethersex mit m644 und 32khz uhrenquarz.<br> datenblatt mega644 seite 101 - http://www.atmel.com/dyn/resources/prod_documents/doc2593.pdf<br> services/clock/clock.c - zeile 64<br> <obiflix> du könntest https://github.com/ethersex/ethersex/commit/da511f074940423e8e8ef7ee67ca20e6d91f608c rückgängig machen <obiflix> möglicherweise bekommst du dann probleme mit dcf77, falls du das nutzen möchtest, aber einen versuch ist es wert ;) Notiz: Hat funktioniert für den MEGA644<br> Update#1<br> 26.1.2011 - Problem sollte nun behoben sein, Danke an eku! master Erik Kunze * ae3ef98 (2 files in 1 dirs): use timer makros for prescaler 64 (32768Hz/256/64=2Hz) - http://bit.ly/eG2d4c --- DCF muss noch getestet werden ==Notizzettel== schnell mal notiert ein script zum email versenden wenn zb..PIN_LOW... <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include <util/delay.h> CONTROL_START CLOCK_USED() ECMD_GLOBAL(t1, 0, uint16_t); ECMD_GLOBAL(var1, 0); ECMD_GLOBAL(var2, 0); ECMD_GLOBAL(aqua_mail_sent, 0, uint8_t) THREAD(start) if (!PIN_HIGH(WTR)) t1++; else t1=0; if (t1 > 10) var1=1; else var1 = 0; if (t1 > 400) var2=1; else var2 = 0; if (var1 == 1) PIN_CLEAR(LED1); else PIN_SET(LED1); if (var2 == 1){ if (aqua_mail_sent == 0){ PIN_CLEAR(LED2); mail_send(); aqua_mail_sent = 1; } var2 = 0; }else{ PIN_SET(LED2); } THREAD_END(start) ON STARTUP DO THREAD_START(start) END CONTROL_END </source> ==Levelshifter 3.3V 5V== <gallery perrow=1> File:Levelshifter.png </gallery><br> Source: http://wiki.senseye.org/adir/levelshifter/levelshifter.sch 7af31dd78a84ed54c8d9eab9352daeb123761c15 1818 1814 2018-05-10T17:35:32Z Djmaster 255 wikitext text/x-wiki [[File:RJ45Buchse_Pinout.png|400px|thumb|RJ45 Buchse]] ==Person== Nick im IRC: djmaster oder djmaster2<br> Web: http://wiki.senseye.org/ == Wiki/Hoster Problem == Fehler im Browser Forbidden You don't have permission to access /index.php on this server. Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request. -->Support--> We have whitelisted the ModSecurity rule triggered for ethersex.de. ==Bauteile== Für [http://www.lochraster.org/etherrape/ Etherrape] Module {| | {|cellpadding="4" cellspacing="0" style="margin-top:5px; background:#EEEEEE; border:1px #aaa solid; font-size:95%;" |- ! Bauteil !! Hersteller !! HerstellerNr !! Lieferant !! Bestellnummer !! Dokumente !! Sonstiges |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/products/en?q=6605424-1 6605424-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154361/ 615-4361] || [http://www.te.com/catalog/pn/en/6605424-1?RQPN=6605424-1 Link] || Netzwerkbuchse ohne LED, Verriegelung Unten |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/pn/en/5-6605308-1 5-6605308-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154383/ 615-4383] || [http://www.te.com/catalog/pn/en/5-6605308-1?RQPN=5-6605308-1 Link] || Netzwerkbuchse mit LED, Verriegelung Unten |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/products/en?q=6605759-1 6605759-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154399/ 615-4399] || [http://www.te.com/catalog/pn/en/6605759-1?RQPN=6605759-1 Link] || Netzwerkbuchse ohne LED, Verriegelung Oben |- align="right" | RJ45 Buchse || TE Connectivity || [http://www.te.com/catalog/products/en?q=5-6605758-1 5-6605758-1] || RS-Components || [http://at.rs-online.com/web/p/products/06154412/ 615-4412] || [http://www.te.com/catalog/pn/en/5-6605758-1?RQPN=5-6605758-1 Link] || Netzwerkbuchse mit LED, Verriegelung Oben |- align="right" | Hutschienen Gehäuse || Axxatronic || [http://www.axxatronic.de/serie-cnmb.html CNMB-4-KIT-CON] || Conrad || [http://www.conrad.at/ce/de/product/531443/Axxatronic-Hutschienen-Gehaeuse-CNMB-4-KIT-CON-Polycarbonat-L-x-B-x-H-90-x-710-x-58-mm 531443 - 62] || [http://www.axxatronic.de/serie-cnmb.html Link] || (L x B x H) 90 x 71.0 x 58 mm |- align="right" | DS2450 || Maxim || [http://www.maximintegrated.com/datasheet/index.mvp/id/2921 DS2450] || RS-Components || [http://at.rs-online.com/web/p/products/07327557/ 732-7557] || [http://datasheets.maximintegrated.com/en/ds/DS2450.pdf Link] || Onewire quad AD Converter |- align="right" | HIH4000-001 || Honeywell || [http://sensing.honeywell.com/product%20page?pr_id=53944 HIH4000-001] || RS-Components || [http://at.rs-online.com/web/p/products/05283171/ 528-3171] || [http://sensing.honeywell.com/product%20page?pr_id=53944 Link] || Luftfeuchte Sensor von Honeywell |- align="right" | MPXH6115AC6U || Freescale || xx || RS-Components || [http://at.rs-online.com/web/p/products/07176536/ 717-6536] || [http://www.freescale.com/files/sensors/doc/data_sheet/MPXA6115A.pdf Link] || Luftdruck Sensor von Freescale |} ==Die Software== [[File:Ethersex det ssr.png|400px|thumb|die Theorie]] [[File:Hausbus v1.JPG|400px|thumb|die Praxis]] ===TFTP-Bootloader & Fuses=== Menuconfig: │ │ Load a Default Configuration ---> │ │ [*] Ethernet Bootloader │ │ Network ---> │ │ [*] Ethernet (ENC28J60) support ---> │ │ Etherrape IP address: "192.168.12.220" │ │ Netmask: "255.255.255.0" │ │ [*] UDP support │ │ [*] UDP broadcast support │ │ Applications ---> │ │ [*] TFTP support ---> │ │ Bootloader configuration ---> │ │ [*] TFTP-o-matic │ │ --- TFTP-o-matic configuration │ │ TFTP IP address: "192.168.12.120" │ │ TFTP image to load: "ethersex.bin" make clean && make --> ethersex.hex =======The ethersex project======== Compiled for: atmega644 at 20000000Hz Imagesize: 6064/65536 bytes (9.25%) [==----------------------------] Program (.text + .data) : 6064 bytes Data (.data + .bss) : 826 bytes =================================== sudo avrdude -cusbasp -pm644 -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m sudo avrdude -cusbasp -pm644 -U flash:w:ethersex.hex sudo avrdude -cusbasp -pm644 -U lock:w:0x0F:m Achtung bei den SMD Typen vom mega644, ich habe mega644P bekommen, wobei ich jetzt nicht weiß ob die SMD immer P Typen sind. Egal das Problem ist man sollte avrdude genau lesen und auch "-p m644p" anhängen da der P Type eine andere Signatur aufweist. Hat mich ne Stunde gekostet. ;) ==Bilder== ===Testsystem=== <gallery perrow=7> File:1_stella_all_off.jpg File:2_stella_all_on.jpg File:3_mosfets.jpg File:4_schaltung_fet.png File:IMG_5286.JPG File:IMG_6592.JPG File:IMG_6594.JPG File:S0-zaehler_img.JPG File:Esex sensor1.JPG </gallery><br> ==Probleme== 25.1.2011 - ethersex mit m644 und 32khz uhrenquarz.<br> datenblatt mega644 seite 101 - http://www.atmel.com/dyn/resources/prod_documents/doc2593.pdf<br> services/clock/clock.c - zeile 64<br> <obiflix> du könntest https://github.com/ethersex/ethersex/commit/da511f074940423e8e8ef7ee67ca20e6d91f608c rückgängig machen <obiflix> möglicherweise bekommst du dann probleme mit dcf77, falls du das nutzen möchtest, aber einen versuch ist es wert ;) Notiz: Hat funktioniert für den MEGA644<br> Update#1<br> 26.1.2011 - Problem sollte nun behoben sein, Danke an eku! master Erik Kunze * ae3ef98 (2 files in 1 dirs): use timer makros for prescaler 64 (32768Hz/256/64=2Hz) - http://bit.ly/eG2d4c --- DCF muss noch getestet werden ==Notizzettel== schnell mal notiert ein script zum email versenden wenn zb..PIN_LOW... <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include <util/delay.h> CONTROL_START CLOCK_USED() ECMD_GLOBAL(t1, 0, uint16_t); ECMD_GLOBAL(var1, 0); ECMD_GLOBAL(var2, 0); ECMD_GLOBAL(aqua_mail_sent, 0, uint8_t) THREAD(start) if (!PIN_HIGH(WTR)) t1++; else t1=0; if (t1 > 10) var1=1; else var1 = 0; if (t1 > 400) var2=1; else var2 = 0; if (var1 == 1) PIN_CLEAR(LED1); else PIN_SET(LED1); if (var2 == 1){ if (aqua_mail_sent == 0){ PIN_CLEAR(LED2); mail_send(); aqua_mail_sent = 1; } var2 = 0; }else{ PIN_SET(LED2); } THREAD_END(start) ON STARTUP DO THREAD_START(start) END CONTROL_END </source> ==Levelshifter 3.3V 5V== <gallery perrow=1> File:Levelshifter.png </gallery><br> Source: http://wiki.senseye.org/adir/levelshifter/levelshifter.sch e89418eac05665c5a31fa7e2ec7ef9d60ec28396 0 29 1815 1452 2018-05-10T17:27:33Z GooPie4o 265 wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR Receivers->IRMP IR |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |TIMER={{occupies_timer|0}}&{{occupies_timer|2}} (RX & TX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} [[File:Irm.jpg|200px|thumb|right|IR sender/receiver module with display and USB connector]] IRMP is a port of the [http://www.mikrocontroller.net/articles/IRMP infrared multi-protocol decoder] for [[Ethersex]]. == Connection == The reception of IR signals is performed by a receiver TSOP1736 type (or similar). This may be connected to any pin. The interrogation of the pins and the decoding of the IR protocol is done in an ISR, which occupies one 8-bit timer of the ATmegas. When sending the signal with the carrier frequency of the respective IR Protocol is [[PWM]] modulated. This is another 8-bit timer of the ATmegas (OC0/OC2) is demonstrated. On the [[Etherrape]] board takes a [[NE555]] this function, ie the option ''Use external modulator for the transmitter'' is activated. It saves a timer on the [[AVR]] is set at a carrier frequency. Example of a ATMega32 from: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Meaning: * IRMP_RX - pin the IR receiver is connected to * IRMP_USE_TIMER2 - use Timer2 for receiver, Timer0 for sender (undef = reversed) * IRMP_RX_LOW_ACTIVE - the IR receiver is low-active (undef = high-active) * IRMP_RX_LED_LOW_ACTIVE - the control LED of the receiver is switched to USS (undef = switched to GND) * IRMP_TX - pin the IR sender is connected to (=output of Timer0 or Timer2, see IRMP_USE_TIMER2)<br>'''Caution: 0A to 2A if MCU with A / B channel''' Without an external modulator, pins other than OC0 or 0C2 can not be used. Trying to do so will fail without an error message. * IRMP_TX_LED_LOW_ACTIVE - the control LED of the sender is switched to USS (undef = switched to GND) == Configuration == Each supported IR protocol occupies memory of code. Therefore, one should select only the required protocols. A detailed overview of the protocols are in [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail article in the mikrocontroller forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] A1TVBOX │ │ [ ] ACP24 ... │ │ [ ] THOMSON │ │ [ ] VINCENT │ │ --- Network │ │ [*] Remote IRMP │ │ (10001) UDP port (default 10001) │ │ --- Debugging Flags │ │ [ ] IRMP │ │ [ ] Remote IRMP IRMP also decodes the RC5 protocol, so that the separately [[Ethersex]] contained [[RC5]] decoder is not needed any longer. == [[ECMD]] == IRMP implements an [[ECMD]] interface for reading received and decoded IR commands and send IR commands. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == === Output received characters via [[SYSLOG|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> IRMP_READ checks for received IR code and stores it in the variables IRMP_PROTOCOL, IRMP_ADDRESS, and IRMP_COMMAND IRMP_FLAGS. Return values ​​greater than zero indicate the validity of the variables. If IRMP_FLAGS = 1 it is a repetition. === Control of [[StellaLight|Stella]]/Pins by IR commands === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> The script switches the Stella channel 0 to 255 or 0, the remote control is a Denon (Protocol 8). With ''include'' access to the Stella sources granted.<br> Instead of ''"stella_setValue (STELLA_SET_IMMEDIATELY, 0, 255);"'' ''"PIN_SET (LED)"'' and ''"PIN_CLEAR (LED)"'' can be used ([[Named_PIN|named pin]]). |Named PIN]]). === Send IR commands === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSH dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5 dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSG32 dnl 11 = APPLE dnl 12 = RECS80EX dnl 13 = NUBERT dnl 14 = BANG dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO dnl 24 = IR60 dnl 25 = KATHREIN dnl 26 = NETBOX dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON dnl 31 = BOSE dnl 32 = A1TVBOX dnl 33 = ORTEK dnl 34 = TELEFUNKEN dnl 35 = ROOMBA dnl 36 = RCMM32 dnl 37 = RCMM24 dnl 38 = RCMM12 dnl 39 = SPEAKER dnl 40 = LGAIR dnl 41 = SAMSG48 dnl 42 = MERLIN dnl 43 = PENTAX dnl 44 = FAN dnl 45 = S100 dnl 46 = ACP24 dnl 47 = TECHNICS dnl 48 = PANASONIC dnl 49 = MITSU_HEAVY dnl 50 = VINCENT dnl 51 = SAMSUNGAH dnl 52 = IRMP16 dnl 53 = RADIO1 IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Command 5678 to device 1234 will be send with one repetition using the NEC protocol. == Remote IRMP == [[File:Remote_buttler.png|200px|thumb|right|Android App]] This is an implementation of the [https://www.mikrocontroller.net/articles/Remote_IRMP Remote IRMP protocol ] in [[Ethersex]]. Control your HiFi equipment with your smartphone. 34e9acb4926b73cc540d7417a9f14a4ec31af120 0 30 1816 1453 2018-05-10T17:29:43Z GooPie4o 265 wikitext text/x-wiki {{i18n|IRMP}} {{Module |NAME=IRMP |MENUCONFIG={{I/O}}->IR Receivers->IRMP |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= - |TIMER={{occupies_timer|0}}&{{occupies_timer|2}} (RX & TX) |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp https://github.com/ethersex/ethersex/tree/master/hardware/ir/irmp] }} [[File:Irm.jpg|200px|thumb|right|IR Sender/Empfänger-Modul mit LCD und USB-Anschluss]] IRMP ist eine Portierung des [http://www.mikrocontroller.net/articles/IRMP Infrarot-Multiprotokoll-Decoders] nach [[Ethersex]]. == Anschluss == Der Empfang der IR-Signale erfolgt durch einen Empfänger vom Typ TSOP1736 (oder ähnlich). Dieser kann an einem beliebigen Pin angeschlossen werden. Die Abfrage des Pins und die Dekodierung des IR-Protokolls erfolgt in einer ISR, die einen 8-Bit-Timer des ATMEGAs belegt. Beim Senden wird das Signal mit der Trägerfrequenz des jeweiligen IR-Protokolls über [[PWM_(Deutsch)|PWM]] moduliert. Dazu wird ein weiterer 8-Bit Timer des ATMEGAs (OC0/OC2) belegt. Auf dem '''[[Etherape_(Deutsch)|Etherrape]]'''-Board übernimmt ein [[NE555_(Deutsch)|NE555]] diese Funktion, d.h. die Option ''Use external modulator for sender'' ist zu aktivieren. Man spart einen Timer des [[AVR_(Deutsch)|AVR]] und ist auf eine Trägerfrequenz festgelegt. Beispiel für einen ATMega32 aus: ''pinning/hardware/pollin_evalboard_addon.m4'' ifdef(`conf_IRMP', `dnl pin(IRMP_RX, PD2) #define IRMP_USE_TIMER2 #define IRMP_RX_LOW_ACTIVE #undef IRMP_RX_LED_LOW_ACTIVE pin(IRMP_TX, PD7) dnl OC2/OC2A #undef IRMP_TX_LED_LOW_ACTIVE ') Bedeutung: * IRMP_RX - Pin an dem der IR-Empfänger angeschlossen ist * IRMP_USE_TIMER2 - benutze Timer2 für den Empfang, Timer0 für das Senden (undef = umgekehrt) * IRMP_RX_LOW_ACTIVE - der IR-Empfänger ist Low-Aktiv (undef = High-aktiv) * IRMP_RX_LED_LOW_ACTIVE - die Kontroll-LED des Empfängers ist gegen USS geschaltet (undef = gegen GND geschaltet) * IRMP_TX - Pin an dem der IR-Sender angeschlossen ist (= Ausgang des Timer0 oder Timer2, vgl. IRMP_USE_TIMER2)<br>'''Achtung: 0A bzw 2A bei MCU mit A/B Kanal''' Ohne einen externen Modulator sind ausschließlich OC0 oder OC2 möglich. Der Versuch einen anderen Pin zu konfigurieren wird ohne Fehlermeldung fehlschlagen. * IRMP_TX_LED_LOW_ACTIVE - die Kontroll-LED des Senders ist gegen USS geschaltet (undef = gegen GND geschaltet) == Konfiguration == Jedes unterstützte IR-Protokoll "verbrät" Speicher an Code. Deshalb sollte man nur die benötigten Protokolle auswählen. Eine detailierte Übersicht über die Protokolle gibt der [http://www.mikrocontroller.net/articles/IRMP#Die_IR-Protokolle_im_Detail Artikel im Mikrocontroller Forum]. │ │ Load a Default Configuration ---> │ │ General Setup ---> │ │ [*] Status LEDs ---> │ │ [*] Status LED (Received) │ │ [-] RFM12 RX │ │ [ ] ZBUS RX │ │ [*] IRMP RX ... │ │ Network ---> │ │ I/O ---> ... │ │ [*] IR Receivers ---> ... │ │ [ ] RC5 IR ---> │ │ [*] IRMP IR ---> ... │ │ [*] Receive IR-codes │ │ [*] Send IR-codes │ │ [ ] Use external modulator for sender │ │ [*] IRMP ecmd │ │ --- Protocols │ │ [ ] A1TVBOX │ │ [ ] ACP24 ... │ │ [ ] THOMSON │ │ [ ] VINCENT │ │ --- Network │ │ [*] Remote IRMP │ │ (10001) UDP port (default 10001) │ │ --- Debugging Flags │ │ [ ] IRMP │ │ [ ] Remote IRMP IRMP dekodiert auch das RC5-Protokoll, so dass der separat in [[Ethersex_(Deutsch)|Ethersex]] enthaltene [[RC5_(Deutsch)|RC5]]-Dekoder nicht länger benötigt wird. == [[ECMD_(Deutsch)|ECMD]] == IRMP implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle zum Auslesen empfangener und dekodierter IR-Kommandos und zum Senden von IR-Kommandos. Siehe [[ECMD_Reference|ECMD Referenz]]. == [[Control6_(Deutsch)|Control6]] == === Ausgabe empfangener IR-Zeichen via [[SYSLOG_(Deutsch)|Syslog]] === <source lang="text"> CONTROL_START THREAD(read_irmp) ON IRMP_READ > 0 DO SYSLOG("IRMP %02hhd:%04hX:%04hX:%02hhX\n", IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND, IRMP_FLAGS); END THREAD_END(read_irmp) ON STARTUP DO THREAD_START(read_irmp); END CONTROL_END </source> Mit IRMP_READ wird auf empfangenen IR-Code geprüft und dieser in die Variablen IRMP_PROTOCOL, IRMP_ADDRESS, IRMP_COMMAND und IRMP_FLAGS gespeichert. Rückgabewerte größer Null signalisieren die Gültigkeit der Variablen. Bei IRMP_FLAGS=1 handelt es sich um eine Wiederholung. === Steuern von [[StellaLight_(Deutsch)|Stella]]/Pins durch IR-Zeichen === <source lang="text"> C6_HEADER(`/* This will be in control6.h */') #include "services/stella/stella.h" CONTROL_START THREAD(control_stella) ON IRMP_READ > 0 DO if(IRMP_PROTOCOL==8 && IRMP_ADDRESS==0x0002) { switch(IRMP_COMMAND) { case 0x0268: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255); break; case 0x0068: stella_setValue(STELLA_SET_IMMEDIATELY, 0, 0); break; } } END THREAD_END(control_stella) ON STARTUP DO THREAD_START(control_stella); END CONTROL_END </source> Das Script schaltet den Stella Channel 0 auf 255 oder auf 0, die Fernbedienung ist hier eine Denon (Protocol 8). Mit ''include'' wurde dem Script der Zugriff auf die Stellasourcen gestattet.<br> Statt ''"stella_setValue(STELLA_SET_IMMEDIATELY, 0, 255);"'' kann auch ''"PIN_SET(LED)"'' und ''"PIN_CLEAR(LED)"'' verwendet werden ([[Named_PIN_(Deutsch)|Named PIN]]). === Senden von IR-Zeichen === <source lang="text"> dnl 01 = SIRCS dnl 02 = NEC dnl 03 = SAMSUNG dnl 04 = MATSUSH dnl 05 = KASEIKYO dnl 06 = RECS80 dnl 07 = RC5 dnl 08 = DENON dnl 09 = RC6 dnl 10 = SAMSG32 dnl 11 = APPLE dnl 12 = RECS80EX dnl 13 = NUBERT dnl 14 = BANG dnl 15 = GRUNDIG dnl 16 = NOKIA dnl 17 = SIEMENS dnl 18 = FDC dnl 19 = RCCAR dnl 20 = JVC dnl 21 = RC6A dnl 22 = NIKON dnl 23 = RUWIDO dnl 24 = IR60 dnl 25 = KATHREIN dnl 26 = NETBOX dnl 27 = NEC16 dnl 28 = NEC42 dnl 29 = LEGO dnl 30 = THOMSON dnl 31 = BOSE dnl 32 = A1TVBOX dnl 33 = ORTEK dnl 34 = TELEFUNKEN dnl 35 = ROOMBA dnl 36 = RCMM32 dnl 37 = RCMM24 dnl 38 = RCMM12 dnl 39 = SPEAKER dnl 40 = LGAIR dnl 41 = SAMSG48 dnl 42 = MERLIN dnl 43 = PENTAX dnl 44 = FAN dnl 45 = S100 dnl 46 = ACP24 dnl 47 = TECHNICS dnl 48 = PANASONIC dnl 49 = MITSU_HEAVY dnl 50 = VINCENT dnl 51 = SAMSUNGAH dnl 52 = IRMP16 dnl 53 = RADIO1 IRMP_PROTOCOL = 2; IRMP_ADDRESS = 1234; IRMP_COMMAND = 5678; IRMP_FLAGS = 1; IRMP_WRITE; </source> Kommando 5678 an Gerät 1234 wird mit einer Wiederholung im NEC-Protokoll gesendet. == Remote IRMP == [[File:Remote_buttler.png|200px|thumb|right|Android App]] Dies ist die Implementierung des [https://www.mikrocontroller.net/articles/Remote_IRMP Remote IRMP Protocols] in [[Ethersex]]. Damit wird es möglich, mit einer Android-App eine anlernbare IR-Fernbedienung zu realisieren. Der Anwender kann dann mehrere Geräte, die irgendwo im Haushalt verteilt sind, über das Handy steuern. Dabei sendet die App über WLAN zuvor gespeicherte IRMP-Codes an das gewünschtee Ethersex Gerät. Dieses strahlt dann die Signale über den IR-Sender aus, um damit unsere Geräte aus der Unterhaltungsindustrie zu schalten. edda18bd6b821f52c3ea595223ab923747225282 0 360 1817 1261 2018-05-10T17:32:02Z GooPie4o 265 wikitext text/x-wiki {{i18n|SD_CARD}} {{Module |NAME=SD/MMC-Card Reader |MENUCONFIG={{I/O}}->Storage->SD/MMC-Card Reader |STATUS={{stable}} |PINNING=yes |ECMD={{has_ecmd}} |CONTROL6={{has_control6}} |DEPENDS=[[ECMD]] |REQUIRES= |TIMER= |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader https://github.com/ethersex/ethersex/tree/master/hardware/storage/sd_reader] }} The module is based on Roland Riegel's [http://www.roland-riegel.de/sd-reader/ MMC/SD/SDHC card library] complemented by the connection to the Ethersex [[VFS|Virtual File System]]. == Connection == [[File:Sdcard adapter schaltung.png|200px|thumb|right|SD-Card adapter circuit diagram]] [[File:Sdcard adapter.jpg|200px|thumb|right|SD-Card adapter module]] [[File:Microsd_adapter.jpg|200px|thumb|right|MicroSD card adapter with level-shifter from China]] MMC and SD memory cards can be used in [[SPI]] mode relatively easily controlled with a microcontroller. In principle, there is not between SD Card and MMC many differences, but SD cards are more common, generally faster than MMCs, and have a better-implemented SPI interface. There are several variants (miniSD, microSD), which are largely compatible with the standard SD-card. The card reads the adjacent data bits with the rising clock edge, as [[SPI]] modes are thus suitable Mode 0 and Mode 3 In MMCs, the SPI mode is not precisely specified, so it does happen sometimes that the SPI mode must be selected differ depending on the card. SD cards are typically often operated with 3.3V and 5V microcontrollers. This forces a [http://www.mikrocontroller.net/articles/Pegelwandler#5V_.3C-.3E_3.3V level adjustment], because the input lines to the SD card are not 5V tolerant. [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#Bekannte_Fehler A level adjustment] with resistors is not recommended. In addition to the lines leading to the SD card, there are two other lines which lead to the SD card socket: namely, the card-detect line and the write-protect line. They serve as the name already say, to signal the physical presence of a card in the SD socket and the position of the write protect switch. If hardware SPI used, only the chip select line must be configured. The card-detect line and the write-protect line are optional and MicroSD anyway not exist. ifdef(`conf_SD_READER', ` /* port the sd-reader CS is attached to */ pin(SPI_CS_SD_READER, PB2, OUTPUT) /* uncomment and edit this if you have connected the CD (card detect) signal */ pin(SD_READER_AVAILABLE, PD4, INPUT) /* uncomment and edit this if you have connected the WP (write protected) signal */ pin(SD_READER_WR_PROTECT, PD5, INPUT) ') Another problem with the SD card is the initialization. Manages Ethersex not in a certain time to sync, so the card into the normal drops (not the SD) mode and can no longer be addressed. A solution for this is that the card receives a controllable power supply. For this purpose, we define the pinning only pin pin(SD_READER_POWERON, PB3, OUTPUT) === Connector === A cheap type of contact is probably cannibalizing a cheap card reader if you want to solder any cables directly to the card. Individually purchased connectors can usually considerably teuerer. Even [http://uanr.com/sdfloppy/ old floppy cable] can be used as cheap connectors. Parts of AT slots or connectors of 5.25-inch floppies go. If necessary, you can see the card between two rows of pin strip pinch (or solder). It's even cheaper if you use micro or mini SD cards and usually included adapter anlötet. However, anyone who wants to give up a DIY, alternatively, for relatively little money a [http://www.shop.display3000.com/elektronikmodule/sd-kartenmodul/index.html completely assembled SD adapter] available for purchase to be connected to the AVR. With this adapter already is a bidirectional signal level between the 5V levels of the control lines of the AVR and the 3.3 V level of the SD card on board. Affordable modules sourced from China are available on [http://www.ebay.com/sch/i.html?_from=R40&_sacat=0&_nkw=Micro+SD+Card+Module+SPI&rt=nc&LH_PrefLoc=2 ebay]. == Configuration == | | I/O ---> | | ... │ │ Storage ---> │ │ ... | | [*] SD/MMC-Card Reader ---> | | ... | | [ ] SDHC support | | | | [*] VFAT LFN support | | | | [ ] Read-only mode | | | | [*] Use read-timeout | | | | [*] Ping-read SD card every 10s | | | | --- ECMD Support | | | | [*] info | | | | [*] dir | | | | [*] mkdir | | | | [*] rm | | | | --- Debugging Flags | | | | [*] FAT | | | | [*] RAW | | | | [*] VFS | | | | General Setup ---> | | ... | | [*] VFS (Virtual File System) support ---> | | ... | | [*] SD/MMC-Card Filesystem | | == [[ECMD|ECMD]] == The SD CARD module implements an [[ECMD]] interface. See [[ECMD_Reference|ECMD reference]]. == [[Control6|Control6]] == The following example writes the date, time and temperature by VFS_LOG_ALLOCA (VFS_LOG requires UIP) in the file "temp.log" as soon as the temperature has changed by more than a degree to the last measurement. For date and time CLOCK_SUPPORT must be enabled. <pre> #include <stdlib.h> int16_t Temperatur; int16_t Temperatur_alt; CONTROL_START THREAD(read_temp) Temperatur = ONEWIRE_GET(10d85594010800eb); ON abs(Temperatur-Temperatur_alt)>10 DO uint8_t sign = Temperatur<0; div_t res = div(abs(Temperatur),10); VFS_LOG_ALLOCA("temp.log", 50, "%2d.%2d.%4d %2d:%02d %S%d.%d", CLOCK_DAY, CLOCK_MONTH, CLOCK_YEAR, CLOCK_HOUR, CLOCK_MIN, sign?PSTR("-"):PSTR(""),res.quot,res.rem) Temperatur_alt = Temperatur; END WAIT(15); THREAD_END(read_temp) ON STARTUP DO Temperatur = Temperatur_alt = 0; THREAD_START(read_temp); END CONTROL_END </pre> 505459b0937281ae7660a7e05544c3f3620b31ba 0 563 1819 2018-05-11T17:15:02Z GooPie4o 265 Created page with "{{i18n|Temperaturmesssystem}}" wikitext text/x-wiki {{i18n|Temperaturmesssystem}} de297519f3615fa1511f09b9339c258191224332 0 149 1820 570 2018-06-03T13:49:00Z GooPie4o 265 I18n wikitext text/x-wiki {{i18n|BMP085}} {{Module |NAME=BMP085 |MENUCONFIG={{I/O}}->{{I2C Master}}->BMP085 |STATUS={{experimental}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]], [[I2C]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/blob/master/hardware/i2c/master/i2c_bmp085.c https://github.com/ethersex/ethersex/blob/master/hardware/i2c/master/i2c_bmp085.c ] }} = Bosch BMP085 and BMP180 barometric pressure sensors = == Sensors == * Cheap (about 6 EUR) * Small * Precise (Resolution 0.25m, absolute accuracy +-2.5 hPa) * Digital readout via I2C * BMP085 and BMP180 are code-compatible, the BMP180 comes in a smaller package [http://www.bosch-sensortec.com/content/language1/html/3477.htm Datasheets] == Availibility == Pure sensors * [http://www.digikey.com Digikey] Breakout boards * [http://jeelabs.com/products/pressure-plug JeeLabs] * Sparkfun * [http://www.watterott.com/de/Breakout-Board-mit-dem-BMP085-absoluten-Drucksensor Watterott] == [[ECMD]] == {| border=1 | '''Command Syntax''' | '''Short description''' |- | bmp085 temp | Returns the temperature in 0.1°C (16 Bit integer) |- | bmp085 apress | Returns the absolute pressure in Pa (32 Bit integer) |- | bmp085 height <p0> | Returns the height in cm. Needs the pressure p0 at NN as parameter (given in Pa, 32 Bit integer). |- | bmp085 pressnn <height> | Returns the pressure p0 at NN in Pa. Needs the current height in cm (32 Bit integer). |- |} == Pressure calculations == * Pressure calculations for the height and pressnn commands are done using the [http://en.wikipedia.org/wiki/Barometric_formula Barometric formula] == Precision == * The sensor is sensitive to air turbulences (propellers, fans, loud music) * The sensor is sensitive to power supply ripple - if not using a battery try to filter it well * The results will have some noise, filter them with a moving average or other algorithm to get good results 9930d02b033d95a8accd074449b86cd33f3f7aeb 0 564 1821 2018-06-10T11:39:40Z GooPie4o 265 Created page with "{{i18n|BH1750}} {{Module |NAME=BH1750 |MENUCONFIG={{Hardware}}->I2C->I2C master->I2C BH1750 light sensor |STATUS={{Experimental}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6=no..." wikitext text/x-wiki {{i18n|BH1750}} {{Module |NAME=BH1750 |MENUCONFIG={{Hardware}}->I2C->I2C master->I2C BH1750 light sensor |STATUS={{Experimental}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=I2C Master |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/i2c/master/ https://github.com/ethersex/ethersex/tree/master/hardware/i2c/master/] }} 0fe35290d13aaa066c85c5627437f4ae59115b13 1825 1821 2018-06-10T12:03:17Z GooPie4o 265 wikitext text/x-wiki {i18n|BH1750}} {{Module |NAME=BH1750 |MENUCONFIG={{Hardware}}->I2C->I2C master->I2C BH1750 light sensor |STATUS={{Experimental}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]], [[I2C]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/i2c/master/i2c_bh1750.c https://github.com/ethersex/ethersex/tree/master/hardware/i2c/master/i2c_bh1750.c] }} 4e706bebb077da0a69cd34fcb80205674b808225 1826 1825 2018-06-10T12:04:05Z GooPie4o 265 wikitext text/x-wiki {{i18n|BH1750}} {{Module |NAME=BH1750 |MENUCONFIG={{Hardware}}->I2C->I2C master->I2C BH1750 |STATUS={{Experimental}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]], [[I2C]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/i2c/master/i2c_bh1750.c https://github.com/ethersex/ethersex/tree/master/hardware/i2c/master/i2c_bh1750.c] }} 2f1302fa3f78bb7610f4bb1ec3f96d8ebaa52037 0 565 1822 2018-06-10T11:40:08Z GooPie4o 265 Created page with "{{i18n|BH1750}} {{Module |NAME=BH1750 |MENUCONFIG={{Hardware}}->I2C->I2C master->I2C BH1750 light sensor |STATUS={{Experimental}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6=no..." wikitext text/x-wiki {{i18n|BH1750}} {{Module |NAME=BH1750 |MENUCONFIG={{Hardware}}->I2C->I2C master->I2C BH1750 light sensor |STATUS={{Experimental}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=I2C Master |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/i2c/master/ https://github.com/ethersex/ethersex/tree/master/hardware/i2c/master/] }} 0fe35290d13aaa066c85c5627437f4ae59115b13 1823 1822 2018-06-10T11:47:22Z GooPie4o 265 wikitext text/x-wiki {{i18n|BH1750}} {{Module |NAME=BH1750 |MENUCONFIG={{Hardware}}->I2C->I2C master->I2C BH1750 light sensor |STATUS={{Experimental}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=I2C Master |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/i2c/master/ https://github.com/ethersex/ethersex/tree/master/hardware/i2c/master/] }} == [[ECMD]] == BH1750 implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle zur Steuerung des Sensors. Siehe [[ECMD_Reference|ECMD Referenz]]. 7ec86005aae6f16a120cd3308bf7f142dbfb6265 1824 1823 2018-06-10T12:03:04Z GooPie4o 265 wikitext text/x-wiki {{i18n|BH1750}} {{Module |NAME=BH1750 |MENUCONFIG={{Hardware}}->I2C->I2C master->I2C BH1750 light sensor |STATUS={{Experimental}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]], [[I2C]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/i2c/master/i2c_bh1750.c https://github.com/ethersex/ethersex/tree/master/hardware/i2c/master/i2c_bh1750.c] }} == [[ECMD]] == BH1750 implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle zur Steuerung des Sensors. Siehe [[ECMD_Reference|ECMD Referenz]]. 7d45d0e13556164b84b07cf3232ad8f53c46ee0e 1827 1824 2018-06-10T12:04:19Z GooPie4o 265 wikitext text/x-wiki {{i18n|BH1750}} {{Module |NAME=BH1750 |MENUCONFIG={{Hardware}}->I2C->I2C master->I2C BH1750 |STATUS={{Experimental}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]], [[I2C]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/i2c/master/i2c_bh1750.c https://github.com/ethersex/ethersex/tree/master/hardware/i2c/master/i2c_bh1750.c] }} == [[ECMD]] == BH1750 implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle zur Steuerung des Sensors. Siehe [[ECMD_Reference|ECMD Referenz]]. de75782574609f08ef6990e8e3232b8c3507d711 1828 1827 2018-06-16T12:26:00Z GooPie4o 265 wikitext text/x-wiki {{i18n|BH1750}} {{Module |NAME=BH1750 |MENUCONFIG={{Hardware}}->I2C->I2C master->I2C BH1750 |STATUS={{Experimental}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]], [[I2C]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/tree/master/hardware/i2c/master/i2c_bh1750.c https://github.com/ethersex/ethersex/tree/master/hardware/i2c/master/i2c_bh1750.c] }} == [[ECMD]] == BH1750 implementiert eine [[ECMD_(Deutsch)|ECMD]] Schnittestelle zur Steuerung des Sensors. Siehe [[ECMD_Reference|ECMD Referenz]]. {| border=1 | '''Command Syntax''' | '''Short description''' |- | bh1750 mode auto_power_down | Setzen des Arbeitsmodus (Empfindlichkeit 1=Niedrig, 2=Mittel 3=Hoch 99=Automatisch, Stromsparmodus 0=aus, 1=an) |- | bh1750 lux | Abfrage der gemessenen Helligkeit in Lux |- |} 6d12e813fd39d357573f7b378873e1194ea6407b 0 566 1829 2018-06-16T12:34:12Z GooPie4o 265 Created page with "{{i18n|BMP085}} {{Module |NAME=BMP085 |MENUCONFIG={{I/O}}->{{I2C Master}}->BMP085 |STATUS={{experimental}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]], I2C..." wikitext text/x-wiki {{i18n|BMP085}} {{Module |NAME=BMP085 |MENUCONFIG={{I/O}}->{{I2C Master}}->BMP085 |STATUS={{experimental}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]], [[I2C]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/blob/master/hardware/i2c/master/i2c_bmp085.c https://github.com/ethersex/ethersex/blob/master/hardware/i2c/master/i2c_bmp085.c ] }} = Bosch BMP085 und BMP180 Luftdrucksensoren == Sensors == * Billig (ca. 6 EUR) * Klein * Präzise (Auflösung 0,25 m, absolute Genauigkeit + -2,5 hPa) * Digitalanzeige über I2C * BMP085 und BMP180 sind Code-kompatibel, der BMP180 kommt in einem kleineren Paket [http://www.bosch-sensortec.com/content/language1/html/3477.htm Datenblätter] == Verfügbarkeit == Sensoren * [http://www.digikey.com Digikey] Breakout boards * [http://jeelabs.com/products/pressure-plug JeeLabs] * Sparkfun * [http://www.watterott.com/de/Breakout-Board-mit-dem-BMP085-absoluten-Drucksensor Watterott] == [[ECMD]] == {| border=1 | '''Befehlssyntax''' | '''Kurze Beschreibung''' |- | bmp085 temp | Gibt die Temperatur in 0,1 ° C (16 Bit Ganzzahl) zurück. |- | bmp085 apress | Liefert den absoluten Druck in Pa (32 Bit Integer). |- | bmp085 height <p0> | Gibt die Höhe in cm zurück. Benötigt den Druck p0 bei NN als Parameter (angegeben in Pa, 32 Bit Integer). |- | bmp085 pressnn <height> | Gibt den Druck p0 bei NN in Pa zurück. Benötigt die aktuelle Höhe in cm (32 Bit Integer). |- |} == Druckberechnungen == * Druckberechnungen für die Befehle height und pressnn erfolgen mithilfe der [http://en.wikipedia.org/wiki/Barometric_formula Barometric formula] == Präzision == * Der Sensor reagiert empfindlich auf Luftturbulenzen (Propeller, Lüfter, laute Musik) * Der Sensor reagiert empfindlich auf Stromversorgungsschwankungen - wenn Sie keine Batterie verwenden, versuchen Sie, sie gut zu filtern * Die Ergebnisse werden etwas Rauschen aufweisen, sie mit einem gleitenden Durchschnitt oder einem anderen Algorithmus filtern, um gute Ergebnisse zu erhalten 4a63865fc4958dc146958c3504badd61c1805b66 1830 1829 2018-06-16T12:34:46Z GooPie4o 265 wikitext text/x-wiki {{i18n|BMP085}} {{Module |NAME=BMP085 |MENUCONFIG={{I/O}}->{{I2C Master}}->BMP085 |STATUS={{experimental}} |PINNING=no |ECMD={{has_ecmd}} |CONTROL6=no |DEPENDS=[[ECMD]], [[I2C]] |REQUIRES= - |CODE=[https://github.com/ethersex/ethersex/blob/master/hardware/i2c/master/i2c_bmp085.c https://github.com/ethersex/ethersex/blob/master/hardware/i2c/master/i2c_bmp085.c ] }} Bosch BMP085 und BMP180 Luftdrucksensoren == Sensors == * Billig (ca. 6 EUR) * Klein * Präzise (Auflösung 0,25 m, absolute Genauigkeit + -2,5 hPa) * Digitalanzeige über I2C * BMP085 und BMP180 sind Code-kompatibel, der BMP180 kommt in einem kleineren Paket [http://www.bosch-sensortec.com/content/language1/html/3477.htm Datenblätter] == Verfügbarkeit == Sensoren * [http://www.digikey.com Digikey] Breakout boards * [http://jeelabs.com/products/pressure-plug JeeLabs] * Sparkfun * [http://www.watterott.com/de/Breakout-Board-mit-dem-BMP085-absoluten-Drucksensor Watterott] == [[ECMD]] == {| border=1 | '''Befehlssyntax''' | '''Kurze Beschreibung''' |- | bmp085 temp | Gibt die Temperatur in 0,1 ° C (16 Bit Ganzzahl) zurück. |- | bmp085 apress | Liefert den absoluten Druck in Pa (32 Bit Integer). |- | bmp085 height <p0> | Gibt die Höhe in cm zurück. Benötigt den Druck p0 bei NN als Parameter (angegeben in Pa, 32 Bit Integer). |- | bmp085 pressnn <height> | Gibt den Druck p0 bei NN in Pa zurück. Benötigt die aktuelle Höhe in cm (32 Bit Integer). |- |} == Druckberechnungen == * Druckberechnungen für die Befehle height und pressnn erfolgen mithilfe der [http://en.wikipedia.org/wiki/Barometric_formula Barometric formula] == Präzision == * Der Sensor reagiert empfindlich auf Luftturbulenzen (Propeller, Lüfter, laute Musik) * Der Sensor reagiert empfindlich auf Stromversorgungsschwankungen - wenn Sie keine Batterie verwenden, versuchen Sie, sie gut zu filtern * Die Ergebnisse werden etwas Rauschen aufweisen, sie mit einem gleitenden Durchschnitt oder einem anderen Algorithmus filtern, um gute Ergebnisse zu erhalten 3c04be8b289fd254a21ac65b574fc25eff24ae4b 0 556 1831 1719 2019-02-06T08:58:56Z Alez 726 update external link wikitext text/x-wiki mae1061 - tiny board similar to Pollin Avr-Net-Io [[File:maetech-it-mae1061_1.jpg|500px]] by Alessandro Mauro see the page at [http://wiki.maetech.it/projects/mini-ethersex-board] Key features: * Mounts ATmega32, can also mount ATmega64; * Form factor fits in a 2-modules-width DIN box; * Ethernet 10Mbps (ENC28J60); * 1 RS485 through screw 5mm connector with optional polarization and termination; * 2 opto-isolated dc-input through screw 5mm connector; * 1 low-voltage, low-current relay output through screw 5mm connector; * 1 internal i/o line on a 2 pin header that can be used for a OneWire sensor, or a configuration Jumper, or other; * 12V power supply through screw 5mm connector. compiled Ethersex using Pollin Avr-Net-Io basic configuration; just few patches are needed for the RS485 to work. '''''If you are interested in this, contact me at''''' alez at maetech dot it . 59e50791cf258d86b015f113bc5c862185dc8c5b 0 38 1832 514 2021-05-23T12:24:49Z GooPie4o 265 Moved from freenode to libera (see https://www.heise.de/news/IRC-Netz-Freenode-ist-tot-es-lebe-Libera-Chat-6050724.html) wikitext text/x-wiki {{i18n|Community}} = Mailing lists = *[http://list.zerties.org/cgi-bin/mailman/listinfo/ethersex-devel ethersex-devel] '''Discussion, Feature Request, Problems.''' Post your questions in German or English *[https://list.zerties.org/cgi-bin/mailman/listinfo/ethersex-commit ethersex-commit] '''Do not send messages to this list''' This list is read-only. Subscribe to this list if you want to be notified about changes in the code. = IRC = You can find us on [irc://libera.chat/#ethersex #ethersex] (libera.chat) If you have any questions...just ask! If no one answers right away - don't take it personally. We might just be away from keyboard. Just stick around for some time. 82042a10a3788305c8d2550935376ddb54e46b0a 0 59 1833 198 2021-05-23T12:29:01Z GooPie4o 265 Moved from freenode to libera (see https://www.heise.de/news/IRC-Netz-Freenode-ist-tot-es-lebe-Libera-Chat-6050724.html) wikitext text/x-wiki {{i18n|Community}} = Email-Verteiler = *[http://list.zerties.org/cgi-bin/mailman/listinfo/ethersex-devel ethersex-devel] *[https://list.zerties.org/cgi-bin/mailman/listinfo/ethersex-commit ethersex-commit] = IRC = Du findest uns auf [irc://libera.chat/#ethersex #ethersex] (libera.chat) Wenn du irgend eine Frage hast ... frag einfach! Falls nicht sofort jemand antwortet, nimm es nicht persönlich. Es könnte sein, dass gerade niemand von uns vor dem Computer sitzt. Schau einfach später nochmal vorbei. 9741c875b1ac46cb4e4282d83ef28e40ac54bb40